Dear Bruce,
I have some problems with abstractions/ kinds of subsystems, especially with logical and physical. The reason is, that logical subsystems often map to multiple physical subsystems and a physical subsystem can contain multiple logical subsystems.
In one of your SE book there is an example for physical subsystems.
[...]
For example, an automotive braking subsystem will contain mechanical (brake pedal, braking pads), hydraulic (pistons, o-rings, pump, fluid reservoir), electronic (ECU,2 pedal position, wiring), and software (ABS) components
[...]
(1)
With this description, I would model an _subsystem and components view_ that has separate components ECU and software, even if the software do run on the ECU of course. I would show this relation in an separate view? What is necessary in Handout and is it an SE or SW task? It is always difficult for me to separate Systems Engineering from native downstream disciplines.
(2)
When I show logical subsystem, then it may be possible that a subsystem contains hydraulic, electric parts and SW. In a _deployment view_ I have to identify the engineering disciplines. Right?
(3)
Which possibilities can I use to show the relation of logical parts of deployment view and physical components?
Thank you very much!
Best regards
Matthias
Hi Bruce,
thank you, this is a great explanation!!!
And how would you organize your rhapsody projects now? I mean beyond the common Harmony structure. Do you prefer separate rhapsody projects and use a common workspace? For me it is difficult to make a clear separation of events, interfaces, types, etc. on the one hand and have a good traceability (represents) on the other hand.
What do you think about this?
Thanks!
Best regards,
Matthias
Hi Bruce,
I do have again some trouble with different abstraction levels, kinds of subsystems (functional, logical, technical) and moreover with a clear system scope and the correspondig actors.
When I look for example at an Adaptive Cruise Control in a car:
On very high level (maybe logical/functional) I analyze and design the system regarding events from its environment like "preceding car accelerates" "preceding car decelerates" "preceding car changes lane"
On a more detailed level (maybe logical/technical) I do have some environment radar sensors and events from the outside world like "object detected" with attributes and I need to interpret it internally in order to get the information, that I have a preceding car that decelerates.
For me it is very difficult to work on different levels, and find proper representations for the different abstraction levels.
Bruce what are your experiences here? Which guidelines do you suggest?
Thank you very much.
Best regards,
Matthias
Doh! When I said above " During the hand off, the deployment architecture and physical architectures are created, although at this point, the internal details relegated to those engineering disciplines are defined. " what I MEANT TO SAY was " During the hand off, the deployment architecture and physical architectures are created, although at this point, the internal details relegated to those engineering disciplines are NOT defined. "
Remember "logical" and "physical" are terms only vaguely defined and can be used for system architecture as well as software architecture. Having said, that, let's answer your question in terms of physical architecture.
Yes, a logical subsystem can - and should - contain elements from multiple engineering disciplines. Generally, this is ONLY shown in the deployment view because for the most part, the systems model is about system properties. During the hand off, the deployment architecture and physical architectures are created, although at this point, the internal details relegated to those engineering disciplines are defined. The deployment architecture 1) identifies the engineering disciplines involved by identifying what Harmony aMBSE called "facets"; 2) requirements are allocated to those facets, and 3) the interfaces between the facets are characterized.
Any software facets so defined are physical from the system perspective but still logical from the software POV. Software architecture and design are needed to fully flesh out their structure.
Dear Bruce,
thank you very much.
I agree with your rule to match logical and physical views as close as possible. At least when it comes to deployment views one can see how good everything fits together or is kind of fuzzy.
Regarding the example above: It is possible that a logical subsystem contains brake pedal (mechanic), sensor (electronic) and software parts (software). For me it is still difficult to see, that the software parts belong to the brake subsystem at logical architecture and of course to the ECU at physical architecture.