Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

2. Modelling Rules for System Analysis

2.1. Overall

IDRule
SA-001

In order to ensure consistency within the project, British English is to be used at all times.

Refer to the Cambridge Dictionary for further information.

SA-002

Images and/or diagrams that are to be used in the descriptions of Capella model elements shall be created and maintained on the following Confluence page:

Images for Capella model element descriptions

SA-003

Description Links for model elements shall be used in all model element descriptions.

E.g. if a certain description refers to a defined model element, the name of the model element being referred to shall be copied (as a Description Link) and pasted (as a Link) in the corresponding description field.

Exception: model elements defined as abstract concepts or terms, which serve solely as a form of documenting information external to the project, shall be excluded from this rule.

2.2. Elements

2.2.1. System Capability 

RCAMT-396 - Getting issue details... STATUS

SC-106

Naming convention:

Sentence case - the first letter of the first word in a sentence is capitalised.

The name of a system capability should begin with an active verb.

The verb should be specific enough to identify what the actor wants from the system. Verbs such as "manage", "handle" or "process" are not specific enough and are forbidden.

The usage of abbreviations should be well considered and should only be used in cases where the abbreviation is standardised.

In addition, the system capability name gets a prefix:

<Capability unique number>.<Number in case of generalisation link>: <System capability's name>

  • Each capability has a number to be identified. This unique number is defined by creation of the capability (began by 01);
  • If some capabilities have a generalisation link, we can add a specific number to report this.

Note: capabilities can be grouped by a mission in the model if needed

Examples:

01: Set point for train unit movement
02: Authorise train unit movement
03.1: Prepare departure of passenger train unit
03.2: Prepare departure of fright train unit
SC-103

All identified system capabilities have a valid set of metadata comprising:

a statement of the primary actor's goal in the capability, to be written in the description field

template:

The [SystemActorname] requires the system to [mandatory description of the operation on the primary object] [optional description of the influence of the secondary object] and [optional description of the involvement of the secondary actors to enable the operation on the primary object].

Note: Primary object and secondary objects of a capability shall be determined as the object on which a service of the system is performed upon and the secondary object is an object that is involved in the provision of the service upon the primary object, respectively. 

and

at least one pre-condition entered into the correct field in Capella

and

at least one post-condition entered into the correct field in Capella

WHERE the capability has multiple pre and/or post-conditions, each condition shall be included in its own line in the correct field in Capella and joined to the other conditions with an AND statement, e.g.:

<Entity> is <state>

AND

<Entity> is <state>

WHERE the capability has multiple possible post-conditions (a main success condition and one or more failure/diminished success conditions) THEN each separate post-condition should be included in an inclusive OR statement WITH the main success condition being the first listed condition.

i.e. Post-condition = <main success condition> OR <second success condition> OR <failure condition>

Ideally, start and end conditions should have the following format:

<entity> is <state>

where entity could be any actor or a data concept and state is one of the defined states that the entity is allowed to occupy.

Guidance:

  • System Capabilities are to be written from an actor's perspective, similar to use cases. Although the ARCADIA method describes system capabilities from the system perspective, we have decided that a deviation from the established method is preferred for our purposes.
  • Although the <entity> is <state> format is ideal, there may be some start and end conditions that do not conform to it due to the fact that the desired condition of the entity cannot be expressed in terms of states (e.g. The current point_position_estimation is indicated to Railway Operator). 
  • Detailed guidance and explanations can be found in ARCH.M.040 Method for definition of capabilities.
SC-104Each capability has an involvement relationship to at least one actor, except where a capability is included by other capabilities (in which case, a direct involvement with an actor is not necessary, but is allowed) or when a capability is sub typed (in that case, it inherits the actor from the super-type capability)
SC-105The set of relationships between capabilities is logically consistent and allows for no unintended overlaps between the scopes of different system capabilities.
SC-107

At the post-condition of each system capability, a measurable or observable result has been delivered to at least one actor in the wider system of interest (that is, the user story has been achieved).

If a candidate capability has valid behaviour but yields nothing to any actor, it is more likely to be a function.

In other words, capabilities are "stories" where functions are just "chapters".

2.2.2. System Mission 

IDRule
SMN-001

Naming convention:

Sentence case - the first letter of the first word in a sentence is capitalised.

The name of a system mission should begin with an active verb.

The verb should be specific enough to identify what the high-level goal for the system is.

The usage of abbreviations should be well considered and should only be used in cases where the abbreviation is standardised.

In addition, the system mission name gets a prefix:

<Mission unique number>: <Mission name>

  • Each mission has a number to be identified. This unique number is defined creation of the mission (began by 101);
SMN-010Each mission has a meaningful description that includes a rational why it is a mission for the system.

2.2.3. System Actor

IDRule

SA-040

Naming convention:

  • Title Case - the first letter of each word is capitalised, words separated by space.
  • Names should be singular
SA-020

The description of a system actor focuses on the features that define them, not on its responsibilities or functions.

Guidance: a brief summary of responsibilities/behaviour is allowed but this should not read like a list of functions (because this information should be defined only through the allocation of functions to this actor, not duplicated in a text description)

SA-030Where an abstract concept is mentioned in the description of an system actor, this is done using a hyperlink to the abstract concept, rather than plain text.
SA-010

System actor name and description is consistent with harmonised definitions from collaboration projects (RCA, S2R, OCORA etc.) or with international standards where applicable.

SA-050

Where a system actor is a system-level realisation of an operational entity or actor AND the system actor is NOT defined by a collaboration project (see SA-010):

There exists a realisation relationship to the corresponding operational entity/actor

AND

The description of the system actor is identical to the description of the corresponding operational entity/actor

OR

The description of the system actor is aligned with the description of the corresponding operational entity/actor but is adjusted to make it appropriate for system-level

Guidance: the name of the system actor does not need to be identical to that of the operational entity/actor, but this is permitted, if it makes sense.

SA-060Generalisation between system actors is not permitted.

2.2.4. System Function

2.2.4.1. Guidance 

Detailed guidance and explanations can be found in ARCH.M.010 Method for definition of functionality.

2.2.4.2. General Rules

IDRule
SF-010

Naming convention:

All function names are written using sentence case capitalisation. The first word in the name of the function will begin with a capital letter and the remaining words will be lower case.

SF-020

The usage of abbreviations in both the names and descriptions of logical functions is only permitted in the case of standardised abbreviations (e.g. ETCS, PRM, GoA), not for terms that have been defined within the scope of the project (e.g. TU in place of Train Unit).

SF-030

Function Description - describe what the function is for, such that the following boxes can be ticked:

  • The description explains what the function will produce (output)
  • (optional) The description explains why the inputs are required
  • (optional) The description explains how the inputs may be used to produce the outputs

Pattern: This function <verb> ....

Note: see also rule SRA-040

2.2.4.3. Function Allocated to System

SFS-010

Naming convention:

All function names have the form verb-noun, where the noun is the object upon which the function operates.

The noun or noun expression in the function's name is consistent with the output of the function.

SFS-020For system functions, the multiplicities shown in the ontology in Method for definition of functions must be complied with.
SFS-030

Control system principle

Each core system function should be named and described in such a way that it conforms to one of the categories of control system function. A "core" system function is a function that is active when the system is in the OPERATIONAL state (or equivalent).

All functions are members of one and only one of the following categories:

  • Control
  • Actuate
  • Indicate/Display
  • Sense
  • Observe

The main five ontology elements (control, actuate, indicate/display, sense and observe), are to be used for naming system functions.
If neither the main functions nor their specialisations fit to the function being created, it is possible to use other verbs.
In such a case, the usage of a previously undefined verb must be justified and coordinated with the parties responsible for the modelling rules.

SFS-040

Configuration data

When a Control, Observe and Indicate function needs to consume continuously-supplied configuration data, a function named "Maintain <kind of configuration data>", delivers this configuration data. (e.g. Maintain map data, Maintain record of registered vehicles).

There should only be one "maintain" function for each distinct type of configuration data at system level.

SFS-050

All functions at system level have at least one functional exchange that crosses the system boundary.

Rationale: ARCADIA system needs analysis is intended only to identify the needs of external stakeholders on the system, not to create a model of how the system works internally. The logical level of ARCADIA is the appropriate level to begin modelling and presenting the partitioning of the functions into a solution architecture. By clustering functionality around the external interfaces of the system, the functions remain focused on needs of stakeholders (handling inputs/producing outputs). This approach is also aligned with the EULYNX ModStan approach of clustering behaviour around the ports of a system, with linking behaviour in between.

exception: 

  1. A "control" or "observe" function may have only internal functional exchanges if at least one functional exchange feeds to an "indicate" function. (Rationale: the states produced by the "control" or "observe" function are needed outside the system and reach the actor via the "indicate" function, so there is an external need for the information produced).
  2. A "observe" function may have only internal functional exchanges if at least one incoming functional exchange comes from "sense" function that is allocated to the system.

2.2.4.4. Function Allocated to Actor

IDRule
SFA-010

Naming convention:

Actor function names have the form verb-noun

Exception: functions of type "plant" may deviate from this rule if it makes the name clearer, for example "train unit mechanical behaviour" could be used to represent the mechanics of a physical train unit's motion.

SFA-020Actor functions are permitted to merge multiple items from the control system pattern, where used; in this case, the name of the actor function may contain several verbs (e.g. Sense+observe or Control+actuate)
SFA-030Actor functions are defined wherever some behaviour is expected from an actor in order to reach the end conditions of a system capability
SFA-040Actor functions must be described in a way that show the responsibilities of the actor in a clear manner.
SFA-050

Configuration and calibration data

When an actor provides new orginal configuration data to the system, an actor function named "Provide <kind of configuration data>", provides this configuration data to a "Maintain <kind of configuration data>" function. (e.g. Provide model of railway topology, Provide record of registered vehicles).

When an actor wants to activate a new configuration of the system, an actor function named "Control <kind of configuration data>", produces the required state of configuration data for each "Maintain <kind of configuration data>" function.

SFA-060When an actuation or sensing function needs to be calibrated according to calibration data supplied, an actor function named "Provide <kind of calibration data>", delivers this calibration data. (e.g. Provide wheel diameter).

2.2.4.5. Interfacing Function

Detailed guidance and explanations can be found in ARCH.M.030 Method for definition of interfaces.Method for definition of system interfaces

IDRule
SFI-010

Naming convention:

  • Interfacing function name should begin with an active verb: e.g. transmit
  • The usage of abbreviations should be well considered and should only be used in cases where the abbreviation is standardised.
  • In addition, interfacing function name gets a suffix:

                                   <Interfacing Function’s name> (<Interface number information>)

          • Each interfacing function has a number to be identified in case of multiple interfaces with the same entities.
          • This number is defined by the creation of the interfacing function pair (see. SFI-030) and began by 01.
          • This number is identical for each interfacing function of a same pair (see. SFI-030)

Then, the template of the interfacing function name at system level must be:

<Active verb> between <allocating entity> and <entity communicating through this interface> (<Interface number information>)

Examples:

Transmit between System X and Planning System (01)
Transmit between System X and Physical Train Unit (02)
SFI-020

Interfacing principle

An "interfacing" function is a function that is active when the system and an actor need to exchange with a specific constrained interface between each other.

SFI-030Interfacing functions are always created per pair: one allocated to the system, one allocated to an actor.
SFI-040

All interfacing functions at system level have at least one functional exchange that crosses the system/actor boundary.

2.2.5. System Functional Exchange

SFE-120

Naming convention:

Sentence case - the first letter of the first word in a sentence is capitalised.

Note: The name of the functional exchange is not the definition of the interaction (for the definition refer to SFE-140) and will be filtered in diagrams. The name may be freely chosen and should give guidance to the modellers about what is expressed by it.

Strong recommendation:

Functional exchanges between functions conforming to the pattern could be named using the structure <exchange type> of <state> e.g. Estimated internal state of point position or similar (Estimated position state of point) etc.

------------------------------

Exception for functional exchange between interfacing function:

    • The Source and Target entities' names should be written in PascalCase - All words are capitalized and run together. First letter is capitalized.
    • If there is more than one functional exchange for one interface (interface layer) each functional exchange should have the layer information: _<LayerName> (But please do not include the word "layer" in the layer name)
    • If there is more than one interface between entities, each functional exchange should end with the interface number information (see. SFI-010): _< interface number information>

Template for Functional Exchange name: <SourceEntity>_<TargetEntity>_<LayerName>_< interface number information>

Example: SystemX_PlanningSystem_Application_01

SFE-010

There should only be one functional exchange per direction between two functions

*Warning: multiple functional exchanges between the same pair of functions may imply that the functions have not been decomposed to a primitive level - check before allowing multiple functional exchanges.

Note: Each functional exchange will automatically be assigned a unique ID upon creation.

---------------------------------------------

Exception for functional exchange between interfacing function:

For one interfacing function, there should only be one functional exchange per interface layer (and per direction). See Method for definition of system interfaces to have guidance for this rule

SFE-140

Each functional exchange shall have at least one exchange item allocated to it. These exchange items define the functional exchange.

Exception: Actor function to actor function do not need necessarily exchange items.

SFE-150

For all exchanges between core system functions (functions that use the control pattern), the following exchange types are permitted; no other exchanges are permitted.

  1. Abstract required state (non-reflexive)(WHERE an abstract required state is used as a parameter to another function) 
    • Produced by function type: Control OR External input to system
    • Consumed by function type: Control (different type) or Indicate.

    Example (classical route signalling):

    SourceExchangeSink
    control set/unset state of routerequired state of pointcontrol left/right position of point
    control set/unset state of routerequired state of pointindicate required state of point
  2. Abstract required state (reflexive) (WHERE one type of abstract state is used as a parameter to another instance of the same function that produced the original abstract state type)
    • Produced by function type: Control state x (instance y)
    • Consumed by function type: Control state x (instance z)
    • For functional exchanges between two instances of the same function, the functional exchange should go through a duplicate function (Name of the duplicate function shall be Duplicated instance of function 'original function name').

    • Example (classical light signalling):

      SourceExchangeSink
      control aspect of light signal BER003 (Hauptsignal/Main signal)required aspect of signal BER001control aspect of light signal BER001 (Vorsignal/Distant signal)
  3. Plant external required input state
    • Produced by function type: Control
    • Consumed by function type: Actuate or Indicate
  4. Plant external actual input state
    • Produced by function type: Actuate
    • Consumed by function type: Plant
  5. Plant actual output state
    • Produced by function type: Plant
    • Consumed by function type: Sense
  6. Sensed output state
    • Produced by function type: Sense
    • Consumed by function type: Observe
  7. Estimated internal state (abstraction level equal to abstraction used by control)
    • Produced by function type: Observe
    • Consumed by function type: Control
  8. Estimated internal state (abstraction level less than abstraction used by control OR used by observe function for a different internal state)
    • Produced by function type: Observe
    • Consumed by function type: Observe (different instance)
  9. Estimated internal state (for indication to a human user)
    • Produced by function type: Observe
    • Consumed by function type: Indicate
  10. Human perceptable state
    • Produced by function type: Indicate
    • Consumed by function type: Control or Observe (allocated to human actor)
SFE-160

WHERE a function outputs more than one separate exchange type, each exchange type exits the function by a separate output port.

Note: a single exchange type may be realised by more than one different type of exchange item. At the modeller's discretion, this means that the number of functional exchanges and ports can be reduced, if the exchange items all belong to the same type . For example, for state type "required state of train unit motion", the exchange items "required state of emergency brake", "required state of traction cut-off", "variable traction/braking command", "pseudo-journey profile" and "pseudo-movement authority" can all be categorised and therefore can all legitimately be outputs of the one single function "control the motion state of one train unit".

Modelling style may need to be varied here for different particular instances; it is impossible to be absolute about how to apply the rules; when in doubt, consult the lead system architect.

SFE-170

WHERE a function takes as inputs more than one separate type of state (that is, a completely separate type of functional exchange), each separate type of state enters the function by a separate input port.

The note against SFE-160 also applies.

SFE-180WHERE a function produces more than one instance of the same type  of a functional exchange, all the instances of this type of functional exchange exit the function via the same output port.
SFE-190WHERE a function takes more than one instance of the same type of a functional exchange as inputs, all the instances of this type of functional exchange enter the function via the same input port.
SFE-200

Multiple instances of the same type of functional exchange must have identical names but it is permissible to add a unique suffix to them if this improves the descriptiveness of the model

Example:

  • Required motion state of one train unit (restriction)
  • Required motion state of one train unit (desired)
SFE-210

Each instance of a functional exchange of a given type only conveys those exchange items that are used by the sink function.

This means that multiple instances of the same type of functional exchange are allowed to carry different sets of exchange items, provided that all the exchange items are legitimate for that functional exchange type (see note against SFE-160).

SFE-220

For functional exchange between interfacing function:

A functional exchange can only exist between interfacing functions of the same interfacing functions pair (see SIF-030).

2.2.6. System Component Exchange

IDRules

SCE-010

Naming convention:

If the interface is defined or governed by an external standard the name of the system component exchange is used as defined in the external standard.

Note: this rule applies only if the current name within the standard is meaningful and can no longer be changed.

  • Prefix for interface to a non human actor: I_
  • Prefix for interface to a human actor: HMI_
  • The ActorName should be written for component exchanges in PascalCase - All words capitalised and run together. First letter is capitalised.
  • If there are more then one component exchanges for one interface (interface layer) each component exchange should have the layer information: _<LayerName>
    (But please do not include the word "layer" in the layer name)
  • If there is more than one interface between entities, each component exchange should end with the interface number information: _< interface number information (see. SFI-010): _< interface number information>

component exchange name = I_ / HMI_ <ActorName>_<LayerName>_< interface number information>

E.g. I_PlanningSystem_Application_01

SCE-020

Component Exchanges have only allocated functional exchanges which came from an exchange between interfacing functions.

Exception: if the interface is non-externally constrained then component exchanges can have allocated functional exchanges which came from an exchange between core functions.

SCE-030A Component Exchange has only allocated functional exchanges which came from the same interfacing functions pair (see SFI-030).
SCE-040Component Exchanges may have more than one allocated functional exchange.
SCE-050

Port of a Component Exchange should be In or Out port.

Exception: if a component exchange has bilateral allocated functional exchanges, then both ports are InOut ports.

2.2.7. System Physical Link

IDRules

SPL-010

Naming convention:

If the interface is defined or governed by an external standard the name of the system component exchange is used as defined in the external standard.

Note: this rule applies only if the current name within the standard is meaningful and can no longer be changed.

If name is not meaningful and can be changed this following scheme is applied:

  • Prefix for interface to a non human actor: I_
  • Prefix for interface to a human actor: HMI_
  • The ActorName should be written for component exchanges in PascalCase - All words capitalised and run together. First letter is capitalised.

component exchange name = I_ / HMI_ <ActorName>_ Physical

E.g. I_PlanningSystem_Physical

2.2.8. System Functional Chain for System Capability

IDRule
SFC-010

Naming convention:

The initial functional chain shall be named <system capability name> (initial)

The functional chain that assesses and mitigates the different risks shall be named<system capability name> (with robustness measures)

SFC-020

There exists for each system capability two functional chains: one initial system functional chain, and one system functional chain including robustness measures for operational performance, functional safety and functional security

SFC-030

Note: A functional chain may be used to refine its owning capability by limiting the features applied to it. As a result, the pre and post-conditions of the owning capability may apply only partially to the functional chain. In such cases, the pre-conditions and post-conditions of the functional chain may be refined from those of the owning capability.  If, for example, either the train driver or train attendant may close the doors of a train unit within the scope of a capability, the more refined functional chains may show these refinements of the overall capability in the form of additions in the pre-condition and post-condition fields of the functional chain.

WHERE the pre and/or post-conditions of a functional chain deviate from those of its owning capability, they should ideally be formatted as such:

<Entity> is <state>

where entity could be any actor or a data concept and state is one of the defined states that the entity is allowed to occupy.

Guidance:

  • System Capabilities are to be written from an actor's perspective, similar to use cases. Although the ARCADIA method describes system capabilities from the system perspective, we have decided that a deviation from the established method is preferred for our purposes.
  • Although the <entity> is <state> format is ideal, there may be some start and end conditions that do not conform to it due to the fact that the desired condition of the entity cannot be expressed in terms of states (e.g. The current point_position_estimation is indicated to Railway Operator). 

2.2.9. Exchange Scenario for System Capability

Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios

SXS-102

Naming convention:

The initial scenario shall be named  <capability name>[<X>](initial).

X is the number of the initial scenario.

The scenario that contains the assessment and mitigation of risks of system failures shall be named <capability name>[<X.Y>](with robustness measures).

X is the number of the related initial scenario.

Y is the number of scenarios with robustness measures.

SXS-101

There exists for each System Capability at least two scenarios: one initial scenario and one initial scenario with robustness measures for operational performance, functional safety and functional security.

SXS-104

Note: An Exchange Scenario may represent either a more specific and detailed course of the main success scenario OR a deviation from the main success scenario (e.g. depending on operational scenarios). Therefore the pre- and postconditions of the Capability may or may not apply to the Exchange Scenario.

If the pre- and postconditions of the owning capability fully apply to the Exchange Scenario:

  • Pre- and postconditions of owning capability will be selected for Exchange Scenario
  • Additional pre- and postconditions represent a refinement or more concrete conditions that apply to this specific scenario. 

If the pre- and postconditions of the owning capability do not (fully) apply to the Exchange Scenario:

  • Pre- and postconditions of the Exchange Scenario represent which pre- and postconditions of the owning capability are NOT fulfilled
  • Additional pre- and postcondition provide specific context for this scenario

2.2.10. Exchange Scenario for an Interface Layer

Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios

SXS-105

Naming convention:

The initial scenario shall be named I_ / HMI_ <ActorName><LayerName>< interface number information>.

  • Prefix for interface to a non-human actor: I
  • Prefix for interface to a human actor: HMI_
  • The ActorName should be written in PascalCase - All words capitalised and run together. The first letter is capitalised.
  • If there is more than one interface between the entities, then the scenario should end with the interface number information: _< interface number information (see. SFI-010): _< interface number information>

E.g. I_PlanningSystem_Presentation_01

SXS-106

There may exist a scenario for an Interface Layer if there is a need to model interface-specific behaviors

SXS-107

Note: An Exchange Scenario may represent either a more specific and detailed course of the main success scenario OR a deviation from the main success scenario (e.g. due to incidents). Therefore the pre- and postconditions of the Capability may apply to the Exchange Scenario or not.

If the pre- and postconditions of the owning capability fully apply to the Exchange Scenario:

  • Pre- and postconditions of owning capability will be selected for Exchange Scenario
  • Additional pre- and postconditions represent a refinement or more concrete conditions that apply to this specific scenario. 

If the pre- and postconditions of the owning capability do not (fully) apply to the Exchange Scenario:

  • Pre- and postconditions of the Exchange Scenario represent which pre- and postconditions of the owning capability are NOT fulfilled
  • Additional pre- and postcondition provide specific context for this scenario
SXS-108A scenario only model on one interface layer at a time

2.2.11. System State

IDRule
SST-010

Naming convention:

Sentence case - the first letter of the first word in a sentence is capitalised.

State names contain either

adjectives, referring to a quality of the owning entity/actor

or

verbs in the present participle form (-ing)

or

verbatim copies of states defined externally to the project (that is, when reusing state definitions from elsewhere, they should be reproduced precisely and not changed)

SST-020

States have a brief description of the qualities that define this state as distinct from the others.

Guidance: This may include a brief summary of the distinct behaviour of the entity that is exposed in this state.

SST-030

Only states are used in the model. Modes are not used.

Rationale: The behaviour of both elements in the model is identical and the difference in definition, arising from ARCADIA methodology, is somewhat philosophical. Methodology circle recommends standardising on using only states throughout.

2.2.12. System Rationale

IDRule
SRA-010Rationales should be created using the model element requirement (type rationale).
SRA-020The description for the rationale is inserted in the field "text" in Capella.
SRA-030Each rationale has at least one outgoing link to a target model element using the relation type "justifies".
SRA-040

Basically, all model elements can be justified by a rationale. At least the following model elements on system level should be justified:

  • component exchange + actor → to justify why that actor has an interface to the system and why this actor was chosen to be relevant for the system
  • (optional but recommended) function input port + incoming functional exchange → to justify why that input is necessary.
  • system function → to justify why that function is allocated to the system
  • (optional) function allocated to actor → to justify why that function is allocated to an actor and not to the system
SRA-050

If a rationale is expanded by an artefact, e.g. a trade study result (AMOD-046 or AMOD-024) or other type of supporting artefact, the rationale text shall include a reference to the expanding artefact, including (where possible) its document number and a hyperlink to the artefact's current version.

Guidance:

ARCH.M.110 Method for definition of rationales

2.3. Diagram Types and Viewpoints

2.3.1. General Rules

IDRule
GRV-010

Each diagram shall be named according to following convention:

[<Capella diagram type abbreviation>][<Viewpoint number>] <Subject of view> [<Viewpoint name>]

Capella diagram type abbreviation: abbreviation indicating the type of the diagram with the following possible values:

  • MCB - Mission Capabilities Blank
  • CC - Contextual Capability

  • SDFB - System Data Flow Blank

  • SFBD - System Function Breakdown

  • SAB - System Architecture Blank
  • CSA - Contextual System Actors

  • S.ES - System Exchange Scenario (Default in Capella [ES])

  • SDFB - System Functional Chain Description

  • S.CDI - Contextual Component Detailed Interfaces (Default in Capella [CDI])

  • S.STM - System State Machine (Default in Capella [MSM])

Viewpoint number: number given to the viewpoint based on ARCH process

Subject of view: either a <model element> or <free text>

  • <model element>
    • exact name of the model element
    • is used if the viewpoint focuses on a single model element
  • <free text>
    • a useful title providing initial information about the contents of the diagram (e.g. set of model elements shown)
    • is used if the viewpoint does not focus on a single model element or for other cases
    • shall be written in sentence case - the first letter of the first word in a sentence is capitalised

Guidance:

  • if needed also further information like e.g. sequence diagram main success scenario, alternative scenario, etc. can be included

Viewpoint name: name given to the viewpoint based on ARCH process

Examples:

  • [SDFB][AMOD-056] SysC15: Respond autonomously to obstacle on or near the line [System functions and exchanges (single system capability)]
GRV-020

Optional rule: A diagram has a visible note as a short text description consisting of the following three parts:

  • Status: initial draft, group reviewed, design reviewed
  • Version: version of the diagram, there is only a version after first design review
  • Reference: references to resources on which the diagram was created/build
GRV-030

If a note is used on a diagram, it should include the name of the person responsible and the date of creation.

Note: if after the design review there is still a need for the note, the name can be removed.

2.3.2. System Architecture (SAB)

2.3.2.1. General Rules

SAB-010The system of interest appears on the diagram
SAB-020At least one actor (external to the system) is visible on the diagram

2.3.2.2. AMOD-041 System boundary options

041-010This view is produced as a sketch using any preferred drawing tool.
041-020

The notation used by the Capella SAB diagram is used in this view:

  • dark blue box for the system
  • light blue box for system actors
  • green for system functions
041-030The view presents two or more alternative system boundaries alongside each other for comparison.
041-040

For each alternative system boundary, there is displayed

  • the system
  • at least one actor
041-050

For each alternative system boundary, there is displayed

at least one candidate function allocated to the system

AND

at least one candidate function allocated to one actor

041-060

WHERE a candidate function has been created as an implementation of an operational activity, the function is named identically to the operational activity

041-070WHERE two or more candidate functions have been created as a decomposition of an operational activity, a note is added to the sketch, linked to all such candidate functions, containing the name of the operational activity that was decomposed.
041-080Comparing one alternative system boundary with another, there exists at least one difference in the allocation of candidate functions between the system and the actor(s).

2.3.2.3. AMOD-046 Selected system boundary tradeoff record

046-010

This view is produced as a sketch using any preferred drawing tool.

046-020

The notation used by the Capella SAB diagram is used in this view:

  • dark blue box for the system
  • light blue box for system actors
  • green for system functions
046-050There exists one and only one system on the view.


044-010All system actors are displayed on the view.
044-020

All known functions allocated to the actor are displayed on the view.

2.3.2.4. AMOD-114 System interface definition

114-005The multiplicities shown in the ontology must be complied with.
114-010One system actor is displayed on the view.
114-020

Core functions are displayed on this view if and only if they have exchanges with core functions allocated to the other part of the interface.

114-022A pair of interfacing functions is displayed on the view in case of an externally constrained interface
114-025

This view defines interface layers, which means that this view displays functional exchanges and component exchanges between interfacing functions in the case of an externally constrained interface.

Where requirements or constraints on the exchange between the system and system actor have been identified. For all aspects of the interface where no requirements have been identified, no interface layers are defined. More guidance and method → Method for definition of system interfaces

114-030All exchanges between core functions and interfacing functions are defined in this view
114-050

One component exchange is displayed on this view to represent each identified layer, except for physical layer (see 114-060).

Exception: in case of a non-externally constrained interface, a component exchange is displayed between the system and the actor and can be associated to the “application layer”

114-055All functional exchanges between interfacing functions should be allocated to the corresponding component exchange of the specific interfaces
114-060A physical link is displayed on this view to represent the physical layer of the interface.
114-061

If physical links are used for the interface, allocate the corresponding component exchanges of an interface layer to these physical links.

114-080The filter settings of the SAB diagram are set to display the exchange items that are exchanged over each functional exchange.

2.3.2.5. AMOD-119 System context definition

119-010All actors on the diagram are connected with the system via a component exchange.
119-020

The flow direction of each component ports is set as follows:

  • in: In case all functional exchanges flowing into a system function that is allocated to the system or actor, to which the component port belongs. This must correspond to component port of the inverted flow direction at the other end of the same component exchanges.
  • out: In case all functional exchanges flowing out of a system function that is allocated to the system or actor, to which the component port belongs. This must correspond to component port of the inverted flow direction at the other end of the same component exchanges.
  • inout: In case at least one functional exchange is flowing out of a system function and at least one functional exchange is flowing into the same system function and that system function is is allocated to the system or actor, to which the component port belongs. This must correspond to component port of the same flow flow direction at the other end of the same component exchanges.

2.3.2.6. AMOD-133 Consolidated system function allocation

133-005All system actors are displayed on the view.
133-010All functions in the model are allocated to either a system actor or the system.
133-020

All functional exchanges that cross the system boundary are allocated to a System component exchange (Port allocation is shown),

133-030The filter "Hide Functional Exchanges" is activated.

2.3.3. System Capability Subset (MCB) and Contextual Capability (CC)

2.3.3.1. General Rules 

SC-101

At least one system capability is visible on the diagram

Guidance (MCB): Show a subset of the system capabilities that focus on a given aspect of the system

SC-102At least one actor (external to the system) is visible on the diagram
SC-103

Where missions are visualised:

Each mission exploits at least one capability

AND

Each system capability is exploited by at least one mission

SC-104

The relationship between two capabilities is shown with generalisation or include or extend relationship.

(exclusive OR: only one of these relationships may be established between any pair of capabilities)

SC-110

The set of relationships between system capabilities is logically consistent.

(this means avoiding issues like circular dependencies, making sure that include and extend relationships point in the correct direction, etc.)

2.3.3.2. Guidance

Detailed guidance and explanations can be found in ARCH.M.040 Method for definition of capabilities.

2.3.3.3. AMOD-045 System capabilities

045-010The capabilities and missions are divided between diagrams in the same structure as done at operational level (view AMOD-021)
045-020

Actor involvements may be shown but this is optional.

Rationale: actor involvements may clutter the diagrams if there is a large number of actors and a large number of capabilities.

2.3.3.4. AMOD-138 Single system capability context

IDRule
138-010

For the system capability of interest, all actor involvement relationships are shown.

Note: capabilities other than the system capability of interest may optionally show relationships to actors and to each other, if useful.

138-020

For the system capability of interest, all relationships to other system capabilities are shown.

2.3.4. System Exchange Scenario (S.ES) 

2.3.4.1. General Rules

SES-010

The diagram comprises all directly involved actor lifelines.

SES-031

Only the following combined fragments are permitted to be used in S.ES:

  • OPT
  • LOOP
  • PAR
  • REF
  • ALT

Note: ALT fragments should not usually be needed, since alternative paths are usually modelled in separate scenarios; they continue to be permissible but only where strictly necessary.

SES-040

If at least two functional exchanges can occur in parallel each following weak sequencing rules, the functional exchanges are modelled using the PAR fragment. There is no implied order between occurrences in different operands.

SES-041Where PAR fragments are used, at least two operands are required.
SES-050Optional functional exchanges("if-" functional exchanges that take place under certain conditions, with no alternative) are modelled using the OPT fragment.
SES-060

Where OPT fragments are used, OPT fragments have a defined guard condition describing the logical condition under which the functional exchange takes place.

SES-061

When a LOOP combined fragment is used, it shall have a guard condition that describes the logical condition under which the combined fragment takes place.

Optional: you can specify a minimum and a maximum number of iterations of the loop between parentheses. The format is: (<min.>, <max.>) and it shall be added in a note attached to the LOOP combined fragment (a note because this capability is not supported by Capella). If not specified, a default range (0, *) is assumed.

SES-070

See note against SES-031

Alternate functional exchanges ("if-then-else" constructs of functional exchanges that take place under certain conditions, with alternative functional exchanges under different conditions) are modelled using the ALT fragment.

SES-080

See note against SES-031

Where ALT fragments are used, at least two operands are required. Each operand of the fragment has a defined guard condition describing the logical condition under which the functional exchange takes place.

SES-090

See note against SES-031

Where ALT fragments are used,

the set of guard conditions for the fragment covers all eventualities

AND

there are no logical intersections between guard conditions (they are mutually exclusive)

SES-092

It is allowed to use reference (interaction use) to reduce the complexity of a scenario within one capability. The use should be well justified and really only used where it makes sense.

Note: Where a reference is used, the reference object must be manually configured with the correct involved lifelines. Where practical, the reference object must be laid on the diagram in such a way that non-involved lifelines are not covered by the reference object.

SES-093

When one capability includes another capability with the "include"-relationship then the scenarios of the included one are referenced using the REF combined fragment (reference/interaction use).

No lifelines in the scenarios are shown which do not have any interaction which another lifeline. If another scenario is referenced where the omitted lifeline is then involved, its involvement is only shown in the referenced one, but not the referencing one.

Note: This is done for practical reasons and tool constraints deviating from common practice (e.g. SysML) to show every lifeline involved in the capability (i.e. the including capability and the included one).

SES-094

When one capability extent another capability with the "extent"-relationship then the scenarios of the extended one are referenced using the REF combined fragment (reference/interaction use) and OPT combined fragment. The OPT fragment includes the condition when the extension is applicable.

No lifelines in the scenarios are shown which do not have any interaction which another lifeline. If another scenario is referenced where the omitted lifeline is then involved, its involvement is only shown in the referenced one, but not the referencing one.

Note: This is done for practical reasons and tool constraints deviating from common practice (e.g. SysML) to show every lifeline involved in the capability (i.e. the extended capability and the extending one).

SES-100The diagram contains at least one complete sequence of functional exchanges (output of function of interest) that is navigable from the start conditions to the end conditions.
SES-105The execution element of an incoming exchange is as long as the duration in which the outputs of functions can change within a lifeline. This means as long as new exchanges with a changed value to another lifeline are happening depicted on the diagram.
SES-110

All functions of interest (functions that are part of the sequence path in the respective functional chain) are shown as graphical representation (allocated function) on the diagram:

  • functions are placed on the execution element of a lifeline for incoming functional exchanges
  • preceding incoming functional exchanges and outgoing functional exchange (only when representation of the function has added value for the reader of the diagram)

Note: The intended meaning is that, at this point of the sequence, the function's output changes in line with changes to its inputs. It is NOT intended to indicate that the function is "called" or "invoked"; the function is assumed to be "always-on" or at least "always-on in a particular system state".

SES-120

Functional Exchanges are shown on the diagram:

  • Names of functional exchanges are not shown on the diagram (Hide by filter)
  • Allocated exchange items are shown on the diagram (Shown by filter)
  • Show the functional exchanges between the system and the external actors (only exchanges between functions of interest that are part of the sequence path)
  • Internal functional exchanges within the system of interest or an actor are not shown (e.g. functional exchanges to the system or actor itself)
SES-131

If the pre- and postconditions of the owning capability fully apply to the Exchange Scenario these shall be contained in the diagram.

Additional pre- and postconditions of the Exchange Scenario shall be specified in the related field in Capella, representing a refinement or more concrete conditions that apply to this specific scenario.

Preconditions will be represented in the upper left corner of the diagram. Capability preconditions will be represented over the specific preconditions

Postconditions will be represented in the bottom left corner of the diagram, at the end of the lifelines. Capability postconditions will be represented over the specific postconditions


SES-132

If the pre- and postconditions of the owning capability do NOT apply to the Exchange Scenario these shall NOT be contained in the diagram.

Pre- and postconditions of the Exchange Scenario shall be specified in the related field in Capella, explicetely specifying which pre- or postconditions are NOT fulfilled in this scenario. The semantic shall be:

NOT(<pre/postcondition of owning capability>)

Any other additional pre- or postconditions providing context to the specific scenario shall also be specified in the related field in Capella.

Preconditions will be represented in the upper left corner of the diagram.

Postconditions will be represented in the bottom left corner of the diagram, at the end of the lifelines.


SES-130

Where a particular state on a lifeline changes as a result of an interaction, and this is relevant to the scenario, it should be shown using the "State Invariant" graphical element ("State Fragment" in Capella obtained through "Involved State / Mode")

State Machine contained in Physical Train Unit here


At this level, the trigger of the transition of the state machine should match/be consistent with the interaction depicted in the sequence diagram (see "switch on fwrd" in the example above)

SES-140

Where an exchange context is used to illustrate the content of a Sequence Message:

  • Exchange Context is specified as a Sequence Message property.
  • An Exchange Context is displayed as a Constraint linked to a Sequence Message.
  • Exchange Context can be either written in plain text or as linked text referencing elements from the data model.

2.3.4.2. Guidance

Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios

2.3.4.3. AMOD-058 Initial system exchange scenario 

058-010

The diagram shows only the functional exchanges needed to reach the end conditions, without any consideration of robustness to system failures.

2.3.4.4. AMOD-117 System exchange scenarios with risk control measures [S.ES] 

117-010

The diagram shows all the functional exchanges needed to reach the end conditions, including mitigations against the risk of system failures.

2.3.4.5. AMOD-115 External interface behaviour 

115-010

The diagram shows the functional exchanges needed to capture any pre-defined/externally-defined behaviour of an interface layer protocol that is a constraint on the system (i.e. forced by outside needs).

115-020Only the system and one actor (the external party of the interface) are displayed on the diagram.
115-030Only one interface layer is considered in the scenario.
115-040The functions of the system and the actor involved in this scenario are shown on the corresponding lifeline.
115-050Only the symbolic functional exchanges between the system and the actor are shown

2.3.5. System Data Flow (SDFB)

2.3.5.1. General Rules 

SDFB-010

The general direction of functional exchanges is directed either

left to right

or

top to bottom

SDFB-020

The direction of functional exchanges that form feedback loops is either

right to left

or

bottom to top

SDFB-040Where there exists some hierarchy of functions, the owning function is shown on the diagram, with the owned function nested inside it.
SDFB-050

Functional Exchanges are shown on the diagram between functions of interest and functions that provide information.

  • Names of functional exchanges are not shown on the diagram (Hide by filter)
  • Allocated exchange items are shown on the diagram (Shown by filter)

2.3.5.2. AMOD-056 System functions and exchanges (single system capability)

056-010

General rule: there exists one diagram per system capability;

Qualification 1: where more than one capability use almost exactly the same set of functions, it is permissible to use one diagram to capture the functions and exchanges of more than one capability;

Qualification 2: where a capability involves more functions than can fit sensibly on a diagram, it is permissible to create more than one diagram for the capability.

056-030The diagram (or set of diagrams if 056-010 Q2) displays all functions AND functional exchanges involved in the fulfilment of the owning capability, including functions allocated to actors.

2.3.5.3. AMOD-103 Consolidated system functions

IDRules
103-010

General rule: there exists one diagram that shows all system functions and their functional exchanges.

Note: This is not used as a deliverable, but as a working diagram.

103-020

The free text for the diagrams name shall include:

"<system name> system functions consolidated"

Where:

<system name>: Is the name of the one system on system level. E.g. System RCA.


2.3.6. System Functional Chain Description (SFCD)

2.3.6.1. General Guidance

  • The green blocks displayed on an SFCD are System Function Involvements, not System Functions themselves. They can only be created to represent System Functions that already exist, so it is useful to have an SDFB (AMOD-056) open where you can create new System Functions and Functional Exchanges if you need them. When they are deleted, they do not delete the System Function they represent.
  • The functional chain viewpoint exists to show sequential order of functions without considering allocation of the functions.
  • Allow plenty of space so that you can set the diagram out in a neat and orderly way; these diagrams quickly become unreadable if the left-to-right or top-to-bottom convention is not followed.
  • A function involvement means that when the chain of sequence links reaches this particular function involvement, the output value of this function has changed.

2.3.6.2. General Rules

SFCD-100

There exists no function of interest involvement that is unconnected to the rest of the functional chain by a sequence link.

A function of interest is a function whose execution happens wholly within the timeframe of this functional chain and is inextricably bound up in the execution sequence of this functional chain. In contrast, an information-providing function is one that (in the context of THIS functional chain) could be thought of as an always-present information source/sink, where the sequencing/logic of its execution is not relevant to the sequence of THIS functional chain.

SFCD-110There exists at least one navigable path of sequence links from the beginning of the functional chain to end of the functional chain.
SFCD-120

Functional Exchanges are shown on the diagram between functions of interest and functions that provide information.

  • Names of functional exchanges are not shown on the diagram (Hide by filter)
  • Allocated exchange items are shown on the diagram (Shown by filter)
SFCD-130

To illustrate the content of a Functional Chain Involment Link using values, an Exchange Context may be used as follows

  • Exchange Context is specified as a Functional Chain Involment Link property.
  • An Exchange Context is displayed as a Constraint linked to the Functional Chain Involment Link.
  • Exchange Context can be either written in plain text or as linked text referencing elements from the data model.

2.3.6.3. Start and End Conditions

SFCD-005

The start and end conditions of the owning System Capability are displayed on the SFCD diagram. They should be placed such that they conform to the flow of the diagram. If a diagram flows from top to bottom, the conditions should be placed on the top and bottom.

Note: Related functional chains can have different end conditions. A capability should contain all relevant conditions for all of the functional chains it contains. They can be differentiated in the description using OR relationships.

Guidance: To display start and end conditions, use the Constraint referencing tool and look up the two constraints linked to the owning System Capability - these will be the start and end conditions, and they should display on the diagram just like any other constraint.

Note: constraints attached to functional chains which are displayed collapsed will not appear on the diagram.

2.3.6.4. Logic Nodes (AND, OR) and Sequence Links

SFCD-001A System Function Involvement shall only have a maximum of one incoming sequence link.
SFCD-002A System Function involvement shall only have a maximum of one outgoing sequence link.
SFCD-010

Where a decision is made between two or more possible, mutually exclusive paths in the process:

  • This is modelled using the OR node to split one incoming sequence link into two or more outgoing sequence links.
  • Each outgoing sequence link has a valid guard condition describing when this path is taken.
  • The guard conditions cover all possibilities without logical gaps.

SFCD-011When an OR node is used as a SysML decision node (see SFCD-010), the OR node should always be preceded by a Function
SFCD-020

Where two or more alternative paths come back together to a common path:

  • This is modelled using the OR node to merge two or more incoming sequence links to one outgoing sequence link
  • The merge of these paths is consistent with the logic of the original split as defined under SFCD-010 (note: this does not mean that ORs must always be used in matching pairs; multiple splits and merges are allowed, provided the logic is correct)

SFCD-030

Where two or more branches of the process run in parallel/concurrently:

  • An AND node is used to split one incoming sequence link into two or more outgoing sequence links
  • An AND node is used to merge two or more incoming sequence links into one outgoing sequence link

Note: This does not mean that AND nodes must be always used as matching pairs where the number of outgoing links from the first AND equals the number of incoming links to the second AND, as long as all parallel branches are eventually terminated by an AND.

2.3.6.5. Instantiation of Functions

SFCD-039Where an actor function is needed in order to completely reach the end conditions/stimulate the start conditions of a system capability, this actor function is shown on the diagram.
SFCD-040Where the same function occurs more than once within a functional chain in different contexts, this is modelled with two or more separate function Involvements, placed in a logically consistent position in the process.
SFCD-050

Where the same function or sequence of functions occurs more than once within a functional chain

OR

Where the execution logic of the functional chain requires a return loop from a later function to an earlier function

this is modelled using the IT construct to create a loop


2.3.6.6. Included Functional Chains

SFCD-060Where a functional exchange exists between two functions AND the function is relevant to this functional chain the functional chain is displayed on the SFCD. Functional chains of interest (needed to arrive at the postcondition) will be included or extended, and will be displayed minimized. The included or extended functional chain should be connected to the functional chain of interest using sequence links.
SFCD-070

Where a functional chain includes another functional chain in its entirety

the included functional chain is displayed on the SFCD for the including functional chain as a separate reference block (that is, the included functional chain steps are not redefined)

Note: modelling in this way would imply that there is an inclusion relationship between the respective owning system capabilities.

SFCD-080

The view must comply with SFCD-080 INCLUSIVE OR SFCD-090

Where a functional chain includes another functional chain in its entirety

there exists at least one sequence link from a function involvement outside the included functional chain to a function involvement inside the included functional chain

AND

there exists at least one functional exchange involvement from a function involvement outside the included functional chain to a function involvement inside the included functional chain

SFCD-090

The view must comply with SFCD-080 INCLUSIVE OR SFCD-090

Where a functional chain includes another functional chain in its entirety

there exists at least one sequence link from a function involvement inside the included functional chain to a function involvement outside the included functional chain

AND

there exists at least one functional exchange involvement from a function involvement inside the included functional chain to a function involvement outside the included functional chain

2.3.6.7. AMOD-059 Initial system functional chain description

059-010The diagram shows only functions of interest and functional exchanges necessary to reach the end conditions of the capability, disregarding any need for system robustness.

2.3.6.8. AMOD-118 System functional chain descriptions with risk control measures [SFCD]

118-010The diagram shows all functions of interest and functional exchanges necessary to reach the end conditions of the capability, including measures needed for system risk control.

2.3.7. State Machine (MSM)

2.3.7.1. General Rules

IDRule
SSM-010

There exists a single Initial state.

SSM-030There exists at least one transition outgoing from each state (except for the Final state)
SSM-040There exists at least one transition incoming to each state (except for the Initial state)
SSM-050

There exists at least one navigable path along transitions from the Initial state to the Final state, if a final state is defined.

SSM-060

All transitions have a definition of the conditions for the transition, selected from:

  • Trigger definition, by referring to functional exchanges/exchange items/functions, with (optionally) guard conditions to qualify the trigger (preferred)
  • Guard condition describing the trigger (non-preferred, for use where the triggers are not readily identifiable, especially for more abstract state machines)
SSM-070

Only change events are allowed to trigger transitions of a state machine.

A change event of a transition is defined as follows:

when (<boolean expression>)

The boolean expression is textual and can be written in natural language.

Exception: an actor uses an interface already defined at the system level and this is event based. Then events can also be used for an actor state machine.

2.3.7.2. AMOD-060 System/actor states

IDRule
060-010

The set of states on the view gives complete coverage of the statefulness of the owning actor/system.

Guidance: rather than defining hundreds of specific states, define broad states that together cover the full range of possible states. When closing a gap, adjust the definition to make it broader, in preference to creating more states.

060-020

Where an entity has a range of states that all amount to the same behaviour with respect to the system of interest and where the transitions between these states are not relevant to the system of interest, this is modelled with one broadly-defined "super"state rather than a faithfully-rendered model of many distinct states.

Guidance: this is a time/effort-saving measure to focus energy on those states and transitions that are important to the system of interest.

060-030Where an operational actor/entity has a set of states defined externally from the system of interest (e.g. in existing documentation) then the states are reused, if it is judged to be appropriate, in preference to a completely new the system of interest definition of the states.

2.3.7.3. AMOD-055 System functions to state allocation map [Matrix]

IDRule
055-010

Per System State Machine on matrix of name "Capability Function and State Machine Matrix" shall be generated.

055-020

A system function shall be allocated to a state by using the field "Operational Activities / Functions", which can be edited after double-clicking the state.

2.3.8. Query-based Viewpoint

2.3.8.1. AMOD-116 System implementation constraints 

IDRule
116-010

All model elements shall be listed/displayed in this viewpoint that conform to the following:

The rationale of the model element makes reference to either the IVV strategy OR the CONEMP in justifying its existence.

Color legend :

MeaningColor
Naming convention