21 June 2022


Ari_Keranen, Christian_Glomb, Cristiano_Aguzzi, David_Ezell, Erich_Barnstedt, Jack_Dickinson, Kaz_Ashimura, Kunihiko_Toumura, Matthias_Kovatsch, Michael_Koster, Michael_McCool, Philipp_Blum, Sebastian_Kaebisch, Tetsushi_Matsuda

Meeting minutes

<kaz> W3C Patent Policy 2020 for the WoT IG

Digital Twins Definition Language

Erich's slides

Erich: DTDL is a Microsoft private invention, not a standard
… initial conversations with digital twin consortium, in the process to standardize and create an ecosystem
… some companies use it for products. Microsoft uses it.
… devices can be preregistered and predefined - when a device is connecting to the cloud they can be discovered and used right away
… as Microsoft developed Azure digital twins we needed to model devices and relations between assets, people, places and things
… needed a hierarchy
… We also wanted to create a developer API to be used - described in a separate spec
… topology representation is very similar to property graphs
… we have extension points for 3D models, physics and more
… digital twin service has a query interface - enables rich queries on topology graph
… we can attach external compute to do calculation on property changes
… we created a few domain specific ontologies, e.g. Wind parks, smart grids, factory use, Platform I4.0 administration shell
… once vocabulary and ontology are available, you can create a property grah and queries
… other use case is plug and play for IoT devices
… following a similar approach with limited vocabulary, descriptions can be distributed and used
… we have some open source models available
… when model is defined, you can create instances
… DTDL distinguishes between types and instances
… we open-sourced DTDL spec and a parser
… we try to build an ecosystem and help interested parties to get started
… target to get adoption through consortia and open source initiatives
… DTDL metamodel is RDF based, we are programming language agnostic
… using JSON-LD
… The API spec is implemented by digital twin service, published and can be used by others
… can be used for uploading DTDL ontologies, usual CRUD operations and a query API
… integrates with time-series store
… other services that use DTDL or plug&play device are IoTHub and IoT Central
… we have a way to export and import DTDL
… Simple DTDL example: an interface with a property, telemetry for temperature (time series) and a command
… currently version 2 has been published, we are working on version 3. Versions are backwards compatible

McCool: do you have events?

Erich: mapped to a property and you can have property updates - or mapped to a telemetry

Sebastian: q on domain ontolgies: are they public? how are they bound to DTDL? Can they be used independently

Erich: they are published on github, are tightly coupled, search for dtdl ontologies on github
… energy distribution, smart cities, real estate
… we have others as well, e.g. one for wind parks that is maintained by the digital twin consortium
… there are typically using/referencing other standards

Cristiano: we can map commands to WoT actions - what are the assumptions? Do you support sync and async actions?

Erich: you can do both - some systems use sync, others use async

<kaz> Azure Digital Twins Documentation

<kaz> DTDL GitHub repo

Erich: components are basically instances
… relationships between instances
… inheritance and semantic types
… (shows an example of complex types)
… like a struct in C
… a schema for a complex type for rotation (roll, pitch, yaw)
… most OPC-UA types in companion specs are complex types
… we need it for mapping

McCool: we are talking with spatioal data on the web and OGC

Erich: there's a need for it, also for arrays
… you need several types to be bundled

Kaz: we are talking with IEC as well, try to achieve a global standard for IoT vocabulary definition

Erich: IEC would be good, we also talk with OASIS
… we start with a coalition of the willing, it is a precursor to standard
… need an ecosystem and critical mass for adoption
… we decided to wait for critical mass

Sebastian: is this type definition based on an existing standard, or defined specifically for DTDL

Erich: we do not rely on JSON schema

Erich: units are an important concept, we define a bunch of them and add new ones as needed
… they help to interpret the data and visualize
… we have inheritance concept - very similar to programming languages
… we have a base class and extend it

Lagally: multi inheritance? namespaces?

Erich: no multi inheritance - top level namespace

Erich: tools: DTDL parser, can be used for validation
… we heavily invest in digital twin explorer, can be used to interact with the model, run queries
… you can display the twin graph, read properties
… (example from digital twin consortium)
… model of an automotive production line
… several MES, a simulation
… 8 production lines, 3 stations each with telemetry

<kaz> Twin Consortium - ManufacturingDTDLOntologies Manufacturing Ontologies

Erich: we integrate with OPC-UA, this is a better integration concept than mapping
… (shows a dashboard with predictions and anomalies)
… OEE - Operational effectiveness calculation based on the simulation
… we can query the model and get the twin graph and caluclate the OEE for each production line and get the overall OEE

Lagally: the query language - standard or proprietary?

Erich: proprietary, similar to SQL, called KQL, open sourced
… customers can use their query language and we can do a mapping to it
… I can select a MES node and display the properties
… You can create a new twin using the UI and connect it to the existing model via relationships

Christian: can we have an example of a federated query, e.g. give me all rooms with a certain temperature and ...

Erich: this is basically a join

Christian: do you access 2 dbs for that, time series and metadata?

Erich: we use a single database Kosmos DB, you can do a join to put different queries together

Christian: precondition that temperature values are time series

Erich: yes

Kaz: did you already talk with ** about automotive ontologies

Erich: rather than interacting with partners 1:1, we started with manufacturing onologies.

Kaz: we are planning to organize a breakout session in TPAC on collaborations on that, would like to invite you to that

McCool: next steps?

Sebastian: we have a similar concept in the thing description - do you think DTDL version 3 will be aligned?

Erich: 3.0 is already almost complete, we work with customers already
… we can align in the future - start this conversation now, define a mapping, identify gaps

McCool: short term goal is to aim for interop

Erich: if customers come with a TD we could have a tool for automatic mapping
… I created a similar tool for OPC-UA, > 1Mio downloads
… mapping is not losless
… we could create a new tool that does something similar

McCool: goals for TPAC, come out with input for our new charter
… we should focus on that. We will do breaking changes in 2.0 version.
… There's more opportunity to align with your version 4.0

Erich: we could use an existing task force to try out a mapping

McCool: this could be a project - we could target a plug fest
… currently we are working on the release

Lagally: we could benefit from input from Microsoft in the profile TF

McCool: we should schedule one call befor TPAC to plan for plugfest / TPAC
… should have a follow up call

Erich: I just sent the deck via email

McCool: we can use this call slot in 3-4 weeks for a follow-up.

Kaz: japanese guys work on integration of DTDL and WoT, this could be in a plugfest

<kaz> [adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).