IIoT Overview James Gilbert | April 2017

IIoT – It’s Here

Agenda Who I am What is an IIoT Cloud? Who are the IoT Cloud Providers? Why do we care? Education on different IoT protocols & why MQTT 9/18/2018

What is the Cloud Thingy? 9/18/2018

IIoT Cloud Providers Top Tier Cloud Providers Amazon AWS (complete) Microsoft Azure (in progress) IBM BlueMix (future) AT&T M2X (complete) ThingWorx (PTC) (future) Fusion Connect (Autodesk) ILS (Telit) (complete) Cumulocity (Planned) Telenor (uses Amazon AWS) (complete) Skkynet (complete) LEC IqWebScada & Set-Point IPwebcontrol (complete) 9/18/2018

Related IIoT Cloud Providers How do companies like these fit in? GE Predix Bosch Companies like Inductive Automation with Ignition There are many – who else do you see? 9/18/2018

IIoT Cloud Providers Why a Customer selects one over the other? Offers other key IT services such as storage or Software-as-a-Service (Amazon, Microsoft, IBM) Fits with parent company products (ThingWorx, Fusion Connect, ILS) Relationships (Cumulocity, Telenor, Skkynet, IqWebScada) Analysis and Visualization features Skills with the SI or integration partner Pricing 9/18/2018

IIoT Cloud Challenges Challenges for system integrators or distributors RAM solution designed to make the mapping to cloud data easy but…. Cloud skills are much different than Automation engineer skills Examples Large Automation Co: started with MODBUS but really solved by RAMQTT M2X integration and moving to MQTT Large Texas based oil and gas co. looking at Azure, now asking about AT&T M2X Assess if who is presenting opportunity has identified all of the challenges 9/18/2018

Criteria for IIoT Comparison slide Security 1: none required 2: user name/password 3: strong encryption 4: unique device authentication 5: uses signed certificates Device Registration Easy: automatic Medium: Simple to create on cloud side Difficult: multiple layers to create on cloud side Service type IaaS: basic services provided (e.g. storage, access) PaaS: I can write my own visualization to API or use 3rd party tools SaaS: Provider must write solution to customer requirements Data Visualization None provided must use 3rd party tools Yes: limited: indicates some provided but not extensive Yes: more mature widget library 9/18/2018

Cloud Provider Comparison Data Analysis Data Management Data Visualization Device Management Device Registration Security Strength Ease Of Setup Service Type AT&T M2X Yes Yes supported via MQTT* Easy 4 SaaS Fusion Connect Yes – limited Medium 1 – 2 Difficult Amazon AWS IoT Custom None provided, use 3rd Party tools 5 PaaS/IaaS Microsoft Azure  Yes supported via MQTT*  Medium 4 – 5 PaaS Telenor Possible but requires work from Telenor IQ Web SCADA SixView Manager 3 Package Install Skkynet ILS deviceWise Yes, their own solution Medium* 9/18/2018

Where Does Red Lion Fit? 9/18/2018

IIoT and the Yellow Brick Road 9/18/2018

Understanding the Integration Process Opportunity or Strategic Driven Start with Colin Geis or Steve Gallagher (Business Development) Product Manager engages Engineering Getting a new Provider integrated Questions that impact integration Is there an engaged customer? What is their use case? What documentation is available? How do they connect? Is the platform already supported? 9/18/2018

Understanding the Integration Process Assuming MQTT is supported then: 1st Milestone is Proof of Concept (PoC) for ‘basic functions’ to RLC team 2nd Milestone is PoC to ‘customer’ to validate use case 3rd Milestone (if applicable and approved by PM) is beta package for customer 4th Milestone is released in a official firmware Cloud Integration background info RLC Engineering has to do enough to understand and to validate interface is working correctly in order to implement integration on RAM device Tech notes are in the works for the platforms but should be viewed as simple guidelines 9/18/2018

Understanding the Integration Process What are the basic and advanced functions Basic Functions Device Registration, sending data, receiving data Advanced Functions (not all platforms support this) Device Management functions such as firmware & configuration update Device setup and registration Devices have to be registered Requires account setup on cloud prior to devices can be setup Some platforms (i.e. AT&T M2X) support device auto-registration 9/18/2018

Why Protocols? Advantage of using standard protocols Allows different systems to exchange information in a standard format Confusion on what is ‘standard’ Regardless of protocol the above confusion exists…. ‘Why can’t we just connect’? Use of protocols does make integration ‘easier’ but don’t assume just a plug-n-play 9/18/2018

Protocol - Key terms Publish – Subscribe From Wikipedia: publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead characterize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are. RESTful (Representational state transfer) Interface: A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. Data can be a variety of formats (XML, JSON, HTML) Broker Exactly what you think it is – ‘brokers’ messages between senders and receivers 9/18/2018

Protocol Architectures 9/18/2018

Protocol Comparison Making sense of the alphabet soup AMQP: https://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security.[ MQTT: https://en.wikipedia.org/wiki/MQTT MQTT[1] (MQ Telemetry Transport or Message Queue Telemetry Transport) is an ISO standard (ISO/IEC PRF 20922)[2] publish-subscribe-based "lightweight" messaging protocol for use on top of the TCP/IP protocol. It is designed for connections with remote locations where a "small code footprint" is required or the network bandwidth is limited.  9/18/2018

Protocol Comparison Making sense of alphabet soup (continued) ZeroMQ: https://en.wikipedia.org/wiki/ZeroMQ ZeroMQ (also spelled ØMQ, 0MQ or ZMQ) is a high-performance asynchronous messaging library, aimed at use in distributed or concurrent applications. It provides a message queue, but unlike message-oriented middleware, a ZeroMQ system can run without a dedicated message broker. The library's API is designed to resemble that of Berkeley sockets. DDS: https://en.wikipedia.org/wiki/Data_Distribution_Service The Data Distribution Service for real-time systems (DDS) is an Object Management Group (OMG) machine-to-machine (sometimes called middleware) standard that aims to enable scalable, real-time, dependable, high-performance and interoperable data exchanges using a publish–subscribe pattern. 9/18/2018

Protocol Comparison Making sense of alphabet soup (continued) STOMP: https://en.wikipedia.org/wiki/Streaming_Text_Oriented_Messaging_Protocol Simple (or Streaming) Text Oriented Message Protocol (STOMP), formerly known as TTMP, is a simple text-based protocol, designed for working with message-oriented middleware (MOM). It provides an interoperable wire format that allows STOMP clients to talk with any message broker supporting the protocol. It is thus language-agnostic, meaning a broker developed for one programming language or platform can receive communications from client software developed in another language. Lots of information available - Next slides from article from RTI https://blogs.rti.com/2016/09/12/6-industrial-iot-communication-solutions-which-ones-for-you-comparison/ 9/18/2018

Protocol Comparison 9/18/2018

MQTT Diagram 9/18/2018

Using MQTT – ‘Just connect it’ Using Inductive Automation Ignition – why can’t we just ‘connect’ It is ‘MQTT enabled’! (https://inductiveautomation.com/ignition-iiot) Ignition uses Cirrus Link http://www.cirrus-link.com/oem-device-data-integration/ Sparkplug ‘A’ Payload Definition (https://s3.amazonaws.com/cirrus-link-com/Sparkplug+Topic+Namespace+and+State+ManagementV2.2+Appendix+Payload+A+Format.pdf) (Note: this is a 57 page document) Sparkplug ‘B’ Payload Definition (https://s3.amazonaws.com/cirrus-link-com/Sparkplug+Topic+Namespace+and+State+ManagementV2.1+Apendix++Payload+B+format.pdf) (Note: this is a 67 page document) MQTT-enabled means MQTT is supported if the payload (i.e. data format) matches with their A or B specification: note size of documents! 9/18/2018

More links on IoT Protocols IIoT pricing overview From this link: https://blogs.endjin.com/2016/08/aws-vs-azure-vs-google-cloud-platform-internet-of-things/ AWS Pricing is relatively straight forward with a fee per 1 million messages sent or received (a free low throughput tier is also available). Messages are processed in 512 byte blocks with each block representing a single message up to a maximum 128 KB Other AWS services have additional fees (https://aws.amazon.com/pricing/services/) Azure IoT Hub comes in 4 tiers, ranging from a free tier up to the high throughput S3 tier which can support up to 300,000,000 messages per day. Additional units can be added to each tier for more throughput if required. Messages are sent in 4 KB blocks, each block is counted as a message for billing purposes up to a maximum 512 KB. There are some throttling rules to consider when determining the best tier for your needs. Event Hubs is another option for device-to-cloud scenarios and may be a better solution for basic large scale device telemetry ingestion. Event Hubs can ingest large volumes of messages over AMQP and HTTP. Event Hubs performance is measured in throughput units (TU) where each TU allows 1 MB/S ingress up to 20 TUs, although this can be raised via a support ticket. Pricing is based on the number of ingress events (per million) plus a fee for each throughput unit per hour Take-away from this slide Confusing as heck and I have read many times…… /

More links on IoT Protocols Various articles of interest: http://vasters.com/blog/From-MQTT-to-AMQP-and-back/ https://blogs.vmware.com/vfabric/2013/02/choosing-your-messaging-protocol-amqp-mqtt-or-stomp.html https://blogs.rti.com/2016/09/12/6-industrial-iot-communication-solutions-which-ones-for-you-comparison/ https://www.novotek.com/en/solutions/kepware-communication-platform/iot-gateway-with-rest-and-mqtt-interface https://stackoverflow.com/questions/29897654/opc-ua-protocol-vs-mqtt-protocol 9/18/2018

Closing topics Additional questions you may get: Do you support Node-RED?(https://nodered.org/) Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways. Fancy words for a means to visually connect ‘things’ roughly similar to using ladder logic Do you have a generic implementation of MQTT? Not yet, future, depending on need Likely means the customer is thinking of developing their own… OPC & MQTT – what’s up? OPC-UA is considered an architecture oriented to SCADA whereas MQTT is a stand-alone protocol for exchanging data OPC-UA is a broader set of features and may include protocols such as MQTT 9/18/2018

Remember the ‘machines are watching’ 9/18/2018