FilesFormat

File formats

.capella/.aird/.afm file formats

Capella use XML/XMI to store the .capella, .afm and .aird files.

The elements are stored as an XML tree as you see it in the Project Explorer. So it is easy to browse deep in the elements directly by parsing the XML.

<org.polarsys.capella.core.fa:Project>
  <ownedModelRoots xsi:type="SystemEngineering">
    <ownedArchitecture xsi:type="OperationalAnaysis">
      ...
    <ownedArchitecture xsi:type="SystelAnalysis">
      ...
    <ownedArchitecture xsi:type="LogicalArchitecture">
      ... 

The references between elements are commonly stored by referencing the id of the element.

<ownedFunctions xsi:type="xxx:SystemFunction" id="SF1" ...>
  <ownedInputs xsi:type="xxx:FunctionInputPort" id="FOP1" ...>
<ownedFunctions xsi:type="xxx:SystemFunction" id="SF2" ...>
  <ownedInputs xsi:type="xxx:FunctionInputPort" id="FIP1" ...>
<ownedFunctionalExchanges xsi:type="xxx:FunctionalExchange" source="#FIP1" target="#FIP1".../>

When a reference is multiple, the ids are referenced with a space.

<ownedFunctionalExchanges xsi:type="xxx:FunctionalExchange" exchangeItems="#EI1 #EI2" .../>

If the referenced element is located in another resource, the id will be prefixed by the path to the resource.

<ownedFunctionalExchanges xsi:type="xxx:FunctionalExchange" exchangeItems="#EI1 ../library/library.capella#EI2" .../>

The XML format uses many namespaces. Root element tag and types are prefixed by the xmlns, By default (without specific addons), there is no conflict between elements, so if you parse it, it can be good to remove namespaces as it will complicates the code without much added values.

<org.polarsys.capella.core.fa:Project>
 <ownedFunctionalExchanges xsi:type="org.polarsys.capella.core.fa:FunctionalExchange" exchangeItems="#EI1 ../library/library.capella#EI2" .../>
</...>

.capella

Elements are stored as a Tree, the same than the Project Explorer (with all elements unfiltered)

The references between elements are commonly stored using three ways:

• The direct reference is stored in the XML as an attribute of the element. (a FunctionalExchange refers to ExchangeItems with a reference conveyedExchangeItems

• The traceable reference is stored in the XML (and in Capella) as an additional element between both elements in which you can add additional properties. (for instance, the detailled reason why a Function is allocated to a Component). In Capella, those elements are hidden by default but it's possible to reveal them.

• The derived reference is a computed reference that is not serialized in the XML but computed 'in the fly' by Capella. These references are often used to have direct access to the elements when a traceable artifact exists to describe a relationship. (for instance, a Function is allocated to a Component by an ComponentFunctionalAllocation element. In the function, there is a derived reference allocatingComponent, and in the Component, another one, allocatedFunctions )

• The semantical reference is a reference that is not serialized in the XML but computed 'in the fly' and visible in the Semantic Browser. (for instance, in the System Function, there will be a Allocating System Component to improve the readability of the reference)

The derived references are not serialized in the .capella, nor semantical references. But as the format is XML, you can easily use XPath to write quicker queries (or JSON queries as XML can be easily transformed to JSON) and those 'derived or semantics' references will not be probably useful.

On the Capella concept pages, the derived references are displayed on italic and contains a tooltip description explaining how they are computed if needed. The semantical references are defined using Java and can be retrieved here

flowchart TB
Function:::fct
SystemFunction:::fct
Component:::cpt
SystemComponent:::cpt
ComponentFunctionalAllocation:::tech

SystemFunction -.->|inherits| Function
SystemComponent -.->|inherits| Component
SystemFunction -->|allocatingSystemComponent| SystemComponent
SystemComponent -->|allocatedSystemFunctions| SystemFunction

Function -->|allocatingComponent| Component
Component -->|allocatedFunctions| Function
ComponentFunctionalAllocation -->|sourceElement| Component
ComponentFunctionalAllocation -->|targetElement| Function

Function -->|incomingTraces| ComponentFunctionalAllocation
Component -->|outgoingTraces| ComponentFunctionalAllocation

classDef fct fill:#EBFFD5;
classDef cpt fill:#BEE1FB;
classDef tech fill:#EEE;

Loading

To detect if a Function is allocated to a Component, it is XML/Json-easy to detect if there is a ComponentFunctionalAllocation between both. or to recreate some of the direct references if they are really needed for a given script.

.aird

The aird stores the diagrams and tables.

On the first part of the aird, you will find the "Representation Descriptors" which contains the name, the description and other non-graphical attributes (Elements of Interests, Contextual elements, ..)

<DAnalysis>
  <ownedViews xsi:type="DView" viewpoint="oa">
    <ownedRepresentationDescriptor xsi:type="DRepresentationDescriptor" uid="diagram1" description="LDFB" .../>
</DAnalysis>

The second part of the aird will be the graphical storage of the diagrams and tables.

...
<xmi>
  <ownedRepresentation xsi:type="DDiagram" description="LDFB">
    <coordinates and visible states of all elements/>
    <graphical representations, color, shape, etc/>
  </ownedRepresentation>
  ...
</xmi>

.afm

This file contains the capella and the viewpoints versions used for the current model. This can be useful, or not.