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

For GR1 controller synthesis, the specification includes various items:

• Safety properties. These are process names that describe bad behaviour with error states. They may have been constructed using the property or ltl_property keyword.
• Assumptions. These are names of assertions that must be boolean formulae (i.e., no temporal operators) expressed in terms of fluents. An assertion A is interpreted by the synthesis procedure as []<>A.
• Liveness. As with assumptions, they are boolean formulae and are interpreted as being preceded by []<>.
• Controllable alphabet. This is the set of events that are controllable by the controller to be synthesised.

The control problem solved is to build an LTS that is deterministic and that when composed with the plant, there are no deadlocks, the plant is never blocked from doing an event that is not controllable, and all traces in the composition satisfy the implication []<> A1 && .. && []<> An -> []<> G1 && .. && Gm where A1, ..., An are assumptions and G1, ..., Gn are liveness goals.

controllerSpec NAME = {
    safety = { COMMA SEPARATED PROCESS NAMES }
    assumption = { COMMA SEPARATED ASSERTION NAMES }
    liveness = { COMMA SEPARATED ASSERTION NAMES }
    controllable = { NAME OF SET OF LABELS }
}

A concrete example:

Plant = (a -> b -> d -> Plant | c -> d -> Plant | e -> AUX), 
AUX = (f -> AUX | g -> Plant).

ltl_property NoB = []!b
fluent FE = <e, {a, b, c, d, f, g}>
fluent FD = <d, {a, b, c, e, f, g}>
fluent FG = <g, {a, b, c, d, e, f}>
assert E = FE
assert D = FD
assert G = FG

controllerSpec Spec = {
	safety = {NoB}
	assumption = {G}
	liveness = {E, D}
	controllable = {a, c, e}
}

controller ||C = (Plant)~{Spec}.

Compatibility

For GR1 specifications, to check if the assumptions are compatible (i.e., the environment can achieve the assumptions for any controller), which is desirable (see Nicolás Roque D'Ippolito, Victor Braberman, Nir Piterman, and Sebastián Uchitel. 2010. Synthesis of live behaviour models. In Proceedings of the eighteenth ACM SIGSOFT international symposium on Foundations of software engineering (FSE '10). Association for Computing Machinery, New York, NY, USA, 77–86. pdf)

checkCompatibility ||Compatible = (Plant)~{Spec}.

Non Blocking

MTSA supports synthesis of controllers that achieve non-blocking control for safety properties. See Daniel Ciolek, Matias Duran, Florencia Zanollo, Nicolas Pazos, Julián Braier, Victor Braberman, Nicolas D'Ippolito, Sebastian Uchitel, On-the-fly informed search of non-blocking directed controllers, Automatica, Volume 147, 2023, 110731, ISSN 0005-1098. pdf.

To do non-blocking synthesis the controller specification must include the keyword nonblocking.

controllerSpec ANonBlockingSpecification = {
    controllable = {c45}
    marking = {c45, u55}
    nonblocking
}

The states that the controller is expected to never block the plant from having the possibility of reaching can be marked in two ways:

• Keyword marking within the controller specification can be used to determine a set of transition labels. A marked state is reached if a transition is taken that has a label in the marking transition label set.

Example = A1,
A1 = (u1 -> A2 | u3 ->A4),
A2 = (u2 -> A1),
A4 = (c ->A5),
A5 = (u4 -> A5 | c -> A6),
A6 = (u2 -> A6).

||Plant = Example.

controllerSpec Goal = {
    controllable = {c}
    marking = {u4}
    nonblocking
}

heuristic ||DirectedController = Plant~{Goal}.

||ControlledPlant = (DirectedController || Plant).

• Keyword liveness followed by a set of assertions can be used to define marked states. Although the syntax is as in GR(1), the interpretation differs. Instead of requiring that every infinite trace of the composite plant, sees the liveness goals infinitely often, it requires that every finite trace can be extended (not necessarily controllably) in the controlled plant to see the liveness goals infinitely often.

Example = A0,
A0 = (a -> A1),
A1 = (c_1 -> Up | u_1 -> Down),
Up = (u_2 -> Up),
Down = (u_3 -> Down).

fluent GoingUp = <u_2, a>
fluent GoingDown = <u_3, a>

assert NeverGonnaGiveYouUp = (!GoingUp && GoingDown)

||Plant = Example.

controllerSpec Goal = {
    liveness = {NeverGonnaGiveYouUp}
    controllable = {c_1}
}

heuristic ||DirectedController = Plant~{Goal}.

Unsupported

The following are unsupported or not yet documented properly

Fluent Activity / Concurrency

These are soft-goal clauses used inside a controllerSpec / controller goal block, telling the heuristic controller synthesiser what to optimise. This functionality is 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.
• 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