Functional Safety: Safely Delivering Real-Time Performance

November 15, 2012 // By Christoph Hammerschmidt
The persistent customer demand for increasing features and functions has forced Automotive OEMs to install an ever increasing quantity of ECUs in their vehicles to the point where the complexity of the networks is almost at a tipping point. Some features are purely for comfort or convenience such as navigation, premium sound systems, auto-climate whereas other systems are legally mandated such as tyre pressure monitoring, advanced airbags, vehicle stability control.

In an attempt to manage the growing complexity, the vehicle electrical architecture has been split into specific domains, including: powertrain, body, chassis, safety, and infotainment. Each sub-domain connects to a high speed backbone bus with a gateway for information between the different clusters of ECUs.

Image 1: The Domain Controller “Bordnetz” used to simplify network connections by integration of several related applications into high performance Domain Control ECUs

The backbone bus is commonly FlexRay today but likely to also include Ethernet in the future. In the next step it is desired to drastically reduce the number of ECUs in each sub-domain by providing 'Domain Controllers' to replace a collection of the ECUs in the sub-domains. These Domain Controller ECUs provide a high performance computing platform which can host many applications in parallel, thus replacing a multitude of smaller ECUs and simplifying the system. This approach has many appealing benefits, such as saving package space, assembly time, wire harness complexity, network complexity and power. It also saves a significant amount of money in terms of system cost and R&D investment. However it does bring with it many new requirements for the computing platform to allow software and applications from different vendors to be hosted in parallel on one microcontroller in the Domain Controller ECU.

Freedom of interference between the different applications

One of the key issues is to provide a guarantee of ‘freedom of interference’ between all the different applications that are running on the platform. This means enforcing pre-defined limits on resource usage for each process in terms of CPU processing time, interrupt latency, code execution boundaries, RAM footprint, peripheral accesses and service usage (of operating system functions, EEPROM handlers, bus network drivers and similar shared functions). These guarantees need careful consideration on multicore microcontrollers. These multicore microcontrollers will have several CPUs running multiple AUTOSAR operating system (OsApplication) instances and share a common set of hardware resources. Traditional methods of

Design category: