Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
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
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 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
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