On Building Reliable Automotive Software Systems

During the last years me and my team built various automotive software systems in the connected car domain as well as in the body domain.
Before that, we built Android-based infotainment systems, mobile internet routers and some kind of wireless display like Miracast.
Over time, our work became highly inspired by two software platforms and their characteristics: Erlang and Android.
Erlang's influence came mostly from its reliability characteristics and its shared-nothing methodology. Android provides a modular, component-based application framework including a software development kit and documentation which we wanted to have for all kinds of automotive software systems as well.
This led to the developement of the Mindroid application frameworks.

What is Mindroid?

In short, Mindroid is a component-based application framework similar to Google's Android, including a software development kit and documentation. It builds upon the Actor model as core system architecture building block and provides an event-based programming paradigm.
Currently, there are three variants of Mindroid.

• Mindroid.java targets the Java platform
• Mindroid.cpp targets native platforms, like Linux or QNX Neutrino RTOS
• Mindroid.ecpp targets deeply embedded systems without dynamic memory management, like AUTOSAR OS, CMSIS RTOS or even bare metal

One of Mindroid's main goals is to provide a slim platform to develop highly reliable (distributed) software systems. Other goals and their prerequisites are:

• Modularity: Components with clear interfaces, threading and dependencies
• Reuse: Set of reusable components across projects and platforms
• SDK: Sustainable, public APIs crafted by an API first design approach (Finding good abstractions and truly care about naming things)
• Reliability, testability and refactorings: No shared state between components
• Software quality highly benefits from Actor model design approach
  • No complex critical sections
  • Callbacks run in right thread contexts
  • Low energy, CPU time and memory requirements
• Logging (No long-lasting debugging sessions)
• Slim platform: Simplicity is prerequisite for reliability
• Scalability: Distributed systems running multiple Mindroid instances on different nodes

Mindroid relies on the Erlang-style actor process model to achieve that goals. The core Actor model is mainly based on the Android Thread, Looper, Message, MessageQueue, Handler and Binder classes. Together with the Process class Mindroid implements deployable components and component isolation comparable to Erlang-style process isolation. The component isolation assures that there is no shared state across component boundaries. This is done by exchanging only POD types a.k.a. plain old data structures and component interfaces (actor endpoints) on component interface level. Using such component interfaces one can access further components. Furthermore, each component clearly defines its own threading behavior within the hosting process to achieve true component isolation regarding data (no shared state) and the runtime environment (process and actor).

Slide 5 below illustrates the Erlang-style actor process model using a CarFinder component that relies on a LocationManager for location updates.


For future, we plan to implement Erlang-style distribution transparency for services and service discovery. And we would love to have a Rust variant of Mindroid.

See also:

• Building a car (from the perspective of a pragmatic software engineer)
• Our Concurrent Past; Our Distributed Future
• Butler Lampson's Hints for Computer System Design