Legal information

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

3. Modelling Rules for Logical Architecture

3.1. Overall

IDRule
LA-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.

LA-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

LA-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.

3.2. Elements

3.2.1. Logical Function

3.2.1.1. Guidance

Guidance and method can be found on this page → ARCH.M.010 Method for definition of functionality

3.2.1.2. General Rules

IDRule
LF-100

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.

LF-120

The usage of abbreviations should be well considered and should only be used in cases where the abbreviation is either standardised  (e.g. ETCS, PRM, GoA) or when it improves readability as in the case of known defined abbreviation within the project (e.g. DPS).

LF-121

All leaf-level logical functions have been allocated to

one of the proposed logical components

or

one of the actors

LF-122

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

  • The description explain 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 LRA-040

3.2.1.3. Function Allocated to Logical Component

LFC-130

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.

LFC-132For logical functions, the multiplicities shown in the ontology in Method for definition of functions must be complied with.
LFC-140

Control system principle

Each core logical function should be named and described in such a way that it conforms to one of the categories of control function. A "core" 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
  • Sense
  • Observe

Taxonomy:

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

LFC-141

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 logical level.

LFC-160The logical functions, that was created due to split of a system function needs to be inline with the Method for decomposition of functions.

3.2.1.4. Function Allocated to Logical Actor

IDRule
LAF-010

Naming convention:

Names of functions allocated to logical actors 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.

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

LAF-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).

3.2.1.5. Interfacing Function

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

IDRule
LIF-010

Naming convention:

Each logical interfacing function has an identical name to the corresponding system interfacing function

LIF-020The set of logical interfacing functions is identical to the set of system interfacing functions.
LIF-030Each logical interfacing function has an identical description to the corresponding system interfacing function.
LIF-040Each logical interfacing function traces to one and only one system interfacing function.

3.2.2. Functional Exchange

LFE-010

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.

LFE-120

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.

LFE-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 type) 
    • 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)
LFE-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.

LFE-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 LFE-160 also applies.

LFE-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.
LFE-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.
LFE-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)
LFE-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).

3.2.3. Logical Actor 

LAC-010

Naming convention:

Each logical actor has an identical name to the corresponding system actor.

LAC-020

The set of logical actors is identical to the set of system actors.

LAC-030Each logical actor has an identical description to the corresponding system actor.
LAC-040Each logical actor traces to one and only one system actor via the "realised actors" relationship.

3.2.4. Logical Component

LCM-010

Naming convention:

  • Title Case - the first letter of each word is capitalised, words separated by space.
  • Name should be singular
  • The last word of the name should be a noun (e.g. Sensor, Actuator, Observer, Executor, Controller, Indicator)
  • The usage of abbreviations should be well considered and should only be used in cases where the abbreviation is either standardised  (e.g. ETCS, PRM, GoA) or when it improves readability as in the case of known defined abbreviation within the project (e.g. DPS).

Exception for logical components allocating interfacing functions:

  • Each logical component's name should begin with the system's name followed by a dash and the actor's name
  • Each logical component's name should end with "Interface Endpoint"

Logical component name: <System> - <ActorName> Interface Endpoint

LCM-020

Logical component ports have direction consistent with the functional exchanges they support - this means either

Where a component exchange supports functional exchanges in both directions, the component port has direction INOUT

exclusive or

Where a component exchange supports only incoming functional exchanges, the component port has direction IN

exclusive or

Where a component exchange supports only outgoing functional exchanges, the component port has direction OUT

LCM-030

Each logical component has a description. Where an abstract concept is mentioned in the description of a logical component, this is done using a hyperlink to the abstract concept, rather than plain text.

Guidance:

  • Template:
    • Function summary: The <logical component name> component <summary of the type of functionality grouped into this logical component. NOT a complete listing of all allocated functions. NOT a complete description of any single function. Brief overview only.>
    • Defining characteristics: Bulleted list of characteristics apart from functionality that define this logical component as distinct from the others, e.g. level of safety criticality, the layer of the system of interest that it belongs to, and the value of any other logical splitting factors that were used to separate it from other components (see ARCH.180 Define logical component candidates)
LCM-040Based on the defined splitting principle for functions, there should never exist two or more logical components that have the same combination of splitting principle values; each logical component should have a unique combination of values.

3.2.5. Logical Component Exchange

LAB-112

Naming convention:

All component exchanges between logical components and an external actor crossing the system boundary are named in accordance with the following naming convention (pattern):

  • 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.
  • Each logical component exchange with the same name should have an unique number as part of the name (e.g. one component exchange on system level know splitted into two because the target is not the system anymore but two logical components.)
  • If there are more then one component exchanges for one interface (interface layer) each component exchange should end with the layer information: _<InterfaceLayerName> (But please do not include the word "layer" in the layer name)

Guidance:

logical component exchange name = I_ / HMI_ ActorName>_<unique number starting at 01>_<InterfaceLayerName>

Examples:

I_PlanningSystem_01_Application

I_PlanningSystem_02_Application

LAB-113

Where a functional exchange crosses a the boundary of the allocating logical component A

the functional exchange is assigned to the logical component exchange

and

the function port is assigned to a logical component port on A (automaticly done by capella when functional exchange is assigned to component exchange)

and

the assigned logical component port is connected to a logical component port on another logical component B

and

logical component B hosts the function at the other end of the functional exchange

Corollary: When functions are re-allocated to other logical components, function port allocations to component ports must be revisited to ensure all three conditions above are still met. The tool will not always stop the user from leaving an invalid port allocation after moving a function.

LAB-205

All component exchanges between logical components inside the system boundary are named in accordance with the following naming convention (pattern):

C <unique number> 

Note:

The standard mechnism of Capella is used which provides an automatic generated name and number for the created component exchanges.

Example:

C 03

C 19

LAB-208

There exists either zero or one component exchange between any pair of logical components

3.2.6. Logical Capability Realisation 

SCR-105

Naming convention:

An original capability realisation (see viewpoint definition AMOD-147) has the same name, description, relationships, precondition and postconditions as the system capability it represents.

refined capability realisation (see viewpoint definition AMOD-147) has its name derived from the original capability realisation, and its number has an additional decimal enumeration.

Example:

Original capability realisation is called <M> Deliver value <x>

Refined capability realisations are called <M.1> Deliver value <x> to actor <P>, <M.2> Deliver value <x> to actor <Q>...

These are just examples; it is possible to split/refine a capability for other reasons than because the value is delivered independently to different actors - see ARCH.191 for details, consult the lead system architect or methodology team if unsure.

SCR-110

refined capability realisation (see viewpoint definition AMOD-147) has its description, pre- and post-conditions derived from those of the original capability realisation that it refines.

In other words, these metadata should be broadly identical to the original capability realisation, except for those parts that make this refined capability realisation distinct from the other refined capability realisations.

Example:

Original capability realisation <M> had end condition "Value <x> has been delivered to actor <P> OR to actor <Q>"

after logical analysis according to ARCH.191 it emerges that the capability can be split into two with the value delivered independently to P or Q; in that case:

Refined capability realisation <M.1> has end condition "Value <x> has been delivered to actor <P>" 

and 

<M.2> has end condition "Value <x> has been delivered to actor <Q>".

3.2.7. Logical Exchange Scenario for Realised Capability

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

IDRule
LSC-010

Naming convention:

The exchange scenario for the realised capability is named <capability name>[<X>].

Where X is the number of the scenario.

LSC-020

There exists for each realised Capability at least one scenario. Further scenarios are optional.

LSC-030

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

3.2.8. Logical Exchange Scenario for Interface Layer

IDRule
LSC-040

Naming convention:

The exchange scenario for the interface layer is named <interface layer name>[<X>].

Where X is the number of the scenario.

LSC-050

There may exist an exchange scenario for the Interface Layer.

LSC-060

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

3.2.9. Logical Functional Chain for Realised Capability

LFC-010

Naming convention:

The functional chain shall be named <realised capability name> (logical functional chain)

There exists for each realised capability one logical functional chain.

LFC-020

There exists for each realised capability one logical functional chain.

3.2.10. Logical State

IDrule
LST-010

Naming convention:

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

State names are referring to a quality of the considered entity for which owning logical function performs something for or is tied to.

State names contain either

adjectives (-ed)

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)

LST-020

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

LST-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.

LST-040An entry action of a state is modelled as a constraint and the constraint is attached to the state.
LST-050

The content of an entry action is defined as follows:

<action expression>

The action expression is textual and consists of one or more atomic statements. It is conforming to the rules of the chosen modelling language.

Guidance: Try to limit the number of statements inside the action expression to keep and increase readibility of the state machine diagram (approx. a maximum number of five statements per action). In addition, avoid conditional statements (e.g. if-else) inside the action expression. Instead use choice states or guard conditions to express condtional outcomes.

LST-060An exit action of a state is modelled as a constraint and the constraint is attached to the state.
LST-070

The content of an exit action is defined as follows:

<action expression>

The action expression is textual and consists of one or more atomic statements. It is conforming to the rules of the chosen modelling language.

Guidance: Try to limit the number of statements inside the action expression to keep and increase readibility of the state machine diagram (approx. a maximum number of five statements per action). In addition, avoid conditional statements (e.g. if-else) inside the action expression. Instead use choice states or guard conditions to express condtional outcomes.

LST-080

The current value of an exchange item element is accessed inside an action expression by using the name of the exchange item element.

The corresponding statement follows the rules of the chosen modelling language.

Example: Action with an atomic assignment statement (pseudo modelling language)
OutgoingExchangeItem.ExItemElem = (IncomingExchangeItemA.ExItemElem < 10) And (IncomingExchangeItemB.ExItemElem != 1)
LST-090

A new value of an exchange item element is set inside an action expression by using the name of the exchange item element.

The corresponding statement follows the rules of the chosen modelling language.

Guidance: Assignment statements can be used to set the new value.

Example: Action with two atomic assignment statements (pseudo modelling language)
OutgoingExchangeItemA.ExItemElem1 = 10
OutgoingExchangeItemB.ExItemElem2 = AnEnumTypeLiteral
LST-100

Do behaviours of a state are not allowed.

Guidance: If there is a need identified that an ongoing do behaviour shall be performed while in a state, the overall behaviour shall be evalutated regarding scope and splitting. It shall be avoided that two different larger behaviours are nested inside each other.

3.2.11. Logical Rationale

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

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

  • (optional but recommended) function input port + incoming functional exchange → to justify why that input is necessary.
  • logical components → to justify why this logical component was created and if it is the case why multiple principles are grouped.
  • logical function → to justify why the system function was split and the splitting principles which were taken as the basis for the split.
  • (optional) function allocated to logical component → to justify why that function is allocated to this logical component.
LRA-050

If a rationale is expanded by an artefact, e.g. a trade study result 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

3.2.12. REC/RPL

IDRule
LRR-010Logical REC/RPLs should be used to describe/instantiate functions are to be allocated to more than one logical component.
LRR-020

Where there exists the possibility for a function to be carried out by more than one logical component/actor depending on the configuration of the system or a state, the function should be defined once as a replicable element catalogue (REC) without being allocated, then replicas (RPL) of the function should be created and allocated to the respective logical component/actor. These replicas should then have their availability in states/modes set to the correct configuration or other state. 

Rationale: Depending on grades of automation, either an actor or a logical component will carry out a particular function. It shouldn't be possible that two logical components do the same function, though - that is ruled out by the splitting rules for logical components.

Note: It is possible to keep the REC/RPL (or at least some other way) for alternative function allocation; this should begin at system level and go consistently down. Where there exists the possibility for a function to be carried out by more than one logical component/actor depending on the configuration of the system or a state, the function should be defined once as a replicate element catalogue (REC) without being allocated, then replicas (RPL) of the function should be created and allocated to the respective logical component/actor. These replicas should then have their availability in states/modes set to the correct configuration or other state.

LRR-030

The following model elements gets a suffix if they are part of a REC:

  • Functions
  • Functional exchanges

Note: As part of creating a REC the add suffix button needs to be clicked for each of the model elements listed above.

LRR-040

Following naming conventions shall be applied:

  • Name of REC: Same name as the function
  • Suffix for one RPL: Abbreviation of logical component
LRR-050The replicable element (REC) shall not be allocated, only the replicas (RPL) of the function should be allocates to the respective logical component.

3.3. Diagram Types and Viewpoints

3.3.1. General Rules

IDRules
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:

  • CRB - Capability Realisation Blank
  • LDFB - Logical Data Flow Blank

  • LFBD - Logical Function Breakdown

  • LAB - Logical Architecture Blank
  • L.ES - Logical Exchange Scenario (Default in Capella [ES])

  • LDFB - Logical Functional Chain Description

  • L.STM - Logical 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:

  • [LDFB][AMOD-081] SysC1: Set point to position required by operational plan [Logical functional flow definition (single system capability realisation)]
  • [LAB][AMOD-125] System RCA logical component consolidated [Logical architecture definition]
  • [L.ES][AMOD-084] Set point to position required by operational plan [Logical exchange scenario definition]
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.

3.3.2. Logical Capability Realisation Blank (CRB)

3.3.2.1.  General rules 

LCRB-010

At least one capability realisation is visible on the diagram

Guidance (CRB): Show a subset of the capability realisations that focus on a given aspect of the system, consistent with the partitioning of MCBs that was done at system level

LCRB-020At least one logical actor (external to the system) is visible on the diagram
LCRB-030

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

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

LCRB-040

The set of relationships between capability realisations is logically consistent.

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

3.3.2.2.  AMOD-147 Logical capability realisation 

147-004At least one original capability realisation is visible on the diagram
147-006Zero or more refined capability realisations are visible on the diagram
147-010

A refined capability realisation may have include or extend relationships to an original capability realisation in either direction

Guidance: usually, we would expect that a refined capability realisation would extend an original, or that an original would include a refined, but other arrangements are allowed if needed

147-020A refined capability realisation may be generalised by an original capability realisation but the converse is not permitted.
147-030

All original capability realisations must have a trace to the corresponding system capability.

Guidance: this would not be visible on the diagram, but is visible when viewing the properties of the capability realisation (the property "Realised system capabilities" should not be blank).

3.3.3. Logical Architecture Blank (LAB) 

3.3.3.1. AMOD-125 Logical architecture definition

125-010

All functional exchanges that cross the system boundary are allocated to a component exchange.

125-020All visible functions are primitive/leaf-level (i.e. not further decomposed elsewhere in the model)
125-030

All leaf-level functions are visible (that is, there are no leaf-level functions left hidden in the model)

125-040

There exist at least one diagram per realised capability:

  • Showing all logical component which are part of a realised capability and all functions allocated to this logical component, the allocations of functional exchanges to component exchanges for functional exchanges crossing the border of the logical component.
  • The filter ‘Hide Functional Exchanges’ and ‘Show Exchange Items on Component Exchanges’ is activated
125-060

There one diagram that shows all logical componets, allocated functions and optional the component exchanges.

The free text for the diagrams name shall include:

"<<system name>> logical component consolidated 1"

Where:

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

The filter ‘Hide Functional Exchanges’ and 'Collapse Functional Ports' and 'Hide port allocation' are activated.

Optional the filter ‘Hide Component Exchanges’ and 'Collapse Component Exchanges' are activated.

125-070

There exists one diagram that shows all logical componets and component exchanges.

The free text for the diagrams name shall include:

"<<system name>> logical component consolidated 2"

Where:

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

The filter ‘Hide Functional Exchanges’ and ‘Hide Functions" is activated

125-080

There one diagram that shows all logical componets, component exchanges, allocated functions, functional port allocation.

The free text for the diagrams name shall include:

"<<system name>> logical component consolidated 3"

Where:

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

The filter ‘Hide Functional Exchanges’ is activated.

3.3.4. Logical Dataflow Blank (LDFB)

3.3.4.1. General Rules 

LDFB-010

The general direction of functional exchanges is directed either

left to right

or

top to bottom

LDFB-020

The direction of functional exchanges that form feedback loops is either

right to left

or

bottom to top

LDFB-040Where there exists some hierarchy of functions, the owning function is shown on the diagram, with the owned function nested inside it.
LDFB-050The diagram filters are set to display exchange items on functional exchanges, if they exist.


3.3.4.2. AMOD-081 Logical functional flow definition (single system capability realisation) 

IDRuled
081-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.

081-030The diagram (or set of diagrams if 081-010 Q2) displays all functions AND functional exchanges involved in the fulfilment of the owning capability, including functions allocated to actors.
081-040A behaviour definition for a logical function (which is not state-based and not modelled with a state machine (L.STM)) is modelled with a constraint which is attached to the corresponding logical function.
081-050

A behaviour definition for a logical function is textual and is conforming to the rules of the chosen modelling language.

3.3.4.3. AMOD-088 Consolidated logical functional flow definition 

IDRules
088-010General rule: there exists one diagram that shows all logical functions and their functional exchanges.
088-020

The free text for the diagrams name shall include:

"<system name> logical functions consolidated"

Where:

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

088-030For functional exchanges on the diagram the associated exchange items shall be displayed, instead of the name of the functional exchange.

3.3.5. Logical Exchange Scenario (L.ES)

3.3.5.1. General Rules

LES-010

The diagram comprises all direct involved actor and logical component life lines.

LES-031

Only the following combined fragments are permitted to be used in L.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.

LES-040If 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.
LES-041Where PAR fragments are used, at least two operands are required.
LES-050Optional functional exchanges("if-" functional exchanges that take place under certain conditions, with no alternative) are modelled using the OPT fragment.
LES-060

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

LES-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 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.

LES-070

See note against LES-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.

LES-080

See note against LES-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.

LES-090

See note against LES-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)

LES-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.

LES-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).

LES-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).

LES-100

The 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.

LES-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.
LES-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".

LES-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)
LES-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

LES-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.

LES-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)

LES-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.

3.3.5.2. Guidance

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

3.3.5.3. AMOD-084 Logical exchange scenario definition

084-010

After completion of ARCH.086, and where there remains a question over which logical component will generate or consume a functional exchange, the diagram shows all alternative routes for the functional exchanges without a logical fragment.

084-040Internal exchanges between function pairs shall not be sown on the diagram. Internal exchanges are functional exchanges between functions that are both allocated to the same logical component or actor.

3.3.6. Functional Chain Description (LFCD)

3.3.6.1. General Guidance

  • The green blocks displayed on an LFCD are Logical Function Involvements, not Logical Functions themselves. They can only be created to represent Logical Functions that already exist, so it is useful to have an LDFB (AMOD-081) open where you can create new Logical Functions and Functional Exchanges if you need them. When they are deleted, they do not delete the Logical Function they represent.
  • Relationships between capabilities will be defined in CC diagrams on the system level. Include, Extend and Generalization relationships can be defined.
  • If possible, eliminate usage of swim lane text boxes. The functional chain viewpoint exists to show sequential order of functions without considering allocation of the functions. Other views in Capella (ES, LAB) exist to show the allocation of functions. If allocation has to be shown, then a textbox can be used next to the concerned function.
  • 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.

3.3.6.2. General Rules

LFCD-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.

LFCD-110There exists at least one navigable path of sequence links from the beginning of the functional chain to end of the functional chain.
LFCD-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)

3.3.6.3. Start and End Conditions

IDRule
LFCD-130

The start and end conditions of the owning Realised Capability are displayed on the LFCD 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 Realised 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.

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

IDRule
LFCD-001A Logical Function Involvement shall only have a maximum of one incoming sequence link.
LFCD-002A Logical Function involvement shall only have a maximum of one outgoing sequence link.
LFCD-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.
LFCD-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 LFCD-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)
LFCD-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.

3.3.6.5. Instantiation of Functions

LFCD-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.
LFCD-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.
LFCD-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

3.3.6.6. Included Functional Chains

LFCD-060Where a functional exchange exists between two functions AND the function is relevant to this functional chain the functional chain is displayed on the LFCD. 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.
LFCD-070

Where a functional chain includes another functional chain in its entirety

the included functional chain is displayed on the LFCD 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.

LFCD-080

The view must comply with LFCD-080 INCLUSIVE OR LFCD-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

LFCD-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

3.3.6.7. AMOD-082 Logical functional chain definition

IDRule
082-010

Where a functional chain represents the entirety of a capability realisation, the start and end conditions of the owning capability realisation are displayed on the diagram.

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

3.3.7. Logical State Machine (L.STM)

3.3.7.1. General rules

IDrule
LSTM-010There exists a single Initial state.
LSTM-020There exists at least one transition outgoing from each state (except for the Final state).
LSTM-030There exists at least one transition incoming to each state (except for the Initial state).
LSTM-040There exists at least one navigable path along transitions from the Initial state to the Final state, if a final state is defined.
LSTM-040

There exists at least one simple state or at least one composite state.

Guidance: An comparison to simple states, composite states are nesting other simple states or composite states in sequential or parallel/concurrent manner. They can be used handle to complexity of hierarchical state structures.

LSTM-050

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

  • Event definition, by referring to change events of exchange item element values (data objects) via functional exchanges, with (optionally) guard conditions to qualify the trigger of the transition which reacts to these change events (preferred)
  • Guard condition describing the event (non-preferred, for use where the events are not readily identifiable)
LSTM-060

An action of a transition is defined as follows:

<action expression>

The action expression is textual and consists of one or more atomic assignment statements. It is conforming to the rules of the chosen modelling language.

Guidance: Try to limit the number of statements inside the action expression to keep and increase readibility of the state machine diagram (approx. a maximum number of five statements per action). In addition, avoid conditional statements (e.g. if-else) inside the action expression. Instead use choice states or guard conditions to express condtional outcomes.

LSTM-070

A change event of a transition is defined as follows:

when (<boolean expression>)

The boolean expression is textual and is conforming to the rules of the chosen modelling language.

LSTM-080

A guard condition of a transition is defined as follows:

<boolean expression>

The boolean expression is textual and is conforming to the rules of the chosen modelling language.

LSTM-090

The current value of an exchange item element is accessed by using the name of the exchange item element inside an action expression or boolean expression.

Corresponding statements follow the rules of the chosen modelling language.

Guidance: Assignment statements or relational operators in context of a boolean expression can be used to access the current value.

Example: Action with an atomic assignment statement (pseudo modelling language)
OutgoingExchangeItem.ExItemElem = (IncomingExchangeItemA.ExItemElem < 10) And (IncomingExchangeItemB.ExItemElem != 1)
LSTM-100

A new value of an exchange item element is set by using the name of the exchange item element inside an action expression.

Corresponding statements follow the rules of the chosen modelling language.

Guidance: Assignment statements can be used to set the new value.

Example: Action with two atomic assignment statements (pseudo modelling language)
OutgoingExchangeItemA.ExItemElem1 = 10
OutgoingExchangeItemB.ExItemElem2 = AnEnumTypeLiteral

3.3.7.2. AMOD-083 State-based behaviour definition (logical function)

IDrule
083-010

The set of states on the view gives complete coverage of the statefulness of the owning logical function.

083-020

Where the logical function considers and covers 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 (also called complex or composite state) rather than a faithfully-rendered model of many distinct states.

083-030Where an logical function consider and covers a set of states defined externally (e.g. in existing documentation) then the states are reused, if it is judged to be appropriate, in preference to a completely new definition of the states.

Color legend:

MeaningColor
Naming convention