In general, IoT architecture can be broken down into six components: Connectivity, Storage, Analytics, Visualization, Automation, and Security. This is the beginning of a series of articles which discusses lessons learned and questions which should be asked when designing an IIoT architecture. In this first article, we’ll discuss the starting point and source of data for many IoT initiatives – Connectivity.

1. Data acquisition

Data acquisition for an IIoT platform is usually done through sensors/instrumentation and integration with existing data acquisition systems such as DCS/SCADA/PLC systems.

– What data should be monitored?

When determining what data points to monitor, first consider the business need or purpose. For example, is the intention to increase the throughput, avoid unplanned outage, or perhaps manage product quality? The first thing is to identify what data is important to be brought into the platform and is necessary for further analysis and reporting. Subject Matter Expertise (SME) knowledge should be leveraged in this stage to make sure the proper sensors are selected to provide meaningful data. For example, if you are looking to monitor health and efficiency of rotating equipment a SME might order a set of pressure sensors, accelerometers, and temperature sensors to perform appropriate calculations like determining head and monitoring the overall status of the asset.

– Does the sensor meet your requirements?

Make sure the sensor’s signal type, precision level, signal range and other specifications meet your instrumentation requirements.  If your Subject Matter Expert has defined which type of sensors are needed, work with them to make sure they have specified the precision and range. For example, monitoring pressure of one set of assets might require a 0-1000 PSI sensor, whereas another set of assets might require 0-10,000 PSI sensors – this could be the different between collecting meaningful data and having a broken sensor! Also consider the interface requirements for the sensor – different instrumentation, communication devices, and I/O boards may require different types of interfaces.

2. Communication technologies

There are many wired and wireless communication technologies available in Industrial IoT space with different characteristics with respect to bandwidth, transmission rate, and coverage.

– Wired, wireless, or hybrid?

Wireless is cost effective, but it is not necessary to assume it is the only approach for your IIoT deployment. Wired connections may be required for bandwidth, stability, or security reasons. In fact, maintaining a mixed wireless and wired (hybrid) implementation in IIoT architecture is quite common. Wired sensors often provide a much higher data acquisition and transmission rate which might be necessary for things like monitoring high frequency vibration data. On the other hand, pulling wires can be expensive and wireless can be a cost-effective alternative. In the example of vibration monitoring, a wireless sensor might contain an embedded processor capable of locally analyzing the high frequency vibration data — sending over consistent snapshots of data on a normal timed basis and sending data more frequently when a threshold is reached.

– How frequent and how much bandwidth is required?

It is important to understand the characteristics of the data being monitored from your assets, and determine what communication requirements are, such as bandwidth and cycle. Some data, such as temperature, may not change frequently, and therefore can be transmitted every 15 minutes, instead of 5 seconds, to reduce cycle and gain better battery life.

– How many assets and how big the facility is?

Low-Power Wide-Area Networks (LPWAN), such as LoRA, Sigfox and NB-IoT(Narrow-Band IoT), provide wider network coverage at with relatively limited bandwidth. For example, LoRAWAN supports up to 0.9 Kbps and can transmit data over several miles, which can be a good option for asset monitoring in large outdoor production facility. On the other hand, technologies like WiFi or Bluetooth can deliver high bandwidth at a shorter range. For example, Bluetooth supports up to 25 Mbps and 100 meter range, and is a great option for interacting with customers and data communication in a smaller setting like a retail store.

– Are there existing wireless technologies in the facility?

Although the integration can be implemented in different layers in the IoT platform, It can significantly reduce cost and allow tighter integration by leveraging existing infrastructure. Maintaining the same wireless technology in field can introduce synergies with effort in managing network security. Industrial protocols like WirelessHART and ISA100 are being implemented more broadly by many organizations and there may already be an accepted standard or even an implementation within your organization.

3. Integration with existing data acquisition system

Most industrial facilities will have some form of Distributed Control System (DCS) and SCADA in the facility which can be leveraged as a data source or data destination with your IoT implementation. This integration can impact the technical design as well as physical location of the IoT node/gateway. For example, it may be easier to install IoT gateway near the onsite DCS system due to distance limitations of cabling and hazardous area requirements.

– What protocol does the existing system support?

Legacy systems often communicate via common industrial protocols such as Modbus, OPC, or proprietary protocols whereas moderns systems might support REST, SOAP, and Websockets. As such, a custom protocol conversion interface may be needed to bridge the old and new. For example, a custom Proprietary-to-MQTT interface could be needed to communicate between an PLC and the IoT platform. Some IoT platform support a wide variety of protocols, so consider what protocols you will need to communicate with when selecting your IoT platform.

– Does the legacy system provide the desired level of data resolution and granularity?

Even though your IoT gateway can talk to the legacy system, don’t overlook if the level of resolution and granularity provided by the legacy system can meet the data analysis requirements. For example, vibration analysis may need greater resolution than the legacy system or chosen protocol can support.

As described in 3 Critical Steps for Industrial IoT Initiatives post, these systems are capital intensive investments, and can be costly to be replaced, so it is crucial to leverage them if applicable.

4. Edge, Fog or Cloud computing

Analytics, such as threshold analysis, custom calculations, or even machine learning can be centralized in the IoT platform, deployed in the plant, or deployed with close proximity to the asset. Deployments to an IoT platform typically provide improved scalability and reliability whereas deployments at the edge or on-device can provide improved latency and remove the dependency network access.

– How to optimize network usage?

Does the gateway or each individual node have enough bandwidth to transmit both raw and calculated data? Does it make more sense to process the raw data at near the asset and only send analysis results to reduce network usage and battery consumption? For example, instead of sending high resolution vibration data over to cloud constantly, it may be a good idea to only send average vibration reading to cloud when the overall vibration level is low, but send spectral data when the overall reading reaches a threshold to enable more detailed analysis of issues.

– How intelligent is the node and how fast are actions expected to be taken?

Some edge devices may be powerful enough to run basic logic control and even complex algorithms for data analytics, but analytics can also be shifted to another more powerful server with enhanced computing power and ample storage space. In many cases, people choose cloud computing for its scalability, simple management, and operational expense benefit over capital expenses. However, don’t forget to consider if it is required to run analytics in the event of losing connectivity. For example, an edge or fog computing may be required to predict unplanned pump failure in an expensive refinery process with or without access to network connectivity. And analytics results may need to be fed into the legacy control system and existing engineering processes to react to events in near real-time in which case an edge or fog computing solution may be a better fit.

– How much storage is required at the edge or gateway?

Storage can be important for data buffering during network outages or data processing that requires significant history, such as data modeling in machine learning. While network outages are not desired, they are common and it’s important to ensure the gateway or edge device has sufficient storage space to buffer logged data and sync without any data loss when connectivity is restored. Depending on the buffering requirement, it may make sense to move the buffering capability to the gateway or local server with much more storage space to buffer the whole facility’s data rather that buffering on devices closer to the asset.

5. Security, security, security

Never underestimate the damage poor security design can cause.

– How sensitive is the data?

What damage can it cause if the data is leaked or manipulated and how can the data impact business processes? For example, the leak of predictive maintenance data is bad, but may not cause immediate damage to the asset or business processes. On the other hand, if the analyzed data is fed into DCS, it could be used to shut down the whole process or cause damage – in this case, one-way, read-only communication may be necessary between the IoT gateway and DCS. Be careful not to underestimate the impact of the asset. For example, a cooling pump may not be an expensive asset, but can cause costly/dangerous damage to other assets in the process if it malfunctions or is maliciously controlled.

– How are security policies and controls defined and executed?

Things like system patching and password change policies are important, and need to be executed regularly to ensure the platform is up to date and secured. It is important to ensure system log reviews, access authorization updates, and system vulnerability scans are conducted regularly to identify potential issues.

Security needs to be thoroughly considered and implemented in every step and every component of an IoT platform. Since it may not be practical to develop proprietary security technology, which is often less secure, it is important to ensure industry standard security technologies and best practices are utilized wherever applicable.

For more technology examples used in each IoT component, check out our service page. What special considerations do you make for Connectivity in your IIoT implementations? Sound off in the comments below.