5.1 Why Understanding What Does the System?
Functional architecture, or equivalently functional analysis, intends to describe precisely the different functions of a system and their relative interactions1And also how these functions are connected to missions. This point – even if important – will however not addressed in this pocket guide since it can be easily addressed through a suitable allocation matrix. The core motivation of functional architecture is to start understanding and specifying in details the system, but only in terms of behaviors – i.e. in other terms, to understand and specify what does the system – and not of concrete structure, i.e. in its functional nature … as one would have easily guessed! It is indeed important to have first a functional description of a system, and not to dig immediately in the technique, if one wants to be able to rationally manage trade-offs between different options2Functional architecture allows in particular to make early cost analysis as soon as one have an idea of the average cost of an elementary function (see also the Constructive Cost Model for Systems – COSYSMO – [79]). Such a feature is especially interesting for trade-offs that may also be done at functional level (in order to choose between two competing functional architectures for a given system).. Functional architecture is indeed usually independent of the technological choices3The car function “Produce torque” is for instance totally independent of the technology: it exists on a car either with a thermic, or an electrical engine. – at least at some level of abstraction – which means that functionally reasoning – of course at the good level of abstraction4As a consequence of that simple remark, functional architecture is absolutely of NO USE if its analyses go too much in the detail. Detailed functional architecture indeed 1) either overlaps with constructional architecture as soon as detailed functions identify with the high level functions of the components of the considered system, 2) or be totally misaligned with its constructional architectural (which means that the identified functions do not naturally map with components). In the first case, functional architecture overlaps with constructional architecture since the two analyzes do provide exactly the same semantics. In the second case, functional architecture is dangerous since its results – which have here no concrete value – may mislead the system designers. In the two case, it is therefore a waste of time and money – on a system allows to reason at the same time on many different constructional options that we will be able to compare and to evaluate later (see Chapter 7 dedicated to these trade-off analyses). One must indeed understand that skipping functional analysis by directly going to technical design is a very bad practice, even if widespread in engineering organizations, since it just means that one makes a very strong design choice without even being conscious of that choice. As a consequence, one will just be glued in that choice, without being able to move to radically different options that may be more adapted.
We must also stress that functional architecture is absolutely fundamental to capture emergence and transversal behaviors that can only be modeled using its tools. By definition, all emergent behaviors can indeed not been captured by constructional architecture since they are functional properties of an integrated system (we refer to subsection 0.2 for more details). One must hence use functional architecture to describe and model such properties. As an immediate consequence, functional architecture is key tool to structure transversal collaboration in an engineering organization whose purpose is indeed just to manage efficiently the emergent transversal behaviors of a system.
Last, but not least, functional architecture also allows to organize a system in functionally decoupled – as much as possible – sub-systems. This is very important if one wants to avoid too many impacts when there is a change in a system design5 See the first case study of Chapter 6 to see what can unfortunately happen in case of a design evolution …. This idea gives rise to layered functional architectures where each functional layer is strictly functionally segregated from the other ones by rigid standard functional interfaces that are managed in configuration. This architectural functional segregation / decoupling principle provides huge flexibility: in an ideal world, one will indeed be able to change a function in one layer without any impact on the other layers, as soon as the functional interfaces between layers are respected. We refer to the concrete examples of systems organized according to such a principle – that is to say computers, mobile phones or communication networks – that are provided in the functional architecture subsection of section 2.2
Transversal Behaviors are Crucial to Master: the Airport Radar Case
ALTHEIS is a leading airport radar company in the world. They developed a new airport radar on the basis of a modular generic functional architecture, each generic functional module being devoted to a certain part of a radar treatment chain and managed by a dedicated engineering team. The idea was to replace development, when dealing with a specific radar deployment, by parametrization. Each generic functional module had thus to be specifically parametrized when instantiated on a given concrete airport application.
However the overall amount of parameters to manage was quite high: around one million elementary parameters that could be organized in around 50.000 high level parameters, each of them with a specific business meaning, were indeed managed by the development engineers. This huge complexity lead initially to what could have become a real industrial disaster: when a radar was parametrized and put in service, it happened that the radar never stabilized since bugs were permanently appearing on the field which regularly obliged the radar to go back to the factory to be reparametrized, which could only be done by the development team due to the technicity of the parametrization. This situation was terribly uncomfortable and clearly economically not sustainable6A radar business model is indeed based on first a fixed initial price that just covers the development costs and secondly yearly maintenance fees on which the constructor is making its benefit. One can thus easily understand that permanent bugs are just destroying the radar business model..
CESAMES was appointed to analyze and to try to solve that issue. It appeared that its root cause was connected to the lack of a shared and explicit radar functional architecture. When the parametrization was initially done, each team in charge was indeed not conscious at all of its functional interdependence – through transversal functions – with the other teams. As a consequence, each parametrization done locally at the level of one team was in conflict with the other parametrizations, which lead to the observed problems.
The solution – provided by CESAMES – was to architecture all parameters in alignment with the radar Functional Breakdown Structure (FBS), by clustering the parameters according to the different functions of the FBS. A parameter architecture team – managed by a functional architect – was then created to manage, guarantee and maintain among time the functional coherence of each of all these parameter clusters.
Case study 7 – The Airport Radar Case
TABLE OF CONTENTS
REFERENCES
[79] Valerdi R., The Constructive Systems Engineering Cost Model (COSYSMO), Quantifying the Costs of Systems Engineering Effort in Complex Systems, VDM Verlag Dr. Muller, 2008