Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
2. Modelling Rules for System Analysis
- 2.1. Overall
- 2.2. Elements
- 2.2.1. System Capability
- 2.2.2. System Mission
- 2.2.3. System Actor
- 2.2.4. System Function
- 2.2.5. System Functional Exchange
- 2.2.6. System Component Exchange
- 2.2.7. System Physical Link
- 2.2.8. System Functional Chain for System Capability
- 2.2.9. Exchange Scenario for System Capability
- 2.2.10. Exchange Scenario for an Interface Layer
- 2.2.11. System State
- 2.2.12. System Rationale
- 2.3. Diagram Types and Viewpoints
- 2.3.1. General Rules
- 2.3.2. System Architecture (SAB)
- 2.3.3. System Capability Subset (MCB) and Contextual Capability (CC)
- 2.3.4. System Exchange Scenario (S.ES)
- 2.3.5. System Data Flow (SDFB)
- 2.3.6. System Functional Chain Description (SFCD)
- 2.3.6.1. General Guidance
- 2.3.6.2. General Rules
- 2.3.6.3. Start and End Conditions
- 2.3.6.4. Logic Nodes (AND, OR) and Sequence Links
- 2.3.6.5. Instantiation of Functions
- 2.3.6.6. Included Functional Chains
- 2.3.6.7. AMOD-059 Initial system functional chain description
- 2.3.6.8. AMOD-118 System functional chain descriptions with risk control measures [SFCD]
- 2.3.7. State Machine (MSM)
- 2.3.8. Query-based Viewpoint
2.1. Overall
ID | Rule |
---|---|
SA-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. |
SA-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: |
SA-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. |
2.2. Elements
2.2.1. System Capability
RCAMT-396 - Getting issue details... STATUS
SC-106 | Naming convention: Sentence case - the first letter of the first word in a sentence is capitalised. The name of a system capability should begin with an active verb. The verb should be specific enough to identify what the actor wants from the system. Verbs such as "manage", "handle" or "process" are not specific enough and are forbidden. The usage of abbreviations should be well considered and should only be used in cases where the abbreviation is standardised. In addition, the system capability name gets a prefix: <Capability unique number>.<Number in case of generalisation link>: <System capability's name>
Note: capabilities can be grouped by a mission in the model if needed Examples:
| ||||
SC-103 | All identified system capabilities have a valid set of metadata comprising: a statement of the primary actor's goal in the capability, to be written in the description field template: The [SystemActorname] requires the system to [mandatory description of the operation on the primary object] [optional description of the influence of the secondary object] and [optional description of the involvement of the secondary actors to enable the operation on the primary object]. Note: Primary object and secondary objects of a capability shall be determined as the object on which a service of the system is performed upon and the secondary object is an object that is involved in the provision of the service upon the primary object, respectively. and at least one pre-condition entered into the correct field in Capella and at least one post-condition entered into the correct field in Capella WHERE the capability has multiple pre and/or post-conditions, each condition shall be included in its own line in the correct field in Capella and joined to the other conditions with an AND statement, e.g.: <Entity> is <state> AND <Entity> is <state> WHERE the capability has multiple possible post-conditions (a main success condition and one or more failure/diminished success conditions) THEN each separate post-condition should be included in an inclusive OR statement WITH the main success condition being the first listed condition. i.e. Post-condition = <main success condition> OR <second success condition> OR <failure condition> Ideally, start and end conditions should have the following format: <entity> is <state> where entity could be any actor or a data concept and state is one of the defined states that the entity is allowed to occupy. Guidance:
| ||||
SC-104 | Each capability has an involvement relationship to at least one actor, except where a capability is included by other capabilities (in which case, a direct involvement with an actor is not necessary, but is allowed) or when a capability is sub typed (in that case, it inherits the actor from the super-type capability) | ||||
SC-105 | The set of relationships between capabilities is logically consistent and allows for no unintended overlaps between the scopes of different system capabilities. | ||||
SC-107 | At the post-condition of each system capability, a measurable or observable result has been delivered to at least one actor in the wider system of interest (that is, the user story has been achieved). If a candidate capability has valid behaviour but yields nothing to any actor, it is more likely to be a function. In other words, capabilities are "stories" where functions are just "chapters". |
2.2.2. System Mission
ID | Rule |
---|---|
SMN-001 | Naming convention: Sentence case - the first letter of the first word in a sentence is capitalised. The name of a system mission should begin with an active verb. The verb should be specific enough to identify what the high-level goal for the system is. The usage of abbreviations should be well considered and should only be used in cases where the abbreviation is standardised. In addition, the system mission name gets a prefix: <Mission unique number>: <Mission name>
|
SMN-010 | Each mission has a meaningful description that includes a rational why it is a mission for the system. |
2.2.3. System Actor
ID | Rule |
---|---|
SA-040 | Naming convention:
|
SA-020 | The description of a system actor focuses on the features that define them, not on its responsibilities or functions. Guidance: a brief summary of responsibilities/behaviour is allowed but this should not read like a list of functions (because this information should be defined only through the allocation of functions to this actor, not duplicated in a text description) |
SA-030 | Where an abstract concept is mentioned in the description of an system actor, this is done using a hyperlink to the abstract concept, rather than plain text. |
SA-010 | System actor name and description is consistent with harmonised definitions from collaboration projects (RCA, S2R, OCORA etc.) or with international standards where applicable. |
SA-050 | Where a system actor is a system-level realisation of an operational entity or actor AND the system actor is NOT defined by a collaboration project (see SA-010): There exists a realisation relationship to the corresponding operational entity/actor AND The description of the system actor is identical to the description of the corresponding operational entity/actor OR The description of the system actor is aligned with the description of the corresponding operational entity/actor but is adjusted to make it appropriate for system-level Guidance: the name of the system actor does not need to be identical to that of the operational entity/actor, but this is permitted, if it makes sense. |
SA-060 | Generalisation between system actors is not permitted. |
2.2.4. System Function
2.2.4.1. Guidance
Detailed guidance and explanations can be found in ARCH.M.010 Method for definition of functionality.
2.2.4.2. General Rules
ID | Rule |
---|---|
SF-010 | 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. |
SF-020 | The usage of abbreviations in both the names and descriptions of logical functions is only permitted in the case of standardised abbreviations (e.g. ETCS, PRM, GoA), not for terms that have been defined within the scope of the project (e.g. TU in place of Train Unit). |
SF-030 | Function Description - describe what the function is for, such that the following boxes can be ticked:
Pattern: This function <verb> .... Note: see also rule SRA-040 |
2.2.4.3. Function Allocated to System
SFS-010 | 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. |
SFS-020 | For system functions, the multiplicities shown in the ontology in Method for definition of functions must be complied with. |
SFS-030 | Control system principle Each core system function should be named and described in such a way that it conforms to one of the categories of control system function. A "core" system 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:
The main five ontology elements (control, actuate, indicate/display, sense and observe), are to be used for naming system functions. |
SFS-040 | 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 system level. |
SFS-050 | All functions at system level have at least one functional exchange that crosses the system boundary. Rationale: ARCADIA system needs analysis is intended only to identify the needs of external stakeholders on the system, not to create a model of how the system works internally. The logical level of ARCADIA is the appropriate level to begin modelling and presenting the partitioning of the functions into a solution architecture. By clustering functionality around the external interfaces of the system, the functions remain focused on needs of stakeholders (handling inputs/producing outputs). This approach is also aligned with the EULYNX ModStan approach of clustering behaviour around the ports of a system, with linking behaviour in between. exception:
|
2.2.4.4. Function Allocated to Actor
ID | Rule |
---|---|
SFA-010 | Naming convention: Actor function names 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. |
SFA-020 | Actor functions are permitted to merge multiple items from the control system pattern, where used; in this case, the name of the actor function may contain several verbs (e.g. Sense+observe or Control+actuate) |
SFA-030 | Actor functions are defined wherever some behaviour is expected from an actor in order to reach the end conditions of a system capability |
SFA-040 | Actor functions must be described in a way that show the responsibilities of the actor in a clear manner. |
SFA-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. |
SFA-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). |
2.2.4.5. Interfacing Function
Detailed guidance and explanations can be found in ARCH.M.030 Method for definition of interfaces.Method for definition of system interfaces
ID | Rule | ||
---|---|---|---|
SFI-010 | Naming convention:
<Interfacing Function’s name> (<Interface number information>)
Then, the template of the interfacing function name at system level must be: <Active verb> between <allocating entity> and <entity communicating through this interface> (<Interface number information>) Examples:
| ||
SFI-020 | Interfacing principle An "interfacing" function is a function that is active when the system and an actor need to exchange with a specific constrained interface between each other. | ||
SFI-030 | Interfacing functions are always created per pair: one allocated to the system, one allocated to an actor. | ||
SFI-040 | All interfacing functions at system level have at least one functional exchange that crosses the system/actor boundary. |
2.2.5. System Functional Exchange
SFE-120 | 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. ------------------------------ Exception for functional exchange between interfacing function:
Template for Functional Exchange name: <SourceEntity>_<TargetEntity>_<LayerName>_< interface number information> Example: SystemX_PlanningSystem_Application_01 | |||||||||||||||
SFE-010 | 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. --------------------------------------------- Exception for functional exchange between interfacing function: For one interfacing function, there should only be one functional exchange per interface layer (and per direction). See Method for definition of system interfaces to have guidance for this rule | |||||||||||||||
SFE-140 | Each functional exchange shall have at least one exchange item allocated to it. These exchange items define the functional exchange. Exception: Actor function to actor function do not need necessarily exchange items. | |||||||||||||||
SFE-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.
| |||||||||||||||
SFE-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. | |||||||||||||||
SFE-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 SFE-160 also applies. | |||||||||||||||
SFE-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. | |||||||||||||||
SFE-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. | |||||||||||||||
SFE-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:
| |||||||||||||||
SFE-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). | |||||||||||||||
SFE-220 | For functional exchange between interfacing function: A functional exchange can only exist between interfacing functions of the same interfacing functions pair (see SIF-030). |
2.2.6. System Component Exchange
ID | Rules |
---|---|
SCE-010 | Naming convention: If the interface is defined or governed by an external standard the name of the system component exchange is used as defined in the external standard. Note: this rule applies only if the current name within the standard is meaningful and can no longer be changed.
component exchange name = I_ / HMI_ <ActorName>_<LayerName>_< interface number information> E.g. I_PlanningSystem_Application_01 |
SCE-020 | Component Exchanges have only allocated functional exchanges which came from an exchange between interfacing functions. Exception: if the interface is non-externally constrained then component exchanges can have allocated functional exchanges which came from an exchange between core functions. |
SCE-030 | A Component Exchange has only allocated functional exchanges which came from the same interfacing functions pair (see SFI-030). |
SCE-040 | Component Exchanges may have more than one allocated functional exchange. |
SCE-050 | Port of a Component Exchange should be In or Out port. Exception: if a component exchange has bilateral allocated functional exchanges, then both ports are InOut ports. |
2.2.7. System Physical Link
ID | Rules |
---|---|
SPL-010 | Naming convention: If the interface is defined or governed by an external standard the name of the system component exchange is used as defined in the external standard. Note: this rule applies only if the current name within the standard is meaningful and can no longer be changed. If name is not meaningful and can be changed this following scheme is applied:
component exchange name = I_ / HMI_ <ActorName>_ Physical E.g. I_PlanningSystem_Physical |
2.2.8. System Functional Chain for System Capability
ID | Rule |
---|---|
SFC-010 | Naming convention: The initial functional chain shall be named <system capability name> (initial) The functional chain that assesses and mitigates the different risks shall be named<system capability name> (with robustness measures) |
SFC-020 | There exists for each system capability two functional chains: one initial system functional chain, and one system functional chain including robustness measures for operational performance, functional safety and functional security |
SFC-030 | Note: A functional chain may be used to refine its owning capability by limiting the features applied to it. As a result, the pre and post-conditions of the owning capability may apply only partially to the functional chain. In such cases, the pre-conditions and post-conditions of the functional chain may be refined from those of the owning capability. If, for example, either the train driver or train attendant may close the doors of a train unit within the scope of a capability, the more refined functional chains may show these refinements of the overall capability in the form of additions in the pre-condition and post-condition fields of the functional chain. WHERE the pre and/or post-conditions of a functional chain deviate from those of its owning capability, they should ideally be formatted as such: <Entity> is <state> where entity could be any actor or a data concept and state is one of the defined states that the entity is allowed to occupy. Guidance:
|
2.2.9. Exchange Scenario for System Capability
Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios
SXS-102 | Naming convention: The initial scenario shall be named <capability name>[<X>](initial). X is the number of the initial scenario. The scenario that contains the assessment and mitigation of risks of system failures shall be named <capability name>[<X.Y>](with robustness measures). X is the number of the related initial scenario. Y is the number of scenarios with robustness measures. |
SXS-101 | There exists for each System Capability at least two scenarios: one initial scenario and one initial scenario with robustness measures for operational performance, functional safety and functional security. |
SXS-104 | 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. depending on operational scenarios). Therefore the pre- and postconditions of the Capability may or may not apply to the Exchange Scenario. 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:
|
2.2.10. Exchange Scenario for an Interface Layer
Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios
SXS-105 | Naming convention: The initial scenario shall be named I_ / HMI_ <ActorName><LayerName>< interface number information>.
E.g. I_PlanningSystem_Presentation_01 |
SXS-106 | There may exist a scenario for an Interface Layer if there is a need to model interface-specific behaviors |
SXS-107 | 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:
|
SXS-108 | A scenario only model on one interface layer at a time |
2.2.11. System State
ID | Rule |
---|---|
SST-010 | Naming convention: Sentence case - the first letter of the first word in a sentence is capitalised. 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 the project (that is, when reusing state definitions from elsewhere, they should be reproduced precisely and not changed) |
SST-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. |
SST-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. |
2.2.12. System Rationale
ID | Rule |
---|---|
SRA-010 | Rationales should be created using the model element requirement (type rationale). |
SRA-020 | The description for the rationale is inserted in the field "text" in Capella. |
SRA-030 | Each rationale has at least one outgoing link to a target model element using the relation type "justifies". |
SRA-040 | Basically, all model elements can be justified by a rationale. At least the following model elements on system level should be justified:
|
SRA-050 | If a rationale is expanded by an artefact, e.g. a trade study result (AMOD-046 or AMOD-024) 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
2.3. Diagram Types and Viewpoints
2.3.1. General 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. |
2.3.2. System Architecture (SAB)
2.3.2.1. General Rules
SAB-010 | The system of interest appears on the diagram |
SAB-020 | At least one actor (external to the system) is visible on the diagram |
2.3.2.2. AMOD-041 System boundary options
041-010 | This view is produced as a sketch using any preferred drawing tool. |
041-020 | The notation used by the Capella SAB diagram is used in this view:
|
041-030 | The view presents two or more alternative system boundaries alongside each other for comparison. |
041-040 | For each alternative system boundary, there is displayed
|
041-050 | For each alternative system boundary, there is displayed at least one candidate function allocated to the system AND at least one candidate function allocated to one actor |
041-060 | WHERE a candidate function has been created as an implementation of an operational activity, the function is named identically to the operational activity |
041-070 | WHERE two or more candidate functions have been created as a decomposition of an operational activity, a note is added to the sketch, linked to all such candidate functions, containing the name of the operational activity that was decomposed. |
041-080 | Comparing one alternative system boundary with another, there exists at least one difference in the allocation of candidate functions between the system and the actor(s). |
2.3.2.3. AMOD-046 Selected system boundary tradeoff record
046-010 | This view is produced as a sketch using any preferred drawing tool. |
046-020 | The notation used by the Capella SAB diagram is used in this view:
|
046-050 | There exists one and only one system on the view. |
044-010 | All system actors are displayed on the view. |
044-020 | All known functions allocated to the actor are displayed on the view. |
2.3.2.4. AMOD-114 System interface definition
114-005 | The multiplicities shown in the ontology must be complied with. |
114-010 | One system actor is displayed on the view. |
114-020 | Core functions are displayed on this view if and only if they have exchanges with core functions allocated to the other part of the interface. |
114-022 | A pair of interfacing functions is displayed on the view in case of an externally constrained interface |
114-025 | This view defines interface layers, which means that this view displays functional exchanges and component exchanges between interfacing functions in the case of an externally constrained interface. Where requirements or constraints on the exchange between the system and system actor have been identified. For all aspects of the interface where no requirements have been identified, no interface layers are defined. More guidance and method → Method for definition of system interfaces |
114-030 | All exchanges between core functions and interfacing functions are defined in this view |
114-050 | One component exchange is displayed on this view to represent each identified layer, except for physical layer (see 114-060). Exception: in case of a non-externally constrained interface, a component exchange is displayed between the system and the actor and can be associated to the “application layer” |
114-055 | All functional exchanges between interfacing functions should be allocated to the corresponding component exchange of the specific interfaces |
114-060 | A physical link is displayed on this view to represent the physical layer of the interface. |
114-061 | If physical links are used for the interface, allocate the corresponding component exchanges of an interface layer to these physical links. |
114-080 | The filter settings of the SAB diagram are set to display the exchange items that are exchanged over each functional exchange. |
2.3.2.5. AMOD-119 System context definition
119-010 | All actors on the diagram are connected with the system via a component exchange. |
119-020 | The flow direction of each component ports is set as follows:
|
2.3.2.6. AMOD-133 Consolidated system function allocation
133-005 | All system actors are displayed on the view. |
133-010 | All functions in the model are allocated to either a system actor or the system. |
133-020 | All functional exchanges that cross the system boundary are allocated to a System component exchange (Port allocation is shown), |
133-030 | The filter "Hide Functional Exchanges" is activated. |
2.3.3. System Capability Subset (MCB) and Contextual Capability (CC)
2.3.3.1. General Rules
SC-101 | At least one system capability is visible on the diagram Guidance (MCB): Show a subset of the system capabilities that focus on a given aspect of the system |
SC-102 | At least one actor (external to the system) is visible on the diagram |
SC-103 | Where missions are visualised: Each mission exploits at least one capability AND Each system capability is exploited by at least one mission |
SC-104 | The relationship between two capabilities is shown with generalisation or include or extend relationship. (exclusive OR: only one of these relationships may be established between any pair of capabilities) |
SC-110 | The set of relationships between system capabilities is logically consistent. (this means avoiding issues like circular dependencies, making sure that include and extend relationships point in the correct direction, etc.) |
2.3.3.2. Guidance
Detailed guidance and explanations can be found in ARCH.M.040 Method for definition of capabilities.
2.3.3.3. AMOD-045 System capabilities
045-010 | The capabilities and missions are divided between diagrams in the same structure as done at operational level (view AMOD-021) |
045-020 | Actor involvements may be shown but this is optional. Rationale: actor involvements may clutter the diagrams if there is a large number of actors and a large number of capabilities. |
2.3.3.4. AMOD-138 Single system capability context
ID | Rule |
---|---|
138-010 | For the system capability of interest, all actor involvement relationships are shown. Note: capabilities other than the system capability of interest may optionally show relationships to actors and to each other, if useful. |
138-020 | For the system capability of interest, all relationships to other system capabilities are shown. |
2.3.4. System Exchange Scenario (S.ES)
2.3.4.1. General Rules
SES-010 | The diagram comprises all directly involved actor lifelines. |
SES-031 | Only the following combined fragments are permitted to be used in S.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. |
SES-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. |
SES-041 | Where PAR fragments are used, at least two operands are required. |
SES-050 | Optional functional exchanges("if-" functional exchanges that take place under certain conditions, with no alternative) are modelled using the OPT fragment. |
SES-060 | Where OPT fragments are used, OPT fragments have a defined guard condition describing the logical condition under which the functional exchange takes place. |
SES-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. |
SES-070 | See note against SES-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. |
SES-080 | See note against SES-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. |
SES-090 | See note against SES-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) |
SES-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. |
SES-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). |
SES-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). |
SES-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. |
SES-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. |
SES-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". |
SES-120 | Functional Exchanges are shown on the diagram:
|
SES-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 |
SES-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. |
SES-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) |
SES-140 | Where an exchange context is used to illustrate the content of a Sequence Message:
|
2.3.4.2. Guidance
Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios
2.3.4.3. AMOD-058 Initial system exchange scenario
058-010 | The diagram shows only the functional exchanges needed to reach the end conditions, without any consideration of robustness to system failures. |
2.3.4.4. AMOD-117 System exchange scenarios with risk control measures [S.ES]
117-010 | The diagram shows all the functional exchanges needed to reach the end conditions, including mitigations against the risk of system failures. |
2.3.4.5. AMOD-115 External interface behaviour
115-010 | The diagram shows the functional exchanges needed to capture any pre-defined/externally-defined behaviour of an interface layer protocol that is a constraint on the system (i.e. forced by outside needs). |
115-020 | Only the system and one actor (the external party of the interface) are displayed on the diagram. |
115-030 | Only one interface layer is considered in the scenario. |
115-040 | The functions of the system and the actor involved in this scenario are shown on the corresponding lifeline. |
115-050 | Only the symbolic functional exchanges between the system and the actor are shown |
2.3.5. System Data Flow (SDFB)
2.3.5.1. General Rules
SDFB-010 | The general direction of functional exchanges is directed either left to right or top to bottom |
SDFB-020 | The direction of functional exchanges that form feedback loops is either right to left or bottom to top |
SDFB-040 | Where there exists some hierarchy of functions, the owning function is shown on the diagram, with the owned function nested inside it. |
SDFB-050 | Functional Exchanges are shown on the diagram between functions of interest and functions that provide information.
|
2.3.5.2. AMOD-056 System functions and exchanges (single system capability)
056-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. |
056-030 | The diagram (or set of diagrams if 056-010 Q2) displays all functions AND functional exchanges involved in the fulfilment of the owning capability, including functions allocated to actors. |
2.3.5.3. AMOD-103 Consolidated system functions
ID | Rules |
---|---|
103-010 | General rule: there exists one diagram that shows all system functions and their functional exchanges. Note: This is not used as a deliverable, but as a working diagram. |
103-020 | The free text for the diagrams name shall include: "<system name> system functions consolidated" Where: <system name>: Is the name of the one system on system level. E.g. System RCA. |
2.3.6. System Functional Chain Description (SFCD)
2.3.6.1. General Guidance
- The green blocks displayed on an SFCD are System Function Involvements, not System Functions themselves. They can only be created to represent System Functions that already exist, so it is useful to have an SDFB (AMOD-056) open where you can create new System Functions and Functional Exchanges if you need them. When they are deleted, they do not delete the System Function they represent.
- The functional chain viewpoint exists to show sequential order of functions without considering allocation of the functions.
- 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.
2.3.6.2. General Rules
SFCD-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. |
SFCD-110 | There exists at least one navigable path of sequence links from the beginning of the functional chain to end of the functional chain. |
SFCD-120 | Functional Exchanges are shown on the diagram between functions of interest and functions that provide information.
|
SFCD-130 | To illustrate the content of a Functional Chain Involment Link using values, an Exchange Context may be used as follows
|
2.3.6.3. Start and End Conditions
SFCD-005 | The start and end conditions of the owning System Capability are displayed on the SFCD 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 System 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. |
2.3.6.4. Logic Nodes (AND, OR) and Sequence Links
SFCD-001 | A System Function Involvement shall only have a maximum of one incoming sequence link. |
SFCD-002 | A System Function involvement shall only have a maximum of one outgoing sequence link. |
SFCD-010 | Where a decision is made between two or more possible, mutually exclusive paths in the process:
|
SFCD-011 | When an OR node is used as a SysML decision node (see SFCD-010), the OR node should always be preceded by a Function |
SFCD-020 | Where two or more alternative paths come back together to a common path:
|
SFCD-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. |
2.3.6.5. Instantiation of Functions
SFCD-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. |
SFCD-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. |
SFCD-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 |
2.3.6.6. Included Functional Chains
SFCD-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 SFCD. 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. |
SFCD-070 | Where a functional chain includes another functional chain in its entirety the included functional chain is displayed on the SFCD 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. |
SFCD-080 | 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 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 |
SFCD-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 |
2.3.6.7. AMOD-059 Initial system functional chain description
059-010 | The diagram shows only functions of interest and functional exchanges necessary to reach the end conditions of the capability, disregarding any need for system robustness. |
2.3.6.8. AMOD-118 System functional chain descriptions with risk control measures [SFCD]
118-010 | The diagram shows all functions of interest and functional exchanges necessary to reach the end conditions of the capability, including measures needed for system risk control. |
2.3.7. State Machine (MSM)
2.3.7.1. General Rules
ID | Rule |
---|---|
SSM-010 | There exists a single Initial state. |
SSM-030 | There exists at least one transition outgoing from each state (except for the Final state) |
SSM-040 | There exists at least one transition incoming to each state (except for the Initial state) |
SSM-050 | There exists at least one navigable path along transitions from the Initial state to the Final state, if a final state is defined. |
SSM-060 | All transitions have a definition of the conditions for the transition, selected from:
|
SSM-070 | Only change events are allowed to trigger transitions of a state machine. A change event of a transition is defined as follows: when (<boolean expression>) The boolean expression is textual and can be written in natural language. Exception: an actor uses an interface already defined at the system level and this is event based. Then events can also be used for an actor state machine. |
2.3.7.2. AMOD-060 System/actor states
ID | Rule |
---|---|
060-010 | The set of states on the view gives complete coverage of the statefulness of the owning actor/system. 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. |
060-020 | Where an entity has 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 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 the system of interest. |
060-030 | Where an operational actor/entity has a set of states defined externally from the system of interest (e.g. in existing documentation) then the states are reused, if it is judged to be appropriate, in preference to a completely new the system of interest definition of the states. |
2.3.7.3. AMOD-055 System functions to state allocation map [Matrix]
ID | Rule |
---|---|
055-010 | Per System State Machine on matrix of name "Capability Function and State Machine Matrix" shall be generated. |
055-020 | A system function shall be allocated to a state by using the field "Operational Activities / Functions", which can be edited after double-clicking the state. |
2.3.8. Query-based Viewpoint
2.3.8.1. AMOD-116 System implementation constraints
ID | Rule |
---|---|
116-010 | All model elements shall be listed/displayed in this viewpoint that conform to the following: The rationale of the model element makes reference to either the IVV strategy OR the CONEMP in justifying its existence. |
Color legend :
Meaning | Color |
---|---|
Naming convention |