A new channel between industry and standards

A new channel between industry and standards

The challenges of MPAI standardisation

Moving Picture, Audio and Data Coding by Artificial Intelligence (MPAI) is a standards organisation with the mission to develop data coding standards that have Artificial Intelligence as its core enabling technology.

MPAI faces two main challenges to achieve its missions. The first comes from MPAI’s definition of “data”: any digital representation of a real or computer-generated entity. As any living being, or human organisation generates data, and they are more and more pervasive, the scope of MPAI standards is definitely very broad. The second comes from MPAI’s definition of data coding as the transformation of data in one representation into another representation that is more convenient. As convenience is in the eye of the beholder, the number of transformations, hence standards, is potentially large.

Unlike audio and video coding, whose needs were clear from day one and whose application domains have incrementally extended over the years, data coding is a much more articulated domain where the simple one-dimensional (compression) world of audio and video coding morphs to a world where the dimensions are potentially many.

This is not a late discovery. The challenges were clear when the MPAI Statutes were drafted. The standard development workflow described in Annex 1 to the Statutes envisages the involvement of any party interested in the process of identifying projects of standard. This is very different from what happens, e.g. in ISO, where the process of definition of a standard happen in watertight compartments where only committee members or National Bodies can propose standard projects. The logic behind is that standards project are weapons in the hands of those who control the committees and you do not want to give up your weapons easily.

The MPAI standardisation process

MPAI has no weapons because its mission is to serve the industry. MPAI has a mission which it implements as follows

  1. MPAI solicits proposals of new projects in the form of use cases from anybody, collects and harmonises use cases in a structured proposal of a project and defines a comprehensive use case that is likely to be usable across industries.
  2. Then MPAI develops functional requirements. Note that in the first two stages of the MPAI standards workflow – Use Cases (UC) and Functional Requirements (FR) – participation in the relevant meetings is open to anybody (strictly speaking, however, the member who has been proposed a use case may request that only MPAI members participate in the UC and FR stages).
  3. The following stages are: Commercial Requirements, Call for Technologies, Standard development and MPAI standard.

The AI Framework case

In the spirit of collecting inputs from anybody, I will report the case of AI Framework that is likely to become the first MPAI standard. If you have any comment please send an email to leonardo@chiariglione.org.

MPAI has built and analysed six use cases where Artificial Intelligence (AI) technologies can offer sig­nif­icant benefits compared to traditional technologies. The use cases cover widely different applic­ation areas:

  1. imp­rov­ing the audio experience when audio is consumed in non-deal conditions
  2. processing DNA information jointly with consequent physical effects on living organisms
  3. replacing components of a traditional video codec with AI-based components
  4. making up for missing information from online gaming clients
  5. multimodal conversation, and
  6. compression and understanding of industrial data.

Even though use cases are disparate, each one of them can be implemented as a combination of processing modules performing functions that concur to achieving the intended result.

MPAI has assessed that leaving it to the market to develop individual implementations would multiply costs and delay adoption of AI technologies, while a suitable level of standardisation can reduce overall design costs and increase component reusability. Eventually a horizontal market may emerge where proprietary and competing implementations of components exposing standard interfaces will reduce cost and promote adoption and progress of AI technologies.

The MPAI-AIF standard

MPAI has determined that a standard for a processing framework satisfying the requirements derived from the six use cases will achieve the goal. MPAI calls the future standard as AI Framework (MPAI-AIF). As AI is a fast-moving field, MPAI expects that MPAI-AIF will be extended as new use cases will bring new requirements and new technologies will reach maturity.

To avoid the deadlock experienced in other high-technology fields, MPAI will develop a Frame­work Licence (FWL) associated with the defined MPAI-AIF Requirements. The FWL, essentially the business model that SEP holders apply to monetise their Intellectual Properties (IP), but without values such as the amount or percentage of royalties or dates due, will act as Commercial Requirements for the standard and provide a clear IPR licensing frameworks.

MPAI-AIF enables the creation and automation of mixed ML-AI-DP processing and inference workflows at scale for the use cases mentioned above. The key components of the framework should address different modalities of operation (AI, ML and DP), data pipeline jungles and computing resource allocations including constrained hardware scenarios of edge AI devices.

The MPAI-AIF reference model

The reference diagram of MPAI-AIF is given by the following figure

Figure 1 – Normative MPAI-AIF Architecture

  1. Management and Control: acts on PMs, so that they execute in the correct order and at the time when they are needed handling both simple orchestration tasks (i.e. a script) and much more complex tasks with a topology of networked PMs that need to be synchronised according to a given time base.
  2. Execution: is the environment where PMs operate. It is interfaced with M&C and with Communication and Storage. It receives external inputs and produces the requested outputs both of which are application specific.
  3. Processing Modules (PM) are composed of (ML or traditional Data Processor) processing element, interface to communication and storage and input and output interfaces (processing specific)
  4. Communication: is required in several cases and can be implemented accordingly, e.g. by means of a service bus.
  5. Storage: Stores the inputs and outputs of the individual PMs, data from the PM’s state and intermediary results, shared data among PMs, information used by M&C and its procedures
  6. Access: represents the access to static or slowly changing data required by the application such as domain knowledge data, data models, etc.

Requirements

Component requirements

  1. The MPAI-AIF standard shall include specifications of 6 Components
    1. Management and Control
    2. Execution
    3. Processing Modules (PM)
    4. Communication
    5. Storage
    6. Access
  2. Management and Control shall enable operations on the life cycle of
    1. Single PMs: instantiation/removal, reconfiguration, dump/retrieve internal state, start-suspend-stop, train-retrain-update, enforce resource limits
    2. Combinations of PMs: initialisation of the computational model, instructions (e.g. manual or automatic) to computational nodes to communicate between themselves and with output and storage, auto-configuration based on machine learning reconfig­uration of computational models, instantiation-removal-reconfiguration of PMs.
  3. Management and Control shall support
    1. An architecture that allows hierarchical execution of workflows, i.e. computational graphs of PMs, possibly structured in hierarchies, for the identified application scenarios
    2. Supervised and unsupervised learning, and reinforcement-based learning paradigms
    3. Direct Acyclic Graph (DAG) topology of PMs
  4. Execution shall
    1. Support distributed deployment of PMs in the cloud and at the edge
    2. Be scalable in complexity and performance to cope with different scenarios, e.g. from small MCUs to complex distributed systems
  5. PMs shall support protocols for
    1. Autoconfiguration (e.g. peer-to-peer)
    2. Manual configuration
    3. Advertising and Discovery
  6. PMs
    1. May be a mixture of AI/ML or DP technologies
    2. Shall be directly connected to the ML life cycle without interruption
  7. Communication shall enable direct and mediated interconnections of PMs
  8. Storage shall support protocols to specify application dependent non-functional requirements such as access time, retention, read/write throughput
  9. Access shall support access to static or slowly changing data of standard formats. Access to private data should also be possible

 Systems requirements

The following requirements are not intended to be applied to the MPAI-AIF standard, but should be used for assessing technologies

  1. Management and Control shall support time-based synchronous and asynchronous operation depending on application
  2. Execution shall allow seamless or minimal-impact operation of its PMs while algorithms or ML models are updated, because of new training, or retraining
  3. Task sharing for ML-based PMs shall be supported

General requirements

  1. The MPAI-AIF standard may include profiles for specific (sets of) requirements

For comments on MPAI requirements send an email to leonardo@chiariglione.org

Articles in the MPAI thread

Earlier posts by categories:MPAIMPEGISO