Physical Flow of Objects, Nested EI's?

[Jai_Gulati]

Hello,

I am modeling a system that is part of a warehouse on the moon. It’s purpose is to pick up an item from inside the warehouse, pass it through the airlock, and deliver it to an astronaut or rover outside.

The item is stored in a box, it might be delivered in the same box or it might be moved into another box that can protect it from the Lunar Environment.

I am currently at the System Analysis level.

I had a problem showcasing the physical flow of the item, it being inside the box, the box being picked up by the system, the item then being moved to another box, and then that box being taken through the Airlock.

Another user had a similar problem in this post: Object flows in Arcadia

@Thierry_Poupon gave an answer statting that this can be done using EI’s and having State and Mode Machines of the EI’s

I have some follow-up questions:

Box = Domain in this diagram,

I have used the above diagram to showcase that an Item is in the Domain, if you notice there is a Domain that can be “None” which means it’s just the item by itself.

1. How do I create an MSM diagram for an EI or Class, I only have the option to create it for an Actor
2. I have “Domain” as an actor, where can I show the class is the actor
3. Now, I can showcase the movement of the Item using the EI, but I am not sure how to showcase the movement of the Box with the item inside it. I could have an EI “Domain” , but there is no feature for me to showcase a Nested EI or Nested Component Exchange.
4. In the above the Item is being passed from Domain to system, or the Domain is being passed from the warehouse to the system when it picks it up. How do I showcase the movement through the airlock, I want to show that the system is inside the airlock holding the box with the item in it.
   (Note, there is the possibility of a single robot moving through the airlock, or even multiple robots that pass the item from outside the airlock to a robot inside the airlock, all these robots are still part of the SOI )

Thank you for taking the time to read this

[StephaneLacrampe]

Hi Jai,

Here are my answers:

1. No, Modes and States applies to components, functions, not EI or class
2. if Domain is an Actor, then it is not a class… Class Diagrams in Capella should not be called Class Diagrams, but rather Data Diagrams. They are here to model date exchanged in Functional Exchanges, not to model Actors
3. I don’t believe you will be able to do it that way using Arcadia/Capella
4. See my comments below

More general comments:

First, you have to think about and decide whether the Domain is an Actor (external to your SOI) or is in the SOI:

• If it is in the SOI, then you cannot model it at the SA level, as at the SA level, the SOI is a black box. The only way you can then talk about your Domain inside your SOI at the SA level is through your functions. See my example below.
• If not in the SOI, then you should model it as an external actor and conduct your functional analysis accordingly, modifying the example I did below

Second, remember that Arcadia enforces a clear separation between the need and the solution, and that at the SA level, you are modeling the need. So here is a (simple) proposal based on your message where I believe you can represent what you are looking for. It would probably require more thinking as I don’t really know what you are trying to do and based it on what I understood from what you described. But the main idea is that you should probably be able to represent what you want by doing more functional analysis, ie using more functions, and then the items flowing on your exchanges may change depending on which path you take. Here is a SAB examples, and from there you can use Scenarios ou Functional chains to describe your different scenarios (item has or has not a domain). I used Functional Chains as an example for describing your 2 scenarios.

If you want to represent your Domain as an external actor, this is totally feasible, just add it and modify your functions accordingly.
If you want to express that Different Domains and Items will flow depending on which path you take, then you would allocate different Exchange items depending on the exchange.
If you want to represents that there are multiple robots in the airlock, at the SA level, then it is just a question of naming your functions correctly, unless I miss something. For example, instead of “Move in Airlock”, you may use “Move robot(s) in Airlocks”. You can also create a Constraint" elements on your Function or on your Exchange indicating these type of constraints.

I hope this helps.
Stephane

[Thierry_Poupon]

Hi Jay

1: You don’t: An EI may be what I call a signal (set of signals) which means that it is seen what ever can be the value (set of values) or a value. You need value to describe discrete scenarios because values open and close doors, change component state/mode.
2: Exchange Item is named like this because it represents a unit of exchange from an emitter to an addressee or receiver at least. The Actor is emitter or receiver, your system or component plays the second role. The Exchange Item contains elements that can be detached at some other times. This exchange item element is typed by a class or a detail data. Using a class, you refer in which class you find the type you are looking for and then you connect the property in which you have set your desired detail. Then the “state” is in fact a value of signal.The way I do this is naming the EI Element as : Signal (natural language)=Value. The type give the signal name if available with its designed name in the product.
3: Composition of “domains”: May be the self composition link is not sufficient: the owner domain has for each owned domain several properties: this owned domain and the coordinates of its location inside. I’m afraid you have to add at least this to your class. Class properties work exactly as EIE: the property name may reflect a value, the type the signal is refers to. (it can reflect the signal itself too). The question is now is it still possible to use self composition link or is it needed to use different classes for owning and owned.
4: I did not really understand: I forget what is the airlock in your system. If you need to showcase an assembly or a disassembly (getting an item out of a box), you need then 3 EI: the box empty, the boxed item and the filled box. each using linked types. The system takes the filled box, unbox the item and render it, and then render the empty box.
Hope this helps

[Jai_Gulati]

@StephaneLacrampe, @Thierry_Poupon

Thank you both for taking the time to answer my questions. It was very nice of you to take the time to draw a diagram to explain things to me. I would like to let you know that while explaining the problem I simplified my concepts to not put too much on you.

This post might not be well-ordered so please read the whole thing before answering.

For 1) and 2)
@StephaneLacrampe, I need to show the physical movement of the item and domains in the SA as it is important to know the changing environments, and my only option to do this is with the one @Thierry_Poupon provided in his answer on the other forum post; to use EI and classes and imagine the movement of data as physical movement of the object. Therefore, do you think it’s okay for me to use documentation/notes to tell the reader of the diagram that the Class IS the Actor?

For 4) When the Item/Domain is being passed through the Airlock it is still being handled by the System, therefore I think it is okay for me to not have a Component Exchange or any such thing involved here.

Now to 3) @StephaneLacrampe I think I might have found a way around this:

The Domain is not part of the SOI. There are two types of Domains* (This should be a generalization but that option does not exist in the Operational Entities Diagram)

Now the class “Domain” IS the Actor “Domain”, the Property “Domain Type” is Boolean ( Storage Domain or Transfer Domain )

My idea to work around the issue of showing the EI taking the Item inside the Domain is to have another empty class “Deliverable” that owns both the Item class and the Domain Class. This class “Deliverable” will change throuhghout my scenario, sometimes it will be just the item ( when the system picks up the item from the domain) and in other times the class will have the Domain class which will have the Item class in it representing the Domain being moved with the item inside it.
I have an EI “Deliverable”, which is typed by Deliverable class, therefore by using this empty class I can represent just the item being moved or I can represent the domain being moved with the item in it or even an item inside a domain which is inside another domain. I am not sure if this is good or not, please let me know your thoughts.

Thank you for your answers

*The purpose of this is because the warehouse has not been designed, and neither have the boxes that the items will be stored. Therefore I have defined the Storage and Transfer Domain, cause there may be the case that an item is stored in a box that will not protect it from the lunar environment. Also the CTB,EVAB etc which will cover ALL possible ways of storage that will be designed in the future.

[StephaneLacrampe]

The fact that you say “the class Domain is the Actor Domain” indicates that there is something wrong in the way you are modeling things. In Arcadia, an Actor cannot be represented as a Class. Actor are external systems. Class objects are data (or anything else, fluids, power, boxes if you want) flowing through functional exchange.
So probably the issue comes from what you define as your SOI. If you need to model your Domain as a class, then it is part of your SOI. So in the end, you may have different Capella models depending if your SOI is the wharehouse (and you want to represent how the different elements flow in the wharehouse) or your robot.

But honestly, I am unsure I am giving the right advice here.

[Jai_Gulati]

I am quite certain of my SOI and its boundaries, it does not make sense to me to have the boxes and items( which interact very similarly with the system) inside my SOI. Do you think there is a possibility that my diagrams and functions are unintentionally from the perspective of the warehouse being my SOI. I have attached an SAB below. Another thing I forgot to mention earlier is the reason why Functional Chains won’t work for me at this stage, (they possibly could in the Logical Analysis). The warehouse(LISE) has a computer(LISE Computer) that coordinates the whole process, giving actors commands and receiving a confirmation. Capella does not allow one to go back to the same function in a functional chain. I don’t see a reason to break down this function, now or in the logical analysis, maybe this is the root of my problem?

(SAS = Airlock)

There might be the possibility that my model is fine and the problem here is Capella has no functionality to showcase the physical movement of an Actor. The only reason I chose to use the class is I have nothing else to showcase this movement and that one actor is with the system or another actor. If this is the case then does it make sense for me to work around this by using documentation to explain the way I have used classes?

[StephaneLacrampe]

Hi Jay,
The quick answer first: When you create a Functional Chain, you cannot have a loop, but once it is created, I think you can navigate to the FCD diagram and add a loop if you want.

Thanks for sharing your diagram. My first question would be: why do you need to model the Transfer Domain or Storage Domain as Actors?
To illustrate why I ask the question: let’s take the example of the InFlight Entertainment System that comes with Capella. I am not sure you are familiar with it. In this IFE example, we can consider the songs and movies that the users are watching. You could model them as external Actors: they are not part of your system, the IFE is not making the movies, Hollywood is. So this is an external system that needs to be loaded on your SOI, and your SOI does something with it, and finally deliver the content to the user. But in the IFE, Movies and Songs are modeled as Exchange Items flowing between your functional exchanges. So, to me, on your context, TD and SD are items that are flowing between your exchanges (and in the end through your interfaces) so in your context I think they should not be Actors.
So as you suggested, I think you should model them as EI. You may have on EI, is you suggested ealrier, or multiple EIs as Thierry suggested.

From there, what would be your next most important question/need?

Stephane

[Jai_Gulati]

Hello,

Thanks for your answer. That’s an interesting perspective, I never looked at it like that. You’re quite right, my thought process for choosing the SD and TD as actors was that they would be designed and developed as part of the warehouse or another system and it is the purpose of my system to interact with them. Intuitively they’re outside the SOI, it was quite ignorant of me to think that them being in the SOI didn’t make any sense. I am going to make them part of my SOI moving forward.

Although there is one thing that is bothering me, in the IFE case and mine it feels like we’re choosing to make them part of the SOI not because of the definition of the SOI but for the reason that it is better to model it that way in Capella/Arcadia.
5)My question here is, is it okay for the SOI definition to be a function of the Methodology /Tool being used.
6) If the TD and SD are in the SOI then the Item will be too?
7) Considering TD,SD and Item in the SOI. Which makes more sense, having an EI for Item and another EI for Domain OR having the EI deliverable like I defined above.

Thank you for your help

Jai

[StephaneLacrampe]

To be honest, there are a lot of good questions here and I would have to ask some of them to Arcadia experts to be sure I am not giving you wrong answers.
Typically, I am not sure that, if you model SD and TD as EIs, then they are part of your SOI.
To me, the SOI is the system on which you are going to define requirements on it. Let’s take the IFE again: Movies are flowing in the IFE, but to me they are not part of the SOI, they are used by the SOI. At some point, they come from outside your SOI, so they will flow through one of your system interface. The same could be said about passengers: they would flow in a plane, but won’t always be part of your SOI depending. The same goes with power/electricity for example: this is something that can flow in your system, that does not make it "part of your SOI per say.

In other words: you should probably model TD and SD (and items) as EIs, but that does not mean they are in your SOI. And that does not mean you should model them as Actor as well. Unless they also interact directly with the system through a specific interface I suppose. Then in that case, you would have them both modelled as Actor and EIs. That case is bothering me. So I need to double check with other people on this.

5. I am not sure I understand the question
6. Yes
7. It depends on the granularity of your functional exchange: if some of them are only flowing the items, then you need an EI for the item, if some of them flowing domains, then you need EIs as well. It enables you to display a distinction between what is flowing, and then when you transition to the LA, it will have an impact on the interfaces definitions between your subsystems.

Stephane

[Jai_Gulati]

The SD,TD, and Item definetly interact with the system. The system will have to be designed to be able to pick up any domain or item, open a domain, and extract the item from it, that means maybe the geometry of the domain has some features that allow the system to latch onto it, maybe even the domain latches onto the system.
Therefore the domain (MAYBE not the item) either needs to be part of the SOI or be an entity. When I said I will remove them as actors I planned to add them as subsystems in the Logical Analysis with similar functions as they have as actors in the diagram above.
It’s intuitive and makes sense to have them as External Entities, although it is also reasonable to have them inside the SOI.
Now coming to 5, the only reason we have chosen to include the domains and items inside the SOI is because of the functionalities of Capella/Arcadia. Therefore the definition of our SOI is a function of the Tool/Methodology. Maybe if I were using cameo my SOI definition would have the domain and Item outside the SOI. I can imagine that the methodology being used could change the way you define your SOI, but I don’t think it’s okay if the tool you’re using is affecting the boundaries of your SOI.

Right now I see only two options:
a) They are EI and External Entities and this is explained to the reader through documentation
b) They are EI and part of the SOI, and will become subsystems in the Logical Analysis

I think the problem here is that Capella has no way to showcase the physical movement of an Actor/Entity similar to component exchanges. I’ve been struggling with this concept for a few months now, although the fact that even you don’t have the answers gives me some comfort that it’s not me that’s the problem. I would be grateful if you could connect me with someone who I can discuss this with.

[StephaneLacrampe]

I don’t agree with you about an Arcadia or Capella limitation to showcase movement
.
Let’s take this as an example, and sorry if this is not the nicest example:
Let’s say you are designing a machine that cuts meat. So your SOI is the machine.

• Are you going to put the meat as an Actor? I don’t think so. You may put the user of the machine, or a belt conveyor, with a function “provide meet to the system” and create an interface between your conveyor and your machine
• Are you going to have Meat as an EI: Yes: it is flowing between your actor and your system, and then other functions in your system are going to use it.
• Is it part of your SOI: No: you’re not delivering the meat with your machine
• Is the machine interacting with meat? Yes, certainly!
• Are you showing movement of the meat: Yes, the meat is flowing between your actors and your system, and flowing within your machine subsystem

I hope this helps.
Stephane

[StephaneLacrampe]

And there will be cases where your meat will be a subsystem, for example if your SOI was the actual living animal. Or it may be an external Actor if your SOI is the blood vessel system of the animal. The muscle will have functions, ports, and interfaces with other sub-systems…

So, does it make more sense if you think about your items/domains in terms of meat?

[Jai_Gulati]

I do get what you’re saying, it’s similar to the IFE and the movies. In the IFE and meat case it’s alright to not have them as EI and not part of the SOI.
Although the domains will have some sort of interface with a robotic arm, there’s also the possibility that they might be smart domains which have their own sensors and actuators for various reasons.

Therefore I again only see the two options and maybe a third that I’m not sure is okay

a) EI and Actor ( I’m curious to know what bothers you about this, I’m unable to understand why this can’t be possible)
b) EI and part of the SOI
c) OR do you think it’s okay for them to be EI’s and not part of the SOI, even if there’s some complex interactions. The IFE still has to store, play, pause, rewind the movies could this be similar to open, close, move but then again what if they had sensors and actuators, one type of storage domain is a specialised environment that will store the item at certain temperatures or various other controlled environments

I’m fine with option b), I understand that you can’t surely give me this as the right answer but if you see them working as subsystems then it’s good for me. Although if this is the case I’d like to know what you think of question 5)

Thank you for bearing with me

Jai

[StephaneLacrampe]

“In the IFE and meat case it’s alright to not have them as EI and not part of the SOI.” → Not sure we understood each other here: The meat or music are defined as EI in this examples. But the fact that they are defined as EI does not make them part of the system.

I agree with you, option a) is probably the best in your case. Creating items/SD/TD as EI, definitely yes in your case, this is how you can show flow (movement).
Creating them as Actor is also a yes if indeed there is a functional interaction between them and your system. For example, in the case of the item, you do not have any Actor in your SA, which I think is fair. For your SD/TD, it probably makes sense to have them as Actor as you did, if you do have an external interface between your system and SD/TD as you did in your model.

So sorry about this long discussion, I may have been wrong from the start saying that “the class Domain is the Actor Domain” is a problem. I would probably indicate as a comment in your Class diagram that the SD/TD EIs corresponds to Actors. And I will discuss this matter and come back to you on this.

Stephane

[Jai_Gulati]

What I understand is that if you define something as an EI it doesn’t automatically make it part of the system, but you can chose to if you want. Do I have that right?

You’ve been very helpful in giving me some clarity and I sincerely thank you for all you time. I will continue on with option a) for now, awaiting your reply.

Thanks again,
Jai

[StephaneLacrampe]

Well, first, I think you need to be clear on what is the System Of Interest in the Arcadia sense:
“The system of interest or solution to be delivered to customers(to be considered as a generic name: could be a software, a service, etc.).” - So to make the distinction whether you should consider an EI as part of your system or not, you need to ask yourself: is this something that is part of the solution to be delivered to customers?

So, the Item, TD and SD exists without your system, right? They are not actually delivered with your Robot? You would actually have probably created them in your OA to explain what is flowing between the different activities conducted by your external actor?

I may be wrong, but in my opinion, there is a good chance that the EI you create at the OA and SA level are generally not part of the SOI since they probably exist independently from your system.

Now the EI that you create specifically at the LA and PA level (and not already created at the OA/SA level), that are going to flow within your subsystems, there is agood chance that they are part of your system of interest.

[Jai_Gulati]

Yes, I think we agree on this. What I am providing to my customer is purely the delivery system, the customer already has the TD, SD and the Item. They are not part of my SOI, therefore they are Actors and at the same time EI’s as they need to flow through my system

[StephaneLacrampe]

From there, what would be your need in terms of showcasing the movements of Items/TD/SDs? How would you like to showcase it?

[Jai_Gulati]

Well I would like to showcase the item being stored on a shelf in a domain, the domain being picked up by the system, the system inserting into the transfer domain and then the TD finally being delivered.

The class = Actor solves my problems for now and I think if that’s okay then I’m pretty confident in what I have, it accurately showcases what I want to showcase. Thanks for all your help

[Jai_Gulati]

Hello,

Sorry this might be a stupid question, but I just noticed that a functional exchange can also have an allocated EI, what would be my reasoning for showing the EI moving around in a component exchange instead of a functional exchange?

Also on another thing, a while ago you had said we could loop back to the same function in a functional chain, Capella will not allow me to do that. I tried editing the chain in the SFCD, still blocks me from doing that.