Skip to content

xhilusius/OSDT-Cookbook

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

14 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Root README

Welcome to the Open-source Digital Twin cookbook!

In this cookbook, we've gathered (and will continue to gather) different tools and systems that can be used to build your own Digital Twin!

General remarks on structure

There are 2 mayor elements:

  • Ingredients: This refers to components (or partial systems even), that can be used to compose a DT system. My sugestion is to make these exclusively external, i.e. if a new tool is developed, this will be placed in its own repository (as is currently the case anyway). This means the purpose of this repo is mainly to serve as a connection point, that helps gather the ingredients and cooks the DT for you (i.e. helps with setup and deployment of separate tools). This means that the ingredients will have a reference to an external tool/system, and itself provides scripts etc to glue it together with the other ingredients (e.g. interfaces, adapters etc).
    • An example could be an adapter for integration with cloud services.
  • Recipes: This is where you go to get system compositions. I.e. here we store the logic that takes the ingredients (which should provide generic adapters itself), and composes them with other ingredients. This can mean docker files, or other constructs. Where the ingredients are self-contained, the recipes show systems that use these ingredients. However, it can do so in multiple ways, which is why a selection procedure here might be really useful (e.g. a tool, or wiki that helps people navigate to the right subdirectory). Possibly, we could create a tool here (or use pipelines), to automatically compose/select the right combination of tools based on a users desires (and what they possibly already have).
    • For example, a user might want a system on 1 device, and for only 1 goal. This can change the tools required, so it can be composed differently.
    • A user could also select options with/without persistant storage, security, visualization etc

Finally there is the Wiki folder (name can be changed). This helps people understand our terminology (it has a dictionary, taxonomy, etc). This is important to maintain, as this is the documentation + ontology (semantics + relations).

2nd Workshop on Next-Gen DT Engineering

Idea: Reconstruct existing project(s), and do the following:

  • Add extra components where possible
  • Remove 1 component, and replace with alternative (see above). This should be easy and possible. If not, then repo is not sufficient.
  • Construct arbitrary DT system. Does not have to have a good function, but should run without issue (using possible combination of components).

About

A repo to hold reusable modules for different implementations that can allow any starting DT enthusiast or researcher get a head-start.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors