About the Authors
Todd Deshane
Graduate Student
Division of Mathematics and Computer Science
Clarkson University
Patty Jablonski
Graduate Student
Engineering Sciences Program
Clarkson University
Kevin Roberts
Undergraduate Student
Division of Mathematics and Computer Science
Clarkson University
Dr. Jeanna Matthews
Assistant Professor
Department of Computer Science
Clarkson University
1
Contact Details
Dr. Jeanna Matthews, Todd Deshane, Patty Jablonski, Kevin Roberts Department of Computer Science
Clarkson University
8 Clarkson Avenue, MS 5815
Potsdam, New York 13699 USA
{jnm, deshantm, jablonpa, robertkn}@https://www.doczj.com/doc/3b1728660.html,
Phone: 315-268-6288; Fax 315-268-2371
3
Name of Book or Article 4
Web-Based Collaborative Exploration and Characterization of Large Databases
5 Web-Based Collaborative Exploration and Characterization of Large Databases
Main Description
Groups of people in many diverse fields face the challenge of characterizing or mining information from a large database. Typically, this exploration and characterization is done via individual long-running SQL queries with little support for collaboration among those issuing the queries. In this paper, we present a generic system for collaborative exploration of large SQL databases. Our system encourages collaboration by enabling users to reuse and build upon the queries issued by others. In addition to supporting collaboration among
people, it also uses limited computing resources more efficiently by avoiding the repetition of commonly used, long-running queries by caching results. The system chooses which results to cache based on the run time of the query, the size of the result, and the user rating of the query. For queries that are already cached, it considers the number of times they have been accessed, the aggregate user rating of the query, and the degree to which the underlying tables consulted for the query have changed since the cached result was generated. Our system supports each user in their transition from new user to expert user. We introduce a
categorization of users along this spectrum and offer benefits to each category of user to support collaboration. Our system is generic and can be used to explore any collection of data tables. The data tables can be inserted into our web-based system and with only minimal configuration, collaborative exploration can begin. Short Description
We present the motivation for and design of a web-based tool for collaborative exploration and characterization of large relational databases.
Keywords
Collaborative Exploration
Database Characterization
1. Introduction
Groups of people in many diverse fields face the challenge of characterizing or mining information from a large data set. In science, the data set might contain astronomy or human genome data. In business, the data set might contain customer purchase or supply chain data. In sociology, the data set may contain census or demographic data. Companies like FedEx, UPS and Wal-Mart and scientific projects like the NASA space missions and the Human Genome Project all have terabytes of data being examined by hundreds of people.
Wherever large databases exist, regardless of their exact contents, there are groups of people seeking to understand that data. Often, this is done with individual SQL queries that summarize certain aspects of the data with little support for collaboration between people. People may work together on forming a query to submit to the system, but the system offers no direct support to help identify and exploit possible collaboration. This lack of collaboration has three main drawbacks.
- Running a query over a large data set can take hours or even days and users often run many of the same basic SQL queries to summarize basic aspects of the data set. With support for caching, users could benefit from answers obtained by other users.
- As users move beyond basic queries, it can often take several tries to write a query that accomplishes the intended purpose. With support for collaboration, users could learn from each other’s mistakes by modifying previously run successful queries. It is easier to modify a working query than to write a completely new query from scratch.
- Users may be characterizing a similar aspect of the data, but would be unable to help one another modify their queries. Without support for collaboration, they would be wasting resources by running similar queries and would be unable to build on each other’s ideas.
To address these problems, we present the design of a generic system for collaborative exploration of large data sets. Our system has the following characteristics:
1) It caches the results of commonly executed queries to avoid
repeating expensive, long-running queries.
2) It automatically caches the results of basic data characterization
queries like a histogram of values for each row element.
3) It allows new users to build on the successful queries of others,
making the system easier for new users. This could reduce the
number of expensive, long-running queries that are caused by user
error and return undesired results.
4) It allows expert users to export polished query sets that answer
important questions and benefit others.
7
Name of Book or Article
85) It allows users to export collaborative query sets that invite others
to refine queries in real time.
6) It provides a generic interface that will work across any data set
that can be represented in a relational database. In other words, the system need not be customized based on the category of data being explored.
In this paper, we describe the design of our system and present the
implementation of a prototype system that demonstrates many aspects of this design. We also tell of our experience using our prototype to support collaborative exploration of a large collection of Border Gateway Protocol (BGP) data.
In Section 2, we describe the use of query sets in our generic collaborative data exploration system. In Section 3, we present a categorization of users from new to expert and discuss the support provided by the system to each class of user. In Section 4, we describe our query caching system. In Section 5, we describe the classes of tables in the design of our system. In Section 6, we describe the implementation of the system and in Section 7 we describe how we used the system to explore a large set of publicly available Border Gateway Protocol data. In Section 8, we consider related work. Finally, in the remaining sections we conclude with contributions and future work, followed by our references.
2. Query Sets
A query set is simply a collection of queries that together characterize a certain aspect of a database. Query sets can be accompanied by a description of the query set as a whole and a description of each query. The system automatically generates a set of basic summary query sets that are useful regardless of the type of data stored in the system. Users can also export query sets that they have developed to answer a particular question. Finally, collaborative query sets can be used as a workspace for collaborative exploration.
2.1 Automated Query Sets
Regardless of the type of data stored in a large database, users begin with the same basic questions. They want to know how many tables are in the database and what the attributes of the rows in those tables are. They want to see a few sample rows from each table and know the distribution of values in each row element (e.g. maximum, minimum, average, histogram or other depending on the element type). Some of these queries like listing the tables or returning a few sample rows from a table can be run quickly. Others like a histogram of values for each row element would require long-running queries that pass over all data in the database.
These basic summary queries can be automatically generated given some basic information about the structure of the database. Also, the results of these
Web-Based Collaborative Exploration and Characterization of Large Databases
9
queries can be cached so that system resources need not be wasted on common queries that many users will want to execute. Finally, the system can determine when the cached results become invalid due to updates in the underlying tables. The system administrator and/or the users can decided whether to re-run the queries whenever the underlying tables change or whether to run them at preset intervals and to return slightly out-of-date answers in between. A basic summary query set is just one type of automated query set. There are other automated query sets that apply to any relational database regardless of the database contents. For example, one automated query set is the set of most popular queries. Another is the set of the most recently run queries. These types of automated queries build a sense of community by providing users with a sense of one another’s activity.
2.2 Polished Query Sets
To fully explore a large data set, users must move beyond automated queries to custom-crafted query sets that illustrate the types of interesting questions that can be answered from the data. Our system allows advanced users to export or publish polished query sets to other users. These query sets consist of a set of queries designed to answer a particular set of specific questions from the data. In addition to the queries, the author of the query set can write an introduction describing the purpose of the query set and can write text explaining the purpose of each query. Having experts teach new users is one type of collaboration. The benefits of these query sets to new users are clear. Without this opportunity, inexperienced users typically write many incorrect queries before they successfully write a query that returns data of interest. Also, without this opportunity, inexperienced users may have difficulty imagining all the ways in which the data can be used. However, the benefits to advanced users deserve some additional explanation. First, the results from these query sets can be cached so that new users do not tax the system resources by repeating the queries. Second, without this help, new users would tax the system many times over with incorrect and inefficient versions of queries when attempting to answer similar questions. Third, our system maintains statistics about the use of each polished query set. In this way, advanced users can document the impact of their work on others. Fourth, system administrators could decide that users who have exported query sets should be given a higher priority when running their queries based on the popularity of their exported query sets. When users examine a polished query set, they are given the opportunity to run modified versions of the queries in the set. Modifications are not incorporated into the finished query set, but the modified query is run on the database. By modifying existing queries, users have the potential of discovering new information without the hurdle of writing the original query from scratch. (Modifying a working example is always easier than starting from scratch!). Our
Name of Book or Article
10 system also allows users to provide feedback on polished query sets to the original authors. Thus, those authors who are advanced users may receive some new insight that they can incorporate into the polished query set.
2.3 Collaborative Query Sets
In polished query sets, all modifications to the query set must go through the author. However, our design also includes another type of query set, the collaborative query set, which allows users to modify the queries in place. The users who open the collaborative query set are called the “query set owners” and have the opportunity to include a description of the problem they are trying to solve. Other users can see the set of queries that have been tried. With each query tried, users can enter an explanation of the results – in what way they represent an aspect of a solution to the problem and in what way they are lacking. Users can also choose not to save a query in the query set if they don’t believe it is worthy of inclusion. The query set owner can set limits on who can join the collaborative query set – either by identifying the participant by username or limiting participation based on the expertise of the user. Query set owners can also finalize the query set when they are satisfied with the solution. In this way, the collaborative query set can become a polished query set containing all the queries tried. Query set owners can also save a modified version of their query set containing only the final polished queries if desired. Alternatively, other users may decide to use those queries as a basis for other problems and branch off in a new direction.
3. Supporting Different User Groups
System support for collaboration takes on a different form for new users than for expert users. One of the primary design goals for our system is for it to support users in their transitions from new user to expert user in a seamless and effective way. Most users will follow the same steps during this transition: 1) Get basic statistics and information about the database. 2) View previously run queries and their results. 3) Run new queries by modifying existing queries or by writing their own. 4) Assemble sets of useful queries for their own benefit and the benefit of others.
3.1 User Classification
Here we identify four specific classes of users based on their level of expertise with the system.
New users – New users are those users that are unfamiliar with this data set. New users may be experts in the field related to this data set – for example an astronomist characterizing a set of astronomy data – but they are new to this particular set of data, both its contents and the best way to write queries for the particular table structure in this database. These users will be directed to a set of basic queries that summarize the contents of the database – its table structure, number of rows in each table, range of values in each row, etc.
Interested users– Interested users are those users who have explored the database and can characterize its basic contents. By continuing to use the system, they have demonstrated that this set of data has the potential to help them. These users will be directed to a set of instructional and cached queries that illustrate interesting questions that can be answered using this data. In addition to suggesting interesting queries, these queries demonstrate important techniques for querying this particular data set like the join criteria needed to combine multiple tables or how to express a date range correctly.
Active collaborators– Active collaborators are those users who have exhausted the usefulness of the cached queries and are now ready to create queries of their own. These users can modify existing cached queries. They could also be directed to a query builder to aid in the formulation of a new query. They can now begin to test their own theories and hypotheses. They may consider participating in a collaborative query set with other active collaborators.
Expert collaborators – Expert collaborators are those users who have written successful queries of their own. These users have successfully characterized some portion of the data and can explain through a set of queries what results they have obtained. Thus, they are ready to export query sets for other users. Their results will allow others to learn and have something to build upon to explore and characterize the data better.
3.2 Moving Through the Classes of Users
Users are supported through each of these levels by the dynamic content of the page that they see when they login to the system. When new users first register with the system, they will be presented with unambiguous links to basic summary queries, along with an explanation of these queries and their results. After completing this task, users will be given a set of links to some of the most popular instructional query sets as well as an opportunity to browse or search all cached queries. Users could also be given a link to a query builder tool. When viewing the results of a cached query, users are given the opportunity to modify the query. Interested users are presented with an interface similar to that of the new users, except that the system suggests new query sets at each login.
As soon as users create their first original query (either by modifying a query or by using the query builder), they become active collaborators and a new feature is added to their initial page upon login – namely a list of recent queries that they have written. They can see whether their queries are cached and, if so, they can also view how many other users have accessed the cached results.
11
Active collaborators are presented with the option of building a query set for export. As soon as users export their first query set, they become expert collaborators and another new feature is added to their initial page upon login – namely a list of their exported query sets. They can then view the access statistics and see feedback given by other users regarding the query sets.
4. Query Caching System
In our discussion of users and query sets, we have mentioned query caching at a high level. In this section, we describe the design of our query caching system in detail.
At the highest level, the query caching system stores the results of an SQL query in a file so that they can be returned without re-running the query. For large data sets, like the ones we are dealing with, returning a cached result can save hours or days of intense computation. However, no single system has the space to cache the results of all queries. So we must choose which results to cache.
To decide whether to cache the result of a query, our query caching system considers the following five primary factors:
(1) The user’s judgment of the query (rating,R)
In our collaborative data exploration system, we expect that many queries run on the system will represent experiments rather than polished queries. As users experiment with writing queries, they will often realize when they see the result that the query was not quite right. In this case, caching the result would not be helpful. Therefore, the most important factor in caching a query is to ask users whether this query answered their question or whether modifications are required. In addition, we ask users whether they think the query results should be cached for other users to be able to view. Even if the query did answer their question correctly, it might not be a result that they expect to be of general interest.
(2) The time taken to produce the result (time, T)
The system also considers the running time of the query when deciding whether to cache the results. The faster a query runs, the less important it is to save the results. We do not save any results that are generated under a parameterizable threshold. For example, in our prototype system, we do not cache the results of any query that takes under 3 seconds to run as we consider that a reasonable response time.
(3) The size of the result (size, S)
The system also considers the size of the result. The larger the result, the less efficient it is for the system to store them. The administrator allocates a fixed amount of space for query caching. The system cannot store any result that exceeds this fixed amount. In addition, the system will not save any results
12
that are a parameterizable fraction of this fixed space. For example, in the prototype system, we do not cache any result that occupies more than 10% of the query cache.
(4) The value of keeping an existing cached query as opposed to replacing it with the new or current one (hits, H)
An initial caching value can be computed by dividing the running time by the size of the result. The units on this result are sec/KB. We also multiply by a user-supplied “interest rating.” For existing results, the user-supplied “interest rating” is replaced by a rating that reflects how often users have accessed the query results and how helpful they rated those results to be.
(5)Whether the result is currently accurate (changed percentage, C) Then, once a query result is saved based on the above criteria, the system also saves the last modification time for each table accessed during the query. These times can be consulted to determine if there is any reason to re-run the query to update the result. Even if the underlying table has changed, a result can still be useful. For example, the average value over terabytes of data is unlikely to be changed by the addition of a few new rows. Administrators of the system can designate certain queries, like the basic summary query set, for example, to be re-run when the database changes.
We combine these factors in the following formula:
C
S H
T R
**
*
where R is rating, T is time, H is hits, S is size and C is the changed percentage.
5. Use with Any Relational Database
A key design goal of our system is to be able to explore any type of data contained in a set of tables in a relational database. In other words, we did not want to require that our collaborative exploration system be modified based on the type of data being explored.
We accomplish this by dividing the tables in our database into two basic classes – infrastructure tables and domain tables. Infrastructure tables are those tables specified by our system to support the collaborative exploration functionality. Domain tables, on the other hand, contain the actual data to be explored. There can be any number of domain tables of any size and structure depending on the data set.
Some infrastructure tables are populated automatically as the system is used. For example, these include tables of users, tables of cached queries, and tables of query sets. Other infrastructure tables are populated by a system administrator that is familiar with the basic structure of the domain tables. For example, one infrastructure table lists all the domain tables and elements of each row in those tables.
13
14
Administrators also have the opportunity to set certain parameters such as the amount of space dedicated to the query cache, the maximum percentage of the query cache for any one result, and the minimum time for a cached query. In the rest of this section, we describe some of the key infrastructure tables.
5.1 Administrative Infrastructure Tables
The infrastructure tables that are populated by an administrator at installation are the ProjectInfo and ,DomainElements. The ProjectInfo table contains parameters that allow administrators to configure project-specific details like the size of the query cache, the maximum size of any one cached query result and even the filename of logo picture to customize the look of the system’s web pages. The DomainElements table is used to allow administrators to provide descriptive overviews of the data being explored. They can enter textual descriptions of each database, each table within a database and each field within a
table.
Figure 1: Relationships between the administrative infrastructure tables The DomainElements table also captures the hierarchical relationship of projects, databases, tables and field. For example, each domain database in the project has the projectId of that project as its parentElementId. Similarly, each table within a database has the elementId of that database as its parentElementId. In this way, our system can use these tables to provide a project explorer functionality. New users can quickly gain an overview of all the domain specific data by viewing a project with its administrator provided description, then each of its databases with their descriptions, etc. later, we will discuss how this browser is integrated with the cached results of automated query sets to provide a quick sense of the type of data stored in each field of each table. Care is taken to minimize the administrative set up tasks. All tasks could be automated if necessary. For example, the list of domain specific tables and their structures could be populated when the domain tables are created. The administrative set-up tasks simply give administrators a chance to enter textual
descriptions of each table and row element as well as to group domain specific tables into named projects. Similarly, administrators need not change the system defaults for parameters such as the maximum percentage of the query cache for any one result.
Since these tables are populated by an administrator, or someone who is familiar with the domain-specific data, who may not know SQL, we will provide web-based entry forms to allow easy population of these infrastructure tables Note that the database containing the infrastructure tables is stored separate from the domain-specific databases. The logical link is made by populating these infrastructure tables with the information that describes the domain-specific data sets.
5.2 Query Infrastructure Tables
Another set of tables are used to track the queries that are executed in the system and the cached results of those queries if applicable. The tables used to store all of this information are the DistinctQueries, ExecutedQueries, CachedQueries, TableModifications, and CacheQueryTableModifications tables. Figure 2 shows the relationships between these tables.
Figure 2: Relationships between the Query Infrastructure Tables
When a query is executed, the system first determines if this query has been run previously by searching for equivalent queries in the DistinctQueries tables for matching queries. If we find a match, we then look in the cached queries table to see if the result is already cached. Even if there is no direct match, we examine the cached queries to see if their results either contain the answer to the current query or can be used to return the answer to the current query more efficiently. We currently use a set of simple tests for query equivalence, but future versions could take advantage of more advanced techniques for determining query
15
equivalence and containment as described in the literature [AH01] [GL01] [SC05].
In all cases, an entry is started in the ExecutedQuery table listing the distinctQueryId for this query, the time the query was submitted and the userId for the user issuing the query. When the query actually begins to execute, the startTime will be update and when the query completes the endTime will be updated as well as information about the size of the result.
When a query completes, we decided whether to cache the result as described in Section 4. If the decision is made to cache the query, then the results will be stored in a location implied by the resultLocationID. Currently, we store it in a file with a name based on this resultLocationID, but we could also have another table mapping resultLocationID to other location information.
Also when a result is cached, we note the last modify time for each table consulted in the query. Each time a table is modified (i.e rows added, deleted or updated), we add a entry in the TableModification table with the time of the modification and the number of row affected by the change. The last modify time of a table is simply the latest time of all rows referring to that table. For each table consulted by a query, a row is added to the CacheQueryTableModification linking the queryID to the last modified row of the TableModification table. We assumed that all users of our system are not updating the data directly, They are characterizing data that may be changing as the result of periodic updates from another source.
Rows in the TableModification table are used to determine whether a cached result is still accurate and if not to compute its change percentage, C, as described in Section 4. Rows in the CacheQueryTableModification table can be deleted when the cached query they refer to is updated or removed from the cache. Similarly, rows in the TableModification table can be removed when no rows in the CacheQueryTableModification table refer to them.
Note that we do not cache multiple copies of the results from any one distinct query. We keep only the most up-to-date version. We have considered that it might be nice to see how the result of a query changes over time as a table is modified but this is currently not accommodated in the design.
Each time a query is executed – regardless of whether the result is generated directly or a cached result is returned – the user is asked to rate the usefulness of the query. This feeds is used to decide whether to cache a result in the first place and also feeds into an aggregateUserRating of each cached query.
We can use these tables to return a variety of important information to users. For example, ExecutedQueries is used to generate lists of the most recent queries and the most popular queries. The ExecutedQueries table can also be used to generate lists of queries that are currently in progress and lists of queries that are queued for execution. The CachedQueries table is used to allow users to browse cached results. Even if the results of a query are no longer cached, the ExecutedQueries table can be used to report how long it has taken to run in the past and how large the result was.
16
For each user, we can generate a list of all the queries they have executed and for each one we can determine if the results are currently cached and if so if the cached results are still acute.
Rows in the ExecutedQueries table can be truncated by time to free up space. For example, the system may choose to store only the last month of executed queries. Similarly, rows in the CachedQueries table can be removed when the result is evicted from the cache. Rows in the distinct query table can also be removed as long as they are no longer pointed to by any other tables (CachedQueries, ExecutedQueries, or QuerySets).
5.3 User and Query Set Infrastructure Tables
Another set of tables are used to track users and the query sets they create. The tables used to store users and their interactions with query sets are in the Users, UserLevels, QuerySets, QuerySetElements, and QuerySetPermissions tables. Figure 3 shows the relationships between these tables
Figure 3: Relationships between the User and Query Set Infrastructure Tables The Users table contains a unique userID, a username, a password or other authentication information, and a levelID which corresponds to the levels defined in UserLevels: New, Interested, Active, and Expert. The system could also store any number of other user attributes like email address, physical address, when they became a user, etc.
The QuerySets table contains a unique querySetID, a userID of the query set owner, and a description of the query set. The actual queried contained the query set are stored in the QuerySetElements table. This table contains the id of the parent query set, the queryID, and the userID of the query author, and a description of the query as it pertains to this query set.
Finally, QuerySetPermissions is used to control who has access to other queries. Read and/or write access can be granted to other users either by specifying them individually or by specifying a certain minimum level of users. Users with write access may add queries to the query set in which case they would be listed as the query author but not the owner of the query set. Users with read
17
access may see all the queries in the query set. Only the query set owner may delete the query set.
We can use these tables to return a variety of important information to users. For example, each user can see every query set they own and its contents. They can also see queries they have authored in other query sets. For all of these query sets and queries, they can see what results are still cached and an aggregate user rating of these queries.
5.4 Integrating the Infrastructure Tables Into Our Implementation
There are many open source database administration tools, particularly for MySQL. Before beginning the implementation of our prototype, we reviewed many of these systems. However, none of these tools provided the query caching and support for collaboration we wanted. The closest tool to ours is phpMyAdmin. [PHA05]. It does provide functionality like a database browser and query builder. However, they were insufficient for our purposes. In this section, we describe how we integrated our infrastructure tables into the implementation of these pieces. We also describe some functionality that we have integrated from existing open source tools.
We implemented a new database explorer that is integrated both with the DomainElement table, the QuerySet table and the CachedQuery table. It uses the DomainElement table to drive the hierarchy of elements displayed as user traverses the domain data in a project. We also use it to display the descriptions entered by the administrator.
We use the QuerySet table to hold the automatically generated query sets that summarize the number of rows in each table and the range of values for each field. These automatic query sets belong to a special user, the system user, denoted by a special userID. These queries are readable by all other users but are not modifiable.
Finally, we use the CachedQueries table to store the results of these automated queries. Users can then browse these results to get an general feel for the data without issuing long running queries to determine the average value in a field or a histogram of the most common values in a field. If a domain table is modified, the system can either rerun all automated queried that reference that table or it can wait to run them on a regular schedule or in idle time if the cached results are still relatively accurate.
Another piece of functionality that exists in other systems is the query builder. We modified our query builder in several ways. First, we found many query builders overly complicated. We decided to build a very easy-to-user builder that supported only simple queries. We decided that if a user need help building more complicated queries that we would help them in another way. Specifically, we provide them with previously issued queries that they can modify in the form of polished query sets.
Implementing our own query builder also allows us to integrate support for finding equivalent queries through matches in our DistinctQueries, searching
18
through the CachedQueries to find cached results and querying the user for their rating of the usefulness of the results they receive.
Finally, we needed to provide some communication links for the users of our system. For this we decided to use the popular phpBB forums. These forums allow for a lot of flexibility and customizability, in terms of administration, general use and look-and-feel. The phpBB forums are also mature and stable software. The choice of this forum software was based on availability and easy integration. Other forms of communication would also be reasonable to integrate if desired.
6 Experience With Prototype
We downloaded the publicly available Border Gateway Protocol (BGP) data that was collected by the Internet Performance Measurement and Analysis (IPMA) project [IPM01]. In the following sections, we describe where the data comes from, what the data means, and how we transformed the data into something that could be stored efficiently in a relational database. Further, we discuss the BGP domain-specific tables and how they interact with the collaborative data explorer. Finally, we show how some of the different classes of users interact with this data.
6.1 Border Gateway Protocol Data
The IPMA project collected the BGP messages sent between peer routers from several Internet Exchange Points (IXP) located across the United States from January of 1999 to December of 2002. We downloaded the data from that project and have imported it into SQL databases. The raw gzipped BGP data is about 16 gigabytes of data. Once it has been extracted, transformed, and imported into SQL databases, its size is about 170 gigabytes. Information about the exchange points is listed in Table 4.1. The Ameritech Advanced Data Services (AADS) exchange point is located in Chicago, IL. MCI’s Metropolitan Area Exchanges (MAE) East and West are located in Washington, D.C. and Silicon Valley, CA respectively. The Palo Alto Internet Exchange (PAIX) is located in Palo Alto, CA. The SBC’s Pacific Bell (PB) Internet exchange is located in San Francisco Bay area, CA. The largest amount of raw data was collected from MAE-East followed by MAE-West, PB, AADS, and PAIX.
6.2 Transforming the Data
Note that even if data is not originally stored in a relational database, it is often possible to convert that data into a format suitable to be imported into a relational database. We did this with some Border Gateway Protocol (BGP) data for our prototype.
The raw data that we downloaded is in a binary format that had to be parsed by a tool called route_btoa, which is part of the Muti-threaded Routing Toolkit
19
(MRT) developed by the Merit project at the University of Michigan. [MRT04] [MER04]. An example of the human readable format produced by route_btoa can be seen in Figure 4.1(a). This particular message, in the figure below, was collected from the MAE-East exchange point and was a message sent on October 5th 1998 at 11:01pm. It was sent from a peer router with the IP address 144.228.107.1 in the Autonomous System numbered 1239 to another peer router with the IP address 192.41.177.169 in the Autonomous System numbered 2885. The message is a withdrawal message since it withdraws Internet prefixes that are no longer available. Specifically, these prefixes are 192.195.250.0/24, 193.40.0.0/24, 193.40.1.0/24, 193.40.2.0/24, 193.40.5.0/24 … etc as seen in the figure. The format of the output is easy to read for a human, but not fast to parse by a computer program. Fortunately, the route_btoa tool supports a –m flag that outputs the data into a machine readable format shown in Figure 4.1(b). In this format it is easy for a computer program to parse into the different pieces. It is also easier to break apart the various prefixes that are withdrawn. The format is: Protocol | Time | Type | PeerIP | PeerAS | Prefix |
Once we understood the data that was output by the command route_btoa –m, we wrote a script to parse the data and import it into an SQL database. The tables used to store it are described in section 4.3.
6.3 Loaded DB stats
Table 1 shows the size of the raw data that was collected and the size it takes in the database.
Table 1: Raw data sizes and size in database
Domain Size Characterize Size Time to cache
1.3GB 5.5KB 15.9 hours
20
Web-Based Collaborative Exploration and Characterization of Large Databases
21
For one of the databases in our domain-specific data (BGP Data) we were able to characterize 1.3 GB of data and store the characterization results in 5.5KB of cache files. This give us histograms, and minimum and maximum values as shown in the screenshot in the appendix (Section 12).
7. Related Work
In this chapter we discuss related work. There are several areas of work that related to collaborative exploration and characterization of large data sets. These include data exploration, collaborative systems, recommender systems, information retrieval, and community and collaborative filtering systems. In the following sections, we discuss the most relevant, collaborative information retrieval and data exploration, in more detail. Twidale and Nichols designed an application, Adriane, to support collaborative information retrieval [TN98]. Their project focuses on visualization of the search process and collaborative browsing. Most of their work has dealt with using library resources. They also realized that this activity is typically a solitary one and that these systems fail to support the process of learning how to locate information and the sharing of information. Chau et. al. [CZ+02] developed a multi-agent collaborative web mining system. Their system was designed for web searches in which users can annotate their sessions for use by future users. They found that for the application of web searches, the search productivity of users only increased when there were enough previous sessions for them to see. A number of online sites allow data exploration including online libraries and encyclopedias, e-commerce and multimedia sites, and search engines and portals. Database content and use can be seen across all disciplines, from geological sampling to business data mining. Many of the web interfaces to these databases allow some collaboration between end users. A prime example of user-database interaction is when customers search for products or information on sites such as https://www.doczj.com/doc/3b1728660.html,, https://www.doczj.com/doc/3b1728660.html,, https://www.doczj.com/doc/3b1728660.html, and https://www.doczj.com/doc/3b1728660.html,. However, these sites do not allow users a high degree of interaction with other users that are seeking or researching a specific topic or product. This type of interaction is characteristic of recommender systems. Data exploration in general has been aided by advances in parallel and distributed computing technologies. In particular, grid computing has been embraced as the platform for the creation, processing and management of petabytes of high-energy physics data [LF04]. In [BAK99], S. Bakin points out that the shear size and complexity of large data sets can be the limiting factor that does not allow for practical analysis of the data. For large and complex data sets, it can be difficult to find useful information in a timely manner. Szalay et al. discussed the Sloan Digital Sky Survey (SDSS) in which they seek to mine multi-terabyte astronomy data. Their system is collaborative in the sense that data is collected across the world and the calculation and results are done in a distributed manner.
Name of Book or Article
22
9. Conclusion
We have presented a generic system for collaborative exploration of large SQL databases. Our system allows system resource to be used more efficiently. Specifically, the query cache avoids long running queries by caching the results of previously executed queries according to a formula that takes into account the user’s own rating of the query, the running time of the query and size of the result. It compares the value of caching new results against the value of existing results which also take into account the number of times the cached results have been viewed, the average user rating of the results and how accurate the cached result is. Our system also allows users to learn from each others queries. It helps users transition from new to expert user. It provides a series of automatically cached queries that allow new users to get a quick overview of the type of data housed in the database. It also allows new users to learn from expert users through polished query sets. This also benefits expert users by reducing the system resources consumed by new user queries that are more likely to be incorrect without assistance. Finally, it enables users to learn by modifying the queries of others. This allows users to focus on the novel aspects of their queries rather than the logistical details. The contributions of this project are the design of a collaborative system in which users can work together to explore and characterize an SQL database, an interface for cached queries and their results, a user-driven query cache, and a prototype system that begins to test the usefulness of such a system. Our system is not customized to the data being explored and can be used with any set of domain specific tables. We note that the benefits of collaboration are multi-faceted. Collaboration can help free up system resources by reducing the number of duplicate and incorrect queries. It helps users free up “mental” resources by also allowing users to focus on the novel aspects of their query rather the logistical details. For both these reasons, our collaborative data exploration system can help users understand large, complex data sets more effectively.
Bibliography
[AH01] A. Halevy. Answering queries using views: A survey. The VLDB Journal — The International Journal on Very Large Data Bases , Volume 10 , Issue 4, pp. 270 - 294 , December 2001. [BAK99] Bakin, S. Adaptive regression and model selection in data mining problems. PhD thesis. Australian National University. 1999. [CZ+02] Chau, M. and D. Zeng, H. Chen, M. Huang, D. Hendriawan. Design and evaluation of a multi-agent collaborative web mining system. Decision Support Systems 2002.
红外温度传感器（BM43系列）应用指南 Application Note for BM43 series 编号BM-SOP-T023 版本V1.0 发布日期2016.8.20 生效日期2016.8.20 1 目的 为更好的解答客户在BM43系列产品在设计和应用中遇到的问题，将之前客户反馈的问题整理解答，以便参照。 2 范围 适用于本公司红外温度传感器系列产品（BM43THA/BM43THD/BM43TNA/BM43TND）以及以BM43系列产品为主要测温单元生产的各种可穿戴式/手持式测温仪器的应用。 3 主要问题及应用指南 3.1. 基本使用 3.1.1 如何使用BM43系列产品测量人体温度 正常人体体温不是一个具体的温度点，而是一个温度范围。机体深部的体温较为恒定和均匀，称深部体温；而体表的温度受多种因素影响，变化和差异较大，称表层温度。临床上所指的体温是指平均深部温度。一般以口腔、直肠和腋窝的体温为代表，其中直肠体温最接近深部体温。正常值：口腔舌下温度为37℃（范围36.3－37.2℃），直肠温度37.5℃（比口腔温度高（0.3-0.5℃），腋下温度为36.5℃（范围 36.0℃-37.0℃）。 使用BM43系列产品测量人体体温时，额温枪建议测量位置为人体额头太阳穴动脉附近，这里的动脉血所辐射出的温度接近人体核心温度；耳温枪建议测量位置为耳道内部，枪头越深入越好，但不要造成不舒服，测儿童时最好将耳朵轻往后上方拉（将耳道拉直）。 3.1.2 穿戴设备戴在手腕上监测手腕皮肤温度的作用 穿戴设备戴在手腕上监测手腕皮肤温度不能代表人体核心温度，原因一：手腕皮肤表面的温度在医学上不能代表人体核心温度，四肢不是医学上认可的测温点；二，通过大数据分析，手腕的温度变化受外界环境影响较大，长时间监测显示温度为非线性变化。 但该测量温度可以作为一项生命体征数据，长时间监控体表温度的变化，超出设定温度的阈值则发出提醒信号。 3.1.3 如果靠近皮肤，每5s检测一次，连续24小时,会不会有问题？时间长了会不会因信号累计出现不准？如果放在腋下长时间使用有没问题？需要注意什么问题？ 如果突然从低温发热源（冰）靠近高温发热源（火），会对传感器增加一个突发热源(骤热) ，会短时间内造成传感器热休克。这种情况与耳温枪类似，耳温枪的解决办法是在传感器外加上金属热阻，以缓冲热休克现象对测温造成不准的影响；另外一种方法是软件上指令ASIC忽略最开始的50-100个数据(大概
红外温度传感器|本质安全型红外测温传感器|GWH400型本安型 红外测温传感器 一、概述 1、产品特点及用途： GWH400本质安全型红外温度传感器（以下简称传感器）是一种非接触式高精度红外测温传感器，可就地显示，远距离信号传输，超限报警等功能，具有体积小、重量轻、测量精度高、防尘、防潮、使用安装方便等特点。 传感器主要用于存在可燃性气体混合物的易燃、易爆工作环境中与监控系统连接进行在线温度监测，可广泛应用于煤炭、石油、化工、铁路、医疗、电力、纺织等行业快速非接触测量物体表面的温度，以达到温度控制或设备安全检测的目的。 2、产品执行标准：Q/SD 005-2006《GWH400本质安全型红外温度传感器》 二、工作原理 传感器由光学系统、红外传感器、信号放大器及信号处理、显示等部分组成。光学系统汇聚 其视场内的目标红外辐射能量，红外能量聚焦在红外传感器上并转变为相应的电信号，通过 信号放大和调理电路放大并进行模拟/数字转换后，由8位单片机组成的中央处理器进行线 形化数据处理及辐射系数补偿，最后转换为被测目标的温度值由LED数码管显示，并将（0～400）℃转换成（200～1000）Hz频率信号输出。 传感器发出的点式激光仅用于瞄准被测目标。 三、主要技术参数 地址：西安市经济技术开发区草滩生态产业园尚苑路3699号 联系人：苏女士 固话：-859
手机： QQ:09 邮编：710018 传真： 免费电话：400-6260611 网址: 本公司主要产销： 仪器仪表： CD4型便携式多参数测定器，CJR100/5H型红外甲烷二氧化碳测定器，CYH25型氧气测定器，CLH100型硫化氢测定器，CJYB4/25型甲烷氧气两参数测定器，CJT4/1000,CTH1000C型一氧化碳测定器，JCB4(A)型甲烷检测报警仪，光干涉式甲烷测定器，气体检测器，气体采样器，皮托管，压差计，通风多参数检测仪，电子风表，粉尘采样器，测尘仪，激光指向仪，激光测距仪，红外测温仪，传感器，隔爆型摄像仪，信号灯，甲烷断电仪，稳压电源，变压器，充电架等。救护设备： 过滤式自救器，隔绝式化学氧自救器，隔绝式压缩氧自救器，矿井供水施救装置，矿井压风自救装置煤矿用自动苏生器，矿用可视化监测通信装置，隔绝式正压氧呼吸器，正压式消防空气呼吸器等。 防爆照明： LED矿灯，多功能矿灯，出口型LED矿灯，隔爆型LED巷道灯，LED矿灯充电器 检测装置： 发爆器参数测试仪，气体检测仪检定装置，自救器正压气密校验装置，自救器负压气密校验装置，矿用气体传感器检定装置，水柱式光瓦校
常用温度传感器解析，温度传感器的原理、分类及应用 温度传感器（temperature transducer）是指能感受温度并转换成可用输出信号的传感器。温度传感器是温度测量仪表的核心部分，品种繁多。按测量方式可分为接触式和非接触式两大类，按照传感器材料及电子元件特性分为热电阻和热电偶两类。 温度传感器的分类接触式 接触式温度传感器的检测部分与被测对象有良好的接触，又称温度计。 温度计通过传导或对流达到热平衡，从而使温度计的示值能直接表示被测对象的温度。一般测量精度较高。在一定的测温范围内，温度计也可测量物体内部的温度分布。但对于运动体、小目标或热容量很小的对象则会产生较大的测量误差，常用的温度计有双金属温度计、玻璃液体温度计、压力式温度计、电阻温度计、热敏电阻和温差电偶等。它们广泛应用于工业、农业、商业等部门。在日常生活中人们也常常使用这些温度计。 随着低温技术在国防工程、空间技术、冶金、电子、食品、医药和石油化工等部门的广泛应用和超导技术的研究，测量120K以下温度的低温温度计得到了发展，如低温气体温度计、蒸汽压温度计、声学温度计、顺磁盐温度计、量子温度计、低温热电阻和低温温差电偶等。低温温度计要求感温元件体积小、准确度高、复现性和稳定性好。利用多孔高硅氧玻璃渗碳烧结而成的渗碳玻璃热电阻就是低温温度计的一种感温元件，可用于测量 1.6～300K范围内的温度。 非接触式 它的敏感元件与被测对象互不接触，又称非接触式测温仪表。这种仪表可用来测量运动物体、小目标和热容量小或温度变化迅速（瞬变）对象的表面温度，也可用于测量温度场的温度分布。 最常用的非接触式测温仪表基于黑体辐射的基本定律，称为辐射测温仪表。辐射测温法包括亮度法（见光学高温计）、辐射法（见辐射高温计）和比色法（见比色温度计）。各类辐
深圳永盟电子邬先生 152.2017.9727 The OTP-668D2 is a thermopile sensor in classic TO-46 housing. The sensor is composed of 116 elements of thermocouple in series on a floating micro-membrane having an active area of diameter 700 μm. The thermopile sensor provides nearly Johnson-noise-limited performance, which can be calculated by its ohmic series resistance. A thermistor with a lead connected to ground is also provided inside the TO package for ambient temperature reference. TO-46 metal housing with IR absorber coating inside Thermistor reference included Low temperature coefficient of sensitivity Ideally suited for ear thermometers, miniature pyrometer. Thermopile Sensor OTP-668D2 Revision Date: 2010/10/14
毕业设计外文文献翻译 毕业设计题目温室大棚测控系统设计翻译题目智能红外温度传感器专业测控技术与仪器 姓名 班级 学号 指导教师 机械与材料工程学院 二〇一一年十月
智能红外温度传感器 跟上不断发展的工艺技术对工艺工程师来说是一向重大挑战。再加上为了保持目前迅速变化的监测和控制方法的过程的要求，所以这项任务已变得相当迫切。然而，红外温度传感器制造商正在为用户提供所需的工具来应付这些挑战：最新的计算机相关的硬件、软件和通信设备，以及最先进的数字电路。其中最主要的工具，不过是新一代的红外温度计---智能传感器。 今天新的智能红外传感器代表了两个迅速发展的结合了红外测温和通常与计算机联系在一起的高速数字技术的科学联盟。这些文书被称为智能传感器，因为他们把微处理器作为编程的双向收发器。传感器之间的串行通信的生产车间和计算机控制室。而且因为电路体积小，传感器因此更小，简化了在紧张或尴尬地区的安装。智能传感器集成到新的或现有的过程控制系统，从一个新的先进水平，在温度监测和控制方面为过程控制方面的工程师提供了一个直接的好处。 1.集成智能传感器到过程线 同时广泛推行的智能红外传感器是新的，红外测温已成功地应用于过程监测和控制几十年了。在过去，如果工艺工程师需要改变传感器的设置，它们将不得不关闭或者删除线传感器或尝试手动重置到位。当然也可能导致路线的延误，在某些情况下，是十分危险的。升级传感器通常需要购买一个新单位，校准它的进程，并且在生产线停滞的时候安装它。例如，某些传感器的镀锌铁丝厂用了安装了大桶的熔融铅、锌、和/或盐酸并且可以毫不费力的从狭窄小道流出来。从安全利益考虑，生产线将不得不关闭，并且至少在降温24小时之前改变和升级传感器。 今天，工艺工程师可以远程配置、监测、处理、升级和维护其红外温度传感器。带有双向RS - 485接口或RS - 232通信功能的智能模型简化了融入过程控制系统的过程。一旦传感器被安装在生产线，工程师就可以根据其所有参数来适应不断变化的条件，一切都只是从控制室中的个人电脑。举例来说，如果环境温度的波动，或程序本身经历类型、厚度、或温度的改变，所有过程工程师需要做的是定制或恢复保存在计算机终端的设置。如果智能传感器由于高温度环境、电缆断裂或者未能组成部分而失败了，其故障进行自动修复。该传感器激活触发报警停机，防止损坏产品和机械。如果烤炉或冷却器失败了，音响和LO警报信号还可以指出哪里有问题并且关闭生产线。 1.1 延长传感器的使用寿命 为了使智能传感器符合数千种不同类型的进程，就必须完全自己定义。由于智能传感器包含只读（可擦除可编程只读存储器），用户可以重新编程以满足他们各自的具体程序要求
红外温度传感器在工业中的应用 随着工业生产的发展，温度测量与控制十分重要，温度参数的准确测量对输出品质、生产效率和安全可靠的运行至关重要。目前，在热处理及热加工中已逐渐开始采用先进的红外温度计等非传统测温传感器，来代替传统的热电偶、热电阻类的热电式温度传感器，从而实现生产过程或者重要设备的温度监视和控制。 基本原理 温度传感器基本原理，最常用的非接触式温度传感器基于黑体辐射的基本定律，称为辐射测温仪表。辐射测温法包括亮度法（见光学高温计）、辐射法（见辐射高温计）和比色法（见比色温度计）。各类辐射测温方法只能测出对应的光度温度、辐射温度或比色温度。只有对黑体（吸收全部辐射并不反射光的物体）所测温度才是真实温度。如欲测定物体的真实温度，则必须进行材料表面发射率的修正。而材料表面发射率不仅取决于温度和波长，而且还与表面状态、涂膜和微观组织等有关，因此很难精确测量。在自动化生产中往往需要利用辐射测温法来测量或控制某些物体的表面温度，如冶金中的钢带轧制温度、轧辊温度、锻件温度和各种熔融金属在冶炼炉或坩埚中的温度。在这些具体情况下，物体表面发射率的测量是相当困难的。对于固体表面温度自动测量和控制，可以采用附加的反射镜使与被测表面一起组成黑体空腔。附加辐射的影响能提高被测表面的有效辐射和有效发射系数。利用有效发射系数通过仪表对实测温度进行相应的修正，最终可得到被测表面的真实温度。最为典型的附加反射镜是半球反射镜。球中心附近被测表面的漫射辐射能受半球镜反射回到表面而形成附加辐射，从而提高有效发射系数式中ε为材料表面发射率，ρ为反射镜的反射率。至于气体和液体介质真实温度的辐射测量，则可以用插入耐热材料管至一定深度以形成黑体空腔的方法。通过计算求出与介质达到热平衡后的圆筒空腔的有效发射系数。在自动测量和控制中就可以用此值对所测腔底温度（即介质温度）进行修正而得到介质的真实温度。 在水泥制造生产中的应用 红外温度传感器在水泥制造生产中有着广泛的应用。据调查目前我国每年因红窑事故造成的直接经济损失达2000万元，间接损失达3亿元。用常规的方法很难对非匀速旋转的水泥胴体进行测温，国际上先进的办法是在窑尾预热平台上安装一套红外扫描测温仪，系统的软件部分主要由数据采集滤波、同步扫描控制、数据通讯处理等，红外辐射测温仪按预定的扫描方式，实现对窑胴体轴向每一个测量段成的温度的测量，在一个扫描周期内，红外温度传感器将在扫描装置的驱动下，将每一个测量元表面的红外辐射转换成温度相关的电信号，送进数据采集装置作为数据采集，同步装置保证数据采集与回转窑的旋转保持严格同步，要让测量的温度值与测量元下确对应，测温仪由扫描起点扫描到终点后，即对窑胴体表面各测量元完成了一次逐元温度检测后，立即快速返回扫描起点，开始下一扫描周期的检测，数据经微机处理后，给出反映窑内状况的图像，文字信息，必要时可以发射声光报警。为保证测量的精度，定要考虑物体的发射率，周围环境影响。红外测温仪要垂直对准窑胴体的表面，因因水汽，尘埃，烟雾的影响，要采取加装水冷，风吹扫装置。意义：1.生产过程中对产品的质量监控与监视，只要温度控制在设定值内，产品质量会有保证，过低过高都浪费能源；2.在线安全的检测可以起到保护人以及设备安全；3.降低能耗，节约能源。 在热处理行业中的应用 红外温度传感器可以广泛的应用于钢铁生产过程中，对生产过程的温度进行监控，对于提高生产率和产品质量至重要。红外温度传感器可精确地监视每个阶段，使钢材在整个加工过程中保持正确的冶金性能。红外温度传感器可以帮助钢铁生产过程中提高产品质量和生产率、降低能耗、增强人员安全、减少停机时间等。 红外温度传感器在钢铁加工和制造过程中主要应用在连铸、热风炉、热轧、冷轧、棒材和线材轧制等过程中。 红外温度传感器传感头有数字和模拟输出两种，发射率可调。—这对于发射率变化金属材料尤其重要。要生产出优质的产品和提高生产率，在炼钢的全过程中，精确测温是关键。连铸将钢水变为扁坯、板坯或方坯时，有可能出现减产或停机，需精确的实时温度监测，配以水嘴和流量的调节，以提供合适的冷却，从而确保钢坯所要求的冶
Introduction The OTP-538U is a thermopile sensor in classic TO-46 housing. The sensor is composed of 116 elements of thermocouple in series on a floating micro-membrane having an active diameter of 545 μm and with blacken surface to absorb the incident thermal infrared radiation, which induces a voltage response at output terminals. The sensor chip is fabricated by a unique front-surface bulk micromachining technology, which result in smaller size and faster to response ambient temperature change.The IR window is a bandpass filter having its 50% cut-on wavelength at 5 μm, and cut -down at 14μm. The sensor responses proportionally to the incident IR radiation and has a constant signal response up to its cut-off frequency, which is limited by the sensor thermal time constant of tens millisecond range.The OTP-538U thermopile sensor provides nearly Johnson-noise-limited performance, which can be calculated by its ohmic series resistance. A thermistor element, with a lead connected to ground, is also provided inside the TO package for ambient temperature reference . Features Non-contact temperature detection Voltage output, easy to take signal Zero power consumption Wide detection temperature range Applications Medical Application: Ear thermometers Home Facility: Microwave oven, Hair dryer, Safety system, Home security, Refrigerator & Air conditioner Industry Application: Process monitor and controller, Infrared non-contact thermometers Automobile Application: Thermal sensing system Table of Contents 1 General Characteristics 1.1 Absolute Maximum Ratings 1.2 Handling Guidelines 2 Device Characteristics 2.1 Device Descriptions 2.2 Sensor Characteristics 2.3 Signal Output Characteristics 2.4 Frequency Response 2.5 Thermistor Characteristics 2.6 Optical Characteristics 2.7 Filter Characteristics 2.8 Mechanic Drawing and Pin Assignment 3 Liability Statement Thermopile Sensor OTP-538U Revision Date: 2009/04/16
温度是一个基本的物理量，自然界中的一切过程无不与温度密切相关。温度传感器是最早开发，应用最广的一类传感器。温度传感器的市场份额大大超过了其他的传感器。从17世纪初人们开始利用温度进行测量。在半导体技术的支持下，本世纪相继开发了半导体热电偶传感器、PN结温度传感器和IC集成温度传感器等接触式温度传感器。与之相应，根据波与物质的相互作用规律，相继开发了声学温度传感器、红外传感器和微波传感器等非接触式温度传感器。 一、接触式温度传感器的检测部分与被测对象有良好的接触，又称温度计。 温度计通过传导或对流达到热平衡，从而使温度计的示值能直接表示被测对象的温度。一般测量精度较高。在一定的测温范围内，温度计也可测量物体内部的温度分布。但对于运动体、小目标或热容量很小的对象则会产生较大的测量误差。 它们广泛应用于工业、农业、商业等部门。在日常生活中人们也常常使用这些温度计。随着低温技术在国防工程、空间技术、冶金、电子、食品、医药和石油化工等部门的广泛应用和超导技术的研究，测量-153℃以下温度的低温温度计得到了发展，如低温气体温度计、蒸汽压温度计、声学温度计、顺磁盐温度计、量子温度计、低温热电阻和低温温差电偶等。低温温度计要求感温元件体积小、准确度高、复现性和稳定性好。利用多孔高硅氧玻璃渗碳烧结而成的渗碳玻璃热电阻就是低温温度计的一种感温元件，可用于测量-271.4℃～27℃范围内的温度。 温度计常用的有： 1、热电阻 根据电阻的温度效应而制，有随温度升高而变大的是正温度系数，也有随温度升高而减小的是负温度系数，使用时取其分压放大后AD转换即可。 热电阻是中低温区最常用的一种温度检测器。它的主要特点是测量精度高，性能稳定。其中铂热电阻的测量精确度是最高的，它不仅广泛应用于工业测温，而且被制成标准的基准仪。 （1）热电阻测温原理及材料 热电阻测温是基于金属导体的电阻值随温度的增加而增加这一特性来进行温度测量的。热电阻大都由纯金属材料制成，目前应用最多的是铂和铜，此外，现在已开始采用甸、镍、锰和铑等材料制造热电阻。各种热电阻的测量范围和优缺点： PT100/ PT1000型热电阻：铂电阻，温度范围-200～850℃。PT100（或PT1000）即0度时阻值为100欧姆（或1000欧姆），根据测量的精度选择。金属铂材料的优点是化学稳定性好、能耐高温，容易制得纯铂，又因其电阻率大，可用较少材料制成电阻，此外其测温范围大。它的缺点是：在还原介质中，特别是在高温下很容易被从氧化物中还原出来的蒸汽所沾污，使铂丝变脆，并改变电阻与温度之间的关系。 CU50型热电阻：铜电阻，温度范围-50～150℃。铜热电阻的价格便宜，线件度好，工业上在-50～+150℃范围内使用较多。铜热电阻怕潮湿，易被腐蚀，熔点亦低。 （2）热电阻的结构 精通型热电阻：从热电阻的测温原理可知，被测温度的变化是直接通过热电阻阻值的变化来测量的，因此，热电阻体的引出线等各种导线电阻的变化会给温度测量带来影响。为消除引线电阻的影响同般采用三线制或四线制。 铠装热电阻：由感温元件（电阻体）、引线、绝缘材料、不锈钢套管组合而成的坚实体，它的外径一般为φ2~φ8mm，最小可达φmm。与普通型热电阻相比，它有下列优点：①体积小，内部无空气隙，热惯性上，测量滞后小；②机械性能好、耐振，抗冲击；③能弯曲，便于安装④使用寿命长。 端面热电阻：感温元件由特殊处理的电阻丝材绕制，紧贴在温度计端面。它与一般轴向热电阻相比，能更正确和快速地反映被测端面的实际温度，适用于测量轴瓦和其他机件的端面温度。 隔爆型热电阻：通过特殊结构的接线盒，把其外壳内部爆炸性混合气体因受到火花或电弧等影响而发生的爆炸局限在接线盒内，生产现场不会引超爆炸。隔爆型热电阻可用于Bla~B3c级区内具有爆炸危险场所的温度测量。 （3）热电阻测温系统的组成
IRTP-300L 红外温度传感器 说 明 书 中文使用手册 1 介绍 感谢您选择IRTP-300L 系列温度传感器。 红外温度传感器可以不接触目标而通过测量目标发射的红外辐射强度计算出物体的表面温度。非接触测温是红外测温仪最大的优点，使用户可以方便地测量难以接近或移动的目标。 IRTP-300L 系列温度传感器为一体化集成式红外温度传感 器，传感器、光学系统与电子线路共同集成在不锈钢壳体内； IRTP-300L 系列易于安装，金属壳体上的标准螺纹可与安装部位快速连接；同时IRTP-300L 系列还有各型选件（例如吹扫器、 安装支架、可调安装支架、吹扫保护套等）以满足各种工况场合要求。 2 参数描述 a ． 基本性能 保护等级 IP65 (NEMA-4) 环境温度 0 ~60°C 存储温度 -20 ~ 80°C 相对湿度 10 – 95%（不结露） 材料 不锈钢 电缆长度 1.5 m (标准) , 其它特殊规格（定制） b ． 电气参数 工作电源 24 VDC 最大电流 50mA 输出信号 0-5V 电压 c ．测量参数 光谱范围 8 ~ 14 μm 温度范围 0 ~300°C 光学分辨率 20:1 响应时间 50 ms (95%) 测温精度 测量值的±1%或±0.5℃，取大值 重复精度 测量值的±0.5%或±1℃，取大值 尺寸 108mm ×ф18mm(长度*直径) 发射率 0.95固定 d. 光路图 3 工作原理及注意事项 a ． 红外测温原理 任何物体都向外辐射红外能量，辐射强度随着温度的变化而变化。红外测温仪一般使用波长在0.8μm －18μm 范围内的红外辐射能量。 红外温度传感器是一种光电子传感器，它接收红外辐射并将其转化成电信号，经电子线路放大器、线性化、信号处理，显示 或输出温度。 b ．被测量点的最大距离和尺寸。 被测目标的尺寸和红外测温仪的光学特性决定了被测目标和测量头之间的最大距离。为了避免测量误差，被测目标应尽量充满探测头的视场。因此，应保持被测点始终小于被测物体或至少与被测目标相同尺寸。 c. 环境温度 IRTP300L 系列红外温度传感器可以在环境温度0－60℃范围 内工作。否则，请选用冷却保护套。 d. 镜头清洁 仪器的镜头必须保持清洁，避免因粘有灰尘、烟尘等污染物而导致测量误差甚至损坏镜头，若镜头粘有灰尘，可用擦镜纸蘸无水酒精擦拭。 e. 电磁干扰 为了防止电磁方面的干扰，请保证以下 措施： 请在安装时尽量使红外温度传感器远离电磁场源（比如电动机、马达、大功率电缆等），如有必要可加金属套管。 4 安装 a 机械安装 IRTP-300L 系列金属壳体带M18×1螺纹，可用于直接安 装，也可通过使用安装支架进行安装，可调安装支架能够使测量头的调节更加方便。 在调整被测目标与测量头时必须确保光路无遮挡。
红外温度传感器的选用原则 1、确定测温范围 红外温度测量范围是零下几十度到+3000℃以上, 如此宽的温度测量范围不能由一种红外温度传感器来完成, 每种型号的测温仪都有自己特定的测温范围。一般来说, 测温范围越窄, 监控温度的输出信号分辨率越高, 精度可靠性容易解决。测温范围过宽, 会降低测温精度。因此, 测量范围也是红外温度传感器选型原则之一。在温度传感器设计选型时要根据现场实际测温要求进行, 测量范围既不要过窄又不要过宽。 2、目标尺寸和距离系数的确定 距离系数的确定, 距离系数由D: S 之比确定, 即红外温度传感探头到目标之间的距离D与被测目标直径之比, 如下图所示。红外温度传感器D: S 的范围一般从2: 1 ( 低距离系数) 到高于300: 1( 高距离系数) 。如果传感器远离目标, 而目标又小, 就应选择高距离系数的传感器。 红外探头与被测物体的距离根据图中的D:S 的比例关系确定,D 为探头与被测物体间的距离, S 为标称光光点直径,D: S 值为红外温度传感器性能指标之一。 确定波长范围, 目标材料的发射率和表面特性决定测温仪的光谱相应波长对于高反射率合金材料, 有低的或变化的发射率。在高温区,测量金属材料的最佳波长是近红外, 测低温区选用7- 18μm 为宜, 系统设计选型时选用此波长范围的传感器。
3、红外温度传感器信号处理 温度大于绝对零度( - 273℃) 的物体都向外发射红外线, 如果分析这种红外辐射, 就可以得到这种物体的温度。温度探头就是利用上述红外线的性质, 首先接受被测物体发出的红外线的辐射, 并把这些光能量转变成可以处理的微弱电信号, 然后送到信号放大处理器进行处理。放大后的电信号转换成可以用微处理器处理的电信号, 实现温度数据的采集。利用温度信号和其他控制设备将可以完成某些自动控制功能。
小型低成本非接触式红外线温度传感器／变送器 OMEGA
~ 1000°F) ? 传感器和变送器组合 ? 封装在一个外径(3?4")、长 89 mm (3.5")的不锈钢外壳中 ? 光学视场：6 比 1 ? 固定发射率为 0.95 ? NEMA 4 (IP66)等级的外壳 ? 可提供 4 ~ 20 mA、0 ~ 5 Vdc、0 ~ 10 Vdc，K 型热电偶，10 mV/度模拟信号输出 ? 可实现快速准确的测量
OS136 型号
-18 ~ 202°C (0 ~ 400°F)， OS136-2： 149 ~ 538°C (300 ? 可提供 2 种温度范围： OS136-1：
OMEGA? 小型低成本、高性能红外线传感器／变送器型号 OS136 具有一个外径 19 mm (3?4")、 长 89 mm (3.5")的 NEMA 4 (IP66)防护等级不锈钢外壳。 该小型变送器特别适合需要在难以进入 的密闭空间或恶劣环境中测量温度的应用。OS136 配备一条 1.8 m (6')屏蔽电缆，用于电源和输 出连接。各型号具有工业标准输出，可直接与所有仪表、控制器、数据记录器、记录仪、计算机 板卡和 PLC 进行简单的接口连接。0.95 的固定发射率允许快速简单的测量，无需在安装和使用 时进行任何调节 ?有关 NIST 校准订购信息，请参阅下一页的配件表。 规格: 温度范围： OS136-1： -18 ~ 202°C (0 ~ 400°F) OS136-2： 149 ~ 538°C (300 ~ 1000°F) 精度@22°C (72°F)环境温度： OS136-1： 读数的 3%或 4.4°C (8°F)，以较大者为准 OS136-2： 读数的 3%或 5.5°C (10°F)，以较大者为准，185 ~ 510°C (365 ~ 950°F) 重复性： 读数的 1% 光学视场： 6 比 1（距离比光点直径） 光谱响应： 5 ~ 14 微米 响应时间： 150 毫秒，最终值的 0 ~ 63% 发射率： 固定为 0.95 模拟信号输出： MA： 4 ~ 20 mA V1： 0 ~ 5 Vdc V2： 0 ~ 10 Vdc K： K 型热电偶，补偿 MVC： 10 mV/°C MVF： 10 mV/°F 输出负载要求：
温度传感器 在带式输送机温度保护中，通过温度传感器，对带式输送机的滚筒及轴承或环境温度进行监控。当监视点的温度高于规定值时，系统报警并驱动洒水装置的电磁阀实现超温洒水。由于滚筒和胶带的摩擦作用，当滚筒温度过高时，会使胶带燃着。因此，要监测滚筒温度，当温度达到一定值时报警。温度传感器从使用上可分为接触式和非接触式两大类，接触式目前使用较为广泛，而非接触式测量是通过检测被测物体所发出的红外线，来达到测温的日的。被测对象是一直转动的滚筒表面，接触式温度传感器测量起来误差太大，响应时间太长，温度变化的传递完全依靠空气为介质进行热交换，因而采用接触式测量不适用于设计。 因此，选用了矿用木质安全型AMK1-MID3301非接触式红外温度传感器。此型号温度传感器适合于煤矿井下非接触式测温的要求，为矿井的测温工作作提供了操作自如、工作方便的检测仪器。矿用红外测温仪体积小，重量轻，坚固、耐用，只需对准目标，扣动扳机，不到一秒钟即可读取物体表面温度，无需接触，即可安全测量热的、危险的或难以接触的物体的表面温度。将检测到的红外温度与设定值比较，当温度大于设定值时，则发出报警指令，同时启动洒水阀洒水降温。它具有响应速度快，测量精度高，安装维护简便等特点。 图2.10 AMK1—MID3301 红外温度传感器 （1）主要技术参数
传感器的工作电压：DC 15—28V，工作电流：15mA； 温度测量范围：-32~535℃； 测温精度：小于100℃时，误差不大于±2℃；大于100℃时，误差不大于±2%的读数。(最高可达±1℃或±1%)； 响应时间：不大于500ms； 显示：带背景光的液晶屏显示； 功能：具有高、低温报警，具有最大值/最小值/平均值/差值显示，具有数据存储，具有扳机锁定； 重量和尺寸：320g，20016055mm； 防爆标志：ExibI(+150℃)。 （2）工作原理 红外测温仪测量物体表面温度时，测温仪的光学元件将物体所辐射的能量会聚到红外探测器上，测温仪的电子元件将此信息转换成温度数值，并显示在测温仪的显示屏上。 （3）安装方法 图2.11温度传感器安装图 第2.7节堆煤传感器 在带式输送机堆煤保护中，当机头下堆煤时，安装在相应位置的堆煤传感器于煤接触，煤堆保护立即动作，报警停机。当煤仓内有大煤块塞住煤仓漏口时，
红外温度传感器选型表 CS 系列 CS系列校核工具可以提供黑体源来校核红外温度传感器，同时 也可以校核接触式的传感器。 型号描述 CS171温度范围：+30.0到+200.0度；分辨率0.1度；精度（和精确温 度计相比）±0.1度；发射率：>0.95；工作电压：220V AC19297 CS172温度范围：低于环境温度40度到+75度；分辨率0.1度；精度 （和精确温度计相比）±0.1度；发射率：>0.95；工作电压： 221V AC26657 RT 系列 RT161是精确的参考温度计，探头和携带盒一并提供。型号描述 RT161温度范围：-35.00到+199.99度；分辨率0.01度；精度（和精确 温度计相比）±0.02度±0.01％；探头：±0.03度±0.07％；9VDC 供电11736 EL系列 型号描述 EL21A 温度范围：0到+250度；光学镜头：2：1；发射率：0.95；输出： 4-20mA2725 EL21AWJ 温度范围：0到+250度；光学镜头：2：1；发射率：0.95；输出： 4-20mA；水冷套和空气吹净管5725 EL101A 温度范围：0到+250度；光学镜头：10：1；发射率：0.95；输 出：4-20mA3225 EL101AHT 温度范围：0到500度；光学镜头：10：1；发射率：0.95；输 出：4-20mA3225 EL101AWJ 温度范围：0到+250度；光学镜头：10：1；发射率：0.95；输 出：4-20mA；水冷套和空气吹净管6225 EL101AHTWJ 温度范围：0到500度；光学镜头：10：1；发射率：0.95；输 出：4-20mA；水冷套和空气吹净管6225 EL301A 温度范围：0到+250度；光学镜头：30：1；发射率：0.95；输 出：4-20mA4475 EL301AHT 温度范围：0到500度；光学镜头：30：1；发射率：0.95；输 出：4-20mA4475 EL301AWJ 温度范围：0到+250度；光学镜头：30：1；发射率：0.95；输 出：4-20mA；水冷套和空气吹净管7475
红外线温度传感器和温度传感器的区别 红外线温度传感器 利用红外线的物理性质来进行测量的传感器。红外线又称红外光，它具有反射、折射、散射、干涉、吸收等性质。任何物质，只要它本身具有一定的温度（高于绝对零度），都能辐射红外线。红外线温度传感器测量时不与被测物体直接接触，因而不存在摩擦，并且有灵敏度高，反应快等优点。 红外线温度传感器包括光学系统、检测元件和转换电路。光学系统按结构不同可分为透射式和反射式两类。检测元件按工作原理可分为热敏检测元件和光电检测元件。热敏元件应用最多的是热敏电阻。热敏电阻受到红外线辐射时温度升高，电阻发生变化（这种变化可能是变大也可能是变小，因为热敏电阻可分为正温度系数热敏电阻和负温度系数热敏电阻），通过转换电路变成电信号输出。光电检测元件常用的是光敏元件，通常由硫化铅、硒化铅、砷化铟、砷化锑、碲镉汞三元合金、锗及硅掺杂等材料制成。 温度传感器 一般测量精度较高。在一定的测温范围内，温度计也可测量物体内部的温度分布。但对于运动体、小目标或热容量很小的对象则会产生较大的测量误差，常用的温度计有双金属温度计、玻璃液体温计、压力式温度计、电阻温度计、热敏电阻和温差电偶等。它们广泛应用于工业、农业、商业等部门。在日常生活中人们也常常使用这些温度计。随着低温技术在国防工程、空间技术、冶金、电子、食品、医药和石油化工等部门的广泛应用和超导技术的研究，测量120K以下温度的低温温度计得到了发展，如低温气体温度计、蒸汽压温度计、声学温度计、顺磁盐温度计、量子温度计、低温热电阻和低温温差电偶等。低温温度计要求感温元件体积小、准确度高、复现性和稳定性好。利用多孔高硅氧玻璃渗碳烧结而成的渗碳玻璃热电阻就是低温温度计的一种感温元件，可用于测量1.6～300K范围内的温度。
IRTP-500LS红外温度传感器 说明书 中文使用手册 1介绍 感谢您选择IRTP-500LS系列温度传感器。 红外温度传感器可以不接触目标而通过测量目标发射的红外 辐射强度计算出物体的表面温度。非接触测温是红外测温仪最大的优点，使用户可以方便地测量难以接近或移动的目标。 IRTP-500LS系列温度传感器为一体化集成式红外温度传感器，传感器、光学系统与电子线路共同集成在不锈钢壳体内；IRTP-500LS系列易于安装，金属壳体上的标准螺纹可与安装部位快速连接；同时IRTP-500L系列还有各型选件（例如吹扫器、安装支架、可调安装支架、吹扫保护套等）以满足各种工况场合 要求。 2参数描述 a．基本性能 保护等级IP65 (NEMA-4) 环境温度0 ~60°C 存储温度-20 ~ 80°C 相对湿度10 – 95%（不结露） 材料不锈钢 电缆长度 1.5 m (标准) , 其它特殊规格（定制） b．电气参数 工作电源24 VDC 最大电流50mA 输出信号4-20mA电流 c．测量参数 光谱范围8 ~ 14 μm 温度范围0 ~500°C 光学分辨率20:1 响应时间50 ms (95%) 测温精度测量值的±1%或±0.5℃，取大值 重复精度测量值的±0.5%或±1℃，取大值 尺寸108mm×ф18mm(长度*直径) 发射率0.95固定 d. 光路图3工作原理及注意事项 a．红外测温原理 任何物体都向外辐射红外能量，辐射强度随着温度的变化而变化。红外测温仪一般使用波长在0.8μm－18μm范围内的红外辐射能量。 红外温度传感器是一种光电子传感器，它接收红外辐射并将其转化成电信号，经电子线路放大器、线性化、信号处理，显示或输出温度。 b．被测量点的最大距离和尺寸。 被测目标的尺寸和红外测温仪的光学特性决定了被测目标和测量头之间的最大距离。为了避免测量误差，被测目标应尽量充满探测头的视场。因此，应保持被测点始终小于被测物体或至少与被测目标相同尺寸。 c. 环境温度 IRTP500LS系列红外温度传感器可以在环境温度0－60℃范 围内工作。否则，请选用冷却保护套。 d.镜头清洁 仪器的镜头必须保持清洁，避免因粘有灰尘、烟尘等污染物而导致测量误差甚至损坏镜头，若镜头粘有灰尘，可用擦镜纸蘸 无水酒精擦拭。 e.电磁干扰 为了防止电磁方面的干扰，请保证以下 措施： 请在安装时尽量使红外温度传感器远离电磁场源（比如电 动机、马达、大功率电缆等），如有必要可加金属套管。4安装 a 机械安装 IRTP500LS系列金属壳体带M18×1螺纹，可用于直接安装，也可通过使用安装支架进行安装，可调安装支架能够使测量头的调节更加方便。 在调整被测目标与测量头时必须确保光路无遮挡。 b 电气安装接线 类型线颜色功能 四线制 4～20mA 红色电源正24VDC ＋ 黑色电源负24VDC - 绿色输出信号4-20mA + 黄色输出信号4-20mA - 对于4~20mA的模拟信号输出。为两线制环路电流输出方
摘要 红外线技术发展到现在，已经为大家所熟知，这种技术在现代科技、国防和农业等领域获得广泛的应用。本文介绍以模拟的红外线温度传感器来验证其温度测量精度达10-5℃数量级。微小的温度变化转换成电压变化，经过放大电路进行处理，再由AD转化电路和AT89C51转码，最终经LED数码输出温度的变化值。 关键字：红外线温度传感器；10-5℃数量级
目录 摘要 (Ⅰ) 1 设计目的及要求 (1) 1.1设计目的 (1) 1.2设计要求 (1) 2 总体概要设计 (2) 3 系统硬件电路设计 (3) 3.1 电路设计原理图 (3) 3.2模拟信号电路 (3) 3.3 运算放大电路 (4) 3.4 模数转换电路 (5) 3.5 AT89C51电路 (7) 3.6 LED显示器 (10) 4 软件设计 (11) 4.1 主程序流程设计 (11) 4.2 显示子程序 (11) 4.3 数据转换子程序 (12) 4.4 延时子程序 (13) 5仿真结果与数据处理 (14) 5.1仿真结果示例 (14) 5.2数据处理 (15) 6 课程设计的总结及体会 (16) 参考文献 (17) 附录 1 原理图 (18) 附录2程序源代码 (19) 附录 3 器件清单 (23)
1 设计目及与要求 1.1设计目的 课程设计是在校学生素质教育的重要环节，是理论与实践相结合的桥梁和纽带。电气测量技术课程设计，要求学生更多的完成软硬结合的动手实践方案，解决目前学生课程设计过程中普遍存在的缺乏动手能力的现象. 《电气测量技术课程设计》是继《电子技术》、和《单片机原理与应用》课程之后开出的实践环节课程，其目的和任务是训练学生综合运用已学课程电气测量技术的基本知识，独立进行电气测量的应用技术和开发工作,掌握电气测量技术的应用、调试和电路设计、分析及调试检测。 1.2设计要求 1、掌握测量信号处理的基本原理和设计误差处理的方法。 2、实现传感器的灵敏度为： k＝ΔLT／ΔLV＝9.26×10-5℃/mV。
如何正确选择红外线温度传感器，红外线温度传感器工作原理解析如何选择红外温度传感器，我们需要根据它的一些性能指标来判定，光学分辨率、响应时间、工作波长、温度范围等，环境和工作条件也是重要的考虑因素，随便着红外技术的不断发展，用户的选择也越来越多，下面给大家详细介绍一下： 光学分辨率由D与S之比确定，是传感器到目标之间的距离D与测量光斑直径S之比。如果传感器由于环境条件限制必须安装在远离目标之处，而又要测量小的目标，就应选择高光学分辨率的传感器。光学分辨率越高，即增大D:S比值，测温仪的成本也越高。 二、确定响应时间响应时间表示红外温度传感器对被测温度变化的反应速度，电磁流量计定义为到达最后读数的95%能量所需要时间，它与光电探测器、信号处理电路及显示系统的时间常数有关。新型红外温度传感器响应时间可达1ms。这要比接触式测温方法，快得多。如果目标的运动速度很快或测量快速加热的目标时，要选用快速响应红外温度传感器，否则达不到足够的信号响应，会降低测量精度。然而，并不是所有应用都要求快速响应的红外温度传感器。对于静止的或目标热过程存在热惯性时，测温仪的响应时间就可以放宽要求了。因此，红外温度传感器响应时间的选择要和被测目标的情况相适应。 三、信号处理功能：测量离散过程（如零件生产）和连续过程不同，要求红外温度传感器有信号处理功能（如峰值保持、谷值保持、平均值）。如测温传送带上的玻璃时，就要用峰值保持，其温度的输出信号传送至控制器内。 四、环境条件考虑温度传感器所处的环境条件对测量结果有很大影响，应加以考虑、并适当解决，否则会影响测温精度甚至引起测温仪的损坏。当环境温度过高、存在灰尘、烟雾和蒸汽的条件下，可选用厂商提供的保护套、水冷却、空气冷却系统、空气吹扫器等附件。这些附件可有效地解决环境影响并保护测温仪，实现准确测温。在确定附件时，应尽可能要求标准化服务，以降低安装成本。调查烟雾、灰尘或其他颗粒降低测量能量信号，双色温度传感器是最佳选择。在噪声、电磁场、震动或难以接近环境条件下，或其他恶劣条件下，光纤双色温度传感器是最佳选择。 五、确定测温范围测温范围是传感器最重要的一个性能指标，每种型号的传感器都有自己