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
- 1.2. Elements
- 1.3. Diagram Types and Viewpoints
- 1.3.1. Generel Rules
- 1.3.2. Operational architecture (OAB)
- 1.3.3. Operational Capabilities Blank (OCB) and Contextual Operational Capability (COC)
- 1.3.4. Operational Activity Interaction Blank (OAIB)
- 1.3.5. Operational Process Description (OPD)
- 1.3.5.1. General Guidance
- 1.3.5.2. General Rules
- 1.3.5.3. Start and End Condition
- 1.3.5.4. Logic Nodes (AND, OR) and Sequence Links
- 1.3.5.5. Instantiation of Activities
- 1.3.5.6. Included Operational Process
- 1.3.5.7. AMOD-029 Operational bare business process
- 1.3.5.8. AMOD-035 Operational business process with risk control measures
- 1.3.6. Operational Entity Scenario (OES)
- 1.3.7. Operational States (MSM)
1.1. Overall
ID | Rule |
---|---|
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: |
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
ID | Rule |
---|---|
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 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) |
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-040 | Generalisation between operational entities is not permitted. |
OEN-050 | The 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
ID | Rule |
---|---|
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-040 | Generalisation between operational actors is not permitted. |
OAC-050 | The 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
ID | Rule |
---|---|
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:
|
OCX-040 | Operational capabilities have at least one defined post-condition entered into the corresponding field in Capella. Guidance:
|
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
ID | Rule |
---|---|
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
ID | Rule |
---|---|
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
ID | Rule |
---|---|
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
ID | Rule |
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:
If the pre- and postconditions of the owning capability do not (fully) apply to the Exchange Scenario:
|
OES-191 | Each 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
ID | Rule |
---|---|
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-030 | States 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
ID | Rule |
---|---|
ORA-010 | Rationales should be created using the model element requirement (type rationale). |
ORA-020 | The description for the rationale is inserted in the field "text" in Capella. |
ORA-030 | Each 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
ID | Rule |
---|---|
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:
Viewpoint number: number given to the viewpoint based on ARCH process Subject of view: either a <model element> or <free text>
Guidance:
Viewpoint name: name given to the viewpoint based on ARCH process Examples:
|
GRV-020 | Optional rule: A diagram has a visible note as a short text description consisting of the following three parts:
|
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.
ID | Rule |
---|---|
OAB-001 | At least one operational entity or operational actor is shown on the diagram. |
1.3.2.2. AMOD-022 Enterprise & environment definition
ID | Rule |
---|---|
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-040 | Operational actors and entities are shown nested in the environment if they have a direct interaction with the Railway Operation. |
022-050 | Operational 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-060 | Operational actors and entities that are parts of larger entities are shown nested inside the appropriate entity. |
022-070 | Operational activities are not shown on this view. |
1.3.2.3. AMOD-024 Operational activity definition and allocation
ID | Rule |
---|---|
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
ID | Rule |
---|---|
OCB-040 | The set of relationships between capabilities is logically consistent. |
OCB-050 | An 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
ID | Rule |
---|---|
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-030 | Each 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
ID | Rule |
---|---|
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
ID | Rule |
---|---|
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-030 | Where 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-040 | Where 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:
|
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....
ID | Rule |
---|---|
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-030 | The 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
ID | Rule |
---|---|
101-010 | All identified operational activities are displayed on this view. |
101-020 | All identified operational interactions are displayed on this view. |
101-030 | Operational 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-040 | Where 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
ID | Rule |
---|---|
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-100 | There 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.
|
1.3.5.3. Start and End Condition
ID | Rule |
---|---|
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
ID | Rule |
---|---|
OPD-008 | An involvement shall only have a maximum of one incoming sequence link. |
OPD-009 | An 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:
|
OPD-011 | When 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:
|
OPD-030 | Where two or more branches of the process run in parallel/concurrently:
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
ID | Rule |
---|---|
OPD-040 | Where 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
ID | Rule |
---|---|
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-091 | There 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
ID | Rule |
---|---|
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
ID | Rule |
---|---|
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
ID | Rule |
---|---|
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:
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-040 | If 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-050 | Optional interactions ("if-" functional exchanges that take place under certain conditions, with no alternative) are modelled using the OPT fragment. |
OES-060 | Where 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-100 | The 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-105 | The 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:
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:
|
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:
|
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
ID | Rule |
---|---|
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
ID | Rule |
---|---|
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
ID | Rule |
---|---|
OSM-030 | There exists at least one transition outgoing from each state (except for the Final state) |
OSM-040 | There exists at least one transition incoming to each state (except for the Initial state) |
OSM-050 | There 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:
|
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
ID | Rule |
---|---|
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-030 | Where 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
ID | Rule |
---|---|
012-010 | The set of lifecycle states covers all known variations of lifecycle for system of intrest. |
012-020 | Where practical, the lifecycle states are named according to lifecycle phases (or collections thereof) from ISO 15288 |
012-030 | The 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
ID | Rule |
---|---|
034-010 | Transition event, guard condition and effect are written in plain text. |
Color legend :
Meaning | Color |
---|---|
Naming convention |