28
IIoT Overview James Gilbert | April 2017

IIoT Overview - redlion.net Sales Meeting - Day 2... · IIoT Cloud Providers • Top Tier Cloud Providers – Amazon AWS (complete) – Microsoft Azure (in progress) – IBM BlueMix

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

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

4/20/2017 3

What is the Cloud Thingy?

4/20/2017 4

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)

4/20/2017 5

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?

4/20/2017 6

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

4/20/2017 7

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

4/20/2017 8

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

4/20/2017 9

• 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

Cloud Provider Comparison

4/20/2017 10

Data

Analysis Data

Management Data

Visualization Device Management Device

Registration Security Strength

Ease Of

Setup Service

Type

AT&T M2X Yes Yes Yes Yes supported via MQTT* Easy 4 Easy SaaS Fusion

Connect Yes Yes Yes – limited Yes supported via MQTT* Medium 1 – 2 Difficult SaaS

Amazon AWS

IoT Custom Yes

None provided,

use 3rd Party

tools Yes supported via MQTT* Difficult 5 Difficult PaaS/IaaS

Microsoft

Azure Custom Yes

None provided,

use 3rd Party

tools Yes supported via MQTT* Medium 4 – 5 Difficult PaaS

Telenor Yes Yes Yes – limited Possible but requires work

from Telenor Difficult 5 Easy SaaS

IQ Web

SCADA Yes Yes Yes SixView Manager Easy 3 Package Install SaaS

Skkynet Yes Yes Yes SixView Manager Easy 4 Package Install SaaS

ILS deviceWise Yes Yes Yes Yes, their own solution Medium* 4 Package Install SaaS

Where Does Red Lion Fit?

4/20/2017 11

IIoT and the Yellow Brick Road

4/20/2017 12

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?

4/20/2017 13

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

4/20/2017 14

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

4/20/2017 15

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

4/20/2017 16

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

4/20/2017 17

Protocol Architectures

4/20/2017 18

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.

4/20/2017 19

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.

4/20/2017 20

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/

4/20/2017 21

Protocol Comparison

4/20/2017 22

MQTT Diagram

4/20/2017 23

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!

4/20/2017 24

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……

• /

25

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

4/20/2017 26

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

4/20/2017 27

Remember the ‘machines are watching’

4/20/2017 28