11

Property Model Methodology Development Process

11.1. Introduction

In this chapter, we will describe the system development process promoted by the property-model methodology (PMM). In order to introduce this process, we will first describe its upstream environment. And then, we will present the different steps of such a development. Then, we will describe each step in detail and, to conclude, we will discuss issues related to configuration management and collaborative work within the framework of the PMM.

11.2. Early phase of a system development, preliminary studies

Developing a new type of systems is usually preceded by a preliminary studies phase. During this preliminary studies phase, we first consider the practical and economical interests of these type of systems. Second, the feasibility and efficiency of such a type of systems is also assessed. The aim is not, at this step, to work through a systems industrial development process, but to highlight the operational environment conditions, operational goals, operating principle of the new type of systems and an associated operational concept. However, if the type of systems under consideration is derived from precedent type of systems, which already exists, this preliminary study phase can be reduced to a re-evaluation of the parameters taken into account during the initial preliminary studies. During these studies, it is not rare to set up simulation methods and develop models. This preliminary studies phase is not covered in the framework of PMM, but it would not be without interest that models drafted during the phase be industrialized in the framework of the system development.

If, for example, these preliminary studies relate to a midair collision avoidance system (CAS), installed in an aircraft, these studies will first be focused on the conditions of midair traffic, namely the traffic density of the different air-space zones. This is done to appreciate the risks of collisions, today and tomorrow, in relation to the foreseeable evolution of traffic, the inacceptable, or not, character of these risks, and to define the safety objectives capable of containing these risks within socially acceptable limits. The preliminary studies will have to characterize the goal of the type of systems, namely, enable the avoidance of aircraft collisions in the air, with a success rate compatible with the safety objectives. Preliminary studies will then consider operational strategies (detection, place of operators in the loop, warning operators, coordination between aircraft involved and characterization of avoidance maneuvers) by plugging them into operation scenarios. The efficiency of these strategies will have to be evaluated with regard to (1) the safety objectives and (2) the available midair collision data or risky situation data, while the situations exhibiting flaws in these strategies will be identified. The preliminary studies will have to identify the resources that are necessary and available to carry out these strategies, as well as the impact of deploying such a new type of systems on the operators, in operational and organizational terms.

Preliminary studies can be concluded with an operational1 and maintenance concept, which the industrial development of the type of systems under consideration can be based on.

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

The concepts of operation and maintenance provide a possible entry point to the industrial development of the type of systems under consideration. The PMM covers this industrial development, from a methodological perspective, by decomposing it into different steps as illustrated in Figure 11.1.

Figure 11.1. PMM system development process

images

The following steps are prescribed by the PMM:

1) initial step: highest level system specification;
2) design step: descending and iterative design of building blocks down to the lowest level;
3) production step: lowest level building block production;
4) integration step: ascending and iterative integration of building blocks up to the integrated system and installed in its operational environment.

In the following sections, we will describe these different steps by identifying the different activities and fail/pass criteria for each step.

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

images

11.4. Initial step: highest level system specification

The highest level system specification is the cornerstone of a descending development process of a type of systems. It provides the reference for the whole of the development. Consequently, it also concentrates the maximum risk of transforming development into a “colossus with feet of clay2”. If the system specification is not carried out well, blurred, incorrect or incomplete, we can fear that the resulting systems will be unsuitable to the needs, that their development costs will strongly surpass the objective costs and that the provision deadline will not be respected.

11.4.1. Initial step general approach

The proposed approach for this first step aims to reduce the risks, although it cannot be completely eliminated. It is described according to the following six points:

1) First, a specification model of the type of systems under consideration is established. Most often, it is recommended to develop this specification model incrementally, in successive versions, in order to correctly identify the different capabilities of the type of systems, one after the other.
2) For each increment of the specification model, a preliminary analysis of the functional hazards (FHAs) can be carried out (see section 10.3.2), which helps clear out the failures associated with the different capabilities taken into account in the model (loss of the capability and undetected degraded capability), and helps categorize their severity according to the foreseeable consequences of the failure.
3) This categorization of the severity of the identified failures helps determine (i) the level of rigor with which the validation of the specification model shall be carried out for the modeled capabilities, (ii) the scenarios and validation conditions that must be run through to ensure the specification exactness of the capabilities taken into account and (iii) enables us to add safety requirements in order to prevent the identified risks. The scenarios and validation conditions are devised in accordance with the level of rigor required (section 8.3.5).
4) The equation design model (EDM) (see section 7.4.2) shall be derived from the system specification model (SSM) to be validated and a validation workbench (see section 8.3.3) composed of a system model (SM) that includes the specification model (SSM) to be validated and its EDM and a validation driver.
5) The SM shall be simulated in the validation workbench, on the basis of the scenarios and validation cases defined above, which are submitted to the SM by the validation driver. This simulation enables an authorized person (a pilot or a test engineer, an expert from the authority, a client, etc..) (1) to observe the behavior of the type of specified systems, and (2), if it is the case, to confirm that the observed behavior is consistent with the intended behavior (for each scenario and validation condition considered) or (3) if it is not the case, declare the observed behavior as invalidated.
6) If some observed behavior has been invalidated, the specification model shall be revised in order to correct the observed discrepancies and return over the process indicated above. When no more discrepancies are observed, we can declare that the specification model, in the version under consideration, is the most possibly exact model for the pre established level of rigor.

11.4.2. Establishing a specification model of the type of systems

Specifying a type of systems Σ according to the PMM approach involves constructing specification models. It is a gradual development process of the system model that can require multiple iterations based on the understanding that it is better to quickly dispose of a crude (“false”) model to then rework it, rather than suffer the absence of a model. Simulation can, therefore, be a means to adjust the specification model, which will progressively mature through successive improvements.

Figure 11.3. System specification model. For a color version of this figure, see www.iste.co.uk/micouin/MBSE.zip

images

According to PMM, a type of systems is specified by its outputs. It is useless to progress any further as long as we do not know what output the system has to produce.

Thus, the first thing to do is to focus on the effects it shall produce on its environment, that is to say its functions (see section 2.3, Function=Intended Effects of a system). We can determine them by, for example, considering the results of preliminary studies and the operational concept that comes from it. We must temporarily forget the inputs, we will return later. Focusing on outputs, we must ask questions such as: (1) what kind shall these outputs be (matter, power, data or events flows)? (2) do these flows have to be continuous or discrete? (3) what are the rates at which these outputs shall be produced? (4) if so, what rate of change in these outputs shall be ensured? We can at the same time, or later, be brought to specify the failure conditions (see section 10.3.2) such as the loss of one or more outputs and detected error outputs (what of the undetected error outputs?).

For example, if we specify a collision avoidance type of systems, installed in an aircraft to prevent midair collisions, the first thing to do is to determine the intended outputs of the systems: these outputs can be (1) visually indicate the crew of the aircraft equipped with a CAS, all aircraft within its immediate vicinity, (2) visually warn the crew and emit an aural warning when an intruder aircraft is closer, finally (3) suggest the crew an avoidance maneuver if the risk of collision is found. In addition to the functional outputs specification, we can imagine the specification of a CAS observable state, including, for example, failure codes. Then, the question of knowing how many intrusions the system shall be able to take into account concurrently comes? This being set, we know what the system shall do.

Figure 11.4. CAS specification model of intended functions. For a color version of this figure, see www.iste.co.uk/micouin/MBSE.zip

images

The outputs being defined, we can now focus on the conditions the outputs shall be performed in. There are multiple kinds of conditions. These could be, for example, an output must appear within a given timeframe after the occurrence of an input, and this output must be a function of the input. Another possibility is that an output must appear within a given timeframe after the occurrence of an observable state, and this output is a function of the observable state under consideration. We can multiply, as needed, the appearance conditions of an output and its current value. That is to define the inputs or the observable states linked to the outputs by property-based requirements.

For example, if we specify a type of CASs installed in aircraft to prevent midair collisions, the outputs having already been identified, we shall specify the appearance and disappearance conditions of a (1) close traffic indication, of a (2) traffic warning and, of (3) a caution associated with a conflict resolution advice, and all those conditions depend on a representation of the aircraft local environment, elaborated by the system. This local environment representation constitutes an observable state of the model that conditions its outputs and shall be as exact as possible.

Figure 11.5. CAS protected, volume and local environment representation. For a color version of this figure, see www.iste.co.uk/micouin/MBSE.zip

images

After this, we are brought to ask ourselves the same questions about the observable states as the ones asked about the outputs, that is to say, what their appearance and elaboration conditions are. For example, if we specify a type of CASs installed in aircraft to prevent midair collisions, the outputs having already been established, we will specify the elaboration and conditions of the local environment representation the system builds. This representation of the local environment is elaborated from inputs, from the CAS carrier aircraft and from aircraft located in the CAS carrier aircraft close environment.

Once the outputs and observable states have been taken care of, the case of inputs remains. What is the nature of the inputs, are they material flows, energy flows or even information flows? Are these flows continuous or discrete? What are the magnitudes or definition domains? What are the flow rates or the highest frequencies of these inputs? What are the logics of appearance or disappearance of these inputs? If relevant, what are the variation rates of these inputs? As these inputs come from the environment, we do not have control over them. In this case, we do not formulate requirements but assumptions (that are formally identical but very different in practice).

For example, for a CAS, these inputs can be a number of physical aircrafts with their own kinematics (position and speed). We will, therefore, formulate assumptions on (1) the maximum number of aircrafts that can be taken into account by the CAS, (2) the accessible information concerning these aircraft. Thus, we obtain assumptions on the available inputs of the type of systems and conversely the operational limits of this type of systems. We will also be able to imagine a CAS, based on the data provided by an automatic-dependent surveillance-broadcast (ADS-B)3 system, as an input assumption.

Once the outputs, observable states and the inputs of the type of systems to be developed are identified, the relationships, which shall exist, between them shall be specified. In other words, how the outputs shall be devised as functions of the observable states and/or inputs. In which circumstances shall an event appear as an output, as a function of which input events? How shall the value of an output be devised from the value of the inputs and/or observable state? What shall the temporal inertia of the type of specified system be? What maximum delay can it introduce between the coming of the inputs and the appearance of the outputs?

For example, for a CAS, the specification of the relationship between the inputs and outputs can be the following:

1) The position of a new intruder shall be visually reported to the crew each time an aircraft enters the green envelope defined around an aircraft equipped with a CAS (own aircraft) in Figure 11.5.
2) The position of the intruders shall be visually presented to the crew so long as they remain within the green envelope in Figure 11.5.
3) The position of an intruder shall cease to be visually presented to the crew when it leaves the green envelope in Figure 11.5.
4) A traffic advisory (TA) alert shall be visually and aurally emitted to the crew each time an aircraft enters the yellow envelope defined around an aircraft equipped with a CAS in Figure 11.5.
5) A resolution advisory (RA) alert, including an appropriate maneuver message, shall be visually and aurally emitted to the crew each time an aircraft enters the red envelope defined around the aircraft equipped with a CAS in Figure 11.5.
6) An aural message “clear of conflict” shall be emitted to the crew when the threat leaves the red envelope in Figure 11.5.

Figure 11.6. CAS specification model PBRs. For a color version of this figure, see www.iste.co.uk/micouin/MBSE.zip

images

This gives us six property-based requirements:

PBRa: when CAS_Engaged and inGreen_Envelop(NewIntruder) → AdditionalIntruderDataDisplayed

PBRb: when CAS_Engaged and inGreen_Envelop(Intruders) → IntruderPositionDisplayUpdate

PBRc: when CAS_Engaged and goesoutGreen_Envelop(Intruder) → IntruderPositionDisplayCanceled

PBRd: when CAS_Engaged and inYellow_Envelop(Intruder) → TA_Displayed and Aural(“Traffic, Traffic”)

PBRe: when CAS_Engaged and inRed_Envelop(NewIntruder) → RA_Displayed and Aural(Avoidance_Maneuver)

PBRf when CAS_Engaged and goesoutRed_Envelop(Intruder) → Aural(“Clear of conflict”)

The terms appearing in this specification model all refer to a state (a value of a property) of the targeted type of systems. This is what we named the semantic assumptions (see section 4.3) of a model.

SA1: CAS_Engaged: the CAS system is installed and engaged

SA21: inGreen_Envelop(NewIntruder): a new aircraft has been detected in the external (green) envelope

SA22: AdditionalIntruderDataDisplayed: the characteristics of the last aircraft detected in the external (green) envelope are visually presented to the crew

SA23: inGreen_Envelop(Intruders): the characteristics of the aircrafts detected in the external (green) envelope evolve

SA24: IntruderPositionDisplayUpdate: the visual presentation, intended to the crew, of the characteristics of the aircraft detected in the external (green) envelope is updated

SA25: goesoutGreen_Envelop(Intruder): an aircraft leaves the external (green) envelope

SA26: IntruderPositionDisplayCanceled: the visual presentation, intended to the crew, of the characteristics of the aircraft detected in the external (green) envelope is deleted

SA31: inYellow_Envelop(NewIntruder): a new aircraft has been detected in the intermediary (yellow) envelope

SA32: TA_Displayed: a visual Traffic Advisory alert is emitted for the crew

SA33: Aural(“Traffic, Traffic”): the aural alert “Traffic, Traffic” is emitted for the crew

SA41: inRed_Envelop (New Intruder): a new aircraft has been detected in the internal (red) envelope

SA42: RA_Displayed: a visual Resolution Advisory alert is emitted for the crew

SA43: Aural(Avoidance_Maneuver) : the aural alert indicating the type of maneuver to be carried out is emitted for the crew

SA51: goesoutRed_Envelop(Intruder): an aircraft leaves the internal (red) envelope

SA52: Aural(“Clear of conflict”): the aural alert indicating the end of the conflict is emitted to the crew

Of course, this specification is objective but it is not necessarly exact. It shall be validated.

Finally, we know that a system does not only produce intended effects but it can also produce undesired effects, which we will seek to limit, false alarms on one hand, but also other unwanted events on the other hand (see section 10.3), in order to make them tolerable or acceptable.

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

Once we have a specification model of the type of systems under consideration that is sufficiently exact (in other words, validated as indicated above), it is possible to start the design phase, which is decomposed into different design steps by obeying the following rules:

1) Each design step corresponds to a building block: for example, a system, subsystem, item, component, assembly and part of the type of systems considered.
2) Dependence rule: the design step of a block B can only be engaged after the completion of its specification model (see section 6.7).
3) Independence rule: the design steps of two blocks B1 and B2 can be engaged independently from one another when B2 is not in B1 lineage, and conversely.
4) Two variations of the design process cover, on the one hand, non-terminal blocks (for example, a system, subsystem, item, component or assembly) and, on the other hand, the lowest level blocks (terminal) or parts. The first kind is described in the following section. The second is described right after.

11.5.1. Design step of a non-terminal block

In case we have a clear vision of the behavioral chain to be set up in order to satisfy the requirements allocated to a non terminal block, a design step of this block can, straightaway, be limited to a structural design, so long as we dispose of a validated specification model for that block.

1) In this case, we define a structural design model (SDM) of this block (see section 7.6.2) as follows. Usually, we develop such an SDM by taking into account the general architectural constraints linked to (1) the knowledge we have of the design patterns established by the state of the art, (2) the components and links existing on the market and (3) the installation and environmental constraints.
i) Selecting the components: the block designers are brought to consider different parts, assemblies, components, items or subsystems, which could form the composition of the block under consideration. This choice is made depending on the knowledge the designers have of the domain, existing solutions, their advantages and disadvantages and the innovations that could be introduced.
ii) Defining the block exo-structure: some of the block components shall be linked to the inputs, observable states and outputs of the block, by material, energy or data links, in order to connect them to the block exo-structure.
iii) Defining the block endo-structure: in a complementary way, the components of the block shall be linked to one another, by material, energy or data links, and according to adapted architectural patterns, in order to constitute the block endo-structure.
2) Defining the specification models of the block components:
i) A block SDM having been established, the block designers derive the specification model requirements over the different selected components of the structural architecture of the block. Each specified requirement to the block is derived over on or more block components. Note that some block requirements, such as redundancy requirements, can be fully satisfied by the selected architectural pattern. They are not assigned to block components and are no more derived.
ii) The set of requirements derived and assigned to a block component form the specification model of that component. Additional requirements can be added to the specification model of this component with the potential effects clarified in section 10.3.7. The structural design solution is, therefore, constituted of a structural architecture, a set of specification models associated with the different components of the block under consideration.
3) Validating the specification model of the components: a final activity linked to the design of a block remains to be carried out, namely demonstrating that the requirements assigned to different components of the block have been correctly and completely derived from the requirements assigned to the block, and that the additional requirements added to some components do not cause infeasibilities. To do this, we only need to carry out a validation activity as we described in section 8.3.4. If this validation process is conclusive, we can then declare that the derivation and specification models assigned to the different components are valid. In the opposite case, the derivation shall be reworked to correct the identified errors.
If, on the contrary, the assumption we made at the start of this section, namely that the designer(s) have a clear vision of the behavioral chains to be set up in order to satisfy the requirements allocated to this block, it is more cautious to start the design step of this block with a behavioral design, from the moment we have a validated specification model of this block.
4) To do this, we only need to follow the rules described in the following section (11.5.2) to design a behavioral design model (BDM) of the block under consideration. Then, we need to ensure that the design model does not comprise any design errors in relation to the corresponding specification model according to the verification rules described in section 9.3.3.
5) Once the BDM is free of errors, we then have sufficient knowledge of the behavioral chains that could be set up to satisfy the requirements of the specification model of the block under consideration. We can then start the structural design of the block as indicated above by allocating one or more behavioral components (discrete, continuous or mixed processes) to each structural component (subsystem, item, component, assembly or part). This allocation of the behavioral design process shall be complete, i.e. each behavioral entity shall have a structural counterpart resulting of this allocation operation. Note that this allocation operation is not an injective operation, several behavioral entities may have a common structural counterpart. Conversely, the same behavioral entity may not have several structural counterparts in one design solution.
Remind that there generally is not a unique behavioral or structural solution corresponding to a block specification model. There can be none (unfeasible specification), but there are generally multiple, which can all be treated in the way indicated above.

11.5.2. Behavioral design step of a terminal block

We consider a block to be terminal (a block of the lowest level) within a system decomposition when it (1) is available off the shelf of a supplier (this is the case for, for example, with sold equipment with an approbation letter (TSO/ETSO)), (2) is developed to satisfy defined specifications by a supplier and (3) can be directly made without any additional design. We recall also, that an equation-based model design is a terminal behavioral design model.

A behavioral design step of a lowest level block can start from the moment we dispose of a validated specification model of that block.

1) In this case, we define a BDM of that block as follows. Usually, we develop such a BDM by taking into account general architectural constraints, linked to the knowledge we have of design patterns and possible material transformations recognized by the state of the art. The preliminary studies can also have studied and developed transformation principles and algorithms validated by computation or simulations.
i) Selecting processes: the block designers are brought to consider different kinds of discrete, continuous or mixed processes, which could form the behavioral composition of the block under consideration. This choice is made according to the knowledge the designers have of the domain, the existing solutions, their advantages and disadvantages and the innovations that could be introduced.
ii) Defining the block exo-structure: some of the block processes shall be linked with the inputs, observable states and outputs of the block, by material, energy or data flows, in order to connect them to the block exo-structure.
iii) Defining the block endo-structure: in a complementary way, the block processes shall be linked to each other, by material, energy or data flows, in order to constitute the block endo-structure. This endo-structure constitutes the behavioral architecture of the block.
2) Verifying the block behavioral design model: a last activity linked to the behavioral design of a block remains to be carried out, that is to say demonstrating that this behavioral design is feasible and without errors.
i) For this reason, using an EDM helps establish the specification model does not contain any absolute contradiction (see section 6.2). This is enough in the case of a terminal block.
ii) Using a BDM that is more complex than an EDM enables us to define functional chains while we design a non-terminal block, and that we seek to have a clear vision of these chains, as we mentioned in the previous paragraph. After identifying, as we indicate it in the previous indent, the design of an intermediary block can be taken up again as in section 11.5.1, indent 5.

11.5.3. End of the design step

The design phase ends with the verification of various level of integration of the system model ascending order design templates terminal blocks to model the complete system. This activity is fully described in section 9.3.3.

11.6. Realization step of the lowest level building blocks

The realization of a lowest level block can be subdivided into two substeps:

1) The block physical realization: it is not technically covered by the PMM. The manufacture of each lowest level block requires processes that are specific to the kind of block to be produced, machining a metal part, performing a special process for a composite part and so forth. However, processes in line with the PMM can be used when producing a software block or a complex electronic hardware (CEH). In this case, the PMM remains applicable, and a code generator or CEH synthesizer can be used, if they are available.
2) The verification of the realized block: once produced, the physical block shall be verified. In order to do this, the compliance with the specification model will be established on a testbench by confronting this block with the set of scenarios and verification cases that have been selected (see section 9.3.3). If this compliance is proven faulty, we can either suspect an error in the manufacturing process or in the material selection, either an unfeasibility of the specification model. In the first case, we can just correct the error, in the second; we have to modify the specification model to make it feasible. This modification of the specification model can impact the specification model of the blocks coupled with the preceding block within the encompassing model endo-structure. It can also impact the specification model of the encompassing block, and therefore, by domino effect, more or less severely impact the design of the type of systems under consideration. Wise designers limit this risk nonetheless by introducing components for which enough experimental feedback exists, or for which feasibility studies have been carried out, for example during the preliminary studies.

11.7. Integration and installation steps

The integration of a type of systems is an iterative and ascending process ending on an installation final step, which is composed of two substeps:

1) The physical integration of each non-terminal block through the assembly of its constituents, compliant with the endo-structure of the block under consideration. The integration of each non-terminal block requires processes specific to the kind of block to be integrated. However, processes in line with the PMM can be used when integrating a software block or CEH. In this case, PMM remains applicable, and a code generator or a CEH synthesizer can be used.
2) The verification of the block integration: once physically integrated, the block shall be verified. In order to do this, the compliance with the specification model will be established by confronting, on a laboratory or installed in an aircraft, this physical block with the set of scenarios and verification cases selected. If this compliance is proven faulty, we can suspect an error in the physical integration process. In this case, we shall correct the integration error or the installation error. It is a result we had anticipated within the framework of the contract theorem stated in section 9.3.5.

11.8. Conclusion

The development process we have described in this chapter allows mastering and sharing of the design and development workload, for a type of systems, so long as it clearly identifies the steps from which the workload can be shared between multiple separated teams, and performed in parallel. These sharing steps are specified in the introduction of section 11.5, indent 2 and 3, which provide the independence and dependence rules allowing the parallel set up of the workload, while the contract theorem, stated in section 9.3.5 ensures the correct integration of workloads carried out in parallel. Additionally, the development process proposed gives us the possibility to manage, in parallel, multiple different versions of the specification models and design models of different constituents of a building block, and therefore to configure the type of systems under consideration according to different clauses, which all ensure the same system-level requirements.

1 IEEE Std 1362–1998, IEEE Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document.

2 “32-Then was the iron, the clay, the brass, the silver, and the gold, broken to pieces together, and became like the chaff of the summer threshingfloors; and the wind carried them away, that no place was found for them” Daniel, Chapter 2–32.

3 ADS-B = automatic-dependent surveillance-broadcast.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.226.170.187