Think out-of-the-helicopter
Modern helicopters are not anymore a mecanical #aircraft, but a #system of systems, a complex system of systems.
Even for civil helicopters, they are more complex, as shows the H160 payload : even the aircraft is 2 tons heavier than H145, it has the same payload of 1.7 ton.
The #Helicopter need to be redesigned in accordance with his new definition : a system of systems.
For example, with #FlyByWire technology and the improvement of electrical engines, is the driveshaft still required or can the tail-gearbox (at the tail-rotor) be replaced by an electrical engine such as the wheel-engine used in electrical cars ? (those wheel-engines can provide torque force)
But this example is not the topic of this article :
I will develop here on #complexity and #architecture design of a system of systems.
The #modular approach (both on design & processes) enables to split a system into a set of subsets, which are (almost) independants of each others.
The 2 most well-known cases of use are Car Industry and Computers (enhanced with the « plug-and-play » solution).
– OK, but an helicopter is much more complex, with lot of more components and flying issues (to make it short, helicopter flight is a unstable system) !
– That’s why it must be designed all the more through a modular approach.
NH90 sample :
Each #NH90 variants has some specificities that make the helicopter dedicated to a variant (iow. a customer) since the airframe.
It means that since the early start of assembly, it is dedicated to a variant and can not be re-oriented to another one.
Worst : all variants are independant, so each of them need to be qualified.
So, can we say that an helicopter such as NH90 has no module ?
Yes and no… :
For example, as you might know, NH90 proposes 2 engines : The RTM332, or the T700…
… But, of course, it has impact on other design aspects :
- fasteners,
- piping,
- harnesses,
- up to cowlings
- You can not replace a RTM332 by a T700 (w/o making a list of modifications)
- Same thing for Flir and other missions equipments, even other Flir (or missions equipments) a qualified on other variants.
That’s why, even if the engine could be considered as a module, the NH90 architecture around the engine is not modular.
To be modular, cowlings and other items in relation with the engine should have been able to support both engines (or being part of engine module, which means able to be changed easily with a minimum of operations).
In fact, in that case of a kind of « plug-and-play » subset but not interchangeable, we don’t speak about « module », but « kit ».
On NH90, like many other helicopters, the engine, Flir and missions equipment are kits.
Each option, additional feature, dynamic element or data, grow the complexity, raise it through an exponential curve.
About complexity :
Each option, additional feature, dynamic element or data, grow the complexity, raise it through an exponential curve.
Basically, if you have 5 degrees of complexity, you have 5 axes of statuses, so you can evaluate this environment as 2^5.
To illustrate that :
- a line is defined by 2 points on 1 axis, 2^1
- a rectangle, a geometric plane, or a 2-axis graph is at least 2^2
- a volume, 3D graph, 2^3
Curves of complexities
- Note the blue curve showing basic complexity
- The violet curve is the case of no impact between features
- While the red one is often how people almost expect, or even hope, that combinations will improve, enhance, if not simplify…
… So they add, add more and add again, endingless, features to the system.
That's typically the case of the F35 engine :
Initial program planned 2 engines in competition in order to reduce costs...
Finally it generated cost deviations so it has been decided to keep F135 only and cancel the F136.
The Modular approach :
As you might know, it does decades that cars industry answered to the problem of complexity through a modular approach.
Computer too ; enhanced with the plug-in system that enables you to easily upgrade it.
Those 2 cases are well known (and referent of modular approach), so I will not enter in depth on them.
We can summarize a system to a set of axioms, which means a set of factors with relations (data exchanges, mechanical links, flying constraints…).
It’s a kind of cube Rubik, and the modular approach is the solving : you redefine the cube in order to get coherent faces.
A modular approach is to define the system as a set of subsets (which can also be sets of subsets), according to degrees of complexity (such as options or inherited constraints), and enabling to act on a module (modify it, redefine, reorganize it…) without impact on others (since there are no change on its interfaces).
#NH90 opened the way of #Integrated and #ObjectOriented (modular kit) approaches helicopters, which are keys of #Next-Gen #Warfare systems
— Julien Maire (#Julien Maire) 23 octobre 2012
For helicopters, the use of modular approach is still limited, but slowly grows :
- On NH90, the ASW kit can be mounted / dismounted within 2-to-3 hours, even it is a large kit.
- More recently, #AirbusHelicopters qualified its #HForce system :
Basically, it is (as far as I know) a « plug-and-play » of differents weapon pods, available for different helicopter classes/range.
Here we are ! A start of modular approach :- replace a pod by another on an helicopter
- same pod that can be applied on another helicopter class, version or variant
But today, the modular approach on helicopters, such as HForce, is almost limited to some external equipment.
It is still far away from a #Flexible and #Lean system {*}.
#Julien Maire > "plug-and-play" sub-systems are already used for some multi-role and/or missions data but not for full aircraft development
— Julien Maire (#Julien Maire) 23 septembre 2011
However, some ways are on : H160 and H160M HIL are expected to enhance the modularity on helicopters :
- #H160 is expected to be designed through a Lean approach, with modularity both on the helicopter and the processes, up to the maintenance aspects.
Time will answer if it is a « true modular » design or more a « kit » design… - In addition, #H160M is expected to offer a flexible answer to #HIL, designed around a single and common airframe.
Definitely, NH90 feedbacks and Retex regarding ‘Golden rules’ and ‘fails’ will help those projects.
And about other aircraft, such as Rafale ?
Rafale was expected to be versatile, with reduced maintenance, through an almost modular approach.
It partially failed as its maintenance factually needs 12 technicians instead of the 7 expected.
But partially succeeded as its maintenance can be operated even on the aircraft carrier Charles De Gaulle.
How to optimize the complexity through a modular architecture ?
Evaluate the complexity of a design :
There are different methods to evaluate complixity or complication (actually, some don’t evaluate the complexity but the complication). Most of them have been defined to evaluate algorithms or databases efficiency.
I propose here my own method that can be applied easily :
- For each element, give a weight :
- based on its criticity in the system, according to a QFD analysis ;
- or of 1 + number of other elements with which it interact ;
- or, at least, weight all elements at 2 (useful for a initial analysis, but might be unable to evaluate and rate different architectures solutions).
- Elements within a subset are linked by multiplications
- While the sum symbolize links between subsets
Quality Function Deployment : an easy-to-use tool to evaluate engineering (How’s) criticities
What is an « element » ?
It is up to you to define the depth of the wished analysis.
It can be up to components ; but mostly it will concern a list of golden/key items that define the system (for the helicopter : that influence the flight or the missions abilities).
According to that, the relations can be mechanical constraints and/or data exchanges, the system definitions (flight, missions…).
Limits of the method :
It can not be applied to analyse a « 3D » model, with subsets of subsets.
In such case, you have to consolidate the different layouts evaluations.
An enhanced method can evaluate, imperfectly, 3D models :
- Multiplications will then represent all links between interactions
- While the sums are for strictly independant elements
(by default, in the case you can not ensure a strict independancy, then it will be a multiplication) - Subset has its own weight, which is not the result of its elements but :
- The average of its sub-elements weights
- The median of its sub-elements weights
- The N-root of the subset result, where N is the number of sub-elements)
- Or, here too, the number of its external relations, or 2
Basic modularity methods :
2 methods enables to easily identify « cells ».
(Some too complex systems might not give solution)
Method of Kuziack (source : « Gestion de Production », by M. Pillet)
- Method of Kuziack :
This method is used in industry to identify and define cells of machines according to the flows.
(Note that, instead of binary values, you can use weight the relations (see after) in order to enhance the method). - Method of King :
Another method from industrial cells using a similar approach of ranking machines and flows.
Those 2 methods are able to design on 1 layout only.
But, they can be adapted to approach a multi-layouts (subsets of subsets) model.
About « noding » :
The use of « hubs » or « nodes » is a key element of the modularity.
You will tell me that it is already applied on helicopters : typically, the MAB.
However, I will say no : not in term of global modular design :
Remind the NH90 engine and its cowlings or piping…
A modular architecture would have define a piping « node » making the final junction between the piping and the engine. This node must be almost plug-and-play and is part of the engine subset, not of the common core.
The Noding does not limit to concentrate harnesses, but as it is named : it is a node, between the common design and the module options, the junction.
It is like your computer screen :
Your computer has a video output (i.e: DVI), which is fix. While all screens do not have necessary the same design. And you use a junction, the cable. And maybe with an adaptator (from DVI to HDMI).
So 2 connectors :
- the cable, for physical positioning
- and the adaptator, for conversion
It’s the node, which joint and mix constraints from the module to the common design (or another module).
Lessons learnt from coding and networks architectures :
On first, I am not a programmer, so these explanation might not be exhaustive.
… But I will come back on that aspect at the end of this article 😉
Modular and object-oriented architectures have evolved since 2 decades. Especially on computer sciences :
Today, large databases or softwares (i.e: SAP) and networks have modular architectures.
MVC
With complex (and complicated) programs codes, huge improvements on the architecture have been done, related to the « #ObjectOriented ».
Basically, it starts by separate the requests to database, from the exploitation of these data, the formats styles and the sheet structure.
This kind of pattern is named « Model-View-Controller« .
| MVC | coding | helicopter |
| Model | database | interactions with external environnement :
|
| View | display | display to the crew |
| Controller | data exploitation | internal system :
|
… And the Airframe ? Except the stealthness, the airframe results from your system architecture.
Then you organize your Model (database patterns can be used), build templates to organize the display and router to organize your controls.
These two organizing are usually designed in order to avoid redundancies.
It is important to follow as much as possible a split between the 3 MVC features, in order to facilitate maintenance and upgrade.
However, this pattern can not be fully applied, as there are some almost autonomous equipments (such as pods, Flir…) that mix Model and Control.
Computer sciences are certainly the most advanced on modular modelling.
The Modelling pattern :
Another approach is the system modelling (note : « Modelling », because it usually concern the database, the Model).
To summarize, it consists of modelling a system into a kind of database, with data and relations.
Fully Object-Oriented might faces to limits that might the modularity reduced to a nut, so fail.
Since the initial Object-Oriented pattern, more efficient patterns emerged :
especially Object-Relational and Component-Oriented, which are more adapted to helicopter system.
These two methods more or less balance between autonomous subsets and object-oriented core, so they can support equipment such as pods.
The architecture must be « human readable ».
Back to the helicopter context :
Helicopter is much more complex, and complexified through 50 years of evolution without really redefine the paradigm : switch from an helicopter with capabilities to a system of systems.
Compared to a network or a database, it has lot of more degrees of complexity.
At least, on primary degrees, there is the flight mechanics and dynamic, and the center of gravity.
It is those Primary Degrees that will define the subsets.
To make it short :
While a program modules are defined by the features (MVC) and the flows of data (2 primary degrees),
Helicopter modules will be defined at least by :
6 degrees.
Both concepts of Modularity and Lean answer to such complex systems :
The architecture must be « human readable ».
It means that you should :
- Reduce the number of degrees, if possible.
For that, analysis such as QFD or Taguchi can help to eliminate a degree or group 2 degrees. - Another way is to split degrees into different groups.
… Make architectures according to each group
… Then consolidate those architectures into a single one by considering each group as a degree.
To conclude :
Helicopter is a complex system, maybe the most complex one due to its flying specificities.
However, difficult has never meant impossible. « Who dares wins »
That’s why I titled this article « Think out-of-the-Helicopter » :
Redefine the paradigme ; overpass the primary feature ; today, rotary flight is just a part of the helicopter system.
I presented 2 levels of methods :
- #agile methods that enables to quickly give a first raw answer :
- Evaluate either system or architectures complexities
- 2 Industrial celling methods, which, even « flat », can be easily adapted
- Object-Oriented principles used for large and complex networks, databases and softwares.
Once again, if helicopter has some special degrees complexity, these methods work and have proven their efficiency.
In addition to that, I strongly recommand to enhance a project team, a design office, with a large-database architect or a network architect.
These profiles have strong knowledge and skills regarding modular architectures design and will approach the helicopter out of the box.
Think Globally and Act Locally
What benefits to expect ?
All the benefit as expected for HIL, with an harmonized rotary-wing fleets, and more :
- reduce the number of platforms dedicated to each missions roles and their specificities
- imrove the versability of the fleet (to re-balance between differents missions as they might be less dedicated to a specific use)
- improve the interoperability of the different fleets (since they use the same pods or sub-systems, even of the fleets classes)
- reduce maintenance operations (due to Lean and Object-Oriented basics)
- while improve availability (due to the easiness of modules replacement in case of failure)
- reduce crews certifications (both on-board crews and maintenance crews)
- facilitate retrofit and fleet continuous improvements
Think Modularity,
Think System of Systems,
Think Globally and Act Locally,
Think « out-of-the-helicopter » !
Julien Maire.
Leonardo Da Vinci’s Aerial-Screw, 1493
{*} Lean, Flexible and Agile :
Let's come back shortly on these terms :
Lean is the avoidance of wastes : redundancies, useless data, unused process, non-pokayoke process, misuse, non-value-added...
Basically, modular approach is Lean.
But a mis-application of modularity can genrate wastes ; especially, a too "deep" model (too many layout) can generate non-value-added, lost of time-to-respond...
Keep in mind to build a Lean architecture.
Too often, Agile is misued to say "Flexible" (which means "adjustable", "almost versatile").
Agile regroups differents methods which does not have the same approaches, nor the same close goals.
(It is largely use today, as it give quick response, especially on smartphone and Apps')
Basically, it consists of giving early uncomplete reponse, which then you complete and improve continuously.
It also supposes developping small functionalities, more or less independantly, which you consolidate, and then fix, improve or enhance.
Agile methods are useful for some complex and not well-defined project, typically for research & development or maintenance.
However it is not adapted to aircraft as it continuously redesign the architecture.
On top, some Agile 'users' make confusion between speed and rushing, which may cause safety issues.
