(c) Bruce Powel Douglass, Ph.D. 2019

Jul 16, 2018

arch design: logical/ physical subsystems

7 comments

Edited: Jul 16, 2018

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

 

 

 

Jul 16, 2018

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

Jul 20, 2018Edited: Jul 20, 2018

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

 

Jul 20, 2018

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.

Jul 24, 2018

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. "

Jun 27

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

New Posts
  • Hi! I am reading in Chapter 8 of Agile Systems Engineering, while simultaneously reviewing the example model TWrecks1.rpy and have some questions. in ibCommCoord there are three flowProperties called cmdProximalJointAngle:JointRadian cmdMedialJointAngle:JointRadian cmdDistalJointAngle:JointRadian These are combined into the message CommandedJointAngleMsg:CANMsg with the following mapping: Data0:unsigned char = Low byte Proximal Angle Data1:unsigned char = High byte Proximal Angle Data2:unsigned char = Low byte Medial Angle Data3:unsigned char = High byte Medial Angle Data4:unsigned char = Low byte Distal Angle Data5:unsigned char = High byte Distal Angle In paint it would look something like this: Now to my questions: Why are there no explicit relation between the logical flowProperties and the physical data? Wouldn't that kind of traceability be beneficial to know exactly how the logical data schema is refined into the physical? It feels unsatisfying on relying on the semantics of the text string to indicate traceability. If I where to add such a relation how would I do it in the best way? To I have tried to use «allocate» and «dependency» , but that can only be done between the interface specification and the flow property and not to the exact value (Data0, Data1, ...). See below: Thanks in advance! Best regards Markus
  • Suppose you have your system "S" that receives an event Ev1() and an operational contract called OP1(). During the architectural phase, you decide to fulfill the requirements with two blocks, B1 and B2. B1 receives Ev1(), but B2 is allocated the operational contract OP1(). Now between B1 and B2, a message is needed. I assume this is Ev1() again, it is just forwarded. However, I need them to be different, because it might be the case, that B1 performs some tasks on the parameters of Ev1() and then forwards the filtered data to B2. How would you model this? Do I need to invent a new message for this? I have seen in the examples in the paper from H. P. Hoffmann and the Harmony deskbook that the messages are just duplicated. I suppose Ev1() in the above example is duplicated but now has a different TYPE for its parameter. Afterall, the fact that I drew Ev1() from B1 to B2 has already created a new event on B2, so yes, they are different. For the example in Hoffmanns' paper see figure 10, the operational contract is reqCalcCmdrLosCmd, which is shown several times between LRUs: http://static1.1.sqspcdn.com/static/f/702523/9277834/1288929233000/200511-Hoffmann.pdf?token=F%2FmLJpHRBLG3JpdFzxeJcZZyB1I%3D
  • What are your hot questions and systems engineering and MBSE?