<-Reference Model Go to ToC AI Modules ->

1 Reference Model

Figure 1 depicts the Reference Model of the User Agent.

Figure 1 - Reference Model of the User Agent

Figure 1 – Reference Model of the User Agent

The User Agent implements an Application. Its Workflow interpreter executes the steps of a Workflow. Through the Physical Layer API it asks the Physical Layer, whose Acquisition Units and Delivery Units serve the devices, to obtain data from the real world and to deliver data to it. It drives a Module through the Controller API, records and plays back what crosses the Module’s boundary, and keeps the identity and the session of each client it serves.

2 Functions

The User Agent:

  • decides the sequence of steps of the Application, as its Workflow states;
  • acquires data from the real world and delivers data to it, through the Physical Layer;
  • requests the Controller to start and stop the Module it drives;
  • gives data to the Module’s boundary Input Ports and obtains data from its boundary Output Ports;
  • requests the recording of the Module’s boundary, and plays a record back;
  • brings the devices it drives to a safe state when the Module stops or fails.

3 Components and technologies

Table 1 – Components of the User Agent

Component Function and technology
Workflow What the User Agent does, and in what order, written once against one Module in the Workflow Description Language.
Workflow interpreter Executes a Workflow at run time: offers choices, asks, acquires, presents, branches, loops, runs an App.
Physical Layer Deals with the real world through its Acquisition Units and Delivery Units, as specified in 4.
Record and playback Requests the Controller to record what crosses the Module’s boundary, with its time stamps, into the Private Storage of the Module, which the User Agent reads and cannot write; plays a record back to a Module at its original rate. A Module whose Metadata requires it is recorded from start to stop, whatever the User Agent does.
Identity and sessions One session per client of a Service. What the Module keeps for a session is deleted when the session ends: when the client leaves, or after a period of silence set by the Service.
Controller API client Deals with the Controller: locally, or over MPAI as a Service.

4 Physical Layer

The Physical Layer is the part of the User Agent that deals with the real world. It consists of:

  • Acquisition Units, each taking data from a device – a microphone, a camera, a keyboard, a sensor – and giving it as an Object of a Data Type, with its Qualifier;
  • Delivery Units, each taking an Object and delivering it to a device – a loudspeaker, a screen, an avatar, an actuator.

Acquisition Units and Delivery Units are not AIMs: they belong to the User Agent, not to a Module, and no Controller is involved in them. Like AIMs, they produce and consume Objects with their Qualifiers. An AIM that produces data intended for a person – speech, face descriptors – produces data; delivering it is the Physical Layer’s act. The Physical Layer:

  • acquires what is asked for by a Qualifier, never by a device. Which device serves a Data Type is the Physical Layer’s own matter;
  • where the wanted Qualifier cannot be satisfied, returns an Object with no data and a Qualifier describing what is available. The Workflow may abandon the step or repeat it asking for what is available. Nothing is substituted silently;
  • brings a device that acts on the world to its safe state when asked, whatever it was last told.

The Workflow interpreter reaches the Physical Layer through the Physical Layer API (Table 2).

5 APIs

Table 2 – APIs of the User Agent

API Between Functions
Controller API, User Agent face (Basic API) User Agent and Controller Start, pause, resume and stop the Module; write to and read from its boundary Ports by Data Type and Port Number, with a timeout; reach Storage as its rules allow; record the boundary. Each call returns a named outcome.
Physical Layer API Workflow interpreter and Physical Layer Acquire an Object of a Data Type, stating the Qualifier wanted and, for speech, whether voice activity decides when it ends; present Objects by Data Type; deliver an Object to a device and read what a device produces; bring a device to its safe state; read a record for playback.

6 Requirements

Table 3 – Requirements of the User Agent

# Requirement
UA-1 A User Agent shall give and obtain data identified by Data Type and, where a Data Type recurs at the boundary, by Port Number.
UA-2 A User Agent shall not address an AIM. The AIMs of a Module and the Channels between them are the Controller’s business alone.
UA-3 A User Agent shall name no Module but the one it drives, and that only when requesting the Controller to start it.
UA-4 A User Agent shall not depend on the Metadata of the Module it drives. Its implementer may know the Metadata; the implementation shall not use it.
UA-5 A User Agent shall write to Storage only as the rules of the data allow, and shall not write into the record of a Module’s boundary.
UA-6 A User Agent shall deal with the Controller only through the Controller API.
UA-7 A Physical Layer shall not substitute an Object of another Qualifier for the one asked for.

These requirements ensure that a User Agent works with any conforming Implementation of the Module it drives, however that Implementation is composed.

7 Remote User Agent

A User Agent may run on another machine than the Controller. It is then a remote User Agent: its components, its APIs and the requirements of Table 3 are unchanged, and the Controller API is carried over the network by MPAI-MAS. The main functions of the MPAI-MAS API are: create a Controller Instance; start a Module; send input data to a boundary Input Port; receive output data from a boundary Output Port; terminate the Module; delete the Controller Instance.

<-Reference Model Go to ToC AI Modules ->