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
Matthias ,
(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.
Bruce: The definitions of logical architecture is, by its nature, fuzzy. Given the example you reference, it is possible to have a singular Braking Subsystem that decomposes to several physical subsystems with a number of ECUs, or one could have a closer 1-to-1 match between the logical and physical subsystems. It really depends on the difference of abstraction level between the logical and physical perspectives.
At minimum, where the logical and physical subsystems are at a 1-to-1 match, the interfaces are distinctly different; the logical interfaces are modeled simply (often as events carrying data as necessary) but the physical interfaces map directly to the technology (such as specific bus messages but corresponding bit-level mapping). At maximum, the logical subsystems are rather vaguely defined groupings of functionality that map many-to-many (a logical subsystem is implemented by many physical subsystems and each physical subsystem may implement parts of many different logical ones).
Personally, I tend for a closer to (but not completely) 1-1 mapping.
(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?
Bruce: Yes, that is the purpose of the deployment view.
(3)
Which possibilities can I use to show the relation of logical parts of deployment view and physical components?
Bruce: <<Realization>> is a metasubtype of Abstraction which is a metasubtype of Dependency. So you can use that; In Rhapsody at least, Realization seems to be a metasubtype of Generalization, since it includes the notions of inheritance and specialization, so it can’t be used. Why? Because generalization is very constrained. If a subclass contains an operation getWheelSpeed(wheelID):int then any subclass also contains it. But what if the subclass implements this service with a CAN bus message RequestData(RequesterID, TargetID, dataRequestedSpec) resulting in a HerezaRequestedData(RequesterID, TargetID, requestedData) message. These two representations – logical and physical – have the same intent – but vastly different structure. This means that anything based on specialization is too limiting.
So I use <<represents>> relation of my own for this purpose (a stereotype of Dependency). (It’s in the Handoff profile.) Because this is a new metatype (“New Term” in Rhapsody-speak), I can create tables to explicitly show these relations between logical and physical elements. Chapter 10 of the Harmony aMBSE Deskbook gives an example.
-b
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.
Best regards
Matthias
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.
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. "
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
Matthias,
I think this is a really interesting question and I have some thoughts on that 😊. First, from an epistemological standpoint, abstraction levels are a completely artificial construct. That means we get to decide what kind of conceptual hierarchy makes the most sense in light of the problems we’re trying to address. Having said that, I basically use the following criteria to decide what’s in a given abstraction level:
1. Conceptual – focus on key principles of need (what do I need to happen, in principle) and ignore functionality and structure necessary to achieve it.
2. Functional – focus on required functionality as ordered collections of “system functions” without regard to how or where internally those functions are implemented
3. Logical – focus on large scale pieces, with assigned functionality; this includes the cooperation of these large-scale elements in terms of ordered sets of that functionality. Interfaces and data elements, notably, as described in terms of their content and meta-properties rather than their actual (bit- or byte) realization
4. Physical – focus on the realization of logical and functional entities, such as the bit- or byte- format of interfaces and data, and algorithmic or state definitions of functionality (i.e. functionality defined in terms of behavior)
5. Detailed – Specifying – often at the machine level – the implementation of logical and physical elements; for example, this includes the source code that implements and algorithm, or the machine code that implements the source code
Levels can be added or subtracted, depending on the details and context of the problem to be solved. As an example, let’s consider the radar sensor for an adaptive cruise control:
1. Conceptual - the system must be able to detect position and velocity of vehicles in front and control the car speed to maintain both forward progress and safety
2. Functional – the system will be able to identify vehicles in front, their relative position and velocity with respect to “Ego vehicle” (the system instance), determine their impact in near term safety margins, and adjust ego vehicle speed accordingly
3. Logical – the system consists of the following subsystems: sensor suite, sensor processing, control logic, and effector control. Radar data is characterized by Identified_Vehicle which has the properties of id, range (in meters, range 1 .. 100m, accuracy +/- 5cm, lag < 0.5s), azimuth angle (in radians, range 0.0 to 0.8 radians off-bore, accuracy +/- 0.01 radians, lag < 0.5s), and velocity (in meters/sec, range -100 m/s to +100 m/s, accuracy +/- 1m/s, lag < 0.75s).
4. Physical – the sensor suite and sensor processing are located on one ECU while the control logic and effector control are located on a second; The CAN bus message for radar VehiclePosition message has the following bit format: … The algorithm for determining speed adjustment is ….
5. Detailed – the source code for the speed control algorithm in C++ is …
I do think its important to either explicitly or implicitly, be clear on the level of abstraction being used and to be careful not to mix levels. I use a stereotyped dependency <<represents>> to provide traceability across abstraction levels. In particular, SE models are generally Logical in nature, and the hand off process creates the Physical representations of those logical elements, especially the interfaces and data schema. Downstream engineering then realizes that with the Detailed abstraction level.
And, of course, each of the levels can have nested levels of abstraction, when appropriate. Remember that we introduce abstraction levels to help us conceptualize the problem. If you find a level of abstraction unhelpful, remove it; if you find you need more, add them.
As I said, it's an interesting topic and I can go on and on about it :-) I hope this was helpful.
- b
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