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!
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).
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).