SENSOR WEB
Sensor web can be defined in several ways, so it consists of several definitions. the Sensor Web is a macro-instrument comprising a number of sensor platforms. These platforms, or pods, can be orbital or terrestrial, fixed or mobile Coordinated communication and interaction among the pods provides a spatio -temporal understanding of the environment. Specific portal pods provide end user access points for command and information flow into and out of the Sensor Web. At JPL, the focus has been on in situ Sensor Webs, with the resulting system output viewed over the Internet.
Traditionally, Sensor Web is defined as a web of interconnected heterogeneous sensors that are interoperable, intelligent, dynamic, flexible and scalable. This definition implies that a sensor Web is a hardware network of sensors. Alternatively, the Sensor Web can be defined as a universe of network-accessible sensors, sensory data and information. This definition is more network-centric and includes sensory data and information, but seems excluding the virtual sensor.
A sensor web definition from computational view point and under the service-oriental architecture (SOA) and web service environment. A sensor web is a group of interoperable web services which all comply with a specific set of sensor behaviors and interfaces specifications. In this definition, a web service which contains an algorithm or simulation model could be a senor in a sensor web as long as its interfaces and behaviors comply with the specifications. such a sensor is called the virtual sensor. From computational viewpoint, there is no different between a real sensor and a virtual sensor. By using this definition, we can classify a sensor web based on the specifications it complies. For example, a sensor web that complies with OGC Sensor Web Enablement (SWE) specifications can be called an OGC sensor web, while a sensor web that complies with IEEE sensor web specification can be called an IEEE sensor web. A sensor web can be applied to a specific application domain. By combining the application domain and the specifications it complies with, a sensor web can be uniquely identified. By defining a sensor web as a group of interoperable web services, all features of the web services are also applicable to the web-ready sensors, which include but not limit to the dynamics, flexibility, plug- in-and-play, self description, and scalability. This also implies the data and information generated by individual web-ready sensors are interoperability and the sensor services are chainable.
By defining a sensor web as a group of interoperable web services, all features of the web services are also applicable to the web-ready sensors, which include but not limit to the dynamics, flexibility, plug- in-and-play, self description, and scalability. This also implies the data and information generated by individual web-ready sensors are interoperability and the sensor services are chainable.
From above definition we can define sensor web as
A spatially distributed observing system, consisting of nodes that are interconnected through a nications fabric, and that functions as a single, highly coordinated, virtual instrument.
Sensor web reacts to instrument observations and other information to determine present and future states of Earth- and space-science phenomena. The Sensor Web Application Prototype (SWAP) was developed as an engineering proof-of-concept for a collaborative sensor web. It used government owned software, the Instrument Remote Control (IRC) software, to monitor and control the sensors. Each sensor in the web published its data to the other sensors. Sensors used the data from other sensors to make decisions and issue commands to other sensors.
The Scenario Specification describes the science scenario that we were using to drive the engineering prototype. Keep in mind that this was an engineering proof of concept and that the science scenario was written to simplify the concept, not necessarily to prove any scientific problem. Examples of how the scenario would be different for a real science mission would be to deploy more than 5 rain gauges and field them farther apart than we did during the demonstration. These scientific issues with the scenario would not have affected the engineering concepts that we were exploring.
Traditionally, Sensor Web is defined as a web of interconnected heterogeneous sensors that are interoperable, intelligent, dynamic, flexible and scalable. This definition implies that a sensor Web is a hardware network of sensors. Alternatively, the Sensor Web can be defined as a universe of network-accessible sensors, sensory data and information. This definition is more network-centric and includes sensory data and information, but seems excluding the virtual sensor.
A sensor web definition from computational view point and under the service-oriental architecture (SOA) and web service environment. A sensor web is a group of interoperable web services which all comply with a specific set of sensor behaviors and interfaces specifications. In this definition, a web service which contains an algorithm or simulation model could be a senor in a sensor web as long as its interfaces and behaviors comply with the specifications. such a sensor is called the virtual sensor. From computational viewpoint, there is no different between a real sensor and a virtual sensor. By using this definition, we can classify a sensor web based on the specifications it complies. For example, a sensor web that complies with OGC Sensor Web Enablement (SWE) specifications can be called an OGC sensor web, while a sensor web that complies with IEEE sensor web specification can be called an IEEE sensor web. A sensor web can be applied to a specific application domain. By combining the application domain and the specifications it complies with, a sensor web can be uniquely identified. By defining a sensor web as a group of interoperable web services, all features of the web services are also applicable to the web-ready sensors, which include but not limit to the dynamics, flexibility, plug- in-and-play, self description, and scalability. This also implies the data and information generated by individual web-ready sensors are interoperability and the sensor services are chainable.
By defining a sensor web as a group of interoperable web services, all features of the web services are also applicable to the web-ready sensors, which include but not limit to the dynamics, flexibility, plug- in-and-play, self description, and scalability. This also implies the data and information generated by individual web-ready sensors are interoperability and the sensor services are chainable.
From above definition we can define sensor web as
A spatially distributed observing system, consisting of nodes that are interconnected through a nications fabric, and that functions as a single, highly coordinated, virtual instrument.
Sensor web reacts to instrument observations and other information to determine present and future states of Earth- and space-science phenomena. The Sensor Web Application Prototype (SWAP) was developed as an engineering proof-of-concept for a collaborative sensor web. It used government owned software, the Instrument Remote Control (IRC) software, to monitor and control the sensors. Each sensor in the web published its data to the other sensors. Sensors used the data from other sensors to make decisions and issue commands to other sensors.
The Scenario Specification describes the science scenario that we were using to drive the engineering prototype. Keep in mind that this was an engineering proof of concept and that the science scenario was written to simplify the concept, not necessarily to prove any scientific problem. Examples of how the scenario would be different for a real science mission would be to deploy more than 5 rain gauges and field them farther apart than we did during the demonstration. These scientific issues with the scenario would not have affected the engineering concepts that we were exploring.
COMPONENTS OF SENSOR WEB
1. Instrument
2. Node
3. Data
4. Communications Fabric
1. Instrument
A self-contained infrastructure that receives (digital or analog) data from one or more sensors, provides temporary storage for the measurements and transmits sensor data to a node. It may have its own infrastructure to sustain its own operation (e.g., power, structure, environmental, etc), or it may rely entirely on the node (e.g., a spacecraft bus) for this infrastructure. Examples rain gauge, magnetometer, IR observatory, laser interferometer.
2. Node
1. Instrument
2. Node
3. Data
4. Communications Fabric
1. Instrument
A self-contained infrastructure that receives (digital or analog) data from one or more sensors, provides temporary storage for the measurements and transmits sensor data to a node. It may have its own infrastructure to sustain its own operation (e.g., power, structure, environmental, etc), or it may rely entirely on the node (e.g., a spacecraft bus) for this infrastructure. Examples rain gauge, magnetometer, IR observatory, laser interferometer.
2. Node
A self-contained computing, storage, and communications device. A node provides mechanical, power, thermal, electrical, communications, control, timing, environmental protection, etc. to support its own operation and possibly for any science instrument directly connected to the node. A node is also called Pod or Platform. The Sensor Web consists of a system of intra-communicating, spatially distributed sensor pods that can be deployed to monitor and explore new environments. Typically, the communication occurs wirelessly. Each pod consists of two modules. The first module comprises the transducers that physically interact with the environment and convert environmental parameters into electrical signals. The second module represents the infrastructure of the Sensor Web itself. Included in this module are telecommunication capabilities, power sources and energy harvesting devices, and computation devices to run the protocol schemes and provide for local data analysis. The penultimate goal of a Sensor Web is to extract knowledge from the data collected and adapt and react accordingly.
Although the computation hardware in a pod can be quite sophisticated, it is the sharing of information among the pods that gives the Sensor Web a macro-intelligence. the Sensor Web is an instrument where greater functionality is derived from a parallel-type architecture as sensor measurements (including pod location) are passed, and collectively interpreted, from pod to pod. This global sharing of information will lead to pod synergism (the whole of their activity being greater than the sum of their parts) by permitting intelligent resource (power, bandwidth, consumables) management by the web, and allowing for self-modifying behavior based on environmental factors and internal web diagnostics.
A Sensor Web pod is merely a physical platform for a sensor and thus can be orbital or terrestrial, fixed or mobile and might even have real time accessibility via the Internet. Pod-to-pod communication is both omni-directional and bi-directional where each pod sends out collected data to every other pod in the network. As a result, on-the-fly data fusion, such as false positive identification and plume tracking, can occur within the Sensor Web itself and the system subsequently reacts as a coordinated, collective whole to the incoming data stream. For example, instead of having uncoordinated smoke detectors, a Sensor Web can react as a single, spatially-dispersed, fire locator.
The basic concept of a network of sensors is not new. The novelty of the Sensor Web architecture lies in the ability of the individual pieces to act and coordinate as a whole. This immediately allows the system to be synchronous throughout, unlike many other networks. In addition, the individual pods of a Sensor Web are all equal with one another and a Sensor Web architecture does not require special gateways or routing to have each of the individual pieces communicate with one another or an end user. By definition, a Sensor Web is an autonomous, stand-alone, sensing entity that does not require the presence of the World Wide Web to function.
The term "Sensor Web" is sometimes used to refer to sensors connected to the Internet (or "World Wide Web"). Such terms are occasionally used in conjunction with projects of the Open Geospatial Consortium (OGC) or Sensor Net. In this case, the network architecture requires the Internet to link together the individual sensing elements. The OGC architecture is very different than that of a true Sensor Web system and requires schemes to bring together vastly different datasets, in the same way that TCP/IP is used to tie together vastly different pieces of hardware and computing platforms. Note also that a single Sensor Web may be an individual sensing element imputing into an OGC-type network
It is critically important to recognize that the individual pods in the Sensor Web are not the actual instrument. The macro-instrument is comprised of the sensor pods and the space between them. An example of an actual Sensor Web pod is shown in Figure 4. This pod, constructed at JPL in 1999, was used to demonstrate the validity of the Sensor Web concept. The small pod contains a radio transmitter and receiver, microcontroller, lithium battery (hidden in the base), and two sensors to monitor light levels and temperature. The total pod mass is about 50 g. Over a duty cycle of one set of measurements per second, it is estimated that 50 microwatts of power are needed.
The figure above is a node.Although the computation hardware in a pod can be quite sophisticated, it is the sharing of information among the pods that gives the Sensor Web a macro-intelligence. the Sensor Web is an instrument where greater functionality is derived from a parallel-type architecture as sensor measurements (including pod location) are passed, and collectively interpreted, from pod to pod. This global sharing of information will lead to pod synergism (the whole of their activity being greater than the sum of their parts) by permitting intelligent resource (power, bandwidth, consumables) management by the web, and allowing for self-modifying behavior based on environmental factors and internal web diagnostics.
A Sensor Web pod is merely a physical platform for a sensor and thus can be orbital or terrestrial, fixed or mobile and might even have real time accessibility via the Internet. Pod-to-pod communication is both omni-directional and bi-directional where each pod sends out collected data to every other pod in the network. As a result, on-the-fly data fusion, such as false positive identification and plume tracking, can occur within the Sensor Web itself and the system subsequently reacts as a coordinated, collective whole to the incoming data stream. For example, instead of having uncoordinated smoke detectors, a Sensor Web can react as a single, spatially-dispersed, fire locator.
The basic concept of a network of sensors is not new. The novelty of the Sensor Web architecture lies in the ability of the individual pieces to act and coordinate as a whole. This immediately allows the system to be synchronous throughout, unlike many other networks. In addition, the individual pods of a Sensor Web are all equal with one another and a Sensor Web architecture does not require special gateways or routing to have each of the individual pieces communicate with one another or an end user. By definition, a Sensor Web is an autonomous, stand-alone, sensing entity that does not require the presence of the World Wide Web to function.
The term "Sensor Web" is sometimes used to refer to sensors connected to the Internet (or "World Wide Web"). Such terms are occasionally used in conjunction with projects of the Open Geospatial Consortium (OGC) or Sensor Net. In this case, the network architecture requires the Internet to link together the individual sensing elements. The OGC architecture is very different than that of a true Sensor Web system and requires schemes to bring together vastly different datasets, in the same way that TCP/IP is used to tie together vastly different pieces of hardware and computing platforms. Note also that a single Sensor Web may be an individual sensing element imputing into an OGC-type network
It is critically important to recognize that the individual pods in the Sensor Web are not the actual instrument. The macro-instrument is comprised of the sensor pods and the space between them. An example of an actual Sensor Web pod is shown in Figure 4. This pod, constructed at JPL in 1999, was used to demonstrate the validity of the Sensor Web concept. The small pod contains a radio transmitter and receiver, microcontroller, lithium battery (hidden in the base), and two sensors to monitor light levels and temperature. The total pod mass is about 50 g. Over a duty cycle of one set of measurements per second, it is estimated that 50 microwatts of power are needed.
3. Data
Loosely defined to mean any “string of bits”.
Data bits may represent
Loosely defined to mean any “string of bits”.
Data bits may represent
Raw sensor or science instrument data
Processed science data
Ancillary information required to perform science data processing
Node or instrument state data (e.g., spacecraft health and safety engineering telemetry data; instrument mode of operation; …)
Commands to the node and/or science instrument to change its operating state
Executable code (i.e., algorithms) to be executed by the node
Sensor web system state messages
4. Communications Fabric
A communications infrastructure that permits nodes to transmit and receive data between one another. The scope of the communications fabric encompasses The communications media (e.g., wired vs. wireless; optical vs. RF; baseband signal vs. modulated; etc)
A communications infrastructure that permits nodes to transmit and receive data between one another. The scope of the communications fabric encompasses The communications media (e.g., wired vs. wireless; optical vs. RF; baseband signal vs. modulated; etc)
The communication topology (e.g., ring, star, mesh, etc)
Communications fabric protocol considerations like:
Different models (e.g., 7 layer OSI vs. 5 layer Internet; virtual circuit vs. connectionless; etc)
Low level protocols (e.g., media access, transport, routing, etc)
Higher level protocols (e.g., guaranteed in-order packet delivery; file transfer services, etc)
Low level protocols (e.g., media access, transport, routing, etc)
Higher level protocols (e.g., guaranteed in-order packet delivery; file transfer services, etc)
Signal processing
Signal encoding scheme
Uncompressed vs. Lossless or lossy compression
Forward Error Correction (FEC)
.
