Isolation of Cores. Reduce costs of mixed-critical systems by using a divide-and-conquer startegy on core level

Transcription

1 Isolation of s Reduce costs of mixed-critical systems by using a divide-and-conquer startegy on core level Claus Stellwag, Elektrobit Automotive GmbH; Thorsten Rosenthal, Delphi; Swapnil Gandhi, Delphi Abstract Mixed-critical systems will be common in future embedded devices. The reason for this trend is the still growing functionality of such devices combined with further integration steps and new safety requirements. This paper describes a statically approach to limit the costs of development and to increase the reuse. Main idea is to allocate safety and non-safety software parts (applications) to different cores and isolate them from each other. This way the non-safety software does not impact the safe part of the system and thus can be developed with less effort. The idea is one outcome of the RECOMP project and was demonstrated in an ECU device (ESCL) which controls an automotive steering column lock. I. INTRODUCTION Within the RECOMP project the partners develop approaches to realize safety related systems running on multicore controllers. Typically such systems do not only comprise of safety applications, but also contain legacy and other non-safety related software. Often industry standards like AUTOSAR [1] are used. The main goal of RECOMP is to realize such systems in a way that the (re-) certification costs can be reduced significantly. This is important since new safety standards like the ISO [2] in the automotive market demand as a base high quality software development which already increases costs. Additional required safety measures add further work and costs. In sum it is obvious that the costs of software development and certification are increasing. There are different options possible how the increasing costs can be stopped or at least their growth rate decreased. One idea is to use virtualization and hypervisor technology to separate the safety and non-safety applications from each other to allow a separate certification. If they are separated they can be independently developed and the impact on each other is minimized. This already saves costs. In this approach the hypervisor must be developed also according to some safety standards since a failure of this software impact directly all software which runs on top. Additionally the hypervisor must know which parts of the application are allowed to access hardware registers, e.g. for an ADC module. Another approach is to use the standard protection mechanisms which are known from larger real-time operating systems or even from the desktop world. There the operating system takes care and isolates applications via processes from each other. In such systems typically the applications must be aligned to the API offered by the OS and are quite depended on the OS and middleware. Also the OS needs to be certified to the same level as the safety related software. The idea which is presented in this paper also focuses on a separation approach but not based on software layers but on core level. II. THE IDEA The idea is a separation of safety and non-safety applications on core level. This means that each core (or even a static set of cores) runs either a safety or a non-safety application. The mapping is static and will not change during run-time. The hardware must support the approach by allowing a configuration where one core is not able to impact the behavior of another core. E.g. the non-safety software on one core shall not be able to modify the data / variables of another cores application (and vice versa). This strict isolation further allows running the different applications directly on the hardware without the need of an additional software layer below. The strict division of the available cores is in principle the same as the old and famous divide-and-conquer principle if things are getting too complex to control just split them up. Figure 1 illustrates the approach with a 5-core controller where 2 normal applications and 3 safety applications ( ) run QM Figure 1: Mapping of applications to cores Since we do not strictly need to separate different non-safety parts from each other it is recommended to combine those parts especially if the software is newly developed. This way the applications can also be implemented to take advantage of the multiple cores. The figure 2 shows this evolved mapping. QM QM Figure 2: Mapping of applications to cores

2 III. HARDWARE REQUIREMENTS The approach for strict isolation on core level is only possible if the used controller supports the separation within the hardware. The most important topics are the following. Each core shall have own memory which the core exclusively controls. This memory shall not be modifyable by other cores. One way to support this is to have a core local RAM where the core can exclusively grant access. So it can be configured that only the local core can write but all other cores are only allowed to read from such a memory. It is still possible to have common RAM which is accessed via some bus. The common RAM may contain shared data of non-safety applications. The used bus system which connects cores, flash memory, RAM and peripherals must be deterministic and has to support a fair scheduling of bus messages. It must be avoided that one core which accesses the bus extensively causes nondeterministic delays or even a starvation of other cores which request the bus in parallel. A round-robin strategy for the bus access can guarantee a deterministic and fair behavior for the cores. The same applies to all bus masters who use the bus, e.g. DMA or intelligent peripherals. Peripherals need also a static assignment to cores (or bus masters). This is required to avoid interference when one core is using such a module and others also access it. Best would be that each module is only accessed by one application / core. Unfortunately this is not always possible. Just consider a situation where more applications receive and send messages via a CAN bus and the controller only has one CAN module. In such cases either the HW is directly shared (with much care!) or one takes over the HW access (peripheral master) and the other applications have to access the hardware via this core. For some situations it might be useful to allow a configuration for peripherals which completely disallows further reconfigurations. E.g. the on-chip flash device should be protected with such a mechanism to avoid a modification or erase of it during normal operation. The same applies for clock configurations which are typically initialized once. The following picture shows the block diagram of the AURIX which was used within RECOMP and which supports the above features for isolation. Figure 3: block diagram AURIX (source: Infineon, [3]) IV. SOFTWARE ENVIRONMENT The isolation of cores also impacts the design of applications. In our approach the designer must decide how many cores an application will use. For legacy software this is easy since most embedded software was designed to run on one core. They often have a dedicated timing within the application which does not change if the application gets a whole core. As previously mentioned sometimes it is needed that applications communicate to each other. A common case is the sharing of resources (e.g. peripherals). In such a system there is a need to have a standard core-to-core (C2C) communication module available which can be used on all cores. Such a C2C module should consider: A lock-free communication. Since the application shall not depend on each other a lock-free approach is mostly promising. In practical this means a dead-lock within one core does not cause stalls on other cores trying to read data. The send buffers are only written by the sending core and do belong to it. It must be guaranteed that the communication buffers always belong to one (the sending) core. The other cores can read the buffer to get the data but shall not be able to write. The initialization of the C2C module on one core shall be flexible. It is common that the cores may start in a defined order, so an immediate communication may not be possible. Furthermore it may happen that the software of one core is updated and the C2C communication structures have moved to a different location. The module shall be independent of the used OS. It might happen that the different applications use different OSes, so a dependency may impact the implementation negatively. The best is to implement the

3 C2C module as a library which can be directly used by the application. There are also some situations where an existing application must be adopted to run properly on an isolated core. For example in the following scenarios: Re-flashing of the MCU or of parts of it. It is common that embedded devices are updated in the field. E.g. car makers update their embedded devices via diagnostic services to offer new functions and to solve detected (software) problems. It is clear that the re-flashing should only take place in a secure and save environment in order to guarantee the success of the operation. This means that the access to the re-flashing registers must be limited, e.g. to only one of the application which controls the update process. Initialization of the clocks. Typically todays MCUs have a high complex clock chain and it is recommended that this is initialized by one core only. Often a reinitialization is not possible simply because some applications might already run while another just starts up. The same argument applies to the ports which control the pins of the chip. Since on most chips the pin configuration per port is quite flexible. So it is recommended that there is only one place which initializes these registers. V. CASE STUDY: ESCL Figure 4: Building blocks of ESCL system this is done by turning the key to the OFF position and then pulling it out. In an electrical system this means that a control unit is needed to check if all independent conditions for locking or unlocking are fulfilled. Locking of steering column makes the vehicle unable to steer and hence not worth driving. Locking of steering while vehicle is moving would lead to severe accidents causing serious casualties to the occupants of vehicle as well as other traffic participants. To evaluate such risks and their consequences, a detailed hazard and risk analysis has to be done. Following figure shows a result of such a hazard-andrisk analysis. A. Introduction to safety aspects of ESCL A steering column lock is an automotive sub-system designed to prevent un-authorized driving of a vehicle. It serves as an effective anti-theft deterrent and hence is made mandatory by several national regulatory agencies (e.g. Thatcham UK). Conventional steering column locks are purely mechanical and directly coupled to the ignition lock. Since such mechanical implementation has adverse effect on the degrees of freedom in designing the dashboard and hence of the complete interior, most of the OEMs have accepted electronically driven steering column locks. Such locks are called electrical steering column locks or ESCL. A design with slot in ignition locks (using transponder technology) or with a starter button (as in keyless cars using RF transceiver) is impossible without an electronically controlled steering column lock. The primary building blocks of an electrical steering column lock (ESCL) function are shown in the figure below. An electrical actuator in form of a reversible electric motor is required to mechanically decouple the ignition and the steering column. The motor drives the mechanical locking bolt into the steering column indents in order to lock the steering column. Reversing the motor direction makes the bolt drive in opposite direction thereby unlocking the steering column. It is only allowed to lock the steering column if the driver accomplishes two independent actions to avoid a locking by accident while vehicle is still on the roll. In a mechanical Figure 5: Functional Safety goals of ESCL Results of hazard and risk analysis showed there was at least one risk which carried safety criticality level of D (according to ISO criterions). This made the whole ESCL system carry D criticality and was required to be designed with corresponding requirements as specified by ISO Following metrics were now valid for the safety element ESCL Figure 6: Functional safety metrics for ESCL

4 While single point failure and latent fault metric provides guidelines for diagnostic measures to be implemented, random HW failure metric provides hints towards system architecture. Classical approach to come to above safety requirements would be to build two-channel system where each control channel can independently decide on state of ESCL. The diagram below shows such a classical approach. against three in the real silicon implementation). Both cores were supported by so called shadow cores running in lockstep to the main CPUs. The challenge was to decide on allocating control modules 1&2 from above diagram to different cores of a multi-core MCU, in this case Infineon AURIX. Along with ESCL control modules, it was also necessary to run other involved applications (i.e. PMM and driver information system). Various allocation strategies were studied in details before coming to final allocation solution. Below these different allocation strategies are discussed in details. 2) Strategy 1: Each ESCL control module is allocated to different cores. Figure 7: Functional safety concept of ESCL The classical approach (derived against IEC standard) would have required two independent ECUs controlling locking and un-locking sequence of an ESCL. An intelligent ESCL ECU would have required as well driving the loads and collecting feedback signals. The goal of Delphi within RECOMP project was to reduce overall costs of such a complex implementation by introducing a trusted multi-core platform. Using such a multicore platform Delphi was targeting to reduce number of overall components required to realize an D system. Reduced components would then indirectly lead to reduced certification costs (lesser number of components to certify and reduced complexity in design). Besides ESCL, there were other applications of lesser safety criticality. One was so called Power mode manager (PMM) which was providing power-state of vehicle (Ignition, Sleep, Power-OFF etc.). PMM was assigned B criticality level after through hazard and risk analysis. A Driver information system application was designed to provide necessary status output to the vehicle driver. This driver information application was assigned safety criticality of QM. B. allocation strategies for D applciation 1) Introduction to Infineon AURIX MCU AURIX (see figure 3) is the latest multi-core microcontroller from Infineon and is based on three independent 32 bit CPUs. In the RECOMP project though, a soft image (Xilinx based FPGA) was used to implement ESCL. The platform was called Meridian and had only two independent cores (as In the diagram below, ESCL control modules are distributed to two different core. Other applications are divided between two cores as well. Each core has its own operating system instance as well as own basic software (BSW) stack and runtime environment (RTE). C2C communication is implemented by OS and works as a complex device driver in the BSW stack. The periphery of microcontroller is divided between two cores and is guarded by hardware built acceptance filter. Since both cores run safety critical part of an ESCL application, both cores need to run its lock step companion as well. Figure 8: allocation strategy 1 Advantages o Easier allocation of control modules to different cores as they are treated like two separate microcontrollers o Plug-n-play of applications on each core is possible o No shared memory, or peripherals Dis-advantages o Safety overhead spread over two cores

5 o o Time synchronous (sequential) execution of ESCL algorithm requires wait sates in both cores (time consuming) Memory intensive implementations as both cores are equipped with separate instances of software stack. 3) Strategy 2: ESCL application on only one core with common BSW stack and only one OS instance To overcome disadvantages of above architecture, it was decided to evaluate a version of allocation where ESCL module 1&2 were implemented on one core which is running in lock-step. The other core was used for the implementation of non-safety critical applications like PMM and driver information system. To avoid a memory intensive implementation it was decided to have a BSW stack, RTE and OS common to both cores. C2C communication was managed by RTE/IOC itself. Below figure describes the implementation. Dis-advantages o Low on functional availability o Difficult to prove non-interference principles o Difficult to segregate periphery access to different cores o BSW/RTE/OS could become a single point failure case unless a lot of resources are spent to make these modules D conformed 4) Strategy 3: ESCL application on only one core with separate instances of BSW and OS on each core (Isolated cores) A shared software stack strategy as discussed above and shown in figure. 9, has some critical flaws. Major disadvantage of such a strategy is loss of availability of functions. After detection of first failure which can affect safety critical applications, all the applications running on other core needs to be taken to safe-state (Fail-Safe). This severely affects prospects of Multi- MCUs to be used for domain consolidated ECUS. So below shown architecture was chosen as a trade-off between safety, availability and cost criterions. Safety critical ESCL application was implemented on one core with two different control paths running at different time slots (temporal redundancy). PMM application ( B) was also implemented on the same core (core 1). 2 was used to host non-safety critical applications like driver information system (QM). Both cores were having their own instance of AUTOSAR stack as well operating systems. 1 used D conformed EB AUTOSAR operating system while core 2 was running with an in-house developed operating system. Figure 9: allocation strategy 2 Though this solution looks to give some advantages on the memory consumption and safety overhead management, availability of individual cores was severely affected. A single failure on a shared software resource would take down applications on both cores. This does not look good from perspective of providing a solution to up-integrate applications to reduce number of ECUs (one of the goals on RECOMP for Delphi). Besides this it is very hard to provide arguments supporting clinical segregation of safety critical and nonsafety critical applications due to large amount of shared resources. Advantages o Optimized for memory consumption o Safety managed only by one core Figure 10: allocation strategy 3 The data of the different application parts on core 1 are separated using the MPU. Advantages

6 o Higher functional availability required for domain consolidation (up-integration) o Segregated resources and periphery (only power supply and main quartz are common) o Supports plug-n-play implementation if applications o Complete separate development and update possible (eases re-certification) o Safety overhead limited to only one core Dis-advantages o Higher memory consumption After analysis of above mentioned different core allocation strategies, it was decided to use third strategy of isolated cores as it supported objective of domain up-integration. Domain consolidation strategy is then used to host applications from different vehicle domains (Body, Safety etc.) on a trusted multi-core platform. Such an up integration is a crucial first step towards achieving goal of EE footprint reduction. VI. PROS AND CONS The isolated cores approach has different advantages and disadvantages. The positive impacts on the design include: Application can be separately designed and have their own core(s). This simplifies the development compared to a full multicore approach using one common system. Composition of different applications is simplified. The application can run bare-metal on the hardware. There is no need to have additional layers below like in system using virtualization The approach is easy usable for existing applications since the single-core behavior can be established. The method scales with the available number of cores for multicore systems. For safety applications, the freedom from interference is much easier to proof. Failures in common middleware do only impact the local core and not the whole MCU. On the other side the following problems show up and need to be handled / considered: - Each core can run a complete application including all middleware and OS. This requires additional space in on-chip flash memory and RAM. - There is often the demand that peripherals need to be shared between applications. This mostly means an adoption to the software is needed to run the application. Also one core typically acts as master (for startup and complete shutdown) VII. SUMMARY The approach to use isolated cores to implement mixedcritical systems seems promising. It enables a clear design by mapping different applications of different criticality to different cores. The shown examples proof that the method works and keeps its promises. It is clear that the approach needs more work and more practical use to give a final statement. Nevertheless the results so far are quite impressing. [1] [2] ISO Road vehicles Functional safety [3] pdf?folderId=db3a304412b b409ae660342&fileId =db3a30431f fc664882a7648