Legal information

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

4. Modelling Rules for Physical Architecture

4.1. Overall

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

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

PA-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 and terms, which serve solely as a form of documenting information external to the project, shall be excluded from this rule.

4.2. Elements

4.2.1. Physical capability realisation 

PCR-010

Naming convention :

An original capability realisation (see viewpoint definition AMOD-148) has the same name, description, relationships, precondition and post-conditions as the logical capability realisation it represents.

Guidance

Physical capability realisations are still capabilities of the whole system, not of individual subsystems. Abstraction level shifts from system-of-systems to system and from system to subsystem capabilities are not done within one Capella model, rather by deriving a new model. Consult the lead system architect or methodology team if unsure.

refined capability realisation (see viewpoint definition AMOD-148) has its name derived from the original physical 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.192 for details, consult the lead system architect or methodology team if unsure.

PCR-030

refined physical capability realisation (see viewpoint definition AMOD-148) has its description, pre- and post-conditions derived from those of the original physical 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.192 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>".

4.2.2. Physical Function

Guidance ARCH.M.010 Method for definition of functionality

RCAMT-293 - Getting issue details... STATUS

4.2.2.1. General rules

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

PFU-110

Physical function descriptions may contain further capitalised words if they represent terms, actors, or other model elements defined in the current model. These elements should then be linked in the function description.

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

4.2.2.2. Function allocated to interface layer component

IDRule
PFU-200

Naming convention:

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

Strong recommendation

The verb should not follow the ones for the control loop pattern, but instead should focus on verbs which underlines synchronisation relationships of the interface layer (e.g. technical term). 

    • list of recommended verbs (with role in the sense of producing information): Authorise, Transmit, Send, Generate, Publish, Request, Encode, Produce
    • list of recommended verbs (with role in the sense of consuming information): Replicate, Duplicate, Repeat, Respond, Subscribe, Follow, Decode, Consume
    • list of recommended verbs (with undefined role): Synchronise, Handle, Manage, Convert, Decide, Collect
PFU-210

The definition of the interface layer functions shall follow the master-mimic pattern,

Guidance: Method for definition of subsystem interfaces

4.2.3. Functional Exchange 

RCAMT-294 - Getting issue details... STATUS

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

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

PFE-130

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

PFE-140All functional exchanges have to be allocated to intended corresponding component exchange.

4.2.4. Physical Component 

4.2.4.1. Node Physical Components (physical components for subsystems created on physical level)

IDRule
PCM-110

Naming convention :

A node physical component respresents a subsystem have been named in accordance with the pattern:

Subsystem <subsystem name> <abbreviation of subsystem name>

PCM-120

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

Where a physical link supports component exchanges in both directions, the component port has direction INOUT

exclusive or

Where a physical link supports only incoming component exchanges, the component port has direction IN

exclusive or

Where a physical link supports only outgoing component exchanges, the component port has direction OUT

4.2.4.2. Behaviour Physical Components (logical component derived from logical level)

IDRule
PCM-200

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).
PCM-210

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

PCM-220

Each behaviour physical 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 <component name> component <summary of the type of functionality grouped into this 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 architecture layer 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)

4.2.4.3. Behaviour Physical Components (interface layer component created on physical level)

IDRule
PCM-230

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. technical term).
    • list of recommended nouns (with clear role in the sense of a information producer): Authoriser, Transmitter, Sender, Generator, Publisher, Requester, Encoder, Producer
    • list of recommended nouns (with clear role in the sense of a information consumer): Replicator, Duplicator, Repeater, Responder, Subscriber, Follower, Decoder, Consumer
    • list of recommended nouns (with unclear role and additional role prefix): <Master | Primary | Secondary | Slave | Mimic> Synchroniser, Handler, Endpoint, Manager, Converter, Collector, Decider, Instance, Entity, Layer
  • 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).
  • If the component is considered as a REC/RPL the corresponding naming conventions shall be applied as well.

Example:

  • to be added at a later stage
PCM-240

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

PCM-250

Each behaviour physical component has a description.

Guidance:

  • Template:
    • Function summary: The <component name> component <summary of the type of functionality grouped into this 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 interface layer component as distinct from the others.
PCM-260

If an interface layer component together with it's adjacent one on the same interface layer shall be reusable the REC/RPL mechanism is used.

PCM-270

The definition of the interface layer components shall follow the master-mimic pattern,

Guidance: Method for definition of subsystem interfaces

4.2.5. Physical Actor 

IDRule
PAC-010The set of physical actors is identical to the set of system actors.

4.2.6. Physical Component Exchange 

IDrule
PCE-020There exists either zero or one component exchange between any pair of behaviour physical components.
PCE-030

Where a functional exchange crosses a the boundary of the allocating behaviour physical component A

the function port is assigned to a component port on A

and

the assigned component port is connected to a component port on another behaviour physical component B

and

behaviour physical component B hosts the function at the other end of the functional exchange.

Corollary: When functions are re-allocated to other behaviour physical 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.

PCE-040

Naming convention:

This rules applies when component exchanges transfered from logical level:

All component exchanges between two logical components each deployed to a subsystem are named in accordance with the following naming convention (pattern):

I_<abbreviation of subsystem A>_<abbreviation of subsystem B>_Abstract_<unique number starting at 01>

Example: I_FOT_P_Abstract_01

All component exchanges between two logical components each deployed to the same subsystem are named in accordance with the following naming convention (pattern):

C <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, C19

All component exchanges between logical components deployed to subsystems and an external actor are named in accordance with the following naming convention (pattern):

Names according to rules from logical level.

Guidance:

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

Examples:

I_PlanningSystem_Application_01

I_PlanningSystem_Application_02


This rule applies when new component exchanges are created on physical level for interface layer components (1):

All component exchanges between two interface layer components on different interface layers (inter-layer component exchange) deployed to the same subsystem are named in accordance with the following naming convention (pattern):

C_<abbreviation of subsystem><name of interface layer A>_<name of interface layer B>

Examples:

C_FOT_Application_Presentation

This rule applies when new component exchanges are created on physical level for interface layer components (2):

All component exchanges between two interface layer components on the same interface layer (intra-layer component exchange) each deployed to one of the adjacent subsystems are named in accordance with the following naming convention (pattern):

I_<name of interface layer>

Guidance:

The name of the interface layer can be e.g. the name of a protocol, technical specification or another term which provides a useful name of the layer. It can contain optional terms to distuinigish interface layers based on architectural models ot abstraction levels.

Examples:

I_DataCoding

I_HTTP_Application

I_RaSTA_SafeCommunication

I_Ethernet_Physical

This rule applies when new component exchanges are created on physical level not related to subsystem interfaces:

All component exchanges between two logical components each deployed to the same subsystem are named in accordance with the following naming convention (pattern):

C <number>

Examples:

C 03, C 11

4.2.7. Physical 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
PES-010

Naming convention :

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

Where X is the number of the scenario.

PES-020

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

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

4.2.8. Physical Exchange Scenario for Interface Layer

IDRule
PES-040

Naming convention :

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

Where X is the number of the scenario.

PES-050

There may exist an exchange scenario for the Interface Layer.

PES-060

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

4.2.9. Physical Link

IDRule
PLI-010

Naming convention:

A physical link which models an inter-subsystem interface between two physical components is named in accordance with the pattern:

<abbreviation of first subsystem name>_<abbreviation of second subsystem name> : <name of interface>

Examples: 

PAS_SL : SCI-OP

PE_SL : SCI_CMD

FOT_OC-P : SCI_P

PLI-020All component exchanges which cross the border of the physical components that are linked by a physical link are allocated to that physical link.

4.2.10. REC/RPL

IDRule
PRR-010Physical REC/RPLs should be used to describe/instantiate that the same component + allocated functions are to be deployed to more than one subsystem depending on the different subsystem boundaries.
PRR-020

The REC candidates shall always be a component-function pair (including the function and component ports) i.e. a possible component with a function allocated to it.

Note:

  • replication shall be applied on components, subsequently replicating the functions automatically.
  • When component/functional exchanges between RPL elements are to be added and these connections already exist between the corresponding REC elements, then the "Update connections" option shall be used and no new functional/component exchanges shall be created. But do not create RPL instances just for the sake of update connections. 
  • If there are any exchanges (or flow ports) that are needed to be moved to a leaf function or component on physical layer, this needs to be done before instantiating a REC for a component-function pair. This will lower the post processing work for the component and also ensure that logical architecture realisations are retained for the exchanges within the RPL.
PRR-030

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

  • Components
  • 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.

PRR-040

Following naming conventions shall be applied:

  • Name of REC: Same name as the component
  • Suffix for one RPL: Abbreviation of subsystem
  • Name of RPLs for components + allocated functions deployed in subsystems:  <Name of component/function>.<abbreviation of subsystem name> e.g. Map Data Maintainer.SL
PRR-050The replicable element (REC) shall not be deployed, only the replicas (RPL) of the logical component should be deployed to the respective subsystem.

4.2.11. Physical State

4.2.11.1. State of a Physical State Machine

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

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).
PST-020States have a brief description of the qualities that define this state as distinct from the others.
PST-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.

PST-040An entry action of a state is modelled as a constraint and the constraint is attached to the state.
PST-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 textual notation.

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.

PST-060An exit action of a state is modelled as a constraint and the constraint is attached to the state.
PST-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 textual notation.

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.

4.2.12. Physical Rationale

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

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

  • subsystems → to justify why this subsystem was defined.
  • deployed logical components → to justify why this logical component was deployed to this subsystem.
PRA-050

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

4.2.13. Class

4.2.13.1. Location Kind Element 

ID Rules
LKE-005Location kinds are modelled in Capella as Classes.
LKE-010

Naming convention:

  • Title Case - the first letter of each word is capitalised, words separated by space.
  • Names should be singular
LKE-020The top-level location kind is modelled as an abstract class with a boolean property isIndoor.  When set to FALSE the location kind is exposed to outdoor air and weather conditions e.g. rain, external temperature, humidity, icing, pollution etc. Moreover, it is exposed to other external risks related to human intervention e.g. vandalism.
LKE-030Requirements arising out of standards on environmental conditions must be allocated to one or more location kinds using <<satisfied by>> relationships at the highest applicable level in the  taxonomy, unless a requirement is explicitly applicable to a leaf location kind.
LKE-040

Standards are modelled as requirements organised in packages. Standards must be unambiguously identifiable by name. Therefore its numeric ID, title and release date must be  explicitly modelled as a requirement element.

Note: A model-based representation of all parts of a standard are beyond scope. It is the supplier's obligation to prove the conformance of the tenderable elements they supply to the specified Standards by means of official certification, conformance test results etc.

4.3. Diagram Types and Viewpoints

4.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
  • PDFB - Physical Data Flow Blank

  • PFBD - Physical Function Breakdown

  • PAB - Physical Architecture Blank
  • CSA - Contextual System Actors

  • P.ES - Physical Exchange Scenario (Default in Capella [ES])

  • PFCD - Physical Functional Chain Description

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

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

[PAB][AMOD-100] RaSTA safe communication protocol for the session layer [Interface layer definition]

[PAB][AMOD-143] Interface between Subsystem A and Subsystem B [Inter-subsystem interface 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.

4.3.2. Capability Realisation Blank (CRB) 

4.3.2.1. General rules 

PCRB-010

At least one physical 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

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

The relationship between two physical 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 physical capability realisations)

PCRB-040

The set of relationships between physical 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.)

4.3.2.2. AMOD-148 Subsystem capability realisation 

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

A refined physical capability realisation may have include or extend relationships to an original physical 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

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

All original physical capability realisations must have a trace to the corresponding logical capability realisation.

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

4.3.3. Physical Architecture Blank (PAB)

4.3.3.1. General rules

IDrule
PAB-001

A subsystem is modelled with a node physical component.

PAB-002A logical component is modelled with a behavior physical component.
PAB-003A interface layer component is modelled with a behavior physical component.

4.3.3.2. AMOD-080 Subsystem option sketch

IDRules
080-010This viewpoint is produced as a sketch using any preferred drawing tool.
080-020

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

  • yellow boxes for the subsystems
  • dark blue box for the behaviour compontes (derived from logical component)
  • red box for the behaviour compontes (further split logical component)
  • green box for the functions (derived from logical function)
  • red box for the functions (further split logical function)
  • light blue box for system actors
080-030The viewpoint presents two or more alternative subsystem boundaries alongside each other for comparison.
080-040

For each alternative subsystem boundary, there is displayed at least two subsystems.

080-050

For each alternative subsystem boundary, there is displayed at least two candidate logical components deployed to two subsystems.

080-060Comparing one alternative subsystem boundary with another, there exists at least one difference in the allocation of candidate logical components between the subsystems.
080-065The elements on the viewpoint contain additional info if a logical component/function has been further split on for the subsystem architecture.

4.3.3.3. AMOD-085 Subsystem architecture definition (single realised capability)

IDRules
085-010<free text> is name of the realised capablity.
085-020All involved subsystems, physical actors, logical components and functions are shown.
085-030Physical links are not mandatory to be shown.

4.3.3.4. AMOD-093 Subsystem architecture definition

IDrule
093-010<free text> is "Overall subsystems definition".
093-020

All subsystems, physical actors, and logical components are shown.

093-030Functions of logical components and physical actors are not shown.
093-040Physical links are not mandatory to be shown.

4.3.3.5. AMOD-100 Interface layer definition

IDrule
100-010The functions of the interface layer components are shown.
100-020The functional exchanges between the two interface layer components are shown.
100-030The component exchanges (symbolic ↔ "horizontal") between the two interface layer components are shown.
100-040

For the real component exchanges ("vertical") only the component ports are shown.

100-050Symbolic ↔ "horizonal" and real ↔ "vertical" functional exchanges of an interface layer component are allocated to its corresonding component ports through port allocation.

4.3.3.6. AMOD-143 Inter-subsystem interface definition

IDrule
143-010All functions of all interface layer components are shown.
143-020All interface layer components included in this inter-subsystem interface are shown.
143-030All functional exchanges (symbolic ↔ "horizontal", real ↔ "vertical") between two interface layer components are shown.
143-040All component exchanges (symbolic ↔ "horizontal", real ↔ "vertical") between two interface layer components are shown.
143-050The inter-subsystem interface is modelled and shown as a physical link between the node physical components that model the subsystems.
143-060The symbolic component exchanges of all interface layer components are allocated to the corresponding physical ports through port allocation.

4.3.3.7. AMOD-111 Subsystem interface definition to external system / actor

IDrule
111-010All functions of all interface layer components are shown.
111-020All interface layer components included in this subsystem interface to external system / actor are shown.
111-030All functional exchanges (symbolic ↔ "horizontal", real ↔ "vertical") between two interface layer components are shown.
111-040All component exchanges (symbolic ↔ "horizontal", real ↔ "vertical") between two interface layer components are shown.
111-050The subsystem interface to external system / actor is modelled and shown as a physical link between the node physical components that models the subsystem and the physical actor representing the external system / actor.
111-060The symbolic component exchanges of all interface layer components are allocated to the corresponding physical ports through port allocation.

4.3.4. Physical Exchange Scenario (P.ES)

4.3.4.1. General Rules

IDRule
PES-010

The diagram comprises all needed model element lifelines.

PES-031

Only the following combined fragments are permitted to be used:

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

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

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

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

PES-070

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

PES-080

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 exchange takes place.

PES-090

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)

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

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

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

PES-100The diagram contains at least one complete sequence of exchanges that is navigable from the start conditions to the end conditions.
PES-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 as depicted on the diagram.
PES-110

All functions of interest are shown as graphical representation (allocated function) on the diagram:

  • functions are placed on the execution element of a lifeline for incoming exchanges
  • preceding incoming exchanges and outgoing 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".

PES-120

Exchanges are shown on the diagram:

  • Names of exchanges are not shown on the diagram (Hide by filter)
  • Allocated exchange items are shown on the diagram (Shown by filter)
  • Show the exchanges between the system and the external actors (only exchanges between functions of interest that are part of the sequence path)
  • Internal exchanges within the system of interest or an actor are not shown (e.g. exchanges to the system or actor itself)
PES-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


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


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

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

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

4.3.4.3. AMOD-099 Interface layer exchange scenario

IDRule
099-010Only one interface layer is considered on the scenario.
099-020The lifelines shown in this scenario are the interface layer components of the considered interface layer.
099-030The functions of the interface layer components involved in this scenario are shown on the corresponding lifeline.
099-040Only the symbolic functional exchanges between the two interface layer components are shown.

4.3.5. Physical State Machine (P.STM)

4.3.5.1. General rules

IDRule
PSTM-010There exists only one initial state.
PSTM-020There exists at least one simple state or at least one composite state.
PSTM-030There exists at least one transition outgoing from each state (except for the final state).
PSTM-040There exists at least one transition incoming to each state (except for the initial state).
PSTM-050There exists at least one navigable path along transitions from the initial state to the final state, if a final state is defined.
PSTM-060

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

  • Event definition, by referring to events (e.g. change events of exchange item element values (data objects) via functional exchanges)
  • Guard condition (optionally) to qualify the trigger of the transition which reacts to these events
PSTM-070

An action of a transition 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 notation.

PSTM-080

A signal event of a transition is defined as follows:

<name of exchange item>

The signal event has the same as the exchange item which has the type signal.

PSTM-090

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

PSTM-100

A time event of a transition is defined as follows:

after (<expression of time value>)

The time value is textual and is conforming to the rules of the chosen notation.

PSTM-110

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

4.3.5.2. AMOD-089 Subsystem lifecycle definition 

IDRule
089-010There exists a single state machine diagram showing the whole state machine.
089-020All states and transitions are shown on the diagram.

4.3.6. Class Diagram (P.CDB)

4.3.6.1. AMOD-095 Location kind definitions  

095-010There is a single class diagram in the model showing all candidate location kinds.
095-020The diagram contains a location kinds taxonomy i.e. a tree of generalisations with an abstract class location kind element as root..
095-030Requirements allocated to location kind classes may be fully or selectively shown on the diagram. In case that only a subset of allocated requirements are shown e.g. for readability purposes due to large number of requirements, it shall be explicitly stated in a comment that "requirements shown on the diagram are non-exhaustive.


Color legend:

MeaningColor
Naming convention