Theoretical contributions

This page contains a more detailed description of the concepts that allow MOPED to be an open, flexible, and easily extendable platform for experimentation on interconnected embedded systems. Our contributions extend the state-of-the-art AUTOSAR standard with the possibility to dynamically add application software at runtime. 

Ordinary application software (static)

According to the AUTOSAR standard, application software should be contained into software components (SW-C) that communicate with the rest of the system through provided (output) and required (input) ports. In other words, the application software reads and writes to its ports without the knowledge of how the rest of the surrounding software is organised. The signals between the ports are transferred by a middleware, called Runtime Environment (RTE).

This allows for simple re-allocation of software components during the design phase, by simply adjusting how the RTE forwards messages between the ports. In practice, this is typically done by defining desired port connections and SW-C allocations in xml-format, which is then used to automatically generate appropriate RTE code (typically C-code).

However, once this code is generated and integrated into the system, it is no longer easy to modify it. Generally, any modification requires regeneration of the RTE code, its reintegration with the rest of the software system and a re-flash of the whole ECU code. In this sense, typical application software in an AUTOSAR-based vehicle is rather static.

Plugin application software (dynamic)

The MOPED architecture extends the existing AUTOSAR standard by opening up for dynamic installation of additional application software. The idea is to pre-define SW-Cs that are dedicated to plugin software. Such plugin SW-Cs contain a virtual machine (which in our case is the lightweight Squawk Java VM)  for plugin execution and a dynamic middleware, called Plugin Runtime Environment or PIRTE, that interfaces between the dynamic nature of the plugins and the static nature of the ordinary AUTOSAR RTE.

Also, there is a need for a SW-C that is responsible for the communication with the external world, e.g. for transmission of plugin binaries or for publishing sensor data. This is handled by an External Communication Manager (ECM) SW-C, typically allocated to a WiFi-equipped ECU.

Plugin components and their ports

Replicating the AUTOSAR concepts, plugins come as self-contained software components (we will call them simply plugin components or PCs to avoid confusion with the AUTOSAR-level plugin SW-Cs, which are the containers for the PCs) and interact with the rest of the system through so-called plugin ports (provided and required).

When a new plugin is installed (which is done by PIRTE), all its ports must be connected according to a configuration description (which should be shipped with the binary packages), either to other plugin ports within the same SW-C or to so-called virtual ports, which serve as relays passing data to PIRTE for further processing. PIRTE is then responsible for formatting the data and forwarding it through the AUTOSAR interface to the RTE. This is done through one of three types of ports that must be pre-defined at the SW-C level:

  • one pair of ports (P/R) for interacting with the outside world, for example for receiving new plugin binaries or for publishing sensor data to an external server (type I ports);
  • one pair of ports (P/R) for every other plugin SW-C (type II ports);
  • ordinary ports, used for accessing built-in software, e.g. sensor signals (type III ports).
Different kinds of port connections in a plugin SW-C

In the above figure, type I/II/III ports are orange/green/blue respectively. Focusing on the left ECU, a new plugin is received at s9, the required type I port, and passed to v9, which triggers PIRTE to install the plugin. In the other direction, data is sent from the plugin port p3 to v8, and further through s10 to the wifi equipment for external publishing. P4 is connected to p5 through a simple write operation, while p0 and p1 are similarly connected to the basic software (after appropriate formatting in v0 and v1 respectively, such as for example mapping from Java to C through JNI technology).

Type II ports are probably the trickiest ones to handle. While they have to serve varying plugin configurations, their number is fixed on the SW-C level, since the AUTOSAR ports must be pre-defined statically. Thus, some kind of indexing information must be introduced. This is done by PIRTE at the virtual layer. For example, at v5, the data proceeding from p2 and p3 is labeled with their respective recipient plugin ports in the right ECU, p0 and p3, before being written to s7 for further transportation through RTE. The recipient PIRTE will then route the data to the correct plugin port in its virtual port v5. 

Plugin configuration

In order to establish appropriate connections between the plugin ports, each plugin installation should be accompanied by a configuration description. Such description consists of the following parts:

  • Header contains the message type (e.g. bytecode or external input signal), the SW-C port on which the incoming message (or bytecode) should be relayed (which decides which plugin SW-C will receive the plugin), and additional information (e.g. name of the plugin);
  • Port internal context (PIC) assigns unique ids, within the scope of each plugin SW-C, to the ports of the installed plugins;
  • Port linking context (PLC) provides the information to PIRTE about which connections between plugin and virtual ports that should be established. In case of type II connections, indexing information for the recipient ports is also included;
  • External communication context (ECC) defines addressing information for the additional external resources that will be used by the plugins.

The following figure exemplifies the use of configuration data. Two plugins (“COM” and “OP”) are being installed. The first one is installed in the ECM, while the second one is targeted for ECU2.

Example application, consisting of two plugins "COM" and "OP"
Example application, consisting of two plugins “COM” and “OP”

To achieve this, two installation packages of the following form:


are sent to the vehicle, which results in the following installation messages:


where the initial 0 stands for “installation message” type. The relay port v2 means that the “OP” package should be placed in v2, which will forward it to s2 and consequently through RTE to s1 on ECU2, where the binaries will be installed by the recipient PIRTE. The relay port “-1″ means that the “COM”-plugin stays on ECU1.

Both plugins receive port indices from p0 to p3. On ECU1, p0 and p1 are used for external communication and are not connected to the rest of the system through virtual ports. The other plugin ports, p2 and p3 are connected to the virtual port v0, with attached indexing information p0 and p1 respectively. This is used on the recipient side (by PIRTE) to dispatch the messages correctly to the “OP” plugin. For example, a signal from p2 on “COM” is routed to v0 (direct connection, ECU1) -> s0 (PIRTE mapping, ECU1) ->  RTE -> s3 (ECU2) -> v3 (PIRTE mapping, ECU2) -> p0 (PIRTE dispatching, ECU2). 

Server structure

All plug-in management is done through a pre-defined trusted server, a.k.a. “the open innovation portal”, which relieves the resource-constrained embedded system from much of the firewall issues. The server not only serves as a gateway for the plugin binaries, but it is also responsible for verifying that new plugins are compatible with a particular vehicle configuration. Also, the server is better suited for maintaining a coherent picture of the plugins that have been installed and how they may interfere with each other. It collects all information about the state of the FES and uses it to create plugin configurations that are shipped together with the plugin binaries at installation.

The following picture shows the functional server-side components that have been included into the MOPED platform, explained in more detail below.


On the top level from the users perspective, the server has a User and a Vehicle module, recording user profiles and associated vehicle details respectively. Vehicle has an associated configuration Vehicle Conf, which consists of hardware configuration in the HW Conf module, built-in software configuration in the SystemSW Conf module, and records of the installed plug-ins in the InstalledAPP module.

On the developer side, the APP module represents the application code stored on the server. Typically, an application consists of one or several plug-in binaries. Furthermore, each APP comes with one or several configurations (SW conf ), which describe for various vehicle models how the plug-ins should be distributed in the vehicle and how the different plug-in ports should be connected. Combining the vehicle and plug-in configurations, the server creates a context for the specific combination of APP and Vehicle.

The trusted server provides two modules that communicate externally. The Web Services module presents an interface to the user of the server, whether it is the vehicle user, the
OEM, or the plug-in developer. The Pusher module is used to interact with the vehicles through their ECM modules.

The server provides three kinds of operations through the Web Services module: user  setup, upload of plug-ins and configurations, and plug-in (re)deployment. Except for typical settings, such as creating a user account, the user setup involves binding of a Vehicle module to a User, allowing the server to keep track of specific Vehicle-User-configurations.
Upload operations are typically done by OEMs or third party plug-in developers. OEMs should upload descriptions of the hardware resources that are available to plug-ins (HW
conf ), together with the exposed API, in terms of virtual ports in the available plug-in SW-Cs (SystemSW conf). Finally, the plug-in developers upload their binary code and
descriptions of how to distribute their plug-ins on the available ECUs and how to connect the plug-in and virtual ports, based on the information in HW conf and SystemSW conf.

Plug-in installation is normally triggered by the user through a web portal. To begin with, the server checks whether the target vehicle meets the pre-requisites of the plug-in by comparing the vehicle configuration with the list of SW conf modules for the plug-in. If a match is found, i.e. there exists a description of how to distribute and connect the plug-ins in the vehicle, the turn comes to check the plug-in dependencies. In some cases, certain pre-requisite plug-ins must be installed in order for the new plug-ins to function. Conversely, the deployment operation can be hindered by an already installed plug-in being in conflict with the new plug-in functionality.

If the compatibility check fails, the server presents the reason for the failure to the user. If the check passes, the server creates a PIC context by assigning SW-C-scope unique ids
to the plug-in ports, using the knowledge about the already installed plug-ins. Next, the port connection information, found in SW conf, is translated into a PLC context. Special care must be taken with the plug-in ports that will be connected to plug-ins located in other SW-Cs. In that case, the port ids of the recipient side must be included into the context that is communicated to the sending side SW-C. If any plug-in is designed to communicate externally, a package with ECC information is prepared for the ECM PIRTE.

Finally, the server extracts appropriate binaries from the APP database, combines them with the generated contexts into installation packages, adds the ids of the destination ECUs and the message types, and sends the packages to the target vehicle through the Pusher module. Afterwards, the server keeps track of the returning acknowledgement messages (acks) and records them into the InstalledAPP table.

When the uninstallation operation is invoked, the server starts by consulting its InstalledAPP table to check which plug-ins belong to this APP and whether there are some
other installed plug-ins that are dependent on the plug-ins being uninstalled. If this is the case, the user is notified about the need to also uninstall the dependent plug-ins.
Otherwise, uninstallation messages, containing the plug-in names and the ids of the ECUs on which they run, are sent to the vehicle and the InstalledAPP table is updated once
successful uninstallation has been fully acknowledged.

Finally, the restore operation is used when an ECU hardware has been physically replaced, e.g. in a workshop. The server filters out previously installed plug-ins in the replaced
ECU by querying the InstalledAPP module. Next, the usual installation steps are followed for each plug-in.