Skip to content

MSc

Modelica Notes

Six sessions of annotated Modelica examples that build up model-based control design: plant, controller, monitor, Monte Carlo verification, then synthesising the parameters that still satisfy the requirement.

Sept 2021Distributed systems

Seventeen worked examples from six sessions of a cyber-physical systems course, re-typed and annotated in Italian with a written note per session explaining what each model changes and why.

Sessions
Six, October–November 2020
Methods
Runtime monitors · Monte Carlo · parameter sweeps
Stack
Modelica · OpenModelica · OMPython
Repository
VincenzoImp/modelica-notes
VincenzoImp/modelica-notesAnnotated Modelica examples on discrete-event modelling, control design and requirement verification.Modelica

What it is

Despite the name, almost none of it is physics. The models are discrete-event and control: a traffic light as a clocked state machine, a car whose driver “only presses the accelerator and does not fear death”, a controller replacing that driver, and a monitor that formalises whether the controller got it right.

The arc is what makes the collection worth keeping. Once the monitor exists, a Python driver sweeps every arrival scenario through the compiled model and reports where the controller breaks, and the notes record it breaking: the first version stops for a red light even after it has already crossed the junction, which, as the note says, makes no sense. The fix is a controller that only obeys a light still in front of it.

Then the question turns from correctness to cost. Reading the light continuously is expensive, so the sampling period becomes a variable and a search finds the largest period that still passes every test. The last session goes further: a second monitor adds a conflicting requirement – keep a buffer near half full – and the two are weighted 0.8 to 0.2 so a grid search can optimise against both at once.

What I took from it

One line in the notes has stayed with me longer than the syntax: with a Markov-driven input stream, a badly shaped transition matrix makes overflow unavoidable no matter how good the controller is. The environment, not the controller, decides whether the requirement is satisfiable at all, and finding that out is what the monitor and the sweep are for.