Key requirements for Interoperable IoT systems

Transcription

1 Key requirements for Interoperable IoT systems Pratul Sharma Technical Marketing Manager, ARM Inc. May/08/2014

2 Agenda Why Interoperability? Open standards for interoperability Data Communication Standards Web Objects Device Management Web Services ARM IoT Solution 2

3 Why Interoperability?

4 IoT market Growth Projections IoT 39% IoT Source: Piper Jaffray

5 Reach Two Scenarios of IoT Market Growth The future Scale Needs Standards Sharing Needs Trust Trust Needs Security Open Data and Objects Smart Everything Sensors & Actuators Networks Risk Applications Mobile internet Internet / broadband M2M SaaS Today Fixed Telephony Networks Mobile Telephony Time

6 Key Elements to Drive IoT Market Growth Interoperability Standards Trust Security New Applications Innovation

7 Growth in the Billions Doesn't come without Standards and Industry Alliances

8 A simple Model of an IoT system Communication Infrastructure User Interface/Application Device Management Sensor, Actuator and ucontroller (nodes) Data For Interoperable IoT system we need standards for 1) Data Communication 2) Device Management 3) Web Objects 4) Web Services

9 Data Communication Standards

10 Communication interfaces in an IoT system IoT Device Comm. Infra. Interface Comm. Infra. App. Interface Communication Infrastructure User Interface/Application Device Management Sensor, Actuator and ucontroller (nodes) Data 1

11 Communication infrastructure and Web app. Interface TLS TLS TLS TLS TLS TLS

12 Communication infrastructure and Constrained Device interface DTLS DTLS DTLS DTLS DTLS DTLS It s a Standard IP interface as constrained devices are not involved Standard IP protocol stack is suitable for communication 1

13 How does CoAP features optimize IoT data communication? Resource discovery New devices (nodes) are discovered automatically. No human intervention needed. Easy to add new devices. Easy to replace the devices. Subscription Push of Information from IoT devices to application. Content Negotiation Data type to be used between the client and the server is settled before the actual data communication. It make it easy to integrate CoAP enabled device in an IoT system. Explicitly indicate the content type of the payload in the header Simple Caching Optimize performance REST oriented REST based web services are based on architecture of the web and more compatible with existing web tools and techniques. It has less overhead, less parsing complexity, statelessness, and tighter integration with HTTP

14 Bandwidth CoAP and optimized security handshakes: 10x reduction in bandwidth Constrained Devices Little Data Internet HTTP 10x reduction in BW CoAP 1

15 1 6LoWPAN : High level overview Standard Internet IOT nodes 6LoWPAN specification 6LoWPAN is adaptation layer for IPV6 Function IPV6 header compression Packet fragmentation and re-assembly Optimized Neighborhood discovery Packet size ~127 bytes Packet size ~ 1280 bytes

16 Why 6LoWPAN? No need for translation gateways or proxies. IP networks allow the use of existing network infrastructure. Very well known and have been proven to work and scale. Open and free standard. Processes and documents available to anyone. Encourages innovation and is better understood by a wider audience. Tools for managing, commissioning and diagnosing IP-based networks already exist. Allows Interoperability on device side.

17 Web Objects

18 IoT Device IoT Device IoT Device IoT Device IoT Device Web objects Service 1 Service 2 Service 3 Service 1 Service 2 Web Object CoAP DTLS / UDP Proprietary CoAP Proprietry CoAP 6LoWPAN Interoperable Services DTLS / UDP 6LoWPAN DTLS / UDP 6LoWPAN Service 1 Service 2 Non-interoperable devices & Services Web Object Web Object In addition to data communication we need standard web objects for Interoperability CoAP DTLS / UDP CoAP DTLS / UDP 6LoWPAN 6LoWPAN Interoperable Devices & Services

19 IPSO Web Objects The IPSO Alliance promotes the Internet Protocol for smart objects. We need semantics to build a Web of Things Web Objects exposes the state and behavior of a device. IPSO defines Web Object guidelines (join us!) 65+ members

20 IPSO Object example: Temperature Sensor Example Temperature sensor: This IPSO object should be used over a temperature sensor to report a remote temperature measurement. It also provides resources for minimum/maximum measured values and the minimum/maximum range that can be measured by the temperature sensor. The unit used here is Celsius degree. Object info Object Object ID Object URN Multiple Instances? IPSO Temperature 303 urn:oma:lwm2m:ext:303 Yes Resource Info Resource Name Resource ID Access Type Multiple Instances? Type Units Descriptions Sensor Value 5700 R No Decimal Cel This resource type returns the Temperature Value in C Min Measured Value 5601 R No Decimal Cel The minimum value measured by the sensor since it is ON Max Measured Value 5602 R No Decimal Cel The maximum value measured by the sensor since it is ON LWM2M Client Accessing the Resources Temperature Value /303/0/5700 Min Measured Value /303/0/5601 Max Measured Value /303/0/5602 /303/ Temperature Value Min Measured Value Max Measured Value Object

21 Device Management

22 Device Management Provisioning Enabling, disabling features Device Management Device Configuration Mobile Device Management Changes to settings Changes to parameters of the device Software Upgrade Update application and system software Bug fixes Fault Management Report Errors from devices Query about status of devices 2

23 Sensinode 2013 OMA Lightweight M2M Efficient Device-Server interface based on open IETF standards Banking class security based on DTLS Standard Device management already defined by OMA Applicable to Cellular, 6LoWPAN, WiFi, Zigbee IP and other IP based on constrained networks Can be combined with other DM offerings. * OMA also define Objects for Device Management

24 Web Services

25 REST Style Web Services We need web applications in an IoT system to configure, control and monitor the sensors and actuators. Web services are required to integrate web applications over the internet protocol backbone. REST is web service architecture style for designing networked applications. REST is not a "standard". Its a set of guidelines/constraints. REST uses simple HTTP/CoAP to make calls between machines rather than using complex mechanisms such as Remote Procedure Call (RPC) or (Simple Object Access Protocol) SOAP. The World Wide Web can be viewed as a REST-based architecture.

26 Open Standard based ARM IoT Solution

27 ARM IoT Products: from Device to Cloud 27

28 ARM Sensinode NanoService Web Application SDK Java SDK and Reference Applications (source code) for rapid development of customer application that controls/monitors IoT nodes NanoService Platform IoT security, communication and data flow platform with OMA Lightweight M2M Server support NanoService Client Enables secure, efficient communication between devices and the NanoService Platform with OMA Lightweight M2M Client support

29 ARM Sensinode NanoMesh NanoRouter IPv6 6LoWPAN to IPv6 border router for both embedded platforms and Linux. NanoStack 6LoWPAN protocol stack for both routing and host devices GHz 6LoWPAN BT 4.0 (LE) 2.4 GHz g Sub-GHz Stack Products ZigBee IP Home Area Network Mesh BT Smart IP 6LoWPAN for BT Smart devices ZigBee IP BT Smart IP ZigBee NAN ZigBee NAN Neighborhood Area Network Mesh G3 PLC For wired smart metering applications

30 Free Online IDE

31 Get started today! mbed.org 1,200,000+ mbed.org unique visitors in ,000+ mbed-enabled development boards shipped 45,000+ Mbed developers 100+ Major OEMs from diverse industries are using mbed

32 Summary The Internet of Things is the next evolution of Web Market growth driven by Standards, Security and Innovation. Interoperability will be the key. CoAP, 6LoWPAN, IPSO objects, OMALWM2M ARM Mbed and Sensinode SW enables the design of future proof and scalable IoT systems. 32