Model Based Systems Engineering E-Book

Patrice Micouin

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 305

Veröffentlichungsjahr: 2014

Beschreibung

This book is a contribution to the definition of a model based system engineering (MBSE) approach, designed to meet the objectives laid out by the INCOSE. After pointing out the complexity that jeopardizes a lot of system developments, the book examines fundamental aspects of systems under consideration. It goes on to address methodological issues and proposes a methodic approach of MBSE that provides, unlike current practices, systematic and integrated model-based engineering processes. An annex describes relevant features of the VHDL-AMS language supporting the methodological issues described in the book.

Leseprobe

Contents

List of Figures and Tables

Acknowledgements

Foreword

Introduction: Goals of Property-Model Methodology

PART 1: Fundamentals

1 General Systems Theory

1.1. Introduction

1.2. What is a system?

1.3. Systems, subsystems and levels

1.4. Concrete and abstract objects

1.5. Properties

1.6. States, event, process, behavior and fact

1.7. Systems of interest

2 Technological Systems

2.1. Introduction

2.2. Definition of technological systems

2.3. Function, behavior and structure of a technological system

2.4. Intended and concomitant effects of a technological system

2.5. Modes, mode switching and states

2.6. Errors, faults and failures

2.7. “The human factor”

3 Knowledge Systems

3.1. Introduction

3.2. Knowledge and its bearers

3.3. Intersubjective knowledge

3.4. Concepts, propositions and conceptual knowledge

3.5. Objective and true knowledge

3.6. Scientific and technological knowledge

3.7. Knowledge and belief

4 Semiotic Systems and Models

4.1. Introduction

4.2. Signs and systems of signs

4.3. Nomological propositions and law statements

4.4. Models, object models, theoretical models and simulation

4.5. Representativeness of models and the expressiveness of languages

Part 2: Methods

5 Engineering Processes

5.1. Introduction

5.2. Systems engineering process

6 Determining Requirements and Specification Models

6.1. Introduction

6.2. Specifications and requirements

6.3. Text-based requirements and subjectivity

6.4. Objectifying requirements and assumptions through property-based requirements

6.5. Conjunction and comparison of property-based requirements

6.6. Interpreting text-based requirements

6.7. Conclusion: specification models and concurrent assertions

7 Designing Solutions and Design Models

7.1. Introduction

7.2. Deriving requirements

7.3. Basic system model of a type of systems

7.4. Dynamic design models of a type of systems

7.5. Derivation and allocation of the system’s behavioral requirements

7.6. Static design models

7.7. Derivation and allocation of system requirements

7.8. The end of the design process and the realization

8 Validating Requirements and Assumptions

8.1. Introduction

8.2. The validation process according to the ARP4754A

8.3. The validation process according to the property model methodology

8.4. Conclusion

9 Verifying the Implementation Step by Step

9.1. Introduction

9.2. The verification process according to the ARP4754A

9.3. The verification process according to the property model methodology

9.4. Conclusion

10 Safety Engineering

10.1. Introduction

10.2. The safety assessment process according to the ARP4754A

10.3. The safety assessment process according to the property model methodology (PMM)

10.4. Conclusion

11 Property Model Methodology Development Process

11.1. Introduction

11.2. Early phase of a system development, preliminary studies

11.3. Steps of the industrial development of a type of systems

11.4. Initial step: highest level system specification

11.5. Design steps: descending and iterative design of the building blocks down to the lowest level blocks

11.6. Realization step of the lowest level building blocks

11.7. Integration and installation steps

11.8. Conclusion

Appendix

A1.1. Introduction

A1.2. Roles and means

A1.3. Producing a specification model (SSM)

A1.4. Producing design models

A1.5. Producing a system model (SM)

Bibliography

Index

First published 2014 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.

Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address:

ISTE Ltd27-37 St George’s RoadLondon SW19 4EUUK

www.iste.co.uk

John Wiley & Sons, Inc.111 River StreetHoboken, NJ 07030USA

www.wiley.com

© ISTE Ltd 2014

The rights of Patrice Micouin to be identified as the author of this work have been asserted by him in accordance with the Copyright, Designs and Patents Act 1988.

Library of Congress Control Number: 2014945532

British Library Cataloguing-in-Publication Data

A CIP record for this book is available from the British Library

ISBN 978-1-84821-469-9

List of Figures and Tables

List of Figures

Introduction

I.1. ARP4754A engineering processes

Chapter 1

1.1. System composition, structure and environment

1.2. Concrete and abstract systems composition

1.3. Concrete and abstract systems environment

1.4. Representation of fictions (Arezzo Chimera and pi number)

1.5. Concrete and abstract objects

1.6. Laws and law statements

1.7. Systems involved in the systems engineering processes

Chapter 2

2.1. Artificial systems

2.2. Structure of technological system design

2.3. Function-behavior-structure framework

2.4. Function-behavior-structure relationships

2.5. Failure, fault and error

Chapter 3

3.1. Conceptual knowledge classification

Chapter 4

4.1. Sign, concept and represented object

4.2. Rosetta stone, signification and meaning

4.3. Page extracted from Voynish manuscript

4.4. Sentence, proposition and fact

4.5. Signs and symbols

4.6. Law statement, nomological proposition and factual law

4.7. Systems and models

4.8. Object model and theoretical model

4.9. Fault tree representation

4.10. Reliability block diagram

Chapter 5

5.1. ARP4754A engineering processes

5.2. EIA632 system breakdown structure

5.3. EIA632 building block requirement definition subprocess

5.4. EIA632 building block solution definition subprocess

5.5. EIA632 building block design processes

5.6. ARP4754A safety assessment and system development process integration

5.7. EIA 632 design process extended to safety assessment topics

Chapter 6

6.1. EIA632 building block requirement definition subprocess

6.2. EIA632 system specification architecture

6.3. Airfoil structural properties and related PBR

6.4. Interpretation: a process from TBR to PBRs

6.5. Some PBRs linking inputs and outputs of an air data computer

6.6. Some PBRs linking inputs and outputs of an aircraft fuel systemE

6.7. Canonical graphical representation of a system

6.8. System specification model

Chapter 7

7.1. EIA632 building block solution definition subprocess

7.2. Design model typology

7.3. Basic system model

7.4. Fuel system behavioral design model

7.5. System mode model

7.6. “Feeding the engines” functional chain

7.7. Basic system model including an equation design model

7.8. Composite system model

7.9. Composite system model

7.10. Fuel system structural design model

7.11. EIA632 system design process

Chapter 8

8.1. ARP4754A validation and verification processes connection

8.2. ARP4754A validation process model

8.3. Specification model tree validation

8.4. System specification model exactification process by simulation

8.5. Subsystem specification model validation process by simulation

8.6. Graphical representation of a specification model

Chapter 9

9.1. Implementation verification process regarding specifications

9.2. ARP4754A verification process model

9.3. Composite system model

9.4. System model verification bench

9.5. System model integration verification bench

9.6. EIA632-based system verification process

Chapter 10

10.1. ARP4754A safety assessment process

10.2. Failure, fault and error

10.3. EIA632 requirement definition process extended to safety aspects

10.4. Interpretation of FAR29.1309(b)(2) and systems FHA

10.5. Baro-altimeter specification model

10.6. Fault-tolerant baro-altimeter specification model

10.7. EIA632 solution definition process extended to safety aspects

10.8. SDM virtual component computing failure rates

10.9. SDM virtual component computing DAL

10.10. Reliability design model b) derived from a baro-altimeter structural design model a)

10.11. Extended EIA 632 design process model

Chapter 11

11.1. PMM system development process

11.2. Colossus with feet of clay in Nebuchadnezzar’s dream

11.3. System specification model

11.4. CAS specification model of intended functions

11.5. CAS protected volume and local environment representation

11.6. CAS specification model PBRs

Appendix

A1.1. PMM workbench conceptual design

A1.2. Front-end main window and views on PMM models

A1.3. PMM specification view

A1.4. Function and PBR graphical editor

A1.5. Equation design model view

A1.6. Behavioral design model view

A1.7. Process graphical editor

A1.8. Structural design model view

A1.9. System model and specification and design tree

A1.10. Component-block binding in system model editor

List of Tables

Chapter 1

1.1. Endo and exo-structure for concrete and abstract systems

Chapter 6

6.1. Document-centric versus model-centric paradigms

6.2. Tolerances on computed altitude by an ADC required by the SAE-AS8002A

Chapter 8

8.1. Validation case for a level of rigor consistent with no safety effect (NSE)

8.2. Validation case for a hardened level of rigor

8.3. Validation scenarios

Chapter 10

10.1. Failure rate classification according to AC29.1309.b(1)

10.2. Failure condition severity definitions according to AC29.1309.b(2)

10.3. Safety objectives for installed systems according to AC29.1309.b(3)(ii)

10.4. Top-level function FDAL assignment according to ARP4754A

10.5. Examples of system design patterns considered for safety aspects

Acknowledgements

I would like to thank all those who contributed to this book, often unknowingly, during a reading, a discussion, a comment about a technological fact or rule and what not.

First and foremost, I would like to acknowledge the intellectual debt that I took from Mario Augusto Bunge, the Argentine-Canadian philosopher of science. His work, discovered by chance in [DUR 02], became to me over the years the most demanding, the most encyclopedic, the most fertile and, especially, the most true of contemporary epistemologies (because, of course, all epistemologies are not of equal value [BUN 12]). His vision, ontological, epistemological and methodological, is not only of a philosophical background, but also the tool that allowed me to develop an approach for the development of technological systems which is, both theoretically sound and practically effective and efficient. I have maybe sometimes misunderstood concepts and propositions supported by Mario A. Bunge, or I have reused them roughly, but his work and how he puts it forward are both a solid foundation on which to build and also an invitation to think for myself and, I hope, for the best. I also accept full repsonsibility for weaknesses. I would also emphasize the conceptual borrowings I took from Vladimir Hubka, Norbert Roozenburg and John Gero.

In second place, comes the Doctor, and Major General, Dominique Luzeaux. I had the privilege of working with him in the French chapter of INCOSE (AFIS). Chairman of this chapter, he showed me, practically, what could and should be a rational decision making process. He gave me the opportunity to take an interest in the systems of systems. I thank him warmly for having forworded my work, that I think innovative and thus exposed to controversies.

Then follow those who, at Airbus Helicopters (AH) and the Centre National des Etudes Spatiales (CNES), provided me with direct support in my research effort. They are Michel Palandri, Charles Lanzalavi, Louis Fabre, Pascal Pandolfi and Sebastien Poussard (from AH) and Erwann Poupard (from CNES). They allowed me not only to validate the concepts and approach initially imagined, but they also pushed me to deepen it. I owe them, first, for allowing me to formalize the notion of EDM and, second, for building a mock-up of property model method (PMM) front-end.

I would also like to thank all those whom I have rubbed shoulders with daily in recent years, during the development of the EC175, until its certification in January 2014, and now, on a new helicopter development. I think of airworthiness teams with O. Jeunehomme, D. Strutzer, G. Brun, A. Illinca and C. Bousquet, but also of the EASA counterparts such as P.G. Colombo, G. Soudain, A. Smerlas, C. Rosay and R. White, those of AH Design Office, M. Achache, A. Ducollet, A. Jenni, K. de Bono, M. Godard, S. Bailly, J. Nobili and M. Lanteaume, and those of laboratory test, G. Cahon and C. Gaurel and flight test, P. Bremond, A. Di Bianca, M. Oswald and A. Delavet.

I also think of those with whom I have exchanged ideas on these issues, more sporadically by the force of circumstance, but always with benefits: R. Miginiac and J.M. Lecuna from Dassault Aviation, P. Farail and Y. Bernard from Airbus Avionics and Simulation Products, G. Meuriot and J.P. Daniel from AREVA, F. Hasse from DCNS, J.R. Ruault from DGA, E. Combes and J. Personnaz from PSA Peugeot Citroën, J.M. Pelbois from CMR, D. Seguela from CNES, and F. Malburet and P. Veron from Arts and Metiers Paris’ Tech.

I would also like to thank my family, my daughter Louise, my son Pierre and especially my wife Monique who has been, at the same time, the most diligent, the most critical but also the most benevolent of my readers. I have needed them to be able to bring this project to fruition.

Foreword

With the ubiquitous spread of potentially disruptive technology in our daily life, we face continuously, increasingly complex systems, and as engineers it is legitimate to ask ourselves whether we are still able to manage that complexity, whether requirements and specifications, as well as their verification and validation are still needed and even possible. Patrice Micouin’s book clearly answers “yes” and discusses a framework, both epistemological and practical, in order to address that challenge.

Patrice Micouin advocates a change of paradigm and introduces the Property-Model Methodology which relies on three claims:

1) in order to improve requirement engineering and aim for less ambiguous requirements that are better understood by the various stakeholders and the suppliers, a propertybased requirement theory is needed;

2) in order to have objective specifications that can be interpreted by all stakeholders in the same way, model-based systems engineering should be used: the models are executable within simulations and yield results that are easily accessible and shared by the stakeholders;

3) simulation becomes the main means to validate the specifications and verify the proposed designs, but does not fully replace verification of the unitary physical products as well as their integration.

All existing systems engineering processes call for an initial effort on having from the start testable, measurable and unambiguous requirements. However, the methodology developed by Patrice Micouin goes further, as it aims at cancelling any interpretation margin in the understanding of a requirement.

Such a paradigmatic change relies on the capacity of expressing specifications as membership constraints on the properties satisfied by the system and recursively its components (when condition C is fulfilled, property P should take its values in the given domain D of numerical values). Restricting the class of specifications in such a way is justified by an epistemological discussion inspired by Mario Bunge’s philosophy. Furthermore it should be noted that this class covers many real-world industrial applications and objectives in a much more immediate way than the behaviors obtained through simulation. Since such specifications build a semi-lattice, there is also a thorough way to go from system specification to component specifications, and back. On the one hand, this facilitates the transition from systems engineering to the different engineering disciplines needed to address individual components, and conversely. On the other hand, it avoids the usually tedious tasks of writing interface requirement specifications and interface definition documents.

As simulation is a common tool in many engineering disciplines, it is then much more straightforward to also use simulation as an effective tool at systems level, and engage in a paradigm transition from paper-centric engineering to model-based systems engineering. Practical efficiency considerations meet thus paradigmatic developments in this work, which is a landmark in the evolution of systems engineering practices that were formulated half a century ago when technology did not offer all the possibilities offered now.

Dr. Dominique LUZEAUXFormer Chairman of the French Chapter of INCOSEJuly 2014

Introduction

Goals of Property-Model Methodology

I.1. Introduction

This book is an introduction to a systems engineering methodology, called property-model methodology (PMM). This compound noun is formed from two of its main characteristics, namely, the formulation of requirements due to the concept of property (property-based requirements (PBR)) and the adoption of a model-based systems engineering (MBSE) approach.