IDD: Integrating Diagnosis in the Design of automotive systems

In this paper we overview the achievements of the IDD European project, which aims at defining a new framework for the design of automotive systems. In particular, starting from the weak- nesses of the current design process, especially as regards issues re- lated to diagnosis (diagnosability analysis, generation of the FMEA - Failure Mode Effect Analysis, generation of on-board diagnostic software), the project aims at defining a new process in which these issues are integrated within the design of a system and of its con- trol strategies. The project also aims at defining and implementing a software toolkit supporting the new process. The toolkit integrates applications for design and simulation (e.g., Matlab Simulink) and model-based reasoning systems for diagnosis-related tasks. 1 INTRODUCTION The importance of diagnosis in onboard automotive systems is con- stantly growing together with the complexity of the systems them- selves. The average dimension of the diagnostic software inside a modern electronic control unit (ECU) is now more than of the whole code. However, if one analyses the design process of any sig- nificant mechatronic automotive component, it is very common to see that diagnostic issues are usually taken into account only at the end of the process and are not integrated with the rest of it. In partic- ular, during the critical phases of the design process, when the actual architecture of the system is conceptualized, the control strategies are defined and models or prototypes of the system are simulated, diag- nostic issues are not taken into account. Not only does this mean that the diagnostic software is not developed together with the control software, but, more critically, that issues such as the diagnosability of the system being designed or the analysis of the FMEA (Failure Mode Effects Analysis, which is very useful to discover safety criti- cal faults or failures) are only partially considered in this phase. Usu- ally, these activities are performed by separate teams and most of the times after the design decisions have been made. In many cases the