What Is OpenSCENARIO

How do you express "set up this situation and test it" in robot simulation? imSim writes scenarios not as code scripts but as a declarative domain-specific language (DSL). The language it chose is the automotive industry standard ASAM OpenSCENARIO — borrowed in an interesting way.

This is the entry point of the OSC series, so it starts from why a language instead of code, moves to what we borrow and what we don't, and ends with how imSim layered its own domain on top.

Why a declarative language (DSL) instead of code

The first question — "why not just write it in Python?" You can. But writing scenarios as imperative code creates problems.

	Imperative code (Python)	Declarative DSL (OpenSCENARIO)
What you write	how, step by step	what (the situation itself)
Who writes it	robot engineers	domain experts too
Reproducibility	must know the whole codebase	one file = the scenario
Review / audit	hard	humans read and review it
Tool compatibility	ad hoc	standard parser/validation ecosystem

The key is — you write "what," not "how." It's the same idea as using SQL instead of a for-loop to work with data. Declare the situation, and the way to run it is the engine's responsibility.

💡 Declarative is what makes it deliverable — if a scenario is a single human-readable file, customers and engineers can reproduce and review the same test in that language alone. Buried in code, it becomes a one-off only we can run.

Borrow the language, build the domain

So do we invent a new language? No — we borrow an existing standard. OpenSCENARIO was made for self-driving-car validation (actions like lane change, headway, overtaking). Those automotive actions don't fit robots or unmanned systems. So imSim takes only OpenSCENARIO's grammar and type system and builds all the actual action behaviors itself.

Rendering diagram…

• ASAM layer — grammar like scenario/serial/parallel/wait/emit and SI-unit types like time/length/speed/angle. Used as-is.
• Execution-engine layer — an engine that compiles the scenario into a Behavior Tree and ticks it (py_trees-based).
• Domain-action layer — spawn robot, inject sensor noise, switch engagement rules, etc. Not a single automotive action of ASAM is used; we built all of them.

What we borrow, and what we don't

Drawing the boundary of this "borrowing" clearly is the heart of the design.

Rendering diagram…

💡 "Standard compatibility + domain freedom" at once — borrow the standard language and you stay compatible with the tool/parser/validation ecosystem (no reinventing the wheel); build the domain actions yourself and you gain freedom in fields like robotics and defense. Getting both is the elegance of this design.

Scenario as Code

The result of this DSL is that the scenario logic lives, declaratively, in one file. Composition, behavior, checks, and verdict are written as human-readable text.

scenario patrol_demo:
    do serial:
        spawn_robots(count: 3, area: zone_a)
        parallel:
            patrol(path: route_a, speed: 1.5mps)
            inject_obstacle(at: 10.0s)
        assert(collisions == 0)
        emit verdict(PASS)

With just this text, anyone reproduces the same scenario exactly — which three robots, where, on what route, and what to verify are all visible.

⚠️ Scenario logic must not leak into code scripts — if half lives in the DSL and half in a separate Python helper, it becomes "demo only." The intent must be captured self-contained in the domain language to be a deliverable structure (the self-containment philosophy).

In a nutshell

📌 A scenario must be written as what (declarative DSL), not how (code), to be reproducible, reviewable, and deliverable. imSim borrows only ASAM OpenSCENARIO's language and SI types (not its automotive actions) and builds its own robot/military domain actions on top — a three-layer DSL that gets "standard compatibility + domain freedom" at once.