Here, main software elements, included into the MOPED platform, are shortly outlined. The interested reader is referred to the theoretical section for more details on the concepts, while the more impatient reader is advised to proceed to the step-by-step installation instructions page.
ECU software architecture
An important design choice was to make the software configuration as realistic as possible, tightly related to the technology that is actually used in real embedded systems. For a vehicular platform, an obvious choice was to base the ECU software on the AUTOSAR standard, being the currently prevailing software architecture standard in the automotive segment. The implementation chosen was Arctic Core, one of the very few open-source implementations available with full AUTOSAR support. The implementation used corresponds to version 4 of the AUTOSAR standard.
AUTOSAR is a layered software architecture that decouples application software from lower level basic software (BSW) by means of a standardized middleware called runtime environment (RTE). This allows running the same application software seamlessly on different hardware platforms, as long as the underlying hardware is linked with the RTE through appropriate BSW. The BSW consists of an operating system that has evolved from the OSEK standard; system services for e.g., memory management; communication concepts; ECU and microcontroller abstraction layers; and complex device
drivers for direct access to hardware.
The application software typically consists of a number of software components (SW-C). Each SW-C declares a number of ports for communication with the rest of the system. They can be either required ports (meaning that the component is expecting some input) or provided ports (used by the SW-C for its output). The ports can implement different interaction schemes, including sender-receiver or client-server. The internal functionality, or the runnable, of the component only accesses its ports, and not any other components, which promotes reuse and transferability of SW-Cs between ECUs. The runnables are mapped to OS tasks. SW-Cs can also be composite, i.e. containing other SW-Cs inside.
Porting AUTOSAR to Raspberry Pi
First of all, necessary low level software needs to be put in place to glue together higher level software with the underlying Raspberry Pi hardware. This involves modifications of OS functionality such as boot loader, initialization, memory model, context switching, and exception handling. It also includes writing device drivers for various I/O types, such as the general-purpose I/O, UART, SPI, I2C, Ethernet, and CAN. More details on the porting process can be found here.
Current version of the AUTOSAR basic software, targeting Raspberry Pi hardware, is shipped in the form of a kernel.img-file, ready to be deployed on a Raspberry Pi board. See the installation instructions page for more detail on how to set up the basic AUTOSAR software on a Raspberry Pi.
Dynamic application software
Ordinary AUTOSAR software is static, once the configuration phase is over and the vehicle has left the factory. This hinders the development of new kinds of applications and interactions between embedded systems. To resolve this limitation, AUTOSAR concepts have been extended with dynamic behavior, presented in more detail here.
To put it shortly, the dynamic concepts that have been developed involve the definition of two types of dedicated SW-Cs. One is called the external communication manager (ECM) and is responsible for downloading new software and communicating with other systems. The software components of the other type, called plugin SW-Cs, serve as the actual containers for the additional software.
The dynamic SW-Cs also contain a static side, regarding their connections to the underlying system. These connections (ports) must be supplied at the design time by the vehicle manufacturer and serve as an API to the developers of plugin software. The interface between the dynamic elements of plugin software and the static ports of a plugin SW-C is handled by a middleware, called the plugin runtime environment (PIRTE).
In our approach, Java was the choice of programming language for the additional software, in order to promote its transferability. Thus, each plugin SW-C contains a Squawk Java virtual machine. Further, PIRTE exists in two flavors, one for each type of dynamic SW-Cs, and comes bundled together with the Squawk JVM. Step-by-step installation instructions, collected here, allow to set up the system for future addition of plugin software.
The additional application software is delivered to the embedded system through a pre-defined trusted server. An application may consist of several interacting plugin components and sometimes rely on certain basic software functionality and even earlier installed plugins. It falls under PIRTE’s responsibility to set up proper communication channels for the additional software internally. However, to reduce the computational load on the ECUs, it was decided to store the description of how this should be done externally and deploy it together with the binaries.
Since the configuration description will generally differ depending on the underlying hardware and software, the application server needs to keep track not only of the different hardware models, but also of the basic and additional software, currently installed. Typically, the information about necessary connections is provided by the application developer and synthesized on the server-side into PIRTE-readable format, taking into account the actual configuration of the target system. The server becomes thus an important point of intelligence for managing different plugins and their positive and negative interactions. The steps to set up an application server are listed here.
Also, it should be possible to publish information to another device or a server. The functionality for doing so is included into the ECM PIRTE, while the actual activation of this functionality is done by supplying proper configuration, which is best described by an example application.
Typically, an application developer has a limited access to appropriate hardware, especially one that is AUTOSAR-compliant. Thus, the MOPED platform includes simulation tools for representing message transfer between SW-Cs, as well as between SW-C and basic software, in a distributed AUTOSAR system. In such a way, to a large extent, new applications can be tested in desktop environment. The simulation software packages are found on the installation instructions page.