Chapter 9

Conclusion to the “Antarctica Life Support Facility” Case Study ¹

“Just because nobody complains doesn’t mean all parachutes are perfect.”

Benny HILL

The Antarctica mission was a success for the OTL laboratory. The Antarctica Life Support Facility, an indispensable support for this mission, kept its promises and responded well to the expectations of all stakeholders. The mission went without any major glitches, and cooperation between the scientific teams, the acquirers and suppliers was carried out efficiently in a climate of reciprocal trust.

To mark the occasion and celebrate this success, Yves decides to bring together the different teams for a social event. Yves is particularly fond of Sylvanès Abbey, where he was a participant at a conference the previous year, and he wishes to share his enthusiasm for the location. Thankfully, a slot is available and Yves issues invitations to all of the actors involved in this adventure.

All those involved in the Antarctica project therefore find themselves in a magnificent Cistercian abbey, known for its sacred music, one fine day in September. The abbey has recently acquired a new organ¹, and Yves, an amateur organist, cannot resist the temptation. He convinces the abbey staff to let him play the magnificent instrument for a short while for the benefit of the whole team. To everyone’s delight, Yves is granted permission to play for half an hour. First, as it is still the summer and the team is in a festive mood, he plays the Larghetto in D Major from the Concerto BWV 972, a transcription of Vivaldi’s Concerto in D Major for Violin, RV 230. Next, the location calls for something more spiritual, so he plays Bach’s Chorale BWV 768 in G Minor: “Sei Gegrüßt Jesu gütig”.

Later in the evening, the tone shifts towards discussion, and everyone seems pleased to have taken part in this adventure. An attentive listener to these conversations might be able to learn something about factors for success in appropriate and effective systems engineering, a process that allows us to obtain an optimal solution and maximize stakeholder satisfaction. Firstly, the listener might think that for the acquirer, this satisfaction comes from the acquisition of a system that strictly satisfies needs and expectations at the best possible price. For the supplier, the ultimate goal appears to be the provision of that which was requested (with proof of conformity to these requests) with the greatest possible profit.

However, the lessons “learnt” by our imaginary listener are based on two major errors in terms of perspective, confusing engineering, i.e. the art of finding a solution through reasoning, with the management or representation of this solution.

9.1. “Before we can manage a solution, we need to find one!”

This may appear self-evident, but there is a noticeable trend towards the dominance of management activities over technical activities, to the point where the two are confused. During the evening, certain individuals mentioned this shift, which makes requirement management a question of engineering and not, as its name might suggest, of management. Some were surprised to see this aspect promoted as a spearhead in certain environments. For all those present, it is clear that the spearhead of systems engineering lies in the capacity to understand a complex universe and create an optimal solution, giving consideration to a host of aspects that often contradict each other. The key point is to reach this solution, not by simple intuition (although, as in mathematics, intuition should not be ignored), but through logic and the application of rules obtained from feedback and by following good practices.

Anne and Marc, as technical directors (or systems engineers, or systems architects) for the acquirers and suppliers respectively, concentrated their efforts and those of their teams on activities based on reason and value creation, with extensive use of models. Of course, these different activities generated engineering elements, and thus information, requiring support structures in terms of management to organize, distribute and maintain this information over time. However, a certain number of “good” properties appeared in relation to this generated information, allowing management activities to be put in their proper place:

– Reasoning must be carried out “at the right level”. As the notion of a system is an abstract and often recursive notion (a system is made up of sub-systems), any information produced is at a given level of abstraction, that of the system under consideration. This is one of the keys to mastering complexity. The information generated therefore remains relevant and of a reasonable quantity. Teams are not “drowned” by thousands of requirements, producing thousands of attributes and interconnecting links. Instead, the system is summarized, or abstracted and factorized, into a limited number of relevant elements of key information.

– While these items of information or engineering elements are limited in number, their engineering involves considerable efforts in terms of analysis, verification, validation, etc.

– This information is shared based on a single and shared knowledge model, an ontology of the systems-engineering domain. The number of concepts is limited (needs, requirements, functions, flows, performances, components, links, etc.) but the definition of these concepts, their structural links and the semantics of the concepts and links are known. This means that although each individual works on a sub-set of information, he participates directly in the coherent and complete construction of the system, directly and advisedly making use of engineering elements produced by others. Unfortunately, a number of organizations consume non-negligible quantities of resources in transforming and re-writing engineering elements for different actors, attempting to reduce the semantic losses involved in each rewriting.

As we have repeated on a number of occasions, an engineering activity is a transformation activity based on reasoning and which produces added value. We shall now attempt to extract a typical pattern for these activities in engineering terms.

An engineering activity transforms input (engineering elements) into output (other engineering elements) with the addition of value. This added value lies essentially in the fact that the engineer is confronted with a certain number of alternatives or possible options (choice of technologies, make or buy, etc.) or conflicts (reliability versus availability, for example) and must make choices. To do this, he must carry out system analysis and optimizations (global trade-offs). The engineer therefore makes a certain number of definitive technical decisions that require objective justification: demonstration of the relevance of a choice, explanation of the rejection of certain options, etc. The output engineering activities must be verified and validated (see section 8.1).

Figure 9.1. Typical diagram of a systems engineering activity

9.2. “Modeling isn’t drawing!”

We must not confuse the representation of an element with its use as a basis for reasoning.

One opinion, with an unfortunately widespread effect in practice, tends to limit modeling efforts in systems engineering to a descriptive activity, using the model as a vehicle for communications between various project stakeholders. While a coherent description of the system involving different stakeholders through graphical representations, rather than textual representations and where mathematical representations are not available, is undoubtedly a factor that contributes positively to the success of a project, this reductionist vision is nonetheless dangerous.

This vision promotes graphical notations, which are expressive but weak from a semantic point of view, and thus tends to distance systems engineers from the necessity to work in a reasoned manner based on more formal models.

This is sometimes amplified by the following syllogism concerning the contractual relationship between acquirers and suppliers:

“The two parties are linked by a contract, and the contract clearly stipulates that the deliverables (particularly during the early phases) are documents, and thus our activity must produce documents.”

Unfortunately, this syllogism often turns out to be a sophism, and a number of organizations fall into the trap of engineering centered on documentary production (including the production of “models” representing the system), which concentrates on representation and not on the orchestration of engineering activities.

The same drift has also been seen in the domain of requirements engineering, where certain approaches concentrate more on the rules of representation. So, in this case, writing of needs and requirements (leading to quarrels and debates on the differences in usage of shall, should or will, for example), is to the detriment of the construction of system models at the right level and with the right perspectives.

Our imaginary listener recalls certain moments of heightened discussion on this subject during the course of the evening, particularly a heated debate between Marc and Michel. This question of the difference between representations and bases for reasoning brought up memories of their high school philosophy classes, notably on Plato’s Republic. In a dialog between Glaucon and Socrates (Plato, Republic X, 596d–598d, [PLA 02]), Plato shows mistrust of the pictorial representation of things. In this case, he takes the example of a bed, differentiating between the relationships between the bed, as a tangible object, and the bed itself, or the very idea of a bed (the different tangible beds that we may experience participate in this idea, or “form”, of a bed) and the representation, or “painting” of the bed.

Plato’s theory of forms, or ideas (in his opinion, the only source of knowledge) led him to oppose two realms: the physical realm (where the physical bed and its possible representation exist) and the intelligible realm (where we find the idea, or form, of the bed). These two realms are mentioned in the famous allegory of the cave. The analogy of the line constitutes an ontological and epistemological preliminary to this. This analogy of the line (Plato, Republic VI, 509d–511a) is summarized graphically and allows Marc and Michel to place the different representations and models correctly.

Finally, they reach the conclusion that the models they used as a basis for reasoning and engineering their system belong to the intelligible realm. These models are intermediary forms, mostly mathematical, which allowed them to reason logically, infer and deduce a certain number of facts linked to their system that they were able to verify and validate objectively.

Figure 9.2. Models and representations in systems engineering

They also note that a number of graphical representation frameworks for systems that are becoming widespread nowadays do not really constitute an effective basis for logical and rational reasoning, and should be classified as “pictorial representations”, or images.

However, the use of standardized frameworks (for example architectural frameworks such as the DoDAF (DoD Architectural Framework) or the NAF) allows us to reinforce communications between actors, mainly between acquirers and suppliers. Generally, the contractual framework between these parties explicitly demands the provision of documents, the reading and understanding of which (and their comparison during phases of competition between different potential suppliers) must be facilitated. The use of representation frameworks is interesting in such cases.

This discussion between Marc and Michel is essential. It allows them to address and (re)create foundations for the natural approach to systems engineering which, like other forms of engineering – despite certain deviations into the domain of practice – has always been based on models. We return to the typical pattern of a systems engineering activity, which we can add to in the following manner, shown in Figure 9.3:

Figure 9.3. Model-based systems engineering (versus representations of the system)

This vision does not present an opposition between the world of model-based engineering and that of representation (graphical or textual), but clearly shows their complementarity and the crossing points between the two:

– A: the passage from the realm of representations to engineering elements operates mainly through the analysis of documents and other descriptive sources. The transformation is often manual, but may be assisted if the input elements of representation are of a suitable type and expressed using a standard or known structure and format;

– B: the passage from the domain of engineering towards that of representation is indispensable in explaining, publishing (in a documentary, so textual or pictorial, form) and diffusing the results of work to other stakeholders. This is particularly important, as we have already indicated, in the relationship between acquirer and supplier. This passage may make use of quasi-automatic model transformation techniques (which have now reached maturity) to move from elements expressed using a systems engineering metamodel to standardized elements of representation (such as the frameworks defined by the DoDAF, the NAF, etc.) or graphical notations (SySML).

9.3. Implementing systems engineering

Through this incomplete and at times imperfect case study, which we have presented as a narration of the exchanges between fictional acquirers and suppliers, we have attempted to illustrate the systems-engineering approach to an original and representative system, showing a certain number of the challenges encountered in engineering complex systems. It constitutes a plea to restore engineering and systems architecture to their rightful place and to give them the respect they deserve.

This aspect seems particularly important to us in the world today and, in our opinion, is one of the factors that will enable us to guarantee competitiveness. Understanding, evaluating and making choices are the best ways of staying ahead in our capacities of innovation in order to confront a world that is increasingly open in terms of competition.

More generally, this seems to us to be one of the last liberties that remain in our increasingly complicated, or even complex, artificial environment, where our capacity for production sometimes exceeds our capacities for representation and abstraction [AND 02], and to which we are often subjected rather than mastering.

The purpose of systems engineering, its adoption and use within an organization should not be seen as:

– an attempt at justification, to “sugar coat” or promote certain solutions;

– a medium or vector for communications between disciplines or different actors through the representation or management of information.

Nor should systems engineering be seen as a form of “super-engineering” or as the be-all and end-all of engineering. Although systems engineering is over 60 years old, it is far from being the oldest of the engineering disciplines. It does not aim to override other forms of engineering, as it does not apply to the same levels of abstraction and does not operate in the same ways; systems engineering stops at the point where other forms of engineering take their natural place.

We have attempted to show that:

– Techniques and methods exist in systems engineering (the body of knowledge is not as small as it initially appears). Unfortunately, not all are widely known or taught, and may be hidden from view by incorrect ideas (confusion of management and engineering, confusion between representations and models for reasoning). In this respect, we hope that this work will raise reader interest in discovering, learning or deepening their knowledge of these techniques and methods.

– Systems engineering is a subtle balance between an art (capitalization of knowledge) and a science (the use of formal techniques, mathematics, etc.). None of this would be possible without the considerable talents of systems architects and those who direct and coordinate different disciplines. Their understanding of the disciplines involved, their ability to interact with actors from these different disciplines and their ability to place all of this into relief while mastering various interactions, make them key actors in the successful development of complex systems.

Systems architects, of today and tomorrow – over to you!

9.4. Acknowledgements

Firstly, we wish to pay our homage to two individuals who have played a major role in the development of systems engineering: Alain Faisandier and Jean-Pierre Meinadier, who contributed a great deal by teaching and spreading knowledge of systems engineering, both in France and abroad.

We also wish to thank all those who have supported us in this madcap adventure, sometimes unknowingly.

We all occupy teaching posts or give occasional lectures in higher education, and we have made use of this case study as a guiding project, a teaching support used to integrate our various contributions. The hours spent with our students or interns were particularly enriching. Their questions, at times naïve but always relevant, challenged us constantly, pushing us to do better, helping us to build on our practical abilities in order to transmit this knowledge, which is not without its challenges. Thanks, then, are due to our students at Supaéro and the ENAC (Ecole Nationale de l'Aviation Civile).

Thanks go more directly to:

– Jean-Philippe Lerat, Valery Rault and Laurie Baudoin of Sodius, the company responsible for the MDWorkbench For Defense systems engineering platform, for their support; all views (functional, physical, service, temporal, etc.) and tables have been extracted or generated using a system model created using their platform.

– Robert Darimont, of Respect-IT, for his attentive re-reading, support and the details he was able to supply in relation to KAOS methodology.

– Yves Gourinat, professor at the ISAE (Institut Supérieur de l'Aéronautique et de l'Espace)/Supaéro and honorary president of the “Earth and Space” association [T&E 09] for allowing the main author of this work to participate in a scientific mission in the Arctic at Ny Ålesund (Aerocrew Mission, December 4-7, 2007 [GOU 10]). Thanks are also due to Rainer Vockenroth, director of the AWIPEV arctic base at Ny Ålesund for his warm welcome.

– Friends and colleagues, who assisted us by rereading the manuscript and providing us with corrections and valuable comments, including Claude, Dominique, Thierry, Thomas, Rafael and Sonia.

– Last but not least, we should not forget our friends and family, who have supported and put up with us throughout this project, which has been a part of our daily lives and, often, of theirs too!

9.5. Bibliography

[AND 02] ANDERS G., L’Obsolescence de l’Homme, (original title: Die Antiquiertheit des Menschen, 1956), DAVID C. (trans.), Encyclopédie des Nuisances, IVREA, Paris, France, 2002.

[GOU 10] GOURINAT Y., APEL U., DELBART F., “The aerocrew mission: training space session at Ny Aalesund Arctic base”, Acta Astronautica, vol. 66, no. 1-2, pp. 74-77, 2010.

[PLA 02] PLATO, La République, Flammarion, Paris, France, 2002.

[T&E 09] ASSOCIATION “TERRE & ESPACE”, terrespace.free.fr/, 2009.

1 Chapter written by: Jean-Luc WIPPLER.

1 A new contemporary organ, built by Daniel Birouste, was inaugurated at Sylvanès in 1997