1. The different nature of the interacting technologies making up a CAV.
2. The sheer size of the future CAV market.
3. The need for users and regulators alike to be assured of CAV safety, reliability and explainability.

But what would be the meaning of a CAV standard? For sure not the CAV itself because each manufacturers has their own ideas about how a CAV should be presented to buyers.  On the other hand, CAVs belong at best to an industry still being formed, that will target the production of affordable units in the hundreds of millions. Some may think – like the car manufacturers of 100 years ago – to make a CAV entirely relying on their own forces, but that approach will make a mass market of CAV to the reemote future. Since CAVs promise to have a major positive impact on the environment and society, they are urgently needed and, to reduce their costs, early availability of critical components is required.

The role of a CAV standard should be that of facilitating the achievement of this goal and its development can be accelerated by creating a CAV Reference Model (RM) that subdivides the CAV to components to the lowest atomic level possible. The standard should concern the components, their functions and their interfaces.

When we say components we certainly do not mean the mechanical ones but those that make a CAV a vehicle capable of sensing the environment and make decisions about how to best move in the physical environment to achieve the goal set.

There is no such thing as _the_ CAV Reference Model. There can only be good assumptions that need confirmation from research. Progression from research to standardisation can then be implemented as a series of transitions between research – proposing components and interfaces to standardisation – and standardisation – possibly requesting more results, or refining the results, or adopting the proposal. Eventually, industry will receive a set of specifications for functions and interfaces. Implementation in products relies at a minimum on the know-how of those who have driven standard component  the development of those specifications.

A CAV Reference Model (RM) identifying components and their interfaces can accelerate the definition of standard components. Progression from research to standardation can unfold as a series of proposals from research suggesting components and interfaces to standardisation, and standardisation either requesting more results, or refining the results, or adopting the proposals. Eventually, industry will receive a set of specifications for standard component functions and interfaces to be implemented as best available technology allows. Implementation in products will rely, as a minimum, on the know how of those who have driven the development of the specific­ations.

MPAI has been engaged for about a year in the Connected Autonomous Vehicles (MPAI-CAV) standard project that seeks to define identified CAV standard components that fit in Subsystems – 5 identified so far – corresponding to Use Cases for each of which a Reference Model is defined with its Components, their functions and interfaces and the connections between and among Subsystems. The Subsystems Reference Models identify and describe the requirements of the data types received or generated by the AIMs in each subsystem. Therefore they allows researchers to select data, define testing setups, propose update of interfaces, conduct contests, consider the influence of external components, and subdivide workload in a way that allows unambiguous comparison of results.

The 5 Subsystems are briefly identified and described with their acronyms.

Table 1 – The 5 MPAI-CAV Subsystems

Each of the 5 subsystems is meant to be implemented as an instance of the MPAI-defined AI Framework (AIF).

MPAI has not been the first to identify the need for a Reference Model. However, and unlike previously published papers, the MPAI Reference Models has the following features:

1. It adopts a holistic approach that includes all IT components of a CAV;
2. The components of the AIF standards, namely, the AI Framework (AIF) itself, the notion of AI Workflow (AIW) and the notion of processing units called AI Modules (AIM) as the unifying elements that determine the Functions and the Data Formats of all CAV components;
3. AI Modules (AIM) with Functions and Data Formats that are being or already specified in other MPAI standards;
4. Focus on the Data Formats between AIMs rather than focus on the AIMs themselves whose internals are not part of the standard but left to proprietary implementations, as long as they perform the identified funxtions and expose the identified interfaces with the specified data formats.
5. A process where research is seamlessly integrated with a subsequent standardisation process.

The current result of the effort is a document called MPAI-CAV Use Cases and Functional Requirements whose goal is:

1. To collect and describe the 5 identified subsystems.
2. To identify the functions, and the input and output data of the AIWs that implement the subsystems.
3. To identify the Topology of the AIMs making up the AIWs.
4. To identify the Functions, and the input and output Data Formats of the AIMs required to realise the AIWs.