Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
3. Modelling Rules for Logical Architecture
- 3.1. Overall
- 3.2. Elements
- 3.2.1. Logical Function
- 3.2.2. Functional Exchange
- 3.2.3. Logical Actor
- 3.2.4. Logical Component
- 3.2.5. Logical Component Exchange
- 3.2.6. Logical Capability Realisation
- 3.2.7. Logical Exchange Scenario for Realised Capability
- 3.2.8. Logical Exchange Scenario for Interface Layer
- 3.2.9. Logical Functional Chain for Realised Capability
- 3.2.10. Logical State
- 3.2.11. Logical Rationale
- 3.2.12. REC/RPL
- 3.3. Diagram Types and Viewpoints
3.1. Overall
ID | Rule |
---|---|
LA-001 | In order to ensure consistency within the project, British English is to be used at all times. Refer to the Cambridge Dictionary for further information. |
LA-002 | Images and/or diagrams that are to be used in the descriptions of Capella model elements shall be created and maintained on the following Confluence page: |
LA-003 | Description Links for model elements shall be used in all model element descriptions. E.g. if a certain description refers to a defined model element, the name of the model element being referred to shall be copied (as a Description Link) and pasted (as a Link) in the corresponding description field. Exception: model elements defined as abstract concepts or terms, which serve solely as a form of documenting information external to the project, shall be excluded from this rule. |
3.2. Elements
3.2.1. Logical Function
3.2.1.1. Guidance
Guidance and method can be found on this page → ARCH.M.010 Method for definition of functionality
3.2.1.2. General Rules
ID | Rule |
---|---|
LF-100 | Naming convention: All function names are written using sentence case capitalisation. The first word in the name of the function will begin with a capital letter and the remaining words will be lower case. |
LF-120 | The usage of abbreviations should be well considered and should only be used in cases where the abbreviation is either standardised (e.g. ETCS, PRM, GoA) or when it improves readability as in the case of known defined abbreviation within the project (e.g. DPS). |
LF-121 | All leaf-level logical functions have been allocated to one of the proposed logical components or one of the actors |
LF-122 | Function Description - describe what the function is for, such that the following boxes can be ticked:
Pattern: This function <verb> .... Note: see also rule LRA-040 |
3.2.1.3. Function Allocated to Logical Component
LFC-130 | Naming convention: All function names have the form verb-noun, where the noun is the object upon which the function operates. The noun or noun expression in the function's name is consistent with the output of the function. |
LFC-132 | For logical functions, the multiplicities shown in the ontology in Method for definition of functions must be complied with. |
LFC-140 | Control system principle Each core logical function should be named and described in such a way that it conforms to one of the categories of control function. A "core" function is a function that is active when the system is in the OPERATIONAL state (or equivalent). All functions are members of one and only one of the following categories:
Taxonomy: The main five ontology elements (control, actuate, indicate, sense and observe), or their specialisations are to be used for naming logical functions. |
LFC-141 | Configuration data When a Control, Observe and Indicate function needs to consume continuously-supplied configuration data, a function named "Maintain <kind of configuration data>", delivers this configuration data. (e.g. Maintain map data, Maintain record of registered vehicles). There should only be one "maintain" function for each distinct type of configuration data at logical level. |
LFC-160 | The logical functions, that was created due to split of a system function needs to be inline with the Method for decomposition of functions. |
3.2.1.4. Function Allocated to Logical Actor
ID | Rule |
---|---|
LAF-010 | Naming convention: Names of functions allocated to logical actors have the form verb-noun Exception: functions of type "plant" may deviate from this rule if it makes the name clearer, for example "train unit mechanical behaviour" could be used to represent the mechanics of a physical train unit's motion. |
LAF-020 | Functions allocated to logical actors are permitted to merge multiple items from the control system pattern, where used; in this case, the name of the logical actor function may contain several verbs (e.g. Sense+observe or Control+actuate). |
LAF-030 | Actor functions are defined wherever some behaviour is expected from an actor in order to reach the end conditions of a system capability |
LAF-040 | Functions allocated to logical actors must be described in a way that show the responsibilities of the actor in a clear manner. |
LAF-050 | Configuration and calibration data When an actor provides new orginal configuration data to the system, an actor function named "Provide <kind of configuration data>", provides this configuration data to a "Maintain <kind of configuration data>" function. (e.g. Provide model of railway topology, Provide record of registered vehicles). When an actor wants to activate a new configuration of the system, an actor function named "Control <kind of configuration data>", produces the required state of configuration data for each "Maintain <kind of configuration data>" function. |
LAF-060 | When an actuation or sensing function needs to be calibrated according to calibration data supplied, an actor function named "Provide <kind of calibration data>", delivers this calibration data. (e.g. Provide wheel diameter). |
3.2.1.5. Interfacing Function
Detailed guidance and explanations can be found in ARCH.M.030 Method for definition of interfaces
ID | Rule |
---|---|
LIF-010 | Naming convention: Each logical interfacing function has an identical name to the corresponding system interfacing function |
LIF-020 | The set of logical interfacing functions is identical to the set of system interfacing functions. |
LIF-030 | Each logical interfacing function has an identical description to the corresponding system interfacing function. |
LIF-040 | Each logical interfacing function traces to one and only one system interfacing function. |
3.2.2. Functional Exchange
LFE-010 | Naming convention: Sentence case - the first letter of the first word in a sentence is capitalised. Note: The name of the functional exchange is not the definition of the interaction (for the definition refer to SFE-140) and will be filtered in diagrams. The name may be freely chosen and should give guidance to the modellers about what is expressed by it. Strong recommendation: Functional exchanges between functions conforming to the pattern could be named using the structure <exchange type> of <state> e.g. Estimated internal state of point position or similar (Estimated position state of point) etc. | |||||||||||||||
LFE-120 | There should only be one functional exchange per direction between two functions *Warning: multiple functional exchanges between the same pair of functions may imply that the functions have not been decomposed to a primitive level - check before allowing multiple functional exchanges. Note: Each functional exchange will automatically be assigned a unique ID upon creation. | |||||||||||||||
LFE-150 | For all exchanges between core system functions (functions that use the control pattern), the following exchange types are permitted; no other exchanges are permitted.
| |||||||||||||||
LFE-160 | WHERE a function outputs more than one separate exchange type, each exchange type exits the function by a separate output port. Note: a single exchange type may be realised by more than one different type of exchange item. At the modeller's discretion, this means that the number of functional exchanges and ports can be reduced, if the exchange items all belong to the same type . For example, for state type "required state of train unit motion", the exchange items "required state of emergency brake", "required state of traction cut-off", "variable traction/braking command", "pseudo-journey profile" and "pseudo-movement authority" can all be categorised and therefore can all legitimately be outputs of the one single function "control the motion state of one train unit". Modelling style may need to be varied here for different particular instances; it is impossible to be absolute about how to apply the rules; when in doubt, consult the lead system architect. | |||||||||||||||
LFE-170 | WHERE a function takes as inputs more than one separate type of state (that is, a completely separate type of functional exchange), each separate type of state enters the function by a separate input port. The note against LFE-160 also applies. | |||||||||||||||
LFE-180 | WHERE a function produces more than one instance of the same type of a functional exchange, all the instances of this type of functional exchange exit the function via the same output port. | |||||||||||||||
LFE-190 | WHERE a function takes more than one instance of the same type of a functional exchange as inputs, all the instances of this type of functional exchange enter the function via the same input port. | |||||||||||||||
LFE-200 | Multiple instances of the same type of functional exchange must have identical names but it is permissible to add a unique suffix to them if this improves the descriptiveness of the model Example:
| |||||||||||||||
LFE-210 | Each instance of a functional exchange of a given type only conveys those exchange items that are used by the sink function. This means that multiple instances of the same type of functional exchange are allowed to carry different sets of exchange items, provided that all the exchange items are legitimate for that functional exchange type (see note against SFE-160). |
3.2.3. Logical Actor
LAC-010 | Naming convention: Each logical actor has an identical name to the corresponding system actor. |
LAC-020 | The set of logical actors is identical to the set of system actors. |
LAC-030 | Each logical actor has an identical description to the corresponding system actor. |
LAC-040 | Each logical actor traces to one and only one system actor via the "realised actors" relationship. |
3.2.4. Logical Component
LCM-010 | Naming convention:
Exception for logical components allocating interfacing functions:
Logical component name: <System> - <ActorName> Interface Endpoint |
LCM-020 | Logical component ports have direction consistent with the functional exchanges they support - this means either Where a component exchange supports functional exchanges in both directions, the component port has direction INOUT exclusive or Where a component exchange supports only incoming functional exchanges, the component port has direction IN exclusive or Where a component exchange supports only outgoing functional exchanges, the component port has direction OUT |
LCM-030 | Each logical component has a description. Where an abstract concept is mentioned in the description of a logical component, this is done using a hyperlink to the abstract concept, rather than plain text. Guidance:
|
LCM-040 | Based on the defined splitting principle for functions, there should never exist two or more logical components that have the same combination of splitting principle values; each logical component should have a unique combination of values. |
3.2.5. Logical Component Exchange
LAB-112 | Naming convention: All component exchanges between logical components and an external actor crossing the system boundary are named in accordance with the following naming convention (pattern):
Guidance: logical component exchange name = I_ / HMI_ ActorName>_<unique number starting at 01>_<InterfaceLayerName> Examples: I_PlanningSystem_01_Application I_PlanningSystem_02_Application |
LAB-113 | Where a functional exchange crosses a the boundary of the allocating logical component A the functional exchange is assigned to the logical component exchange and the function port is assigned to a logical component port on A (automaticly done by capella when functional exchange is assigned to component exchange) and the assigned logical component port is connected to a logical component port on another logical component B and logical component B hosts the function at the other end of the functional exchange Corollary: When functions are re-allocated to other logical components, function port allocations to component ports must be revisited to ensure all three conditions above are still met. The tool will not always stop the user from leaving an invalid port allocation after moving a function. |
LAB-205 | All component exchanges between logical components inside the system boundary are named in accordance with the following naming convention (pattern): C <unique number> Note: The standard mechnism of Capella is used which provides an automatic generated name and number for the created component exchanges. Example: C 03 C 19 |
LAB-208 | There exists either zero or one component exchange between any pair of logical components |
3.2.6. Logical Capability Realisation
SCR-105 | Naming convention: An original capability realisation (see viewpoint definition AMOD-147) has the same name, description, relationships, precondition and postconditions as the system capability it represents. A refined capability realisation (see viewpoint definition AMOD-147) has its name derived from the original capability realisation, and its number has an additional decimal enumeration. Example: Original capability realisation is called <M> Deliver value <x> Refined capability realisations are called <M.1> Deliver value <x> to actor <P>, <M.2> Deliver value <x> to actor <Q>... These are just examples; it is possible to split/refine a capability for other reasons than because the value is delivered independently to different actors - see ARCH.191 for details, consult the lead system architect or methodology team if unsure. |
SCR-110 | A refined capability realisation (see viewpoint definition AMOD-147) has its description, pre- and post-conditions derived from those of the original capability realisation that it refines. In other words, these metadata should be broadly identical to the original capability realisation, except for those parts that make this refined capability realisation distinct from the other refined capability realisations. Example: Original capability realisation <M> had end condition "Value <x> has been delivered to actor <P> OR to actor <Q>" after logical analysis according to ARCH.191 it emerges that the capability can be split into two with the value delivered independently to P or Q; in that case: Refined capability realisation <M.1> has end condition "Value <x> has been delivered to actor <P>" and <M.2> has end condition "Value <x> has been delivered to actor <Q>". |
3.2.7. Logical Exchange Scenario for Realised Capability
Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios
ID | Rule |
LSC-010 | Naming convention: The exchange scenario for the realised capability is named <capability name>[<X>]. Where X is the number of the scenario. |
LSC-020 | There exists for each realised Capability at least one scenario. Further scenarios are optional. |
LSC-030 | Note: An Exchange Scenario may represent either a more specific and detailed course of the main success scenario OR a deviation from the main success scenario (e.g. due to incidents). Therefore the pre- and postconditions of the Capability may apply to the Exchange Scenario or not. If the pre- and postconditions of the owning capability fully apply to the Exchange Scenario:
If the pre- and postconditions of the owning capability do not (fully) apply to the Exchange Scenario:
|
3.2.8. Logical Exchange Scenario for Interface Layer
ID | Rule |
LSC-040 | Naming convention: The exchange scenario for the interface layer is named <interface layer name>[<X>]. Where X is the number of the scenario. |
LSC-050 | There may exist an exchange scenario for the Interface Layer. |
LSC-060 | Note: An Exchange Scenario may represent either a more specific and detailed course of the main success scenario OR a deviation from the main success scenario (e.g. due to incidents). Therefore the pre- and postconditions of the Capability may apply to the Exchange Scenario or not. If the pre- and postconditions of the owning capability fully apply to the Exchange Scenario:
If the pre- and postconditions of the owning capability do not (fully) apply to the Exchange Scenario:
|
3.2.9. Logical Functional Chain for Realised Capability
LFC-010 | Naming convention: The functional chain shall be named <realised capability name> (logical functional chain) There exists for each realised capability one logical functional chain. |
LFC-020 | There exists for each realised capability one logical functional chain. |
3.2.10. Logical State
ID | rule |
---|---|
LST-010 | Naming convention: Sentence case - the first letter of the first word in a sentence is capitalised. State names are referring to a quality of the considered entity for which owning logical function performs something for or is tied to. State names contain either adjectives (-ed) or verbs in the present participle form (-ing) or verbatim copies of states defined externally to the project (that is, when reusing state definitions from elsewhere, they should be reproduced precisely and not changed) |
LST-020 | States have a brief description of the qualities that define this state as distinct from the others. |
LST-030 | Only states are used in the model. Modes are not used. Rationale: The behaviour of both elements in the model is identical and the difference in definition, arising from ARCADIA methodology, is somewhat philosophical. Methodology circle recommends standardising on using only states throughout. |
LST-040 | An entry action of a state is modelled as a constraint and the constraint is attached to the state. |
LST-050 | The content of an entry action is defined as follows: <action expression> The action expression is textual and consists of one or more atomic statements. It is conforming to the rules of the chosen modelling language. Guidance: Try to limit the number of statements inside the action expression to keep and increase readibility of the state machine diagram (approx. a maximum number of five statements per action). In addition, avoid conditional statements (e.g. if-else) inside the action expression. Instead use choice states or guard conditions to express condtional outcomes. |
LST-060 | An exit action of a state is modelled as a constraint and the constraint is attached to the state. |
LST-070 | The content of an exit action is defined as follows: <action expression> The action expression is textual and consists of one or more atomic statements. It is conforming to the rules of the chosen modelling language. Guidance: Try to limit the number of statements inside the action expression to keep and increase readibility of the state machine diagram (approx. a maximum number of five statements per action). In addition, avoid conditional statements (e.g. if-else) inside the action expression. Instead use choice states or guard conditions to express condtional outcomes. |
LST-080 | The current value of an exchange item element is accessed inside an action expression by using the name of the exchange item element. The corresponding statement follows the rules of the chosen modelling language. Example: Action with an atomic assignment statement (pseudo modelling language) OutgoingExchangeItem.ExItemElem = (IncomingExchangeItemA.ExItemElem < 10) And (IncomingExchangeItemB.ExItemElem != 1) |
LST-090 | A new value of an exchange item element is set inside an action expression by using the name of the exchange item element. The corresponding statement follows the rules of the chosen modelling language. Guidance: Assignment statements can be used to set the new value. Example: Action with two atomic assignment statements (pseudo modelling language) OutgoingExchangeItemA.ExItemElem1 = 10 OutgoingExchangeItemB.ExItemElem2 = AnEnumTypeLiteral |
LST-100 | Do behaviours of a state are not allowed. Guidance: If there is a need identified that an ongoing do behaviour shall be performed while in a state, the overall behaviour shall be evalutated regarding scope and splitting. It shall be avoided that two different larger behaviours are nested inside each other. |
3.2.11. Logical Rationale
ID | Rule |
---|---|
LRA-010 | Rationales should be created using the model element requirement (type rationale). |
LRA-020 | The description for the rationale is inserted in the field "text" in Capella. |
LRA-030 | Each rationale has at least one outgoing link to a target model element using the relation type "justifies". |
LRA-040 | Basically, all model elements can be justified by a rationale. At least the following model elements on logical level should be justified:
|
LRA-050 | If a rationale is expanded by an artefact, e.g. a trade study result or other type of supporting artefact, the rationale text shall include a reference to the expanding artefact, including (where possible) its document number and a hyperlink to the artefact's current version. |
Guidance:
ARCH.M.110 Method for definition of rationales
3.2.12. REC/RPL
ID | Rule |
---|---|
LRR-010 | Logical REC/RPLs should be used to describe/instantiate functions are to be allocated to more than one logical component. |
LRR-020 | Where there exists the possibility for a function to be carried out by more than one logical component/actor depending on the configuration of the system or a state, the function should be defined once as a replicable element catalogue (REC) without being allocated, then replicas (RPL) of the function should be created and allocated to the respective logical component/actor. These replicas should then have their availability in states/modes set to the correct configuration or other state. Rationale: Depending on grades of automation, either an actor or a logical component will carry out a particular function. It shouldn't be possible that two logical components do the same function, though - that is ruled out by the splitting rules for logical components. Note: It is possible to keep the REC/RPL (or at least some other way) for alternative function allocation; this should begin at system level and go consistently down. Where there exists the possibility for a function to be carried out by more than one logical component/actor depending on the configuration of the system or a state, the function should be defined once as a replicate element catalogue (REC) without being allocated, then replicas (RPL) of the function should be created and allocated to the respective logical component/actor. These replicas should then have their availability in states/modes set to the correct configuration or other state. |
LRR-030 | The following model elements gets a suffix if they are part of a REC:
Note: As part of creating a REC the add suffix button needs to be clicked for each of the model elements listed above. |
LRR-040 | Following naming conventions shall be applied:
|
LRR-050 | The replicable element (REC) shall not be allocated, only the replicas (RPL) of the function should be allocates to the respective logical component. |
3.3. Diagram Types and Viewpoints
3.3.1. General Rules
ID | Rules |
---|---|
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. |
3.3.2.
3.3.2.1.
LCRB-010 | At least one capability realisation is visible on the diagram Guidance (CRB): Show a subset of the capability realisations that focus on a given aspect of the system, consistent with the partitioning of MCBs that was done at system level |
LCRB-020 | At least one logical actor (external to the system) is visible on the diagram |
LCRB-030 | The relationship between two capability realisations is shown with generalisation or include or extend relationship. (exclusive OR: only one of these relationships may be established between any pair of capability realisations) |
LCRB-040 | The set of relationships between capability realisations is logically consistent. (this means avoiding issues like circular dependencies, making sure that include and extend relationships point in the correct direction, etc.) |
3.3.2.2.
147-004 | At least one original capability realisation is visible on the diagram |
147-006 | Zero or more refined capability realisations are visible on the diagram |
147-010 | A refined capability realisation may have include or extend relationships to an original capability realisation in either direction Guidance: usually, we would expect that a refined capability realisation would extend an original, or that an original would include a refined, but other arrangements are allowed if needed |
147-020 | A refined capability realisation may be generalised by an original capability realisation but the converse is not permitted. |
147-030 | All original capability realisations must have a trace to the corresponding system capability. Guidance: this would not be visible on the diagram, but is visible when viewing the properties of the capability realisation (the property "Realised system capabilities" should not be blank). |
3.3.3.
3.3.3.1. AMOD-125 Logical architecture definition
125-010 | All functional exchanges that cross the system boundary are allocated to a component exchange. |
125-020 | All visible functions are primitive/leaf-level (i.e. not further decomposed elsewhere in the model) |
125-030 | All leaf-level functions are visible (that is, there are no leaf-level functions left hidden in the model) |
125-040 | There exist at least one diagram per realised capability:
|
125-060 | There one diagram that shows all logical componets, allocated functions and optional the component exchanges. The free text for the diagrams name shall include: "<<system name>> logical component consolidated 1" Where: <<system name>>: Is the name of the one system on system level. E.g. SysRCA. The filter ‘Hide Functional Exchanges’ and 'Collapse Functional Ports' and 'Hide port allocation' are activated. Optional the filter ‘Hide Component Exchanges’ and 'Collapse Component Exchanges' are activated. |
125-070 | There exists one diagram that shows all logical componets and component exchanges. The free text for the diagrams name shall include: "<<system name>> logical component consolidated 2" Where: <<system name>>: Is the name of the one system on system level. E.g. SysRCA. The filter ‘Hide Functional Exchanges’ and ‘Hide Functions" is activated |
125-080 | There one diagram that shows all logical componets, component exchanges, allocated functions, functional port allocation. The free text for the diagrams name shall include: "<<system name>> logical component consolidated 3" Where: <<system name>>: Is the name of the one system on system level. E.g. SysRCA. The filter ‘Hide Functional Exchanges’ is activated. |
3.3.4. Logical Dataflow Blank (LDFB)
3.3.4.1. General Rules
LDFB-010 | The general direction of functional exchanges is directed either left to right or top to bottom |
LDFB-020 | The direction of functional exchanges that form feedback loops is either right to left or bottom to top |
LDFB-040 | Where there exists some hierarchy of functions, the owning function is shown on the diagram, with the owned function nested inside it. |
LDFB-050 | The diagram filters are set to display exchange items on functional exchanges, if they exist. |
3.3.4.2. AMOD-081 Logical functional flow definition (single system capability realisation)
ID | Ruled |
---|---|
081-010 | General rule: there exists one diagram per system capability; Qualification 1: where more than one capability use almost exactly the same set of functions, it is permissible to use one diagram to capture the functions and exchanges of more than one capability; Qualification 2: where a capability involves more functions than can fit sensibly on a diagram, it is permissible to create more than one diagram for the capability. |
081-030 | The diagram (or set of diagrams if 081-010 Q2) displays all functions AND functional exchanges involved in the fulfilment of the owning capability, including functions allocated to actors. |
081-040 | A behaviour definition for a logical function (which is not state-based and not modelled with a state machine (L.STM)) is modelled with a constraint which is attached to the corresponding logical function. |
081-050 | A behaviour definition for a logical function is textual and is conforming to the rules of the chosen modelling language. |
3.3.4.3. AMOD-088 Consolidated logical functional flow definition
ID | Rules |
---|---|
088-010 | General rule: there exists one diagram that shows all logical functions and their functional exchanges. |
088-020 | The free text for the diagrams name shall include: "<system name> logical functions consolidated" Where: <system name>: Is the name of the one system on system level. E.g. System RCA. |
088-030 | For functional exchanges on the diagram the associated exchange items shall be displayed, instead of the name of the functional exchange. |
3.3.5. Logical Exchange Scenario (L.ES)
3.3.5.1. General Rules
LES-010 | The diagram comprises all direct involved actor and logical component life lines. |
LES-031 | Only the following combined fragments are permitted to be used in L.ES:
Note: ALT fragments should not usually be needed, since alternative paths are usually modelled in separate scenarios; they continue to be permissible but only where strictly necessary. |
LES-040 | If at least two functional exchanges can occur in parallel each following weak sequencing rules, the functional exchanges are modelled using the PAR fragment. There is no implied order between occurrences in different operands. |
LES-041 | Where PAR fragments are used, at least two operands are required. |
LES-050 | Optional functional exchanges("if-" functional exchanges that take place under certain conditions, with no alternative) are modelled using the OPT fragment. |
LES-060 | Where OPT fragments are used, OPT fragments have a defined guard condition describing the logical condition under which the functional exchange takes place. |
LES-061 | When a LOOP combined fragment is used, it shall have a guard condition that describes the logical condition under which the combined fragment takes place. Optional: you can specify a minimum and maximum number of iterations of the loop between parentheses. The format is: (<min.>, <max.>) and it shall be added in a note attached to the LOOP combined fragment (a note because this capability is not supported by Capella). If not specified, a default range (0, *) is assumed. |
LES-070 | See note against LES-031 Alternate functional exchanges ("if-then-else" constructs of functional exchanges that take place under certain conditions, with alternative functional exchanges under different conditions) are modelled using the ALT fragment. |
LES-080 | See note against LES-031 Where ALT fragments are used, at least two operands are required. Each operand of the fragment has a defined guard condition describing the logical condition under which the functional exchange takes place. |
LES-090 | See note against LES-031 Where ALT fragments are used, the set of guard conditions for the fragment covers all eventualities AND there are no logical intersections between guard conditions (they are mutually exclusive) |
LES-092 | It is allowed to use reference (interaction use) to reduce the complexity of a scenario within one capability. The use should be well justified and really only used where it makes sense. Note: Where a reference is used, the reference object must be manually configured with the correct involved lifelines. Where practical, the reference object must be laid on the diagram in such a way that non-involved lifelines are not covered by the reference object. |
LES-093 | When one capability includes another capability with the "include"-relationship then the scenarios of the included one are referenced using the REF combined fragment (reference/interaction use). No lifelines in the scenarios are shown which do not have any interaction which another lifeline. If another scenario is referenced where the omitted lifeline is then involved, its involvement is only shown in the referenced one, but not the referencing one. Note: This is done for practical reasons and tool constraints deviating from common practice (e.g. SysML) to show every lifeline involved in the capability (i.e. the including capability and the included one). |
LES-094 | When one capability extent another capability with the "extent"-relationship then the scenarios of the extended one are referenced using the REF combined fragment (reference/interaction use) and OPT combined fragment. The OPT fragment includes the condition when the extension is applicable. No lifelines in the scenarios are shown which do not have any interaction which another lifeline. If another scenario is referenced where the omitted lifeline is then involved, its involvement is only shown in the referenced one, but not the referencing one. Note: This is done for practical reasons and tool constraints deviating from common practice (e.g. SysML) to show every lifeline involved in the capability (i.e. the extended capability and the extending one). |
LES-100 | The diagram contains at least one complete sequence of functional exchanges (output of function of interest) that is navigable from the start conditions to the end conditions. |
LES-105 | The execution element of an incoming exchange is as long as the duration in which the outputs of functions can change within a lifeline. This means as long as new exchanges with a changed value to another lifeline are happening depicted on the diagram. |
LES-110 | All functions of interest (functions that are part of the sequence path in the respective functional chain) are shown as graphical representation (allocated function) on the diagram:
Note: The intended meaning is that, at this point of the sequence, the function's output changes in line with changes to its inputs. It is NOT intended to indicate that the function is "called" or "invoked"; the function is assumed to be "always-on" or at least "always-on in a particular system state". |
LES-120 | Functional Exchanges are shown on the diagram:
|
LES-131 | If the pre- and postconditions of the owning capability fully apply to the Exchange Scenario these shall be contained in the diagram. Additional pre- and postconditions of the Exchange Scenario shall be specified in the related field in Capella, representing a refinement or more concrete conditions that apply to this specific scenario. Preconditions will be represented in the upper left corner of the diagram. Capability preconditions will be represented over the specific preconditions Postconditions will be represented in the bottom left corner of the diagram, at the end of the lifelines. Capability postconditions will be represented over the specific postconditions |
LES-132 | If the pre- and postconditions of the owning capability do NOT apply to the Exchange Scenario these shall NOT be contained in the diagram. Pre- and postconditions of the Exchange Scenario shall be specified in the related field in Capella, explicetely specifying which pre- or postconditions are NOT fulfilled in this scenario. The semantic shall be: NOT(<pre/postcondition of owning capability>) Any other additional pre- or postconditions providing context to the specific scenario shall also be specified in the related field in Capella. Preconditions will be represented in the upper left corner of the diagram. Postconditions will be represented in the bottom left corner of the diagram, at the end of the lifelines. |
LES-130 | Where a particular state on a lifeline changes as a result of an interaction, and this is relevant to the scenario, it should be shown using the "State Invariant" graphical element ("State Fragment" in Capella obtained through "Involved State / Mode") State Machine contained in Physical Train Unit here At this level, the trigger of the transition of the state machine should match/be consistent with the interaction depicted in the sequence diagram (see "switch on fwrd" in the example above) |
LES-140 | Where an exchange context is used to illustrate the content of a Sequence Message:
|
3.3.5.2.
3.3.5.3.
084-010 | After completion of ARCH.086, and where there remains a question over which logical component will generate or consume a functional exchange, the diagram shows all alternative routes for the functional exchanges without a logical fragment. |
084-040 | Internal exchanges between function pairs shall not be sown on the diagram. Internal exchanges are functional exchanges between functions that are both allocated to the same logical component or actor. |
3.3.6. Functional Chain Description (LFCD)
3.3.6.1. General Guidance
- The green blocks displayed on an LFCD are Logical Function Involvements, not Logical Functions themselves. They can only be created to represent Logical Functions that already exist, so it is useful to have an LDFB (AMOD-081) open where you can create new Logical Functions and Functional Exchanges if you need them. When they are deleted, they do not delete the Logical Function they represent.
- Relationships between capabilities will be defined in CC diagrams on the system level. Include, Extend and Generalization relationships can be defined.
- If possible, eliminate usage of swim lane text boxes. The functional chain viewpoint exists to show sequential order of functions without considering allocation of the functions. Other views in Capella (ES, LAB) exist to show the allocation of functions. If allocation has to be shown, then a textbox can be used next to the concerned function.
- Allow plenty of space so that you can set the diagram out in a neat and orderly way; these diagrams quickly become unreadable if the left-to-right or top-to-bottom convention is not followed.
- A function involvement means that when the chain of sequence links reaches this particular function involvement, the output value of this function has changed.
3.3.6.2. General Rules
LFCD-100 | There exists no function of interest involvement that is unconnected to the rest of the functional chain by a sequence link. A function of interest is a function whose execution happens wholly within the timeframe of this functional chain and is inextricably bound up in the execution sequence of this functional chain. In contrast, an information-providing function is one that (in the context of THIS functional chain) could be thought of as an always-present information source/sink, where the sequencing/logic of its execution is not relevant to the sequence of THIS functional chain. |
LFCD-110 | There exists at least one navigable path of sequence links from the beginning of the functional chain to end of the functional chain. |
LFCD-120 | Functional Exchanges are shown on the diagram between functions of interest and functions that provide information.
|
3.3.6.3. Start and End Conditions
ID | Rule |
---|---|
LFCD-130 | The start and end conditions of the owning Realised Capability are displayed on the LFCD diagram. They should be placed such that they conform to the flow of the diagram. If a diagram flows from top to bottom, the conditions should be placed on the top and bottom. Note: Related functional chains can have different end conditions. A capability should contain all relevant conditions for all of the functional chains it contains. They can be differentiated in the description using OR relationships. Guidance: to display start and end conditions, use the Constraint referencing tool and look up the two constraints linked to the owning Realised Capability - these will be the start and end conditions, and they should display on the diagram just like any other constraint. Note: constraints attached to functional chains which are displayed collapsed will not appear on the diagram. |
3.3.6.4. Logic Nodes (AND, OR) and Sequence Links
ID | Rule |
---|---|
LFCD-001 | A Logical Function Involvement shall only have a maximum of one incoming sequence link. |
LFCD-002 | A Logical Function involvement shall only have a maximum of one outgoing sequence link. |
LFCD-010 | Where a decision is made between two or more possible, mutually exclusive paths in the process:
|
LFCD-020 | Where two or more alternative paths come back together to a common path:
|
LFCD-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. |
3.3.6.5. Instantiation of Functions
LFCD-039 | Where an actor function is needed in order to completely reach the end conditions/stimulate the start conditions of a system capability, this actor function is shown on the diagram. |
LFCD-040 | Where the same function occurs more than once within a functional chain in different contexts, this is modelled with two or more separate function Involvements, placed in a logically consistent position in the process. |
LFCD-050 | Where the same function or sequence of functions occurs more than once within a functional chain OR Where the execution logic of the functional chain requires a return loop from a later function to an earlier function this is modelled using the IT construct to create a loop |
3.3.6.6. Included Functional Chains
LFCD-060 | Where a functional exchange exists between two functions AND the function is relevant to this functional chain the functional chain is displayed on the LFCD. Functional chains of interest (needed to arrive at the postcondition) will be included or extended, and will be displayed minimized. The included or extended functional chain should be connected to the functional chain of interest using sequence links. |
LFCD-070 | Where a functional chain includes another functional chain in its entirety the included functional chain is displayed on the LFCD for the including functional chain as a separate reference block (that is, the included functional chain steps are not redefined) Note: modelling in this way would imply that there is an inclusion relationship between the respective owning system capabilities. |
LFCD-080 | The view must comply with LFCD-080 INCLUSIVE OR LFCD-090 Where a functional chain includes another functional chain in its entirety there exists at least one sequence link from a function involvement outside the included functional chain to a function involvement inside the included functional chain AND there exists at least one functional exchange involvement from a function involvement outside the included functional chain to a function involvement inside the included functional chain |
LFCD-090 | The view must comply with SFCD-080 INCLUSIVE OR SFCD-090 Where a functional chain includes another functional chain in its entirety there exists at least one sequence link from a function involvement inside the included functional chain to a function involvement outside the included functional chain AND there exists at least one functional exchange involvement from a function involvement inside the included functional chain to a function involvement outside the included functional chain |
3.3.6.7. AMOD-082 Logical functional chain definition
ID | Rule |
---|---|
082-010 | Where a functional chain represents the entirety of a capability realisation, the start and end conditions of the owning capability realisation are displayed on the diagram. The diagram shows all logical functions of interest and functional exchanges necessary to reach the end conditions of the capability, including measures needed for system risk control. |
3.3.7. Logical State Machine (L.STM)
3.3.7.1. General rules
ID | rule |
---|---|
LSTM-010 | There exists a single Initial state. |
LSTM-020 | There exists at least one transition outgoing from each state (except for the Final state). |
LSTM-030 | There exists at least one transition incoming to each state (except for the Initial state). |
LSTM-040 | There exists at least one navigable path along transitions from the Initial state to the Final state, if a final state is defined. |
LSTM-040 | There exists at least one simple state or at least one composite state. Guidance: An comparison to simple states, composite states are nesting other simple states or composite states in sequential or parallel/concurrent manner. They can be used handle to complexity of hierarchical state structures. |
LSTM-050 | All transitions have a definition of the conditions for the transition, selected from:
|
LSTM-060 | An action of a transition is defined as follows: <action expression> The action expression is textual and consists of one or more atomic assignment statements. It is conforming to the rules of the chosen modelling language. Guidance: Try to limit the number of statements inside the action expression to keep and increase readibility of the state machine diagram (approx. a maximum number of five statements per action). In addition, avoid conditional statements (e.g. if-else) inside the action expression. Instead use choice states or guard conditions to express condtional outcomes. |
LSTM-070 | A change event of a transition is defined as follows: when (<boolean expression>) The boolean expression is textual and is conforming to the rules of the chosen modelling language. |
LSTM-080 | A guard condition of a transition is defined as follows: <boolean expression> The boolean expression is textual and is conforming to the rules of the chosen modelling language. |
LSTM-090 | The current value of an exchange item element is accessed by using the name of the exchange item element inside an action expression or boolean expression. Corresponding statements follow the rules of the chosen modelling language. Guidance: Assignment statements or relational operators in context of a boolean expression can be used to access the current value. Example: Action with an atomic assignment statement (pseudo modelling language) OutgoingExchangeItem.ExItemElem = (IncomingExchangeItemA.ExItemElem < 10) And (IncomingExchangeItemB.ExItemElem != 1) |
LSTM-100 | A new value of an exchange item element is set by using the name of the exchange item element inside an action expression. Corresponding statements follow the rules of the chosen modelling language. Guidance: Assignment statements can be used to set the new value. Example: Action with two atomic assignment statements (pseudo modelling language) OutgoingExchangeItemA.ExItemElem1 = 10 OutgoingExchangeItemB.ExItemElem2 = AnEnumTypeLiteral |
3.3.7.2. AMOD-083 State-based behaviour definition (logical function)
ID | rule |
---|---|
083-010 | The set of states on the view gives complete coverage of the statefulness of the owning logical function. |
083-020 | Where the logical function considers and covers a range of states that all amount to the same behaviour with respect to the system of interest and where the transitions between these states are not relevant to the system of interest, this is modelled with one broadly-defined "super" state (also called complex or composite state) rather than a faithfully-rendered model of many distinct states. |
083-030 | Where an logical function consider and covers a set of states defined externally (e.g. in existing documentation) then the states are reused, if it is judged to be appropriate, in preference to a completely new definition of the states. |
Color legend:
Meaning | Color |
---|---|
Naming convention |