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.
2 How to integrate reliability into SE framework? A Case from automotive design.
Table I. Systems Architect vs. Reliability Expert. Systems architects see the system of interest with…
Reliability experts see the system of interest with…
…a projective and functional viewpoint. The solution will satisfy all stakeholders’ requirements.
…a retrospective and dysfunctional viewpoint. Experience has shown that past solution were unsafe, dangerous, unreliable, nonmaintainable…
…a deterministic and symbolic viewpoint. Requirements are expressed by natural language. They integrate deterministic variables.
…a stochastic and physical viewpoint. Failures are induced by hazardous events reliability laws take into account.
…a logical viewpoint. The system states are modelled as events.
…a temporal viewpoint. Failure laws are continuous.
…a structural and a spatial viewpoint. The system is a modular or a integrative architecture containing separate modules or layers. Each of them can be separately modelled and designed. He uses a deep-first top-down reasoning.
…a behavioural and temporal viewpoint. The system is a set of transversal dysfunctional processes producing hazardous events. He uses a width-first bottom-up reasoning.
…unconditional viewpoint. The solution always functions…
…conditional viewpoint. What will happen if?
…black box viewpoint. He generates a satisfying architecture without opening its components modelled as black boxes.
…white box viewpoint. Satisfying DFR requires explicit behaviours and structures elicitation.
One possibility is to give them a symbolic tool helping them to create new domain knowledge without going to deep in their respective expertise. It seems that formal ontology may be this appropriated tool.
III. ONTOLOGY AS PEACE MA K E R TOOL Ontology is a term derived from two Greek words: on (being) and logos (rational thinking). Aristotle (384-322 BC) is supposed to be the first author defining what future Medial Philosophers will call Ontologia. Aristotle’s ontology is supposed to take into account all beings (syn. essences, entities…) Man can conceptualize, be they material (mineral, living creatures…) or purely speculative (gods, soul…). If one reads the Book Γ of Aristotle’s Metaphysics, then one can conjecture that his ontology is based on three epistemological principles. Firstly, ontology is specific domain knowledge. It is separate from phenomenology, e.g study of the phenomena, the accidents, the events, the particular contexts. Secondly, ontology is supposed to make understandable all the entities of this domain. Expressed differently, it is an exhaustive and static conceptualization of the domain - for Aristotle, this domain is the whole reality. Thirdly, ontology is rational. Man uses his a-prioristic reason to build it. Entities are classified into a binary taxonomy, depending on their respective and opposite substance (ousia). One uses logical inferences to test taxonomy consistency, e.g modus ponens. It is known that Socrates is a Man, and then, as all men, is mortal. Since the 1960s, the term ‘ontology’ has been acquiring a new sense. It is no longer referring to the way we analyze the beings as such. It concerns the outcome of this conceptualization process. Formal ontological are “artifacts” (designed systems) giving a clear conceptualization of a given domain knowledge, for a specific use or function . Ontologies satisfy specific requirements. Thus, Knowledge representation specialists used set theory set, predicate logics, graphical visualization, and thesaurus, to model and test ontologies . A good ontology must be encoded by object-oriented languages. The quality or the originality of its content can be evaluated by a Philosopher or a specialist of the domain under study.
Thus, Table II shows proximities between Philosophers’ viewpoint on ontology and Computer scientists’ one. Table II. Philosophical Ontology vs. Formal Ontology. Philosophical Ontology
Formal Ontology
Being Substance Interaction Gender (genos) Subsumption Individual Generation Composition…
Entity Attribute Relation Class Inclusive class Instance Inheritance Aggregation…
A satisfying ontology complies with the following criteria: - functional and substantial relevance. A satisfying formal ontology is useful for a given KM purpose. It contains as clearly, as concisely, as coherently, as exhaustively and as objectively as possible the significant knowledge of a given domain, - minimal engagement. It only has the entities and relations required to describe the given domain. No more, but no less, - abstraction, - formalization, - software operability on ontology-based language, e.g Protégé, OWL…. . Its design follows incremental or Y cycle principles software standards have still defined .
IV. SE-DFR ONTOLOGY In our case, the SE-DFR ontology we want is based on three contributing domains, as Fig.1 shows: Systems engineering (tip S), Reliability (tip R), and Object-based models (tip O). Our ontology also uses results of previous mappings between domains, such as object-based models in SE (SO junction), Reliability in SE (SR junction), and the use of object-based software to re-encode Reliability tools (RO junction). This last point is still in limbo. SO and SR junctions respectively refer to SysML and to ISO 26262 still working-on projects.
3rd CRECOS Seminary. Espoo, FI: Aalto University, 11-12 November 2010
S
Systemic framework
SR
SO SE-DFR ontology
R
Objectbased software
Reliabilityfocused viewpoint
RO
O
Fig. 1. RSO Triangle.
Our SE-DFR ontology can be seen as a prospective Knowledge Management (KM) tool both developed in 2009 and 2010 by an experienced design manager and three researchers. Its main purpose is not to conceptualize a wellestablished reality. It is to give a framework within system architects and reliability experts should build a future shared knowledge about the system of interest. Our ontology is a comprehensive and a demonstrative tool. It shows that is possible to integrate reliability in a general SE framework. Our SE-DFR ontology can be evaluated following three perspectives. The first one is related to its compliance with technical design processes standards has defined. Abstract design
Fig. 2. SE-DFR Ontology.
4
paradigm, and one of its avatars: MBSE, stands that every design process is supported by models production, use, transformation. It means that every entity or relation of the proposed ontology is built, used or managed in standardizes technical processes, be they requirements analysis, technical requirements specification, functional architecture (ISO 15288), or safety goals definition or safety mechanisms definition (ISO 26262). The second perspective refers to the existence of an objective (syn. well-accepted) thesaurus. Several standards are used to define SE, ASE or reliability-based entities. Synonyms, ambiguous definitions, not enough abstract and too detailed definitions are too numerous. Thus, our first task was to create a concise thesaurus. The one we obtain has a little more than 40 terms. Expressed differently, our SE-DFR ontology can be understood with only 40 terms. The third perspective concerns the software operability of the proposed ontology. It can not be directly managed by a software application. Its software operability is not immediately evaluated. But our ontology can be validated by SysML diagrams. That means that every proposed entity or relation can be described in a SysML diagram, be it the “use case” (uc), the “requirement diagram” (req), the “internal bloc diagram” (ibd), ot the state machine (stm) . By transitivity, it can then be ‘software-proof’. Fig.2 shows the SE-DFR ontology we have produced. Grey blocks refer to SE framework, while green ones refer to DFR. Dashed red rectangles refer to SysML diagrams. Gray dash ones correspond to different SE technical process, e.g Vee cycle layers. Blue arrows underline the relations between SE domain and Reliability domain.
V. PERSPECTIVES The previous parts of this communication have shown that SE-DFR development is both relevant and feasible. Car design becomes more and more complex. It then requires closer collaboration between designers and reliability experts. If those two functions, skills, or job positions remain distant, it is possible to create ontology helping shared domain knowledge building. Nevertheless, further work is envisaged. The challenge is now to study effective functionalities of the proposed ontology. Is it really relevant to help upstream design collaboration? Is it possible to use it to describe DFR related to powertrain system, which is a very complex artefact? How to encode our proposed ontology? So many (important) questions unanswered to this day!
VI. REFERENCES [1] É. Bonjour, J-P. Micaëlli, 2009. Design Core Competence Diagnosis: A Case from the Automotive Industry. IEEE Transaction on Engineering Management, Vol.57, N°2, pp.323-347. [2] É. Bonjour, S. Deniaud, D. Loise, J-P. Micaëlli, 2009. L'Ingénierie Système fondée sur les modèles, clef de voûte de la conception abstraite? Ingenium Research Seminary. Paris, F: CNAM, 3-4 December, 6 p. [3] É. Bonjour, S. Deniaud, J-P. Micaëlli, 2009. Conception Complexe et Ingénierie Système. In: S. Aït-el-Hadj, V. Boly (Dir.), Les Systèmes techniques : lois d’évolution et méthodologies de conception. Paris, F: Hermès, pp.83-101. [4] Stapelberg R-F., 2009. Handbook of Reliability, Availability, Maintainability and Safety in Engineering Design. London, UK: Springer Verlag. [5] International Standards Organization (ISO), 2000. Systems Engineering – System Life Cycle Processes. Geneva, CH: ISO. [6] Object Management Group (OMG), 2006. System Modeling Language (SysML) Adopted Specification, ptc/06.05.04. [7] R-T. Gruber, 1995. Toward principles for the design of ontologies used for knowledge sharing, International Journal of Man-Computer Studies, Vol 43, pp.907-928. [8] N. Rescher, 1989. Cognitive Economy: The Economic Dimension of Knowledge. Pittsburgh, PN: University of Pittsburgh Press. [9] H-A. Simon, 1997. The Sciences of the Artificial. Cambridge, MA: MIT Press (third edition). [10] Yu J., Thom J-A., Tam A., 2009. Requirements-oriented methodology for evaluating ontologies. Information Systems, 34(2009), pp.766–791.