Supporting IoT Interoperability via Open Standards€¦ · 13/8/2019 · Supporting IoT...
Transcript of Supporting IoT Interoperability via Open Standards€¦ · 13/8/2019 · Supporting IoT...
Supporting IoT Interoperability via Open Standards
Conexxus Strategy Conference, 13 Aug 2019Michael McCool: Intel Principal Engineer / W3C WoT WG Co-chair
Supporting IoT Interoperability via Open Standards
Conexxus Strategy Conference, Aug 2019Michael McCool: Intel Principal Engineer / W3C WoT WG Co-chair
Outline
• The Role of Open Standards in IoT– Business justification for IoT standards– Use cases
• The W3C Web of Things (WoT) Standards Work– Building Blocks– Key deliverable: Thing Description– Planned work: Profiles, Thing Directory
• The Future of Open Standards– Standards landscape for data and edge computing– Gaps and opportunities– Roadmap: where do we go from here?
Role of Open Standards in IoT
Business Justification• Why Standards?
– Standards support interoperability of products from multiple vendors.▪ Multiple sources for standardized products reduces risk.▪ Competition reduces cost.
– Standards support portability and scalability▪ Vendors can develop products and services that can be used in multiple markets.
– 40% of IoT use cases require integration of services from multiple verticals▪ McKinsey: The Value of Digitizing the Physical World
– Investing in closed systems is a business risk▪ Machina Research: Smart Cities Could Waste $341 Billion by 2025 on Non-standardized IoT Deployments
• Why Open Standards?– Free access to standards documents– Royalty-free– Wide participation
Use Case: Connected Car Charging
• EcoG provides PaaS support for custom fast EV charging
• Can link charging access and pricing to retail activity
Image provided under Creative Commons Attribution-Share Alike 3.0 Unported License by BP63Vincent
Use Case: Mozilla WebThings Gateway
• Mozilla provides a WoT gateway hub which bridges several other IoT standards to WoT
• Devices are interconnected locally, enhancing privacy
Use Case: AI-Enabled Security
• AI appliance provides person identification service
• Other Things provide motion detection and image capture services
• Orchestration system discovers sensors and AI service and connects then to trigger alarms when person identified in interdicted zones.
Other Retail Use Cases…
• Inventory monitoring and order management
• Automated checkout
• Security and access control
• Employee monitoring for hygiene management
• Customer reward programs tied to activity
• Loitering alerts
• Foot traffic monitoring and analysis
• Parking access control and guidance
• Smart signage and targeted marketing
• Refrigeration monitoring, including lifecycle tracking during shipment
Use Case: Smart Factory Digital Twins
• Provide bridge between IT and OT systems
• Manage data and control in local cloud and predict performance with digital twins.
EtherCAT
RS-485
MonitorServices
Integration: System Architecture
11
Device
DirectThing-to-Thing
Interaction
Existing Device
ComplementExisting Devices
DeviceWeb Browser
Web Integration
serverclientserver server
Integration and Orchestration
Remote access and Synchronization
client
Gateway
client
gateway
Cloud
client
proxy
Connected Car
server
Goal of Standards
Goal of Standards
Interoperability
Goal of Standards
Interoperability
“I can plug it in and it just works.”
Goal of Standards
Interoperability
“I can plug it in and it just works.”
In other words: standards help to automate or streamline an integration process so the user does not have to think about it.
Goal of Standards
Interoperability
“I can plug it in and it just works.”
To define: “I”, “plug”, “it” and “works”
What is “Interoperability”?
Ingestion Interoperability: Connect Data Sources to Data Stores
• Normalize data using common semantics upon data ingestion.
Transfer Interoperability: Connect Multiple Stacks
• Exchange data between vertical silos.
Mesh Interoperability: Connect Devices and Services
• Communication and control among distributed devices and services
Application Interoperability: Deploy Code across a Distributed System
• Manage applications running in portable and secure contexts.
Interoperability: Technical RequirementsP
rio
rity Requirement
Type
InteractionAbstraction
DataInterpretation
DiscoveryMechanism
ApplicationEnvironment
1 Ingestion Description Data Model
2 Transfer Description Data Model
3 Mesh Description Data ModelIntroduction,Directory
4 ApplicationAPIs and/orDescription
Data ModelIntroduction,Directory
Management, APIs,Runtime
W3C WoT Standards Work
W3C Web of Things – Building Blocks
21
Any IoT Device
Protocol Bindings
Data Model
Events
Properties
Actions
Interaction ModelThe index.html for Things
JSON-LD representation format to
describe Thing instances with metadata.
Uses formal interaction model and
domain-specific vocabularies to
uniformly describe how to use Things,
which enables semantic interoperability.
WoT Thing Description (TD)
Standardized JavaScript object API for
an IoT runtime system similar to the
Web browser. Provides an interface
between applications and Things to
simplify IoT application development
and enable portable apps across
vendors, devices, edge, and cloud.
WoT Scripting API
Common Runtime
Scripting API
Application Script
Capture how the formal Interaction
Model is mapped to concrete protocol
operations (e.g., CoAP) and platform
features (e.g., OCF). These templates
are re-used by concrete TDs.
WoT Binding Templates
…
HTTP
MQTTCoAP
Security Guidelines
WoT Architecture
Overarching umbrella with architectural constraints and guidance on how to use and combine building blocks.
Published Candidate Recommendations
• WoT Thing Description (TD){"@context": [
"https://www.w3.org/2019/wot/td/v1",{ "iot": "http://iotschema.org/" }
],"id": "urn:dev:org:32473:1234567890","name": "MyLEDThing","description": "RGB LED torchiere","@type": ["Thing", "iot:Light"],"securityDefinitions": ["default": {
"scheme": "bearer„}],"security": ["default"],"properties": {
"brightness": {"@type": ["iot:Brightness"],"type": "integer","minimum": 0,"maximum": 100,"forms": [ ... ]
}},"actions": {
"fadeIn": {...
Door = Thing
Handle = Affordance
What? How?
Open
Pull
Turn
• WoT Architecture– Constraints
▪ Things must have TD (W3C WoT)
▪ Must use hypermedia controls (general WoT)– URIs
– Standard set of methods
– Media Types
– Interaction Affordances
▪ Metadata of a Thing that shows and describes the possible choices (what) to Consumers, thereby suggesting howConsumers may interact with the Thing
Published WG Notes
• WoT Security and Privacy Guidelines– Details beyond the security considerations
in each specification for a holistic security and privacy configuration of Things
– Security testing plan
• WoT Binding Templates– Documentation for how to describe
existing IoT ecosystems (e.g., OCF or generic Web) with WoT Thing Description
• WoT Scripting API– Proposal for a standard API to consume
and produce WoT Thing Descriptions
– Provides interface between applications and network-facing API of IoT devices(cf. Web browser APIs)
– Documents learnings from the design process
Status and Recent Developments• Decision to adopt JSON-LD 1.1 proposed features to allow:
– Default values
– Object notation (name: value) instead of arrays
– Alignment with common JSON practices
• Security metadata– Focus on HTTPS (Basic Auth, Digest, Tokens, OAuth2)
• Protocol Bindings– Focus on HTTP and structured payloads compatible with JSON
– Support for Events also using subprotocols (e.g., long polling in HTTP)
• Extension Points– CoAP(S), MQTT(S), and further security schemes (e.g., ACE)
– Semantic annotations with custom vocabularies (JSON-LD @context and @type)
WoT Next Steps: Proposals1.1 Maintenance
• TD Security schemes
– Oauth2 flows
– PoP tokens
– ACE?
• TD Link Relation types
– TD hierarchies
– IANA?
• TD vocabulary
– Producer
– Full JSON Schema
– TD Default Values
• Refactoring
– Readability etc.
– Update WoT Archuse cases
– More examples
1.1 Improvements
• “Profile” for Plug&Play– TD default values
without override– Limit URI schemes,
media types, etc.
• Implementation View Spec– “Web Thing API”-like– Specify details such as
error responses, common features, etc.
➢ Could representthe “Profile”
• Complex Interactions– Monitor, cancel Actions– Action/Event queues– Error recovery➢ Hypermedia responses
• Observe Defaults– Method / subprotocol
• Protocol Vocabulary– CoAP(S)
(including CoAPS+WS)
28
2.0 New Items
• IG output
• Discovery
– Peer-to-peer
1.1~2.0 Tentative
• Privacy-preserving lifecycle and identity management
• Thing Templates
• Discovery
– Directory
• Protocol Vocabulary
– MQTT(S)(including MQTT+WS)
W3C WoT Resources
• W3C WoT Wiki– https://www.w3.org/WoT/IG/wiki
(IG/WG organizational information)
• W3C WoT Interest Group– https://www.w3.org/2016/07/wot-ig-charter.html
(charter)– https://lists.w3.org/Archives/Public/public-wot-ig/
(mailing list)– https://github.com/w3c/wot
(technical proposals)
• W3C WoT Working Group– https://www.w3.org/2016/12/wot-wg-2016.html
(charter)– https://www.w3.org/WoT/WG/
(dashboard)
• W3C WoT Candidate Recommendations– https://www.w3.org/TR/wot-architecture/– https://www.w3.org/TR/wot-thing-description/
• W3C WoT Working Drafts / Group Notes– https://www.w3.org/TR/wot-binding-templates/– https://www.w3.org/TR/wot-scripting-api/– https://www.w3.org/TR/wot-security/
• W3C WoT Editors’ Drafts and Issue Tracker– https://github.com/w3c/wot-architecture/– https://github.com/w3c/wot-thing-description/– https://github.com/w3c/wot-binding-templates/– https://github.com/w3c/wot-scripting-api/– https://github.com/w3c/wot-security/
• Reference Implementation: node-wot– https://github.com/eclipse/thingweb.node-wot
Future of Open Standards in IoT
WARNING
“It’s hard to make predictions, especially about the future.”
IoT Standards Map: Data – Now
32
Discovery Ingestion Exchange Modeling Consumption
Descriptions Encoding Protocols Semantics Query
RAML
W3C: WoT Thing Descriptions
W3C: RDF/JSON-LD
SQL
IETF: JSON
IETF: CBOR
IETF: HTTPW3C: HTML
W3C: XML
JSON Schema
iot.schema.org
ETSI: NGSI-LD
W3C: RDF Schema/SHACL
IETF: CoAP
OMG: DDS
IETF: IP/TCP/UDP
Oasis: MQTT
Oasis: AMQP
Haystack
W3C: SSN
W3C: OWLOGS: O&M
IETF: COINYAML
IETF: YANG
W3C: SPARQL
IETF: ICN
Oasis: TOSCA/UDDI
Oasis: SAML
OneDM
OCF: oneiota
Zigbee
LwM2M/IPSO
ZWave
OneM2M
OPC-UA: XML Schema
LF: Swagger/OpenAPI
Microsoft: DTDL/DCL
OneDM: SDF
IoT Standards Map: Data – Goal
33
Discovery Ingestion Exchange Modeling Consumption
Descriptions Encoding Protocols Semantics Query
W3C: RDF/JSON-LD
SQL
IETF: HTTPW3C: HTML
W3C: RDF Schema/SHACL
IETF: CoAP
OMG: DDS
IETF: IP/TCP/UDP
Oasis: MQTT
Oasis: AMQP
W3C: OWL
IETF: COIN
IETF: YANG
W3C: SPARQL
IETF: ICN
W3C: Data Schema
Structured Linked Data
IETF: JSON
IETF: CBOR
W3C: XML
IETF: YAML
W3C: JSON-LD 1.1
W3C/ISO:
IoT Semantics
W3C: Resource Descriptions
OPC-UA: W3C Data Schema
IoT Standards Convergence: Data
34
2019 2020 2021 2022 2023 2024 2025
De
sc
rip
tio
nD
ata
Mo
de
l Se
ma
nti
cs
Sc
he
ma
W3C: Resource
DescriptionsLF: OpenAPI
W3C: WoT TD
W3C: OpenAPI
IETF: YAMLW3C: XML
IETF: JSONIETF: CBOR
Structured Linked Data
W3C: JSON-LD 1.1
W3C: IoT Semantics
W3C: Data SchemaJSON Schema
OPC-UA: XML Schema
One Data
Model
OneM2MLwM2M/IPSO
ZWaveZigbee
OCF: oneiota
ETSI: NGSI-LDW3C: SSN
iot.schema.orgHaystack
OGS: O&MDescription:
• Metadata such as
location, security,
identification, owner,
support information,
relations
• Network interface plus
Data Models for each
possible communication
Data Model:
• Schema describes
structure of data
• Semantics describes
meaning of data.
W3C: WoT TD 1.1
IoT Standards Map: Compute - Now
35
Discovery Edge Computing Security
Introduction Exploration Stacks Components Mechanisms
IETF: ICN
Oasis: TOSCA/UDDI
Oasis: SAML
W3C: HTTPS Local
IETF: DTLS
IETF: TLS
IETF: OAuth2
IETF: PSK
Kubernetes
LF: EdgeX
LF: Akraino
Eclipse: Edge Stack(s)
Starling X
OPNFV
ONAP
IIC/OpenFog Ref Arch
AWS IoT
IETF: Resource DirsIETF: mDNS
IETF: DNS-SD
Bluetooth Ads
OCF: UPnP
SSDP
QR Codes
IETF: DHCP
Docker
IETF: SFC
Ubuntu: Snaps
NFC
Azure IoT Hub
AWS Greengrass
NIST Security Baseline
Interledger
SCONE (isolation)
AWS Lambda
Azure IoT Edge
Hyperledger
W3C: Web Payments
FiWare (ETSI: NGSI) Node.js
ECMAScript
OCP: Open Containers
CoreOS: Rocket
Docker Swarm
CoreOS Tectonic
Apache Mesos
RedHat OpenShift
LandscapeIntel: Clear Linux/ECS
IETF: Web Authn/FIDO
Kata (sandbox)
IoT Standards Map: Compute - Goal
36
Discovery Edge Computing Security
Introduction Exploration Stacks Components Mechanisms
X as a Service
W3C: HTTPS Local
IETF: DTLS
IETF: TLS
IETF: OAuth2
IETF: PSK
W3C: Edge Apps
ISO/IEEE: Ref Arch
AWS IoT/Edge
W3C: Service/Thing
DirectoriesIETF: URL-based
Introductions
Azure IoT/Edge NIST Security Baseline
W3C: Interledger
W3C: Dist. Ledgers
W3C: Web PaymentsECMA: Node.js
ECMAScriptGoogle IoT/Edge
Secure Accelerated
Containers
System Management
Service
AI Inference
AI TrainingW3C: Web Authn/FIDO
IoT Standards Convergence: Compute
37
2019 2020 2021 2022 2023 2024 2025
Dis
co
ve
ry Ex
plo
rati
on
Intr
od
uc
tio
n
Ed
ge
Co
mp
uti
ng
AI
Se
cu
rity
La
ng
.
OCF: PnP
IETF: DHCP
IETF: DNS-SD
IETF: mDNSIETF: URL-based
Introductions
W3C/IETF: Service/Thing
DirectoryIETF: ICN
W3C: Thing Description
IETF: Resource Directory Discovery:
• Introduction: provides
just a URL first point of
contact
• Exploration: uses
directory service (or
equivalent) identified by
first point of contact to
retrieve details of
resources
IETF: SSDP
Edge Computing:
• AI: AIaaS, PWA/SW →
Edge Apps, Secure
Accelerated Containers
• Security: HTTPS Local,
Identity (FIDO)
• Language: standardize
Node.js and Python
application environments
IETF: HTTPS W3C/IETF: HTTPS Local
OCP: Docker OCP: Secure Accelerated Containers
Web Authn/FIDO: Identity
Node.js NF: Standard Node.js
W3C: PWA + SW + WebML W3C: Edge Apps (incl. WebML)
nGraph/ONNX AI-as-a-Service
Python ?: Standard Python
Conclusions and Summary
Conclusions• Many current IoT applications tend to be siloed
– Solve a specific problem with a closed, custom implementation
• Open Standards can enhance IoT growth and deployment– Simplifying development and deployment
– Supporting development of modular, extensible systems
– Making it possible to source interchangeable equipment from multiple vendors
• Standardization will unlock scaling and new applications– Across verticals
– Across regions
• Standards support interoperability– But there are many kinds of interoperability…
– Different technical requirements
– Current device-cloud architectures will probably evolve to support more “local” solutions
Contacts
Dr. Michael McCool
Principal Engineer
Intel
Technology Pathfinding
Dr. Matthias Kovatsch
Principal Researcher
Huawei Technologies
Applied Network Technology Lab
https://www.w3.org/WoT/WG/