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:

Figure I.1. ARP4754A engineering processes

whereas it supports the remaining processes:

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:

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 contexts². 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 complexity³, 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:

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 effort required. This allows an estimate of the integration and installation test methods to be implemented as well as the costs of the verification of the integrated and installed physical subsystems and system.

I.5. Conclusion

The remainder of the book is organized into two main parts and an appendix.

Part 1 introduces the underlying concepts of the PMM approach. It consists of four chapters (Chapters 1–4). Chapter 1 provides the framework for general systems theory (GST) and the subsequent three chapters cover the types of systems manipulated by designers of technological systems. The first chapter is about the technological systems themselves. The last two chapters (Chapters 3 and 4) are concerned with the means used by the designers to achieve their goals. On the one hand, this involves the knowledge systems used during an engineering process: factual knowledge and engineering reasoning and, on the other hand, the system of signs that allows the sharing of this knowledge among all stakeholders, including intermediate representations (models) of the targeted type of technological systems. These chapters provide the theoretical basis to the methodological proposals discussed in Part 2. If the readers wish to eagerly tackle this as soon as possible, they may skip the first part and move directly onto the second part. They will then be able to return, if necessary, to this foundation part (Part 1), whenever they feel that the ideas based on common sense deserve a theoretical explanation.

Part 2 describes the engineering process associated with the PMM. This part consists of seven chapters (Chapters 5–11) . Chapter 5 provides a general framework inspired from the standards ARP4754A [SAE 10] and EIA632 [ANS 03]. Then the following five chapters describe the main categories of activities associated with this process (1) to determine the requirements and specification models (Chapter 6), (2) to define a solution and the design models (Chapter 7), (3) to validate the requirements and assumptions (Chapter 8), (4) to verify the implementation (Chapter 9) and (5) to perform safety analyses (Chapter 10). The last chapter of this part (Chapter 11) is dedicated to describing the development process and the different stages of development.

Finally, the Appendix describes the elements of a metamodel assuring that a system model is translated into a VHDL-AMS [IEE 08, IEE 07, ASH 03] simulation model.

1 “In particular, MBSE is expected to replace the document-centric approach that has been practiced by systems engineers in the past and to influence the future practice of systems engineering by being fully integrated into the definition of systems engineering processes”, extracted from Systems Engineering Vision 2020, Document INCOSE-TP-2004-004-02, Version 2.03, p. 15, September 2007.

2 Due to their starting options, Agile methods do not form part of this.

3 As defined by N.P. Suh [SUH 05].