Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
4. Modelling Rules for Physical Architecture
- 4.1. Overall
- 4.2. Elements
- 4.2.1. Physical capability realisation
- 4.2.2. Physical Function
- 4.2.3. Functional Exchange
- 4.2.4. Physical Component
- 4.2.5. Physical Actor
- 4.2.6. Physical Component Exchange
- 4.2.7. Physical Exchange Scenario for Realised Capability
- 4.2.8. Physical Exchange Scenario for Interface Layer
- 4.2.9. Physical Link
- 4.2.10. REC/RPL
- 4.2.11. Physical State
- 4.2.12. Physical Rationale
- 4.2.13. Class
- 4.3. Diagram Types and Viewpoints
- 4.3.1. General Rules
- 4.3.2. Capability Realisation Blank (CRB)
- 4.3.3. Physical Architecture Blank (PAB)
- 4.3.3.1. General rules
- 4.3.3.2. AMOD-080 Subsystem option sketch
- 4.3.3.3. AMOD-085 Subsystem architecture definition (single realised capability)
- 4.3.3.4. AMOD-093 Subsystem architecture definition
- 4.3.3.5. AMOD-100 Interface layer definition
- 4.3.3.6. AMOD-143 Inter-subsystem interface definition
- 4.3.3.7. AMOD-111 Subsystem interface definition to external system / actor
- 4.3.4. Physical Exchange Scenario (P.ES)
- 4.3.5. Physical State Machine (P.STM)
- 4.3.6. Class Diagram (P.CDB)
4.1. Overall
ID | Rule |
---|---|
PA-001 | In order to ensure consistency within the project, British English is to be used at all times. Refer to the Cambridge Dictionary for further information. |
PA-002 | Images and/or diagrams that are to be used in the descriptions of Capella model elements shall be created and maintained on the following Confluence page: |
PA-003 | Description Links for model elements shall be used in all model element descriptions. E.g. if a certain description refers to a defined model element, the name of the model element being referred to shall be copied (as a Description Link) and pasted (as a Link) in the corresponding description field. Exception: model elements defined as abstract concepts and terms, which serve solely as a form of documenting information external to the project, shall be excluded from this rule. |
4.2. Elements
4.2.1. Physical capability realisation
PCR-010 | Naming convention : An original capability realisation (see viewpoint definition AMOD-148) has the same name, description, relationships, precondition and post-conditions as the logical capability realisation it represents. Guidance Physical capability realisations are still capabilities of the whole system, not of individual subsystems. Abstraction level shifts from system-of-systems to system and from system to subsystem capabilities are not done within one Capella model, rather by deriving a new model. Consult the lead system architect or methodology team if unsure. A refined capability realisation (see viewpoint definition AMOD-148) has its name derived from the original physical capability realisation, and its number has an additional decimal enumeration. Example: Original capability realisation is called <M> Deliver value <x> Refined capability realisations are called <M.1> Deliver value <x> to actor <P>,<M.2> Deliver value <x> to actor <Q>... These are just examples; it is possible to split/refine a capability for other reasons than because the value is delivered independently to different actors - see ARCH.192 for details, consult the lead system architect or methodology team if unsure. |
PCR-030 | A refined physical capability realisation (see viewpoint definition AMOD-148) has its description, pre- and post-conditions derived from those of the original physical capability realisation that it refines. In other words, these metadata should be broadly identical to the original capability realisation, except for those parts that make this refined capability realisation distinct from the other refined capability realisations. Example: Original capability realisation <M> had end condition "Value <x> has been delivered to actor <P> OR to actor <Q>" after logical analysis according to ARCH.192 it emerges that the capability can be split into two with the value delivered independently to P or Q; in that case: Refined capability realisation <M.1> has end condition "Value <x> has been delivered to actor <P>" and <M.2> has end condition "Value <x> has been delivered to actor <Q>". |
4.2.2. Physical Function
Guidance ARCH.M.010 Method for definition of functionality
RCAMT-293 - Getting issue details... STATUS
4.2.2.1. General rules
ID | Rule |
---|---|
PFU-100 | Naming convention : All function names are written using sentence case capitalisation. The first word in the name of the function will begin with a capital letter and the remaining words will be lower case. |
PFU-110 | Physical function descriptions may contain further capitalised words if they represent terms, actors, or other model elements defined in the current model. These elements should then be linked in the function description. |
PFU-120 | The usage of abbreviations should be well considered and should only be used in cases where the abbreviation is either standardised (e.g. ETCS, PRM, GoA) or when it improves readability as in the case of known defined abbreviation within the project (e.g. DPS). |
4.2.2.2. Function allocated to interface layer component
ID | Rule |
---|---|
PFU-200 | Naming convention: All function names have the form verb-noun, where the noun is the interface layer upon which the function operates. Strong recommendation The verb should not follow the ones for the control loop pattern, but instead should focus on verbs which underlines synchronisation relationships of the interface layer (e.g. technical term).
|
PFU-210 | The definition of the interface layer functions shall follow the master-mimic pattern, |
4.2.3. Functional Exchange
RCAMT-294 - Getting issue details... STATUS
ID | Rule |
---|---|
PFE-010 | Naming convention : Sentence case - the first letter of the first word in a sentence is capitalised. Note: The name of the functional exchange is not the definition of the interaction (for the definition refer to SFE-140) and will be filtered in diagrams. The name may be freely chosen and should give guidance to the modellers about what is expressed by it. Strong recommendation: Functional exchanges between functions conforming to the pattern could be named using the structure <exchange type> of <state> e.g. Estimated internal state of point position or similar (Estimated position state of point) etc. |
PFE-120 | There should only be one functional exchange per direction between two functions *Warning: multiple functional exchanges between the same pair of functions may imply that the functions have not been decomposed to a primitive level - check before allowing multiple functional exchanges. Note: Each functional exchange will automatically be assigned a unique ID upon creation. |
PFE-130 | Each functional exchange shall have at least one exchange item allocated to it. These exchange items define the functional exchange. |
PFE-140 | All functional exchanges have to be allocated to intended corresponding component exchange. |
4.2.4. Physical Component
4.2.4.1. Node Physical Components (physical components for subsystems created on physical level)
ID | Rule |
---|---|
PCM-110 | Naming convention : A node physical component respresents a subsystem have been named in accordance with the pattern: Subsystem <subsystem name> <abbreviation of subsystem name> |
PCM-120 | Physical ports have direction consistent with the component exchanges they support - this means either Where a physical link supports component exchanges in both directions, the component port has direction INOUT exclusive or Where a physical link supports only incoming component exchanges, the component port has direction IN exclusive or Where a physical link supports only outgoing component exchanges, the component port has direction OUT |
4.2.4.2. Behaviour Physical Components (logical component derived from logical level)
ID | Rule |
---|---|
PCM-200 | Naming convention :
|
PCM-210 | Component ports have direction consistent with the functional exchanges they support - this means either Where a component exchange supports functional exchanges in both directions, the component port has direction INOUT exclusive or Where a component exchange supports only incoming functional exchanges, the component port has direction IN exclusive or Where a component exchange supports only outgoing functional exchanges, the component port has direction OUT |
PCM-220 | Each behaviour physical component has a description. Where an abstract concept is mentioned in the description of a logical component, this is done using a hyperlink to the abstract concept, rather than plain text. Guidance:
|
4.2.4.3. Behaviour Physical Components (interface layer component created on physical level)
ID | Rule |
---|---|
PCM-230 | Naming convention:
Example:
|
PCM-240 | Component ports have direction consistent with the functional exchanges they support - this means either Where a component exchange supports functional exchanges in both directions, the component port has direction INOUT exclusive or Where a component exchange supports only incoming functional exchanges, the component port has direction IN exclusive or Where a component exchange supports only outgoing functional exchanges, the component port has direction OUT |
PCM-250 | Each behaviour physical component has a description. Guidance:
|
PCM-260 | If an interface layer component together with it's adjacent one on the same interface layer shall be reusable the REC/RPL mechanism is used. |
PCM-270 | The definition of the interface layer components shall follow the master-mimic pattern, |
4.2.5. Physical Actor
ID | Rule |
---|---|
PAC-010 | The set of physical actors is identical to the set of system actors. |
4.2.6. Physical Component Exchange
ID | rule |
---|---|
PCE-020 | There exists either zero or one component exchange between any pair of behaviour physical components. |
PCE-030 | Where a functional exchange crosses a the boundary of the allocating behaviour physical component A the function port is assigned to a component port on A and the assigned component port is connected to a component port on another behaviour physical component B and behaviour physical component B hosts the function at the other end of the functional exchange. Corollary: When functions are re-allocated to other behaviour physical components, function port allocations to component ports must be revisited to ensure all three conditions above are still met. The tool will not always stop the user from leaving an invalid port allocation after moving a function. |
PCE-040 | Naming convention: This rules applies when component exchanges transfered from logical level: All component exchanges between two logical components each deployed to a subsystem are named in accordance with the following naming convention (pattern): I_<abbreviation of subsystem A>_<abbreviation of subsystem B>_Abstract_<unique number starting at 01> Example: I_FOT_P_Abstract_01 All component exchanges between two logical components each deployed to the same subsystem are named in accordance with the following naming convention (pattern): C <number> Note: the standard mechnism of Capella is used which provides an automatic generated name and number for the created component exchanges. Example: C 03, C19 All component exchanges between logical components deployed to subsystems and an external actor are named in accordance with the following naming convention (pattern): Names according to rules from logical level. Guidance: logical component exchange name = I_ / HMI_ ActorName>_<name of interface layer>_<unique number starting at 01> Examples: I_PlanningSystem_Application_01 I_PlanningSystem_Application_02 This rule applies when new component exchanges are created on physical level for interface layer components (1): All component exchanges between two interface layer components on different interface layers (inter-layer component exchange) deployed to the same subsystem are named in accordance with the following naming convention (pattern): C_<abbreviation of subsystem><name of interface layer A>_<name of interface layer B> Examples: C_FOT_Application_Presentation This rule applies when new component exchanges are created on physical level for interface layer components (2): All component exchanges between two interface layer components on the same interface layer (intra-layer component exchange) each deployed to one of the adjacent subsystems are named in accordance with the following naming convention (pattern): I_<name of interface layer> Guidance: The name of the interface layer can be e.g. the name of a protocol, technical specification or another term which provides a useful name of the layer. It can contain optional terms to distuinigish interface layers based on architectural models ot abstraction levels. Examples: I_DataCoding I_HTTP_Application I_RaSTA_SafeCommunication I_Ethernet_Physical This rule applies when new component exchanges are created on physical level not related to subsystem interfaces: All component exchanges between two logical components each deployed to the same subsystem are named in accordance with the following naming convention (pattern): C <number> Examples: C 03, C 11 |
4.2.7. Physical Exchange Scenario for Realised Capability
Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios
ID | Rule |
PES-010 | Naming convention : The exchange scenario for the realised capability is named <capability name>[<X>]. Where X is the number of the scenario. |
PES-020 | There exists for each realised Capability at least one scenario. Further scenarios are optional. |
PES-030 | Note: An Exchange Scenario may represent either a more specific and detailed course of the main success scenario OR a deviation from the main success scenario (e.g. due to incidents). Therefore the pre- and postconditions of the Capability may apply to the Exchange Scenario or not. If the pre- and postconditions of the owning capability fully apply to the Exchange Scenario:
If the pre- and postconditions of the owning capability do not (fully) apply to the Exchange Scenario:
|
4.2.8. Physical Exchange Scenario for Interface Layer
ID | Rule |
PES-040 | Naming convention : The exchange scenario for the interface layer is named <interface layer name>[<X>]. Where X is the number of the scenario. |
PES-050 | There may exist an exchange scenario for the Interface Layer. |
PES-060 | If the pre- and postconditions of the owning capability fully apply to the Exchange Scenario:
If the pre- and postconditions of the owning capability do not (fully) apply to the Exchange Scenario:
|
4.2.9. Physical Link
ID | Rule |
---|---|
PLI-010 | Naming convention: A physical link which models an inter-subsystem interface between two physical components is named in accordance with the pattern: <abbreviation of first subsystem name>_<abbreviation of second subsystem name> : <name of interface> Examples: PAS_SL : SCI-OP PE_SL : SCI_CMD FOT_OC-P : SCI_P |
PLI-020 | All component exchanges which cross the border of the physical components that are linked by a physical link are allocated to that physical link. |
4.2.10. REC/RPL
ID | Rule |
---|---|
PRR-010 | Physical REC/RPLs should be used to describe/instantiate that the same component + allocated functions are to be deployed to more than one subsystem depending on the different subsystem boundaries. |
PRR-020 | The REC candidates shall always be a component-function pair (including the function and component ports) i.e. a possible component with a function allocated to it. Note:
|
PRR-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. |
PRR-040 | Following naming conventions shall be applied:
|
PRR-050 | The replicable element (REC) shall not be deployed, only the replicas (RPL) of the logical component should be deployed to the respective subsystem. |
4.2.11. Physical State
4.2.11.1. State of a Physical State Machine
ID | Rule |
---|---|
PST-010 | Naming convention: Sentence case - the first letter of the first word in a sentence is capitalised. State names are referring to a quality of the considered entity.. State names contain either
|
PST-020 | States have a brief description of the qualities that define this state as distinct from the others. |
PST-030 | Only states are used in the model. Modes are not used. Rationale: The behaviour of both elements in the model is identical and the difference in definition, arising from ARCADIA methodology, is somewhat philosophical. Methodology circle recommends standardising on using only states throughout. |
PST-040 | An entry action of a state is modelled as a constraint and the constraint is attached to the state. |
PST-050 | The content of an entry action is defined as follows: <action expression> The action expression is textual and consists of one or more atomic statements. It is conforming to the rules of the chosen textual notation. Guidance: Try to limit the number of statements inside the action expression to keep and increase readibility of the state machine diagram (approx. a maximum number of five statements per action). In addition, avoid conditional statements (e.g. if-else) inside the action expression. |
PST-060 | An exit action of a state is modelled as a constraint and the constraint is attached to the state. |
PST-070 | The content of an exit action is defined as follows: <action expression> The action expression is textual and consists of one or more atomic statements. It is conforming to the rules of the chosen textual notation. Guidance: Try to limit the number of statements inside the action expression to keep and increase readibility of the state machine diagram (approx. a maximum number of five statements per action). In addition, avoid conditional statements (e.g. if-else) inside the action expression. |
4.2.12. Physical Rationale
ID | Rule |
---|---|
PRA-010 | Rationales should be created using the model element requirement (type rationale). |
PRA-020 | The description for the rationale is inserted in the field "text" in Capella. |
PRA-030 | Each rationale has at least one outgoing link to a target model element using the relation type "justifies". |
PRA-040 | Basically, all model elements can be justified by a rationale. At least the following model elements on physical level should be justified:
|
PRA-050 | If a rationale is expanded by an artefact, e.g. a trade study result (AMOD-124) or other type of supporting artefact, the rationale text shall include a reference to the expanding artefact, including (where possible) its document number and a hyperlink to the artefact's current version. |
Guidance:
ARCH.M.110 Method for definition of rationales
4.2.13. Class
4.2.13.1. Location Kind Element
ID | Rules |
---|---|
LKE-005 | Location kinds are modelled in Capella as Classes. |
LKE-010 | Naming convention:
|
LKE-020 | The top-level location kind is modelled as an abstract class with a boolean property isIndoor. When set to FALSE the location kind is exposed to outdoor air and weather conditions e.g. rain, external temperature, humidity, icing, pollution etc. Moreover, it is exposed to other external risks related to human intervention e.g. vandalism. |
LKE-030 | Requirements arising out of standards on environmental conditions must be allocated to one or more location kinds using <<satisfied by>> relationships at the highest applicable level in the taxonomy, unless a requirement is explicitly applicable to a leaf location kind. |
LKE-040 | Standards are modelled as requirements organised in packages. Standards must be unambiguously identifiable by name. Therefore its numeric ID, title and release date must be explicitly modelled as a requirement element. Note: A model-based representation of all parts of a standard are beyond scope. It is the supplier's obligation to prove the conformance of the tenderable elements they supply to the specified Standards by means of official certification, conformance test results etc. |
4.3. Diagram Types and Viewpoints
4.3.1. General Rules
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: [PAB][AMOD-100] RaSTA safe communication protocol for the session layer [Interface layer definition] [PAB][AMOD-143] Interface between Subsystem A and Subsystem B [Inter-subsystem interface definition] |
GRV-020 | Optional rule: A diagram has a visible note as a short text description consisting of the following three parts:
|
GRV-030 | If a note is used on a diagram, it should include the name of the person responsible and the date of creation. Note: if after the design review there is still a need for the note, the name can be removed. |
4.3.2.
4.3.2.1.
PCRB-010 | At least one physical capability realisation is visible on the diagram Guidance (CRB): Show a subset of the capability realisations that focus on a given aspect of the system, consistent with the partitioning of MCBs that was done at system level |
PCRB-020 | At least one physical actor (external to the system) is visible on the diagram |
PCRB-030 | The relationship between two physical capability realisations is shown with generalisation or include or extend relationship. (exclusive OR: only one of these relationships may be established between any pair of physical capability realisations) |
PCRB-040 | The set of relationships between physical capability realisations is logically consistent. (this means avoiding issues like circular dependencies, making sure that include and extend relationships point in the correct direction, etc.) |
4.3.2.2. AMOD-148 Subsystem capability realisation
148-004 | At least one original physical capability realisation is visible on the diagram |
148-006 | Zero or more refined physical capability realisations are visible on the diagram |
148-010 | A refined physical capability realisation may have include or extend relationships to an original physical capability realisation in either direction Guidance: usually, we would expect that a refined capability realisation would extend an original, or that an original would include a refined, but other arrangements are allowed if needed |
148-020 | A refined physical capability realisation may be generalised by an original physical capability realisation but the converse is not permitted. |
148-030 | All original physical capability realisations must have a trace to the corresponding logical capability realisation. Guidance: this would not be visible on the diagram, but is visible when viewing the properties of the physical capability realisation (the property "Realised capability realisations/capabilities" should not be blank). |
4.3.3.
4.3.3.1. General rules
ID | rule |
---|---|
PAB-001 | A subsystem is modelled with a node physical component. |
PAB-002 | A logical component is modelled with a behavior physical component. |
PAB-003 | A interface layer component is modelled with a behavior physical component. |
4.3.3.2. AMOD-080 Subsystem option sketch
ID | Rules |
---|---|
080-010 | This viewpoint is produced as a sketch using any preferred drawing tool. |
080-020 | The notation used by the Capella PAB diagram is used in this view:
|
080-030 | The viewpoint presents two or more alternative subsystem boundaries alongside each other for comparison. |
080-040 | For each alternative subsystem boundary, there is displayed at least two subsystems. |
080-050 | For each alternative subsystem boundary, there is displayed at least two candidate logical components deployed to two subsystems. |
080-060 | Comparing one alternative subsystem boundary with another, there exists at least one difference in the allocation of candidate logical components between the subsystems. |
080-065 | The elements on the viewpoint contain additional info if a logical component/function has been further split on for the subsystem architecture. |
4.3.3.3. AMOD-085 Subsystem architecture definition (single realised capability)
ID | Rules |
---|---|
085-010 | <free text> is name of the realised capablity. |
085-020 | All involved subsystems, physical actors, logical components and functions are shown. |
085-030 | Physical links are not mandatory to be shown. |
4.3.3.4. AMOD-093 Subsystem architecture definition
ID | rule |
---|---|
093-010 | <free text> is "Overall subsystems definition". |
093-020 | All subsystems, physical actors, and logical components are shown. |
093-030 | Functions of logical components and physical actors are not shown. |
093-040 | Physical links are not mandatory to be shown. |
4.3.3.5. AMOD-100 Interface layer definition
ID | rule |
---|---|
100-010 | The functions of the interface layer components are shown. |
100-020 | The functional exchanges between the two interface layer components are shown. |
100-030 | The component exchanges (symbolic ↔ "horizontal") between the two interface layer components are shown. |
100-040 | For the real component exchanges ("vertical") only the component ports are shown. |
100-050 | Symbolic ↔ "horizonal" and real ↔ "vertical" functional exchanges of an interface layer component are allocated to its corresonding component ports through port allocation. |
4.3.3.6. AMOD-143 Inter-subsystem interface definition
ID | rule |
---|---|
143-010 | All functions of all interface layer components are shown. |
143-020 | All interface layer components included in this inter-subsystem interface are shown. |
143-030 | All functional exchanges (symbolic ↔ "horizontal", real ↔ "vertical") between two interface layer components are shown. |
143-040 | All component exchanges (symbolic ↔ "horizontal", real ↔ "vertical") between two interface layer components are shown. |
143-050 | The inter-subsystem interface is modelled and shown as a physical link between the node physical components that model the subsystems. |
143-060 | The symbolic component exchanges of all interface layer components are allocated to the corresponding physical ports through port allocation. |
4.3.3.7. AMOD-111 Subsystem interface definition to external system / actor
ID | rule |
---|---|
111-010 | All functions of all interface layer components are shown. |
111-020 | All interface layer components included in this subsystem interface to external system / actor are shown. |
111-030 | All functional exchanges (symbolic ↔ "horizontal", real ↔ "vertical") between two interface layer components are shown. |
111-040 | All component exchanges (symbolic ↔ "horizontal", real ↔ "vertical") between two interface layer components are shown. |
111-050 | The subsystem interface to external system / actor is modelled and shown as a physical link between the node physical components that models the subsystem and the physical actor representing the external system / actor. |
111-060 | The symbolic component exchanges of all interface layer components are allocated to the corresponding physical ports through port allocation. |
4.3.4. Physical Exchange Scenario (P.ES)
4.3.4.1. General Rules
ID | Rule |
---|---|
PES-010 | The diagram comprises all needed model element lifelines. |
PES-031 | Only the following combined fragments are permitted to be used:
Note: ALT fragments should not usually be needed, since alternative paths are usually modelled in separate scenarios; they continue to be permissible but only where strictly necessary. |
PES-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. |
PES-041 | Where PAR fragments are used, at least two operands are required. |
PES-050 | Optional exchanges ("if-" exchanges that take place under certain conditions, with no alternative) are modelled using the OPT fragment. |
PES-060 | Where OPT fragments are used, OPT fragments have a defined guard condition describing the logical condition under which the exchange takes place. |
PES-061 | When a LOOP combined fragment is used, it shall have a guard condition that describes the logical condition under which the combined fragment takes place. Optional: you can specify a minimum and maximum number of iterations of the loop between parentheses. The format is: (<min.>, <max.>) and it shall be added in a note attached to the LOOP combined fragment (a note because this capability is not supported by Capella). If not specified, a default range (0, *) is assumed. |
PES-070 | Alternate exchanges ("if-then-else" constructs of exchanges that take place under certain conditions, with alternative exchanges under different conditions) are modelled using the ALT fragment. |
PES-080 | Where ALT fragments are used, at least two operands are required. Each operand of the fragment has a defined guard condition describing the logical condition under which the exchange takes place. |
PES-090 | Where ALT fragments are used, the set of guard conditions for the fragment covers all eventualities AND there are no logical intersections between guard conditions (they are mutually exclusive) |
PES-092 | It is allowed to use reference (interaction use) to reduce the complexity of a scenario within one capability. The use should be well justified and really only used where it makes sense. Note: Where a reference is used, the reference object must be manually configured with the correct involved lifelines. Where practical, the reference object must be laid on the diagram in such a way that non-involved lifelines are not covered by the reference object. |
PES-093 | When one capability includes another capability with the "include"-relationship then the scenarios of the included one are referenced using the REF combined fragment (reference/interaction use). No lifelines in the scenarios are shown which do not have any interaction which another lifeline. If another scenario is referenced where the omitted lifeline is then involved, its involvement is only shown in the referenced one, but not the referencing one. Note: This is done for practical reasons and tool constraints deviating from common practice (e.g. SysML) to show every lifeline involved in the capability (i.e. the including capability and the included one). |
PES-094 | When one capability extent another capability with the "extent"-relationship then the scenarios of the extended one are referenced using the REF combined fragment (reference/interaction use) and OPT combined fragment. The OPT fragment includes the condition when the extension is applicable. No lifelines in the scenarios are shown which do not have any interaction which another lifeline. If another scenario is referenced where the omitted lifeline is then involved, its involvement is only shown in the referenced one, but not the referencing one. Note: This is done for practical reasons and tool constraints deviating from common practice (e.g. SysML) to show every lifeline involved in the capability (i.e. the extended capability and the extending one). |
PES-100 | The diagram contains at least one complete sequence of exchanges that is navigable from the start conditions to the end conditions. |
PES-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 as depicted on the diagram. |
PES-110 | All functions of interest 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". |
PES-120 | Exchanges are shown on the diagram:
|
PES-131 | If the pre- and postconditions of the owning capability fully apply to the Exchange Scenario these shall be contained in the diagram. Additional pre- and postconditions of the Exchange Scenario shall be specified in the related field in Capella, representing a refinement or more concrete conditions that apply to this specific scenario. Preconditions will be represented in the upper left corner of the diagram. Capability preconditions will be represented over the specific preconditions Postconditions will be represented in the bottom left corner of the diagram, at the end of the lifelines. Capability postconditions will be represented over the specific postconditions |
PES-132 | If the pre- and postconditions of the owning capability do NOT apply to the Exchange Scenario these shall NOT be contained in the diagram. Pre- and postconditions of the Exchange Scenario shall be specified in the related field in Capella, explicetely specifying which pre- or postconditions are NOT fulfilled in this scenario. The semantic shall be: NOT(<pre/postcondition of owning capability>) Any other additional pre- or postconditions providing context to the specific scenario shall also be specified in the related field in Capella. Preconditions will be represented in the upper left corner of the diagram. Postconditions will be represented in the bottom left corner of the diagram, at the end of the lifelines. |
PES-130 | Where a particular state on a lifeline changes as a result of an interaction, and this is relevant to the scenario, it should be shown using the "State Invariant" graphical element ("State Fragment" in Capella obtained through "Involved State / Mode") State Machine contained in Physical Train Unit here At this level, the trigger of the transition of the state machine should match/be consistent with the interaction depicted in the sequence diagram (see "switch on fwrd" in the example above). |
PES-140 | Where an exchange context is used to illustrate the content of a Sequence Message:
|
4.3.4.2. Guidance
Detailed guidance and explanations can be found in ARCH.M.020 Method for definition of behaviour chapter Method for definition of scenarios
4.3.4.3. AMOD-099 Interface layer exchange scenario
ID | Rule |
---|---|
099-010 | Only one interface layer is considered on the scenario. |
099-020 | The lifelines shown in this scenario are the interface layer components of the considered interface layer. |
099-030 | The functions of the interface layer components involved in this scenario are shown on the corresponding lifeline. |
099-040 | Only the symbolic functional exchanges between the two interface layer components are shown. |
4.3.5. Physical State Machine (P.STM)
4.3.5.1. General rules
ID | Rule |
---|---|
PSTM-010 | There exists only one initial state. |
PSTM-020 | There exists at least one simple state or at least one composite state. |
PSTM-030 | There exists at least one transition outgoing from each state (except for the final state). |
PSTM-040 | There exists at least one transition incoming to each state (except for the initial state). |
PSTM-050 | There exists at least one navigable path along transitions from the initial state to the final state, if a final state is defined. |
PSTM-060 | All transitions have a definition of the conditions for the transition, selected from:
|
PSTM-070 | An action of a transition is defined as follows: <action expression> The action expression is textual and consists of one or more atomic statements. It is conforming to the rules of the chosen notation. |
PSTM-080 | A signal event of a transition is defined as follows: <name of exchange item> The signal event has the same as the exchange item which has the type signal. |
PSTM-090 | A change event of a transition is defined as follows: when (<boolean expression>) The boolean expression is textual and is conforming to the rules of the chosen notation. |
PSTM-100 | A time event of a transition is defined as follows: after (<expression of time value>) The time value is textual and is conforming to the rules of the chosen notation. |
PSTM-110 | A guard condition of a transition is defined as follows: <boolean expression> The boolean expression is textual and is conforming to the rules of the chosen notation. |
4.3.5.2. AMOD-089 Subsystem lifecycle definition
ID | Rule |
---|---|
089-010 | There exists a single state machine diagram showing the whole state machine. |
089-020 | All states and transitions are shown on the diagram. |
4.3.6. Class Diagram (P.CDB)
4.3.6.1. AMOD-095 Location kind definitions
095-010 | There is a single class diagram in the model showing all candidate location kinds. |
095-020 | The diagram contains a location kinds taxonomy i.e. a tree of generalisations with an abstract class location kind element as root.. |
095-030 | Requirements allocated to location kind classes may be fully or selectively shown on the diagram. In case that only a subset of allocated requirements are shown e.g. for readability purposes due to large number of requirements, it shall be explicitly stated in a comment that "requirements shown on the diagram are non-exhaustive. |
Color legend:
Meaning | Color |
---|---|
Naming convention |