+
+
+
+
+
+
+ Eclipse Ditto:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+
+ Eclipse Ditto:
an introduction
+ 05/2021
+agenda
++
-
+
- Motivation +
- Digital Twins +
- Eclipse Ditto +
- Ditto + WoT + +
- Wrap up +
Motivation
++
turn physical devices into services
+IoT
++
connecting things from various domains to the Internet happens
+
+
+ -
+
- on devices +
- on the edge (e.g. gateways) +
- in the back-end (a.k.a. "cloud") +
- near the user (apps, uis) +
IoT solution development
++
-
+
- web and mobile apps need APIs optimized for the web +
- security: control who has access to which aspects +
- choose whether to directly communicate to devices and access last known state +
- integrate with other systems by getting notified about changes/events +
- connect and work with devices at scale +
sounds complicated?
++
let's find out if the Digital Twin pattern can help
+
+ Digital Twins
++
-
+
- digital representation of real physical devices +
- act as broker for communicating with assets + +
- applicable for both industrial and consumer-centric IoT scenarios +
Eclipse Ditto
++
… where IoT devices and their Digital Twins get together
+in context
+
+ 
+
+
+
+
+ Ditto as
Digital Twin
"middleware"
turn device data into APIs
+
+
+ {
+ "thingId": "io.foo:car1",
+ "policyId": "io.foo:car1",
+ "attributes": {
+ "manufacturer": "Foo corp",
+ "productionData": {
+ "serialNo": 4711
+ }
+ },
+ "features": {
+ "temperature": {
+ "properties": {
+ "value": 23.42
+ }
+ }
+ }
+}JSON repr. of a Thing
+
+
+ GET/PUT/DELETE /api/2/things/io.foo:car1
+ /api/2/things/io.foo:car1/thingId
+ /api/2/things/io.foo:car1/policyId
+ /api/2/things/io.foo:car1/attributes
+ /api/2/things/io.foo:car1/attributes/manufacturer
+ /api/2/things/io.foo:car1/attributes/productionData
+ /api/2/things/io.foo:car1/attributes/productionData/serialNo
+
+
+ /api/2/things/io.foo:car1/features
+ /api/2/things/io.foo:car1/features/temperature
+ /api/2/things/io.foo:car1/features/temperature/properties
+ /api/2/things/io.foo:car1/features/temperature/properties/value
+
+
+
+
+modeling thing capabilities
+
+
+ -
+
- by default, thing attributes and feature properties are "schemaless" +
- a feature may be aware of several "definitions" linking to a model +
+ 
+ → docs
+
+
+
+ → docs
+ -
+
- a thing may be aware of one "definition" describing which features it contains,
+ for example:
+
-
+
- a thing definition may link to an Eclipse Vorto InformationModel +
- a feature's definitions may link to several Eclipse Vorto FunctionBlocks +
+
persistence of device state
++
+
+ -
+
- devices are not always connected to the net +
- applications always need to be able to access their data +
- twin vs. live access on API level +
+ 
+ 
+
+
+
+ authorization
++
+
+
+ +
-
+
- Ditto contains a built-in authorization mechanism (Policies) +
- every API call is authorized +
+
+ {
+ "policyId": "io.foo:car1-policy",
+ "entries": {
+ "owner": {
+ "subjects": {
+ "nginx:admin": {
+ "type": "nginx basic auth user"
+ }
+ },
+ "resources": {
+ "thing:/": {
+ "grant": ["READ","WRITE"],
+ "revoke": []
+ },
+ "thing:/features/firmware": {
+ "grant": [],
+ "revoke": ["WRITE"]
+ },
+ "policy:/": {
+ "grant": ["READ","WRITE"],
+ "revoke": []
+ }
+ }
+ }
+ }
+ }search
++
+ 
+
+
+ -
+
- you must not +
- Ditto has you covered +
+
+ GET /api/2/search/things
+ ?filter=like(attributes/manufacturer,"Foo*")GET /api/2/search/things
+ ?filter=and(
+ exists(attributes/manufacturer),
+ gt(features/temperature/properties/value,23.0)
+ )
+ &namespaces=io.foo
+ &option=sort(-_modified,-attributes/manufacturer)
+ &fields=thingId,attributes/manufacturer,_modified
+
+ -
+
- search for arbitrary data with RQL query +
- Ditto again ensures authorization +
- apply field projection over the results +
- don't worry about indexing +
get notified about changes
++
-
+
- notification via various channels: WebSocket, SSE, MQTT (3.1.1 | 5), AMQP (0.9.1 | 1.0), Apache Kafka, HTTP hook +
- server side filtering via RQL (same as in search) +
+
+ var ws = new WebSocket("ws://ditto:ditto@localhost:80/ws/2");
+ws.onopen = function(w) {
+ w.send('START-SEND-EVENTS?filter=gt(features/temperature/properties/value,25)');
+};
+ws.onmessage = function(msg) {
+ console.log('received: ' + msg.data);
+};example of WebSocket browser API
+payload normalization
++
+
+ -
+
- devices send data in various formats +
- Ditto provides structured APIs of things (attributes, features) +
- devices don't need to be aware of Ditto +
+
+
+ 
+
+
+
+
+ -
+
- incoming and outgoing data can be transformed +
nonfunctional
++
+ 
+
+
+
+
+ -
+
- modular architecture of Ditto services +
- horizontal scalability of each Ditto service +
- runtime dependency to MongoDB +
- included monitoring (JVM metrics, roundtrips, MongoDB) +
- codebase written in: Java +
Eclipse Ditto +
+
+ could benefit from each other
++
-
+
- Eclipse Ditto bringing scalable "cloud-ready" digital twin framework to the table +
- Ditto currently lacks modeling things +
- WoT "Thing Models" could be a good fit for feature "definitions" +
- later: WoT TD facade in Ditto? +
Wrap up
++
-
+
- Digital Twins as pattern for simplifying IoT solution development +
- Mission: provide Device-as-a-Service +
- Eclipse Ditto as OpenSource framework for Digital Twins +
+
Links:
+-
+
- Ditto website and documentation +
- GitHub - please give us a star ;) +
- Chatroom to ask more questions +
- Commercial offering incl. free plan +