The Internet of Things on AWS – Official Blog

Secondary sensing and actuation for factories using AWS IoT and CloudRail Gateways

Post also contributed by Felix Kollmar, Co-Founder and CEO of CloudRail.

Introduction

Smart Manufacturing applications such as condition monitoring, predictive analytics, and predictive quality require real-time, granular, rich, and easily accessible process data. Manufacturing uses a hierarchical structure of systems, commonly referred to as the ISA-95 automation pyramid. The two lower layers of the pyramid are the Programmable Logic Controllers (PLC), and the real-time automation network, both on the factory floor. PLCs control industrial equipment using software, sensors and actuators connected via input-output interfaces. Data collected from equipment by PLCs enables applications in the upper layers of the pyramid develop smart manufacturing solutions.

Greenfield environments are sites with new automation equipment that provide out-of-box secure connectivity outside the Operations Technology (OT) network. This connectivity allows Information Technology (IT) software applications on-premises and in the cloud to access rich, granular data sets from manufacturing equipment. Facilities that have decades old legacy equipment which may not have process data available, or unlocking data from them involves significant effort to bridge OT and IT networks, are called brownfield environments. In this blog, we discuss overlay solutions using sensors and actuators that make it possible to implement smart manufacturing applications in brownfield environments.

Challenges in brownfield scenarios

Brownfield facilities encounter the following challenges:

  • There are facilities where mechanisms have been built in the past to extract process data from PLCs into local Data Historians or local Andon type applications on the factory floor. For these scenarios, we recommend using the  Industrial Machine Connectivity on AWS Quick Start solution, and third party software such like Ignition from Inductive Automation and KepServerEx from PTC as an intermediary for translation from the myriad of proprietary industrial automation protocols to the OPC UA (IEC 62541) or MQTT protocols. OPC UA is being widely adopted as a standard in the manufacturing domain.
  • There are facilities where extraction of data from PLCs may be impractical for a variety of reasons. Existing PLCs might be operating in a legacy environment where the risk of re-programming the PLC to unlock data from the field network outweighs the benefit of data extraction. Or, a PLC in operation might not support the required communication interfaces. Often facilities have PLCs from several vendors, further complicating data access.
  • Similar challenges exist for configuration and control of PLCs. A challenge with brownfield environments is that OT personnel is often concerned about making networking changes to legacy environments from a security perspective, and a secondary sensing mechanism can overcome that.

In this blog, we propose sensing and actuation solutions for customers with brownfield facilities, by using secondary sensing. Secondary sensing is a non-invasive way to add edge gateways and sensors to an existing production site to enable more data collection which can be used to improve operational efficiencies and productivity without impacting production downtime.

Solution overview

We recommend two secondary sensing and actuation solutions:

  1. In order to avoid re-programming and impacting the real-time operations controlled by a PLC, deploy an edge gateway running AWS IoT Greengrass and the AWS IoT SiteWise connector in the facility to directly tap into an existing real-time network of sensors. This will provide the mechanism for the edge gateway to extract data from the industrial automation system and exchange data with the AWS Cloud by creating additional data sources.
  2. Deploy a new set of sensors and actuators connected to an edge gateway running AWS IoT Greengrass and the AWS IoT SiteWise connector on the factory floor using a completely separate field network. As in the previous scenario, the edge gateway will exchange data with the AWS Cloud by creating an additional secondary communication channel.

The two approaches discussed above can be implemented together or separately. Both solutions use key AWS IoT services such as AWS IoT Greengrass, AWS IoT SiteWise, and AWS IoT Core.

Building blocks for accelerating Industry 4.0

By ingesting process data at the edge and leveraging a large set of services in the AWS Cloud, applications can be developed to provide sophisticated insights for various operational and business stakeholders.

Edge Ingestion: This block provides an interface for ingestion of sensor readings, PLC tag data and Historian data, as well as for command and control with the edge gateway running AWS IoT Greengrass.

Edge Processing: This provides a variety of capability such as conversion from various industrial protocols to a standard. Various types of data processing can include dead-banding (filtering out irrelevant fluctuations in tag readings), downsampling (reducing the frequency of collection of data that does not change rapidly). Other capabilities at the edge include data buffering (to avoid loss when cloud connectivity is unreliable), local data storage, local ML Inferencing (object detection and image classification). This block also ensures secure communication with the OT network on one hand, and the cloud on the other.

Cloud Ingestion: AWS Cloud ingestion endpoints can be AWS IoT Core for sensor data, AWS IoT SiteWise (for PLC/Historian data points, Amazon Kinesis (for streaming data and video), Amazon S3 (for any generic data upload). These data ingestion endpoints in the AWS cloud facilitate the creation of a Data Lake. Data in the data lake can be cleansing, contextualized, transformed and enriched using AWS analytics services (AWS Glue, Amazon Athena, Amazon EMR, etc) to create datasets that can be visualized using tools such as Amazon QuickSight.

Cloud Processing: Here, data is accessed from the Data Lake to perform analytics, generate and train AI/ML models, run inferencing & data visualization using AWS services such as AWS Glue, Amazon Athena, Amazon Redshift, Amazon SageMaker, Amazon QuickSight. ML models trained in the cloud can also be deployed to AWS IoT Greengrass running on the edge gateway for local inferencing. Additional custom applications can be developed for various user personas.

Selecting an AWS IoT-qualified edge gateway

AWS provides many qualified third party hardware options for customers to choose from to implement a secondary sensing solution on their factory floor. The choices can be found in the AWS Partner Device Catalog. It is important that you pick a gateway device that is qualified for AWS IoT Greengrass for AWS connectivity, and provides the physical interfaces required for communication with the sensors and actuators. They can be analog serial based protocols such as RS232/RS422/RS485 for Modbus RTU/ASCII variants, CAN Bus, USB, or digital protocols such as EthernetIP or Modbus TCP.

In the remainder of this blog, we will dive deep into a solution that we have assembled and tested using a AWS IoT Greengrass-qualified edge gateway device from CloudRail.

The CloudRail edge gateway connects with both AWS IoT Core and AWS IoT SiteWise services in the cloud and optionally runs AWS IoT Greengrass for data preprocessing. Within a factory environment, CloudRail has developed a secondary sensor and actuator architecture primarily around the IO-Link field protocol, and cloud connectivity using an Ethernet interface. The box is DIN rail mountable and provides Ingress Protection (IP 20) suitable for a factory environment.

IO-Link (see FAQs) is a PLC standard (IEC 61131-9:2013 Programmable controllers – Part 9: Single-drop digital communication interface for small sensors and actuators (SDCI)) for a serial communication protocol that allows three types of data to be exchanged – process data, service data, and events.

IO-Link uses point-to-point connectivity between a IO-Link Master device and sensors rather than a message bus topology. Multiple IO Masters can be connected to the CloudRail gateway box via an Ethernet connection. This allows a single gateway to support sensors and actuators across longer runs within a factory floor. Hundreds of IO-Link based sensors and actuators are supported by vendors such as IFM, Turck, Sick, Pepperl+Fuchs, or Balluff . The CloudRail solution also supports Digital I/O (0-24V) sensors as well as Analog (4-20mA) sensors using an Analog to IO-Link Adapter. A design guide can be found at IO-Link Design Guide.

Sensing solution architecture using an AWS IoT-qualified edge gateway from CloudRail

The four scenarios depicted in the diagram allow customers the flexibility to choose the best data ingest mechanism based on their use case.

  1. Proxying sensor data to AWS IoT Core with local processing using AWS Lambda on AWS IoT Greengrass: Data from sensors enters the CloudRail gateway through an IO-Link Master device. Protocol conversion from IO-Link to MQTT is performed by custom logic at ingress to the edge gateway and the payload is transmitted to the AWS IoT Greengrass MQTT Broker in order to invoke a Lambda function. The Lambda function performs user defined custom logic and forwards the resulting data to IoT Core through a secure internet connection on the gateway.
  2. Proxying sensor data to AWS IoT Core without local processing: Data from sensors enters the CloudRail gateway through a IO-Link Master. Protocol conversion from IO-Link to MQTT is performed by custom logic at ingress and the payload is transmitted to AWS IoT Core through a secure internet connection on the gateway.
  3. Proxying sensor data to AWS IoT SiteWise without local processing: Data from sensors enters the CloudRail gateway through a IO-Link Master. Protocol conversion from IO-Link to AWS IoT SiteWise format is performed by custom logic at ingress and the payload is transmitted to AWS IoT SiteWise using the BatchPutAPI through a secure internet connection on the gateway.
  4. Proxying OPC UA tag data to AWS IoT SiteWise without local processing: The CloudRail box has implemented an OPC UA client that can connect to an OPC UA Server to ingest PLC Tag Data from PLCs that support translation from a multitude to automation protocols to OPC UA. By connecting securely with the OPC UA Server, PLC tag data can be ingested into the CloudRail gateway, and transmitted to AWS IoT SiteWise using the BatchPutAPI through a secure internet connection on the gateway.

Actuation solution architecture using an AWS IoT-qualified edge gateway from CloudRail

The three actuator scenarios depicted in the diagram are as follows:

  1. Configuration and command from an end application from AWS IoT Core via AWS IoT Greengrass: Configuration and command messages issued from the end application enters the CloudRail gateway through a secure MQTT connection between AWS IoT Core and AWS IoT Greengrass Core. A subscription can be configured on AWS IoT Greengrass Core such that the MQTT message landing on a topic can invoke a Lambda function. The Lambda function could implement some conditional logic and message forwarding to the IO-Link protocol converter. Protocol conversion from MQTT to IO-Link is performed here and the payload is transmitted to the actuator via the IO-Link Master.
  2. Configuration and command from an end application from AWS IoT Core to IO-Link without local AWS IoT Greengrass processing: Configuration and command messages issued from the end application enters the CloudRail gateway through a secure MQTT connection between IoT Core and a MQTT Broker coexisting with the IO-Link protocol converter. Protocol conversion from MQTT to IO-Link is performed here along with any conditional logic before the payload is transmitted to the actuator via the IO-Link Master.
  3. Configuration and command from an end application from AWS IoT Core to OPC-UA server without local AWS IoT Greengrass processing: Configuration and command messages issued from the end application enters the CloudRail gateway through a secure MQTT connection between IoT Core and a MQTT Broker coexisting with OPC UA Client. Protocol conversion from MQTT to OPC UA is performed here along with any conditional logic before the payload is transmitted to the OPC UA Server. The OPC UA Server then performs the configuration update or command on the target PLC.

Setting up the CloudRail solution with AWS IoT

CloudRail works with over 12,000 compatible industrial sensors supporting the IO-Link standard. These include digital sensors as well as analog ones that can be connected using an IO-Link adaptor. Sensors are connected to IO-modules, which talk to the CloudRail gateway via Ethernet. While the CloudRail gateway needs to be enclosed in an IP20-rated cabinet, the IO-modules are IP67-rated and can be mounted directly on the machine. One CloudRail gateway can be simultaneously connected with hundreds of IO-modules at the same time.

Example Scenario:

In the following example, we have a RFID reader, an IO-Link Hub, a CloudRail gateway, and all the necessary connectors cables. You can find these components in the AWS Partner Device Catalog. We connect the RFID reader to AWS using CloudRail, and receive RFID tag data as a stream of MQTT messages in AWS IoT Core.

  • We first connect the RFID Reader as the sensor to the gateway via the IO-Link hub as shown in the diagram below. Upon power up, the CloudRail gateway automatically detects all connected IO-modules and sensors.

  • We then log in to the CloudRail management portal at https://devices.cloudrail.com/login and create an account if it has not already been created before. The RFID reader will appear in the list of discovered devices.

  • Next, we select AWS IoT Core and name the sensor. CloudRail supports multiple AWS IoT services. We can choose between a direct connection to AWS IoT Core or AWS IoT SiteWise, or can connect the sensor to a local AWS IoT Greengrass instance running on the CloudRail gateway.

  • CloudRail will automatically add and configures sensors as new devices in the AWS IoT Core through an API, retrieve the necessary certificates and configures the local MQTT client. All this happens automatically in the background. We are provided an auto-generated MQTT topic as well as the data schema documentation.

  • At this point the sensor is connected to AWS IoT Core and starts sending data to AWS IoT Core in an automatically generated JSON format. This allows the developers to immediately start building applications using the sensor data as is without needing to do any data transformation.

Conclusion

Secondary sensing and actuation is a non-invasive way to add secondary sensors such as temperature, vibration, pressure, flow, RFID, cameras, etc. to an existing production site to enable more data collection. With the CloudRail secondary sensing solution, you can implement common industrial IoT (IIoT) use cases such as asset condition monitoring, predictive maintenance and predictive quality on AWS in a matter of days and not months and years without making the solution expensive. Try it yourself. Get started with secondary sensing and actuation in manufacturing plants with AWS IoT and CloudRail.

About the authors and additional resources

Rajiv Singhal is a Senior IoT Specialist Solutions Architect at Amazon Web Services (AWS) with a focus on Smart Manufacturing vertical and Industrial IoT solutions. Prior to AWS, Rajiv has worked as a technologist in the San Francisco Bay Area for both startups and large companies building IoT products and solutions for Smart Buildings, Utilities, Energy Optimization, Connected Vehicles and EV charging.

Ryan Dsouza is a Senior Solution Architect for Industrial IoT at Amazon Web Services (AWS). Based in New York City, Ryan helps customers architect, develop and operate scalable and highly innovative solutions using the depth and breadth of AWS platform capabilities to deliver measurable business outcomes.

Felix Kollmar is one of the founders and CEO of CloudRail. He studied telecommunications engineering in Mannheim and went through several leadership positions, especially in young technology companies in the cloud and IoT industry. With CloudRail, he creates important bridges between IT and OT and is considered a thought leader of the IIoT.

Additional resources to learn more:

AWS for Industrial Internet of Things: https://thinkwithwp.com/iot/solutions/industrial-iot/
AWS for Industrial: https://thinkwithwp.com/industrial/
AWS IoT: https://thinkwithwp.com/iot/
Machine Learning on AWS: https://thinkwithwp.com/machine-learning/
Setting-up CloudRail with AWS IoT SiteWise:
https://devices.CloudRail.com/documentation?service=AWSIoTSitewise#awsiotsitewise1
Setting-up CloudRail with AWS IoT Core: https://devices.CloudRail.com/documentation?service=AWS#aws1