Builder - Simulation Development Platform

Tags:

Synopsis

This document describes the simulation execution workflow and Taskfile.yml generation used by the Simulation Development Platform (SDP).

Project folder structure

<project>
├── <project>.dse
├── Makefile
├── <project>.json
├── <project>.yaml
├── simulation.yaml
├── Taskfile.yml
├── .task/
│   └── remote/
│       └── <remote-source>.Taskfile.yml.<hash>.yaml
├── out/
│   ├── cache/
│   ├── downloads/
│   │   ├── <downloaded-files>
│   │   └── models/
│   │       └── <model>/
│   └── sim/
│       ├── data/
│       │   └── simulation.yaml
│       └── model/
│           ├── <model>/
│           │   └── data/
│           └── <model>/
│               ├── data/
│               └── lib/

Source and build files

<project>.dse – Defines the simulation configuration, including models, channels, and referenced resources.
Makefile – Contains build commands to generate specifications and prepare the simulation environment.

Generated specification files

The following files are generated from <project>.dse during the build process:

<project>.json – JSON AST form of the simulation specification
<project>.yaml – YAML AST form of the generated JSON AST
simulation.yaml – Resolved simulation configuration
Taskfile.yml – Task definitions used for build and execution

Output directory (out/)

All contents under out/ are generated and used at build or runtime.
out/cache/ – Internal cache for resolution and build steps.
out/downloads/ – Downloaded artifacts and external resources (e.g., model archives, binaries).
out/sim/ – Simulation runtime directory.

Simulation runtime layout

out/sim/data/ – Contains the generated simulation.yaml used at runtime.
out/sim/model/ – Runtime directories for each model defined in <project>.dse.
<model>/data/ – Model-specific data
<model>/lib/ – Model libraries or binaries (if required)

Task runtime metadata

.task/remote/ – Cached Taskfiles fetched from remote sources during execution.

Simulation Flow

DSE Builder container

Image: ghcr.io/boschglobal/dse-builder:latest

The DSE Builder container is responsible for transforming a .dse simulation definition into simulation.yaml and Taskfile.yml.

It runs the following command-line tools in sequence:

dse-parse2ast <project>.dse <project>.json
dse-ast convert -input <project>.json -output <project>.yaml
dse-ast resolve -input <project>.yaml
dse-ast generate -input <project>.yaml -output .

DSE Report container

Image: ghcr.io/boschglobal/dse-report:latest

The DSE Report container is a containerized simulation validation and reporting tool for Simer-based simulations.

It runs the following command-line tool:

dse-report path/to/simulation

DSE Simer container

Image: ghcr.io/boschglobal/dse-simer:latest

The DSE Simer container provides a containerized runtime environment for executing simulations defined using the DSE framework. It runs simulations based on the resolved simulation.yaml configuration.

It runs the following command-line tool:

simer path/to/simulation -stepsize 0.0005 -endtime 0.04

Taskfile Generation

This section provides a high-level view of the end-to-end Taskfile generation flow.
Starting from the simulation AST, the Builder constructs common tasks, resolves includes, generates model-specific tasks, and assembles the final Taskfile.yml.

Resolve Includes

This stage resolves all Taskfile includes referenced by the simulation configuration.
Includes may originate from the local filesystem or from remote repositories, depending on the uses definition and model characteristics.

Generate Model Tasks

This stage iterates through all stacks and models defined in the simulation.
For each eligible model, the Builder generates model-specific tasks, prepares runtime artifacts, and resolves associated workflows.

Build Model Task

This step determines how an individual model is sourced and prepared.
Models may be copied from local paths or downloaded from remote locations, depending on the model definition.

MCL Type Resolution

This stage evaluates the MCL type to determine the appropriate handling strategy.

  • Lua-based models follow a Lua-specific processing flow
  • Non-Lua models are handled as packaged release artifacts defined in Taskfile.yaml

Lua Model Path Evaluation

For Lua-based models, this step determines whether the model is packaged within an archive or provided as a standalone file, and processes it accordingly.

Parse User Files

This stage processes user-provided files associated with a model.
Files may be sourced locally or downloaded remotely, and are copied or extracted into the model’s runtime directory.

Parse Workflow Uses

This step resolves workflow dependencies referenced by a model.
Workflow artifacts are fetched or copied as required, and the associated workflow actions are executed in the model context.