Michele Albano
28-Aug-17
CiWork 2015
•
•
•
•
•
IoT and Middleware
6LoWPAN
CoAP
MQTT
Arrowhead
• First Industrial Revolution (1781):
– Invention of the (patented) steam engine by James Watt
– Mechanical production
• Second Industrial Revolution / Technological Revolution
(1874):
– Invention of the incandescent light bulb
– Electricity, moving assembly line, division of labour
– Mass Production
• Third Industrial Revolution (1969):
– Invention of the microprocessor
– Electronics, IT
– Automated production
• Fourth Industrial Revolution / Industrie 4.0 /
Digitizing Industry (today)
• Its focus is on:
– Sensing / acting on the environment by means
of Cyber-Physical Systems
– Ubiquitous fruition of information by means of
IoT
– Computation on the Cloud
– Machine learning
IoT
Use of IP
• All devices have an IP address
• Devices are accessible through the
Internet
28-Aug-17
A CISTER Template
• The Industrial Internet of Things (IIoT) is the
use of Internet of Things (IoT) technologies
in the industrial context (e.g.:
manufacturing).
• IIoT incorporates:
– machine and product sensoring
– machine learning and big data technology
crunching sensor data
– machine-to-machine (M2M) communications
and automation technologies on a global scale
28-Aug-17
A CISTER Template
• IIoT has a great potential for:
– quality control
– sustainable and green practices
– supply chain traceability
– overall supply chain efficiency
– user in the loop
28-Aug-17
A CISTER Template
• The Industrial Internet of Things will
transform companies and countries,
opening up a new era of economic
growth and competitiveness.
• A future where the intersection of
people, data and intelligent machines
will have far-reaching impacts on the
productivity, efficiency and operations of
industries around the world.
Accenture, “https://www.accenture.com/us-en/labs-insight-industrial-internetof-things.aspx”
28-Aug-17
A CISTER Template
28-Aug-17
A CISTER Template
NC
(Windows XP)
MANTIS EPC
(Raspberry Pi Linux)
DB
HMI
Data Analysis
(Linux , Play2, Spark)
ETL
Press App
Embedded PLC
API
API
I/O
I/O
API
I/O
Safety
PLC
GUI
Expert System
API
Models
API
ETL
ETL
Data
Web
App
ETL
API
ERP
(LN)
API
ETL
I/O
Model Management
MANTIS Sensors
DB
28-Aug-17
A CISTER Template
•
•
•
•
•
IoT and Middleware
6LoWPAN
CoAP
MQTT
Arrowhead
•
Extensive interoperability
–
–
•
Established security
–
–
•
•
Ping, Traceroute, SNMP, … OpenView, NetManager, Ganglia, …
Transport protocols
–
•
HTTP/HTML/XML/SOAP/REST, Application profiles
Established network management tools
–
•
NAT, load balancing, caching, mobility
Established application level data model and services
–
•
Authentication, access control, and firewall mechanisms
Network design and policy determines access, not the technology
Established naming, addressing, translation, lookup, discovery
Established proxy architectures for higher-level services
–
•
Other wireless embedded 802.15.4 network devices
Devices on any other IP network link (WiFi, Ethernet, GPRS, Serial lines, …)
End-to-end reliability in addition to link reliability
Most “industrial” (wired and wireless) standards support an IP option
IoT (IP) and 802.15.4
802.15.4 has small PDUs
Maximum PHY PDU is 127 bytes
IPv6 header is 40 octets, UDP header is 8 octets
802.15.4 MAC header can be up to 25 octets (null
security) or 25+21=46 octets (AES-CCM-128)
With the 802.15.4 frame size of 127 octets, we have
127-25-40-8 = 54 octets (null security)
127-46-40-8 = 33 octets (AES-CCM-128)
of space left for application data
… and IP datagrams have a typical MTU of 1280
bytes
13
• 6LoWPAN introduces an adaptation layer between the IP stack’s
link and network layers
• The adaptation layer enables efficient transmission of IPv6
datagrams over 802.15.4
ZigBee IP stack diagram
Application
Security
ZigBee SE 2.0
ZigBee IP
stack
Network
Management
(ND, RPL)
TCP
UDP
IPv6
Stack
Security
6lowpan adaptation
802.15.4 MAC
802.15.4 PHY
15
• Introducing the idea of stacked header:
– You only pay for what you use
• This layer provides :
– Header compression
– Fragmentation
– Support for layer-two forwarding
• All header formats are identified using dispatch header
• The mesh header is used to encode the hop limit
• The fragmentation header supports the fragmentation and reassembly of
payloads
• 1)Point to Point Small Packet
• 2)Fragmented Large Packet
• 3)Mesh Transmitted Packet
• Mesh Under Routing
– No IP routing
– Routing within the LoWPAN
• Route Over Routing
– Routing at the IP layer
– Utilizing network-layer capabilities defined by IP
• 6LoWPAN compresses the header reducing
redundancy
• Some information is deducted from underlying link layer
• This achieves an efficient transport of IPv6 headers
and next headers
• In some cases, IPv6 addresses can be deduced from
MAC addresses
• IP payload length can be deduced from L2/L1 length
information
• Traffic Class and Flow Label values are set to zero
• Version field value is IPv6
• Hop limit can be set to predefined values
• Example of header compression
IPv6 base header fields
Version
Traffic Class
Flow Label
Payload
length
Next
header
Hop limit
Source
address
Dest.
address
Potential IPv6 base header
fields to be carried inline
Elided; v6 only
Version
Set to 0
Traffic class
Set to 0
Flow Label
Deduced from link info 6LoWPAN
Maybe compressed
Set to a known value
Deduced from MAC
address or compressed
or uncompressed carried
inline
Payload
length
Next
header
Hop limit
Source
address
Dest.
address

Comprises a Dispatch



Identifies the type of header immediately
following the Dispatch Header.
Similar to a Frame Control field.
It follows a LOWPAN IP Header Compression
(LOWPAN_IPHC) field
• Used with mesh-under routing approach
– Only performed by FFDs
• Hop left field is decremented by one every hop
– Frame is discarded when hop left is 0
• Address fields are unchanged
802.15.4
Header
Mesh
Header
802.15.4
Header
B
A
A
D
Dst
Src
Orig
Final
Data
Mesh
Header
D
C
A
D
Dst
Src
Orig
Final
Originator
A
Final
B
C
D
Data
Application
Application
Transport
Transport
Network (IPv6)
Network (IPv6)
Routing
6LoWPAN Adaptation
6LoWPAN Adaptation
802.15.4 MAC
802.15.4 MAC
802.15.4 PHY
802.15.4 PHY
Mesh-under routing
Route-over routing
• Fragmentation is required when IPv6 payload size
exceeds that of IEEE 802.15.4 payload limit
• All fragments are in units of 8 bytes
(in 8-byte units)
•
•
•
•
•
IoT and Middleware
6LoWPAN
CoAP
MQTT
Arrowhead
•
•
•
•
•
Direct integration Pattern
Gateway Integration Pattern
Cloud Integration Pattern
REST
CoAp
• Some IoT devices have full internet access.
– May provide an HTTP server running over TCP/IP, and
– connect direcly to the internet (WiFi, Ethernet, cellular,
etc).
– may be used to implement a Direct Integration Pattern –
REST on devices.
IoT Device
Client
Thing running an HTPP
server providing a REST
style interface.
Typical use case: The Thing is not battery powered and communicates with low latency
to a local device like a phone.
• Example: Use a phone to communicate via WiFi (with WiFi router) to an HTTP server
on a device. Use web sockets for publish/subscribe.
•
• Some IoT devices do not have full internet access
– May support only Zigbee or Bluetooth or 802.15.4
– We are not sending IP packets to these devices – they
are constrained. This is the Gateway Integration Pattern.
IoT Device
Gateway providing
full REST API
Thing providing access via
non-web protocol.
Client
• Some IoT devices have access to the cloud
and need powerful and scalable cloud
support. This is the Cloud Integration
Pattern.
IoT Device
Gateway providing
full REST API
Thing may or may not use
web protocols, but is able
to communicate with a
gateway in the cloud.
Client
REST API Design Principles
Principle
Implementation
Constrained user interface
HTTP GET, POST, DELETE, PUT
Standard status codes
HTTP codes
Well designed and standard
URI’s
Naming. Well Designed URI’s representing
a resource. Protocol and location.
Identification of resources.
Standard representations
JSON or XML messages
HATEOS
Messages returning pointers or links for
further discovery
Statelessness
Simple request/response required no
conversational state. Easy to scale.
• GET /basement/water/temperature
200 OK
application/text
40.5 F
• GET /basement/water/volume
200 OK
application/text
200 G
HTTP codes reused as
return values.
– A key IoT standard
– Open IETF standard since June 2014
– Based on web standards, easily integrates with HTPP. Is not
simply a compressed version of HTTP.
– Built for small, constrained, imbedded, occasionally sleeping
devices
– Some built-in reliability
– May run over 6LoWPan (IP-like layer over IEEE 802.15.4)
– Use on low power, low bandwidth, lossy networks
– Over UDP or SMS on cellular networks
– DTLS for security
– Asynchronous subscriptions and notifications over UDP
– Built-in resource discovery
– Peer to peer or client server and multi-cast requests
•
•
•
•
•
•
•
Connection oriented and synchronous
TCP 3 way handshake with server
HTTP GET /kitchen/light
HTTP response
TCP 2 way termination
Too much work for simple IoT applications
CoAP does not support all features of HTTP
• Interaction: request/response RESTful similar to HTTP
• Messages: smaller than HTTP, much lower overhead
Example: BLE nodes
• Sensors and actuators on BLE nodes are simply CoAP resources
• To obtain a current temperature, send a GET request
• To turn on/off or toggle LEDs, use a PUT request
IoT Device
Gateway providing
full REST API
Battery powered Thing providing CoAp.
Communication uses UDP over a
PAN protocol, e.g., 6LoWPAN over
IEEE 802.15.4 or Bluetooth Low Energy
Client
–
–
–
–
–
–
–
Has a scheme coap://
Has a well known port.
GET, POST, PUT, DELETE encoded in binary ( 1 == GET)
Block transfer support.
Confirmable messages require an ack with message ID.
Non-confirmable messages do not require an ack.
Example:
CoAP Client
CoAP Server
----> CON {id} GET /basement/light
<---- ACK {id} 200 Content {“status” : “on”}
Confirmable request
Piggy back response
(likely in binary)
CoAP Client
CoAP Server
----> CON {id} GET /basement/light
lost request timeout!!
----> CON {id} GET /basement/light
this time it gets through
<---- ACK {id} 200 Content {“status” : “on”}
The {id} allows us to detect duplicates.
CoAP Client
CoAP Server
----> CON {id} PUT /basement/cleanFloor Token: 0x22 Needs time
<---- ACK {id}
<----- CON {newID} 200 Content /basement/cleanFloor Token: 0x22 Done
---->
ACK {newID}
Token to recognize which request was satisfied
CoAP Client
CoAP Server
----> CON {id} GET /basement/light Observe: 0 Token: 0x22
<---- ACK 200 {id} Observer: 27 Token 0x22
<---- CON 200 Observe: 28 Token: 0x22 {“light” : ”off”}
-----> ACK Token: 0x22
<---- CON 200 Observe: 28 Token: 0x22 {“light” : ”on”}
:
:
etc.
• Implementing by means of REST (POST to register, GET to
discover, PUT to update, DELETE to remove)
• Different (higher level) than service discovery.
• We register a device as web resources using a discovery
service, to find it later on the fly.
• Links are returned (coap:// …… )
– Links may include a rel attribute.
– The rel attribute specifies the relationship between the current
document and the linked document.
• A well known resource can be used to discover other resources.
– Perform a GET on the well known resource. Returned content is a
list of links with REL attributes.
• Resource directories may be used to register services.
•
•
•
•
•
IoT and Middleware
6LoWPAN
CoAP
MQTT
Arrowhead
• A “request” is sent to a server via URL
– Eg.
http://api.example.com/resources/user/10367
21?name=something
• Response is usually text in HTML, XML, or
JSON
• Great if your asking for something
– What about “push”
– Eg. Server wants to tell device to do something
Lightweight
Publish/subscribe
Over TCP/IP
Aimed at remote sensors and control devices
applications
• For communication through low bandwidth,
unreliable or intermittent communications
• Available under a royalty free license
•
•
•
•
Decoupled in space and time.
The clients do not need each others’ IP address and port
(space) and they do not need to be running at the same time
(time).
The broker’s IP and port must be known by clients.
Namespace hierarchy used for topic filtering.
It may be the case that a published message is never
consumed by any subscriber.
Sensor devices publish
messages to topics that
describe the device or
reading attributes
Applications receive
updates to specific topics
A broker retains messages to
reduce network traffic and power,
while increasing reliability when
devices drop out
Servers and storage can
be used to log all
messages in a central
location
•
Topic
– A string identifier of the form
“a/b/c/d/e”, where slashes separate
subtopics
– Clients publish or subscribe to topics
– # is the glob symbol, i.e “a/#” means all
subtopics of “a”
•
Broker
– Server program that receives, buffers,
and send messages based on topic
– Each topic may contain up to 1 message
value at a time, which may be retained
•
Client
– Anything that connects to the MQTT
broker: serial devices, python scripts,
java programs, etc.
– Clients send a unique identifier when
they connect to the broker, e.g. MAC
address
A house publishes information about itself on:
<country>/<region>/<town>/<postcode>/<house>/energyConsumption
<country>/<region>/<town>/<postcode>/<house>/solarEnergy
<country>/<region>/<town>/<postcode>/<house>/alarmState
<country>/<region>/<town>/<postcode>/<house>/alarmState
And subscribes for control commands:
<country>/<region>/<town>/<postcode>/<house>/thermostat/setTemp
• QoS
– Level 0: Deliver message at most once (fire and
forget)
– Level 1: Deliver message at least once
– Level 2: Deliver message exactly once
• Persistent Sessions
– Client can connect to broker with the clean session
flag set false
– Messages are retained even if the client disconnects
– Clients must also maintain messages when broker
disconnects
– Standard does not define how many or how long (until
we run out of resources)
• Message Retention
– Individual messages have a retention flag
– Message is retained indefinitely
• LWT (Last Will & Testament)
– A device can indicate a final
message to send when it
disconnects from the broker
– Often used to set status to “offline”
Cell Phone
client.publish(‘lightSwitch/1’, ‘toggle’)
Broker
‘toggle’
Toggle Switch
WiFi Switch
•
•
MQTT always has a broker
MQTT broker is the only “connection”
– To detect whether device is connected to broker, use status topic
•
MQTT messages are all plain text
– No type information (e.g. double, string, table)
– No meta-data fields (e.g. timestamp, alarm values)
•
A subscriber can subscribe to an absolute topic or can use
wildcards:
–
–
–
–
–
Single-level wildcards “+” can appear anywhere in the topic string
Multi-level wildcards “#” must appear at the end of the string
Wildcards must be next to a separator
Cannot be used wildcards when publishing
For example
•
UK/Hants/Hursley/SO212JN/1/energyConsumption
–
Energy consumption for 1 house in Hursley
•
UK/Hants/Hursley/+/+/energyConsumption
•
UK/Hants/Hursley/SO212JN/#
–
–
Energy consumption for all houses in Hursley
Details of energy consumption, solar and alarm for all houses in SO212JN
•
•
•
The message header for each MQTT command message contains a fixed header
– Fixed length of 2 bytes
Some messages also require a variable header and a payload.
The format for each part of the message header:
— DUP: Duplicate delivery
— QoS: Quality of Service
— RETAIN: RETAIN flag
—This flag is only used on PUBLISH messages. When a client sends a
PUBLISH to a server, if the Retain flag is set (1), the server should hold on to
the message after it has been delivered to the current subscribers.
—This allows new subscribers to instantly receive data with the retained, or
Last Known Good, value.
•
Runs over TCP or TLS.
–
–
•
May use Websockets from
within a browser.
MQTT–SN uses UDP
packets or serial
communication.
As soon as you subscribe
you receive the most
recently published message
•
•
•
•
•
IoT and Middleware
6LoWPAN
CoAP
MQTT
Arrowhead
• Service Oriented Architecture (SOA)
approach supporting local cloud automation
functionalities
• Local Clouds logically contain a set of
application systems
• All interactions are mediated by services,
which are produced / consumed by systems,
which are run on devices
28-Aug-17
A CISTER Template
Services are either
• User Services, providing the application functionalities on each
particular scenario (business logic)
• Core Services, provided by the Arrowhead Framework and satisfying
non-functional requirements (housekeeping)
– At least: Authentication & Authorization (AA) Service for devices,
Registration Service (SD) for devices and services, and Orchestration (O)
Service to look-up for devices/services, and to create more complex
services
AA
SD
O
Offering a user service
Application
system
28-Aug-17
A CISTER Template
• Mandatory services:
– Service Discovery;
– Orchestration;
– Authorization and Authentication
• A set of optional services:
– QoS Manager
– Configuration Manager
– Event handler
• A detailed documentation system
• Several kinds of encryption protocols are
supported
28-Aug-17
A CISTER Template
An Arrowhead-enabled SoS is based on the concept of Local Cloud:
• A bounded set of computational resources used by stakeholders to attain a goal
• Controls security
– Restricts access to authenticated Devices/Systems/Services.
•
Autonomous
– Contains all core services needed to be able to function
Relating QoS to a Local Cloud simplifies QoS monitoring and reduces the QoS
managing complexity.
AA
O
Application
system
Application
system
SD
Arrowhead Local Cloud
Application
system
28-Aug-17
A CISTER Template
28-Aug-17
CiWork 2015