Level-Crossing Example - Emergency Stop - Design Levels

Hello,

I’m currently trying to learn Arcadia and Capella and working through some examples (whilst also working on my own system design). It’s probably a simple concept I haven’t understood correctly but hopefully someone can help:

In the Level-Crossing example the Emergency Stop mode is added at the System level. Why wouldn’t adding an emergency stop mean going back to the Operational level and designing it there first?

It seems like something the operational actors would be very interested in (and perhaps have their own existing procedures & policies) and also where you would address the question about exit conditions mentioned in the example.

Would new ‘Enable train movement’ and ‘Disable train movement’ operational activities be required which would become switching the power off/on at the system level?

Any advice or guidance is much appreciated. Thanks.

Hi Joe,
Just to check, have you seen the 4 videos by Jean-Luc Voirin where he is commenting on this model on this page: http://www.eclipse.org/capella/arcadia.html ?
Stephane

Hi Stephane, thanks for your reply. I’ve seen (and just re-watched) those excellent videos.

As a newcomer to MBSE I find the choice of where to include design decisions to be one of the hardest to understand.

For example, in this case with the emergency stop we have decided that one is required, and also how to implement it (power off) at the same stage. My understanding so far is that we should try to separate what we are trying to achieve and how we will do it.

It’s similar with the crossing prevention device, which is introduced to the model later on in the Logical Analysis. I’m not sure where that need gets introduced to the system. Physically blocking traffic from entering the crossing seems like there should be a system capability (or requirement) that it fulfils.

Do you have any recommended resources to help me with choosing between the different levels and where to introduce design decisions without limiting the solution?

Generally speaking, OA/SA are about the need so there should be nothing about “how the system will fulfill its expectations”. Nevertheless, there could/can be physical constraints or design decisions that are part of the need…
At the OA stage, you should not model anything about the system of interest. You are interested in the context, in the stakeholders’ needs, and the environment.
At the SA level, the System is a black box and you’re interested in defining its boundaries.

Now having said that, first I would say that you are right, this is hard, and it is a very good sign that you are finding it hard because you are asking yourself the right questions. Then it becomes easier with practice I think, but still, these are always important questions to ask yourself. Also, one other type of question which is very important is: “to what level of modeling do you drill down to?”

I have not looked at the Level-Crossing example for some time so my answers may not be accurate, but:

  • “In the Level-Crossing example the Emergency Stop mode is added at the System level. Why wouldn’t adding an emergency stop mean going back to the Operational level and designing it there first?” -> This is a mode of your system of interest, you are not modeling the system of interest at the OA level.
  • “Would new ‘Enable train movement’ and ‘Disable train movement’ operational activities be required which would become switching the power off/on at the system level?” -> Maybe: there could be a situation where you could say that enabling/dissabling train movement is done only by an operator (a person) and that the crossing system is ringing a bell to alert the operator to stop or start the train. Obviously, nobody would do that, but I am just illustrating the decisions you are making at the system level: deciding what are your system boundaries means deciding which functions are part of your system, and if “disabling train movement” is part of your system, it has some important consequences on the design and cost of your system as it is a high safety concern.
  • “For example, in this case with the emergency stop we have decided that one is required, and also how to implement it (power off) at the same stage. My understanding so far is that we should try to separate what we are trying to achieve and how we will do it.” -> Yes you are right. But there may be a train regulation about level-crossing systems that when a car or an obstacle is detected on the level-crossing platform, then the level-crossing platform should disable the power of the train. In that case this becomes a requirement on your system.

Another top maybe: think that people making needs models (OA/SA) and Solution models (LA/PA) may not be from the same organization. A regulatory organization may be doing your need model about the level-crossing system, and hand it over to suppliers for pricing and building it. So what you put at which level on your model is sometimes a question of responsibility: Is the regulatory organization imposing to power off the train, if yes then this should be in the need model that is sent to the suppliers.

One final point: the level crossing example is just an example, and it has not been done by someone from this field/domain. So this model may be very different from what is done in reality, the goal of this model is to illustrate the Arcadia method, not to be an accurate level-crossing model.

I hope this helps.
Stephane

Another idea: the client/stakeholders may express some needs, but the solution may be a level-crossing system, or the solution may be a bridge or a tunnel. So this is something to think about, like at the OA level, you are not modeling the system, so there should be no information about a level-crossing system if options are sill open.
This is not the case because from the start we know we are designing a level-crossing system. But there may be cases where you do not even know this.

Stephane

1 Like

Thanks Stephane. That’s all extremely helpful, especially how each stage could be a transition between organisations or departments. I think I was treating the examples too much as how to create a perfect model rather than a demonstration of how to use the tool.

Great stuff. Thanks again.

I am glad it is helping. The level-crossing example is the one used in the book by Jean-Luc Voirin. This is a very good reference and illustration of how to apply the Arcadia method. But this is an example, it is important to understand the context in which it is developed. There are multiple different ways to use the Arcadia method.
I really recommend buying/reading the Arcadia book from Jean-Luc Voirin for anyone who wants to get a more in-depth understanding of the Arcadia method.

Stephane

Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.