Towards a Flexible Evolution of Digital Twins with Fluent APIs
•Download as PPTX, PDF•
0 likes•5 views
This document discusses approaches for flexibly evolving digital twins. It presents three decisions for handling changes to a digital twin schema: migrate data to new properties, version properties to support multiple schemas simultaneously, or drop unused properties. It demonstrates how a fluent interface can implement these decisions, updating a CO2 sensor digital twin in response to changing its schema. Maintaining consistency while evolving digital twins and handling historical data are challenges it aims to address.
Recommended
More Related Content
Similar to Towards a Flexible Evolution of Digital Twins with Fluent APIs
Similar to Towards a Flexible Evolution of Digital Twins with Fluent APIs (20)
More from Daniel Lehner
More from Daniel Lehner (13)
Recently uploaded
Recently uploaded (20)
Towards a Flexible Evolution of Digital Twins with Fluent APIs
- 1. Christian Doppler Laboratory for Model-Integrated Smart Production Institute of Business Informatics – Software Engineering Johannes Kepler University Linz Altenberger Straße 69, Science Park 3 4040 Linz Christian Doppler Laboratory for Model-Integrated Smart Production CDL-MINT Towards Flexible Evolution of Digital Twins with Fluent APIs Daniel Lehner, Antonio Garmendia, Manuel Wimmer
- 2. Motivation 2 https://github.com/derlehner/DigitalTwin_Airquality_For_Covid_Risk_Assessment/ Physical Twin Digital Twin Applications Snapshot Historical Data <<Instance>> Room101: Room <<Instance>> S1:CO2 Sensor <<Instance>> S2:TempSensor <<Instance>> S3:HumSensor <<Instance>> C1:Controller Prediction Service Simulation Service Visualization App get_data Room101: Room temp. CO2 10:05 temp. 37 10:05 CO2 800 10:06 hum. 0.7 <<Instance>> LED1: Alarm change_color hum. How to ensure consistency after an update? What to do with historical data?
- 3. Problem 3 <<conformsTo>> Decision B: Version Decision A: Migrate <<Slot>> co2 <<Instance>> S1: CO2Sensor <<Instance>> S1: CO2Sensor <<Slot>> co2 <<Slot>> co2Value Timestamp Value 10:01 600 ppm 10:02 620 ppm 10:05 650 ppm TimeStamp Value 10:05 650 ppm TimeStamp Value 10:01 600 ppm 10:02 620 ppm Decision C: Drop <<Slot>> co2 <<Instance>> S1: CO2Sensor Timestamp Value 10:05 650 ppm Evolved Schema Initial Schema <<Type>> CO2Sensor <<Property>> co2Value Initial Instance <<conformsTo>> <<Instance>> S1: CO2Sensor <<Slot>> co2Value TimeStamp Value 10:01 600 ppm 10:02 620 ppm Change <<Type>> CO2Sensor <<VersionedProperty>> co2Value <<Property>> co2
- 4. Demonstration of Fluent Interface 4 Decision B: Version Decision A: Migrate <<Slot>> co2 <<Instance>> S1: CO2Sensor <<Instance>> S1: CO2Sensor <<Slot>> co2 <<Slot>> co2Value Decision C: Drop <<Slot>> co2 <<Instance>> S1: CO2Sensor Type - createProperty(name: String) - versionProperty(name: String) - migrateData(sourceProperty: String, targetProperty: String) - dropProperty(name: String) CO2Sensor.createProperty(‚co2‘) .versionProperty(‚co2Value‘) .migrateData(‚co2Value‘, ‚co2‘); CO2Sensor.createProperty(‚co2‘) .versionProperty(‚co2Value‘); CO2Sensor.createProperty(‚co2‘) .versionProperty(‚co2Value‘) .dropProperty(‚co2Value‘); <<Type>> CO2Sensor instanceOf <<Property>> CO2 <<VersionedProperty>> CO2Value
- 5. CDL-MINT https://cdl-mint.se.jku.at/ Christian Doppler Laboratory for Model-Integrated Smart Production CDL-MINT Thank You! Comments? Questions? Feedback? Daniel Lehner daniel.lehner@jku.at http://github.com/derlehner Use Case https://github.com/derlehner/DigitalTwin_Airquality_For_Covid_Risk_Assessment/