Workflow: Modelling
In order to create a scenario, the Experiment Designer, Technical Architect, Safety Engineer, etc. need to model the different aspects that are required for the particular scenario.
- The Experiment Designer creates a platform independent model of the scenario:
- the Static View is defined by choosing skill components (i.e. controller, etc.) from the CoSiMA Component Library (CCL) and defining the data-flow between those.
- defining the control-flow for the scenario covers the Dynamic View of the system.
- Next the Technical Architect maps the independent model to a chosen platform:
- W.r.t. the Technology Mapping, a software platform needs to be chosen and configured properly (e.g., Orocos RTT).
- For the execution on a hardware platform (simulation or real one), a robot platform need to be chosen (e.g., KUKA LWR 4+).
- A Simulation Model defines the scenario setup for the simulation.
- Further aspects may be addressed by different experts, such as a Safety Engineer, etc.
The aforementioned steps may be iterated (independently) as necessary to produce a model that is ready for testing in simulation.
Workflow: Testing
Once the model of the scenario is ready, the necessary artifacts are generated to test it in simulation.
- In this case the Orocos Program Script is produced and launched by the Orocos environment together with the Gazebo simulation to start the Experiment Execution of the modeled scenario.
- The recorded data from the experiment simulation needs to be evaluated in an in-depth Analysis to spot flaws in the model and improve those by re-iterating the workflow.
- If the modeled scenario performs as expected in the simulation, it can be deployed and executed in the real hardware platform. This is not yet done in this example.
