Legal information

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

1. Modelling Rules for Operational Analysis

1.1. Overall

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

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

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

1.2. Elements

1.2.1. Structure in Operational Analysis

1.2.1.1. Operational Entity Rules

IDRule
OEN-010

Operational entity names and descriptions are consistent with harmonised definitions from collaboration projects (RCA, S2R, OCORA etc.) or with international standards where applicable.

OEN-020

Naming convention:

All operational entities have a name that represents an organisational unit.

Where an operational entity is a type of organisation, the name is generic enough to indicate the type and not to point to individual examples of that organisation (example: "Railway Undertaking (tick)", "DB Regio (error)")

Where an operational entity represents one specific organisation, the name is

specific to that organisation

and

expressed first in English

and

expressed in German if the original name is German

(example: "Federal police (Bundespolizei) (tick)")

OEN-030

Operational entities are divisible.

Any entities or actors that are modelled as parts of this operational entity can be expected to belong to the same organisation.

OEN-040Generalisation between operational entities is not permitted.
OEN-050The description of an operational entity focuses on the features that define it, not on its responsibilities or activities.

1.2.1.2. Operational Actor Rules


IDRule
OAC-010

Operational actor names and descriptions are consistent with harmonised definitions from collaboration projects (RCA, S2R, OCORA etc.) where applicable.

OAC-020

Naming convention:

All operational actors have a name. The name is generic and does not refer to any specific business concern or individual person, although it might describe a role or job type to which an individual belongs.

OAC-030

Operational actors are indivisible.

They are at the level where an individual real person, or an individual system, could realise them. If there is any chance that an operational actor could be subdivided into parts, it should be modelled as an operational entity instead.

OAC-040Generalisation between operational actors is not permitted.
OAC-050The description of an operational actor focuses on the features that define them, not on its responsibilities or activities.

1.2.1.3. Guidance for actors and entities

Generally speaking, Operational Entities should be used for organisations, and Operational Actors should be used for individual job titles or roles.

If you are not sure whether a role belongs to an individual or an organisation, use an Operational Entity but make a note that it might need to be converted to an Operational Actor once we have checked.

1.2.2. Operational Capability

1.2.2.1. Rules

IDRule
OCX-010

Naming convention:

Operational capability names begin with an active verb.

The verb should be specific enough to identify a particular effect that the Digital Railway Operation will have on one or more entities/actors in the environment. Verbs such as "manage", "handle" or "process" are not specific enough and are forbidden.

OCX-020

Operational capabilities have a brief text description that summarises how Digital Railway Operation links the pre-conditions to the post-conditions.

The description should be short and abstract, because the true description of the operational capability will be its operational entity scenario.

OCX-030

Operational capabilities have at least one defined pre-condition and one defined post-condition entered into the corresponding field in Capella.

Guidance:

  • states of entities/actors AND/OR abstract concepts can be used to define the precondition
  • exchange items can be evaluated as well here
OCX-040

Operational capabilities have at least one defined post-condition entered into the corresponding field in Capella.

Guidance:

  • The post-condition describes an observable effect on at least one entity or actor in the environment.
  • states of entities/actors AND/OR abstract concepts can be used to define the post-condition
  • exchange items can be evaluated as well here

1.2.2.2. Guidance

Operational capabilities are a bit like use cases, from the point of view of operational entities in the environment making use of each other.

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

1.2.3. Operational Activity

1.2.3.1. Rules

IDRule
OAV-010

Naming convention:

All operational activity names have the form verb-noun.

OAV-012

Where possible and appropriate, the operational activity should be formed in accordance with the control pattern for operational level (see the Guidance section). 

Note: this rule must be applied with discretion - it is not always appropriate and the pattern should not be applied without first thinking about whether it is really a good idea.

OAV-020

Operational activities are defined with a scope that is what an operational entity or actor is responsible for.

OAV-030

All operational activities have a short text description of the transformation performed by this activity on its inputs to produce the outputs.

1.2.3.2. Guidance

Guidance and method can be found in ARCH.M.010 Method for definition of functionality.Method for definition of operational activities.

1.2.4. Operational Interaction


IDRule
OIN-010

Each interaction has at least one exchange item associated to it. These exchange items define the interaction.

Exception: If no additional content information is added by the data model e.g. level of detail in the operational level, it is ok to not associate any exchange item and give the interaction just a short description.

OIN-020

Naming convention:

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

Note: The name of the interaction is not the definition of the interaction (for the definition refer to OIN-010) 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.

OIN-040

Each interaction has a unique identifier in the format of e.g. O-INT12345. 

Note: The definition of unique identifiers will be done automatically by Capella.

1.2.5. Operational Process

1.2.5.1. Rules

IDRule
OPR-010

There exists for each operational capability two operational processes: one to model the basic business need, and one to model the full business process including control measures for business risk, safety and security

Note: This rule is optional for RCA.

OPR-020

Naming convention:

The operational process for basic business need is named <operational capability name> (bare business process)

The operational process for the full business process is named<operational capability name> (business process with risk control measures)

1.2.6. Operational Exchange Scenario for Operational Capability

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

IDRule
OES-170

There exists for each Operational Capability at least two scenarios: one bare business scenario and one business scenario with risk control measures for business risk, safety and security.

OES-180

Naming convention:

The operational scenario for basic business need is named <capability name>[<X>](bare business scenario).

Where X is the number of the basic business scenario.

The operational scenario for the full business need is named <capability name>[<X.Y>](business scenario with risk control measures).

Where X is the number of the related basic business scenario and

Y is the number of the full business scenario.

OES-190

Note: An Exchange Scenario mays 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
OES-191Each Exchange Scenario has a description that gives detail on the individual nature (that is, what differentiates this scenario from other scenarios, such as an change event that occurs part-way through the scenario.

1.2.7. Operational State


IDRule
OST-010

Naming convention:

State names contain either

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

or

verbs in the present participle form (-ing)

or

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

Naming convention for states: Sentence case - the first letter of the first word in a sentence is capitalised, expect words like commonly known abbreviations or standardised terms which have own (externally-defined) naming conventions.

OST-020

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

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

OST-030States are used where the transitions are triggered by changes of external or internal conditions not directly under the control of the owning entity/actor.
OST-040

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.

1.2.8. Operational Rationale

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

Basically, all model elements can be justified by a rationale if useful.

If a rational for a design decision was created is should have the follwing template at the beginning if the text:

TEMP_XX_YYY (pending a proper numbering convention) (XX is the owner initials, YYY is a serial number, start from 001)

ORA-050

If a rationale is expanded by an 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

1.3. Diagram Types and Viewpoints

1.3.1. Generel Rules

IDRule
GRV-010

Each diagram shall be named according to following convention:

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

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


  • OCB - Operational Capabilities Blank
  • COC - Contextual Capability

  • OAIB - Operational Activity Interaction Blank

  • OPD - Operational Process Description

  • OAB - Operational Architecture Blank
  • OES - Operational Exchange Scenario

  • O.STM - Operational State Machine (Default in Capella [MSN])

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:

  • [OPD][AMOD-029] Perform passenger exchange [Operational bare business process]
  • [COC][AMOD-137] Perform passenger exchange [Single operational capability context]
  • [OCB][AMOD-021] Tactical railway operations (regular situations) [Operational capabilities 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.

1.3.2. Operational architecture (OAB)

1.3.2.1. General Rules


Most of the modelling rules for OAB diagrams are dependent on the specific view being constructed, because of the wide variability of content allowed on this viewpoint.

IDRule
OAB-001

At least one operational entity or operational actor is shown on the diagram.

1.3.2.2. AMOD-022 Enterprise & environment definition


IDRule
022-010

All identified operational entities and actors are shown.

022-020

Operational entities representing the wider system of interest, the environment and the wider environment are shown nested in one another according to the Flood & Carson model.

022-030

Operational actors and entities are shown nested in the wider system of interest if they are directly part of an organisation that has railway operation (Railway Operation).

022-040Operational actors and entities are shown nested in the environment if they have a direct interaction with the Railway Operation.
022-050Operational actors and entities are shown nested in the wider environment if they have indirect interactions with Railway Operation, are influenced by Railway Operation, or have influence on Railway Operation.
022-060Operational actors and entities that are parts of larger entities are shown nested inside the appropriate entity.
022-070Operational activities are not shown on this view.

1.3.2.3. AMOD-024 Operational activity definition and allocation

IDRule
024-010

Operational entities or actors are shown on this diagram only where at least one operational activity is allocated to them.

024-020

Where the exact allocation of an operational activity is uncertain, the activity is allocated to the entity at the next level up.

Guidance: all possible operational activities must take place within some boundary, since we have defined a boundary for the wider environment. It is fine to allocate at a higher level at this point in the process. Specific allocation can be done later.

1.3.3. Operational Capabilities Blank (OCB) and Contextual Operational Capability (COC)

1.3.3.1. General Rules

IDRule
OCB-040The set of relationships between capabilities is logically consistent.
OCB-050An operational capability may be generalised to no more than one superior/higher-level operational capability.
OCB-060

An operational capability may include any number of operational capabilities, if the included capability:

delivers by itself an observable effect to at least one actor/entity in the environment;

AND

might occur by itself, independently of the including operational capability

inclusive OR

is included by two or more including capabilities

OCB-070

An operational capability may extend any number of operational capabilities, if the extending capability:

occurs as an extension during the course of the extended capability's delivery

AND

delivers by itself an observable effect to at least one actor/entity in the environment that is not an effect of the regular delivery of the extended capability

1.3.3.2. AMOD-021 Operational capabilities definition

IDRule
021-010

All identified operational capabilities are shown on the diagram.

021-020

All identified relationships between operational capabilities are shown on the diagram.

021-030Each capability has an involvement relationship to at least one actor or entity in the environment, except where a capability is included by other capabilities (in which case, a direct involvement with an actor is not necessary, but is allowed).

1.3.3.3. AMOD-137 Single operational capability context 

IDRule
137-010

For the operational capability in focus, all actor/entity involvement relationships are shown.

137-020

For the operational capability in focus, all relationships to other operational capabilities are shown.

1.3.4. Operational Activity Interaction Blank (OAIB)

1.3.4.1. General Rules

IDRule
OAIB-010

The general direction of interactions is directed either

left to right

or

top to bottom

OAIB-020

The direction of interactions that form feedback loops is either

right to left

or

bottom to top

OAIB-030Where an operational activity is modelled because it already exists (e.g. it represents part of predecessors current processes, or because it is in a regulation) then a Requirement object is created with the metadata from the source, and the operational activity is traced to the requirement.
OAIB-040Where there exists some hierarchy of activities, the owning activity is shown on the diagram, with the owned activity nested inside it.
OAIB-050

Interactions are shown on the diagram as follows:

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

1.3.4.2. AMOD-028 Operational activities and interaction definitions (single operational capability)

Create an OAIB per OC, to define activities, interactions and traces to requirements

If more than one OAIB (for size control) then suffix 1, 2, 3....

IDRule
028-010

General rule: there exists one diagram per operational capability (The OAIB diagram should be created directly under the respective OC);

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

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

028-030The diagram (or set of diagrams if 028-010 Q2) displays all operational activities AND interactions involved in the fulfilment of the owning capability, including operational activities allocated to actors/entities outside the WSOI.
028-040

Where more than one capability uses the same diagram, both operational processes (bare business) should be displayed, so that it is visible which capabilities are shared by the processes and which are not.

Qualification 1: this might be when 028-010 is the case

Qualification 2: this might be when OPD-070, OPD-080, OPD-090 is the case

1.3.4.3. AMOD-101 Consolidated operational activities & interactions

IDRule
101-010

All identified operational activities are displayed on this view.

101-020All identified operational interactions are displayed on this view.
101-030Operational activities are arranged broadly so that the activity flow on the diagram is simplified (that is, as far as practicable, that most interactions flow either left to right, or top to bottom).
101-040Where a hierarchy of activities exists, the nesting of operational activities is shown on the diagram.

1.3.5. Operational Process Description (OPD)

1.3.5.1. General Guidance

  • The yellow blocks displayed on an OPD are Function Involvements, not operational activities themselves. They can only be created to represent operational activities that already exist, so it is useful to have an OAIB open where you can create new operational activities and interactions if you need them. When they are deleted, they do not delete the operational activities they represent.
  • 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 involvement means that when the chain of sequence links reaches this particular involvement, the output value of this function has changed.

1.3.5.2. General Rules

IDRule
OPD-001

There exists no activity of interest involvement that is unconnected to the rest of the operational process by a sequence link.

A operational activity of interest is a activities whose execution happens wholly within the timeframe of this operational process and is inextricably bound up in the execution sequence of this operational process. In contrast, an information-providing operational activity is one that (in the context of THIS operational process) 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 operational process.

OPD-100There exists at least one navigable path of sequence links from the beginning of the operational process to end of the operational process.
OPD-110

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

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

1.3.5.3. Start and End Condition

IDRule
OPD-005

The start and end conditions of the owning Operational Capability are displayed on the OPD 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 operational process can have different end conditions. A capability should contain all relevant conditions for all of the operational process 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 Operational 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 operational process which are displayed collapsed will not appear on the diagram.

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

IDRule
OPD-008An involvement shall only have a maximum of one incoming sequence link.
OPD-009An involvement shall only have a maximum of one outgoing sequence link.
OPD-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 possiblities without logical gaps.

OPD-011When an OR node is used as a SysML decision node (see OPD-010), the OR node should always be preceded by an Operational Activity
OPD-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 OPD-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)

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

1.3.5.5. Instantiation of Activities

IDRule
OPD-040Where the same operational activity occurs more than once within an operational process in different contexts, this is modelled with two or more separate Operational Activity Involvements, placed in a logically consistent position in the process
OPD-050

Where the same operational activity or sequence of operational activities occurs more than once within an operational process

OR

Where the execution logic of the process requires a return loop from a later activity to an earlier activity

this is modelled using the IT construct to create a loop

1.3.5.6. Included Operational Process

IDRule
OPD-060

Where an Interaction exists between two operational activities AND the Interaction is relevant to this operational process the interaction is displayed on the OPD. Operational process of interest (needed to arrive at the postcondition) will be included or extended, and will be displayed minimized. The included or extended operational process should be connected to the operational process of interest using sequence links.

OPD-070

Where an operational process includes another operational process in its entirety the included operational process is displayed on the OPD for the including operational process as a separate reference block (that is, the included operational process steps are not redefined)

Note: This imply that there is an include or extent relationship between the respective owning capabilities.

OPD-080

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

Where an operational process includes another operational process in its entirety

there exists at least one sequence link from an operational activity involvement outside the included operational process to an operational activity involvement inside the included operational process

AND

there exists at least one interaction involvement from an operational activity involvement outside the included operational process to an operational activity involvement inside the included operational process

OPD-090

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

Where an Operational Process includes another Operational Process in its entirety

there exists at least one sequence link from an operational activity involvement inside the included operational process to an operational activity involvement outside the included operational process

AND

there exists at least one interaction involvement from an operational activity involvement inside the included operational process to an operational activity involvement outside the included operational process

OPD-091There exists at least one navigable path of sequence links from the beginning of the process to end of the process.
OPD-092

There exists no operational activity involvement that is unconnected to the rest of the process by a sequence link.

Exception: where an operational activity represents a persistent source of information that is drawn upon at discrete points in the process, a sequence link is not needed.

1.3.5.7. AMOD-029 Operational bare business process

IDRule
029-010

The diagram shows only the bare business activities of interest and interactions necessary to reach the end conditions of the capability, without measures to mitigate safety, security, or service quality risks.

1.3.5.8. AMOD-035 Operational business process with risk control measures

IDRule
035-010

The diagram shows all activities of intrest and interactions necessary to reach the end conditions of the capability, including measures introduced to mitigate safety, security, or service quality risks.

1.3.6. Operational Entity Scenario (OES)

1.3.6.1. General Rules

IDRule
OES-010

The diagram comprises all involved operational entities or actor lifelines.

OES-030

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

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

Where PAR fragments are used, at least two operands are required. 

OES-050Optional interactions ("if-" functional exchanges that take place under certain conditions, with no alternative) are modelled using the OPT fragment.
OES-060Where OPT fragments are used, OPT fragments have a defined guard condition describing the logical condition under which the functional exchange takes place.
OES-061

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

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

OES-070

See note against OES-030

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

OES-080

See note against OES-030

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.

OES-081

See note against OES-030

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)

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

OES-993

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

OES-994

When one capability extends 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).

OES-100The diagram contains at least one complete sequence of interactions (output of activity of interest) that is navigable from the start conditions to the end conditions.
OES-090

Each interaction is preceded by an "allocated operational activity" graphical item showing the operational activity that generates the interaction.

Note: the intended meaning is that, at this point of the sequence, the activities output changes, in line with changes to its inputs; it is NOT intended to indicate that the activity is "called" or "invoked"; the activity is assumed to be "always-on" or at least "always-on in a particular entity state".

OES-105The execution element of an incoming interaction is as long as the duration in which the outputs of activities can change within a lifeline. This means as long as new interactions with a changed value to another lifeline are happening depicted on the diagram.
OES-110

All activities of interest (activities that are part of the sequence path in the respective process) are shown as graphical representations (allocated function) on the diagram:

  • activities are placed on the execution element of a lifeline for incoming interactions
  • preceding incoming interactions and outgoing interactions (only when the representation of the interaction has added value for the reader of the diagram)

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

OES-120

Interactions are shown on the diagram:

  • Names of interactions are not shown on the diagram (Hide by filter)
  • Allocated exchange items are shown on the diagram (Shown by filter)
  • Show the interactions between the entities (only interactions between activities of interest that are part of the sequence path)
  • Internal interactions within an entity are not shown
OES-120

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 OES 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 OES specific postconditions

OES-121

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.

OES-160

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


Note: at Operational level, the transition of the state machine does not need to match the interaction of the sequence diagram

OES-170

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.

1.3.6.2. General Guidance

  • Where possible, guard conditions should be expressed in terms of the states of entities, actors or abstract concepts.
  • State changes of entities/actors should be visualised on the lifelines using the provided tool, to aid understanding; this is not mandatory but is helpful to the reader.
  • Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios

1.3.6.3. AMOD-027 Operational bare business scenario

IDRule
027-010

The diagram shows only the basic business interactions needed to reach the end conditions, without consideration of safety, security or business robustness.

1.3.6.4. AMOD-033 Operational business scenario with risk control measures

IDRule
033-010

The diagram shows the interactions needed to reach the end conditions including interactions for mitigating safety, security and business risks.

1.3.7. Operational States (MSM)

1.3.7.1. General Rules

IDRule
OSM-030There exists at least one transition outgoing from each state (except for the Final state)
OSM-040There exists at least one transition incoming to each state (except for the Initial state)
OSM-050There exists at least one navigable path along transitions.
OSM-060

This rule only apply to state machines of entities/actors:

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

  • Trigger definition, by referring to operational interactions/activities, with (optionally) guard conditions to qualify the trigger (preferred)
  • Guard condition describing the trigger (non-preferred, for use where the triggers are not readily identifiable, especially for more abstract state machines)

1.3.7.2. General Guidance

  • The preferred method of transition conditions can only be used where a triggering activity (or the activity that generates a triggering interaction) is allocated inside the operational entity that owns the state machine. This means that state machines constructed on classes may not be able to use this method for identifying triggers, since an operational activity cannot be allocated to a class.

1.3.7.3. AMOD-023 Operational entity/actor states

IDRule
023-010

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

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

023-020

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

Guidance: this is a time/effort-saving measure to focus energy on those states and transitions that are important to Railway Operation.

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

1.3.7.4. AMOD-012 System lifecycle model


IDRule
012-010

The set of lifecycle states covers all known variations of lifecycle for system of intrest.

012-020Where practical, the lifecycle states are named according to lifecycle phases (or collections thereof) from ISO 15288
012-030The transitions between states define the operational processes that must be completed in order for the system to change state.

1.3.7.5. AMOD-034 Abstract concept states

IDRule
034-010Transition event, guard condition and effect are written in plain text.

Color legend :

MeaningColor
Naming convention