Sensors and Embedded Systems

Types of sensors

Sensors can measure virtually anything. Examples include GPS, moisture, water levels, tank levels, carbon dioxide, volatile organic hydrocarbons, particulates, radiant temperature, temperature, wind speed sensors and more. In addition to measuring specific attributes, there are other kinds of inputs to IoT systems such as machine vision. Applications of sensors with IoT connectivity are wide, including smart metering of utilities such as water and electricity, building management systems, and asset tracking with Real Time Location Services (RTLS).

They also have the potential to enable major societal changes, such as monitoring offenders in their own homes rather than in prison, through technological incarceration, and provide inputs to applications such as industrial automation.

Interfacing sensors to an IoT system

Sensors, at a very basic level, are inputs to an IoT system. Sensors typically physically interface with IoT system using a communication bus such as I²C, serial and USB, 0-10 V or 4-20 mA using. These systems use sensors and electrical contacts that have been around a long time so all the normal considerations with conventional sensors apply for IoT. For example, the digital signals from contact closures need to have debounce protection.

Similarly, outputs from an IoT system may be digital or analogue and will interface to actuators that make changes to things, such as opening or closing of gates, opening or closing valves, switching pumps etc, often using electrical or solid state relays. Again there are well known things that needs to be addressed, such as the characteristics of the load including the voltage, the current, whether it is an inductive load. 

Sensors typically interface with RF modules, which have analogue and digital I/O pins. Many RF modules also have optional integrated microprocessor. RF modules also require an antenna connection. 

One challenge of IoT systems is discovering where the IoT devices are on a network. A key technology for addressing this is the W3C's Semantic Sensor Networks.

Cost and power limitations of sensor communications for IoT

The cost and power requirements of communications technologies can limit the amount of sensors deployed in IoT solutions.

Many communications technologies used for IoT, such as wifi, are power hungry. Others, like satellite, are expensive. Low power solutions are emerging, including the Sigfox low power wide area (LPWA) network.

Aggregating sensors in an array around a user terminal for satellite communications can reduce the power and cost of satellite communications for IoT applications, by eliminating the need for a dedicated uplink and downlink for each sensor.

Visualisation of IoT sensor data

Technologies such as augmented reality can be used to provide a visual display of IoT sensor data overlaid on the physical device which is updated live in the cloud for 'in context' visualisation of device data.

Hardware

The following diagram gives a representation of the architecture of a typical deployed Thing. In many cases you typically have a single sensor, a single actuator and battery storage, but when you generalise a Thing to a slightly higher level the following elements may all be represented.

The sensors and actuators shown above are just a few examples. They will interface to an intelligence in a micro-controller via, typically via an interface of some sort. The microcontroller would typically be a system on chip with thousands of options. Ultimately the microcontroller is responsible for communicating via an interface which could be low power Wide Area Networks among other communication options. 

In addition to designing an IoT device from scratch, it is also possible to buy a single board computer such as Raspberry Pi and configure this for use in many IoT contexts.

Firmware

Firmware is the software on the microcontroller embedded into the Thing. The following diagram presumes a typical configuration of one or more sensors and one or more actuators with input and output drivers that communicate with a network. All this is managed by an operating system.

At the simplest level there is a master polling loop microcontroller architecture but typically the more advanced microcontrollers available are running RTOS which give you a high level of sophistication. Linux is also a possibility and Contiki is often tied to 6LoWPAN communications.

The structure of the firmware includes input and output drivers, middleware that takes the information and converts it via an applications programme, interfaced to some form that the business logic of the device can decide what to do with that information. That can include communications up via the network or control commands from the network. It can also include local logic operations that relay input drivers or input devices and sensors to output drivers that drive actuators so you can have local control functions standalone from the network. The firmware includes a communications driver to interface with the communications device be it a radio or a UART etc. Behind that is a communications protocol stack. For example, for a Bluetooth low energy or for 6LoWPAN the communications must be managed in terms of the packet payload encapsulation, and the various layers in the communications protocol.

An important aspect that's sometimes overlooked is the connection manager. The purpose of the connection manager is to establish the network communications and to then monitor and manage that. If the communication drops out it must re-establish  communications. It typically to include some form of health heartbeat, so even when the Thing is not reporting data, the device is telling the server that it is alive and happy. Conversely you could have a ping from the network down to the Thing so that the Thing knows it has the necessary connectivity to fulfil it's part in the IoT system.

Overlaid on top of all of these software layers is energy management, that applies top to bottom in terms of how much energy we use for communicating with our sensors and actuators, how much energy is used for communications traffic and how much is consumed by the logical processing functions of the device. Another overlay top to bottom is having the appropriate security at the network level and then appropriate integrity in all of the processing layers.

Design Considerations

In terms of your typical Thing, we're really talking about standalone battery powered devices, so we need energy storage and desirably some form of external source into that, or it may be a self-contained primary cell. It's paramount that we carefully manage the energy. You'll hear power management tools often mentioned in IoT but it's not actually power we're trying to manage, it's energy. How many transmissions or sensing operations can we get out of the Thing, per day, per week, per month, and how many years will that battery last while performing that function. Getting that equation right is absolutely critical to having a practical thing. So an early starting point in considering the design of a Thing is to look at the energy budget over the life-cycle of the device and of its internal energy storage.

A design decision must be made on whether to select a RF and microprocessor combination module or a separate module for each function. A particular application might require microprocessor specifications that are not met by an integrated microprocessor. Or, it might be cheaper to implement intelligence on a separate microprocessor rather than paying the difference in cost between the RF module, and the combination RF module with an integrated the CPU.

It is  hard to hard to separate sensor selection and the design of embedded electronics from consideration of the communication technologies available. The regulatory maximum power level for all "things" is at at the usual 920 MHz is one watt, which is 30 dBm. A key influencing factor is the receiver’s sensitivity. The various communication technologies vary in their sensitivity (e.g. Bluetooth is 90 dBm. Zigbee is typically -100 dBm).LoRa can be up to 138 dBm which is why they are suited to the applications requiring long range. They can get distances of up to 15 kilometers. The reason for that is they've got three bandwidths. There's seven spread factors, giving normal bit rates from 290 bits per second up to 37 1/2 kilobits per second.

Other design considerations include the choice of antenna and the range of radio frequency (RF) considerations that must be taken into account, to ensure any IoT device is compliant with Australian regulations and the system will work as intended in the deployment environment. Another consideration is to determine if the data needs to be encrypted, typically using the Advanced Encryption Standard (AES) and the associated security considerations.

Power budgets must also be taken into account, especially where battery operation is required. What data rate is required and how much power will that use? Is there an option for recharging. What battery options are available for the device package and budget. These questions can affect the design or choice of sensing devices and embedded electrics dramatically.

Another design consideration is the level of uncertainty which may be introduced by the context, or environment, in which the sensor is used, and whether its performance will vary over time. This is discussed further in the section on design thinking for IoT.

Sources: Material on this page has primarily been sourced from the following:

• Presentation by Phillip Lark, Engineering Manager, Braetec titled Front End Integration: Connecting sensors to the cloud

• Webinar titled Satellites and the new industrial frontier – how new space technology is intersecting with the Internet of Things by Flavia Tata Nardina, Co-founder and CEO, Fleet Space Technologies