For the above activities some will be detailed in sections below, others it will be provided references as it is not considered part of this guide:

1. “Create IBM Doors module”.
2. “Capture textual requirements and attributes”.
3. “Create export ReqIf module view”, this activity will be described in detail in a section below.
4. “Purge Deleted Objects”, this activity will be described in detail in a section below.
5. “Configure ReqIF Doors file export”.
6. “Export textual requirements from Doors module”.
7. “Export Capella project from the server”, this activity will be described in detail in a section hereafter.
8. “Import textual requirements”, this section will be described in detail in a section hereafter.
9. “Import Capella project to the server”, this section will be described in detail in a section hereafter.
10. “Formalise textual requirements and design the system”. A reference to why textual requirements is needed, and an approach to requirements modelling can be found within the Model Based System and Architecture Engineering with the Arcadia method book, Chapter 11.
11. “Establish textual requirements to model element traceability”. For this activity and if not created previously in the Capella model, there will be the need to created requirements traceability types.
12. “Export textual requirements and traceability”, this section will be described in detail in a section hereafter.
13. “Prepare and match csv file and Doors module attributes”, this section will be described in detail in a section hereafter.
14. “Import textual requirements and traceability”, this section will be described in detail in a section hereafter.

For the activities (1) and (2), a tutorial reference on how to create objects and attributes in IBM Rationale Doors can be found in the IBM Documentation.

For the activities (3) and (4), a reference can be found in the Exporting the ReqIF File by using Rational DOORS 9.6, section 3.

The process captured above is considered as part of the textual requirements synchronisation roundtrip context between an IBM Doors module and a Capella project, it can be used in initial stages of an architecture development for learning purposes, practise with Capella modelling tool or business case development for use and purchase of a Capella commercial add-on.

Create export ReqIf module view

In order to export requirements and heading it can be created a tailored ReqIF export view.

In the Capella modelling tool, new filters can be created by clicking on Menu Tools -> Filter -> Define; then to create the filter for section 4 headings and requirements, the following filter should be created:

Then save the view by clicking on Menu View -> Save as.

When creating the ReqIf step 4 above this view should be referenced as below:

When created the ReqIf file it will include section 4 objects.

Purge Deleted Objects

When objects are deleted, they still remain in the module. In order to deleted them permanently, from the module the objects need to be purged. Before the purge action, it is advised to create a minor baseline of the module, so the objects can be referenced back if needed.

In order to purge Doors module object, there is the need first to see the deleted objects. Click on Menu View -> Show -> Deletions. Then right-click over the object and select “purge” as shown below:

Import textual requirements

The first step in Capella is to make sure that it is possible to see the requirements.

For this follow the steps described in:

• Visualize types
• Show requirements in semantic browser

User attributes might have been created, updated, and exported from the Doors module at the time when exporting module view content to ReqIF file. The system modeler may want to have access to this attributes and current set status, for example, if there is an attribute that captures:

• Requirement types: what type of requirement are defined (e.g., functional, or non-functional) or
• Requirement status: what is the requirement status (e.g., draft, released, reviewed).

In order to, import the Doors module user attributes, there is the need first to create a file with the extension .properties.

To create a .properties configuration file, follow the following steps:

1. Create a new notepad file.
2. Wright the name of each of the variables to be imported, for example, for the Doors module attribute “Requirement type”, write in the format “Requirement\ type: true”. True means the variable will be available to import in Capella. Note, there is the need to add a “\” for each space and make sure the space is added. Careful should be taken as Capella is case sensitive.
3. Save as the file in the format: name.properties.

A properties file content example can be found below:

In Capella go to the menu: Window -> Preferences -> Capella -> Requirements -> Importer.

In the importer window:

• Manage files containing set of attributes section, add the file .properties.
• Select attributes to import section, choose which user attributes to import as below:

At this stage you should be able to import the Doors module textual requirements. A reference on how to import ReqIF can be found in: ReqIF Import in Capella.

When imported the ReqIF file, you should be able to see a similar Types folder and Requirements as below:

Teams for Capella ReqIF limitations

This section covers the process activities:

• “Export Capella project from the server”
• “Import textual requirements”.
• “Import Capella project to the server”.

Teams for Capella does have limitations. It is not possible to import a ReqIF file to a CDO server project. Hence, before importing the textual requirements and attributes there is first the need to “Export Capella project from the server”, that is, export the Capella project to a local drive, “Import textual requirements” and finally, the “Import Capella project to the server” activity.

More details can be found in the Teams for Capella.

Server import requirements limitations

When model is stored on a server the following steps need to be followed:

• When a reqif import is performed in a Capella project, a .capella.bridgetraces is created (filtered by default).
• As the file is hidden in the local Capella project, if you handle the version of your project in git, it will be in your next commit and updated after each import.
• The bridgestraces is not considered as part of the model, hence, not imported to the server.
• To import a reqif to a shared project: there is the need to copy/paste the .bridgeTraces inside it from the precedent import and then store the file on the server.

Bridgestraces file can be found under the workspace -> model (e.g. Electrical Infrastructure).

Textual requirements roundtrip

The following activities will be described in this section:

• “Export textual requirements and traceability from Capella”
• “Prepare and match csv file and Doors module attributes”.

It is relevant to make sure the above step were followed for the first time, that is, Capella imports the textual requirements ReqIF file exported from Doors and not creating a new requirements module in Capella. This activity will allow Capella to create and configure the Capella Requirement Module with the ReqIF Identifier as captured below:

The ReqIF Identifier is unique when exporting from the same Doors module and will be used by Capella to map and update the Capella requirements relevant module.

Later iterations, it will be allowed any order and parallel work of the following activities:

• Update Doors requirements and/or attributes, export to a ReqIF file, and import to Capella OR
• Update Capella textual requirements to model elements traceability updates, export to csv file and import to Doors.

Careful should be considered and a process should be defined when updating requirements in Doors and traceability in Capella.

It is suggested later in the Architecture section, what and where textual requirements and traceability to model elements should be performed and maintained.

Export Capella requirements to csv file

In order to do the “Export requirements from Capella” activity, a number of sub-activities can be performed as it will be described hereafter in this section.

How to guides can be found in view requirements in Capella. The guide describes:

• How to visualise requirements in a diagram.
• How to show requirements in a tabular format.
• Sort and group requirements and verify requirements traceability in a table.

It is recommended that only requirements model types are sent to the Mass Visualisation table, that is, not folder package types should be included. This allows to have the same set of attributes per view.

From the set of attributes at least the three below should be available (not hidden):

• ReqIFForeignID.
• ReqIFText.
• Allocating Elements.

Prepare csv file

We are now in a position to export the requirements and attributes to a csv file as described in Editing requirements attributes. A similar exported csv file should be shown as below:

There is the need prior to importing requirements back to IBM Doors module to “Prepare and match csv file and Doors module attributes”. The following steps need to be performed in the csv file exported:

• Delete line 2; line 2 will create an empty object in Doors.
• Rename attribute ReqIFForeignID to Absolute Number.
• In the ReqIFForeignID, format each of the .csv cells field to general.
• Delete the <div> and </div> from the ReqIFText.
• Rename ReqIFText to Object Text.

The csv file export updated and before importing to Doors should contain the following attributes:

To import a csv file to Doors, open the Doors module from where it was exported initially the textual requirements and click on File -> Import -> Spreadsheet as shown in the below figure:

Select the csv file location and keep the default settings as below:

When clicked in the “import” button, Doors will ask for any new attributes to create in the module. For the first time the csv file is imported into the IBM Doors module, it will need to be created the attribute “Allocating Elements”. This attribute contains the model element traceability done previously in Capella; confirm the new attribute.

Doors will then ask what the reference attribute for the object requirement unique ID is, select the attribute “Absolute Number” as shown in the below figure:

Doors will then present a window with the number of objects created and/or created, as below:

The final step will be to ensure that the import has been done correctly. For the object requirement below the only change was the allocating element updated with allocated element “System”.

This roundtrip process can be repeated when needed to synchronize textual requirements authored in the IBM Doors module or when new model elements traceability is done in Capella.

Architecture

The figure below shows the roundtrip directional flow that must be followed for textual requirements roundtrip synchronisation between an IBM Doors module and Capella requirements module.

In the figure below it can also be seen the tools attributes management and ownership:

• IBM Doors module: generates object unique IDs, which are associated to textual requirements and textual requirements are associated to attributes.
• Capella tool: holds and manages the requirements to model elements traceability within the project.

It is envisaged that other formats can be exported from the Capella tool, such as, model HTML pages and Word documents. The IBM Doors module can then be baselined as well as the Capella project can be created Git repositories for change control management, as below:

The post How to perform Capella–IBM DOORS 9.x round‑trip synchronisation for textual requirements: step-by-step guide first appeared on Hélder Castro.

In most engineering practices today, requirements constitute the main vector for managing technical contracts between customers and suppliers, at any level of the breakdown. Quite often customers express their needs as requirements using natural language and suppliers analyse, interpret, reformulate, refine, and complete these requirements in order to describe the expectations on the solution system. A flaw of these practices is that requirements are sometimes the main vector to perform design analysis and describe the architecture of the solution and suffer from weaknesses that may impact engineering and product quality when used too extensively or inappropriately.

• Because in most cases textual requirements are written in natural language, they are possibly ambiguous, contradictory, or incoherent with each other. Guides and rules have been written to help and guide the textual requirements authoring; INCOSE Guide for Writing Requirements or the standard ISO/IEC/IEEE29148 can be used as reference. In addition to author good requirements, requirements patterns should be considered. Requirements patterns provides a consistent style when authoring the different types of requirements, enhancing requirements consistency, understandable; Easy Approach to Requirements Syntax (EARS) and Sophist requirement patterns are good examples.
• The relationships and dependencies between textual requirements are difficult to express.
• In most cases, textual requirements cannot be checked or verified by digital means.
• The process of creating traceability links to each requirement (for design, verification and validation, for sub-contracting, etc.) is often unclear and not guided by a well-defined methodological approach. The means to verify these links are undefined and the quality of these links proves to be insufficient in many cases (this is often only discovered in V&V phases).

Model-based systems engineering (MBSE) has developed significantly over the last few years, resulting in an increased usage of models in requirements modelling, systems specification and architecture description.

MBSE covers a very broad spectrum of applications, spanning from high-level architecture modelling to detailed design at the frontier of simulation. More about the MBSE role can be read in my previous article: What is Model-Based System Engineering.

MBSE do have drawbacks as not all expectations can be expressed or captured in a model; environmental constraints (temperatures, corrosion, etc.), applicable norms and standards, required maintenance period, for example, would be difficult to express with model elements. Certain model elements are too complex to be considered and not clear about the added value to the system engineering activities.

The question of the positioning of requirement engineering versus MBSE is a recurrent one:

• Are requirements still needed if an MBSE approach is used?
• Do models describe existing requirements, or do they help elicit them?

Models are not intended to replace textual requirements, they complete each other and must typically be related to each other, for example in the following situations:

• Model elements that formalize a textual requirement should be linked to it by traceability/justification links, typically the case with customer requirements.
• Some expectations on a model element are easier or simpler to express by textual description; this description can be captured as one or more textual requirements that will be linked to the model element by satisfaction links.
• Textual requirements will remain in the scene since they are also key for testing, certification, and communication with other stakeholders.

The next section will highlight another factor to consider, traceability and consistency between requirements and models.

Requirements and models traceability consistency

Textual requirements and models not always are captured under the same tool, in fact it is quite common in projects and organisations, requirements captured in a requirements management tool (e.g., IBM Doors) and models architecture in a modelling tool (e.g., Capella).

In addition to the above, the role of requirements specification and models architectures definition can be split by more than one team member and performed in parallel, communication plays a key role, however, inconsistencies between specification and the model do often emerge when traceability is performed.

When requirements are imported into the modelling tool, traceability links (e.g., satisfy, refine) with the appropriate model element can be performed. Requirements and the allocating element can be exported and imported back to Doors. This closes the loop and provides traceability visibility in both ends.

The below figure shows a manual approach for textual requirements to model elements process, between IBM Doors and the Capella tool:

Importing ReqIF file to Capella

User attributes might have been created, updated, and exported from the Doors module at the time when exporting module view content to ReqIF file. The system modeler may want to have access to this attributes and current set status, for example in the Capella modelling tool, for example, if there is an attribute that captures:

• Requirement types: what type of requirement are defined (e.g., functional, or non-functional) or
• Requirement status: what is the requirement status (e.g., draft, released, reviewed).

In order to, import the Doors module user attributes, there is the need first to create a file with the extension .properties.

To create a .properties configuration file, follow the following steps:

1. Create a new notepad file.
2. Wright the name of each of the variables to be imported, for example, for the Doors module attribute “Requirement type”, write in the format “Requirement\ type: true”. True means the variable will be available to import in Capella. Note, there is the need to add a “\” for each space and make sure the space is added.
3. Save as the file in the format: name.properties

A properties file content example can be found below:

In Capella go to the menu: Window -> Preferences -> Capella -> Requirements -> Importer.

In the importer window:

·         Manage files containing set of attributes section, add the file .properties.

Select attributes to import section, choose which user attributes to import as below (e.g., L2 SRD):

It is fundamental to make sure the above step was followed for the first time, that is, Capella imports the textual requirements ReqIF file and not creating a new requirements module in Capella. This activity will allow Capella to create and configure the Capella Requirement Module with the ReqIF Identifier as captured below:

The ReqIF Identifier is unique when exporting from the same Doors module (it should be used the current IBM Doors module) and will be used by Capella to map and update the Capella requirements relevant module.

Later iterations, it will be allowed in any order and parallel work of the following activities:

• Update Doors requirements and/or attributes, export to a ReqIF file, and import to Capella OR
• Update Capella textual requirements to model elements traceability updates, export to csv file and import to Doors.

Careful should be considered and a process should be defined when updating requirements in Doors and traceability in Capella.

Textual requirements to Capella model elements traceability

The ReqIF Identifier is unique when exporting from the same Doors module (it should be used the current IBM Doors module) and will be used by Capella to map and update the Capella requirements relevant module.

Later iterations, it will be allowed in any order and parallel work of the following activities:

• Update Doors requirements and/or attributes, export to a ReqIF file, and import to Capella OR
• Update Capella textual requirements to model elements traceability updates, export to csv file and import to Doors.

Careful should be considered and a process should be defined when updating requirements in Doors and traceability in Capella.

Textual requirements to Capella model elements traceability

When traceability is being performed, inconsistencies may emerge. For example, the below figure on the left shows a logical breakdown of a logical component and a textual requirement on the right. Core Aircraft Interface is not part of the Aircraft Front Servers. Hence, for a number of reasons, both specification and architecture are not aligned and inconsistent. Either the model element needs to be added or revisited the requirement.

A requirement can be captured: “The IFE system shall have Aircraft Front Servers”.

The above process can be done for a small number or requirements and model elements. When a project is in a early phase or a Minimum Viable Product (MVP). However, as the number of requirements and model complexity grows, the process and traceability verification effort will follow.

Expanding traceability consistency

As mentioned in the section above, requirements and model elements traceability consistency are often unclear and not guided by a well-defined methodological approach. The means to verify these links are undefined and the quality of these links proves to be insufficient in many cases.

What if rather than linking the full text requirement to a model element, wouldn’t it be better to link a requirement to each and correspondent model element? To answer this question, there may well be the need to explore and use requirements patterns for a parsing process.

Considering the following pattern:

And the pattern slots relationship to model elements concepts (example):

• [Condition], to a state in a state machine.
• <System>, to an element in a Product Breakdown Structure (PBS).
• <process verb>, to a function in a Functional Breakdown Structure (FBS).

The above relationship between requirement patterns slots and model elements concept, may promote traceability consistency between requirement and model elements at the time a requirement is being authored. Furthermore, it could be automated and generated traceability links.

Going further, this may well be the underlaying principle for parsing and automate the generation of:

• Model elements from textual requirements.
• Textual requirements from the model.

The textual requirement to model elements traceability consistency is ensured by the relationship of each slot content to the existing model element, changes and updates will be easier to detect, and traceability review time greatly reduced.

The post How to configure Capella for ReqIF import and high-level textual requirements traceability first appeared on Hélder Castro.

Transition from Logical Architecture

Transition activities from Logical Architecture to Physical Architecture model:

• Perform an automated transition of Logical Functions.
• Perform an automated transition of External Logical Actors.
• Perform an automated transition of Logical System.
• Logical Architecture Capabilities Functional Transition

Physical Architecture Activity explorer, as below:

Perform an automated transition of Logical Functions

Starting with the “Perform an automated transition of Logical Functions” and when Functional Transition window opens, all the candidate model elements will be copied to the resulting model. To copy all elements, click on “Copy all to the right”, as below:

Perform an automated transition of External Logical Actors

Next, “Perform an automated transition of External Logical Actors” and when the Actors Transition window opens, all the candidate model elements will be copied to the resulting model. To copy all elements, click on “Copy all to the right”, as below:

Perform an automated transition of Logical System

Next, “Perform an automated transition of Logical System” and LC / LA to PC / PA Transition window opens, all the candidate model elements will be copied to the resulting model. To copy all elements, click on “Copy all to the right”, as below:

Only part of the Logical Components Breakdown is possible to be shown in the figure above.

Logical Architecture Capabilities Functional Transition

For the Functional Chain transition captured at Logical Architecture to Physical Architecture, it will be used in the Functional Transition of the Logical Capability. This will show another tool capability to transition model elements. For Logical Capability Functional Transition, select from the Project Explorer “Perform Flight On-Board Announcement” Capability, then mouse right-click “Transitions” > “Functional Transitions”, as below:

When the Functional Transition window opens, expand the model packages under synthesis, and the Capability, as below:

When performing the Capability Functional Transition, it will also be transitioned the Functional Chain owned.

When all the above transitions are complete, the Physical Architecture (partly shown) should be as below:

Physical Architecture to Logical Architecture realisation links

Similarly, to Logical Architecture transition, realisation links are created during Physical Architecture transition providing traceability between model elements captured at Physical Architecture and Logical Architecture as figure below:

Realisation links types:

• A: Physical Components realise Logical Components.
• C: Physical Capabilities realise Logical Capabilities.
• F: Physical Functions realise Logical Functions.
• P: Physical Functional Chain realises Logical Functional Chain.

Capabilities Realization at Physical Architecture

Steps to create the Capability Realization Blank diagram, insert Capability Realization and Physical Actor model elements in the diagram are the same as described in section above. The Physical Capability Realisation Blank diagram, as below:

Define Physical Functions

Steps to create Physical Function Breakdown diagram, insert Physical Functions and change Functions background colour are the same as described in previous section. When completed the diagram should be like the one below:

From a design analysis, new functions can be added that are identified and related to specific technologies. New functions were added to the Functional Breakdown structure, as below:

Define Functional Exchanges

The steps and process to insert Functions and Interactions and organise the diagram is like described in the previous section. When completed the Physical Data Flow Blank diagram should be similar to diagram below:

Define Behavioural and Physical Nodes

Steps to create a new Physical Component Breakdown Diagram (PCBD) is the same for Physical as Logical. Create the new PCBD under the Structure package. Organise and change the background colour to white, as below:

From the palette click and create new Node Physical Component (PC) and Behaviour Physical Component (PC):

Create the component breakdown structure, as below:

Allocate functions to Behavioural Nodes and deploy Physical Nodes Components

Node Physical Components, allocate Behavioural Nodes Components, Behavioural Components implement Functions. To make the relationship of model elements the Physical Architecture Blank diagram will be used.

Create a new diagram under Structure package. When diagram opens

• Insert first Node PC in the diagram.
• Next from the palette click on “Manage Node PC’s Deployment” and select the Behavioural PC for each Node.
• When Behavioural PC are allocated to the correspondent node PC, Functions can be shown or allocated to the Behavioural PC.
• Create Component exchanges between Behavioural PC.
• Allocate Component to Function Ports.

When completed the Physical Architecture Blank diagram should be the same as below:

At this level Physical Links can also be captured. Physical Links connect Node PCs.

When Physical Links are defined, Components Ports should be allocated to Physical Ports and define Physical Paths.

Let’s create a first Physical Link “Audio Stream Data Cable” that will allow audio and video streaming between ASU Processor and VSU Processor. Also allocated Physical Ports to Component Ports, as below:

A Physical Link can be created that captures all the Node PC. To create a Physical Path is like creating a Functional Chain. Select all the Physical Links created previously, then mouse right-click and select “Physical Path”. When creating the Physical Path, change the name to “Audio Stream Data Path”. When completed the Audio Stream Data Path is shown in the diagram, as below:

For diagram simplicity, let’s hide Functions and functional Exchanges. To hide both Functions and Functional Exchanges there is only the need to hide Functions. To hide functions, click on the diagram “Filters”, then the “Hide Functions”.

Create the Physical Links, Port allocations and Physical Paths, as below:

Let’s create the Physical Path. Select “Audio Stream Data Path”, then mouse right-click, the “New Physical Path Description”. When completed reorganise the diagram, as below:

Keep the same name as default: [PPD] Audio Stream Data Path

Repeat the process above for the other two Physical Paths.

Describe Capability Realization with Functional Chains and Scenarios

New Physical Functions were created; hence, it is expected to have an invalid Functional Chain, previously transitioned from Logical Architecture. In this section it will be described how to correct the invalid Functional Chain. It will use the Physical Data Flow Blank diagram defined under Perform Flight On-Board Announcements Capability. The Functional Chain shows invalid, as figure blow:

To correct the Functional Chain, select the “Play Imposed Video” Functional Chain, then “New” > “Functional Chain Description”. 

Keep the same default name: [PFCD] Play Imposed Video

When corrected the Functional Chain it should be similar to the diagram below:

Scenarios could be created as described in previous sections.

MBSE Arcadia step-by-step quick guide

This document includes:

• MBSE Arcadia matrix in one slide
• MBSE with Arcadia steps and diagrams with description
• References to the MBSE with Arcadia step-by-step guide online

Download PDF879 Downloads

The post Capella Physical Architecture practical example first appeared on Hélder Castro.

Transition from System Analysis

Transition activities from System Analysis to Logical Architecture model:

• Perform an automated transition of System Functions.
• Perform an automated transition of System Actors.
• Perform an automated transition System Analysis Capabilities.
• Transition of the Functional Chain.

Logical Architecture Activity explorer, as below:

Starting with the Perform an automated transition of System Functions and when the Functional Transition window opens, all the candidate model elements will be copied to the resulting model. To copy all elements, click on “Copy all to the right”, as below:

Note in the figure above that when in the transition it is also transitioned the allocated component ports to functional ports under the structure package.

Repeat the process above for the other two automated transitions.

When completed the activity explorer automated transition the Logical Architecture package should be as below:

Finally, it will be transitioned to the Functional Chain that describes the Perform Flight On-Board Announcements Capability Realisation. To perform a Functional Chain transition, select from the Project Explorer and under “System Analysis > Capabilities” the Play Imposed Video Functional Chain, as below:

Functional Chain transitioned to Logical Architecture:

Functional Chain transitioned to Logical Architecture:

Logical Architecture to System Analysis realisation links

Similarly, to System Analysis transition, realisation links are created during Logical Architecture transition providing traceability between model elements captured at Logical Architecture and System Analysis as figure below:

Realisation links types:

• A: Logical Components (Actors) realise System Actors.
• C: Logical Capabilities realise System Capabilities.
• F: Logical Functions realise System Functions.
• P: Logical Functional Chain realises System Functional Chain.

Capabilities Realization at Logical Architecture

Let’s start creating a new Capability Realization diagram. To create a new Capability Realization diagram, select from the Project Explorer “Capabilities”, then “New Diagram / Table…” > “Capability Realization Blank”, as below:

Keep the same name as default: [CRB] Capabilities.

Insert Actor to Capability Realisation Blank diagram. To insert Actor, select from the Palette and under Tools “Actors”. When the transfer dialog window is shown select only “Cabin Crew”, then “Add selected element(s)” > “Ok”, as below:

Insert Capability Realisation in the diagram, as below:

When completed the Capability Realisation Blank Diagram should be similar as below:

This diagram will not be changed at Logical Architecture; however, it is represented in a diagram what Capability realises the Capability defined at System Analysis, which realises an Operational Capability at Operational Analysis.

Define Logical Functions

The process to define Logical Functions is very similar to System Analysis. To create a Logical Functional Breakdown Diagram, select “Root Logical Function”, then mouse right-click “New Diagram / Table” > “Logical Function Breakdown”, as below:

Keep the same default diagram name: [LFBD] Root Logical Function.

When the Logical Function Breakdown diagram opens change the fill colour to white. This is a good practice that allows to identify what functions were transitioned from System Analysis and that may be refined. Also note that function icon shows “LF”, whilst at System Analysis it was “SF”. When completed the Logical Function Breakdown diagram should be, as below:

Add, resize, and move functions, as Function Breakdown diagram below:

Define Functional Exchanges

Next it will be created a Logical Data Flow Blank diagram that describes the Perform Flight On-Board Announcement Capability Realisation. Select from the Project Explorer “Perform Flight On-Board Announcements”, then mouse right-click “New Diagram / Table…” > “Logical Data Flow Blank”, as below:

Keep the same diagram name as default: [LDFB] Perform Flight On-Board Announcements.

When the diagram opens insert Logical Functions in Logical Data Flow Blank diagram. To insert Logical Functions, select from the Palette “Functions”, then click in a blank area of the diagram. When the transfer dialogue window opens click on “Add all elements” > “Ok”, as below:

When functions are inserted into the diagram, functions will need to resize and moved to make the diagram readable.

Diagram colours are unique to each diagram, hence, there is the need to identify what functions were transitioned and change the fill background to white. After initial rework on the diagram, it should be like the diagram below:

New Functional Exchanges will be created, and some functional ports moved. Creating Functional Exchanges at Logical Architecture is the same as described at System Analysis. Hence, it will not be described again. Create the Logical Data Flow Blank diagram, as bellow:

Define Logical Components

At this point, it will be created a Logical Components Breakdown diagram. To create Logical Breakdown Blank diagram, select from the Project Explorer “Structure” package, then mouse right-click “New Diagram / Table…” > “Logical Component Breakdown”, as below:

Keep the same diagram default name as [LCBD] Structure.

When created and opened the diagram it shows the Logical System and Logical Actors as below:

New Logical Components will be created. To create new Logical Component, select on the Palette “Logical Components”, then click on the Logical System. A new Logical Component will be created. Rename the Logical Component to Aircraft Front Servers, as below:

Repeat the process above and create the Logical Component Breakdown Diagram, as below:

Allocate Logical Functions to Logical Components

To allocate Logical Functions to Logical Components previously created, it will be created the Logical Architecture Blank diagram. To create a new Logical Architecture Blank diagram, select “Logical System” under Structure package, then mouse right-click “New Diagram / Table…” > “Logical Architecture Blank”, as below:

Keep the diagram name as default: [LAB] Logical System

When Logical Architecture Blank diagram is open from the Palette: Insert Components and Actors, as below:

Rearrange and resize Logical Components and Actors as below:

Rearrange and resize Logical Components and Actors as below:

We can now allocate functions to Logical Components. To allocate functions to Logical Components, select from the Palette “Manage Function Allocation”, then click on a Logical Component, select, and add the correspondent Logical Function, as diagram below:

Finally, Component Exchanges and Functional Ports need to be created. To create Components Exchanges and Functional Port allocations, is a similar process as described at System Analysis. When the diagram is complete it should be as below:

Describe Capability Realisation with Functional Chains and Scenarios

The Play Imposed Video Functional Chain was transitioned from System Analysis. It can now be inserted and shown in diagrams. From the palette select “Functional Chain” and click on a blank area of the Logical Architecture Blank diagram, as bellow:

In the diagram next to the Functional Chain name is shown as invalid. Again, the reason is that functions transitioned from System Analysis were refined at Logical Architecture and only leaf functions were allocated to Logical Components. Hence, there is the need to correct the Functional Chain. To correct the functional similarly to what was described at System Analysis, there is the need to create a new Logical Functional Chain Description diagram. To create a new Logical Functional Description diagram, select from the Project Explorer Play Imposed Video Functional Chain, then mouse right-click “New Diagram / Table…” > “Functional Chain Description”, as bellow:

Keep the same diagram name as default: [LFCD] Play Imposed Video.

The Logical Functional Chain Description diagram first time opened should be like below:

When complete the Logical Functional Chain Description diagram should be like the below:

Logical Architecture Blank and Logical Data Flow Blank diagram below showing corrected Functional Chain:

The post Capella Logical Architecture practical example first appeared on Hélder Castro.

Natural language textual requirements can be constructed based on templates in order to set up a complete, uniform set of requirements. This enables a common understanding between the author and the reader about the intention of the requirements. These requirements may be implemented systematically into a system analysis model or used in the acceptance criteria for tests and system verifications. The process of starting with an idea up to creating a perfectly written requirement and its further processing, for example in a model, is being systemized.

The analysis and improvement of textual requirements would not be necessary, if requirements of high quality, meaning correct and comprehensible, were available from the start.

Constructing requirements according to certain rules is a means of avoiding mistakes from the very beginning. This way of creating requirements makes it possible to assign a similar structure to each requirement and eliminates many of the possible mistakes being made in wording the requirements, like passive sentences, which usually don’t offer any information about what functionality is being expected from whom. Similar to building a house according to an architect’s plan, it is possible to construct a requirement according to a plan, or rather according to a template.

These are called generic, syntactical requirements templates, since only the syntax (structure) of a requirement is defined, not its semantics (the contents).

Writing perfect requirements from the beginning means to consider several aspects, to ensure correctness, well structured, and consistency. Requirements should free of mistakes, well-structured with the requirements patterns support and consistent with glossaries and models.

Below an image of the three aspects that should be considered:

Requirements management tools are widely used to manage both requirements and relationships between them and often maintained in a database.

Requirements can be depicted on diagrams captured in a Model-Based System Engineering (MBSE) model (model will be referenced as a MBSE model), it is useful in representing the traceability of a single requirement to examine how that requirement is satisfied, verified, and refined, and to analyse its derived relationship with other requirements.

Models aims at centre of the interactions between all engineering stakeholders, in order to benefit from an increased rigour and improved communications. This means not only system architects but also customers, specialty engineers, V&V engineers and others may work and benefit on the basis of the model information, either by contributing to the model or by consuming its outputs.

This connection of architecture models with the surrounding engineering activities is implemented either by linking models to other engineering artefacts, or by extracting and transforming data in the right format (document generated from the model, data in excel sheets, code structure and interfaces generated from the model, etc.).

A combination of tool automation, the requirement management process and configuration management can be defined to synchronise the requirements between the requirements management tool and the model. This capability is intended to improve requirements management throughout lifecycle of a system by enabling rigorous traceability between textual requirements and the model elements.

Models are not intended to replace textual requirements; model elements and textual requirements complete each other and must typically be related to each other, model elements help to formalize a textual requirement, for example, stakeholder requirements.

Requirements engineering is indisputably the backbone of the current engineering practices. Hence, the need of the articulation of requirements with models is essential. As captured in the figure below Model and requirements traceability, a project or organisation may have different needs to create several models, for example, breakdown a system complexity, hand-over a system or component to a team or supplier.

As mentioned above, models help to formalize and consolidate the customer and system textual requirements needs. In Arcadia, need models are covered by the two first engineering perspectives:

• Operational Analysis focus, on the needs of the system from any stakeholders that will interact or do have an interest on it.
• System Analysis focus on the system itself, what is expected from it.

A solution/architecture model helps validate the feasibility and elicit/justify new requirements for the system or its subsystems. In Arcadia, solution is covered by:

• The conceptual Logical Architecture focus on, how the system should work to fulfil the system needs.
• The developed Physical Architecture focus on, how the physical system will be built.

Different types of traces can be created:

1. Between textual requirements: normally created and maintained within the requirements management tool.
2. Between model elements and textual requirements: directly in the model and textual requirements if requirements captured or imported into the model, or a tool that provides the capability to connect both the modelling and requirements management tool to create trace links.
3. Between model elements: normally created by the modelling language or modelling tool.

In the section hereafter, it will be captured examples of different types of traceability relationship links.

Traceability relationship types

Textual requirements and model elements traceability relationships can be specified. These include relationship for defining a requirements hierarchy, deriving, satisfying, verifying, refining, and copying requirements, as well as general purpose trace relationship.

In the table below, it is captured common types of traces accompanied by a description of its intended use:

A requirement specifies a capability or condition that should (or shall) be satisfied, a function that a system must perform, or a performance condition a system must achieve.

In general terms, textual requirements and model elements can be traced and linked as follows:

• Functional requirements are likely to be traced to Capabilities, Functions, Functional Chains, Scenarios, Modes, States.
• Other non-functional requirements can also be traced to model elements, for example, to Functional Chains capturing latency constraints, datatypes, classes, physical quantities, and structural elements.

Life cycle and artefacts

Figure below illustrates the relationships between models and textual requirements across several levels of engineering. A good practice is to separate the artefacts in different modules based on configuration management scopes, so as to preserve independence of lifecycles:

Figure above, shows a typical workflow for architectural design based on the Arcadia engineering method:

1. Stakeholder requirements document captures the stakeholder high-level requirements expectations and their objectives, and normally, the input to the model.
2. Operational Analysis formalizes stakeholder requirements by using Operational Activities and Processes. Performing the analysis of the stakeholder expectations with a model helps check their consistency and completeness.
3. System requirements document captures system requirements that the system must do by analysing both stakeholder requirements and the operational analysis. System requirements are derived, captured, and traced (derivation links.
4. System Analysis goal perspective is to formalize system textual requirements and capture what the system must accomplish. Traceability between Operational Analysis and System Analysis models ensures completeness and paves the ground for later impact analysis.
5. Definition of the solution, justified by the System Need Analysis model. Possibly described at different levels of abstraction Logical Architecture and Physical Architecture, the architecture description specifies first how the system should work to satisfy the needs captured at System Analysis.
6. The Physical Architecture goal is to prepare the contracts for all subsystems and guarantee their proper integration, with the adequate level of detail how the system works and what is expected from each constituent. Instead of simply allocating (or cascading) textual requirements to elements of the Product Breakdown Structure, performing a rigorous, model-based design analysis has multiple benefits. In particular, the solution can easily be shared with all stakeholders: how the system works, what is the contribution of each component, what are the transitions between modes and between states, what are the impacts of modes and states on functional expectations, etc.

The specification of the subsystems with a model comes at no extra cost when the system architecture has been properly modelled. Arcadia advocates a recursive application of the method, and the Capella modelling tool provides an automated, iterative transition from system to subsystem. The context of a given system constituent is entirely computed (anything contributing to the definition of this constituent including allocated Functions, interfacing Components, etc.) and a downstream System Analysis model is initialized and maintained based on the evolutions of the system definition. The subsystem Analysis in Arcadia perspective is a centrepiece of the contract for the downstream engineering team.

The combination of model-based approach and automated system to subsystem transition as illustrated above favours co-engineering over the traditional differentiation between customer requirements and system requirements.

Conclusion

Textual requirements still form the backbone of systems engineering practices. However, textual requirements can be formalized and supported by a model and improving the transition between systems and subsystems.

Arcadia can be used to model text-based requirements and relate them to other requirements and to other model elements. The requirements modelling capability serves as the bridge between traditional text-based requirement and the modelling environment. Requirements can be directly created in the modelling tool or imported from a requirements management tool.

Integrating models in the technical contracts for the subsystems is a way to strengthen their specification and to guarantee their good integration in the global solution.

Finally, bridging textual requirements to models contributes to reduce lack of understanding, promote communication, consistency, completeness, and correctness in a single source-of-truth.

The Arcadia method is a Model-Based Systems Engineering (MBSE) approach structured around abstraction layers to support the development of complex systems. The MBSE with Arcadia guide explains Arcadia step-by-step — from Operational Analysis through Physical Architecture — with a focus on what each layer means, what activities are performed, and how it supports coherent system development. The guide is supported by the MBSE Arcadia Matrix below. Click on the image below or read more here.

The post Formalizing textual requirements in a model to improve articulation first appeared on Hélder Castro.

The Capella System to Subsystem add-on allows transition and creation of new models from a parent model element. The transition extracts relevant model information from a selected Capella model element and creates top-down traceability links. The model of the subsystems is computed from the parent system.

The transition and iterative approach between system and subsystems is a great help for managing several levels of engineering and complexity.

Ideally, subsystems stakeholders are involved in engineering activities at system level before the transition occurs.

Capella provides several options to perform model transition. This article does not intend to elaborate on the different transitions, but on the traceability and relationship between the different model elements, and decisions and ways of working that may need to be considered in advance when working with a federated Capella model environment.

The below figure shows a generic product breakdown structure (PBS) and a Capella model structure when performed several vertical transitions of the correspondent parent model elements.

The Capella model structure presented below focus on part of PBS elements (blue) that will be used on this article. The System-of-Interest (SoI) can be considered as a system of systems.

Capella elements by default don’t have any SID. As soon as, a transition is performed and if:

• The SID of the source element is null, it is initialized with the technical ID of the source element.
• The SID of the source element is not null (i.e., the system is already a sub system, result of a transition or manually defined by the model owner), the SID is kept.

The Capella System to Subsystem described above captures aspect when it is always performed a top-bottom process, the tool creates traceability references between the transitioned model elements and the source model (parent).

As it can be observed in the figure below, model elements ID are unique to each model element, but the SID between two model elements (underlined) shall be the same. That is the reference and traceability reference between model elements in different models.

But what if:

1. There is the need to update and add functions, functions exchanges, etc. to the assembly A.1?
2. Assembly A.1 has been developed in isolation and in parallel with parent System A?
3. After a system to sub-system transition, the Product Breakdown Structure (PBS) has been updated and the traceability links between System A and assembly A.1 need to change?

For the first scenario:

It is highly recommended to work and update, when possible, the physical layer of the System A (parent) and then do the System to sub-system transition.

Update the assembly A.1 diagrams accordingly. Traceability between System A and assembly A.1 is created by the tool.

If the steps above are not able to be performed, then the steps defined for scenario 2 as below, may be followed.

For the second scenario, there is the need to perform several steps:

1. Edit and assign manually SIDs for each and all model elements, that is, Functions, Functional Exchanges, Capabilities, etc. defined in the System Analysis of the Sub-system A.1.
2. Update and add the new model elements to the physical layer of the System A (parent model).
3. Perform a System to Sub-System transition. When the diff/merge window emerges, there should not be any elements in RED on the “Synthesis” left pane. If there are, it means the tool has not been able to identify the same model element against the SID. There is the need to manually review the SIDs and update them before attempting a new transition.

The figure below shows assembly A.1 functions (System Function 1 and 2) where captured initially in the assembly A.1, then added to the System A, assigned user manual SID to assembly A.1 and matched with SID to functions represented in System A.

For the third scenario, it is very similar with the scenario described above with the additional step:

• Delete all Sub-System SIDs for all model elements at System Analysis.

Follow steps as described for scenario 2, but now linking to the new parent system. The work to re-create traceability can be quite laborious.

Conclusion:

Bottom-up approach when working with several Capella models is possible, but the work to create traceability links can be quite significant.

In any of the above scenarios it is always preferable to create a lower model from a parent model even if the parent model is not fully developed. In this case, it should be possible to create a simple thread of functionality and interactions that enables transition to a sub-system model.

The post How to build a federated model with Capella for Model-Based Systems Engineering first appeared on Hélder Castro.

The post Initial considerations when capturing textual requirements in a Capella model first appeared on Hélder Castro.

Arcadia matrix in the Capella tool

Capella models can grow fast and become hard to navigate. This short video introduces a new diagram index you can use to simplify access across layers and accelerate your modelling work.

Typical use cases

• Stakeholder Reviews: supports review particularly with non-System Engineers.
• Project Dashboards: Use the matrix as a front page for your Capella project.
• Model Maturity Assessment: It can be added a color-coded or status-tagged cells to track progress.

Perceived value for all Capella model stakeholders

• Improves communication showing what diagrams can be defined and where to locate them immediately.
• Accelerates model reviews by allowing quick navigation to relevant views.
• Facilitates and supports agreement and management of stakeholders’ expectations.
• Simplifies onboarding of new team members unfamiliar with Capella or Arcadia.
• Customizable for any project: Can be adapted to fit specific architecture milestones.

Share how you use Capella diagrams

Please enable JavaScript in your browser to complete this form.

How would you describe your current experience navigating diagrams in Capella? *

• I often spend time searching for the right diagram
• I can usually find diagrams, but it takes a few steps
• Capella diagrams navigation capabilities are great, no issues
• I’m exploring Capella, not using it actively yet

Leave your details and get free a Capella diagrams navigation example (optional)

First

Last

example would navigating

Email

Submit

Thanks for your feedback!

The post Navigate the MBSE Arcadia Matrix in Capella: Complete Diagram Index first appeared on Hélder Castro.

Read more: System Analysis

Transition from Operational Analysis

A Capella transition is the mechanism that enables the tool to create model elements and links (aka traceability) at one layer from another.
Model elements transitions are performed to transition model elements from Operational Analysis to System Analysis. When you transition model elements, Capella creates traceability links from System Analysis to Operational Analysis and can be explored using the Activity Explorer modelling tool. In the Activity Explorer (considering it is open) and:

• Under transition from Operational Analysis:
  • Automated transition of Operational Activities.
• Under define Actors, Missions, and Capabilities:
  • Contextually create new System Actor from Operational Entities / Actors.
  • Contextually create new System Capability or Mission from Operational Capability.
• Operational Process transition

Automated transition of Operational Analysis

To perform an automated transition of Operational Activities, click on “Automated transition of Operational Activities”, as below:

The below functional transition window shows three columns:

The below functional transition window shows three columns:

• Synthesis: this column shows the difference between candidate and resulting model.
• Candidate model: it provides the ability to select what model elements will be part of the resulting model.
• Resulting model: shows a preview of the model when performed the transition.

Click on “Copy all to the right” and then “Ok” to perform the transition and close the window.

Contextually create new System Capability or Mission from Operational Capability

Let’s do the automated transition of Operational Capabilities in context with the Operational Actors from the Activity Explorer. From the Activity Explorer click on “Contextually create new System Capability or Mission from Operational Capability”, as below:

Then select “System Capability”, as below:

From the Capability Transition window, you can see realisation and the transformation links from System Analysis to Operational Analysis:

Click on “Copy all to the right” and then “Ok” to perform the transition and close the window.

A final transition for Operational Process

The Play Imposed Video Operational Process describes the Perform Flight On-Board Announcements Operational Capability. We will perform a “Function Transition” to transition the Operational Process.

To transition, select from the Project Explorer, select Play Imposed Video Operational Process at Operational Analysis, then mouse right-click “Transitions” > “Functional Transition”, as below:

The Operational Process functional transition will create involvement links (aka references) to the System Functions referenced by the System Functional Chain. It will also create a realisation link from System Capability to Operational Capability, as below :

Contextually create new System Actor from Operational Entities / Actors

Finally, we will perform a System Actor from Operational Entities / Actors transition. Click on “Contextually create new System Actor from Operational Entities / Actors”, as below:

From the selection dialog, select the Operational Entity and the two Operational Actors (i.e., Passenger and Cabin Crew), as below:

In the Operational Entity to System Actor Transition window, it creates System Actors, System Actor realisation links, but also transformation links (i.e., Operational Entities and Actors to System Actors) and Allocation links, as below:

Click on “Copy all to the right” and then “Ok” to perform the transition and close the window. When completed the System Analysis should look like below:

System Analysis to Operational Analysis realisation links

The realisation links highlighted in sections above, create and allow traceability between model elements captured at System Analysis and Operational Analysis as captured in the figure below:

Realisation links types:

• A: System Actors realise Operational Entities and Actors.
• C: System Capabilities realise Operational Capabilities.
• F: System Functions realise Operational Activities.
• P: Functional Chain realises Operational Process.

Capture Context System Actors

To define a new Context System Actor diagram, select from the Project Explorer and under Structure “System”, then mouse click “New Diagram / Table…” > “Contextual System Actors”, as below:

For this example, the name remains as default: [CSA] System:

Define Missions and System Capabilities

To create a new Missions and System Capabilities diagram, select from Project Explorer “System”, then mouse right-click “New Diagram / Table…” > “Missions Capabilities Blank”, as below:

Let’s start to insert the transitioned Capability in the diagram. From Palette select “Capabilities”, then click on a blank area of the diagram and “Add selected element(s)”, as below:

To insert transitioned System Actor, select from the Palette “Actors”, then click on a blank area of the diagram, then select “Cabin Crew” and “Add selected element(s)”, as below:

To finish this diagram, create the “Provide Cabin Management Solutions Mission” and the Capability exploitation from the Mission to Perform Flight On-Board Announcements Capability, as below:

Define System Functions Breakdown Structure

To create a new System Function Breakdown Structure diagram, select from Project Explorer “Root System Function”, then mouse right click “New Diagram Table…” > “System Function Breakdown”, as below:

You can change the diagram name, but for this example we will keep the same diagram name as default.

We will now refine the Broadcast Movies function allocated to the Aircraft.

To create a new function, select from the Palette “System Function”, then click on the Broadcast Movies function. It creates a new function and containment link. Rename the new function to Play Audio in Cabin, as below:

Repeat the process above and create two new functions contained by Broadcast Movies, as below:

We can change the colour of the Broadcast Movies function to white. This is a proposed practise and visual reference, only, to help to identify transitioned functions and traceability.

Define Functional Exchanges

Next we will create a System Data Flow Blank diagram for the Perform Flight On-Board Announcements Capability. To create a new System Data Flow Blank diagram, select Perform Flight On-Board Announcements Capability, then mouse right-click “New Diagram / Table…” > “System Data Flow Blank”, as below:

You can keep the same default diagram name: [SDFB] Perform Flight On-Board Announcements. When diagram created select from the Palette “Functions”, then click on a blank area of the diagram. The below Transfer Dialog window will open. Select “Add all elements”:

Organise the functions and change the colour of the Broadcast Movies to white, as below:

Move the ports as below:

• From Broadcast Movies (in) to Store Digital Media.
• From Broadcast Movie (out) to Broadcast Audio Video Stream.

Create the Functional Exchange:

• Audio Stream.
• Audio Signal.
• Audio Video Media.

Rearrange the System Functions and ports. The finished System Data Flow Blank diagram, should be similar as below:

Allocate System Functions to System Components and Actors

Let’s create a System Architecture Blank diagram.

First, rename the model element System. Select “System” from Project Explorer and rename to In-flight Entertainment. To create a new System Architecture Blank diagram, select System, then mouse right-click “New Diagram / Table…” > “System Architecture Blank”, as below:

You can keep the same default name: [SAB] In-flight Entertainment.

To insert System Actors into System Architecture Blank diagram, select from the Palette “Actors” then “Add all elements”, as below:

When Actors inserted to the diagram, rearrange, and resize as below:

Let’s insert allocated System Functions to System and Actors. Start by allocating functions to System. Select from Palette “Allocated Functions” then click on In-flight Entertainment System model element. When you see the Transfer Dialog window, select the three functions and click “Add selected element(s)”, as below:

Repeat the process above for Passenger and Cabin Crew Actor. Rearrange and resize the functions as below:

Let’s reallocate system functions. Select Play Audio in Cabin function and drag from In-flight Entertainment to Aircraft, as below:

Aircraft System Actor allocates the Play Audio in Cabin function, hence, the System Data Flow Blank Diagram and System Functional Breakdown Blank diagram updates. You can visualise the function colour changes from green (functions allocated to the System) to blue (functions allocated to Actors):

We will now create the Components Exchanges between all Actors and the In-flight Entertainment. To create new Component Exchange, select from the Palette “Component Exchange”, then click on “Cabin Crew” and then “In-flight Entertainment”, as below:

Functional Exchanges allocate to Component Exchanges. Component Exchanges implement Functional Exchanges.

To create Port Allocation, select from the Palette “Port Allocation”, then click on Component Port owned by Cabin Crew, then click on Function Port owned by Cabin Crew, as below:

Repeat the process above to create the Component Exchanges and Port Allocations, and rename Component Exchanges as below:

Now that Component Exchanges and Port Allocation is complete, there is the need to make sure all Component Exchanges and Port Allocations directions are consistent. Let’s update both ports directions for Imposed Video Playing Status Component Exchange to IN OUT to reflect consistency with Functional Input and Output ports.

To change Component Port direction double click on one Component Port and when the Properties Window opens change the direction to INOUT, as below:

Repeat the process above for the other Component Port. When changed the Component Port directions the System Architecture Blank should be as below:

Use the diagram filters, as figure below to:

• Collapse Component Ports.
• Hide Component Exchanges.
• Hide Port Allocations.

When filters applied the diagram should look like above [SAB] In-flight Entertainment reallocated function figure.

Describe System Capability with Functional Chains

Functional Chains can be created in either System Architecture Blank or System Data Flow Blank diagram in a similar process to the described for the Operational Analysis is section above.

For this example, we will insert the Functional Chain transitioned from Operational Analysis. To insert the Play Imposed Video Function, select from the Palette “Functional Chain” then click on a blank area of the SDFB diagram. When the transfer dialog shows select the Functional Chain and click “Add selected element(s), as below:

Notice that when inserted the Functional Chain next to its name it is shown as invalid. The reason is the Broadcast Movies System Function was broken down and Function Ports delegated. Hence, new leaf functions are added, but not reflected on the Functional Chain.

To correct the Functional Chain there is the need to create a System Functional Chain Description diagram. To create a System Functional Chain Description diagram, select the Play Imposed Video Functional Chain, then mouse right-click “Functional Chain” > “Create a Functional Chain”, as below:

Keep the same default diagram name: [SFCD] Play Imposed Video.

When created the new Play Imposed Video System Functional Chain Description you can see there is a function with no interactions, as below.

The following updates to the System Functional Chain Description:

• Delete from diagram Broadcast Movies. As a reminder this function was initially defined at Operational Analysis, transitioned to System Analysis, and finally refined in two more functions as described in previous section. In addition, the Arcadia rule that only leaf functions should be allocated. In addition, Broadcast Movies is also part of the Operational Process. As the Operational Process was transitioned and Play Imposed Video Functional Chain was created. Hence, Broadcast video belongs to the Functional Chain, but needs to be deleted and only leaf functions should be reference in the Functional Chain
• Insert the new refined functions captured at System Analysis: Play Audio in Cabin.
• Broadcast Audio Video Stream and Store Digital Media are already part of the Functional Chain as the ports were delegated from Broadcast Movies to each function and as described previously.
• Create Exchange between:
  • Broadcast Audio Video Streams and Play Imposed Movie Functional Chain Involvement Function.
  • Play Audio in Cabin to Watch Movie Functional Chain Involvement Function.
• Create Exchange and Function:
  • From Broadcast Audio Video Streams to Play Audio in Cabin.
  • Store Digital Media and Broadcast Audio Video Streams Functional Chain Involvement Function. There is the need to add this new function as Capella prevents closed loops.

When completed the System Functional Chain Description the diagram should be similar to:

Use the Exchange and Exchange and Function from the Palette to add Functional Exchange involvement Functions and links. Functional Chains updated and inserted in System Data Flow Blank and System Architecture Blank diagrams:

Describe System Capability with Functional and Entity Scenarios

Functional and Entity Scenarios describe System Capabilities. You can create Scenarios in a similar way to Operational Scenarios described in Operational Analysis page.

MBSE Arcadia step-by-step quick guide

This document includes:

• MBSE Arcadia matrix in one slide
• MBSE with Arcadia steps and diagrams with description
• References to the MBSE with Arcadia step-by-step guide online

Download PDF879 Downloads

The post Capella System Analysis practical example first appeared on Hélder Castro.

Let’s get started with the example.

The steps and diagrams will be created in the same order as described in the MBSE with Arcadia method step-by-step for Operational Analysis, and captured again below:

Capture Operational Entities and Actors

As captured in the Operational analysis activities matrix, first needs to be created an Operational Entity Breakdown diagram (OEBD). New diagrams can be created from the Capella Activity Explorer; however, we will use the project explorer to create a new diagram under the package Operational Entities.

To create a new Operational Entity Breakdown diagram, select from the project explorer “Operational Entities”, then mouse right-click “New Diagram / Table…” > “Operational Entity Breakdown”, as below:

When the Operational Entity Breakdown window is open, a new name can be given to the diagram. It was chosen not to change the diagram name, as below:

With the [OEBD] open, select first from the Palette the correspondent model element and then click on the diagram to create the Operational Entity OE 1, Operational Actor OA 2 and OA 3, as below:

 Let’s rename the model elements created. To open the model element Property window, double click on an element, for example Operational Entity (OE 1) and rename to Operational Users, as below:

Repeat step above to rename Operational Actors (OA 2 and OA 3), as below:

Capture Operational Capabilities

The Operational Capabilities diagram will be created next and not renamed.

From Project Explorer, select Operational Capabilities package, then mouse right-click “New Diagram / Table” > “Operational Capabilities Blank”, as below:

Keep the same name as default: [OCB] Operational Capabilities

From the Palette, to show Operational Actor Cabin Crew, select “Operational Actors”, then click on a blank area of the diagram to open the Transfer Dialog, as below:

In the Palette, select “Operational Capability”, and click on a diagram blank area to create the Operational Capability 1.

From the Palette, select “Involvement”, then click on the previously created Operational Capability 1 in the diagram, then click on the “Cabin Crew” Operational Actor to create an involvement link between the two, as below:

Double click on the Operational Capability and rename it to: Perform Flight On-Board Announcements:

The Operational Capability diagram showing the model elements relevant to this view:

Define Operational Activities

This section will describe how to capture Operational Activities with the Operational ActivityBreakdown Diagram.

A new Operational Activity Breakdown Diagram (OABD) can be created from the project explorer and under an Operational Activity. To create an OABD, select “Root Operational Activity”, then click “New Diagram / Table…” > “Operational Activity Breakdown”, as below:

Create Operational Activity Breakdown Diagram

When the “New Operational Activity Breakdown” window opens, rename the diagram to: In-flight Operational Activity:

From the Palette create three Operational Activities in the diagram:

• Broadcast Movies.
• Watch Movie.
• Play Imposed Movie.

Define Operational Activities Interactions

Next step will be to create Operational Activities Interactions Blank (OAIB) diagram, where Operations Activities can be captured. OAIB diagrams can be created under:

• An Operational Activity.
• Operational Capability (OC). When created under the OC model element, activities are related and describe the Operational Capability.

For this example, an OAIB will be created under the Operational Capability that describes it. To create a new OAIB, select Perform Flight On-Board Announcements Operational Capability, then mouse right-click “New Diagram / Table…” > “Operational Activity Interaction Blank”:

Keep the same diagram default name: [OAIB] Perform On-Board Announcements.

When the OAIB diagram is created,  select “Operational Activities” from the Palette and then click on the blank area of the diagram to show the Transfer dialog window. In the Transfer dialog window select all three Operational Activities and then “Add All Elements” to add only the three Operational Activities, then click “Ok” to close window:

Reorganise the Operational Activities and create the first Operational Interaction. To create the Operational Interaction, select in the Palette “Interaction”, then click on the “Play Imposed Movie” then on “Broadcast Movies” Operational Activities, as below:

Repeat the process above and create a new Interaction between Broadcast Movies and Watch Movie.

Next let’s change the Interaction name. To rename the Interaction 1, double click on the “Interaction 1”. When the Properties window opens, rename interaction to Safety Instructions. Repeat the rename process for Interaction 2. When completed the OAIB diagram should be as below:

Allocate Operational Activities

Operational Activities should be allocated to Operational Entities or Actors that are responsible to execute them. For this it will be created an Operational Architecture Blank (OAB) diagram where it will be shown Operational Entities and Actors and allocated Operational Activities.

To create an Operational Architecture Blank diagram, select “Operational Entities” in the Project Explorer, then mouse right-click “New Diagram / Table…” > “Operational Architecture Blank”, as below:

When the New Operational Architecture Blank window shows, leave the name as default: [OAB] Operational Entities and click “Ok”.

Let’s insert Operational Entities and Actors to the diagram. To insert Operational Entities to the OAB diagram, select in the Palette “Operational Entities”, then click on a blank area of the OAB diagram, then “Add all Elements” > “Ok”, as bellow:

To insert Operational Actors, click on the arrow next to Operational Entities to show Operational Actors in the Palette. In the transfer dialogue click on “Add all elements” > “Ok”:

When Operational Entities and Actors are inserted into the Operational Architecture Blank diagram, it should be shown as below:

To allocate Operational Activities to Operational Actors select “Manage Activity Allocation” then click on the Passenger Operational Actor shown in the diagram, as below:

When the transfer dialogue opens, select “Play Imposed Movie”, then “Add selected element(s)” > ”Ok”:

Repeat the process above to Manage Activity Allocation for Passenger and Aircraft as below:

Interactions are also added to the diagram as they were previously defined in the OAIB diagram in the previous step. The OAB diagram can be a good diagram candidate to not only Manage Activity Allocation, but also define new Interactions now in context with structure (i.e., Operational Entities and Actors) and behaviour (i.e., Operational Activity).

Describe Operational Capabilities with Operational Process

Perform Flight On-Board Announcements Operational Capability was previously described by the relevant Operational Activities captured in the OAIB diagram under the Operational Capability. Operational Capabilities can also be described with Operational Process. Operational Process references what Operational Activities and Interactions are considered relevant to describe an Operational Capability, but also to show in diagrams the flow of Activities and Interactions.

An Operational Process could be created from this diagram; however, it will be created from the OAIB diagram instead. As the OAIB diagram is defined under the Operational Capability, any Operational Process created will also be created under the same Operational Capability promoting consistency.

To create an Operational Process, Hold Ctrl, then select all three Operational Activities and the two Interactions, then mouse right-click on a model element (e.g., Watch Movie) > “Operational Process” > “Create an Operational Process”, as below:

Rename the new Operational Process to Play Imposed Video as below:

The Play Imposed Video Operational Process defined in the Operational Architecture Interaction Blank diagram should look as below:

To create an Operational Process Description (OPD), select “Perform Imposed Video” Operational Process from the Project Explorer, then mouse right-click “New Diagram / Table…” > “Operational Process Description”, as below:

When the New Operational Process Description window shows, do not rename the diagram and confirm the default name provided as [OPD] Play Imposed Video and click “Ok”.

The below Operational Process Diagram is automatically created showing the three Operational Activities referenced by the Operational Process:

An Operational Process can also be shown in the Operational Architecture Blank diagram. Inserting an Operational Process in a diagram not only shows the flow of Operational Activities and Interactions, but also what Operational Entities and Actors are involved in a diagram. If more Operational Processes were defined a combination of insert/remove can be performed to help the analysis process.

To insert an Operational Process in the Operational Architecture Blank diagram, in the Palette select “Operational Process”, then click on a blank area of the diagram. The Transfer dialogue window will be shown, then click “Add selected elements(s)” > “Ok”, as below:

When inserted the Operational Process into the Operational Architecture Blank diagram it should be seen as below:

Describe Operational Capabilities with Operational Activity and Entity Scenarios

Operational Capabilities can be described by Operational Process that describes and involves Operational Activities and Interactions above but can also be described by Operational Activity and Entity Scenarios.

To create new Operational Activity Scenarios, select from the Project Explorer the “Perform Flight On-Board Announcements” Operational Capability, then mouse right-click “New Diagram / Table…” > “Activity Scenario”, as below:

When the New Activity Scenario is shown, keep the default name and click “Ok”.

It is created a new Operational Activity Scenario diagram under the Operational Capability, as below:

To add Operational Activities to the diagram, select Activities in the Palette, then when the Transfer Dialogue window opens select the three Operational Activities, then click “Add selected element(s)” > “Ok”. By selecting the three Operational Activities will not add the Root Operational Activity to the diagram.

Resize Operational Activities to show full name in diagram and reorder them. Operational Activity Scenario should be as below:

To add Interaction to the Operational Activity Scenario, select “Interaction” from the Palette, then click first on the Play Imposed Movie Operational Activity’ lifeline and then on the Broadcast Movies Operational Activity lifeline, as below:

When the Selection Dialog window opens, select “Safety Instructions [Play Imposed Movie -> Broadcast Movies]”, then “Ok”:

Repeat the process above for the other Interaction between Broadcast Movies and Watch Movie and add “Imposed Movies [Broadcast -> Watch Movie]”.

When completed the Operational Activity should be like as below:

An Operational Entity Scenario can also be chosen to describe an Operational Capability.

To create an Operational Entity Scenario, the steps are like above described for Operational Activity Scenario. Select Perform Flight On-Board Announcements Operational Capability from Project Explorer, then mouse right-click “New Diagram / Table…” > “Entity Scenario”, as below:

Keep the same diagram default name: [OES] Perform On-Board Announcements.

Select “Operational Entities / Actors” and “Interaction” from the Palette. When completed the diagram should be as below:

The above steps allow to create new Operational Activities and Entity Scenarios under an Operational Capability.

As the Play Imposed Video Operational Process is created, Capella does provide the capability to transition and initialise Operational Activities and Entity Scenarios, to represent time-ordered scenarios.

To create a new Operational Activity Scenario from an Operational Process, open the Operational Architecture Blank diagram, then mouse right-click on the “Play Imposed Video” Operational Process, then “Transitions” > “Operational Process to Operational Activity Scenario Initialization”, as below:

Transitions can also be done by selecting the “Play Imposed Video” Operational Process from the Project Explorer and then follow the same steps as described above.

Capella creates a new Play Imposed Video 3 Operational Activity Scenario under the Perform Flight On-Board Announcements Operational Capability, as below:

The number 3 in the name represents the third scenario created under the Operational Scenario. 

Now let’s create the Operational Activity Scenario to show model elements in a diagram.

To create Operational Activity Scenario, select Play Imposed Video 3 Operational Activity, then click “New Diagram / Table…” > “Activity Scenario”, as below:

The new Operational Activity Scenario created may need to be rearranged to show the same as the All Interaction inserted in Operational Activity Scenario described above.

To create a transition for the Operational Entity Scenario, select “Play Imposed Video 3” Operational Activity from the Project Explorer, then click “Transitions” > “Operational Activity Scenario to Operational Entity Scenario Initialization”, as below:

An Operational Entity Scenario can be created similarly to described for Operational Activity Scenario above, select “Play Imposed Video 3 (OES) in the Project Explorer, then mouse right-click “New Diagram / Table…” > “Entity Scenario”, as below:

When the New Entity Scenario window is shown, keep the same diagram as proposed: [OES] [OAS] Play Imposed Video 3 (OES).

A new diagram is created and visible in the Project Explorer: [OES] [OAS] Play Imposed Video 3 (OES) and the new Operational Entity Scenario diagram is open. The diagram model elements and display should be similar to the Operational Entity Scenario described above.

There is freedom in Capella to create the diagrams in any sequence.

Despite elements in Scenarios represent only references to model element, this means Scenarios are not synched with the model evolution, hence, consistency and completeness needs to be checked. Links created during the transition helps to verify consistency, correctness, and completeness of diagrams in a model.

For this simple example, Operational Activity and Entity Scenarios diagrams do share the same model elements and Operational Capability description. The reason was to describe the option to create Scenarios from an Operational Process using the Capella Transition capability.

Hence, the below will be performed in the model:

• Delete the Perform On-Board Announcements Operational Activity Scenario.
• Delete the Perform Flight On-Board Announcements Operational Entity Scenario.
• Rename both Scenario and diagram for Play Imposed Video 3 Operational Activity Scenario to Play Imposed Video.
• Rename Play both Scenario and diagram for Imposed Video 3 (OES) Operational Entity Scenario to Play Imposed Video. It could be left (OES) to visualise the Scenario was transitioned.

The Operational Analysis project explorer at this point should look as below:

Operational Analysis traceability flow

When completed the model for Operational Analysis Project Explorer should look like as below:

As described in sections above, the Capella tool implements the Arcadia method, and the Arcadia method owns an ontology. Arcadia ontology defines model elements and the relationship among them enabling inherent traceability. Hence, it is possible in Capella to query and navigate from one model element to another.

For this example and only for the Operational Analysis (similar analysis can be done for all the other layers), it will be described as an example of how model elements are related via their relationship and navigate from one to another model element using a combination of Project Explorer and the Semantic Browser.

Starting with the Project Explorer. The steps for the model elements navigation are captured in the figure above (yellow) and again below:

• (start) Perform Flight-Onboard Announcements Operational Capability.
• Play Imposed Video Operational Process.
• Watch Movie Operational Activity.
• (end) Passenger Operational Entity.

In the Project Explorer select the Perform Flight On-Board Announcements Operational Capability. The Operational Capability will be shown in the Semantic Browser under the current element area. Under the Referenced Elements area it can be seen the Play Imposed Video Operational Process. Select and press F8. This Capella command will navigate back Project Explorer and to the Play Imposed Video Operational Process model element.

To navigate from Play Imposed Operational Process to Watch Movie Operational Activity, select first the “Play Imposed Video” Operational Process in the Project Explorer then in the Semantic Browser, select “Watch Movie” Operational Activity and press F8 to navigate to model element as below:

Finally, let’s navigate from Watch Movie Operational Activity to Passenger Operational Actor.

Select “Watch Video” Operational Activity from the Project Explorer, then under Referencing Elements select “Passenger” and click F8 to navigate to model element in Project Explorer, as below:

Capella creates links between model elements that are going to be explored hereafter. 

By default, let’s make sure links will be visible. Click on “View Menu” > “Filters and Customisation”, as below:

When the Filters and Customisation window opens locate the following filters:

• Functional Chains involvements
• Trace

Let’s make sure the filters are not set. An example for Trace filter bellow:

Figure below, shows relevant links that allow the same navigation between model elements as described above using the semantic browser and the relationship between model elements. Links are captured and can be seen in the Project Explorer highlighted in blue in figure above.

When completed the analysis above, let’s set the filters

Set Default Filters. Click on “View Menu” > then “Set Default Filters”.

MBSE Arcadia step-by-step quick guide

This document includes:

• MBSE Arcadia matrix in one slide
• MBSE with Arcadia steps and diagrams with description
• References to the MBSE with Arcadia step-by-step guide online

Download PDF879 Downloads

The post Capella Operational Analysis practical example first appeared on Hélder Castro.