当前位置：文档之家› Sensor Bus_An Intermediary Layer for Linking Geosensors and the Sensor Web

Sensor Bus_An Intermediary Layer for Linking Geosensors and the Sensor Web

Sensor Bus:An Intermediary Layer for Linking Geosensors and the Sensor Web

Arne Broering

International Institute for Geo-Information Science and Earth Observation(ITC)

University of T wente

Enschede,Netherlands broering@https://www.doczj.com/doc/ed2672167.html,

Theodor Foerster

Institute for Geoinformatics

(IfGI)

University of Münster

Münster,Germany

theodor.foerster@uni-

muenster.de

Simon Jirka

52?North

Initiative for Geospatial Open

Source Software

Münster,Germany

jirka@https://www.doczj.com/doc/ed2672167.html,

Carsten Priess

Institute for Geoinformatics

University of Münster

Münster,Germany

carsten.priess@uni-

muenster.de

ABSTRACT

In recent years,the standards of OGC’s Sensor Web En-ablement(SWE)initiative have been applied in a multi-tude of projects to encapsulate heterogeneous geosensors for web-based discovery,tasking and access.Currently,SWE services and the di?erent types of geosensors are integrated manually due to a conceptual gap between these two layers. Pair-wise adapters are created to connect an implementa-tion of a particular SWE service with a particular type of geosensor.This approach is contrary to the aim of reaching interoperability and leads to an extensive integration e?ort in large scale systems with various types of geosensors and various SWE service implementations.

To overcome this gap between geosensor networks and the Sensor Web,this work presents an intermediary layer for integrating these two distinct layers seamlessly.This inter-mediary layer is called the Sensor Bus as it is based on the message bus architecture pattern.It reduces the e?ort of connecting a sensor with the SWE services,since only the adaption to the Sensor Bus has to be created.The com-munication infrastructure which acts as the basis for the Sensor Bus is exchangeable.In this work,the Sensor Bus is based on Twitter.The involved SWE services as well as connected geosensors are represented as user pro?les of the Twitter platform.

Categories and Subject Descriptors

H.4[Information Systems Applications]:Communica-tions Applications;D.2[Software Engineering]:Software Architectures

Keywords

Sensor Web,geosensor networks,SWE,Twitter

1.INTRODUCTION

Nowadays,sensors become smaller,cheaper,more reliable, more power e?cient and more intelligent.Geosensors,as kinds of sensors delivering an observation with georeferenced location[33],are increasingly used in various applications ranging from environmental monitoring,precision agricul-ture to early warning systems[29].The sensors utilized in these applications may be stationary or mobile,either on land,water or in the air and could gather data in an in-situ or remote manner.Due to this variety,a coherent infras-tructure has become necessary to integrate heterogeneous sensors in a platform independent and uniform way.The Sensor Web is such an infrastructure for sharing,?nding and accessing sensors and their data across di?erent appli-cations[25].The Sensor Web is to sensors what the World Wide Web(WWW)is to general information sources-an infrastructure allowing users to easily share their sensor re-sources.It hides the underlying layers with the network communication details,and heterogeneous sensor hardware, from the applications built on top of it.

The Sensor Web Enablement(SWE)[5]initiative of the Open Geospatial Consortium(OGC)1standardizes Web Ser-vice interfaces and data encodings for the Sensor Web.In recent years,these SWE standards have demonstrated their practicability and suitability in various projects(e.g.,[10, 27,19,34])and applications(e.g.,[15,1,8,14]).How-ever,due to the missing interoperability between the two layers(geosensor network and Sensor Web),it is currently not possible to dynamically install geosensors on-the-?y with a minimum of human con?guration e?ort,to enable a plug &play of geosensors.

1https://www.doczj.com/doc/ed2672167.html,

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

COM.Geo 2010, June 21-23, 2010 Washington, DC, USA

Dynamically installing geosensors on the Sensor Web in a plug&play manner requires advanced concepts.Gener-ally,the SWE standards focus on interacting with the upper application level.They are designed from an application-oriented perspective.As a result,the interaction between the Sensor Web and the underlying geosensor network layer has not been su?ciently described yet.The Sensor Web is based on the WWW and its related protocols.On the other hand,sensor network technologies are based on lower-level protocols such as Bluetooth2,ZigBee3,the IEEE1451stan-dards family[21]or proprietary protocols.From an appli-cation perspective,the SWE services encapsulate the sensor network and hide these lower-level protocols.Currently,the Sensor Web and geosensor network layer are integrated by manually building proprietary bridges for each pair of Web Service implementation and sensor type.This approach is cumbersome and leads to extensive adaption e?ort.Since the price of sensor devices is decreasing rapidly,the man-ual integration becomes the key cost factor in developing large-scale sensor network systems[3].Concepts are miss-ing which facilitate the connection of the two layers.

After giving an overview of the SWE standards(Section2) and related work(Section3),the concept of an intermediary layer between Sensor Web and geosensor network layer,the Sensor Bus,is described(Section4).In a next step(Section 5)the Sensor Bus is implemented by the example of Twitter followed by an analysis of this implementation(Section6). The paper ends with a conclusion and discussion of future work.

2.SENSOR WEB ENABLEMENT

The OGC is an industry consortium comprising over380 members de?ning interoperable services for the Geospatial Web.The SWE initiative[5]as part of OGC’s speci?ca-tion program develops standards to integrate sensors into the Geospatial Web.In particular,SWE incorporates data models for describing sensors(SensorML[4])as well as gath-ered sensor data(Observations&Measurements[11]).The main Web Service interfaces are the Sensor Observation Ser-vice(SOS),the Sensor Alert Service(SAS),and the Sensor Planning Service(SPS).The SWE standards framework can be used to set up a Sensor Web.

The SOS[24]is designed for accessing real time as well as historic sensor data,and sensor metadata.Its operations allow users to request sensor data based on spatial,tem-poral and thematic?lter criteria.Additionally,the SOS o?ers operations for inserting observations and sensors.Re-quested sensor data are encoded conforming to the Obser-vations&Measurements standard and the sensor metadata are returned as SensorML documents.A complementary approach for accessing sensor data is o?ered by the SAS [31].While the SOS follows the pull-based communication paradigm,the SAS is capable of pushing sensor data to sub-scribers.Subscribers of the SAS de?ne particular alert con-ditions to specify the situations they are interested in and want to receive data accordingly(e.g.,when sensor x mea-sures temperature over30?C).To control and task sensors the SPS[32]can be used.A common application of SPS 2https://www.doczj.com/doc/ed2672167.html,

3https://www.doczj.com/doc/ed2672167.html, is to de?ne simple sensor parameters such as the sampling rate but also to de?ne more complex tasks such as mission planning of satellite systems.Further on,the SPS o?ers a broad range of operations for managing submitted sensor tasks(e.g.,deleting,updating and canceling tasks).

Also,service interfaces for the resource discovery within the Sensor Web have been developed and added to the SWE framework.The Sensor Instance Registry(SIR)and the Sensor Observable Registry(SOR)[20]enable searching for sensors,sensor datasets,or SWE services.

3.RELATED WORK

GeoSWIFT[22]is a three-layered architecture for distributed geospatial information infrastructures to realize the Sensor Web.It advocates the usage of OGC standards to expose sensors and sensor data.Additionally to a standardized Web Service interface for sensor data access,a server component is introduced which integrates and fuses heterogeneous sens-ing sources.However,the design of the integrator compo-nent is not described.

Sgroi et al.[28]developed a set of service interfaces usable as an application programming interface for sensor networks. Similar to the SWE framework of services,the approach fol-lows a top down view on sensor networks independent of a particular implementation or hardware platform.Besides an essential query/command service,auxiliary services such as locationing,timing,and a concept repository are de?ned. By o?ering this functionality the approach focuses on the needs of wireless sensor networks.The SWE framework instead,focuses on serving general functionalities needed by geosensor network applications and is not specialized on wireless sensor networks.

The SOCRADES architecture[12]is designed to couple the Internet of Things infrastructure with a Service Oriented Architecture.The architecture comprises multiple services providing middleware functionality such as device managing, eventing or service discovery.The integration of sensors into the infrastructure is done by implementing sensor gateways which hide the communication protocol and expose the sen-sor functionality as device level Web Services.In contrast to the SWE framework,the operations of individual services are not standardized.

Emerging Sensor Web portals provide central web platforms where people can upload and share sensor data.These por-tals o?er di?erent kinds of visualizations on registered sen-sors and collected data.Examples for such systems are Sen-sorMap and the underlying SenseWeb infrastructure[26], SensorBase[9]as well as Sensorpedia4.Besides mechanisms for integration and registration of sensors and the upload of sensor data,also the discovery of sensors is supported.How-ever,the centralized approach of these platforms di?ers from the decentralized approach of SWE.Also,the approaches do not comprise interfaces for tasking sensors which is in scope of this work.

The Sensor Web Agent Platform(SWAP)[23]combines the paradigms of Web Services and Multi Agent Systems.By 4https://www.doczj.com/doc/ed2672167.html,

building on OGC’s SWE framework,the proposed architec-ture shall improve the integration of arbitrary sensors into work?ows on the application level.This is done by intro-ducing a three tier architecture comprising sensor,knowl-edge and application layer.Di?erent kinds of agents residing on the three layers provide certain functionality and facili-tate the development of new applications.While this work facilitates the integration of sensors with applications,the integration of sensors with the Sensor Web is out of scope. Also an agent based system is IrisNet[17].It uses organiz-ing agents to store sensor data in a hierarchical,distributed database and sensing agents which collect the sensor data. The authors envision a worldwide Sensor Web by focusing on data collection and query answering.The architecture lacks particular mechanisms for an easy integration of new sensors.

Similar to the goal of this work,the Global Sensor Net-work middleware[2]focuses on a?exible integration of sen-sor networks to enable fast deployment and addition of new sensors.Its central concept is the virtual sensor abstrac-tion with XML-based deployment descriptors in combina-tion with data access through plain SQL queries.GSN pro-vides distributed querying,?ltering,and combination of sen-sor data as well as the dynamic adaption of a system during runtime.However,service interfaces for tasking and con-trolling sensors are not provided to the application layer. Similar to the GSN approach is Hourglass[30],which pro-vides an architecture for connecting sensors to applications. It o?ers discovery and dataprocessing services and tries to hide internals of sensors from the user.It focuses on main-taining the quality of service of data streams.

None of the existing solutions address the seamless integra-tion of sensors with standardized Web Service interfaces as de?ned by OGC.Aim of this work is to leverage SWE tech-nology and its bene?ts by facilitating the integration of new sensors into the Sensor Web.Another unique characteristic of the approach presented here is the possibility to adapt the concepts to di?erent communication infrastructures acting as base technology(e.g.,XMPP or JMS).So in future,it might be considered to use existing systems as the basis of the proposed Sensor Bus and reuse their functionality. 4.THE SENSOR BUS ARCHITECTURE

In the following,the concept and architecture of the Sensor Bus,an intermediary layer integrating geosensor networks and the Sensor Web,are described.The architecture can be adapted to di?erent communication infrastructures-an implementation based on Twitter is presented in Section5. Fig.1depicts an overview of the components involved in the Sensor Bus architecture.A client located on the appli-cation layer invokes a SWE service for a speci?c functionality such as the retrieval of sensor observations or the submis-sion of a sensor task.The Sensor Bus maintains associations to these services as well as associations to sensor gateways which supply access to connected sensors.The sensor gate-way establishes the communication between its associated sensors and the upper layer.From a hardware perspective, sensor gateway and sensor may merge in certain scenarios to a single component(e.g.,a weather station which comprises multiple sensors and is equipped with an advanced comput-ing unit acting as the gateway to the associated sensors). Also,it is possible that the gateway gives access to a whole sensor network by acting as a sink

node.

Figure1:Sensor infrastructure stack

We propose that the intermediary layer is externally de-signed as a logical bus-the Sensor Bus(see Fig.2).Aligned with the Message Bus pattern[18],the Sensor Bus incorpo-rates(1)a common communication infrastructure,a shared set of(2)adapter interfaces,and a well-de?ned(3)message protocol.

The common communication infrastructure(1)is established through a publish/subscribe mechanism[16]based on the underlying messaging technology(e.g.,Twitter or XMPP). Services as well as sensors can publish messages to the bus and are also able to subscribe to the bus for receiving mes-sages in a push-based communication style.The underlying messaging technology takes care of forwarding the posted messages to the speci?c subscribed components.The di?er-ent components(i.e.,sensors and SWE services)can sub-scribe and publish through interfaces(2).For these inter-faces,pluggable adapters can be developed by sensor ven-dors or service providers.The adapters convert the service or sensor speci?c communication protocol to the internal bus protocol(3).

Other than physical buses,used for example in computer hardware,the Sensor Bus is a logical bus and re?ects a bus topology to external components(sensors and services). While there is no single instance representing the Sensor Bus,the adapters of those components,together with the underlying messaging technology,form the Sensor Bus.

Figure2:Structure of the Sensor Bus

The interfaces which are used to realize the Sensor Bus are depicted in Fig.3.The SensorAdapter(e.g.,an adapter for the SunSPOT5sensor platform)and the ServiceAdapter (e.g.,adapters for SOS and SPS)are used to connect sensors and services to the Sensor Bus.Both interfaces are BusLis-teners so that they can be noti?ed by the BusMessageRe-ceiver for retrieving messages sent over the bus.Senso-rAdapter and ServiceAdapter transmit their messages to the bus through the BusMessageSender.BusMessageRe-ceiver and BusMessageSender hide from the underlying communication infrastructure of the bus.The TwitterCon-nector in Fig.3is an example implementation of the two interfaces to realize the Sensor Bus based on Twitter6.Since the two interfaces abstract from the communication infras-tructure,it is easy to exchange the implementing class and realize the Sensor Bus based on other messaging technolo-gies(e.g.,instant messaging systems).The implementation of BusMessageReceiver calls in case of an incoming message onMessage()to notify the listeners.The concrete sensor and service adapters,acting as listeners,analyze the incoming message and react on it according to their speci?cations. The interactions between the geosensor network layer,the Sensor Web and the intermediary layer are realized through particular bus messages.A detailed analysis of interaction patterns which emerge when introducing the intermediary layer is conducted in[6].The necessary bus messages are listed in Table1.The message format is compact to preserve bandwidth and system resources.Single message?elds are divided by a separator sign.

The subscription of a service at the Sensor Bus is conducted by a sequence of messages.First,the RegServ message is 5https://www.doczj.com/doc/ed2672167.html,

https://www.doczj.com/doc/ed2672167.html, Figure3:Sensor Bus core components as UML class diagram

called to publish the URL of the service.Subsequently,Sub-Serv messages are sent over the bus to subscribe the service for certain sensors.In future,more advanced subscription parameters are possible.For example,a service could sub-scribe for sensors of a particular geographic region or for sensors observing particular phenomena or features.

The subscription of a service for a particular sensor requires the existence of unique identi?ers for the sensor.Uni?ed Resource Identi?ers(URIs)are therefore used here.The discovery of sensors and the look-up of corresponding URIs can be done through the Sensor Instance Registry(SIR) [20].As a SWE service,the SIR is also registered at the Sensor Bus and is noti?ed when new sensors appear.It is automatically supplied with their metadata and?lls its search indexes so that clients can discover them.

The subscription of a service at the Sensor Bus by the means of the RegServ and SubServ message is only necessary and meaningful if the Sensor Bus or the underlying messaging technology is capable of managing the associations between service and sensor.The realization of the Sensor Bus using Twitter5is light-weight and does not support such func-tionality.Here,the service adapter’knows’in which sensors it is interested and handles incoming messages accordingly. To subscribe a sensor at the Sensor Bus and publish its ex-istence the RegSen message is sent.It comprises the sensor identi?er as well as the URL of the sensor description,a Sen-sorML document.The message is forwarded to the services which are subscribed for the sensor.

For publishing new data the sensor adapter transmits the PubData message via the Sensor Bus containing the time when the data was observed as well as the data itself.Ser-vice adapters receive this message and transform the data into the service speci?c protocol.For example,the message PubData*sunspotA1*2010-03-02T15:52:43*-2is transform-

Table1:Sensor Bus messages.

Interaction Bus Message Protocol

Service Registration 1.RegServ*

2.SubServ**

3.SubServ**

...

Sensor Registration SenReg** Data Publication PubData*** Sensor Tasking 1.PubTask**

2.TaskParam***

3.TaskParam***

...

X.DoTask*

ed by a Sensor Observation Service(SOS)adapter to an InsertObservation request as shown in https://www.doczj.com/doc/ed2672167.html,rma-tion which is not contained in the message itself but neces-sary within the InsertObservation request(e.g.,the unit of measure and the URL of the observed feature)is taken from the sensor description.

The data are then collected and stored by the SOS and henceforth available to clients via the standardized SOS in-terface.It can be accessed and retrieved in a pull-based manner.To provide the data in a push-based way,a Sensor Alert Service can be registered at the Sensor Bus.The SAS receives the incoming data,?lters it by certain prede?ned criteria and directly forwards it to interested clients.

...

2010?03?02T15:52:43

...

x l i n k:h r e f=”http://s e r v e r/s e n s o r s#sunspotA1”/>

x l i n k:h r e f=”urn:ogc:phenomenon:tempera ture”/>

x l i n k:h r e f=”http://s e r v e r/f e a t u r e s#myHouse”/>

x s i:type=”gml:MeasureType”

uom=”urn:ogc:uom:deg”>

Listing1:Example of an SOS InsertObservation re-quest.

The tasking of a sensor is triggered by a client request to a Sensor Planning Service(SPS).A client sends a Submit op-eration request to the SPS to submit a sensor task.An example for such a request is shown in Listing2.The camera’myCam123’is tasked to change its focal length to’22.0’millimeters and to change its looking direction to ’North’.The allowed values for the task parameterization can be requested by the client through an afore invoked DescribeTasking operation request.The service adapter of the SPS transforms the Submit request to a sequence of sensor tasking messages.It starts with a PubTask mes-sage to publish an identi?er for the task and the identi?er

of the sensor(e.g.,’myCam123’)which shall execute the task.In subsequent TaskParam messages the parameters

of the task are transmitted.For example the second pa-rameter of the Submit request of Listing2is transformed

to TaskParam*myCam123_task1*LookingDirection*North. Finally,the task is invoked by sending the DoTask message.

~~myCam123~~

22.0,North

...

Listing2:Example of an SPS Submit request.

The sensor adapter of’myCam123’registered at the Sensor Bus receives the tasking message sequence and translates it

to the concrete sensor protocol(e.g.,through speci?c sensor drivers).Subsequently,it is forwarded to the sensor gateway and eventually to the sensor.

5.IMPLEMENTATION OF THE SENSOR BUS

USING TWITTER

In general,the outlined architecture of the Sensor Bus,as

the intermediary layer,is adaptable to di?erent underlying messaging technologies.We implemented the Sensor Bus in four di?erent ways.These implementations are using Inter-

net Relay Chat(IRC),Extensible Messaging and Presence Protocol(XMPP),Java Message Service(JMS),or Twit-

ter as the underlying messaging technology to establish the publish/subscribe mechanism of the Sensor Bus.In this ar-ticle we present the implementation of the Sensor Bus using Twitter.An extensive evaluation and comparison of all ap-plied technologies is current work in progress.

To plug a sensor into the Sensor Bus a sensor administrator implements an adapter(Section4)for the particular type

of her/his sensor.This adapter has only to be implemented

for each type of sensor once.In this work,we created an adapter for the SunSPOT sensors.

In case of Twitter the services and sensors are available as Twitter pro?les.For the realization of the Sensor Bus,the sensor administrator must create a Twitter pro?le for the sensor since an automatic creation is not possible.The de-scription URL of the sensor’s Twitter pro?le points to its metadata description stored at a web-accessible location so that it can be accessed by services at anytime.The sensor description is a SensorML encoded document containing for example detailed information about the sensor’s geographic location.The sensor adapter is usually deployed on the com-puting unit of the sensor gateway.Here,a SunSPOT,which may act as a network sink to multiple SunSPOTs,is con-nected via USB to a computer with network connection. This computer represents the sensor gateway and hosts the sensor adapter.This adapter is accompanied by a con?g-uration?le containing information about the endpoint of the bus communication infrastructure(e.g.,address,port, or in this case the Twitter account identi?er).Finally,when the sensor adapter is started,it posts a RegSen message to the mirco blog of the sensor’s Twitter pro?le.Subsequently, the sensor forwards its measured data to the sensor gateway which uses the sensor adapter to send the data to the Sensor Bus.The speci?c implementation of the BusMessageSender (Section4)posts these data contained in a DataPub message as a tweet to the micro blog of the sensor.

To attach a service to the Sensor Bus the provider has to implement an adapter7for the service.In this work,we created an exemplary adapter for the Sensor Observation Service.Additionally,the service provider has to create a Twitter account for the service.

The runtime instance of the service adapter and the actual Web Service are usually but not necessarily running on the same machine.After starting the service adapter,it reg-isters the service at the bus.The service adapter is ac-companied by a con?guration?le de?ning the sensors(i.e., the Twitter account IDs of those sensors)for which it shall be subscribed.To establish the publish/subscribe mecha-nism in case of Twitter,the Twitter account of the service is registered as a follower at the sensor’s account and vice versa.Since the Twitter architecture is pull-based,the ser-vice adapters and sensor adapters have to regularly check the micro blogs(available as feeds)of the accounts which they are following.So,if a sensor adapter posts a new Dat-aPub message to its micro blog the service adapters,which are following,get aware of that by checking the senor’s feed, transform the message to the service speci?c protocol and forward it.

6.ANALYSIS OF TWITTER IMPLEMEN-

TATION

Building the Sensor Bus on Twitter enables reusing func-tionality o?ered by the messaging platform.For example, security mechanisms can be easily incorporated in the imple-mented approach,since authentication functionality is pro-vided by Twitter.Also,scalability and reliability of the Sensor Bus is managed by Twitter.

7The mid-term aim is to establish a library of adapters for certain types of sensors as well as services.This will al-low service providers and sensor vendors to reuse existing adapter implementations to plug their components into the bus.However,there are some disadvantages in using Twitter as the communication infrastructure of the Sensor Bus.In gen-eral,the pull-based design of Twitter does not allow a true push-based Sensor Bus.Instead,the message retrieval has to be realized by regularly submitted API queries.Another disadvantage is the limited update rate of Twitter’s search index which means that for example a data publication mes-sage posted by a sensor adapter is not instantly accessible by a service adapter.

Further on,there are functional limitations related to a Twitter pro?le.Besides the restriction of the length of a single message(i.e.,a so-called’tweet’)to140characters,a Twitter account(a)cannot submit more than150requests per hour and(b)cannot send more than1.000tweets a day. Restriction(a)results in a limited update rate for the ser-vices listening to the Sensor Bus.By using the method sta-tuses/friends timeline of the Twitter API a service adapter can maximally query150times an hour the recently posted tweets of all sensors it is following8.

A more signi?cant disadvantage is restriction(b).In the current design of the Sensor Bus implementation,a sensor posts one data value per tweet.Due to(b),this results in a maximum sampling rate of around40measurements per hour.In many sensor network applications,this would be unacceptable.

7.CONCLUSIONS AND FUTURE WORK In this paper,we outline the need for mechanisms to close the gap between geosensor networks and the Sensor Web. We propose to achieve this integration by introducing an in-termediary layer realized as a message bus-the Sensor Bus. The Sensor Bus incorporates a publish/subscribe mechanism and de?nes certain messages to realize the interaction with the Sensor Web layer and geosensor network layer.

An implementation of the Sensor Bus is published as open source to the52?North Sensor Web community9.We have implemented the adaptable Sensor Bus concept in di?erent ways based on instant messaging technologies or message oriented middleware.An in-depth evaluation of the di?erent approaches including extended scalability and performance tests is planned future work.

In this work,we present an implementation of the Sensor Bus based on Twitter.Building the Sensor Bus on existing messaging infrastructures is bene?cial to reuse functionality such as authentication,as well as scalability and reliability management.However,the limited functionality of Twitter (e.g.,the maximum of140characters per tweet or the rate limiting for API queries)does not leverage the full function-ality of SWE https://www.doczj.com/doc/ed2672167.html,e cases of a certain complexity cannot be handled by such a solution(e.g.,satellite mission planning).

We aim at contributing the concept of the Sensor Bus to OGC’s SWE initiative.The Sensor Bus enables an auto-matic noti?cation of SWE services about changes in sen-8To solve this issue Twitter o?ers the possibility for applying to whitelist certain accounts or IP addresses.A whitelisted entity can submit20.000requests per hour.

9https://www.doczj.com/doc/ed2672167.html,/swe

sor metadata as well as newly gathered sensor data.So far,new data or changed metadata has to be communicated separately to the di?erent SWE services which may lead to inconsistencies within the Sensor Web quickly.Further de-velopments will base the Sensor Bus on OGC’s Sensor Event Service[13]which realizes a publish/subscribe architecture based on Web Service Noti?cation.This will result in an intelligent Sensor Bus allowing complex event processing on sensor data streams.

A next step will be the development of a mechanism for plug&play of geosensors based on the Sensor Bus architec-ture.Currently,we develop a SensorML application schema de?ning a generic sensor interface description to automati-cally generate the communication logic for adapting sensors to the Sensor Bus.Based on these developments,semantic challenges in the context of sensor plug&play[7]will be identi?ed and tackled.Finally,the approach has to be ap-plied in real-world scenarios to demonstrate its bene?ts in sensor asset management.As the project develops,we an-ticipate that both our design and our research agenda will evolve as new issues and opportunities arise. Acknowledgment

This work is?nancially supported by the project”Flexible and E?cient Integration of Sensors and Sensor Web Ser-vices”funded by the European Regional Development Fund (ERDF)for NRW(contract number N114/2008)of the Eu-ropean Union,as well as the52?North Sensor Web commu-nity which envisions a real time integration of heterogeneous sensors into a coherent information infrastructure.

8.REFERENCES

[1]A.Aasa,O.J¨a rv,and R.Ahas.Developing a model to

determine the impacts of climate change on the

geographical distribution of tourists.In https://www.doczj.com/doc/ed2672167.html,mmert

and L.Arend,editors,Sensing a Changing World

2008,pages55–58.Wageningen University,2008. [2]K.Aberer,M.Hauswirth,and A.Salehi.A

middleware for fast and?exible sensor network

deployment.In Proceedings of the32nd international

conference on Very large data bases,2006.

[3]K.Aberer,M.Hauswirth,and A.Salehi.Middleware

support for the Internet of Things.5.GI/ITG KuVS

Fachgespraech-Drahtlose Sensornetze,pages15–19, 2006.

[4]M.Botts.OGC Implementation Speci?cation07-000:

OpenGIS Sensor Model Language(SensorML).

Technical report,Open Geospatial Consortium,2007.

[5]M.Botts,G.Percivall,C.Reed,and J.Davidson.

OGC(R)Sensor Web Enablement:Overview and

High Level Architecture.Lecture Notes In Computer

Science,4540:175–190,2008.

[6]A.Broering,T.Foerster,and S.Jirka.Interaction

Patterns for Bridging the Gap between Sensor

Networks and the Sensor Web.In WoT2010:First

International Workshop on the Web of Things,

Mannheim,Germany,March29.-April2.2010;

forthcoming.

[7]A.Broering,K.Janowicz,C.Stasch,and W.Kuhn.

Semantic Challenges for Sensor Plug and Play.In

J.Carswell,S.Fotheringham,and G.McArdle,

editors,Web&Wireless Geographical Information

Systems(W2GIS2009),7&8December2009,

Maynooth,Ireland,number5886in LNCS,pages

72–86.Springer,2009.

[8]A.Broering,E.H.J¨u rrens,S.Jirka,and C.Stasch.

Development of Sensor Web Applications with Open

Source Software.In First Open Source GIS UK

Conference(OSGIS2009),22June2009,Nottingham, UK,2009.

[9]K.Chang,N.Yau,M.Hansen,and D.Estrin.

https://www.doczj.com/doc/ed2672167.html,-A Centralized Repository to SLOG

Sensor Network Data.In International Conference on Distributed Computing in Sensor Networks(DCOSS)

/EAWMS Workshop,San Francisco,USA,June2006.

[10]L.-K.Chung,B.Baranski,Y.-M.Fang,Y.-H.Chang,

T.-Y.Chou,and B.J.Lee.A SOA based debris?ow

monitoring system-Architecture and proof-of-concept implementation.In The17th International Conference on Geoinformatics2009,Fairfax,USA,2009.

[11]S.Cox.OGC Implementation Speci?cation07-022r1:

Observations and Measurements-Part1-

Observation schema.Technical report,Open

Geospatial Consortium,2007.

[12]L.de Souza,P.Spiess,D.Guinard,M.Kohler,

S.Karnouskos,and D.Savio.Socrades:A web service based shop?oor integration infrastructure.Lecture

Notes in Computer Science,4952:50,2008.

[13]J.Echterho?and T.Everding.OGC Discussion Paper

08-133:OpenGIS Sensor Event Service Interface

Speci?cation.Technical report,Open Geospatial

Consortium,2008.

[14]T.Foerster,A.Broering,S.Jirka,and J.M¨u ller.

Sensor Web and Geoprocessing Services for Pervasive

Advertising.In J.M¨u ller,P.Holleis,A.Schmidt,and M.May,editors,Proceedings of the2nd workshop on

pervasive advertising-in conjuction with Informatik

2009,pages88–99,L¨u beck,October2009.

[15]S.Fruijtier,E.Dias,and H.Scholten.Geo

Mindstorms:Investigating a sensor information

framework for disaster management processes.In

L.Kooistra and A.Ligtenberg,editors,Sensing a

Changing World2008,pages50–54.Wageningen

University,2008.

[16]E.Gamma,R.Helm,R.Johnson,and J.Vlissides.

Design Patterns:Elements of Resusable

Object-Oriented Software.Addison-Wesley

Professional,1995.

[17]P.Gibbons,B.Karp,Y.Ke,S.Nath,and S.Seshan.

Irisnet:An architecture for a worldwide sensor web.

IEEE Pervasive Computing,pages22–33,2003. [18]G.Hohpe and B.Woolf.Enterprise integration

patterns:Designing,building,and deploying messaging solutions.Addison-Wesley Longman Publishing,

Boston,MA,USA,2003.

[19]S.Jirka,A.Broering,and C.Stasch.Applying OGC

Sensor Web Enablement to Risk Monitoring and

Disaster Management.In GSDI11World Conference, Rotterdam,Netherlands,June2009.

[20]S.Jirka,A.Broering,and C.Stasch.Discovery

Mechanisms for the Sensor Web.Sensors,9,2009. [21]K.Lee.IEEE1451:A Standard in Support of Smart

Transducer Networking.Instrumentation and

Measurement Technology Conference,2000.IMTC

2000.Proceedings of the17th IEEE Volume2,2:525–528,2000.

[22]S.Liang,V.Toa,and A.Croitoru.Sensor Web and

GeoSWIFT-An Open Geospatial Sensing Service.In International Society for Photogrammetry and Remote Sensing XXth Congress–Geo-Imagery Bridging

Continents,pages12–23,2004.

[23]D.Moodley and I.Simonis.A New Architecture for

the Sensor Web:The SWAP Framework.In5th

International Semantic Web Conference ISWC2006,

Athens,Georgia,USA,2006.

[24]A.Na and M.Priest.OGC Implementation

Speci?cation06-009r6:OpenGIS Sensor Observation

Service(SOS).Technical report,Open Geospatial

Consortium,2007.

[25]S.Nittel.A Survey of Geosensor Networks:Advances

in Dynamic Environmental Monitoring.Sensors,

9:5664–5678,2009.

[26]A.Santanche,S.Nath,J.Liu,B.Priyantha,and

F.Zhao.Senseweb:Browsing the Physical World in

Real Time.In International Conference on

Information Processing in Sensor Networks(IPSN),

Nashville,USA,2006.

[27]G.Schimak and D.Havlik.Sensors Anywhere-Sensor

Web Enablement in Risk Management Applications.

ERCIM News,The Sensor Web-Bringing Information to Life(76):40–41,2009.

[28]M.Sgroi,A.Wolisz,A.Sangiovanni-Vincentelli,and

J.Rabaey.A Service-Based Universal Application

Interface for Ad Hoc Wireless Sensor and Actuator

Networks.In W.Weber,J.Rabaey,and E.Aarts,

editors,Ambient intelligence.Springer Verlag,2005. [29]D.Shepherd and S.Kumar.Distributed Sensor

Networks,chapter Microsensor Applications.

Chapman&Hall,2005.

[30]J.Shneidman,P.Pietzuch,J.Ledlie,

M.Roussopoulos,M.Seltzer,and M.Welsh.

Hourglass:An Infrastructure for Connecting Sensor

Networks and Applications.Technical report,Harvard University,EECS,2004.

[31]I.Simonis.OGC Best Practices06-028r3:OGC Sensor

Alert Service Candidate Implementation Speci?cation.

Technical report,Open Geospatial Consortium,2006.

[32]I.Simonis.OGC Implementation Speci?cation

07-014r3:OpenGIS Sensor Planning Service.

Technical report,Open Geospatial Consortium,2007.

[33]C.Stasch,K.Janowicz,A.Broering,I.Reis,and

W.Kuhn.A Stimulus-Centric Algebraic Approach to

Sensors and Observations.In3rd International

Conference on Geosensor Networks,Lecture Notes in

Computer Science.Springer,2009.

[34]C.Stasch,A.C.Walkowski,and S.Jirka.A Geosensor

Network Architecture for Disaster Management based on Open Standards.In M.Ehlers,K.Behncke,F.W.

Gerstengabe,F.Hillen,L.Koppers,L.Stroink,and

J.W¨a chter,editors,Digital Earth Summit on

Geoinformatics2008:Tools for Climate Change

Research.,pages54–59,2008.

android课程介绍

1．课程基本信息课程编号：M21F58D10 课程名称：Android应用与开发开设学期：第3学期总学时：60 总学分：4 课程类别：岗位能力课程课程性质：必修课适用专业：软件技术（移动应用开发）责任单位：计算机与软件学院 2．课程定位《Android应用与开发》课程是软件技术（移动应用开发方向）专业的岗位能力课程，课程的开设依据是软件技术专业人才培养目标和相关职业岗位（群）的能力要求，对本专业所面向的手机软件开发与测试、软件开发与项目管理等岗位所需要的知识、技能和素质目标的达成起支撑作用。在课程设置上，前导课程有《Java程序设计》（M21F1611），《数据结构》（M21F232），后续课程有《移动互联网开发综合实训》（M21J57B10）、《毕业实习》（M21J991）。 3．课程设计思路首先依据专业人才培养方案中关于人才培养目标的阐述，明确课程目标；其次，结合职业教育课程观、教学观、能力观，基于软件工程的开发过程，以项目化教学来组织课程内容，在课程内容的选择与排序中，以软件项目研发的不同阶段、典型任务为载体，将课程内容划分为互相联系的学习情景；第三，通过对各学习情景中学习目标、主要内容、授课方式、师生要求等各项内容的描述，来规范课程所要求的内容；第四，通过对课程内容的选取和组合，以一个完整的项目为载体，完成课程的实施；最后，通过对项目实施过程中各个环节的考察和评价，来完成对课程的评鉴与考核。本课程在设计上本着懂方法，重应用的总体思路，突出体现职业教育的技能型、应用性特色，着重培养学生的实践应用技能，力求达到理论方法够用，技术技能过硬的目的。 4．课程建设基本理念本课程按照理论实践一体、课内外互补、课堂教学与培优工程相结合的课程设计指导思想，以任务或项目为载体组织教学内容，突出学生的主体地位，实现“教、学、做”的有机融合；通过班级讲授、团队学习、个体辅导、展示交流、技能大赛等手段，实现从模仿到应用到创新的高职学生递进式培养。本课程强调对学生职业岗位能力的培养和职业素养的养成，针对不同环节，采用特定的教学方法，有意识、有步骤地将职业能力的训练和职业素养的形成融入到实际的教学过程中。

照度计算公式

照度计算公式 E=(Φ×n×N×MF×UF)/A 式中，E=工作面的维护平均照度（lx)； Φ=灯初始光通量（lm） n= 每个灯具所含光源的数量 N=灯具数量 MF=设备维护系数 UF=设备利用系数 A=工作面的面积一个灯具在给室内的利用系数UF是照射到工作面上所有光通量与设备中所有灯发出的光通量之比。这一系数包括反射光、相互反射光及来自灯具的直接光。它的值取决于房间的形状、高度、墙壁的反射率及灯具的光强分布。 MF=设备维护系数一般取之间。 UF=设备利用系数（由于范围更宽）一般取之间。一般室内取，体育取维护系数：一般取～实例：一个100平方米的办公室，层高3米，工程方要求的照度是

500lx，要用我公司的3*36W T8灯盘，请问要用多少套用上面的公司计算，取MF（设备维护系数）为，UF（设备利用系数）为，假设要用3*36W T8灯盘X套，公式E=(Φ×n×N×MF×UF)/A 即：500=（3300×3×X××）/100 X= 约9套照度计算方法利用系数法计算平均照度平均照度 (Eav) = 光源总光通量(N*Ф)*利用系数(CU)*维护系数(MF) / 区域面积(m2) (适用于室内或体育场的照明计算) 利用系数：一般室内取，体育取维护系数：一般取～举例 1：室内照明： 4×5米房间，使用3×36W隔栅灯9套平均照度＝光源总光通量×CU×MF/面积＝(2500×3×9)××÷4÷5 ＝1080 Lux 结论：平均照度1000Lux以上举例 2：体育馆照明：20×40米场地，使用POWRSPOT 1000W金卤灯60套平均照度＝光源总光通量×CU×MF/面积

Android智能手机软件开发概述

第1章Android智能手机软件开发概述随着移动设备的普及，其功能越来越完善，移动设备的系统平台也日渐火热。本章首先介绍智能手机及其操作系统平台（如Symbian、Android、Windows Mobile、IOS等），并对学习Android手机软件开发的必要性进行阐述。之后，介绍Android平台的总体架构，并对完成Android应用程序软件开发的SDK及其组成进行简要说明。最后，对通过Android Market发布自己应用程序的方法进行介绍。学习本章内容时，要求重点掌握如下内容： ●了解常见的智能手机操作系统平台。 ●了解Android的总体结构及主要功能。 ●了解Dalvik虚拟机、AVD等。 ●了解Android Market及发布应用程序的方法。 1.1 智能手机及其操作系统据中国互联网络信息中心于2011年7月19日发布的统计《中国互联网络发展统计报告》显示，2011年上半年，我国手机网民规模继续稳步扩大。截至2011年6月底，我国手机网民达3.18亿，较2010年底增加1495万人（如图1.1所示）。可以说，智能手机正在快速走进人们的生活。就目前来看，已经有越来越多的人开始把智能手机当作日常看视频、办公的首选设备。随着A9架构、双核概念的问世，智能手机能更广泛、轻松地接管生活和工作中的大小事务[1]。因此，学习和研究智能手机软件开发，具有广阔的社会需求和工程实践意义。图1.1 手机上网网民规模智能手机一般指像个人电脑一样具有独立操作系统，可由用户自行安装软件等第三方服务商提供的程序，并且，用户能对手机功能进行扩充。目前，全球多数手机厂商都有智能手

色温 (CCT) 和色度坐标 (x, y 值)

一、关于led灯具SSL规范的概述今年 5 月份，LED 灯具的能源之星的规范，美洲已公开草案;估计今年的 8 至9 月份，会上升为最终版本,并于9 个月后，即08 年6 月份，授理ENERGY STAR申请;本规范是由美国能源部DOE 负责组织, Lighting Research Center 技术负责; 二、重要流行词 1、SSL (Solid-State Lighting 固态照明) vs. Semi-conductor Lighting (半导体照明) vs. LED Lighting (LED 照明) SSL：(在Internet 网络上，SSL 在90 年代即有, 是Internet 传输加密协议缩略词SSL =Secure Socket Layer; )如今，在国外，有关研究 LED 的政府机构，公司和机构，很流行用 SSL 代替LED; 然而，目前，SSL 还没有给出正式定义，在美国的LRC 网站上，“What is SSL?”,只是解释为: SSL 是区别于传统的灯丝白帜发光和气体放电发光原理，由半导体的电子发光，包括LED，OLED，Laser Diode (LD)，light-emitting polymers. 2、半导体照明 (Semi-conductor Lighting), 在中国政府机构，沿用过去的称谓“半导体照明”较多;但是，LED 产品，技术和标准，美国领先其他国家许多;中国也会随美国技术潮流使用SSL 称谓,尤其在DOE 公开本规范后; 三、我们的目的 1、本规范是第一部LED 照明的性能参数标准,指明了LED 照明的基本要求; 2、LED 灯具的ENERGY STAR认证，要在08 年6 月前讨论;但是，我们可以提前借鉴此规范化的参数标准,应用到研发品质行销工作中,是有帮助的; 3、本规范是如何基于荧光灯，建立 SSL-LED 灯具的光效目标和特性参数要求：

色坐标计算方法

先计算色坐标。方法是，必须先有光谱P（λ）。然后光谱P（λ），与三刺激函数X（λ）、Y（λ）、Z（λ），分别对应波长相乘后累加，得出三刺激值，X、Y、Z。那么色坐标x=X/(X+Y+Z)、Y/(X+Y+Z) 一般，光谱是从380nm到780nm，间隔5nm，共81个数据。 X（λ）、Y（λ）、Z（λ），是CIE规定的函数，对应光谱，各81个数据，色度学书上可以查到。再计算色温，例如色度坐标x=0.5655,y=0.4339。用“黑体轨迹等温线的色品坐标”有麦勒德、色温、黑体轨迹上的(xyuv)、黑体轨迹外的(xyuv)。我们用xy的数据来举例。一、为了方便表达，把黑体轨迹上的x写成XS、y写成YS，黑体轨迹外的x写成XW、y写成YW。先把每一行斜率K算出，K=(YS-YW)/(XS-XW)，写在表边上。例如: 麦勒德530斜率K1=(.4109-.3874)/(.5391-.5207)=1.3352 麦勒德540斜率K2=(.4099-.3866)/(.5431-.5245)=1.2527 麦勒德550斜率K3=(.4089-.3856)/(.5470-.5282)=1.2394 二、找出要计算的x=.5655、y=.4339这个点，在哪两条等温线之间，就是这点到两条等温线距离一正一负。如果不知道它的大概色温，计算就繁了；因为你说是钠灯，那么它色温在1800到1900K之间。用下公式算出这点到麦勒德530，1887K等温线的距离D1 D1=((x-YS)-K(y-XS))/((1+K×K)开方) =((.4339-.4109)-1.3352(.5655-.5391))/((1+1.3352×1.3352)开方) =(.023-.03525)/(1.6682)=-.0073432 再计算出这点到麦勒德540，1852K等温线的距离D2 D2=((.4339-.4099)-1.2527(.5655-.5431))/((1+1.2527×1.2527)开方) =(.024-.02806)/(1.6029)=-.0025329 因为D1、D2都是负数，没找到。再计算出这点到麦勒德550，1818K等温线的距离D3 D3=((.4339-.4089)-1.2394(.5655-.5470))/((1+1.2394×1.2394)开方) =(.025-.02293)/(1.6029)=+.0013005 D2负、D3正，找到了。D2对540麦勒德记为M2、D3对550麦勒德记为M3 三、先把距离取绝对值。按比例得出这点麦勒德M，公式是

小学数学新课标解读

小学数学新课标解读《全日制义务教育数学课程标准（修定稿）》（以下简称《标准》）是针对我国义务教育阶段的数学教育制定的。根据《义务教育法》.《基础教育课程改革纲要（试行）》的要求，《标准》以全面推进素质教育，培养学生的创新精神和实践能力为宗旨，明确数学课程的性质和地位，阐述数学课程的基本理念和设计思路，提出数学课程目标与内容标准，并对课程实施（教学.评价.教材编写）提出建议。《标准》提出的数学课程理念和目标对义务教育阶段的数学课程与教学具有指导作用，教学内容的选择和教学活动的组织应当遵循这些基本理念和目标。《标准》规定的课程目标和内容标准是义务教育阶段的每一个学生应当达到的基本要求。《标准》是教材编写.教学.评估.和考试命题的依据。在实施过程中，应当遵照《标准》的要求，充分考虑学生发展和在学习过程中表现出的个性差异，因材施教。为使教师更好地理解和把握有关的目标和内容，以利于教学活动的设计和组织，《标准》提供了一些有针对性的案例，供教师在实施过程中参考。二、设计理念数学是研究数量关系和空间形式的科学。数学与人类的活动息息相关，特别是随着计算机技术的飞速发展，数学更加广泛应用于社会生产和日常生活的各个方面。数学作为对客观现象抽象概括而逐渐形成的科学语言与工具，不仅是自然科学和技术科学的基础，而且在社会科学与人文科学中发挥着越来越大的作用。数学是人类文化的重要组成部分，数学素养是现代社会每一个公民所必备的基本素养。数学教育作

为促进学生全面发展教育的重要组成部分，一方面要使学生掌握现代生活和学习中所需要的数学知识与技能，一方面要充分发挥数学在培养人的科学推理和创新思维方面的功能。义务教育阶段的数学课程具有公共基础的地位，要着眼于学生的整体素质的提高，促进学生全面.持续.和谐发展。课程设计要满足学生未来生活.工作和学习的需要，使学生掌握必需的数学基础知识和基本技能，发展学生抽象思维和推理能力，培养应用意识和创新意识，在情感.态度与价值观等方面都要得到发展；要符合数学科学本身的特点.体现数学科学的精神实质；要符合学生的认知规律和心理特征.有利于激发学生的学习兴趣；要在呈现作为知识与技能的数学结果的同时，重视学生已有的经验，让学生体验从实际背景中抽象出数学问题.构建数学模型.得到结果.解决问题的过程。为此，制定了《标准》的基本理念与设计思路。基本理念数学课程应致力于实现义务教育阶段的培养目标，体现基础性.普及性和发展性。义务教育阶段的数学课程要面向全体学生，适应学生个性发展的需要，使得：人人都能获得良好的数学教育，不同的人在数学上得到不同的发展。课程内容既要反映社会的需要.数学学科的特征，也要符合学生的认知规律。它不仅包括数学的结论，也应包括数学结论的形成过程和数学思想方法。课程内容要贴近学生的生活，有利于学生经验.思考与探索。内容的组织要处理好过程与结果的关系，直观与抽象的关系，生活化.情境化与知识系统性的关系。课程内容

Android平台介绍及使用指导

Android平台介绍及使用指导二○一○年二月版本 1.0

目录 Android平台介绍 ................................................................................... - 4 -基本名词...................................................................................................................... - 5 - 操作方法介绍 .......................................................................................... - 6 - 手机按键介绍.............................................................................................................. - 6 - 快捷键介绍.................................................................................................................. - 6 - 信息功能介绍.............................................................................................................. - 7 - 联系人功能介绍........................................................................................................ - 11 - 通话记录功能介绍.................................................................................................... - 14 - 文本粘贴/复制功能介绍.......................................................................................... - 14 - Push Email（Moxier）功能介绍............................................................................ - 15 - 电子邮件功能介绍.................................................................................................... - 16 - 桌面功能介绍............................................................................................................ - 19 - 蓝牙功能介绍............................................................................................................ - 23 - Wifi功能介绍........................................................................................................... - 23 - 飞行模式功能介绍.................................................................................................... - 23 - CDMA数据链接介绍................................................................................................... - 24 - 黑屏解锁功能............................................................................................................ - 25 - 回复出厂设置............................................................................................................ - 26 - 应用程序设置............................................................................................................ - 26 - GPS设置..................................................................................................................... - 27 - 手机中英文语言切换................................................................................................ - 28 - 更换手机输入法........................................................................................................ - 29 - 数据线链接Android手机........................................................................................ - 29 - 手机测试模式进入方法............................................................................................ - 30 - 横屏显示介绍............................................................................................................ - 30 - 浏览器功能介绍........................................................................................................ - 31 - RSS功能介绍............................................................................................................ - 32 - Q/A- 34 -

色温对照表

色温对照表 - 以K为单位的光色度对照表色温指的是光波在不同的能量下，人类眼睛所感受的颜色变化。在色温的计算上，是以 Kelvin 为单位，黑体幅射的0° Kelvin= 摄氏 -273 ° C 做为计算的起点。将黑体加热，随着能量的提高，便会进入可见光的领域，例如，在2800 ° K 时，发出的色光和灯泡相同，我们便说灯泡的色温是2800 ° K。可见光领域的色温变化，由低色温至高色温是由橙红 --> 白 --> 蓝。色温的特性 1. 在高纬度的地区，色温较高，所见到的颜色偏蓝。 2. 在低纬度的地区，色温较低，所见到的颜色偏红。 ( <---- 低色温 ------------------ 高色温 ----> ) 3. 在一天之中，色温亦有变化，当太阳光斜射时，能量被( 云层、空气 )吸收较多，所以色温较低。当太阳光直射时，能量被吸收较少，所以色温较高。 4.Windows 的 sRGB 色彩模型是以6500 ° K 做为标准色温，以 D65 表示之。 5. 清晨的色温大约在4400 ° K。 6. 高山上色温大约在6000 ° K。色温对照表 - 以K为单位的光色度对照表烛焰 1500 家用白灯 2500-3000 60瓦的充气钨丝灯 2800 100瓦的钨丝灯 2950 1000瓦的钨丝灯 3000 500瓦的投影灯 2865 500瓦钨丝灯 3175 3200K的泛光灯 3200 琥珀闪光信号灯 3200 R32反射镜泛光灯 3200 锆制的浓弧光灯 3200 1，2，4号泛光灯，反射镜泛光灯 3400 暖色的白荧光灯 3500 切碎箔片，清晰闪光灯信号 3800 冷色的白荧光灯 4500 白昼的泛光灯 4800 白焰碳弧灯 5000 M2B闪光信号灯 5100 正午的日光 5400 高强度的太阳弧光灯 5550 夏季的直射太阳光 5800 早上10点到下午3点的直射太阳光 6000 蓝闪光信号灯 6000 白昼的荧光灯 6500 正午晴空的太阳光 6500 阴天的光线 6800-7000 高速电子闪光管 7000 来自灰蒙天空的光线 7500-8400

OTDR(光时域反射仪)操作手册

CMA8800光时域反射测试仪操作手册郑州维修中心

目录第一章快速开始第二章概览第三章OTDR测量模式第四章储存及打印功能附录 CMA8800的特点及日常维护

第一章快速开始 1.1仪器供电 CMA8800是通过220VAC适配器/充电器从外部供电。注意：CMA8800不能用内置电池供电! 电源开关位于上面板的右侧。按下开关即可启动。 1.2启动顺序当该单元上电后，首先出现了一个开始画面，包括软件版本及日期，接着单元进行自检。结果显示如图1-2所示。当自检结束后，按下PAUSE可以读屏幕上的信息。按下“继续”可以继续进行操作。图1－2典型设备和自检屏幕 1.3操作模式选择屏幕当上电完成后，将显示一个可供选择模式的屏幕，每一种可见的模式均位于相应软键的旁边，你只要按下相应的键就按相应的模式进行操作。这里为有经验的用户出了每一种模式的快速操作信息，详细的信息见于手册中后面的章节。

1.3.1故障定位模式故障定位模式是一种快速确定光纤端/断点位置的方法。当你按下FAULT LOCATE，首先就开始一个光纤接口质量的检查（如果在附加设置中，光纤接口质量的检查功能已启动），这个检查会告诉你基于用户在快速设置菜单中所定义的背向散射系数的连接是不好的、一般的还是好的。当检查进行测试完成后，光纤端/断点显示如图1－4所示。通过按下硬键TEST/STOP或者模式屏幕软键可使测试取消，

1.3.2配置模式按“配置模式”键进入“快速设置菜单”屏，在这里设置自动测试功能及测量参数，参见3.1节和3.2关于快速设置和附加设置的信息按“启动”键显示光纤存储信息屏幕(如图1-5所示)，从这里你可以输入描述新的测试的信息，按“继续”就到达了连接光纤屏幕，接着再按“继续”就开始进行测试。如需要，此时可按“模式屏”回到模式选择屏幕。 1.3.3专家模式专家级的OTDR模式是为那些想应用CMA8800更先进功能的用户而设计的，所有的OTDR功能均见于这种模式。按软键“专家模式”进入快速设置菜单（参见图3－1）；在此处，你可以在测试之前设置所有的必要的参数；目前的设置决定了自动执行哪些操作功能，如果“全自动”设为开，则所有的操作均被认定为自动执行，如果“全自动”设为关，则你必须选择哪一种操作是自动执行的。按下“启动”进入显示曲线屏幕，按下硬键“REAL TIME”开始运行实时扫描，再按下硬键“REAL TIME”可以终止实时扫描状态。按下硬键“TEST/STOP即可开始测试。 1.3.3.1曲线显示屏幕从设置状态按GO就显示了一个与图6-1相似的曲线屏。 1、图标行在曲线图形区上方的图标行，显示了对比曲线和背景曲线参考的曲线文件名和其他信息，包括该曲线是否已被滤波、是否被施加衰减、是否进行过曲线分析的，测试平均是否未完成等产，对比曲线的文件名在屏幕左边显示，背景曲线(如果存在)的文件名在网络上的屏幕右边显示。光标行图标：有效结果表平滑已经运行正在行进数据采集差值比较光标锁定曲线被施加衰减

1.android发展历程简介

android（Google公司开发的操作系统） Android是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。尚未有统一中文名称，中国大陆地区较多人使用“安卓”或“安致”。Android操作系统最初由Andy Rubin开发，主要支持手机。2005年8月由Google收购注资。2007年11月，Google与84家硬件制造商、软件开发商及电信营运商组建开放手机联盟共同研发改良Android系统。随后Google以Apache 开源许可证的授权方式，发布了Android的源代码。第一部Android智能手机发布于2008年10月。Android逐渐扩展到平板电脑及其他领域上，如电视、数码相机、游戏机等。2011年第一季度，Android在全球的市场份额首次超过塞班系统，跃居全球第一。2013年的第四季度，Android平台手机的全球市场份额已经达到78.1%。[1] 2013年09月24日谷歌开发的操作系统Android在迎来了5岁生日，全世界采用这款系统的设备数量已经达到10亿台。2014第一季度Android平台已占所有移动广告流量来源的42.8%，首度超越iOS。但运营收入不及iOS。编程语言 C/C++（底层）Java等（应用层）系统家族类Unix,Linux 源码模式自由及开放源代码软件内核类型宏内核(Linux内核) 软件许可 Apache License、GPL等 1系统简介编辑 Android一词的本义指“机器人”，同时也是Google于2007年11月5日 Android logo相关图片(36张) 宣布的基于Linux平台的开源手机操作系统的名称，该平台由操作系统、中间件、用户界面和应用软件组成。 Android一词最早出现于法国作家利尔亚当（Auguste Villiers de l'Isle-Adam）在1886年发表的科幻小说《未来夏娃》（L'ève future）中。他将外表像人的机器起名为Android。Android的Logo是由Ascender公司设计的，诞生于2010年，其设计灵感源于男女厕所门上

照度计算方法

利用系数法计算平均照度平均照度(Eav) = 光源总光通量(N*Ф)*利用系数(CU)*维护系数(MF) / 区域面积(m2) (适用于室内或体育场的照明计算) 利用系数：一般室内取0.4，体育取0.3 维护系数：一般取0.7～0.8 举例 1：室内照明： 4×5米房间，使用3×36W隔栅灯9套平均照度＝光源总光通量×CU×MF/面积＝(2500×3×9)×0.4×0.8÷4÷5 ＝1080 Lux 结论：平均照度1000Lux以上举例 2：体育馆照明：20×40米场地，使用POWRSPOT 1000W金卤灯 60套平均照度＝光源总光通量×CU×MF/面积＝(105000×60)×0.3×0.8÷20÷40 ＝1890 Lux 结论：平均水平照度1500Lux以上某办公室平均照度设计案例：

设计条件：办公室长18.2米，宽10.8米，顶棚高2.8米，桌面高0.85米，利用系数0.7，维护系数0.8，灯具数量33套，求办公室内平均照度是多少？灯具解决方案：灯具采用DiNiT 2X55W 防眩日光灯具，光通量3000Lm，色温3000K，显色性Ra90以上。根据公式可求得： Eav = (33套X 6000Lm X 0.7 X 0.8) ÷ (18.2米X 10.8米) = 110880.00 ÷ 196.56 m2 = 564.10Lux 备注：照明设计必须必须要求准确的利用系数，否则会有很大的偏差，影响利用系数的大小，主要有以下几个因素： *灯具的配光曲线 *灯具的光输出比例 *室内的反射率，如天花板、墙壁、工作桌面等 *室内指数大小复杂的区域照明设计，需利用专业的照明设计软件，进行电脑模拟计算。浅析照度计算的研究与探讨照度计算是实现建筑光环境设计总体构想的重要手段。采用单位容量法计算,能较好平衡准确度与简便度,为照度计算的实际运用加大了可操作性。

小学数学新课程标准(修改稿——)解读

小学数学新课程标准(修改稿)解读一、前言《全日制义务教育数学课程标准（修改稿）》（以下简称《标准》）是针对我国义务教育阶段的数学教育制定的。根据《义务教育法》、《基础教育课程改革纲要（试行）》的要求，《标准》以全面推进素质教育，培养学生的创新精神和实践能力为宗旨，明确数学课程的性质和地位，阐述数学课程的基本理念和设计思路，提出数学课程目标与内容标准，并对课程实施（教学、评价、教材编写）提出建议。《标准》提出的数学课程理念和目标对义务教育阶段的数学课程与教学具有指导作用，教学内容的选择和教学活动的组织应当遵循这些基本理念和目标。《标准》规定的课程目标和内容标准是义务教育阶段的每一个学生应当达到的基本要求。《标准》是教材编写、教学、评估、和考试命题的依据。在实施过程中，应当遵照《标准》的要求，充分考虑学生发展和在学习过程中表现出的个性差异，因材施教。为使教师更好地理解和把握有关的目标和内容，以利于教学活动的设计和组织，《标准》提供了一些有针对性的案例，供教师在实施过程中参考。二、设计理念数学是研究数量关系和空间形式的科学。数学与人类的活动息息相关，特别是随着计算机技术的飞速发展，数学更加广泛应用于社会生产和日常生活的各个方面。数学作为对客观现象抽象概括而逐渐形成的科学语言与工具，不仅是自然科学和技术科学的基础，而且在社会科学与人文科学中发挥着越来越大的作用。数学是人类文化的重要组成部分，数学素养是现代社会每一个公民所必备的基本素养。数学教育作为促进学生全面发展教育的重要组成部分，一方面要使学生掌握现代生活和学习中所需要的数学知识与技能，一方面要充分发挥数学在培养人的科学推理和创新思维方面的功能义务教育阶段的数学课程具有公共基础的地位，要着眼于学生的整体素质的提高，促进学生全面、持续、和谐发展。课程设计要满足学生未来生活、工作和学习的需要，使学生掌握必需的数学基础知识和基本技能，发展学生抽象思维和推理能力，培养应用意识和创新意识，在情感、态度与价值观等方面都要得到发展；要符合数学科学本身的特点、体现数学科学的精神实质；要符合学生的认知规律和心理特征、有利于激发学生的学习兴趣；要在呈现作为知识与技能的数学结果的同时，重视学生已有的经验，让学生体验从实际背景中抽象出数学问题、构建数学模型、得到结果、解决问题的过程。为此，制定了《标准》的基本理念与设计思路基本理念。（一）总：六大理念 1、人人学有价值的数学，人人都能获得必需的数学，不同的人在数学上得到不同的发展 2、数学是人们生活、劳动和学习必不可少的工具，数学是一切重大技术发展的基础，数学是一种文化。 3、数学学习的内容要有利于学生主动地进行观察、实验、猜测、验证、推理、与交流，动手实践、自主探索与合作交流是学生学习数学的重要方式。 4、学生是数学学习的主人，教师是数学学习的组织者、引导者、合作者。 5、评价的目的—了解学生的数学学习历程，改进教师的教学；目标多元，方法多样；重过程，轻结果；关注情感态度。 6、把现代信息技术作为学生学习数学和解决问题的强有力的工具。（二）分六大理念的解读: 数学课程应致力于实现义务教育阶段的培养目标，体现基础性、普及性和发展性。义务教育阶段的数学课程要面向全体学生，适应学生个性发展的需要，使得：人人都能获得良好的数学教育，不同的人在数学上得到不同的发展。 1、关于数学课程的功能（1）“人人学有价值的数学”是指作为教育内容的数学，应当是适合学生在有限的学习时间里接触、了解和掌握的数学。怎样理解有价值的数学?

自我介绍,android

自我介绍,android 篇一：安卓应用软件个人简历个人简历篇二：面试时自我介绍整理合集应聘面试自我介绍范文尊敬的领导：您好！我是×××，毕业于××学校××专业，获得的是××学位在学校期间，主修的专业课有×××（此处添加技术类专业课，尤其是和应聘工作相关的），根据所学的知识，也参加过一些具体项目的事实，比如××××项目，在其中负责××模块或者××工作，应用了×××计算机语言或者技术，取得了×××什么样的成果。并在实践中，加深了对××的认识，提高了软件设计（或其他技术）的实际操作能力。另外，在学校中也参加过一些社团活动，比如××（此处最好说1－2样），在其中加强了和同学们的团队协作，并且有×××的感受和知识。个性上××××（此处copy简历里面的性格介绍，主要要有团队精神，个人踏实努力，有责任感之类的）在这里应聘贵公司的××职位，是想将自己的所学得到充分发挥，并在这里学习成长。希望有这样的机会，能和诸位成为同事。我的情况大概就是这样，请问您有什么其他方面想要了解的么?（主

体说完之后来句这个，可以直接话题过度给面试的人，省得最后冷场）文员面试自我介绍范文经过长期的实践和研究，面试文员的朋友需要注意三项文员面试技巧。文员面试自我介绍范文下次奉上。文员面试技巧一：文职岗位要求面试者有很好的亲和力，能与其他人进行充分的沟通，这就要求面试者必须要保持良好的心态来面对招聘人员。关键要做到八个字——顺其自然，不卑不亢。只有这样才能给招聘人员留下好印象，使其相信你有能力在将来进入公司后与同事和谐的相处。要做到面带微笑，平视考官，避免情绪波动，走向两个极端：一是自卑感很重，觉得坐在对面的那人博学多才、回答错了会被笑话。所以，畏首畏尾，不敢畅快地表达自己的观点；另一种情况则是，很自信，压根不把招聘人员放在眼里，觉得对方还不如自己。这两种表现都要不得，最好的表现应是，平视对方，彬彬有礼，不卑不亢。应树立两种心态：一.面试的目的是合作而不是竞争。招聘人员对考生的态度一般是比较友好的，他目的是把优秀的人才遴选进自己的公司增强公司的竞争力，而不是为与考生一比高低而来，所以考生在心理上不要定位谁强谁弱的问题，那不是面试的目的。二.面试中两者的地位是平等的，面试者是求职不是乞职。面试者是在通过竞争，谋求职业，而不是向招聘人员乞求工作，成功的关键在于自己的才能以及临场发挥情况。文员面试技巧二：面试者要注意自己在面试中的礼仪问题。因为文职

色坐标转换色温

首先，你要有一“黑体轨迹等温线的色品坐标”表。此表“色度学”书中有。然后，运用内插法和三角形垂足法计算色温在“黑体轨迹等温线的色品坐标”表中，每一行(每一色温)有“黑体轨迹上”x、y，设为x1、y1，“黑体轨迹外” x、y，设为x2、y2。用仪器测得色度坐标x、y设为x0、y0。从最低色温起，取其x1、y1，x2、y2；代入D1 = (x0-x1)(y1-y2)-(x1-x2)(y0-y1),如果D1 = 0则(相关)色温得到。如果D1不等于0，取上一行x1、y1，x2、y2；代入D2 = (x0-x1)(y1-y2)-(x1-x2)(y0-y1),如果D2 = 0则(相关)色温得到。如果D2不等于0，判断D1*D2是否小于0。如果D1*D2大于0，使D1 = D2，再取上一行x1、y1，x2、y2；代入D2 = (x0-x1)(y1-y2)-(x1-x2)(y0-y1),如果D2 = 0则(相关)色温得到。如果D2不等于0，判断D1*D2是否小于0。如果D1*D2小于0，则找到“测得坐标在这两条等温线之间”。D1、D2取绝对值，相对应色温为T1、T2。那么CCT ≈ T1 + D1 * (T1+T2) / (D1+D2) 如果一直找不到D1*D2小于0，那是测得坐标在∞(无穷大)等温线左下方，那片区域是没有(相关)色温的。按理说，离开黑体轨迹一定距离，就没有(相关)色温概念了，可是现在给搞混淆了。

或者，你在附图中，把你坐标点上去，看左右两条等温线的色温，估算出。特征点对应的色坐标值和色温光源点X坐标Y坐标色温(K) A 0.4476 0.4074 2854 B 0.3484 0.3516 4800 C 0.3101 0.3162 6800 D 0.313 0.329 6500 E 0.3333 0.3333 5500

文档之家

Sensor Bus_An Intermediary Layer for Linking Geosensors and the Sensor Web

android课程介绍

照度计算公式

最新小学数学课程标准(完整解读).

Android智能手机软件开发概述

色温 (CCT) 和色度坐标 (x, y 值)

色坐标计算方法

小学数学新课标解读

Android平台介绍及使用指导

色温对照表

最新小学数学课程标准(完整解读)

OTDR(光时域反射仪)操作手册

1.android发展历程简介

照度计算方法

小学数学新课程标准(修改稿——)解读

自我介绍,android

色坐标转换色温