Sensor Platforms and Wireless Networks

Kevin Montgomery

loT/AI Inc.

Introduction

In order to obtain data from field and industrial locations of interest, one requires some means of acquiring the data and some back-end to store and access the data. This chapter discusses key ideas behind sensor platforms and wireless networks to support Total Exposure Health.

Sampling/Transmission Background

Data can be acquired in two different paradigms: logging (with later subsequent download) and transmission (either wired or wireless, perhaps in real time). Objectively, these two paradigms are technologically very similar, and the paradigm selected relates to whether the method of transmission is at the sampling location or at some other (perhaps laboratory) location.

An important concept to note is that there is a difference between the time and frequency that data are sampled (sampling frequency) vs the time which data are transmitted (transmit frequency). For example, a particular sensor could be sampled 100 times per second (100 Hz), but data aggregated in the sensor device would only be transmitted once per hour. Or, in the case of a logging paradigm, data could be sampled over a period of weeks, and the devices manually collected and brought back to a lab for download of data (hence a transmit/download time on the order of weeks). When the sampling time is very close to the transmission time and individual samples transmitted as acquired, the user terms the data acquisition to be “real time.” When the sampling time is similar to the transmission time, the user terms the data acquisition to be “near real time,” although this is largely a semantic difference along a spectrum of data acquisition.

It is important to note that the sampling frequency or transmission frequency timing may not be regular. A device could sample a sensor on regular intervals or only upon an external trigger. For example, a light detection sensor could trigger a device to wake up and capture an image. This discussion will term this type of sampling “triggered sampling.” Similarly, a device could acquire and store a significant number of samples of data and only transmit them when a condition is met (for example, if those samples indicate an important event such as a threshold exceeded for a particular reading; or, alternatively, a device could transmit only in response to another device requesting its data). This type of sampling will be called “triggered transmission.”

Thus, in general, sensors can be sampled on regular intervals (on-schedule sampling), or upon triggering (on-event sampling), or from an external source (on- demand sampling). While a data logging paradigm is important and the predominant method for data acquisition, the rest of this chapter will focus on issues related to data transmission.

Commercial Context

When understanding sensor and data acquisition/transmission technologies, it is also important to understand that they exist within a business or commercial context.

Currently, sensor manufacturers integrate into vertical markets to try to develop solutions to address a particular market need or niche, thus they try to develop a complete solution for the end customer, typically termed “B2C” for Business-to- Customer. This is in contrast to a different business paradigm where the manufacturer develops technologies solely for inclusion into the products created by other companies, termed an “original equipment manufacturer” (OEM) or a Business-to- Business (B2B) paradigm.

Those sensor companies that attempt to develop complete solutions, as stated above, also need to develop a means for data transmission and a back-end to store, process, and derive understanding from that data. Thus, in order to produce solutions, these manufacturers develop their own (typically proprietary, limited) transmission and back-end data storage systems to try to lock in end-users to their business ecosystem. However, sensor manufacturers typically are not experts in data transmission or data storage/databases; they know and are focused on sensors and detection.

Industrial hygiene and other applications, on the other hand, often require the integration of multimodal data from a multitude of sensor modalities. For example, data from noise sensors, air chemistry or particulate sensors, etc., may all be used. If each sensor is developed by a different company that provides a different means of data transmission and back-end, then the end-user is required to cobble together data streams from several proprietary systems and become a systems integrator between incompatible systems. This, in short, is painful, and computer/software system integration is not a typical skillset among the industrial hygiene (IH) end- user community.

Instead, a better idea would be an open, interoperable, common platform across sensor manufacturers so that data integration of other data sources, including personnel exposure monitors, area sensors, even satellite data transmission could be easily integrated. Once this new paradigm for industrial hygiene is chosen using interoperable sensors and open platforms, data fusion across modalities and all sources to obtain a holistic picture of exposure will be possible.

This chapter seeks to present a mental framework for this topic, survey options, and tradeoffs for implementation and provide an insight into the future of complete solutions for IH applications.

Terminology

The following terminology will aid this discussion:

• • Detector—samples a single parameter/detects a single agent (e.g., potential hydrogen [pH])
• • Sensor—consists of one or more detectors (e.g., multiparameter water anode with pH, oxidation-reduction potential (ORP), and turbidity integrated into one device).
• • Sensor platform (aka device)—comprises 0 or more sensors, provides means for data storage, transmission, optional local analytics, etc. (0 sensors = repeater or gateway).
• • Station—deployed sensor platform with relevant sensors. Stations can be in fixed locations or mobile vehicle (e.g., unmanned aerial vehicle [UAV], truck) or personal/wearable mounted.
• • System—comprises sensors, sensor platforms, along with back-end data storage, analytics, visualization, etc.
• • Solution—uses a system to solve a problem, answer a question, distinction=purpose.

Challenges

A series of challenges exist in the development and deployment of sensor systems, including the following: ^[1]

This can be ameliorated to some small degree: the antenna cables can be placed in an optimal location to radiate and a longer sensor cable can allow the sensor to be placed in the appropriate location so that the sensor device itself may be positioned for the optimal mounting and power location.

• • External dependencies: Deploying sensor systems with a dependency on external infrastructure (such as cellular or wireless fidelity [Wi-Fi], power, etc.) can all be compromised. Many systems have been deployed which rely on an optimal set of conditions to be met (reliable power, cellular access, etc.), and users have become painfully aware of the fragility of external infrastructure, especially when infrastructures are owned and operated by groups over which the user has little control. Therefore, a redundant, reliable system needs to minimize such dependencies with internal batteries to smooth out and ameliorate unreliable power and wireless transmission systems that employ graceful degradation techniques to maintain and preserve data in the face of communication disruptions.
• • Proprietary vs open: Many proprietary ecosystems of solutions exist but often are not cost effective nor as innovative. However, open-source systems often prove to be worth their extra cost.

Sensor Interfaces and Protocols

Sensors and detectors can be connected to a sensor platform device through many different interface standards (e.g., analog, serial (RS232/485), interface to communicate (I2C), system packet interface (SPI), universal serial bus (USB), eth- ernet, containing speed/bandwidth, distance, etc.). Options are shown in Table 14.1.

As is evident from the table, each method of interfacing has its own tradeoffs. In general, the thinner the gauge or longer the wire, the harder it is to pass and resolve electronic signals at the other end. A simple voltage will dissipate with distance, so current loop (typically 4-20 mA) analog transmission is used in industrial settings

TABLE 14.1

Options for Interface Standards to Connect Sensors/Detectors to Sensor Platform Devices

kbps—Kilobytes per second, Mbps—Megabytes per second, m—Meters.

for longer wire runs. Higher-level protocols and encoding methods present in RS232 (a simple interface of typically two to four wires—send, receive, power, ground) or RS422/485 (similar to RS232 but uses two wires each for send and receive in order to provide for a differential voltage) can extend range significantly. Yet, higher-level protocols and encoding methods as listed in the table can send and receive data even faster, although always with a tradeoff of distance. However, it is important to keep in mind that within the context of sensors, the distances from a hardwired sensor to its platform device is typically very short (on the order of a few meters). More importantly, the interface needed by a particular sensor of interest must be the primary concern when choosing what interface to use.

Beyond the electrical and signaling interfaces described above, a protocol for data acquisition is also layered on top. While the underlying interface may be RS232, a particular serial sensor will perhaps have a command to request its data and a means of encoding that data.

These sensor protocols tend to be very specific and proprietary to individual sensor manufacturers. While there have been many efforts to standardize sensor data transmission protocols, such as Sensor Model Language (SensorML), the vast majority of sensors provide a proprietary interface most appropriate for a target market. In the industrial market, this may be 4-20 milliamperes (mA) current loop as the de facto standard, whereas simple detectors may be analog voltage, and higher-end sensors may provide an ethernet interface with robust signaling protocol (such as Common Chemical, Biological, Radiological Nuclear (CBRN) Sensor Interface (CCSI in the Department of Defense context).

While on the surface this diversity may seem nonsensical, the reason for this lack of sensor interface and communication standardization is not new nor is it arbitrary. Manufacturers desire to provide the simplest and most optimal interface possible to decrease the cost and complexity of a design. Requiring all sensors to provide an ethernet interface would impose an undue cost, complexity, and power burden on a particular sensor and may not be appropriate for all markets and applications.

• [1] Size/weight v.v transmission power/lifetime: For wearable/small sensordevices, the devices must be small and lightweight and hence utilize smallbatteries. This necessarily implies a trade-off of range and/or transmissionfrequency in order to achieve a sufficient operational duty cycle and batterylifetime. However, these effects can be ameliorated using a hybrid topologynetwork as described below. • Competing for location requirements: Often, the best place to take a reading or sample may not be the best place to mount a device and obtain power,and the best place to mount may not be the best location for transmission.