The Two Types of Functional Decomposition
HTML-код
- Опубликовано: 27 авг 2024
- In this video Brian Moberley and Dr. Ron Carson discuss the two types of functional decomposition.
#STC #RonOnRequirements #functionaldecomposition #cameo #MBSE #SystemFunctions
Thank you so much for this video. Amazing to listen to Dr Carson thinking aloud on Brian's question about a stakeholder giving the design requirement :" We want the ATM to have a finger print scanner" 🤩
Hey Gentlemen, I really loved the discussion on the two types of functional decomposition that had taken place in this video. Dr. Ron Carson responses were really well explained and very clear. I really appreciate this video discussion. Thanks Dr. Carson and Brian for sharing this content with the Systems Engineering community.
Of course! Thanks for listening in!
A few words about observability. While I agree that it is crucial for system verification, not every system function needs or can be directly observable. Some functions are only observable through their interactions with other functions. For instance, consider a function F1 that, while performing its primary task (control), detects a fault within the system. This fault is manifested externally through system fault reports and alerts. It's not necessary for F1 to produce the fault reports and alerts itself. Function F2 might be responsible for system fault reporting, while function F3 handles system alerts. Thus, F1's outputs (detected faults) feed into F2 and F3, making F1 observable externally only through these other functions.
Another example of a function that is not directly observable is the "Receive Some Data" function :) We follow communication protocols and perform data integrity and freshness checks to ensure the input data is available. These protocols and data checks deserve a separate function, at least on a lower level of decomposition, possibly as a software function.
Excellent explanation. I've seen many systems engineers, system architects, and program/product managers who misunderstand this step and rush immediately to a specific implementation, prematurely settling on a functional architecture that is suboptimal at best and at worst may not meet the ultimate mission need and require costly design changes late in development. The "two types of functional decomposition" explanation is useful vocabulary for expressing this to the systems engineering team and project stakeholders.
Great conversation Brian! This definitely changes the way I think about decomposing functions and how tightly coupled they are to the structural architecture. Keep up the great videos!
Intersting perspectives for sure and thanks for putting this together!
Another approach is bottom up, where leaf level use cases form the foundation, then the leaf level functions are grouped into parent level functions according to their anticipated physical allocations and/or with the aim of achieving tighter binding at higher order levels and looser coupling with/among themselves. We also must track / manage inputs & outputs making sure nothing is lost in the translation from groups of children to parents on upward to the system boundary/context level. We also must keep an eye out for duplicated or misplaced groupings and modify accordingly.
Great video, thank you for the explanations!
Very good explanation from Dr. Ron Carson. However, I experience that lots of system designs are struggling with the approach to having "observable" functions. You mentioned at the end of the video, that there shouldn't be a function like "Validating", because it is not observable on the system boundaries. But we are building the logical (resp. the technical) architecture based on the functional architecture. So how to justify that we need somewhere a "processing unit" if this is not needed for the "sending" of the output?
Another question would be the level of decomposition. I often get the demand from functional safety (automotive) to show the critical path and the correlation of safety integrity between in- and outputs. So even if I can allocate all in- and outputs to one single logical element, it is necessary to show which input signal has an effect on the output signal to prove FFI. To have a function-block with inputs at different safety level, it complicates the analysis and a further brake-down could show, that e.g. only certain signals have an influence on certain outputs. Sometimes hard to give this part of the jobs to the domains... How does functional safety influence this topic in your point of view?
Is it possible to create a parametric diagram so that we can show Q = 6 where x = 1 - 3, y = 1 -2, and z = 1 - 2. And to show all the possible combinations of this. Almost like a monte carlo simulation. I've been trying to complete this challenge for a while - if anyone has any ideas how this could be done, I would greatly appreciate the help.