<-Metadata Go to ToC Basic API ->
1 Reference Model
Figure 1 depicts the Reference Model of Execution.
Figure 1 – Reference Model of Execution
The Controller executes a Module in one of two models – the exchange and continuous execution – as the Module’s Metadata declares in its Execution field. Table 1 compares them.
Table 1 – The two execution models
| Exchange | Continuous | |
| The User Agent | Gives what it has and names what it wants. | Binds devices to boundary Ports for the life of the Workflow. |
| An AIM runs | At most once per exchange, when it is ready and has been given something. | From Start to Stop, reading its Input Ports when Messages are pending and writing its Output Ports when it has something to write. |
| Completion | When every boundary Output Port asked for is settled. | When the Module is stopped. |
| Loops | Not allowed: in an exchange the AIMs of a loop would wait for each other. | Allowed, with the feedback input declared (Communication). |
| Suited to | Conversation and request-response: each turn an exchange. | Sensing and control, as in a vehicle. |
2 The exchange
The User Agent gives what it has and names what it wants; the Module runs what its inputs permit and returns what was produced.
- An exchange completes. The User Agent does not undertake to give more, so there is nothing to wait for.
- An AIM is ready when each input it is connected to has received its Message of the exchange, or can no longer receive one because every AIM that could produce it has run or will not run. It runs when ready and given something, and is skipped when given nothing. An AIM whose inputs are absent does not run: that is not a deferral.
- A boundary Output Port is settled as soon as it has its Message, or can no longer get one. The exchange is finished for what the User Agent asks.
- A boundary Output Port that produced nothing returns NOT_PRODUCED. The User Agent may see this and act on it, and continues to ask for the Ports it requires.
Over MPAI-MAS, an exchange closes at the first Output read after one or more Input writes: that read runs the Module on the inputs written.
3 Continuous execution
Each AIM runs from Start to Stop. It reads its Input Ports when Messages are pending, and writes its Output Ports when it has something to write. A Module of such AIMs runs without being driven exchange by exchange; the User Agent binds devices to its boundary Ports for the life of the Workflow (Workflow Description).
A Module with a loop runs continuously. For example, in the Environment Sensing Subsystem of MPAI-CAV, Visual Scene Description feeds Basic Environment Description, which feeds the Basic Environment Descriptors of previous instants back to Visual Scene Description.
An AIM that must run at a period, or complete within a deadline, declares Period or Deadline in its Metadata. A Controller that cannot honour them refuses the Module when it is started. A missed Deadline is counted and reported.
4 One executor
An exchange is a special case of continuous execution: Messages written to the boundary, each AIM run once on what it has received, the Outputs read. One executor serves both models, on the same Channels, transports and Port behaviours.
5 Required and optional inputs
An Input Port is required unless its Metadata declares it optional. In an exchange, an AIM runs on what it has received and the optional flag documents the Port. In continuous execution, an AIM waits for its required inputs, and the flag decides whether it runs: Metadata that declares required an input its Module never supplies stops that AIM from running. Metadata must therefore be truthful.
6 No suspension
In neither model is there suspension at the boundary: a Module never waits for a User Agent to supply an input it did not undertake to supply. No function of the Controller API waits for a Module to be supplied with an input.
7 Life cycle and degradation
The Controller starts, pauses, resumes and stops a Module and its AIMs, at every depth of the AIM hierarchy. An AIM is ALIVE, DEGRADED or DEAD. An error on a Channel, the loss of the link to the host of an AIM, an exception thrown by an AIM, a required Port that delivers nothing within its MaxAge, a persistent Deadline miss, or a report by which an AIM says it fell back makes the AIM DEGRADED. What the Controller then does is the Module’s OnDegraded policy (Controller). Anything richer – a fallback, bringing a vehicle to a safe stop – is written into the Module as AIMs, where it can be reviewed with the rest of the Module.
8 Requirements
Table 2 – Requirements of Execution
| # | Requirement |
| EXE-1 | A Controller shall execute a Module in the model its Metadata declares. |
| EXE-2 | In an exchange, an AIM shall run at most once, and only when ready and given something. |
| EXE-3 | A Module whose Topology has a loop shall be executed continuously. |
| EXE-4 | A Controller shall not suspend a Module waiting for an input the User Agent did not undertake to supply. |
| EXE-5 | A Controller that cannot honour a declared Period or Deadline shall refuse the Module when it is started. |
| EXE-6 | In continuous execution, an AIM shall not run until its required inputs are supplied. |
