SAF and RFLP #62
-
|
A general question for someone wanting to use SAF. I've been modeling systems using RFLP approach which is what SAF is pretty much all about. Question: RFLP is a multilevel approach with levels such as context level, system level, subsystem level and component level. Follows the Vee cycle downhill. Each level has RFLP and decomposed further down each subsequent level. |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
Aligning SAF with Multilevel RFLP ApproachMultilevel RFLP Approach
Mapping SAF with RFLP Approach at each Level
This mapping aligns SAF viewpoints with the RFLP approach across multiple levels, ensuring that each viewpoint is appropriately placed within the systems engineering process. |
Beta Was this translation helpful? Give feedback.
-
|
Hello Anas, thanks for contributing to SAF. |
Beta Was this translation helpful? Give feedback.
-
|
Hello Anas, In most use cases of SAF the OD stays the same and is not part of the recursion that happens when diving down into the systems decomposition. The OD is about the business, concepts and organizations and stories of an organization that might operate the SOI or a super system of the SOI. Only the Functional, Logical and Physical Domains are repeatedly visited in such a recursion. To give an example, the Operational Stories stay the same, regardless if the SOI is an autonomous streed car, or if the SOI is a LIDAR sensor on that hypothetical car. Regardless of the level of the SOI in a total system hierarchy, it is important to understand something about the intended operating environment and the operational stories that could be told. A Sensors requirements would need to suit the operational environment, the car might be used in. Even for a tier n supplier it is important to validate the understanding of upper level requriements with a aquirer to keep risks under control. We had a presentation about a similar situation, at the german INCOSE Chapters conference TdSE in 2021, unfortunately the presentation is in german language. https://github.com/GfSE/SAF An other case would be if the SOI is part of multiple system hierarchies with totally different operational domain uses. This might be the case if the abovementioned sensor is part of a product line and also sold to an OEM building autonomous warehouse transportation robots. The operational environments would differ drastically, and require separate OD content, but linked both with the sensors functional domain (FD). The sensors FD model then would adress the different immediate system contexts from the perspective of the Sensor, and link to the respective OD model parts. There would be multiple contexts contexts needed for the use in the street car (road, workshop, garage, transport of car ..) and the contexts of the use of the sensor in the robot ( in warehouse, yard transit to other warehouse, shop maintainance, shipping of robot, ...) |
Beta Was this translation helpful? Give feedback.
-
|
Hello Anas, Pure RFLP approaches have in my opinion some weaknesses, which we try to avoid in SAF. The idea to first have Requirements on a level and then derive functions from that does not work well with MBSE. In SPES a major MBSE project using RFLP, they have put the necessary analysis into the "R" viewpoint (spes has only 4 viewpoints) They state, that they separate strictly between requiremensts and parts of realization of those requirements. My conclusion is, that this lacks any separation of concerns and lacks a clear idea where the definitive set of requirement is, and how it is elaborated. |
Beta Was this translation helpful? Give feedback.
-
|
@haarer So a function at the system level has stereotype (systemFunction) and function at subsystem level has (systemPartialFunctional). what about logical and physical domains for all levels? |
Beta Was this translation helpful? Give feedback.
-
|
Am 24. Juni 2024 12:13:19 MESZ schrieb Anas Bin Iftikhar ***@***.***>:
@haarer
Thanks for such an elaborative explanation.
So what I understood is that, in the MBSE lifecycle, OD is non recursive. The other 3 domains are recursive from system down to component level, is it right?
Now the only challenge remains is the semantics (specifically stereotypes). Are these embedded into the SAF framework?
This is what I understood from an example:
So a function at the system level has stereotype (systemFunction) and function at subsystem level has (systemPartialFunctional).
Am I Right?
what about logical and physical domains for all levels?
--
Reply to this email directly or view it on GitHub:
#62 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
FD, LD and PD are recursive, yes.
The partialFunction stereotype ist used only for subfunctions within FD, that are not realized by a Subsystem.
Anything that is realized by a Subsystem is again a system function.
Note, there is currently a stereotype SOI, which is a bit misleading. SOI should only be a property of a usage of a system within a context, not a property of a system. (when focusing onto a partial system, *that* ist the SOI.)
…--
Gruß,
Alexander
|
Beta Was this translation helpful? Give feedback.
Hello Anas,
in part 2 of my answer i'd like to comment on RFLP and SAF.
Pure RFLP approaches have in my opinion some weaknesses, which we try to avoid in SAF. The idea to first have Requirements on a level and then derive functions from that does not work well with MBSE.
What works is to analyse the functional need of the contexts with stories (use cases), refine them into activity models which define the functional need of the context more formally. The resulting exchange then can be consolidated into systems exchange need and interfaces, the functional need can be consolidated into systems functions, broken down to a level of understanding and agreement.
Then, when agreement and underst…