Data modelling

Contents:

An important part of system engineering involves ensuring consistency, correctness and completeness between the data managed in the system and the data exchanged with external actors, and components.

In order to, unambiguously describe these exchanges, the data, information, matter flow, etc., must be formalized. 

An important engineering task involves avoiding multiple definitions for a single piece of data in different areas of the system. Hence, the need to declare that several exchanges should carry the same type of data, without having to redefine the shared data for each exchange. 

An Arcadia Rule: It must be noted that the data modelling is transverse to all levels of Arcadia. In particular, a Type defined at the System Analysis level can be used at all of the lower levels, down to the Physical Architecture level. It is therefore not necessary to carry out a “transition” of the definitions of Types, as it is done for Functions or Actors, for example. 

The opposite is not true: a Type defined at a given Arcadia level, cannot be used at higher levels.

Exchange data concepts and relationship

This section will introduce an ontology view of Arcadia related data modelling concepts and relationships.

The below figure shows a view of the different concepts and relationships involved for the exchange data in Arcadia. 

From the below figure it can be read that: 

  • A System or External System is built from 1 or more Hosting Physical Component. 
  • A Behavioural Component implements 1 or more Functions. 
  • A Behavioural Component owns 1 or more Behavioural Port. 
  • A Function Receives or Delivers through Function Port. 
  • A Function Port Produces or Consumes 1 or more Exchange Item. 
  • An Exchange Item Groups 1 or more Exchange Item Element. 
  • An Exchange Item Class references one Class. 
  • A Class groups 1 or more Properties. 
  • A Behavioural Exchange implements 1 and only one Functional Exchange. 
  • A Behavioural Exchange transports 1 or more Exchange Item. 
  • A Behavioural Exchange Links 2 Behavioural Port. 
  • An Operational Interaction carries 1 or more Exchange Items. 
  • A Behavioural Port Provides or Requires 1 or more Interfaces. 
  • An Interface groups 1 or more Exchange Item. 
  • A Functional Path implements 1 or more Functional Exchange. 
  • A Functional Path Groups 1 or more Behavioural Exchange. 
  • A Physical Path transports a Behavioural Exchange. 
  • A Physical Path Groups a Physical Link. 
  • A Physical Link links 2 Physical Ports. 
  • A Hosting Physical Component owns 1 or more Physical Port. 

Data modelling example at captured at Physical Architecture, allocated to Functional Exchanges and exposed in an Interface diagram:

Capella tips:

Capella does provide the powerful capability to :

  • Transition and propagate Exchange items to Function Port.
  • Calculate and create Interfaces of a structural element from its Function allocation.

Functions, behavioural and physical implementation

As an Arcadia rule a leaf function must be allocated to one and only one behavioural component (i.e., system, actor or logical), which is responsible for instantiating it and performing it, that is implementing the leaf function. 

Some good practises rules should be followed to ensure consistency, as follows:

  • Allocate function ports to behavioural ports: any functional port used by a component that performs the function associated with this port, should be allocated to one and only one of this component’s behavioural ports as soon as a functional exchange with the component exterior is connected to this port. That means, function ports, should be all allocated to behavioural ports.
  • Functional exchange implemented by behavioural exchanges: a functional exchange between two functions allocated to two behavioural components should be implemented by one and only one behavioural exchange between these two components. The behavioural exchange references all the functional exchanges it implements. When functional exchanges are allocated to behavioural exchanges, the Capella modelling tool automatically populates the “Allocated Functional Exchanges”.
  • Allocate Exchange Item(s) to functional exchanges (if defined previously in class diagram [CDB]).
  • Propagate Exchange Items to function Ports: Capella does provide a Modelling Accelerator to propagate the Exchange Item of a Functional Exchange toward each of the Function Ports. 

Generally, a behavioural exchange represents a synthesis of several functional exchanges it implements and groups.

In other words, it is recommended allocating Exchange Items to each Function Port in order to define the content that the Function could produce or could need. At least one Exchange Item should be allocated to each Function Port. This Exchange Item could be shared between several Ports, and actually should be shared by the two Ports at the extremities of a Functional Exchange for consistency and correctness of the model. A Function Port has several Exchange Items, hence, it should be specified on each Functional Exchange connected to it, which are the elements that are actually conveyed, which must be coherent with those of the Ports connected by the Exchange.

The figure below shows the function elements to behavioural elements relationship:

Functional and physical path

A functional path is an ordered set of references to behavioural exchanges and delegation links between behavioural ports, defining a continuous path likely to implement one or more functional exchanges between two functions allocated to the path source and destination components. 

A functional path references the functional exchanges and delegation links it implements. 

A physical path is an ordered set of references to physical links, defining a continuous path likely to route one or more behavioural exchanges between components not linked by a single physical link. 

A physical path references the behavioural exchanges it transports. 

The below figure shows a functional path for two functions implemented by different components. It is also represented the physical path that enables the functional path transport. 

Figure below shows Physical and Function path:

Interfaces

In principle, the content of a behavioural exchange is already defined by the exchange items transported by the functional exchanges that it implements, as described in the previous section. 

However, it can be useful to specify this content explicitly, for example when there is the need to verify all the flows for all behavioural ports are consistent, and what is produced and consumed. 

The following rules may be followed if there is the modelling effort to promote consistency:

  • One interface at least should be allocated to each behavioural port in a component to characterize the exchange items that the component can produce or which it needs (i.e., required).
  • Function and interface exchange items should be the same. All the exchange items captured in the functional ports of the functions performed by a component should be referenced by one of the interfaces referenced by the behavioural port that implements these functional ports. It should be the same exchange item carried by the functional and behavioural exchanges.

In other words, an interaction role describes the operating instructions of an Interface for a Component by qualifying the allocation of the Interface to a Component Port of the Component. A role is therefore given to a Port and an Interface. In the largely majoritarian case of dependency from the data (matter, flow, messages, events, shared data, etc.), only two roles are defined: the role (implements/provides) of the provider and the role (uses/requires) of the consumer.”
In other words, an interface should be allocated to a component port (i.e., behavioural port), that shows the component port role: provide or require AND Exchange Items contained.

Ensuring model exchanges consistency

If a functional exchange carries an exchange item, then it should be coherent with those allocated to the functional ports connected to it. 

If a behavioural exchange carries an exchange item, then this should be coherent with those present in the interfaces associated with the ports connected to it. 

As mentioned before, Exchange Item may specify data, mass, events; a Capella model library can be created that contains data model that can (and should) be reused in different models to ensure consistency. 

The figure below captures the different relationships explained before:

  • Classes are defined in a Data model and contain properties. 
  • Exchanges Items are communication elements and may contain more than one to class. 
  • Exchange Items should be the same communication elements associated to a functional exchange and function ports. 
  • Exchange Items can be allocated to Interfaces and transported from one component to another.
  • Interfaces exposes a component role: provide or require.

Exchange item

Exchange items are considered communication elements.

An Exchange Item defines a communication media and a set of data semantically coherent with regards to their use in a given context used as a whole for functional exchanges:

  • Same communication principles.
  • Simultaneity of transportation.
  • Same non-functional properties (e.g., security level, integrity requirement, expected performance, etc.).
  • Indivisibility (an exchange item is atomic).
  • Referring to kinds of data described in the data model.

Exchange Items help in:

  • Structuring ports/exchanges in order to organize exchanged data.
  • Avoiding defining several times the same set of data when used in several ports/exchanges.
  • Imposing a unification of interactions or exchanges of the same kind everywhere in the system (e.g., standard for messaging, protocols, etc.).
  • Constituting a checkable contract in exchanges with outside the system.
  • Carrying a requested communication principle if necessary (e.g., event, dataflow, message, service, shared data, continuous flow).

Conclusion

Arcadia language underpinned by the ontology defined, is the “heart” to ensure consistency, correctness and completeness (CCC) of the data modelled and managed in a system under design.

As mentioned in the article above, the Capella tool implements features to accelerate the modelling activities, but also several modelling validation rules and the ability to create data libraries; all this capabilities can be considered of great value during a Model-Based System Engineering design process to ensure the CCC.