FEATURE MCUS & MPUS BUILDING THE FUTURE AUTONOMOUS CARS
Simplicity is key when it comes to developing the latest advanced applications for automotive. Here Chris Barlow, principal systems engineer EMEA at Lynx Software Technologies presents a practical platform for creating the modern era of safe and secure self-driving cars
I
n the automotive industry, BOM cost is a dominant factor in vehicle system
design. Highly complex systems require a shift from microcontrollers to more expensive multicore microprocessors and graphics processors, so it is desirable to reduce costs by hosting what would traditionally be physically distributed systems on fewer, consolidated devices called Vehicle Domain Controllers. A key requirement for these Domain
Controllers is to maintain the safety characteristics of traditional physically distributed systems while enhancing security. A sensible solution is to use a hypervisor to host multiple virtual machines on one processor. This provides the desired cost and weight savings, as well as the ability to apply strict controls to the communications between sub-systems. The hypervisor should be lightweight, such that it does not interfere with safety-critical timing behaviour, while providing freedom from interference between guests. In cybersecurity, the challenge is
slightly different. We know what the risks are today, however new vulnerabilities are discovered all the time so machines exposed to wireless networks must be considered ‘untrusted’. In connected autonomous cars, we need to accommodate wireless signals from other cars and even street furniture in the case of Vehicle to Infrastructure communications. A malicious wireless signal might be ‘valid’ (traffic lights ahead are green), but might be hazardous in a certain context (lights are actually red). To protect such a system, we need to isolate the safety-critical software from untrusted environments, and tightly control all communications such that functional safety cases can be designed around the detection of ‘valid but unauthorised’ signals. Traditional automotive systems
comprise of separate ‘boxes’ that communicate using serial communications, typically Controller Area Network (CAN). CAN was designed to use a bus topology where all broadcast messages are visible to every node on a network. It is then up to the nodes to decide if they need a given message. A topology where each node
18 JUNE 2018 | ELECTRONICS
has a private point-to-point connection with those it needs to ‘talk’ to would be more secure, however the increase in weight and complexity of the wiring harness would be prohibitive to production. Wireless connections expose attack vectors and could publish any message on the CAN bus.
Figure 1:
The next generation of intelligent vehicles will require powerful vehicle domain controllers
service. The additional processing overheads associated with running a Real-Time Operating System on top of another OS could potentially increase the variation in system response time, known as ‘jitter’. This would pose challenges when trying to run safety- or timing-critical AUTOSAR software. The domain controller paradigm closely
With a hypervisor, any topology can be
implemented between virtualised nodes with minimal impact on the car’s BOM. Private channels can be set up through shared memory regions and read/write, read-only or write-only permissions can be enforced. Communication speeds are no longer limited by the electrical properties of a wiring harness, but can be as fast as a memory access. Additionally, authentication and intrusion detection methodologies can be implemented to ensure signals are coming from their intended sources. There are several ‘embedded hypervisors’ on the market that all claim to do similar things. Many, however, have been developed by stripping down an existing operating system. Device drivers are kept in this trusted codebase and assigned to guests by a hypervisor
Figure 2:
A typical unsecured vehicle architecture –
wireless connections expose attack vectors and could publish any message on the CAN bus
Figure 3:
Locked-down networking for safe and secure vehicle communications
maps to the Separation Kernel described by John Rushby in 1981. A Separation Kernel “recreates, within a single shared machine, an environment which supports the various components of a system, and provides the communications channels between them, in such a way that individual components of a system cannot distinguish this shared environment from a physically distributed one”. A Separation Kernel Hypervisor, such as LynxSecure from Lynx Software Technologies, is therefore very well suited for deployment in these Domain Controllers. LynxSecure implements a very thin trusted codebase which contains no device drivers and instead simply controls device assignment and CPU time given to the VMs allowing them to run almost as if they are on ‘bare metal’. Using LynxSecure’s deterministic CPU scheduling, developers can accurately model what the guests are doing at any given time, even when VMs are sharing a core. This behaviour has proven essential to a major automotive embedded software company, ETAS, who recently announced a collaboration with Lynx to run their AUTOSAR basic software stack, RTA- BSW, on LynxSecure. Using a Separation Kernel Hypervisor within a Vehicle Domain Controller provides a lightweight platform to host virtual machines including AUTOSAR classic platforms as well as newer adaptive platforms. Support for Classic Platforms will allow software written for legacy MCUs to be ported to the domain controller, however it is very important that the Hypervisor is chosen carefully so that timing behaviour of safety-critical virtual machines is still predictable.
Lynx Software Technologies
www.lynx.com e:
inside@lynx.com
/ ELECTRONICS
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52
