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.

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