Can specialized actors use parent actor's function?

Hello,

I would like two actors to be able to use the same function. I have not figured out a way to do it.

Here is how I think it should be possible:

In the diagram below I show actors B & C being specilizations of actor A (left panel). I would like actors B & C to use functions assigned to actor A (right panel).

My reading of the documentation is not encouraging, but it is also not clear what is implemented and what is not.

Is there an alternate way for actors B & C to share a function among them?

Thank you,

Mirko

I don’t think you can as Note1 is probably accurate.
I think you should follow the Note2 advice then…
Also: I don’t think actors are “using functions”. Functions are allocated to Actors. But I do see your point that if inheritance was implemented, then SF-A should be also allocated to Actor B and C by inheritance. Remember that in Arcadia and Capella, you are working with instances only. Physically, what does it mean that Actor B and Actor C have the same function allocated? In the physical world. even if the function does the same thing, it will be 2 separate functions done by 2 separate actors.

Stephane

Here is my use case:

I have a technician, and I have an engineer. They do similar things on this equipment. The engineer will do the experiment, and the tech will do testing to ensure the equipment is in spec.

(what follows is representative of what I am modeling)

For one step, they both need to grab a wrench to unscrew a specific bolt. That is part of operation of experiment/testing, not assembly, disassembly of equipment.

This is how I do it now using Select & Route, and assign the common operations to the generalized “Operator” actor.

  • Am I too pedantic in the use of Select & Route and remove them from the diagram?
  • Should I just make two versions of Grab Wrench and Remove Bolt assigning them to Tech & Engineer?
  • Or is there a better third, fourth way?

This is not terribly important, but I am curious how to do this better. Thanks for your time and attention.

This is how I would do it - my main driver being to keep it as simple as possible for who is going to consume your model:

  • I would indeed duplicate the Grab Wrench and Remove tool functions (I merged them into one function just because I was lazy but if you need to separate them, no problem) and indicate with a constraint of a note that there are in fact the same
  • Separating them may have the advantage to make it clear that if you want to test and validate them, you need to test both (although they are not part of your system of interest so this is not a topic here I suppose)
  • I removed the Select and Route functions as I am unsure why you have them. For example, in your system of interest, is there really going to be a function that is routing the output of your “Do Something” function depending on whee it came from? It could be the case, but I did not understand that both the technician and the engineer were using the wrench “at the same time” and were then receiving outputs “at the same time”. They are simply going to use the Do Something input port with the wrench/bolt functions, and then they would receive naturally receive an output depending on who is in the room doing the operation

Thank you very much.

I will follow your suggestions.

Regarding Select and Route, I found them documented in Help. However I will look for some worked examples to better understand when they need to be used.

Some information here:
When several exchanges arrive in a single port of a function, it just means that exchange items may arrive (or not) through this exchanges. They may arrive independently and in a non correlated way, or in parallel, in succession, from many source or only one. No assumption is made here. The same for the other way around.
If a function has to send one exchange item to different functions but it is the responsibility of the function to decide to which it should send it to, then you would have as many ports as required in the originating function. The same would go for the other way around.

From there, regarding the Select, Route, Gather, they are indeed introducing some control flow in your model where simple functional exchanges are simply expressing functional dependencies.
For example, using the Duplicate function indicates simultaneous diffusion of the exchange item to the recipient functions. The Split one does the same but split the information between the recipient. These types of functions should be used only for expressing how data is flowed between functions. If there is data treatment, then a regular function should be used.