How to Implement Wireless Diagnostics in the Industrial Internet of Things

There are many different unlicensed bands for wireless operation around the world, and each band has different implications for gathering diagnostic data for the Industrial Internet of Things (IoT). Some bands such as 2.4 GHz have standardized protocols such as ZigBee, Bluetooth and Wi-Fi that can be used to both gather data from and about industrial equipment and to access diagnostic data about the network.¹ Other sub-GHz bands, while potentially lower cost and longer range, do not provide these capabilities.

Figure 1: Unlicensed wireless bands around the world.

The application requirements are also important. Industrial IoT applications for diagnostics require less data than streaming video or file transfers, and so there are many more options for the designer. The size and positioning of the network is also important. Higher frequency bands offer more channels and more bandwidth, hence can serve larger networks and drive more data throughput. Lower frequency radio waves propagate better than higher frequency and so achieve better range, especially inside buildings. 

Each of these bands also have different optimizations and processing requirements. The higher performance requirements of the protocols in the 2.4 GHz band have a major influence on the design and power consumption of the wireless transceivers. However, continual evolution of the silicon design by companies such as Texas Instruments is constantly updating the technology, reducing cost and power with higher levels of integration of digital and analog components.

Topologies

Wireless networks can also be categorized by the way the nodes are connected. The topologies vary from a star, where all the nodes are connected to one central node, usually the gateway to the Internet, to a mesh where every node can connect to multiple other nodes, and one of these may serve as the Internet gateway.

Figure 2: Characterizing different wireless protocols for range, throughput and network topologies.

A popular example of a star topology is a Wi-Fi network, with a center node as an access point (AP) and the other nodes as stations. Bluetooth can also be a star network with a smartphone or tablet as the central node.

An example of a mesh network is a ZigBee Light Link network where multiple lighting fixtures form a mesh network to extend the network reach in large buildings. One of the ZigBee nodes is called a coordinator, and it usually serves also as an Internet gateway.

However, mesh networks are more complex to design and can exhibit a longer delay routing a message from a remote node through the mesh, compared to star networks. The benefit of a mesh topology is that it can extend the range of the network through multiple hops, while maintaining low radio transmission power. They can also achieve better reliability by enabling more than one path to relay a message through the network should one node fail.

The size of the network is also an important consideration. Bluetooth, for example, supports up to twenty connections, although this is being expanded with a mesh capability. Other protocols such as ZigBee can support thousands of connections.

Both star and mesh topologies have been standardized in protocols, mostly running at 2.4 GHz, although ZigBee can also be used in the sub-GHz bands. Here, the data bandwidth is traded for longer range, ideal for diagnostic data.

Sub-GHz band

The sub-GHz band varies from 315 MHz to 915 MHz in different regions around the world. By having a flexible RF front end, it is possible to produce a cost effective system-on-chip that can operate across all the different bands. This allows low data rate diagnostic links to be easily set up using modules such as the CC1310DK-KIT-ND.

Figure 3:  Wireless modules simplify the acquisition of diagnostic data for the Industrial Internet of Things.

These modules use the CC1310, the first in a Sub-1-GHz family of cost-effective, ultra-low-power wireless MCUs. The CC1310 combines a flexible, very low power RF transceiver with a powerful 48 MHz Cortex-M3 microcontroller in a platform supporting multiple physical layers and RF standards.

A key part of the architecture is a dedicated radio controller (using the Cortex-M0 core) that handles low-level RF protocol commands that are stored in ROM or RAM, thus ensuring ultra-low power and flexibility to support different bands and different proprietary PHY protocols.

For diagnostic applications, sensors can be handled in a very low-power manner by a dedicated autonomous ultralow power controller block that can be configured to handle analog and digital sensors. This allows the main Cortex-M3 core to stay in sleep mode for the maximum amount of time to reduce power.

The power and clock management and radio systems require specific configuration and handling by software to operate correctly, and this has been implemented in the TI real time operating system (RTOS). The complete TI-RTOS and device drivers are offered in source code free of charge.

Based on the IEEE 802.15.4 link layer standard, ZigBee is a low-throughput, low-power and low-cost technology that can deliver up to 250 kbit/s in the 2.4 GHz ISM band, although the spec also supports the 868 MHz and 915 MHz ISM bands. It also has the capability to maintain very long sleep intervals and low operation duty cycles to be powered by coin cell batteries for years.

The standard defines the higher networking layers on top of the 802.15.4 link layer and various application profiles enable interoperable implementations, and the performance of the CC1130 can support these protocols for the sub-GHz band operation.

ZigBee can be used in multiple applications, but it has gained momentum in smart energy, industrial automation and lighting control.

One reason for its success is the mesh network topology that can include up to thousands of nodes.

To connect to the IoT, ZigBee networks require an application-level gateway that is one of the nodes in the network. This gateway runs a TCP/IP stack and application in parallel to the ZigBee stack, using an Ethernet or Wi-Fi connection for the link to the Internet.

Building a proprietary mesh network for the industrial IoT is potentially time consuming and expensive, especially considering the need to ensure all the nodes are secure from hacking, which is why many existing networks use a star topology. Thus the use of ZigBee in the sub-GHz bands for providing diagnostic data is gaining traction for the scalability, low power consumption and ruggedness.

2.4 GHz band

The 2.4 GHz ISM band has many different options for wireless connectivity in the industrial IoT.  ZigBee, Bluetooth and Wi-Fi are all protocols that can be used with star or mesh networks to provide diagnostic data from industrial equipment.

The CC2640 wireless MCU contains an ARM® Cortex®-M3 (CM3) core, which runs the application and the higher layers of the protocol stack for Bluetooth or ZigBee. The CM3 processor provides a high-performance, low-cost platform that meets the system requirements of minimal memory implementation and low-power consumption with the fast system response to interrupts that is needed to collect diagnostic data.

Figure 4: The CC2540 combines an ARM Cortex-M3, Cortex-M0 and a proprietary sensor controller to provide a flexible wireless node for the 2.4 GHz band.

Like the CC1130, the RF Core contains an ARM Cortex-M0 processor that interfaces the analog RF and base-band circuitries, handles data to and from the system side, and assembles the information bits in a given packet structure for distribution through the network to the cloud-based application. The core uses a high level, command-based API to the main CPU to transfer the data, although this is not accessible to application developers.

The RF core is capable of autonomously handling the time-critical aspects of the radio protocols for Bluetooth Low Energy, reducing the load on the main CPU and leaving more resources for the user applications, and has its own 4 KB SRAM block that runs initially from separate ROM memory.

A key part of the CC2640 for diagnostics in the industrial IoT is the Sensor Controller. This is a proprietary power-optimized controller that selectively enables the different peripherals such as a temperature sensor and the data acquisition sub-system. The controller can read and monitor sensors or perform other tasks autonomously, significantly reducing power consumption and offloading the main CM3 CPU.

The Sensor Controller is set up using a PC-based configuration tool, called Sensor Controller Studio, and can be used to control analog sensors using the integrated ADC and the digital sensors using GPIOs, bit-banged I²C and SPI. It can also work with the UART communication for sensor reading or debugging, and also be used for capacitive sensing, waveform generation, pulse counting and quadrature decoder for polling rotation sensors. Data from these sensors can provide the diagnostic information back to an application in the cloud via the RF core.

The Always On (AON) segment of the device contains circuitry that is always enabled when there is a power supply. This includes the real time clock, which can be used to wake the device from any state where it is active. The RTC contains three compare and one capture registers. With software support, the RTC can be used for clock and calendar operation. The battery monitor and temperature sensor are accessible by software through the AON and give a battery status indication as well as a coarse temperature measure that can be used for diagnostics of the wireless node. If there is a problem with the battery, or the node is overheating, the data can be sent to the network monitoring software and onwards as an alert to the operator.

Conclusion

Addressing the range of unlicensed wireless bands for the industrial Internet of Things can be a challenge, especially for handling diagnostic data. The latest system-on-chip RF transceivers are combining power-efficient and optimized controllers that can process and relay diagnostic data through to a gateway node to specialist applications in the cloud. This data can be used for diagnosing the health of both the industrial equipment and the wireless network itself to predict problems. This data can then be used to avoid costly shutdowns with proactive maintenance and replacement.

References:

1. Wireless Connectivity for the Internet of Things. Texas Instruments