Refining functions at Logical level: how to handle common sub-functions

Hi,

I’m trying to read the knowledge from the “practical guide to capella” across to a sample project. The system I’m considering is a HMI for a machine: the user can use the system to activate functions on the machine, the machine in turn can display its status to the user. And of course it’s reverse engineering to some extent…
At system level I’ve got functions like this: “activate Function x” (User → HMI → machine) and “display status y” (machine → HMI → user)
At logical level, I’d like to show that the communication between HMI and machine is via CAN Bus. So I’m breaking the system level functions down to include CAN communication. Of course I could have “receive data via CAN” and “send data via CAN”, but I’m thinking, that’s too much details and I’d prefer to have a generic bidirectional function “exchange information via CAN”. Is there any way to have this as a single function, that appears in both breakdowns? Or is that not even desirable for some reason? So far I didn’t mangage to model it like this in Capella…
If there would be a single function, that would appear in several breakdowns, it would point to a single component to realise this function and make this a clear decision. An alternative might be to go back to the system level and already split the CAN-aspect out there, so the “node” already appears on a level above and is directly traceable. But then that’s already a lot of details at system level…

Thanks for any guidance / opinions on this.
Matthias

I’ll try to give this topic a little push…
I think this boils down to the question if it is possible, instead of refining and breaking functions further down as I go to lower levels, to summarise or generalise several functions. I also realise this might fit better into the Arcadia sub-forum than the capella one, but can’t figure out how to change the allocation myself…

Going back to my example (which admittedly consists of reverse-engineering a known product): at system level I’ve got several functions, e.g. to “controll illumination”, “capture and execute a user input”, etc. At logical level, when breaking these further down, it becomes clear they all have a common node, which is the data communication via CAN.

One option would be to accept this fact and have several very similar logical functions, each involved in their own specific dataflows, e.g. “receive illumination setting” or “transmit user command”, they could then be allocated to the same logical component. But then the diagrams would become very cluttered, with several very similar functions “to receive a specific set of data”. This cluttering would would thenextend to lower levels as well. So I’d like to summarise these functions and put a “container” around them. Is this possible in Capella?

Another option might be to take this insight back to the system level and have a “CAN-Communication” Function already at that level.

A similar problem arises at the other end: I’ve got several functions which somehow translate the system’s status to an illuminated LED. So I’ll have several dataflows which each activate a specific LED. Then I’ll make a design decision to use a multi-channel LED-Driver, i.e. I will have a SW component which channels all individual activation requests and controls the LED-Driver. It might even be fair to have each of the higher level dataflows broken down to “set the bit corresponding to LED x” and allocate all of them to that single SW-Component. But still it feels like this would overload the diagrams, such that I’d like to hide it behind a generic function and it also feels that this is certainly a design decision, that doesn’t belong at system level. But I don’t currently have any idea how I could realise this in Capella.

hope this makes it a bit clearer

Hi @m.lehmann,

I can see two solutions to this. Firstly, I would suggest that using CAN Bus is a design constraint rather than a function and I personally wouldn’t model it as such. I would simply use a Component Exchange in the LA which mandates the CAN Bus protocol and route all the relevant functions via it.

If you really wanted to express this requirement using a function for some reason you would need to create two CAN Bus functions, one for transmit and one for receive. These would need to be duplicated in your HMI and Machine Logical Components – four functions in total. You could then link all TX/RX functions to the relevant transmit and receive functions in each Logical Component. Obviously if there are many “Activate function…” and “Display status…” functions routed via a single TX or RX function it would make the diagram rather busy. You could resolve this by making all of these exchanges members of an Exchange Category, which would make the view more comprehensible.

Hope this helps.

Thanks Kelvin,

I did already consider, that modelling the CAN communication might not be an ideal choice - after all it could in the future become a different protocol and shouldn’t change the model at the higher levels.

Having digested the tutorial a bit more I realise that I was probably slightly mislead by the fact that the example was built around the automatic transitions in Capella, which clone all functions to the next level and somehow left me with the impression that I always need to start from an existing function and can only break it down further.
However I could also chose not to do this and instead manually create a “bucket function” at the next level, which i then declare realises several functions from the higher level. 'll try to set up one model with that concept and another one with your suggestion to get a feeling for what works better for me.

Thanks again, Matthias