ONEM2M INDUSTRY DAY ALAN SOLOWAY, QUALCOMM. 12 July 2017

Size: px

Start display at page:

Download "ONEM2M INDUSTRY DAY ALAN SOLOWAY, QUALCOMM. 12 July 2017"

Sherman Wheeler
5 years ago
Views:

1 ONEM2M INDUSTRY DAY ALAN SOLOWAY, QUALCOMM 12 July 2017

2 Time Isolated Aggregated Massively Connected Cloud / Data Centres Rich Devices / Gateways Constrained Devices The architecture will need to achieve massive scale 2

3 Complexity of Standards Home/Building Manufacturing/ Industry Automation Vehicular/ Transportation Healthcare Energy Cities Wearables Farming/ Agri Food Fragmentation is BAD! 3

4 OCF Driving Consolidation

5 OCF High Level Goals Make it easy for developers to deal with the complexity of IoT comms Provide a common data model that developers can use to interface with all IoT devices and their underlying data Establish an architectural foundation that can achieve the necessary scalability Focus the architecture around interoperability Supports the needs of multiple vertical markets (since many use cases span multiple vertical markets) Provide a path towards future consolidation of standards 5

6 Board of Directors 1 - Cert WG, UPnP WG AllSeen WG all have seats on Technology SC but not Operations Management SC Operations Management Steering Committee Business Steering Committee Technology Steering Committee Certification Work Group UPnP Work Group Strategy WG Core Technology WG Authorised Test Lab TG Liaisons TG Architecture TG Test Tool TG AllSeen Work Group Smart Home Project Healthcare Project Automotive Project CoAP Native Cloud Project JOOE Project (onem2m) Wi-Fi Easy Setup Project BLE-GATT Project Use Case TG Industrial TG Thread TG Marketing WG Press Release TG Branding TG Digital Marketing TG Events TG Asia Marketing Task Force Membership WG Bridging TG Security WG Security Review TG Remote & Bridging Security TG Data Model WG Open Source WG Developer Ecosystem TG Bridging TG Spec Coordination TG UPnP WG 1 Cert WG 1 AllSeen WG 1 6

OCF & IoTivity Specification Data Modelling Open Source

Implementation of OCF (and Non-Spec Related Code)

Membership) Sponsored (funded) by OCF Separate

7 OCF & IoTivity Specification Data Modelling Open Source Coordination Coordination Open Source Project Reference Implementation of OCF (and Non-Spec Related Code) Certification Business (Marketing, Strategy, Membership) Sponsored (funded) by OCF Separate Governance Innovative coordination Specs & Open Source ready simultaneously 7

8 OCF Conceptual Framework Profiles Consumer Enterprise Industrial Auto Education Health Interaction / Data Model Core Framework Discovery Data Transmission Resource Model Data Management Device Management Security, Identity & Permissions Transports (Smart) Remote Access Cloud 8

9 INTEROPERABILITY BETWEEN OCF AND A PARTNER ECOSYSTEM

10 Interoperability Building Blocks Device 1 Applications 1 Service Layer 1 Data Transport 1 Physical Layer 1 System 1 to System 2 Apps 1 to/from Apps 2 Service Layer 1 to Service Layer 2 Transport 1 to Transport 2 Phy 1 to Phy 2 Device 2 Applications 2 Service Layer 2 Data Transport 2 Physical Layer 2 Bridging between ecosystems can happen at any or all of these layers Each bridged layer may be independent of or dependent on other layers 10

11 Interoperability Levels Data Model Translation between ecosystem data models Fundamental data types, device definitions and assigned attributes Data Model representation design patterns Arrays, links, inheritance, hierarchical representations Data Model representation markup language JSON, Swagger2.0, RAML/YAML Service layer Translation of resource models Transport Translation of ecosystem protocol messages The assumption that there is a one-to-one mapping between operations in different ecosystems is not correct in many cases Transport mapping: Addressability, Encoding, Security Logical Execution of operations across ecosystems State machines, Complex operations, Protocol metadata, Security 11

12 Evaluation Steps The primary goal is to determine which levels of interoperability need to be specified by OCF and the Partner Ecosystem Physical Layer This is out of scope of the OCF specifications Transport Layer This is generally out of scope of the OCF specifications OCF assumes IP connectivity and has not addressed the mapping of IP to other ecosystems IP over normally non-ip transport may be addressed in other organizations (e.g. IP over BTMesh) CoAP over non-ip transport may be addressed by OCF if no other industry activity exists (e.g. CoAP over BLE-GATT) Service Layer OCF has created the Bridging Specification to handle the generic interoperability definition between OCF and a Partner Ecosystem Application Layer OCF created Device Specifications and Resource Type Specifications OCF created Mapping Specifications for data mapping between OCF and Partner ecosystems 12

13 Evaluation Steps Data Models Identify device types and resource types (i.e. attributes) defined by Partner System Correlate identified device types and resource types to existing OCF device types and resource types Identify new device types and resource types to be added to OCF specifications For those device types that exist in OCF Correlate resource types between device definitions Add new resource types to the OCF device definition For those device types that do not exist in OCF Create new device definition in OCF specifications Include resource types corresponding to partner device definition In all cases Map fields to existing or newly defined OCF Resource Types Should the Partner Ecosystem desire equivalence with OCF Data Models, similar effort will need to occur to update the Partner Data Models. 13

14 Bridging Concept Data Model OCF Resource Model Derived Model Partner Ecosystem Resource Model Resource Spec Device Spec Bridging Spec Mapping Spec Bidirectional Operation Other Ecosystem Spec 14

15 Bridging Process OCF has created an agnostic online repository where the entire IoT industry can address data model interoperability Any organization can request to be registered Each organization owns their own data models Each organization selects the licensing regime most appropriate to that organization JSON, RAML/YAML and Swagger2.0 are currently supported Interoperability can be supported by creating derived modelling between organizations whose data models reside in oneiota.org Derived modelling frameworks can be generated Interoperability can be supported for a bridge implementation Used to generate documentation, code stubs and user interfaces 15

16 Bridging Process OCF and a Partner organization decide to support a bridge between ecosystems The Partner organization requests registration on oneiota.org The Partner organization enters its data models into oneiota.org OCF creates a derived data model in oneiota.org A member company of either or both organization(s) implements a bridge OCF Plugfests are available to be able to test that bridge device The OCF Certification program is enabled to test the bridge device The Partner organization can also certify the bridge device independently or a joint certification program can be discussed 16

17 Bridging Security Last but NEVER Least The Bridge (between ecosystems) needs to be a trusted entity as it translates at the message payload level The Bridge itself and all Virtual Devices that it exposes must be onboarded (transfer of ownership) and provisioned for secure operation Each Virtual Device must implement the security (including encryption) requirements of the ecosystem to which it is connected Enables selective blocking of communications with specific service endpoints and clients This fine-grained control allows the network administrator to selectively allow communications across the ecosystems which may not have the same security capabilities 17

18 JOINT OCF/ONEM2M ECOSYSTEM (JOOE)

19 JOOE Charter The purpose of this project is to fully define solutions for interworking between OCF and onem2m components in a complementary way and coordinate between the organizations for significant market penetration The overall goal is to create a joint ecosystem larger than the sum of the individual parts that benefits from the strength of both technologies while avoiding significant overlap The work will include specification of technical solutions for interworking, alignment of data models, coordination on work split, joint marketing/communications activities, and business development 19

20 JOOE Conceptual Architecture The two orange boxes in the bridge represent a single operational control point 20

21 QUESTIONS?

22 THANK YOU

Welcome to IoTivity Developer Day. Introduction: Mark Skarpness, Intel VP & Director Embedded Operating Systems

Welcome to IoTivity Developer Day Introduction: Mark Skarpness, Intel VP & Director Embedded Operating Systems 1 IoT Challenges IoT APIs are rarely re-used They are brand-unique Communication methods are