3rd CRECOS Seminary. Espoo, FI: Aalto University, 11-12 November 2010
4
HOW TO INTEG R ATE R E L I ABI L ITY INTO SE FRA M E W OR K? A C ASE FRO M AUTO M OT I VE DESI GN. Éric BONJOUR 1, Samuel DENIAUD 2, Dominique LOISE 3, Jean-Pierre MICAËLLI 4. 1
2
3 4
FEMTO-ST – AS2M Institute, UMR CNRS 6174 – UFC / ENSMM / UTBM – 24, rue Alain Savary, F-25000 Besançon – eric.bonjour@ens2m.fr Université de Technologie de Belfort-Montbéliard (UTBM), M3M-INCIS Research Team – F-90010 Belfort Cedex – samuel.deniaud@utbm.fr PSA, DTI / DPMO / CSMT. Université de Lyon, INSA Lyon, ITUS Research Team, UMR CNRS 5600 Environnement, Ville, Société – 1, rue des Humanités – F-69621 Villeurbanne Cedex – jean-pierre.micaelli@insa-lyon.fr
I. INTRODUCTION Early 2000s has been marked by significant changes in automotive design. Car satisfies an ever-present need. It longitudinally, autonomously and safely carries a reduced number of passengers and goods. But car is also seriously challenged. Socially acceptable vehicle is expected to satisfy requirements such as reliability, drivability, low gas consumption, minimal environmental footprint, low cost... To achieve them, designers develop vehicles which are no longer pure mechanical products. ‘New’ vehicles must be seen as integrative architectures coupling functional modules embodied in multi-physical components . Their development requires the use of growing number models. Their design gains in abstraction. The mentioned models do not only refer to geometrical CAD applications, digital mock-ups or VR-applications. Moreover, in such a context, design managers have to change their routines. They have to create and implement new organizations (teams, projects, processes…), communities of practice or job positions, to develop skills or competences compliant with we have called the “abstract design paradigm” . Thus, in the late 1990s, automotive design managers have applied aeronautics best practices by implementing Systems engineering (SE) framework to their specific sector . Automotive SE (ASE) begins to be an industrial reality. Nevertheless, ASE lacks some points. The one we will analyze concerns the Design For Reliability (DFR) integration into SE framework, in order to propose a relevant SE-based DFR (SE-DFR). Our focus on reliability is easy to understand. Reliability is a key requirement in automotive design. In fact, car is a mass-produced, potentially dangerous, technological complex, warranted, and long-life product. Reliability-derived criteria such as operational capability, availability, controllability, safety, severity, integrity, maintainability … must be managed throughout the design process. In SE terms, it means that reliability-related concepts, tools, methods, laws or data must take into account different: - stakeholders’ viewpoints, be they drivers, passengers, road users, garage men…, “technical processes” , then different layers of the Vee cycle, - “skill networks” and expertises collaborative complex design requires , - tools supporting Mobel-Based Systems Engineering (MBSE), e.g SysML . The first hypothesis of this communication is that current SE offers a good framework for SE-DFR. For example,
ISO 26262 Functional Safety – Road Vehicles (2008) draft standard partially complies with SE standards. But the way designers conceptualize the “system of interest” differs from reliability experts’ viewpoint. To reduce the cognitive distance between those two professionals, a new shared knowledge domain must be built. Our second hypothesis is that “formal ontologies” are helpful to do it. The remainder of this communication is structured as follows. Section II explains why designers – more specifically, “systems architects” – and reliability experts can be seen as two tribes at war. Section III presents how formal ontologies can be seen as ‘peacemaker tools’ helping designers and reliability experts building a shared knowledge domain. Section IV presents our SE-DFR ontology. Section V draws on perspectives.
II. TWO TRIBES AT WAR? Reliability integration into SE framework is an emergent but growing problem. For example, ISO 26262 remains a draft, and no explicit mention of reliability is made in ISO 15288. No one has a return of experience about such a topic. Whatever, table I shows that cognitive convergence should be a difficult process, because designers and reliability experts have opposite ways of conceptualizing the system of interest. Moreover, they used tools which do not belong to the same generation of methods or software applications. Systems architect can use object-based languages such as SysML. Reliability expert usually have analytical tools designed in the 1950s, e.g Failure Mode and Effects Analysis (FMEA). Moreover, the transition from systems architects’ viewpoint to failure expert ones’ induce huge “cognitive costs” . If system architects integrate reliability concepts, methods, laws or variables, then they increase the number of conjectures depicting how the solution may behave, they operate probabilistic variables, they reason in terms of time and not only in terms of space, they non-trivially map two opposite viewpoints, as Table I shows… Thus, a question erases. How conciliate systems architects’ vs. reliability experts’ viewpoints without creating harmful ‘schizophrenic’ design? It is impossible to permute their respective job positions. It is also impossible to offer reliability tools (vs. SE tools) to system architects (vs. reliability experts) and say: just use them! A pure software-based solution is not relevant at all. Say: OK, share your data without defining if it exist common concepts is a non-sense solution.