Feedback from Capella Aviation Design

[ImNeos]

Hi guys,

I would to get feedback for my Capella Project. I am designing a flight control system for an autonomous aircraft. The MBSE will be consequent as it’s a big project (probably thousands of req at the end) and I am trying to find the good and native way to do this.

I first created entities and actors :

I defined my capabilities :

Then I defined all my activities, that I stored in different packages.

I tried to minimize the amont of activites to be able to reuse them. Note I that don’t have much sub-activites (is that a problem?)

Now, I am writing the interactions between my activites, but I struggle a bit.

1. Is it intented to be written like this? My OAIB seems very “linear”, almost like a scenario and I am therefore not sure if I am doing this the right way. Although, I don’t see another way. Maybe my activities aren’t written properly.
2. How many OAIB diagram should I create ? How do I know when to stop creating them ?
3. In the section “Crew in-flight assistance” I wrote this activity: “Alert crew/pilot of anomalies or critical situations”. However, this could be used hundreds times in the project, so I am bit afraid that it would not be easy to visualize the interactions anymore.
4. 
   
   should I write all the environment info as interaction here? (wind speed, light, humidity, temperature, …) or keep it like this?

If you have any others feedbacks, please don’t hesistate. Even if I have to start it all again.

Thank you !

Thomas

[StephaneLacrampe]

Thanks for sharing all that, that is great.

I think that my first remark would be, if you’re working on such a significant project, and it is your first time with Arcadia/Capella, maybe you should consider getting some external professional help for this. This is something I highly recommend so that you take the right path from the start.
Also, you may want to consider Arcadia as a modelling framework. How you’re going to use it, what diagrams in what order, what information, where to start and where to stop, is highly dependant on your actual context, project, and more importantly your goals with using SE/MBSE. Like what engineering concerns you’re trying to de-risk/improve with MBSE, what output you want to produce out of your models. With that a coach will be able to define some modelling guidelines and rules that will help you and your team.
Message me on Linked-In and I can put you in contact with some of our partners who could help you with that.

Now a few general comments:

• “When I defined all my activities, that I stored in different packages […] I tried to minimize the amount of activities to be able to reuse them. Note I that don’t have much sub-activities (is that a problem?)”: Well, I would encourage you to consider creating High Level activities instead of packages. Typically, “Communication with Outside” sounds very close to a high level activity to me. It is not a problem if you don’t have a lot of sub-activities “at the beginning”, but it can be a problem if, in the end, all your activities are flat (note that the same is valid with functions in the next engineering perspectives). Reason is that doing “functional architecture work” means more than just defining activities (or functions), the “architecture” word here means that you do have to do some work to regroup some activities together, find higher level functions, etc… Which is what you are kind of doing anyway by creating packages to store them. In other words, doing architecture work is much more than creation components and sub-components (linked to my next point). Please note that I am not saying that you need to find some sub-activities to the activities you already created. What I am saying is that, if you end up with a flat list of leaf activities, you have missed a step in creating your functional architecture. Deciding whether you need more sub-activities is a question I cannot really answer. It is linked to your modelling objectives/goals (where to start and stop modelling, what level of details, etc…) that are project dependent. My guess here is that you have identified quite a bunch of activities already, that looks good, you may discover more, but don’t try to be exhaustive before moving forward, see my next point. (And at the system analysis level, you may end-up having much more systems functions if you do have thousands of reqs in the end)
• Also please note that this is a very iterative process. What I mean is that you may want to move forward and start doing some Activities to Actors allocation (OAB). By doing this, you may discover some new activities , some new actors. Or some new ways to group activities together. This is not a linear process but rather an iterative one. How you’re going to group these activities, how to allocate them, etc will also depend on some architecture drivers you may decide for your project (but this point is probably more important when you start moving to the Logical Architecture, see the IFE example, there is an “Architecture Drivers” diagram, to give you an idea of what I mean)
• Remember that in Arcadia, Capabilities are described by Scenarios of Functional Chains (=Operational processes at the OA level), and Scenarios and Functional Chains are described by Functions and Functions exchanges. What I mean here is that you are missing a significant link (how your activities are describing your Op Capabilities). Depending on how people use Arcadia, some would actually start by modeling Operational Entity Scenarios. Because they are actually discussing with the stakeholders and discovering the context. And they use these scenarios to create Capabilities, identify all the actors, then start grouping activities, etc… Apparently you did not start by doing so, which is completely ok. So in the next steps, allocating activities to actors and creating operational processes that describes your capabilities is going to be key in insuring that your model and Operational Architecture is sound and complete.

Having said this, some short answers on your specific questions:
1 - Maybe you need these scenarios. Also: if you have flat activities, most likely this will look linear. If you start having higher level function, you may want to have one OAIB per high level functions. Another strategy could be to have one OAIB per Capability (so showing all function and interactions involved in describing a capability). But all this becomes more important at the SA level when working on the Functional analysis of your system. It is good that you are trying to get this right at the OA level since it will be a very similar process at the SA level. But often the OA level is not as “rich” at the SA level. Unless you want to spend months on doing a CONOPS.
2 - See my previous point(s). And also, diagrams are just diagrams, views on the actual model. Sometimes you create diagrams and organize them for you/your team of architects, and then others intended for communication to other project stakeholders.
3 - Yeah. Not easy to answer this question as modelling choices varies depending on your context and objectives. But I would ask: Will you then have a specific sub-system/component in your system responsible for managing this? Then this activity will be allocated to this component. And this component will probably have a lot of interactions with other components as it need to gather the info. So you’ll probably have a dedicated architecture diagram showing this, and remove it from your other architecture diagram no to clutter your view
4 - Up to you. Is it useful to fulfill your goals or not? I would probably create an exchange item describing the type of info you expect and allocate it to the appropriate activity exchanges.

I hope this helps.
Stephane

[ImNeos]

Hi Stephane,

Thank you so much for taking the time to give me such a complete and helpful feedback. I really value this information. I’ll definitely reach out to you on LinkedIn to find a coach, as it could indeed be very useful. At the moment, we are trying to understand how we can use this tool in our project and how it could benefit us. Therefore, I believe that understanding the basics, the scope, and the vocabulary is important for us.

The hardware aspect is very classical in this industry, so I don’t believe that Capella would help us with the physical architecture (you have controllers, sensors, sticks, actuators, …). However, it might be very useful mainly for the software aspects, and also to help defining in details the softwares functionnalities of the aircraft. I will be also be very useful to define requirements such as “reaction time is less that 20ms …” and to validate them. Also, to choose the exact controler, sensor, … even though the physical architecture is already defined”.

---

First part of the answer

So, I tried to follow your advice and focused on one Operational Capability: Enable safe navigation during flight.

I choose the strategy to create one OAIB for each Capability.

Before taking your advices into account, I believe I had limited the possibilities in the OA, which was not the goal.

So now, instead of creating a high-level activity called “Watch display screen,” I created a high-level activity called “Perceive operational information,” which has three sub-activities. However, I will probably not use the sub-activities in the OA because it might limit other possibilities. Am I understanding this correctly?

I created an OAIB to define interactions. The process was mainly iterative because, before having “Send input to system” and “Perceive operational information,” I only had “Select safe mode,” which is a very low-level activity and too restrictive. As you said, it was very iterative, and then you realize you might already be too specific, so you try to define a higher-level activity. Am I getting this right?

Im 2

I then created the OAB as you suggested, discovered new activities, and found new higher-level ways to group them.

Im - 3

And then I defined the OP, in which, as you said, I can define Exchanged Items to describe in more detail the information I want to share.

Im 4

Then I linked the OP to the capability. Now, I have 4 OP describing my capability “Enable safe navigation during flight”.

---

Second part of the answer

But now, it’s difficult to know where I should stop in the OA. Three things come to my mind now :

1. Before changing flight mode, the system should verify if the chosen flight mode is available at the moment.
2. If multiple hazards are detected by the system, it should have a way to prioritize the information send to the pilots
3. The “manage safe navigation” activity could be a sub-activity of an higher acitvity such as “manage flight mode activity’.

Like this, by example :

Im - 5

But now, in the OAB, should I describe it more then ?

Im - 6

But then, the OP becomes invalid and I can’t create an interaction between “Prioritze Information” and “Manage safe navigation” because they are parent and child.

So am I wondering in this case if I should create more sub-activities for the Manage safe navigation activity :

1. Receive input of a safe type –> but then you could also imagine creating a higher level activity which “receive input”, in which you have a sub-activity saying receive input of a safe type.
2. Send safe mode input
3. Send hazards information
4. …

and then the high-level activity “Manage Safe Navigation” would become a “ghost”: it would not interact with other high-level activities, since activities like “Send input to system” or “Perceive operational information” would instead interact with its child lower-level activities. Am I getting this right?

Then maybe I am going to far?

–> But as you said “But all this becomes more important at the SA level when working on the Functional analysis of your system. It is good that you are trying to get this right at the OA level since it will be a very similar process at the SA level. But often the OA level is not as “rich” at the SA level. Unless you want to spend months on doing a CONOPS.” –> so it’s difficult to know where to stop and not starting the “system analysis” in the “operationnal analysis”.

So maybe I should only consider high-level activities in the OA, and if I come up with ideas for lower-level activities, I write them down in the OA but actually use them in the SA… I’m not sure!

Also, if I end up creating more sub-activities in the SA, since it’s a top-down approach, they won’t go back into the OA, right (after the transition process).So when you said: “What I am saying is that, if you end up with a flat list of leaf activities, you have missed a step in creating your functional architecture. Deciding whether you need more sub-activities is a question I cannot really answer.” → by “end up,” you mean in the SA? So is it important to have a completely finished OA before moving on to the SA? It’s iterative, but only within each step, not across the entire process? (Unless you want to change the stakeholders’ needs).

I really appreciate the time you’re taking for this, and I apologize for the long answer. I’m trying to understand the software and the method and getting it right from the beginning.

Best regards,

Thomas

[ImNeos]

For some reason I can’t put more than 1 image par message.

Im 2 :

[ImNeos]

Im 3 :

[ImNeos]

Im 4 :

[ImNeos]

Im 5 :

[ImNeos]

Im 6 :

[StephaneLacrampe]

lm 1: “However, I will probably not use the sub-activities in the OA because it might limit other possibilities. Am I understanding this correctly?” → Not sure what you are referring to. I don’t think it will limit other possibilities. The important question is : does these sub-activities bring additional value in your model at the OA level, or is it just adding additional complexity in your model for no added value (“added-value” based on your goals. “added-value” compared to creating a single activity “Perceive Operational information (screen, audi, lights)” for example)

“so you try to define a higher-level activity. Am I getting this right?” → I think the important questions are always: “At the OA level, you are building a model that represents what the stakeholders are trying to achieve, not making any assumptions on the system boundaries, is this what I am doing?” and “Is this serving my modeling goals ?”. That does not mean that you should limit yourself to higher-level activities. If these activities are useful for you to better describe and understand stakeholder needs and expectations, that’s good. If these activities are going to be useful for you in the next engineering phases (SA, LA…), that’s good.

The reasons why I am saying that you want to be careful in the level of details you’re putting are:

• First and foremost, be always careful that you are not describing system functions instead of operational activities. The system should not be modeled at the OA phase. No assumption about its boundaries. Only at the SA level you’re adding the system (as a black box) in the middle of your stakeholders and start to think about what role the system will play now that you are adding it in the picture

• The more you model, the more work you have, including when having to maintain and evolve your model

• For each activity you are creating at the OA level, you’re going to ask yourself “How is this activity realized at the SA level, now that I have added the system?”. So again, the more you create, the more work downward. But if this is justified, no problem!

lm 2: Great.

lm 3 and 4: great, but note that in general, there are more than one OP (or FC) to describe a Capability or a Mission. If you have only one OP, I would question the granularity of your Capability, that may instead be… A functional chain itself… A tip: it is often useful to model not only the FC that describe the Capability when everything goes well, but also to describe the corner cases, when something goes wrong

Second part of the answer

“1 - Before changing flight mode, the system should verify if the chosen flight mode is available at the moment.” → “The system should” sounds like something that should not be at the OA level. No System at the OA level. “The system should” maps to a System Function.

“2 - If multiple hazards are detected by the system..” - Same remark. Please note that I am not saying that these should not be OA activities, but really ask you these questions I mentioned above. If it adds value to your OA to have an activity about that on the aircraft, that’s ok. Or you may rename your Activity “Perceive Operational Information” into “Perceive prioritized Operational information”, because this is what the stakeholder wants. Who is going do it ? The system? or an operator that manually sorts the information? Or another system, not the one you’re designing? Do you want to make this assumption at the OA phase? Maybe yes, maybe no, just trying to make you understand what I mean when I say “do not make any assumptions on the system boundaries”, focus on the stakeholders need, what they are trying to achieve.

lm 5: As you see, there is no clear answer on where to start and where to stop. It depends. Some projects are spending 5 years doing operational analysis. Other 5 days. But: one comment related to your question: you may go down to lower level of decomposition of activities. Including in your OAB. But then you may create another OAB showing only the higher level functions. This is one of the very powerful features of Capella that helps you build higher level views of your architecture.

lm 6: Ok so one important aspect here: in a finalized Capella (Arcadia) model, only leaf functions (or leaf activities) have functional exchanges (or activity exchanges). Higher level functions should not have exchanges. They are abstract (grouping) functions/activities. So all these links that goes to the “Manage safe navigation” in your lm6 image should go down to lower functions. So indeed, if you start detailing your “Manage Safe Functions”, then you need all its sub-functions and redirect the exchanges to them.

Now concerning your last comments/paragraphs:

• Yes it is iterative across the entire process. I understand your point on (not) changing the stakeholders’ needs. But there are other aspects like: you may not gather/have the complete stakeholder need in one step; stakeholder needs do change, including through further interactions with them when they realize they forgot a few things, made mistakes, etc.. ; you may have misunderstood some of it ; you may change the way you model it as it is not always easy to get it right the first time ; you may want to refine/extend it as you are discussing and refining with them, etc… And I would say that it is very common in Capella that you do the OA and SA, and then go back to the stakeholders, and discuss and validate with them both (or portion of it). But while doing this, this is when you and the stakeholder realizes things are missing, etc… Probably that moving to the SA and doing this process will help you to figure out where to stop at the OA level. And while doing the SA, you may realize you went too far… or missed some things at the OA level. Anyway, I would not advise anyone to wait for having a “perfectly finalized OA” before going to the SA level.
• Be careful that the SA is not a refinement of the OA (And the same goes for the LA, PA). This is a common mistake and the tool helps to fall into it because of the automatic transitions. The transitions initialize the SA from the OA by copying objects. But that do not mean they should stay as is. If you leave them as is, then what’t’s the point? You’re just duplicating information, making your model harder to maintain. SA is the realization of the OA (same for LA and PA). At the SA level, you’re building a model that answers the question “What will the system do for the stakeholders”. So to take an example, at the OA level, you have your “Perceive Operational Information” activity. How is this activity going to be realized now that you add the system in the equation? Maybe it will be realized by a System Function on your Crew named “Receive operational information from the system”. Or maybe you’re going to break it down into 2 sub-functions on the Crew, one for the audio and one for the video, as you’re going to need these 2 interfaces between your crew and the system. And this same OA activity may also be realized by some new System Function on your system (that did or did not exist at the OA level) to indicate that the system has to produce this information. etc…

I hope this helps. Please note that in all my answer, I did not look precisely at the content of your model/example, and did not take time to analyze it and evaluate if my suggestions and wording for activities/functions/components actually make sense from a domain perspective. I am not an aeronautics engineer. I am trying to answer from an Arcadia standpoint.

Stephane

[ImNeos]

Hi Stephane,

Sorry for the time I took to answer. Btw, do you speak french ? If yes, you can answer in french of course, I just realized you might speak french looking at your profile !

I tried to gather all of your advices and created a new OAIB (and OAB) for another capability, which is a bit more complex.

The capability is called : “Prevent human origin accidents”.

Why not create an OAB directly instead of creating an OAIB ? The OAB is just like the OAIB except it has the entities in addition.

Here, I created the OAIB. After that I created the OAB and had to recopy everything from the OAIB. It took quite a long time because the organization was not saved (aligning arrows, arranging activities, …). So I am not quite sure what is the purpose of creating an OAIB if you create an OAB right after.

In this new OAB, I reused some activities that I used in a previous OAB. Some of the interactions weren’t useful such as “Safe mode input” from the pilot, because the pilot isn’t supposed to do this in this capability. I simply hid it. Does that work like this ?

Is it convenient to reuse activities like ?

You also said “Another strategy could be to have one OAIB per Capability (so showing all function and interactions involved in describing a capability)” –> In my case, I created the OAIB but also the OAB for one capability.

Maybe you mean only create one OAIB per capability but not create one OAB per capability? And after, create one OAB per several capabilities, if not all of them at the same time? (I have around 30 capabilities).

It is a bit unclear to me how to work through this, knowing that this is a big project and that for the moment we don’t have the possibility to hire a coach.

At the beginning, I wanted to create the process “Create Flight Path” following the blue arrows in the picture below. But the software wouldn’t let me create the process. The process seems to be only linear but not circular. Is it intented? Why does a process can’t return to an activity that has already been covered ?

I am not sure if I am using the interactions properly. By example :

The activity “create flight path on the ground” (which receives an input from the pilot - not shown on the process because capella don’t allow circular process) ask for a flight path verification to the activity “minimise exposure to hazards”. If it finds one, it sends it to the pilot through the activity “perceive operationnal information” and the pilot reacts through the activity “send human input to system”.

Are the labels of the interactions correct according to you ? Should it be used like this?

Some activities on the screenshot such as “Minimuse exposure to hazards” or “Manage safe navigation” or “Manage flight mode” maybe kind of look like capabilities and not activities, or very high level activities.

But in some way, I have no idea how I will minimise exposure to hazards at this stage of the project. But still, I have to describe the capability “Prevent human origin accidents”. Instead, I could delete this activity (minimise exposure to hazards) and directly bound the activity “create flight path” to “perceive operationnal information” using an interaction saying “propose safe flight path”, etc.

Like this :

Is it something that you recommend to do ? If not, why ?

Some interactions aren’t covered by any process. Is it a bad thing ? Should everything be covered by a process? If I take this example :

I could create a process for this interaction and I would call it “Send safe mode availability”. I could do it but I don’t see the point ?

The software proposes me to create an OPD. Like this by example :

But what is the point of creating an OPD? I can’t modify anything in it, right?

Is it useful later?

Is there something I forgot here?

I first defined the operationnal entites, then all the capabilities.

Now, for each capabilties I design one OAB (or OAIB depending on your answer). Then, I define all the process.

Then I might define some scenarios and mode/states. After that, I can go to the SA ?

My goal, like you said, is to simplify as much as much possible the OA to not have a huge SA after that. Trying to be high level. But also not spend 5 years on the OA level. Still, I do believe that it is important to have a good base.

Thank you again for your time Stephane !

Have a nice day,

Thomas

[StephaneLacrampe]

Hi Thomas,

Some answers:

We could speak in French, but it is beneficial to more people in the community if we stick to English.

Also, please note that I have some time limits on the time I can spend on helping people on the forum, you may want to seek for professional help on Arcadia/Capella is this is something you feel is needed in your case. I read that you don’t have this possibility. But it is always a good idea to benefit from someone expertise at the beginning of a large project rather than realizing too late that you would have done things differently if you knew.

1. Working only on activities is related to doing functional analysis work. When doing so, you’re not thinking about who is going to do what, just what’s need to be done. Sometimes if you’re just going straight to the OAB, you may limit you’re thinking to what you already know and may not be thinking outside the box (which is what architects are asked to do). But having said that, going straight to the OAB is completely ok. I do it often. Especially with lower complexity/known domains
2. Yes you can certainly hide information from some OABs if they are not useful. You may also have an OAB that has got everything on it (for you to work on) and smaller OABs for presentation purposes. Having the same activities in different OABs is completely normal. You don’t want to duplicate activities. OABs (and diagrams) are just views on your actual underlying model.
3. One OAIB per capability and one OAB per capability is completely ok, it is for you to decide how it is going to be the best to organize your model and diagrams depending on your context and objectives. And also, if you have one OAID and one OAB per capability, that does not mean that you do not have other OAIB and OABs if they provide value to you.
4. It is possible to create a circular one, but not from the start. Reason is because: even if it is circular, Capella needs to know which one to start with, and it is not making this choice for you. More info on how to do it here: Creation of functional chain - #8 by StephaneLacrampe
5. It all looks good. Maybe the activity “Send Human input to System” is a little bit too generic?
6. You are asking yourself the right questions. I don’t have all the answer, as to answer your questions, you need to know the system you are designing, your goals, objectives, etc… It requires experience, and it is ok to try and then evolves things as you learn more. One thing I would say though: You have Capabilities, Processes and the Activities. But also keep in mind that Activities are hierarchical. So “Minimuse exposure to hazards” is most likely not going to be a leaf activity, but a mother one with sub-activities (and could be sub sub sub sub activities depending on the complexity of your system)
7. Good question. It is not that it is bad. But Capabilities are described by scenarios and processes that are made of activities and exchanges. Also, Capabilities are contributing to the Mission. So one may ask: if this exchange is not required for the mission, by bother with it? If you have a good explanation for that, that is ok. Keep in mind that the same process (and questions) will happen at the SA/LA/PA level, so all the knowledge you are gaining here will be useful in the later stages as well. Reason why I am saying this is: Typically, V&V activities (testing plans) are driven by Functional Chains defined at SA Level. If one of your exchanges is not covered, then you are in danger that it will not be tested.
8. Yes you can, that is the whole point of OPDs. Typically, to achieve question 4.
9. I don’t know if you forgot anything. But I would not wait to transition to the SA, as there is not such thing like "waiting for a finalized OA to transition to the SA”. Going to the SA will make yourself ask new questions and realize that you may have forgotten things at the OA level, or put too many things, etc… It is a completely normal things to do both in parallel. And with the stakeholders.

All the best,

Stephane