## 3 Fail-Operational Architectures
What was missing and covered within this project is the development of a computing platform, fulfilling requirements enabling to host autonomous driving functions on the one hand and considering safety and dependability attributes on the other hand by applying already investigated patterns, e.g., on system architecture level. A variety of architectures have evolved over the years to provide an independent mechanism in processor-based systems for detecting failures during runtime. These architectures rely on the use of a single processor with a hardware checker and the use of two processors with the second processor of the same or different type as the main unit. The secondary processor can operate independently, running the same or independent software, serving as a touchstone to validate the primary processor's behaviour on a cycle-by-cycle basis. The more popular alternative is for the second processor to run in lockstep with the primary unit, using the same code and data. However, the secondary processor will typically work with a slight delay from the primary to avoid having both processors affected by a transient error on the system bus. A variety of architectures have evolved over the years to provide an independent mechanism in processor-based systems for detecting failures during runtime, see Figure 1.  
These architectures share a need to make substantial extensions to the basic processor design, including comparison hardware and possibly a full secondary processor. Furthermore, the external power supply and the internal function blocks need to be investigated for safe operation. The introduction of the AURIX safety controller, among others, opened an opportunity for silicon vendors to offload much of this hardware design burden from system developers. Many safety processors are marketed primarily to automotive design  
Figure 1: Variety of architectures supporting detection and mitigation of random processing errors. ers working under the ISO 26262 standard for ASIL (automotive safety integrity level) certification but are equally applicable to other safety-critical applications in industrial control, medical, military, and aerospace. Nevertheless, the fail-operational requirements cause a need for improvement of the design. Consecutively, the detailed investigation of the advanced ADAS fusion platform based on Aurix 2 nd generation safety controller is applicable for the improvement and design of the next-generation safety controller developed in the PRYSTINE project. Within the PRYSTINE project, Infineon Technologies AG (IFAG) works together with TTTech Group (TTTech) to implement a safe design based on traceability that would provide support for obtaining subsequent safety certification, thus improving the overall design cycle. However, one of the key challenges is to choose a proper safety controller. Therefore, TTTech and IFAG collaborated to develop the HW concept of the ADAS platform, the development of which was further done by TTTech. To enable automated driving functions, targeting SAE levels 3+, high-performance computing platforms with significantly high reliability and availability are fundamental components. The challenge in this area is mainly to find the optimal compromise between low costs and a sufficient level of dependability as opposed to the aerospace domain, where the expenses for safety and reliability enabling components are of lesser interest due to a significantly lower number of units. Therefore, the architectural patterns (e.g., triple modular redundancy) for highly reliable computing cannot be simply re-used from the aerospace domain. As previously mentioned, suitable architectures for a fail-operational computing platform in the automotive domain are:  
* Simplex architecture;
* 1-out-of-2 with diagnostics (1 oo2d);
* Hybrid architecture. The investigations of the three different architectures are based on a clear distinction between the item (computing platform) and the environment (power supply, sensor, actuator).