Realizing Modern Automotive Software Environments 

Increasing Automotive Software Complexity

The complexity of today’s automobiles is increasing with every new model on the market.  A modern car can contain hundreds of electronic control units and with connectivity and autonomy becoming commonplace, this is increasing dramatically as we enter the 2020s.  Many of these systems up until a few years ago have safely run on microcontrollers on an unsecured vehicle network, and this has been fine; the networks were ‘air-gapped’ from the rest of the world, and the risk of a malicious attacker causing any kind of danger to a car’s occupants by directly plugging in a new device was as likely as someone cutting the brake lines.  The automotive industry on the whole were happy with this risk.

Today, however, we are seeing a shift from mechanical cars that use computing for assistance, to computerized cars that use mechanics for movement. As the Internet of Things (Iot), artificial intelligence (AI), and autonomy find their way into automotive designs, we expect more and more out of our cars.  Functions such as object-recognition, machine learning, and rendering graphics for HMI systems are too calculation-heavy for microcontrollers to handle, which has led to CPUs and GPUs becoming more favorable.  Moreover, the introduction of AUTOSAR Adaptive Platform is driving a requirement to run POSIX®-compliant operating systems (OSes) on the same silicon as real-time operating systems (RTOSes) implementing the statically-defined AUTOSAR Classic Platform.

Challenges Faced by Builders of Safety-critical Automotive Software Systems

As more and more devices are added to the vehicle, a number of challenges emerge:

• Hardware costs increase with every device added to the vehicle
• Weight increases with every device added to the vehicle
• New CPUs and GPUs are being integrated to run alongside the existing microcontroller-based systems
• From a cyber security perspective, the attack surface increases as previously air-gapped networks become exposed to the Internet

The Benefits of Virtualization for Safety, Security, and Cost Reduction

One solution is to use virtualization to run multiple software environments on one processor.  This provides the cost and weight savings that are vastly important to the automotive industry, as well as the ability to apply strict controls on the communications between sub-systems.

At Lynx, we originally designed LynxSecure® — the foundation of Lynx MOSA.ic™ — to separate DoD networks and applications of different security classifications that needed to run on the same hardware, and so the underlying foundational technology has very strict isolation properties.  Memory, CPU cores, and devices can all be isolated, and then only the ones allocated to a particular domain will be presented to the applications running in that domain on top of the separation kernel.

Clearly, this approach is highly applicable to those functions that are designed to run on CPUs, but what about those written for microcontrollers?  Designers in the automotive industry may become nervous when we talk about running safety-critical software in virtualized environments, and this is understandable.  ‘Traditional’ hypervisors have usually been developed by taking an existing OS and running hypervisor services that share resources to its hosted guests.  This means that it is very difficult to run software designed as ‘bare metal’ applications without inheriting the processing overheads associated with accessing hardware through an OS and its drivers.  Arguments have been made in the past that modern processors are so fast that this doesn’t matter, but “as fast as possible” is not good enough for safety-critical applications – real-time guarantees need to be made.

Leveraging the Lynx MOSA.ic™ Modular Framework for Automotive Applications

Lynx MOSA.ic™ is different. It contains no hardware drivers and instead controls the assignment of resources and CPU time to guests, which reside in uniquely isolated virtual machines called ‘rooms’.  Guests get direct access to hardware, such that control of the hardware at the driver level is the sole responsibility of the guest that needs it.  This beautifully simplistic model means a designer can treat a room as an independent processor and write applications to run on ‘bare-metal’, gaining direct access to any resource that is assigned to it.  These ‘Lynx Simple Applications’ (LSAs) could be anything from a single-function application that the designer wants to keep isolated from the rest of the system (e.g. a cryptography routine) to a task scheduler, that schedules local functions or even functions in different isolated rooms.  This bare-metal environment also drastically reduces the cost and effort involved in porting a real-time RTOS designed for safety-critical applications.

Lynx has been in collaboration with automotive embedded systems company, ETAS, since 2017 to deliver virtualization-based solutions to the automotive market.  Our most recent demonstrator, on display in our booth this week at Arm TechCon 2019, showcases a proof-of-concept automotive platform built using Lynx MOSA.ic™ and hosting three guests:

1.  Open-source In-Vehicle Infotainment (IVI) running on Linux
2.  ETAS RTA-OS controlling a remote-control car via serial port
3.  Embedded Linux running RTI Connext DDS middleware

A separate machine running the CARLA driving simulator is acting as a ‘stimulus’ for the system, publishing driving information as DDS topics.  The RTI Connext DDS middleware subscribes to Vehicle speed and steering angle topics and sends this information via internal ‘passageways’ in RAM to RTA-OS, which controls the RC car in sync with the driving simulator.  A ‘Big Red Button’ can be used to trigger a kernel panic in the IVI guest, bringing down the lower-criticality side of the system.

Preventing Catastrophic Failures in IVI from Affecting Safety-critical Applications 

With this platform, we were able to show that a catastrophic failure of the infotainment system (which could be caused by a software bug, or a malicious actor) does not propagate to the RTA-OS room. Further, because RTA-OS was running on its own CPU core, the scheduled tasks could still meet their real-time requirements. It’s worth noting that this proof-of-concept only considers memory address space isolation and doesn’t consider more complex interference channels such as shared cache and memory bus architectures, A.K.A. “The Multicore Problem”. (Please keep a look out for our upcoming article on this complex topic)..

With the realization in the automotive industry that cyber security and functional safety go hand-in-hand, we believe the architectures possible with Lynx MOSA.ic™ and our partnerships with companies like ETAS and RTI  can provide the combination of safety and security necessary in our increasingly connected and autonomous cars.  You can find more information on using Lynx products in automotive applications here or you can direct any inquiries to inside@lynx.com.