# Strategies and Methods for the Fault-Tolerant Function Development of Multi-Domain Systems +
## 6 Product Development Examples
### Accommodation of Faults \"Emissions\" and \"Self-Acceleration\" in a Combustion Engine  
A good example of a complex multi-domain technical system offering a vast number of possibilities for faults and thus incorporating many approaches for fault-tolerant design is a modern internal combustion engine with its electronic control unit (ECU). Faults may occur on the mechanic level (e.g., tolerances and wear), the electronic level (e.g., malfunction of sensors), or the software level (e.g., a too sensitive calibration of functions or the interplay of various functions)--and, of course, due to a mixture of these aspects. The consequences of these faults might affect driver safety (possibility of unintended so  
Figure 8: Countermeasures for faults. called \"self-acceleration\") and emissions (e.g., of toxic substances such as carbon monoxide) as the most important ones. The main control of the engine is based on a redundant functional modelling of the physical system, i.e., the mechanical engine is represented within the control unit via two distinguished physical models, which calculate the output of the engine--the torque--separately, and in case of discrepancies, a safe mode is applied (fall-back solution with smaller engine power output). Additionally, the output of different sensors is validated by roughly calculating the value via other sensor output--and again setting a default value in the case of a large aberration. In the same way, actuators are limited by mechanical limitations as well as software limits. A main sensor, such as the electronic throttle, is realised via two separate and parallel electronic sensors. Most sensors and actuators are adapted automatically when starting up the engine in order to compensate production tolerances. In the case of emissions, there are various control loops that ensure a minimum of emissions. While the engine's combustion itself can be very clean, a catalyst serves as a buffer, reducing start-up and dynamic effects. A perfectly clean combustion is guaranteed by various oxygen sensors controlling the combustion, the deterioration of the catalyst, and the functioning of the sensors themselves via intelligent diagnosis functions. Just as diagnosis and safety functions might add up to more than half of the control unit functions, testing is the main task in the development of an engine. This happens--as proposed in the V-model--on different levels of the products structure, including (automated) testing of software and the electronic system itself, with software-in-the-loop (SIL) and hardware-in-the-loop (HIL), various test benches, as well as real-life testing in various environmental conditions. There are also design constraints in the software programming, such as not using complex functions (such as pointers), using model-based software engineering (MBSE), and using automated program coding. As described above, engineers have to decide in which domain a function has to be realised. In the same way, a possible or actual fault can be accommodated in different domains, too. Figure 9 summarises the functionally diverse fault accommodation possibilities. The functional accommodation and the implementation are summarised in Table 4.