Assigning A Function To Multiple Components

Hello,
In Logical Architecture, is it possible to assign one function to more than one logical component?
If not, what would be an alternative for that?
This would be needed in cases where a similar behavior may be achieved by different means.
As a basic example: let’s say a car has a function “Cool down the internal environment”. This could be achieved by the windows (when opened), by the fans or by the air conditioning (or by a combination of these). However, it wouldn’t make sense to group these components under the same logical component.
In aeronautics, the guidelines on ARP4754A allow the allocation of a function to more than one system/component and even call for “functional independence”, in order to minimize the likelihood of a common error. A classic example is the function “Decelerate on the ground” which could be performed by wheel brakes, engine thrust reversers and ground spoilers.
Any response is welcome.
Thanks.

Hello,
It is not possible to allocate a function to more than one component.
The same question was asked recently and answered from a methodological point of view in this post:
https://forum.mbse-capella.org/t/508/
In the example you provide, I would say that “Cool down the internal environment” is a capability of the system that can be ensured by at least two functional chains which involve the windows for one, and the fans of the air conditioning for the other. Indeed, the fans may not be the only component required in order to ensure to cool down the air. The air conditioning power supply may also be necessary as probably other ones…

To go one step beyond Aurélien answer (that I fully share), you could consider what each function really describes, and consequently how and where this should be captured. Clearly separating need from solution is sometimes a way to address such issues.
“Cool down the internal environment” looks to me more as an expectation on the system or on a component (hence Aurélien suggestion of using a capability to express it), so it would be at its right place in System Need Analysis (SA), either as a function or a capability.
In logical or physical architecture, where you want to describe the way the system and components fulfil this need, you are likely to rather define “solution oriented” functions, such as “let air enter the compartment”, or even just “open” (for the window), and “create an air stream in the compartment” (for the fan).
Similarly, “Decelerate on the ground” is an expectation on the system, that can be described as a system capability and/or a SA requested service function. In architecture perspectives (LA, PA), this need would lead to functions such as “slow down wheel rotation” (allocated to Brakes component), “reverse thrust” (allocated to engine reversers), and “increase drag” (to spoilers).
Another subject is implementing constraints dealing with safety and fault tolerance issues, as required in ARP.
If you want to implement redundancy for this purpose, for example, then you can
create a set of functions or functional chain to be redunded,
build a Replicable Element Collection (REC) from this functional chain,
and duplicate it into as many Replicas (RPL) as redundancy needs;
then connect functions of each chain to sources functions (e.g. sensor functions) and destination functions (e.g. vote or monitoring functions). each functional chain is allocated to different components so as to implement independence and diversity.
This way, the functional contents of each redundancy chain is ensured to be kept coherent with the reference REC (because synchronisation is maintained between them), and yet each chain may have a distinct state (operational, in failure, ,degraded…), what would not be possible if just allocating one function to several components directly. Furthermore, this allows to describe to which source each chain is linked, and to which port of a vote or monitoring function each is linked. No easy means to do so when just allocating a function to several components…

Thanks Aurélien Pinsonneau & Jean-Luc Voirin

Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.