Answers from Capella Days 2022 - Day 2

The 16th of November 2022 I hosted the second day of Capella Days 2022. 3 talks were presented that day by COMAC & PGM, Thales Avionic Systems and CILAS - ArianeGroup

Some questions were not answered during the live session. Here is a wrap up of these questions with the answers by the speakers.

Q&A by Renfei Xu (PGM) and Xinyi Tang (COMAC)

Q: Can you detail the way you ensure origin traceability when integrating models ?

We are using the attribute “sid” to ensure the traceability. For example, two functional exchanges in different models with the same “sid” will be treated as the same functional exchange in the integrated model.

Q: What other parameters get pulled from the PA model to feed the safety models you showed?

We will pull failure modes, local propagation of failure modes, interfaces between different functions and components to feed the safety model.

Q: Do you develop requirements from a clean slate using the OA layer? or do you use existing requirements from an external tool?

We mainly use existing requirements from DOORS

Q: Safety guys usually start working in parallel to design teams, thus they require a draft physical architecture asap. How did you deal with this issue?

I think we are not facing this issue. The development of physical architecture is ahead of safety model. There will be feedback and iteration if the architecture is not safe.

Q: Did you define criteria for the Auto-validation when using DiffMErge? e.g. did you solve only the errors and not the warnings that could be many?

Yes, we have defined our own criteria for Auto-validation when using Diff Merge. If there are errors, the integration will be abandoned. Otherwise, it will be done automatically.

Q&A by Stéphane Bonnet (Thales Avionic Systems)

Q: For the requirements’ consistency, does the tool check all the different of a textual requirement? For example, When , the shall . Whereas can be related to a mode and state machine, a to a PBS model element, to an FBS model element? Or it does create single traces? For example, a functional requirement linking to function model element.

This kind of checking could be done, but it would require a very detailed and rigorous modelling effort. The need of our teams at that stage was simply to relate to input/outputs. The tooling is basic: engineers use markers in the textual content of their requirements, and the tool processes that: whenever it finds something between markers, I check whether an element with the same name exist in the model.