Functional Safety: Safely Delivering Real-Time Performance
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 sharing common computing resources involve abstracting the hardware by use of a ‘Hypervisor’ layer.
This Hypervisor removes the direct OS access to the physical hardware and instead traps the accesses and marshals them to determine priorities and permissions before denying or permitting the requests. Taking this idea into the automotive world would mean running several ‘Virtual Machine AUTOSAR’ on each CPU with a specific hypervisor layer to sort out the permissions and conflicts for shared resources. This level of abstraction is not yet affordable in automotive ECUs as it has the major drawback of adding substantial latency to all the peripheral accesses of these deeply embedded, real-time systems. To be able to share resources successfully, there is a cooperative sharing model within AUTOSAR version 4 that defines an Inter OsApplication Communication (IOC) mechanism whereby Basic Software modules (BSW) that are not available on one specific core are redirected to the core that has this BSW module available. This mechanism relies on cooperation between cores, the downside being the potential of one core to receive a great number of IOC requests and therefore affect its ability to perform other tasks. The ‘freedom of interference’ desired between applications on different cores with such cooperative schemes has to be carefully examined and limits must be placed on the potential additional loading that could result.
A more pragmatic first step on the way to adopting the Domain Controller philosophy is just to put two ECUs into one. Even by this modest step there can be significant savings made in packaging, ECU infrastructure (PCB, connectors, power supply, bus transceivers, assembly and test) and wire harness. The simplest solution would be to install the two original microcontrollers side by side on a single PCB, however it would be better if a multicore microcontroller could provide both applications with their own unique resources and save further complexity and component costs. However, if one or more of the applications are safety related (i.e. they have the potential to cause harm to humans in the event of unintended operation) then strict analysis, engineering processes, metrics and arguments must be made as defined in the recently release ISO26262 Functional Safety Standard.
The standard requires the hardware to provide adequate fault detection capabilities, along with having a significantly low probability of violating any safety goal, to be usable in such a safety system. The highest demands of Automotive Safety Integrity Level D (ASILD) are an interesting challenge to meet in a cost effective and energy efficient way. To achieve greater than 99% Single Point Fault Metric (SPF) typically requires redundant computation, data corruption detection logic, time and memory protection units, clock monitoring, voltage monitoring and dedicated self test mechanisms. If reliance is placed on the application programmer to try and cover all these hardware related issues then a great deal of processing can be consumed doing plausibility and testing at runtime. If more than one processing core is present on the microcontroller then additional measures must also be in place to detect interference of a CPU by other CPUs, and also from other possible sources such as DMA engines and any other internal bus masters.
Safety meets performance
By working closely with the market leading tier 1 vendors, Infineon has defined a new family of multicore TriCore processors to meet this every growing demand for computational performance, increased memory sizes, safety and automotive quality. This new processor family is named AURIX and is the next generation of the highly successful AUDO and AUDOMAX families. The AURIX family is redesigned from the ground up to provide the very latest capabilities in the most energy efficient and highest performing way. The TriCore core has been reengineered into 2 different derivatives: one super-scalar; achieving 300Mz industry leading performance, the other a scalar version; which at 200MHz achieves the lowest current consumption and smallest area for the most efficient solution for medium performance application processing. Both TriCore CPU derivatives are available as Lockstep versions to provide excellent fault detection and fast reaction times for ASILD safety systems. The scalability in terms of performance, memory and packages within the AURIX family allows for a common Safety Case across the different devices, allowing single applications to be hosted on the smaller devices, but also allows multiple applications to be hosted in parallel on the larger devices without the need to modify software architecture or safety strategies. This is partly due to a unique facility integrated into every peripheral and every internal bus slave to only accept accesses from defined sources.
Image 2: The Register Access Protection System permits the flexible assignment of peripherals and system resources to specific CPUs and DMAs to enforce encapsulation independently of operating system memory protection schemes
This mechanism (called Register Access Protection) brings with it the ability to permanently block or allow any CPU, DMA or other bus master from accessing (or potentially corrupting) the state of any of the internal shared resources (SRAM, Peripherals, IO). This makes it possible for the user to dedicate any combination of peripherals and memories to each of the CPUs and DMAs. Many of the peripherals have also been duplicated to allow each hosted application to now have their own private resources and guarantees of ‘freedom of interference’ independently from any memory protection or other operating system related encapsulation mechanisms.
The potential savings for domain controller software engineering and integration analysis can be very significant (~30% saving) as mixed criticality systems can host one AUTOSAR OS for an ASIL D application on one core, and in parallel host a non-AUTOSAR OS with no native memory or timing protection enabled on the other core without the possibility of the non-safety application interfering with the safety related activities of the microcontroller. If multiple ASIL D applications are desired then AURIX can also host multiple AUTOSAR OsApplications and fully supports the cooperative model. This is assisted by the new Temporal Protection System to provide task time budget supervision and interrupt rate monitoring directly on the CPU cores. This permits an AUTOSAR IOC to be realised also for ASIL C and ASIL D systems as any interactions between cores can be monitored by hardware and restricted to pre-defined limits. The hardware enforcement of encapsulation boundaries allows a straight forward safety argument to be presented when integrating monitoring functions into existing systems as the ‘freedom from interference’ can be directly inferred. Collectively these mechanisms provide the hooks need for ‘Paravirtualization’ as a first pragmatic step towards full ‘Virtualization’ and Hypervisors. As today the ability to run ‘Virtual Machines’ is not really affordable or strictly demanded in automotive applications.
Image 3: The AURIX Supers block diagram shows 2 pairs of lockstep TriCore CPUs plus a single performance TriCore to deliver the highest level of performance and safety in a unified System On Chip architecture.
With many innovative technologies and mechanisms inside the new AURIX family of controllers from Infineon, there is now a scalable solution to address the highest performance computing applications while at the same time bringing many safety features into hardware rather than relying on application level software. The ability to host multiple applications from different vendors and at different safety criticalities on one microcontroller will open the door to new Domain Controller architectures, bringing greater system reliability while managing complexity as the electronically controlled functions and features in the car continue to exponentially grow.
About the author
Dipl. Ing. (BSc) Simon Brewerton is Senior Principal for Automotive Microcontroller Functional Safety at Infineon Technologies and is based in Bristol, UK. He can be reached via his email address simon.brewerton@infineon.com
For more information about the Aurix architecture visit www.infineon.com/aurix
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
