Model Based Systems Engineering (eBook)

Fundamentals and Methods

Patrice Micouin (Autor)

eBook Download: EPUB

2014 | 1. Auflage
100 Seiten
Wiley-Iste (Verlag)
978-1-118-57959-6 (ISBN)

Infos

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.

Autor

Patrice Micouin is a consultant and researcher at Laboratoire des Sciences de l'Information et des Systèmes in Marseille, France, as well as Managing Partner at MICOUIN Consulting.

Inhalt

1 Model Based Systems Engineering Goals

1.1 The Nam Pyo Suh Theory of Complexity

1.2 Systems development complexity root causes and effects

1.3 Model Based Systems Engineering to master systems development

2 Fundamentals

2.1 The Mario Bunge's General System Theory

2.2 Technological Systems

2.3 Knowledge Systems

2.4 Semiotic System or Models

3 Methods

3.1 Engineering processes

3.2 Micouin's Property Based Requirement theory and requirement determination

3.3 Design solution definition behavioral and structural aspects

3.4 Requirements and assumptions validation

3.5 Hardware and software realization considerations

3.6 Implementation verification

3.7 Safety objectives, failure modes and mitigation means

3.8 Collaborative working considerations

3.9 Configuration management considerations

4 Annex - An example of MBSE language : VHDL-AMS

4.1 Requirements modeling and simulation features

4.2 Behavioral and structural architecture modeling and simulation features

4.3 Simulating architectures, requirements and model validation

4.4 Simulation and verification data

4.5 Fault generation and architecture robustness demonstration

4.6 Configuration features

4.7 Collaborative working space and model sharing capabilities

Textauszug

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.

In this introduction, we will begin by (1) giving a brief description of this methodology, and will then present (2) its goals and (3) the processes undertaken and how these goals can be satisfied. In the last section, we will present the organization of the book.

I.2. Brief overview

PMM is a methodology for developing the following technological system types: discrete systems (such as avionics), continuous systems (such as fuel systems), mixed systems (such as electrical generating systems) and multiphysical systems (such as landing gear systems).

This is a descending development approach, arranged from top to bottom, but it authorizes the reuse of pre-existing blocks at all hierarchy levels of a type of systems.

This development approach is compatible with current industrial development standards, specifically ARP4754A and EIA632.

For example, it covers rigorously the following ARP4754A processes:

1) Development Process:

a) requirement determination;

b) architecture and design;

2) Requirement and Assumption Validation Process;

3) Implementation Verification Process;

4) Safety Assessment Process;

5) Configuration Management Process;

Figure I.1. ARP4754A engineering processes

whereas it supports the remaining processes:

6) Planning Process;

7) Process Assurance Process;

8) Certification Process.

Moreover, similarities can easily be drawn from other current standards such as those of the spatial or automobile sector.

This methodology [MIC 13] is based on three main pillars:

1) The first pillar concerns requirement engineering and the implementation of the theory of PBR [MIC 08].

2) The second pillar concerns the principles of MBSE, which more or less radically replaces the specification documents and design description documents by specification models and design description models1. However, this is an original MBSE approach, unrelated to the theoretical work of Wymore [WYM 93], and unconnected, either, with the huge literature on SysML [OMG 12].

3) The third pillar, simulation, is the primary means of validating specifications and verifying designs, while the verification of physical products, their integration and installation are maintained.

This methodology also includes a strict development process that, on the one hand, forces good practices and, on the other hand, eliminates poor ones. Therefore, it is quite the contrary of a toolkit supplied without a manual and that leaves users faced with a task, without guidelines, as most languages are presented (which is normal) but also as some MBSE methodologies (which is clearly abnormal).

Finally, it is based on modeling and simulation languages whose relevance and expressivity have been well demonstrated. The language VHDL-AMS [MIC 13] is currently the target language, but other languages, such as Modelica® [MOD 12], could be also target languages.

I.3. Goals

As all methodologies should claim it, the goal of PMM is to reduce the complexity of developing technological systems as well as to provide technological systems satisfying the needs, i.e. the right systems, in a timely manner and all for an objectively justified cost.

However, from current observations, many large projects concerning the development of technological systems do not satisfy these objectives: poor performances, problems with reliability after set up, significant delays or costs. Although none have been cited, there are many examples, for instance, in the aeronautical domain.

Among the causes, some of the most frequently mentioned are incorrectly introduced innovations, underestimated development times and not properly mastered outsourcing of design activities, which have opposite results to those intended (to reduce delays and costs).

We consider that all these causes have one common mode, namely, the poor quality of specifications communicated from the purchaser to the supplier (internal and external and at any level), while, on the one hand, the supplier still appears to trust overambitious subsystems and, on the other hand, the requirement specifications are the cornerstone of development process models in industrial contexts2. Therefore, just like a building that is transformed into a colossus with feet of clay, it begins to sway: misunderstandings and dysfunctions in development systems (systems made up of human beings) even more important than project organizations involve teams that are increasingly numerous and increasingly spread over very different cultural and linguistic areas.

Uncertainties about delays, costs and conformity of the produced system are the three observable symptoms of development process complexity3, which PMM aims to reduce.

I.4. Processes

To achieve its goal, decreasing the complexity of developing technological systems, PMM introduces a methodological rupture as important as that of introducing the SCADE technology [BOU 14] in the development of software onboard aircraft.

This methodological rupture includes:

– the objectivation and the exactification of the specifications assigned to the systems to be developed;

– the design of solutions that are objectively error free;

– the delivery of specifications for subsystems objectively validated with respect to the system specification (i.e. consistent with the system level);

– the anticipation of approval phases of physical subsystems and of verification of integrated and installed systems;

– the reuse of equipment specifications and design descriptions when they are archived in libraries.

I.4.1. Objectifying and exactifying the specifications

Usually, the specifications are presented as text-based requirements (TBRs). Despite all efforts, they are still too interpretable and extremely dependent on the subjectivity of the author as well as the reader.

For example, it is quite difficult, from a pilot’s perspective, to perform the validation of a long specification of several hundred boring pages, whereas using a test bench, he can immediately detect satisfactory, acceptable or prohibited situations.

To improve this situation, specifications must be objectified, i.e. rendered non-interpretable and understood in the same way by all stakeholders concerned. This is why PMM specification models can be performed on a simulation bench and the results of this simulation can be presented to the stakeholders concerned.

Being objectified, the specifications then become exactifiable; in other words, the stakeholders are put into a situation where they are able to decide on the validity of behaviors observed, just as they could do on a test bench. The deviations can be corrected until the specification is declared exact (as exact as possible).

1.4.2. Designing error-free solutions

When the description of the design of a type of systems is frozen in order to allow further development, it must be error free, i.e. it conforms to its specification. All possible execution pathways, all possible failures should be identified and all protective mechanisms and reconfigurations should be assessed. In other words, when a design is frozen, we should be able to rely on it. The level of confidence should be up to the hazards associated with the operation of the corresponding systems.

This is why PMM design models are simulated and why, when the requirements are breached, the simulator signals the effects of the errors to be corrected as well as where they are situated in the model. This simulation/correction process continues until no more requirements are breached. Afterward, the design model will be deemed error free, provided that the simulation effort was sufficient.

I.4.3. Providing error free specifications of sub-systems

When the specifications of subsystems of a system are provided to suppliers for the development of these subsystems, they should be entirely objective and as exact as the system specification itself.

This is the reason why, in the PMM approach, simulation allows us to establish whether the specifications of subsystems of a system are complete and consistent with one another, but also, with the specification of the system from which they derive, with the level of rigor required for the safety challenges of the system.

I.4.4. Anticipating approval phases of physical units and their integration

From the specification phases of individual components, the scenarios for testing the individual physical components should be obtained according to the verification effort required. This is directly obtained, in PMM, due to the particular form that assumes the expression of PBRs. The test cases are derived directly from the PBR structure. This allows an early estimate of the test means to be implemented as well as the verification costs of the individual physical components.

Similarly, when PMM is implemented, since the specification phases of systems and subsystems, the test scenarios and cases for system and subsystem integration are known according to the verification...

Produkt-Details

• Erscheint lt. Verlag: 10.9.2014
• Sprache: englisch
• Themenwelt: Technik ► Elektrotechnik / Energietechnik
• Schlagworte: Electrical & Electronics Engineering • Elektrotechnik u. Elektronik • Systems Engineering & Management • Systemtechnik • Systemtechnik u. -management
• ISBN-10: 1-118-57959-3 / 1118579593
• ISBN-13: 978-1-118-57959-6 / 9781118579596