Connected autonomous vehicles can be connected to the metaverse

In a previous article, we have described the Architecture of the MPAI Connected Autonomous Vehicle (CAV). The CAV’s Environment Sensing Subsystem (ESS) captures data of the environment with a variety of sensors and produces the Basic Environment Representation (BER) that is passed to the Autonomous Motion Subsystem (AMS). This exchanges (subsets of) the BER with other CAVs in range and uses the received information to produce the Full Environment Representation (FER). Then, the AMS can issue commands to the Motion Actuation Subsystem (MAS) to move the CAV toward the destination.

In a previous article, we have described the Architecture of the MPAI Metaverse Model (MPAI-MMM) where a Metaverse Instance (M-Instance) is defined as a set of Processes providing some or all the following functions (terms beginning with small letters are in the Universe and terms beginning witj a large letter are in an M-Instance:

1. To sense data from U-Locations.
2. To process the sensed data and produce Data.
3. To produce one or more M-Environments populated by Objects that can be either digitised or virtual, the latter with or without autonomy.
4. To process Objects from the M-Instance or potentially from other M-Instances to affect U-Locations (in the Universe) and/or M-Locations (in this or other M-Instances) using Object in ways that are:
   • Consistent with the goals set for the M-Instance.
   • Effected within the capabilities of the M-Instance.
   • Complying with the Rules set for the M-Instance and applicable laws.

At a first glance, it looks like the way a CAV’s BER and FER bear a lot of similarities with the M-Instance of the MMM Architecture as we can see from the comparative .

Table 1 – Comparison between M-Instance and CAV

We need to look more in detail into this “similarities”. Before proceeding, let’s recall two assumptions at the basis of MPAI-MMM – Architecture:

1. User is a type of Process that represents and acts on behalf of a human. A human may have more than one User in an M-Instance.
2. Persona is a rendered User.
3. User may have or acquire the Rights to perform an Action, e.g., to authenticate another User.

To do that, let’s consider the simple case of two CAVs: CAV_A and CAV_B respectively owned by human_A and human_B, where human_A is friend to human_B. human_A has two Users: User_A.1 who represents human_A in the Human-CAV Interaction (HCI) Subsystem (or M-Environment_A.1) and User_A.2 who represents human_A in the Autonomous Motion Subsystem (or M-Environment_A.2). Similarly, for human_B.

human_A wants to see the landscape seen by human_B in their CAV_B.

This is a simplified description of the workflow (a fuller workflow is in the MPAI=CAV – Architecture standard)

1. human_A requests User₁ (HCI) to take them to a destination.
2. User₁ requests User_A.2 (AMS) to take CAV_A to destination.
3. User₂
   • Gets the BER from CAV_A’s ESS (or M-Environment₃).
   • Computes the Route to Destination.
   • Issues a series of Commands to the MAS.
   • Authenticates its peer User₂.
   • Gets a subset of the BER from User₂.
   • Produces CAV_A’s FER.
4. User₁
   • Authenticates its peer User₂.
   • Renders their Persona in CAV_B (e.g., using advanced 3D rendering technologies).
   • Converses with human_B.
   • Watches CAV_B’s M-Location corresponding to the environment currently traversed by CAV_B.

This example is a first demonstration of the compatibility of an M-Instance produced by a CAV implementing the MPAI-CAV – Architecture standard with the MPAI-MMM – Architecture standard.