<-Communication Go to ToC Metadata ->

1 Reference Model

Figure 1 depicts the Reference Model of Storage.

Figure 1 - Reference Model of Storage

Figure 1 – Reference Model of Storage

Storage is Communication across time: a datum written by one AIM and read later by another, or by the same AIM, is carried by Storage as a Message is carried by a Channel. Storage is governed as Channels are: the Controller binds every handle, and the writer does not choose what the record says about the write. Table 1 lists the kinds of Storage.

Table 1 – Kinds of Storage

Storage Holds
Private Storage of an AIM Data reachable by that AIM Instance alone.
Private Storage of the Module The data of the Module, reached by its AIMs, by the Controller on its behalf and by the User Agent that drives it, each as the rules of the data allow. It includes the record of the boundary (5).
Shared Storage Data shared by the Modules to which the User Agent gives one location – one Module, or several.

2 Reaching Storage

Storage is direct. The Controller binds each AIM’s Storage handles to the identity of that AIM when it instantiates it, and the AIM then reaches its Storage with no interface to cross. The User Agent, outside the Module, reaches Storage through the Controller API: it initialises a Shared Storage scope, stating its location – one location for several Modules to share it – and naming, where there is one, the Module whose central control governs it. The User Agent says where a scope is; it cannot say what identity a write will carry.

Each write is stamped with the Module, the AIM within it and the time on the Controller’s time base. A Put is atomic per key; ordering between writers is not guaranteed.

A Shared Storage belongs to one Controller and is shared by the AIMs of its Module, including those placed on AIM hosts, through handles the Controller binds. AIMs of Modules run by other Controllers do not access it: data move between Controllers through External Ports (Communication). Encryption of stored data is a matter of the Implementation.

3 Rules

Each datum of the Private Storage of the Module and of Shared Storage is written under rules (Table 2).

Table 2 – Rules of a datum

Rule Meaning
Category The kind of datum, to which the general rules of the central control, if any, apply.
Readers Who may read it: Modules, AIM Instances, the User Agent.
Time How long it is kept: until the Module instance stops; until the session of the User Agent ends; as long as the scope is kept; or within a duration.
Trace Its writer, its stamp, its category and the rule under which it was written. The Trace is written by the Controller, not by the writer.

Without a central control, the writer sets the rules of its datum. In the Private Storage of the Module, a datum for which no reader is named is read by its writer alone; in Shared Storage, by every Module given the location.

With a central control – the AIM the Module’s Metadata names as StorageControl or, for a Shared Storage, the StorageControl of the Module the User Agent names when it initialises the scope – the general rules of each category are those of the central control: who may write, who may read, the longest time. A writer may restrict them for its datum and may not extend them: a write that tries is refused. A restriction applies at once to what was written. The central control reads everything. The central control is an AIM, never the User Agent.

A call the rules do not allow returns NOT_AUTHORISED.

For example, the A-User Storage of MPAI-PGM Autonomous User Architecture requires exactly this: A-User Control, the central control, authorises writers, categories, persistence and readers, and reads everything.

4 Memories

A Memory with strong semantics of its own – AMS Memory in the Autonomous Motion Subsystem of MPAI-CAV, for instance – is an AIM of its Module. It uses Storage and its rules like any other AIM, and its semantics are specified by the Standard that specifies it, not by MPAI-AIF.

5 The record of the boundary

The Controller records what crosses the boundary of a Module – each Message written to a boundary Input Port, each Message a boundary Output Port receives – with its stamp, in the Private Storage of the Module. Its writer is the Controller; its reader is the User Agent, which cannot write into it.

The Controller records at the User Agent’s request, or from Start to Stop where the Module’s Metadata declares Record Always, whatever the User Agent does: a black box exists because the Module requires it. A record never holds the Module back: what cannot be written in time is counted per Port, and the User Agent is told in the Module’s status and at the end of the record. The form of a record is left to the Implementation.

One mechanism serves in operation – what the Module was given and what it did – and in development: the recorded data on which a Module is tested are played back through the User Agent at their original rate (Workflow Description).

6 Access

Access provides the static or slowly changing data a Module needs – domain knowledge, data models, knowledge bases – through MPAI-specified interfaces.

Access differs from Shared Storage in who writes it. The AIMs of a Module write Shared Storage as they run; they only read Access. Its content is written by whoever holds it: a third party that holds the rights to the data and wants to be its only provider, or the User who provides it.

6.1 Sources

Access content is organised in Sources. A Source is a set of items, each identified by a Key, and has a Version that changes whenever its content changes. Each Source has one Writer: the Provider or the User that created it. The Controller lets only the Writer write a Source.

6.2 Reading

The AIMs of a Module read Access through the Controller:

  • MPAI_AIFM_Access_Get(Source, Key) returns an item.
  • MPAI_AIFM_Access_List(Source, Prefix) returns the Keys of a Source that begin with Prefix.
  • MPAI_AIFM_Access_Version(Source) returns the Version of a Source, so that an AIM can tell that its content has changed.

There is no Module API to write Access.

6.3 Updates by a Provider

When the data belongs to a third party, its updates do not pass through the User Agent: the Provider writes Access directly, through the Provider API.

  • MPAI_AIFP_Access_Create(Source) creates a Source, whose Writer the Provider becomes.
  • MPAI_AIFP_Access_Put(Source, Version, Key, Data) writes an item, and MPAI_AIFP_Access_Delete(Source, Version, Key) removes one; Version is the new Version of the Source.

The functions are specified in Basic API (3.9, 4.11.3 and 6). The Controller protects a Source against anyone but its Provider, and the Provider against replay:

  • The Provider opens its link to the Controller with the Trust Protocol over TLS, presenting a credential issued under a Trust Anchor. The Controller admits the link only if the credential is valid and is the one that created the Source.
  • Each item carries Data Exchange Metadata stating the SHA-256 hash of the data, the KeyID of the Provider and its signature. The Controller stores the item only if the KeyID is that of the Writer of the Source, the key is trusted, the hash matches and the signature verifies.
  • Each update states the new Version of the Source. The Controller refuses an update whose Version is not higher than the current one, so that an old item cannot be sent again and a Source cannot be brought back to an earlier state.
  • The Controller records, for each item, who wrote it, when, and with which Version.

AIMs read only items that passed these checks.

6.4 Updates by the User

When the User provides the data, its updates reach Access through the User Agent.

  • MPAI_AIFU_Access_Create(Source) creates a Source, whose Writer the User becomes.
  • MPAI_AIFU_Access_Put(Source, Key, Data) writes an item, and MPAI_AIFU_Access_Delete(Source, Key) removes one, in a Source whose Writer is the User.

Note. How a Provider makes a Source available to a Module – for instance, under a licence – is outside the scope of this Technical Specification.

7 Security

Every read and write passes through a handle the Controller bound, and Storage checks the Grant of the handle at every operation. The handles of a stopped Module are dead. In the Secure Profile, Secure Storage holds keys and Grants and is reached through the Security API (Zero Trust and Profiles).

8 Requirements

Table 3 – Requirements of Storage

# Requirement
STO-1 An AIM shall reach Storage only through the handles the Controller bound to it.
STO-2 Every write shall be stamped by the Controller with the Module, the AIM and the time; the writer shall not supply the stamp.
STO-3 A datum of the Private Storage of the Module or of Shared Storage shall be written under a category, readers and a time, and the Controller shall keep its Trace.
STO-4 A writer shall not extend the general rules of a central control; a write that tries shall be refused.
STO-5 A call the rules do not allow shall return NOT_AUTHORISED.
STO-6 No party but the Controller shall write into the record of a Module’s boundary.
STO-7 A record shall not delay the Module; what it could not write shall be counted and reported.

<-Communication Go to ToC Metadata ->