AWS IoT Services

Devices & Things

In a nutshell

Devices or sensors are the hardware in the factory.
A device, a node, or a sensor, it means a hardware component with communication capabilities, such as microcontrollers with sensors.

Things are the logical representation of these sensors / hardware in the cloud.

IoT things are entries in the AWS IoT Device Registry.

Each thing should have unique name and set of attributes.
Things are attached to IoT certificates, typically, an X5091.
- The certificate material goes inside the device.
- For the sake of a security best practice, each of those certificates should be unique per device.
- You can register existing certificates, or have AWS IoT generate and register new certificates for you.
- Can do some API calls to manually provision a thing.
  - Such as create-thing, create-certificate-from-csr, create-policy, attach-policy, and attach-thing-principal. $\longrightarrow$ Can add the certificate material to the device.
  - Industrial IoT needs to operate things at scale. So, instead of doing manual-API-calls-for-everything provisioning, there are more sophisticated ways to do all this through bulk actions.
A thing + the corresponding Certificate for it $\longrightarrow$ ready to attach an IoT Policy (AWS IoT Certificates are associated with an IoT Policy).
All this communicates with the device gateway.

IIoT Architecture

IIoT_Architecture
Industrial Internet of Things (IIoT) is an evolution of a Distributed Control System (DCS) that customers can use to achieve a higher degree of automation by using cloud computing to refine and optimize the process controls.

PLCs

PLCs: Programmable logic controllers, used to control and manipulate the devices and sensors to make decisions around the environment.

OPC-UA Server

OPC-UA Server: Open Platform Communication Unified Architecture.
It is a machine-to-a-machine (M2M) Communication Protocol for industrial automation developed by the OPC Foundation.
The OPC-UA server is the Component that serves as a Platform-Independent Architecture that integrates all the functionality of the existing specifications.

Sensors, PLCs, and devices may connect up to an OPC-UA server, which standardizes the protocol and aggregates the data from all the sensors into one place.
The protocol coming from the PLCs and devices may be one of many, such as OPC-DA or Modbus. But the server will convert it to the standard protocol, OPC-UA.

SCADA & MES

For the layer to extract, convert, and send data to the cloud. There’s two main pieces to this layer.

The first is the OPC-UA servers.
- Often provide an interface for SCADA: Supervisory Control And Data Acquisition software.
  - SCADA software processes, distributes, and displays the data coming from PLCs and sensors, and helps factory employees analyze the data so that they can make real-time decisions.
  - It also may interface with a MES: Manufacturing Execution System.
- While SCADA is designed to control the production in real time, MES is designed to track and collect information about each product through all stages of the production process. And they build off of each other. SCADA feeds into MES.
The second is the gateways.
- A gateway is a host that gets information from the sensors and concentrates it before shipping it to somewhere else, which can be the cloud or a data center.
- One of the needs for a gateway is that maybe sensors are communicating using a protocol that is not TCP/IP, or do not have Wi-Fi capabilities due to production cost.
  - For example, if these sensors operate via radio using a 900 megahertz frequency to send their information, the gateway would need to be capable of getting that data coming via radio frequencies, and send it over the internet to the cloud by using TCP/IP.
  - There are many reasons for using radios, from reliability to backwards compatibility.

ISA-95

ISA-95: A standard that has been developed for global manufacturers.
Its entire objective is to create a seamless interface between an enterprise and production control systems, while reducing costs, errors, and risks.
All of this is part of a broader governance structure called ISA-95.

The Industrial IoT principle is usually defined by the idea that all equipments and sensors publish their data to a single namespace, allowing all the factory systems to subscribe to that namespace, instead of being chained to each other.

Microservices

By having a dedicated namespace where everything in the factory connects to, ending up by bringing the concepts of microservices to a factory.

Microservices is a software development term that usually define a different, and more modern way of building software, when compared to monoliths or layered architectures.

AWS IoT Greengrass & AWS IoT SiteWise

AWS_IoT_Greengas_V2
Sample_Smart_Factory_Architecture
AWS IoT Greengrass: Acting as the edge gateway. The broker where do actions at the edge.

AWS IoT Greengrass 2.0 is an open-source software.
This service is built for operating across different platforms, such as X86 and ARM architectures, on different Linux platforms, or as Docker containers.
It requires at least 1 gigahertz of compute and 96 MB of RAM. This service is also qualified on hardwares from different silicon partners.
AWS IoT Greengrass 2.0 supports local data processing, orchestrations, stream analytics, and machine learning on the edge.
Even if there is no cloud connectivity, the intelligent operations on the factory plant can continue.
Greengrass is designed to offer at least 99.9 percent SLA, that is critical for connected factories.
Greengrass has two parts.

First, an edge runtime, that is an open-source software under Apache 2.0 license. This can be installed on the industrial gateways on the factory plant.
Second, a cloud counterpart that helps you manage the edge runtime, along with developing and deploying custom applications from your organization.

Greengrass brings some great features out of the box. Those include

A rich set of prebuilt software components developed by AWS.
Access to local resources, such as serial interfaces or GPIO.
Tools for local software development on your local machine or cloud environment
Advanced features to maintain a large fleet of devices.

Components are software modules that you deploy and run on the edge runtime.
This enables easy creation of complex workflows.

Being modular, the only component that you really need for Greengrass to be up and running is called Nucleus.

You can add prebuilt software components, such as Stream Manager, MQTT Broker, OPC-UA Collector, Log Manager.
You don’t have to worry about understanding device protocols, managing credentials, or interact with external APIs.
Greengrass offers different ways to interface with edge devices or peripherals.
- For example, it supports protocols– such as Modbus, TCU- and RTP-based; MQTT; Ethernet; IP; OPC-UA– out of the box.
- If your use case requires a custom protocol, you can deploy your own custom component as a native process; as serverless functions, such as Lambda; or a container image, to do the decentralization on the edge.

Greengrass offers a prebuilt component called IoT SiteWise OPC-UA Collector that helps collect all these tags from the most common OPC-UA servers.
Once the tags are collected, it can be processed by other Greengrass components as local events.
For example, these tags can be persisted within Greengrass in a local stream analyzed by local processes, or machine learning models.

The OEE results can be displayed on a local dashboard on the plant floor.
And all these operations can continue, even if there is no cloud connectivity (Offline processing, and online connectivity, when available).

When connectivity is available, these tags can also be published directly to cloud through another component or MQTT broker.
The connectivity also helps with over-the-air updates. Let’s say you need to push the latest version of your code or machine learning models onto the edge.
$\longrightarrow$ Filter out noisy data, and publish tags that adds value to the data lake on cloud.

The data has more value when it’s adjacent to more data.

AWS IoT SiteWise: As the data ingestion point and the operational data store.

IIoT Requirements

The mission is to develop an edge solution that can help process the data in near real time, to monitor the current quality, and even predict the upcoming ones based on data, or OPC-UA tags, collected from different sensors, actuators, associated with the production lines.

AWS IoT Core

AWS IoT Core is a managed service that allows you to connect and manage fleet, allowing secure connections, with the ability to process and act upon device data.
Read and Set device states at any time.
Work with device gateways.
Use message brokers to securely transmit and receive messages among all things.
Features that AWS IoT Core offers:

AWS IoT Registry: The catalog for all the things, regardless of their types and how we connect to the service.
- It also supports metadata that describes the capability of a device.
Device Gateway: Serves as the entry point for IoT devices connecting to AWS.
It is the component responsible for managing all active device connections, while implementing security for multiple protocols.
Device gateway supports the most-used connectivity protocols in the industry, such as MQTT, WebSockets, and HTTP protocols.
Can configure encrypted endpoints, even use own domain names, with SSL certificates issued by AWS Certificate Manager, or ACM.
Rules Engine: AWS IoT rules are the main gears to reroute messages and perform tasks, allowing interactions between devices and multiple AWS services. For example:
- Use the rules engine to write data received from a device to an Amazon DynamoDB table.
- Use the rules engine for other things, such as put messages on SQS queues, run AWS Lambda functions to extract data, save files to Amazon S3, start the execution of AWS Step Functions state machines.
- Interact with AWS IoT SiteWise.
- Security features offered by AWS IoT Core:
  - Device Management for fleet management.
  - Device Defender for security.
  - A suite of services for data analytics.

AWS IoT Sitewise

SiteWise is a managed service that helps to understand and improve processes in a single industrial site, or across multiple facilities.
With SiteWise, industrial engineers can group sensor data streams by production line, and group production lines into facilities.
Plant managers or business analysts in the corporate headquarter can then easily query sensor data across all facilities, and track various business KPIs.
SiteWise even allows you to import the existing hierarchy of assets in the factory so you don’t have to reinvent the wheel.
And thereafter, an engineer or technician can understand the condition of each production line in a factory–or multiple–remotely, and dispatch the right resources to fix an issue much faster.
This leaves the engineers more time to focus on their core job of understanding and designing better systems, instead of coordinating operational issues in the field.

Similar to Greengrass, SiteWise also has two components.

One, edge software builds on top of Greengrass and is referred to as SiteWise Edge. That makes it easy to collect, organize, process, and monitor equipment data on premises.
Two, its cloud counterpart, IoT SiteWise, a service that enables industrial enterprises to model, collect, store, organize, and visualize thousands of sensor data streams across multiple industrial facilities.

In addition, since SiteWise supports OPC-UA protocol natively, there is no need for translating the tags or asset hierarchy into a different format.
You can create virtual representations of your industrial equipment or processes using assets in AWS IoT SiteWise.
Thus, it helps industrial engineers to skip months of efforts in developing undifferentiated data collection and cataloging solutions.
Instead, you can focus on building intelligence on top of your data to detect and fix equipment issues, spot inefficiencies, and improve production output.

How SiteWise Edge is different from Greengrass software?
SiteWise Edge is actually built on top of Greengrass, and expands on the hardware support from third-party industrial gateways and computers to other AWS services, such as AWS Outposts, or AWS Snow Family computer devices.

SiteWise Edge can also retain data locally for up to 30 days if the hardware resources permit, which can be crucial for your factory. This is often easier for industrial customers to get started with a packaged gateway solution, over starting from the scratch with Greengrass gateway, and configuring industry-specific capabilities such as with OPC-UA Modbus, et cetera.

SiteWise also offers the APIs and mechanisms to manage asset models for edge and cloud. This helps engineers, like you, to quickly compute metrics– such as overall equipment effectiveness, or OEE; mean time between failures, or MTBF; mean time to resolution, or MTTR– from equipment state, quality count, and throughput data, with or without cloud connectivity.

SiteWise provides ability to create a no-code fully managed web applications, using SiteWise Monitor for visualizing and interacting with operational data from industrial devices and equipment. You can view the asset data in near real time. You can even visualize computer data using statistical aggregates– such as average, sum, and count, and more– over a set of time intervals.

This auto-computed aggregates are stored in a time series data store, can be exported to a data lake, such as Amazon S3, and can be queried by custom applications.

If an organization is using a popular third-party visualization tool, such as Grafana. You can hook those dashboards to Grafana.

Models

A schematic representation of your asset