Some questions were left unanswered because of lack of time et the end of the latest Capella webinar Making Arcadia work for you - A look at framework tailoring in Thales UK.
Below are the answers that the speakers, Alex Laing & Andrew Pemberton, have been kind enough to provide after the webinar. many thanks to them and the attendees for all the interesting questions!
You mention the importance of the data model - how have you captured your data model?
The data model for this project has been captured in a Visio diagram which is data centric. This has a âlayerâ on top of it which shows which tools are used to edit/manage each data artefact. This is referenced from the Systems Architecture and Modelling Plan (SAMP) for the project.
How do you share the model with modelâs users (not modellers). Within the Capella tool or html generation or only through generated documents?
During the process, at daily modelling stand-ups, the model is presented on screen and modellers guide the users through the model, discussing specific issue or topics. During review, we contextualise the views into one or more mini-documents as the baseline, comments are gathered and updates made to the model. The documents are exported using Thalesâ Mozart document generation tool. After the mini reviews of the material, full documents will be published and reviewed in the same way.
In e.g. the Big Picture view, where you need to output a signal from one function F1 to multiple consumer functions F2, F3 etc, do you duplicate the output port on F1 for the same signal or have one output port and duplicate the signal line from that single output port to the consumer functions? i.e. What signal connection approach do you use, 1-to-1 or 1-to-many?
We generally use 1-1 linkages for Functional Exchanges, using single Input and output ports. This is because currently we donât have any such use cases in our model (at the SA level). When we work on the Functions at the PA level then I can see that this use case might arise. If it does then we would make a decision based on whether the signals were always sent to the consumer Functions concurrently (in which case we may use 1-many), or not. We would also look at the Physical Architecture on which the Functional Exchanges were allocated, and if (for example) this was a bus-type architecture, then we would use a 1-many for âbroadcastâ exchanges. If not, then we would probably opt for 1-1.
How do you ensure the consistency between the SA and PA level when you correct something? As when you say you work both in parallel.
We have transitioned the Actors in the SA level through to the PA, so the physical/structural elements are linked and we can perform model checking and impact analysis where needed, if things change. Functionally, we will not transition the SA Functions until they have been fully approved. Going forward, if some functionality is deemed to be missing when we work in the PA level, then we would look to see if this would impact anything at the SA level an update it using a change process. This would be normal regardless of whether MBSE was being used.
Do you manage Non Functional Requirements within Capella? How do you validate them against your architecture?
We should have made this clear, so apologies â we are only using Capella to model the Functional System requirements. Any non-Functional requirements which impact the Functional or Physical Architecture which is within the scope of what is being modelled will be linked, but âtrueâ non-functional ones will be managed and validated outside of Capella.
Sorry if this is a whole topic in itself, but have you used âtailored Arcadiaâ in an Agile process?
Some elements of the management of this project used agile approaches; e.g. prioritisation of workload. Like with any development, parts of the model were progressed to a level of maturity before others, so while not a true agile approach, agile concepts were used.
40 functions at SA level. How many capabilities and functional chains? Thanks
Number of capabilities: 27
Number of functional chains: 68
For the further PAB diag with the functional aspect, do you intend to show function + Behavior PC + node PC, or only function + Behavior PC (for readability issue maybe?)
For these PAB diagrams the âcontextâ would be Behaviour PCs, so we would show Behaviour PCs + Functions + Functional Chains (optional).
Do you create a modelling plan as a formal project artefact? Is this a company standard template?
Modelling plans are produced against established company practice following the principal questions of why, what, how?
Firstly, we understand why we are modelling, who the stakeholders are and what their needs are. We design the project data model (or adopt the one that is already identified/referenced in the SEMP) to account for all the engineering artefacts that will be required to deliver the expected.
We donât have a company standard template but we do have and follow company practices and processes.
What is your approach to multiply people working on one model at the same time?
We host the model on a server using the Thales deployment of Team for Capella. This allows for collaborative working on a shared model.
Through the daily stand-ups and work package management, we agreed on which parts of the model each person will be working to try to de-conflict as much as possible.
How many different people worked on the model? Did you use Team for Capella?
We are using the Thales deployment of Team for Capella, yes. At the peak of the work we had 4 full time modellers and a couple of other project roles (architect and engineering manager) dipping into the model.
Hi, what does âFrameworkâ mean in this context to you?
In terms of the title of the talk, the framework is the set of engineering model elements, their relationships, and the views in which they are able to be presented.
You mentioned DOORS and integration with DOORS. Did you try to integrate with Polarion ALM?
On this project we did not integrate Capella with Polarion, as the project is currently using DOORS for its requirements management.
Thales will be switching to use Polarion for its requirements management in the future and work on achieving a more closely integrated environment using Capella and Polarion is underway.