Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
M MTSA
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 35
    • Issues 35
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • lafhis
  • MTSA
  • Wiki
    • Enduser
  • Discrete Event Controller Synthesis

Discrete Event Controller Synthesis · Changes

Page history
Update Discrete Event Controller Synthesis authored Sep 26, 2026 by Sebastian Uchitel's avatar Sebastian Uchitel
Show whitespace changes
Inline Side-by-side
Showing with 70 additions and 3 deletions
+70 -3
  • enduser/Discrete-Event-Controller-Synthesis.md enduser/Discrete-Event-Controller-Synthesis.md +70 -3
  • No files found.
enduser/Discrete-Event-Controller-Synthesis.md
View page @ 7a46b66f
MTSA supports synthesising behaviour models that control a given plant to satisfy a given property. The plant is defined using an FSP composite process, which may be explicitly marked with the `plant` keyword (e.g. `plant ||NAME = (...).`) to designate it as the uncontrolled environment for synthesis. The property is defined using the `controllerSpec` keyword. MTSA supports synthesising behaviour models that control a given plant to satisfy a given property. The plant is defined using an FSP composite process, The property is defined using the `controllerSpec` keyword.
# GR1 # GR1
...@@ -117,7 +117,7 @@ heuristic ||DirectedController = Plant~{Goal}. ...@@ -117,7 +117,7 @@ heuristic ||DirectedController = Plant~{Goal}.
``` ```
# Unsupported # Unsupported
The following are unsupported or not yet documented properly
## Fluent Activity / Concurrency ## Fluent Activity / Concurrency
These are soft-goal clauses used inside a `controllerSpec` / controller goal block, These are soft-goal clauses used inside a `controllerSpec` / controller goal block,
telling the heuristic controller synthesiser what to optimise. This functionality is telling the heuristic controller synthesiser what to optimise. This functionality is
...@@ -126,5 +126,72 @@ experimental and may not be fully functional. ...@@ -126,5 +126,72 @@ experimental and may not be fully functional.
* `concurrencyFluents={...}` — names fluents whose *simultaneous* truth the synthesiser tries to maximise; a non-empty set routes synthesis to a dedicated concurrency-control problem. * `concurrencyFluents={...}` — names fluents whose *simultaneous* truth the synthesiser tries to maximise; a non-empty set routes synthesis to a dedicated concurrency-control problem.
* `activityFluents={...}` — names "activity" fluents the synthesiser tries to keep active; drives the "best controller" heuristic. * `activityFluents={...}` — names "activity" fluents the synthesiser tries to keep active; drives the "best controller" heuristic.
## Controller Synthesis (GR1)
* `controller` (alias: `gr`) — GR1 controller synthesis
* `controllerSpec` — declares a controller goal specification
* `safety` — safety processes within a `controllerSpec`
* `assumption` — liveness assumptions within a `controllerSpec`
* `liveness` — liveness guarantees within a `controllerSpec`
* `controllable` — set of controllable actions
* `checkCompatibility` — checks whether GR1 assumptions are compatible
## To be checked
* `permissive` — permissive controller mode
* `controlled_det` — controlled determinism
* `nonblocking` — non-blocking requirement
* `lazyness` — controller laziness parameter
* `non_transient` — non-transient constraint
* `reachability` — reachability analysis
## DCS / Non-blocking
* `heuristic` — triggers Directed Controller Synthesis
* `marking` — marks states for non-blocking synthesis
* `disturbances` — disturbance specification
* `partialOrderReduction` — enables partial order reduction
* `compositional` — compositional synthesis approach
* `monolithicDirector` — monolithic director synthesis
## RTC Controllers
* `rtc` — Reactive Test Case controller
* `rtcAnalysis` — RTC analysis controller
* `failure` — fault/failure specification
* `test_latency` — test latency specification
* `exceptionHandling` — exception handling
## Updating Controller
* `updatingController` — updating controller problem
* `oldController` — reference to the old controller
* `oldGoal` — old goal specification
* `newGoal` — new goal specification
* `mapping` — state mapping
* `transition` — transition specification
* `graphUpdate` — graph update specification
* `initialState` — initial state in the update graph
* `transitions` — transitions in the update graph
## Control Stack
* `controlstack` — control stack specification
* `tier` — control tier definition
## Exploration
* `exploration` — exploration specification
* `environment` — exploration environment
* `model` — exploration model
* `goal` — exploration goal
* `environment_actions` — environment action set
--- ---
[← End User](End-User) [← End User](End-User)
\ No newline at end of file
Clone repository
  • Developer
  • End User
  • devs
    • outputmessages
  • enduser
    • DCS
    • Discrete Event Controller Synthesis
    • Hello World
    • MTSA Syntax
    • Modal Transition Systems
  • Home