Stereotypes
The table below reports the stereotypes of the SAF Profile (used in system models), the stereotypes of the SCM Profile (used to specify or extend the SAF, typically not in system models), and the SCM defined patterns. Use the checkmarks to switch categories on or off, and type into the filter field to narrow the table.
| Name | Description |
|---|---|
| SAF_A2_ARAS | Implementation of Argumentation Assurance Viewpoint Purpose: The Argumentation Assurance Viewpoint presents claims backed up by arguments that are supported by evidence, together with the possibility to counter such claims in a similar manner. Presentation: A block definition diagram (BDD) featuring a claim-argument-evidence pattern (CAE). |
| SAF_A2_CSTD | Implementation of Common Standards Definition Viewpoint Purpose: The Standards Definition Viewpoint supports the definition of applicable standards, and their relationships, e.g., for format and protocol specifications, regulations, and engineering documents that are used throughout the system life cycle. It provides the meta-data for the applied standards, guidance and policy, e.g., issue, version, issue date, and publisher. The Viewpoint helps to keep track of changes to the set of applicable documents and of new versions of applied standards. Links should be used to refer to documents external to the architecture description. Presentations:
|
| SAF_A2_CSTD_Table | Implementation of Common Standards Definition Viewpoint Purpose: The Standards Definition Viewpoint supports the definition of applicable standards, and their relationships, e.g., for format and protocol specifications, regulations, and engineering documents that are used throughout the system life cycle. It provides the meta-data for the applied standards, guidance and policy, e.g., issue, version, issue date, and publisher. The Viewpoint helps to keep track of changes to the set of applicable documents and of new versions of applied standards. Links should be used to refer to documents external to the architecture description. Presentations:
|
| SAF_A2_GRID | Implementation of SAF Concepts |
| SAF_A2_GRID_Table | Implementation of Grid Definition Viewpoint Purpose: The Grid Definition Viewpoint serves as overview about the of the Views present in a System Model. Presentations:
|
| SAF_A2_TRMD_Table | Implementation of Common Terms Definition Viewpoint Purpose: The Common Terms Definition Viewpoint supports the definition of applicable terms used in standards or defined during the systems engineering activities. Presentations:
|
| SAF_A7_PRND_Table | Not implementing a concept |
| SAF_A8_EATR | Implementation of EA Traceability Viewpoint Purpose: The EA Traceability Viewpoint provides a mapping between SAF System Model elements and model elements of an upper Enterprise Architecture (EA) Model. The mapping is accomplished by three kinds of relations - a representation relation which states that an element of the SAF System Model and the related model element in the EA model represents the same entity. - a derivation relation, stating that an element of the SAF System Model is derived from an EA model element. - an informed relation, stating that an element of the SAF System Model is related to the respective EA Element. Presentations:
|
| SAF_A8_EATR_Matrix | Implementation of EA Traceability Viewpoint Purpose: The EA Traceability Viewpoint provides a mapping between SAF System Model elements and model elements of an upper Enterprise Architecture (EA) Model. The mapping is accomplished by three kinds of relations - a representation relation which states that an element of the SAF System Model and the related model element in the EA model represents the same entity. - a derivation relation, stating that an element of the SAF System Model is derived from an EA model element. - an informed relation, stating that an element of the SAF System Model is related to the respective EA Element. Presentations:
|
| SAF_A8_EATR_Table | Implementation of EA Traceability Viewpoint Purpose: The EA Traceability Viewpoint provides a mapping between SAF System Model elements and model elements of an upper Enterprise Architecture (EA) Model. The mapping is accomplished by three kinds of relations - a representation relation which states that an element of the SAF System Model and the related model element in the EA model represents the same entity. - a derivation relation, stating that an element of the SAF System Model is derived from an EA model element. - an informed relation, stating that an element of the SAF System Model is related to the respective EA Element. Presentations:
|
| SAF_Adversary | Adversary definition from NIST Special Publication 800-30, Glossary [APPENDIX B]: “Individual, group, organization, or government that conducts or has the intent to conduct detrimental activities.” Implementation of SAF Concept Adversary |
| SAF_Argument | An argument is a rule that provides the bridge between what we know or are assuming (sub-claims, evidence) and the claim we are investigating. The argument used depends on the type, trustworthiness and extent of available evidence and the nature of the claim. Implementation of SAF Concept Argument |
| SAF_ArgumentClaimSupport | Specifies the fact that a claim is supported by one or more arguments via a claim-argument relation. Implementation of SAF Concept Claim supporting Argument |
| SAF_Asset | Asset Definition in ISO 27005, Chapter „Identifying and describing information security risks“ [§7.2.1] (Page 17): „An asset is anything that has value to the organization and therefore requires protection.“ Asset Definition NIST SP 800-160v1r1 „The Concept of Assets“ [§3.4] Page 16: „An asset is an item of value. There are many different types of assets. Assets are broadly categorized as either tangible or intangible. Tangible assets include physical items, such as hardware, computing platforms, other technology components, and humans. Intangible assets include humans, firmware, software, capabilities, functions, services, trademarks, intellectual property, data, copyrights, patents, image, or reputation.“ Implementation of SAF Concept Asset |
| SAF_Assumption | Implementation of SAF Concept Assumption |
| SAF_AttackAction | Implementation of SAF Concept Adversary Attack Action Target Misuse Case |
| SAF_AttackPath | The Aversary uses an Attack Vector to attack a Security Objective of an Asset. Implementation of SAF Concept Security Objective ADV use Attack Path to attack SO Adversary |
| SAF_AttackVector | Not implementing a concept |
| SAF_Availability | Availability is a Security Objective. Availability: Ensuring timely and reliable access to and use of information. [44 U.S.C., Sec. 3542] Implementation of SAF Concept Availability |
| SAF_C1_SCXD | Implementation of System Context Definition Viewpoint Purpose: The System Context Definition Viewpoint defines on a conceptual level how the SOI is embedded in its environment, i.e., where the boundary of the SOI is and who the external entities are the SOI interacts with (e.g., users, other external systems, environmental conditions, etc.). In addition, the System Context Definition Viewpoint serves as architecture concept to demonstrate how the architecture description defined in the Operational Context Definition Viewpoint is realized. Presentations:
|
| SAF_C1_SCXD_Table | Implementation of System Context Definition Viewpoint Purpose: The System Context Definition Viewpoint defines on a conceptual level how the SOI is embedded in its environment, i.e., where the boundary of the SOI is and who the external entities are the SOI interacts with (e.g., users, other external systems, environmental conditions, etc.). In addition, the System Context Definition Viewpoint serves as architecture concept to demonstrate how the architecture description defined in the Operational Context Definition Viewpoint is realized. Presentations:
|
| SAF_C1_SCXE | Implementation of System Context Exchange Viewpoint Purpose: The System Context Exchange Viewpoint serves for the identification and definition of external interfaces of the SOI that are used to interact, e.g., users, external systems, and other external entities defined in the given context of the SOI. The System Context Exchange Viewpoint * identifies system interfaces on a functional level, * states to which external entities the system interfaces are connected to, * and defines the usage of interfaces, e.g., when only a subset of the interface is used. Presentations:
|
| SAF_C1_SCXE_Table | Implementation of System Context Exchange Viewpoint Purpose: The System Context Exchange Viewpoint serves for the identification and definition of external interfaces of the SOI that are used to interact, e.g., users, external systems, and other external entities defined in the given context of the SOI. The System Context Exchange Viewpoint * identifies system interfaces on a functional level, * states to which external entities the system interfaces are connected to, * and defines the usage of interfaces, e.g., when only a subset of the interface is used. Presentations:
|
| SAF_C1_SUCD | Implementation of System Use Case Viewpoint Purpose: The System Use Case Viewpoint provides an outside view on the system functionality from the perspective of the system users and contributes to the definition of system requirements and system usage. The intended system use may be captured as free-text use case description, as well as storytelling approach on a coarse level of detail. The main system exchange partners participating in the intended system use are identified. System use cases are related to a specific system context. System use cases are derived from operational scenarios elaborated during mission analysis. Presentations:
|
| SAF_C1_SUCD_Table | Implementation of System Use Case Viewpoint Purpose: The System Use Case Viewpoint provides an outside view on the system functionality from the perspective of the system users and contributes to the definition of system requirements and system usage. The intended system use may be captured as free-text use case description, as well as storytelling approach on a coarse level of detail. The main system exchange partners participating in the intended system use are identified. System use cases are related to a specific system context. System use cases are derived from operational scenarios elaborated during mission analysis. Presentations:
|
| SAF_C2_SCYD | Implementation of System Capability Definition Viewpoint Purpose: The System Capability Definition Viewpoint defines a taxonomy of Capabilities including composition, specialization, and dependency relationships between System Capabilities. Note: Connecting capabilities to requirements creates a linkage between two different types of conceptual problem description that helps manage the complexity of the system. At a high level of abstraction, capabilities allow an system architect to plan phases of the system evolution without the need to bear details in mind. Those details will not be lost if they are captured as requirements and traced to a corresponding capability. There is one key difference between capabilities and requirements: Requirements come from different sources, sponsored by different stakeholders, and are usually captured at different levels of abstraction. In contrast, capabilities should always represent a coherent and consolidated view of the system. Presentations:
|
| SAF_C2_SCYD_Table | Implementation of System Capability Definition Viewpoint Purpose: The System Capability Definition Viewpoint defines a taxonomy of Capabilities including composition, specialization, and dependency relationships between System Capabilities. Note: Connecting capabilities to requirements creates a linkage between two different types of conceptual problem description that helps manage the complexity of the system. At a high level of abstraction, capabilities allow an system architect to plan phases of the system evolution without the need to bear details in mind. Those details will not be lost if they are captured as requirements and traced to a corresponding capability. There is one key difference between capabilities and requirements: Requirements come from different sources, sponsored by different stakeholders, and are usually captured at different levels of abstraction. In contrast, capabilities should always represent a coherent and consolidated view of the system. Presentations:
|
| SAF_C2_SETD | Implementation of System Exchange Type Definition Viewpoint Purpose: The System Exchange Type Definition Viewpoint captures system wide concepts and collects type definitions for any exchanged item, e.g., information, material, or energy, of the Conceptual Domain for Functional and Logical Architecture. Its purpose is to define these item types and their relationships. Furthermore, the System Exchange Type Definition Viewpoint specifies the data types, entity types, related value types, and units that are used by the SOI. Note: Conceptual Exchange Types are used as types of function input and output in the Functional Archtecture, and for types of interfaces in the Logical Architecture. They specify what is to be exchanged but not how. Presentations:
|
| SAF_C2_SETD_Table | Implementation of System Exchange Type Definition Viewpoint Purpose: The System Exchange Type Definition Viewpoint captures system wide concepts and collects type definitions for any exchanged item, e.g., information, material, or energy, of the Conceptual Domain for Functional and Logical Architecture. Its purpose is to define these item types and their relationships. Furthermore, the System Exchange Type Definition Viewpoint specifies the data types, entity types, related value types, and units that are used by the SOI. Note: Conceptual Exchange Types are used as types of function input and output in the Functional Archtecture, and for types of interfaces in the Logical Architecture. They specify what is to be exchanged but not how. Presentations:
|
| SAF_C2_SFBS | Implementation of System Functional Breakdown Structure Viewpoint Purpose: The System Functional Breakdown Structure Viewpoint defines the structured, modular functional breakdown of the SOI beginning with System Processes, over identified System Functions further refined down to System Partial Functions. The reuse of System Functions, and System Partial Functions over Function Trees of the SOI is facilitated. Presentations:
|
| SAF_C2_SSTD | Implementation of System Structure Definition Viewpoint Purpose: The System Structure Definition Viewpoint describes how the system is decomposed into a hierarchical structure of conceptual elements. These conceptual system parts will be used to assign responsibilty to functions to them (divide & conquer principle). It covers related concepts and principles that define what the system does and is widely reusable among similar systems like product families, or product generations. Presentation: A block definition diagram (BDD) featuring the conceptual system block and conceptual system blocks for parts of the system. These elements are connected to the system block by means of aggregation relationships. Note: Multiple relationships to a kind of element are allowed. This means, that this kind of element is used in several roles. |
| SAF_C3_SFRE | Implementation of System Functional Refinement Viewpoint Purpose: The System Functional Refinement Viewpoint analyses decomposition of System Functions into System Partial Functions in order achieve understanding and agreement about the System functions sufficient to derive system requirements. Presentation: Activity Diagram featuring System Partial Functions, functional exchange between partial functions. There are explicitely no Swimlanes and no allocations to structure. |
| SAF_C3_SPRO | Implementation of System Process Viewpoint Purpose: The System Process Viewpoint provides the functional representation of the system using a black-box approach * the representation of the SOI and all Context Elements * the System Functions the SOI shall be able to perform * the Context Functions the Context Elements are expected to perform * the exchange between SOI System Functions and Context Functions of Context Elements * the functional flows crossing the boundary between SOI and Context Elements Presentations:
|
| SAF_C3_SPRO_Table | Implementation of System Process Viewpoint Purpose: The System Process Viewpoint provides the functional representation of the system using a black-box approach * the representation of the SOI and all Context Elements * the System Functions the SOI shall be able to perform * the Context Functions the Context Elements are expected to perform * the exchange between SOI System Functions and Context Functions of Context Elements * the functional flows crossing the boundary between SOI and Context Elements Presentations:
|
| SAF_C3_SSTA | Implementation of System State Viewpoint Purpose: The System State Viewpoint defines the conditions of the SOI or parts of thereof that constrain the execution of System Functions. System States are used as pre- or post-condition of System Use Cases, and as constraints within the definition of System Functions to specifying valid transitions. Valid transitions between System States and the conditions for transitioning are specified in system wide concepts captured in System Requirements. Presentations:
|
| SAF_C3_SSTA_Table | Implementation of System State Viewpoint Purpose: The System State Viewpoint defines the conditions of the SOI or parts of thereof that constrain the execution of System Functions. System States are used as pre- or post-condition of System Use Cases, and as constraints within the definition of System Functions to specifying valid transitions. Valid transitions between System States and the conditions for transitioning are specified in system wide concepts captured in System Requirements. Presentations:
|
| SAF_C4_SCXI | Implementation of System Context Interaction Viewpoint Purpose: The System Context Interaction Viewpoint describes the System external behavior based on the exchange between Logical SOI and Logical Context Elements Usage in a given System Context. It depicts the sequence of interactions between the Logical SOI, the Context Elements and the exchanged Domain Item Kinds needed to accomplish a given System Process. Note: The System Context Interaction Viewpoint may refine a System Use Case. Presentation: A sequence diagram featuring the flow of control between SOI and Context Elements Roles of a System Context to achieve one outcome of a System Use Case. Note: This diagram depicts the sending and receiving of messages between the interacting entities called lifelines, where time is represented along the vertical axis. The lifelines representatives are part properties typed by a System Context Elements. |
| SAF_C4_SIEX | Implementation of System Internal Exchange Viewpoint Purpose: The System Internal Exchange Viewpoint serves for the identification and definition of interfaces of elements of the conceptual system. also, the delegation of system element interfaces to the conceptual system boundary interfaces is covered. The System Internal Exchange Viewpoint * identifies system element interfaces on a conceptual level * states to which other conceptual elements the interfaces are connected to * assigns conceptual interface definitions to interfaces * defines the usage of interfaces, e.g., if only a subset of the interfaces is used * defines the delegation of conceptual system element interfaces to the conceptual system boundary interfaces Presentation: One or more IBDs featuring the SOI boundary, the conceptual elements of the SOI, as well as the connectors for each identified SOI interface delegation to conceptual SOI elements. An interface is a connection resource for hooking on the conceptual SOI elements to other conceptual SOI elements. Item flows are defined for each exchange on the identified interface. Note: Please use more than one IBD focused on different areas of interest to keep the view comprehensive. |
| SAF_C4_SITI | Implementation of System Internal Interaction Viewpoint Purpose: The SystemInternal Interaction Viewpoint describes System internal behavior based on the exchange between the Conceptual Systems internal Roles It depicts the sequence of interactions between the Conceptual SOI Elements and the exchanged Domain Item Kinds. Presentation: A sequence diagram featuring the flow of control between Conceptual Internal Roles within the SOI. Note: This diagram depicts the sending and receiving of messages between the interacting entities called lifelines where time is represented along the vertical axis. The lifeline representatives are part properties typed by Conceptual System. |
| SAF_C5_SIFD | Implementation of System Interface Definition Viewpoint Purpose: The System Interface Definition Viewpoint captures system wide concepts defining interfaces. It allows to adopt long-lived standards and to harmonize conceptual interface definitions to improve interchangeability, interoperability, and portability. Presentations:
|
| SAF_C6_SRQD_Table | Implementation of System Requirement Definition Viewpoint Purpose: The System Requirement Definition Viewpoint specifies functions, non-functional properties, or constraints of the System. System Requirements are captured, the interrelationships between Functional and Non-Functional Requirements on the same level of abstraction and the traceability to Stakeholder Requirements are depicted. Presentation: A tabular format listing * unique requirement ID, text, and attributes, * traceability reference to Stakeholder Requirements, * traceability reference to depended Requirements on the same level of abstraction. |
| SAF_C7_ASID | Implementation of Asset Identification Viewpoint Purpose: The Asset Identification viewpoint defines the assets that must be taken into account in the risk analysis. This is the first step of the risk management process according to DIN EN ISO/IEC 27005:2024-05. |
| SAF_C7_ASID_Table | Implementation of Asset Identification Viewpoint Purpose: The Asset Identification viewpoint defines the assets that must be taken into account in the risk analysis. This is the first step of the risk management process according to DIN EN ISO/IEC 27005:2024-05. |
| SAF_C7_IMAN | Implementation of Impact Analysis Viewpoint Purpose: tbd |
| SAF_C7_IMAN_Table | Implementation of Impact Analysis Viewpoint Purpose: tbd |
| SAF_C7_RIAN | Implementation of Security Risk Analysis Viewpoint Purpose: tbd |
| SAF_C7_RIAN_Table | Implementation of Security Risk Analysis Viewpoint Purpose: tbd |
| SAF_C7_SECT | Implementation of Security Context Viewpoint Purpose: The Security Context viewpoint defines the Security Context, that describes the environment and all security relevant aspects of a System. This is the first step of the risk management process according to DIN EN ISO/IEC 27005:2024-05. The Security Context describes all internal and external elements, boundaries, interconnections and assumptions that referes to the security of a system or an asset. DIN ISO 31000:2018-10 defines: "The context of the risk management process should be derived from an understanding of the external and internal environment in which the organisation operates and should reflect the specific environment of the activity to which the risk management process is applied." |
| SAF_C7_SECT_Table | Implementation of Security Context Viewpoint Purpose: The Security Context viewpoint defines the Security Context, that describes the environment and all security relevant aspects of a System. This is the first step of the risk management process according to DIN EN ISO/IEC 27005:2024-05. The Security Context describes all internal and external elements, boundaries, interconnections and assumptions that referes to the security of a system or an asset. DIN ISO 31000:2018-10 defines: "The context of the risk management process should be derived from an understanding of the external and internal environment in which the organisation operates and should reflect the specific environment of the activity to which the risk management process is applied." |
| SAF_C7_THSC | Implementation of Threat Szenario Viewpoint Purpose: tbd |
| SAF_C7_THSC_Table | Implementation of Threat Szenario Viewpoint Purpose: tbd |
| SAF_C8_SCYM_Table | Implementation of System Capability Mapping Viewpoint Purpose: The System Capability Mapping Viewpoint describes the relationships of System Capabilities. The reasoning for System Capabilities as support for System Use Cases and the contribution of System Processes to Capabilities are described. Furthermore, the mapping of System Capabilities to Operational Capabilities are identified. Presentation: A tabular format listing the relationships of System Capabilities to Operational Capabilities, System Use Cases, System Process Activities, and System Requirements. |
| SAF_C8_SFUM_Matrix | Implementation of System Function Mapping Viewpoint Purpose: The System Function Mapping Viewpoint supports the definition of assignment of system functions (and their sub functions) to conceptual system elements. Presentation: A FBS to CBS mapping matrix featuring * Functional Breakdown Structure (FBS) * Conceptual Breakdown Structure (CBS) * Allocation from system functions and system partial functions to conceptual system elements |
| SAF_C8_SRQT_Matrix | Implementation of System Requirement Traceability Viewpoint Purpose: The System Requirement Traceability Viewpoint specifies for every System Requirement the traceability to the functional domain level * System Use Case * System Capability * System Context Definition * System Context Exchange * System Context Interaction * System Process * System State Presentation: A dependency matrix featuring relationships for every System Requirement to the functional domain level * System Use Case * System Capability * System Context Definition * System Context Exchange * System Context Interaction * System Process * System State |
| SAF_Claim | A claim is a true/false statement about a property of a particular object. A claim is just what you might consider it to be from common usage of the term; an idea that someone is trying to convince somebody else is true. An example claim could be made on a train, e.g., the train is safe. Implementation of SAF Concept Claim |
| SAF_ClaimAboutSubjectMaking | Specifies the fact that a claim is made about an identified subject matter. Implementation of SAF Concept Subject of Claim being made about Claim |
| SAF_ClaimClaimableItemSupport | Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is supported by one or more claims. Implementation of SAF Concept Claimable Item supporting Claim |
| SAF_ClaimSubject | Note: A claim cannot be generic, it has to be about something, it has to have a defined subject, e.g., system safety. Implementation of SAF Concept Subject of Claim |
| SAF_ClaimableItem | A claim, argument, and evidence are all types of the abstract concept of a claimable item. This allows a counter-claim to be made about any type of claimable item and a claim to support any type of claimable item. Implementation of SAF Concept Claimable Item |
| SAF_Claimant | A party asserting claims. Implementation of SAF Concept Claimant |
| SAF_ClaimantClaimMaking | Specifies the fact that a claim is made by a defined claimant. Implementation of SAF Concept Claim making Claimant |
| SAF_ConceptualContext | Specifies the fact that a System Context for a System of Interest is defined on Conceptual Level. Implementation of SAF Concept Conceptual System Context |
| SAF_ConceptualContextElementActing | Implementation of SAF Concepts |
| SAF_ConceptualContextRole | Specifies the fact that a Conceptual Context Element acts in a given Conceptual System Context. Implementation of SAF Concept Conceptual System Context Conceptual Context Element Role Conceptual Context Element |
| SAF_ConceptualContextRole_SoI | Specifies the fact that a Conceptual System acts as SOI exists in a given Conceptual System Context. Implementation of SAF Concept Conceptual System Context Conceptual SOI Role Conceptual System |
| SAF_ConceptualEnvironment | A Conceptual Environment in the Conceptual Domain, outside the SOI scope, interacting with the SOI. E.g., air, dirt, sun, road. Implementation of SAF Concept Conceptual Environment |
| SAF_ConceptualExchangeType | Specification for any type of conceptual item (energy, material, information, etc.) to be exchanged on Conceptual (Functional Architecture and Logical Architecture) Level. The Conceptual Exchange Type is agnostic to any realization on Physical Level. Implementation of SAF Concept Conceptual Exchange Type |
| SAF_ConceptualExchangeTypeComposition | Specifies the fact that a Conceptual Exchange Type consists of one or more Conceptual Exchange Types. Implementation of SAF Concept Conceptual Exchange Type composed of Conceptual Exchange Type |
| SAF_ConceptualExchangeTypeDerivation | Specifies the fact that a Conceptual Exchange Type on system level is derived from an Operational Exchange Type. Implementation of SAF Concept Operational Exchange Type deriving from Conceptual Exchange Type |
| SAF_ConceptualInterfaceDefinition | Specifies the exchange capabilities of an interaction point on Conceptual Level. Implementation of SAF Concept Conceptual Interaction Point Definition |
| SAF_ConceptualInternalRole | Not implementing a concept |
| SAF_ConceptualSystem | Implementation of SAF Concepts |
| SAF_ConceptualUser | The Conceptual User is the representation for a human in the Conceptual Domain, outside the SOI scope, interacting with the SOI. Implementation of SAF Concept Conceptual User |
| SAF_Confidentiality | Confidentiality is a Security Objective. Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. [44 U.S.C., Sec. 3542] Implementation of SAF Concept Confidentiality |
| SAF_ConformsStandard | Specifies, that a SAF Element may be conform to one or more Standards. Implementation of SAF Concept Standard conform to Any SAF Element |
| SAF_Consequence | The violation of an Security Objective has a Consequence. NIST SP 800-160v1r1 and ISO/IEC 15026-1:2019 describing Consequence as following: "Effect (change or non-change), usually associated with an event or condition or with the system and usually allowed, facilitated, caused, prevented, changed, or contributed to by the event, condition, or system." Implementation of SAF Concept Consequence |
| SAF_ContextAction | Not implementing a concept |
| SAF_ContextElementRepresentation | Specifies the fact that a System Context Element is represented by a SOI Stakeholder. Implementation of SAF Concept System of Interest Stakeholder represented by System Context Element |
| SAF_ContextFunction_deprecated | Specifies the fact that a fundamental action or task is expected to be carried out by an External Entity. Note: The intention is to capture the expectations and to explicitly dissect the functionality. This must not be interpreted as an attempt for a behavior specification of an External Entity. Capturing this valuable information is the basis to reach agreement on the functionality at the System boundary by clarifying the expectations about what is performed by Context Elements. Implementation of SAF Concept Context Function |
| SAF_CounterClaim | A party's claim is a counter-claim if one party asserts claims in response to the claims of another. Implementation of SAF Concept CounterClaim |
| SAF_CounterClaimClaimableItemMaking | Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is countered by one or more claims. Implementation of SAF Concept Claimable Item countering CounterClaim |
| SAF_D2_CCND | Not implementing a concept |
| SAF_D2_COTD | Implementation of Framework Concept Definition Viewpoint Purpose: The Framework Concept Viewpoint allows to define SE concepts and their relationships to be supported by the SAF. It shall specifiy * the concepts with comprehensive documentation * the relationships of concepts with comprehensive documentation and allowable multiplicities * constraints among relations and concepts if applicable. The viewpoint is intended to be used for development or extension of the SAF. Presentations:
|
| SAF_D2_COTD_Table | Implementation of Framework Concept Definition Viewpoint Purpose: The Framework Concept Viewpoint allows to define SE concepts and their relationships to be supported by the SAF. It shall specifiy * the concepts with comprehensive documentation * the relationships of concepts with comprehensive documentation and allowable multiplicities * constraints among relations and concepts if applicable. The viewpoint is intended to be used for development or extension of the SAF. Presentations:
|
| SAF_D2_STKD_Table | Implementation of Framework Stakeholder and Concern Definition Viewpoint Purpose: The Framework Stakeholder Viewpoint provides definitions for Architecture Framework Stakeholders having an interest in SAF Viewpoints. The Interest is formulated using Concerns. A Rationale formulates why a Stakeholder has a certain concern. The viewpoint is intended to be used for development or extension of the SAF. Presentations:
|
| SAF_D2_STYD_Table | Implementation of Framework Stereotype Overview Viewpoint Purpose: The Framework Stereotype Viewpoint provides an overview over all stereotypes provided by SAF. Presentation: A table featuring the stereotypes of the SAF profile and their documentation. |
| SAF_D2_VPTD | Implementation of Framework Viewpoint Definition Viewpoint Purpose: The Framework Viewpoint Definition Viewpoint serves as a specification for any SAF viewpoints in the context of the development of SAF. The Viewpoint shall specify * an example of a conforming view * purpose * applicability * exposed concepts, * presentation forms for the conforming views * related viewpoints * stereotypes used in the conforming views The viewpoint is intended to be used for development or extension of the SAF. Presentation: A View and Viewpoints Diagram featuring one *SCM Viewpoint* Element, one *SCM_View* element, a *conform* relationship among them. Additionally all *SCM_Concept* elements that are of interest in the viewpoint. Additionally *expose* relationships for all concepts that help satisfy the viewpoints concerns. Note, that the consequence of exposing a concept is, that the implementation of the concept must appear in the diagram/table/matrix that implements the viewpoint. |
| SAF_D2_VPTI | Implementation of Framework Viewpoint Implementation Viewpoint Purpose: The Framework Viewpoint Implementation Viewpoint defines the implementation of SE concepts exposed by SAF Viewpoints. It serves as the basis for profile implementations of SAF. It shall specify * for each exposed concept an implementation * an implementation for each presentation of the viewpoint * full traceability from implementation The viewpoint is intended to be used for development or extension of the SAF. Presentation: A Profile Diagram featuring SCM_Concept elements for the exposed concepts of a viewpoint, stereotypes from the SAF Profile implementing the concepts, and SCM_RealizeConcept relationships tracing the implementation to the implemented concept. If concepts are implemented directly by UML Metaclasses or by SysML profile elements, they shall be shown on the diagram and related to the concepts. There are additional relationships SCM_Attribute, SCM_TypedBy and SCM_ContainedIn, that can be used to specify details of the implementation, e.g. if a concept is to be implemented by the fact that one element is part of an other element. Please see the SAF Development Guide how to do this. |
| SAF_D2_VPTO | Implementation of Framework Viewpoint Overview Viewpoint Purpose: The Framework Viewpoint Overview Viewpoint provides an overview about the Viewpoints in SAF from a SAF Developers perspective. It shall specify * the viewpoints available * their location in the grid by domain and aspect * their maturity of development The viewpoint is intended to be used for development or extension of the SAF. Presentations:
|
| SAF_D2_VPTO_Table | Implementation of SAF Concepts |
| SAF_DerivedFromEA | Specifies that any SAF element may derive from any EA elements. Implementation of SAF Concept Any EA Element derives from Any SAF Element |
| SAF_Diagram | Not implementing a concept |
| SAF_DocumentReference | Not implementing a concept |
| SAF_Effect | Implementation of SAF Concept Affected Acteurs CON has Effect On AA Consequence |
| SAF_Evidence | An evidence is an artifact that establishes facts that can be trusted and lead directly to a claim. In projects there can many sources of information, but what makes this evidence is the support or rebuttal it gives to a claim. Implementation of SAF Concept Evidence |
| SAF_EvidenceArgumentReinforcement | Specifies the fact that an argument is reinforced by one or more evidence via a argument-evidence relation. Implementation of SAF Concept Argument reinforcing Evidence |
| SAF_Example | Not implementing a concept |
| SAF_Function | Specifies the fundamental action or task that have to take place in the System in accepting and processing the inputs and in processing and generating the outputs. A System Function * accepts input from the System boundary * exposes its output at the System boundary * changes the System's State * is dependent on System's State Note: A System Function does not need to expose observable output, when it changes the System's state in a way that is observable by other system functions. Furthermore, a System Function does not need to accept any input from the system boundary, when it is dependent on the System State, which in turn is changeable by other System Functions. Implementation of SAF Concept System Function |
| SAF_FunctionAction | Specifies a General Usage of a General Function within one or more other General Functions. Implementation of SAF Concept General Function General Functional Usage General Function |
| SAF_FunctionAsset | System Functions are intangible resources of the System. intangible resources are types of Assets. The NIST SP 800-160v1r1 - Engineering Trustworthy Secure Systems describes them following: „There are many different types of assets. Assets are broadly categorized as either tangible or intangible. Tangible assets include physical items, such as hardware, computing platforms, other technology components, and humans. Intangible assets include humans, firmware, software, capabilities, functions, services, trademarks, intellectual property, data, copyrights, patents, image, or reputation.“ Implementation of SAF Concept Security Context SF is Asset in Security Context System Function |
| SAF_FunctionContribution | Not implementing a concept |
| SAF_FunctionSupport | Specifies the fact that a System Function supports one or more System Capabilities. Implementation of SAF Concept System Capability supporting System Function |
| SAF_Glossary | specifies a coherent set of terms. Implementation of SAF Concept Glossary |
| SAF_ImpactedActeurs | Implementation of SAF Concept Affected Acteurs |
| SAF_InformedByEA | Specifies that any SAF element may be informed by any EA elements. Implementation of SAF Concept Any EA Element informed by Any SAF Element |
| SAF_Integrity | Integrity is a Security Objective. Integrity: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. [44 U.S.C., Sec. 3542] Implementation of SAF Concept Integrity |
| SAF_InterfaceLayerRelationship | Implementation of SAF Concepts |
| SAF_IssuedBy | Specifies the fact that a standard is issued by an organization of standardization. Implementation of SAF Concept Standardization Organization issued by Standard |
| SAF_LikelihoodParameter | Implementation of SAF Concept Likelyhood Parameter |
| SAF_LogicalExternalSystem_deprecated | Not implementing a concept |
| SAF_LogicalResource | tangible & intangible resources are types of Assets. The NIST SP 800-160v1r1 - Engineering Trustworthy Secure Systems describes them following: „There are many different types of assets. Assets are broadly categorized as either tangible or intangible. Tangible assets include physical items, such as hardware, computing platforms, other technology components, and humans. Intangible assets include humans, firmware, software, capabilities, functions, services, trademarks, intellectual property, data, copyrights, patents, image, or reputation.“ Implementation of SAF Concept Intangible Resource |
| SAF_LogicalSOI_deprecated | Not implementing a concept |
| SAF_O1_OCXD | Implementation of Operational Context Definition Viewpoint Purpose: The Operational Context Definition Viewpoint provides the operational contexts and the involved operational performers necessary to support a specific set of operational capabilities. Presentation: A block definition diagram (BDD) featuring the identified Operational Performers playing a role in the Operational Context being addressed. |
| SAF_O1_OCXE | Implementation of Operational Context Exchange Viewpoint Purpose: The Operational Context Exchange Viewpoint provides the operational exchange of systems, personnel, information, material, energy, etc. between operational performers. Presentations:
|
| SAF_O1_OSTY | Implementation of Operational Story Viewpoint Purpose: The Operational Story Viewpoint * captures operational stories within operational contexts and their relation to operational performers, thus enables storytelling * illustrates the operational background from the Stakeholder perspective * serves as starting point to identify Stakeholders and/or context elements * fosters the communication among different Stakeholders Presentation: A use case diagram featuring model elements representing operational stories, the context in they're taking place and operational performers involved. Note: Illustrations, drawings, sketches, etc., and/or descriptions in free text may provide a comprehensive understanding of the operational mission. |
| SAF_O2_OCYD | Implementation of Operational Capability Definition Viewpoint Purpose: The Operational Capability Definition Viewpoint defines a taxonomy of Capabilities from a Stakeholder’s perspective including composition, specialization, and dependency relationships between Operational Capabilities. Presentation: A block definition diagram (BDD) featuring Operational Capabilities, their composition, specialization, and dependency relationships. |
| SAF_O2_OETD | Implementation of Operational Exchange Type Definition Viewpoint Purpose: The Operational Exchange Type Definition Viewpoint captures enterprise wide concepts and collects type definitions for any exchanged item of the Operational Domain. Its purpose is to define these item types and their relationships. Presentations:
|
| SAF_O2_OETD_Table | Implementation of Operational Exchange Type Definition Viewpoint Purpose: The Operational Exchange Type Definition Viewpoint captures enterprise wide concepts and collects type definitions for any exchanged item of the Operational Domain. Its purpose is to define these item types and their relationships. Presentations:
|
| SAF_O2_OPRF | Implementation of Operational Performer Definition Viewpoint Purpose: The Operational Performer Definition Viewpoint represents the taxonomy of the identified Operational Performers, if existing and relevant for the understanding of the operation of the intended solution. Presentations:
|
| SAF_O2_OPRF_Table | Implementation of Operational Performer Definition Viewpoint Purpose: The Operational Performer Definition Viewpoint represents the taxonomy of the identified Operational Performers, if existing and relevant for the understanding of the operation of the intended solution. Presentations:
|
| SAF_O2_STID | Implementation of Stakeholder Identification Viewpoint Purpose: The Stakeholder Identification Viewpoint of the operational domain strives to identify Stakeholders, who's concerns shall be considered, and adequatley adressed by the intended solution. Presentation: A block definition diagram (BDD) depicting the identified, analysed, and classified Stakeholders, their interrelaions and their relations to the Intended Solution. Relations to represented Operational Performers shall also be shown. |
| SAF_O3_OPRO | Implementation of Operational Process Viewpoint Purpose: The Operational Process Viewpoint describes the Operational Processes related to a specific Operational Story, the sequence of execution, and their Operational Exchanges, including information, materials, natural resources, etc. The assignment of Operational Processes to Operational Performers is captured. Presentation: An activity diagram featuring the ordered execution of Operational Process Actions. Operational Processes may be linked in terms of control flow and/or data flow visualizing the Operational Exchanges needed. Note: Operational Process Actions are assigned to Operational Roles and therefore in a more general manner to Operational Performers. |
| SAF_O3_OSTA | Implementation of Operational State Viewpoint Purpose: The viewpoint defines modes of operation for the prosed system (such as normal, on-road, degraded, war-time, maintenance, training etc.) which apply not only to the SOI but also to involved personnel. An operational mode defines a potential life-cycle selection for the SOI which has a relevant impact for the SOI’s stakeholder/users w.r.t. to the operations. [tbd] Presentation: A block definition diagram (BDD) featuring states, and state transitions. Note: References to model elements that are dependent of states, or transitions shall be shown as callout, or compartment notation. |
| SAF_O4_OCXI | Implementation of Operational Context Interaction Viewpoint Purpose: The Operational Context Interaction Viewpoint describes single threads of interaction between Operational Performers in an Operational Context on an operational domain level. Note: The Operational Interaction Viewpoint may refine an Operational Story. Presentation: A sequence diagram featuring the flow of control between Operational Performers of an Operational Context to achieve one outcome of an Operational Story. Note: This diagram depicts the sending and receiving of messages between the interacting entities called lifelines where time is represented along the vertical axis. The lifelines representatives are part properties typed by Operational Performers. |
| SAF_O6_SKRD_Table | Implementation of Stakeholder Requirement Definition Viewpoint Purpose: The Stakeholder Requirement Definition Viewpoint specifies all capabilities, functions and properties, that the intended solution shall possess or expose from the perspective of the Stakeholders. The Stakeholder Requirement Definition Viewpoint also captures constraints for the system to be developed from stakeholders perspective. Presentation: A tabular format lisiting * unique requirement ID, text, and attributes, * traceability reference to justifying model artefacts, e.g. operational stories, operational capabilities, identified concerns of stakeholders, and compliance statements Note: Stakeholder Requirements are to be structured in a way that the Stakeholder behind the Requirement is identifiable. When appropriate, the relationships between identified Stakeholder Requirements are and the justifying model artefacts, Operational Story, Operational Capability, Operational Performer, Operational Process, and Operational Exchange are presented. * "One Requirement Package for each Stakeholder" is a best-practice modeling rule. A package contains the Requirements specific for one Stakeholder. * Even if different Stakeholders may have intersecting interests and / or concerns resulting in a similar set of Requirements, each Stakeholder shall have its own set managed in a dedicated Requirement Package. Requirements must not be shared due to their different life cycles. Resolving duplications and conflicts is subject of the requirement analysis resulting in an agreed and consolidated set of System Requirements. |
| SAF_O8_OCYM_Table | Implementation of Operational Capability Mapping Viewpoint Purpose: The Operational Capability Mapping Viewpoint describes the relationships of Operational Capabilities. The reasoning for Operational Capabilities as support for Operational Stories and the contribution of Operational Processes to Capabilities are described. Operational Capabilities encoded in Stakeholder Requirements are identified. Presentation: A tabular format listing the relationships of Operational Capabilities to Stakeholder Requirements, Operational Stories, and Operational Process Activities. |
| SAF_O8_OPRM_Table | Implementation of Operational Process Mapping Viewpoint Purpose: The Operational Process Mapping Viewpoint describes the relationships of Operational Processes. The reasoning for Operational Processes from Operational Stories and their contribution to Capabilities is described. The assignment of Operational Processes to Operational Performers is captured. Presentation: A tabular format listing the relationships of Operational Process Activities to Operational Capabilities, Operational Stories, and Operational Performers. |
| SAF_OperationalCapability | A Operational Capability is a high-level description or specification of an organizational unit's ability to execute a specified course of action, to implement a business process or to provide a service. Operational Capabilities typically require people, processes, infrastructure, technology and supporting systems to be implemented. A Operational Capability is an enduring element, its implementation may change over time. A necessary or desired change of a Operational Capability triggers the updated of involved systems or the integration new systems. Aliases: UAF::Capability NAF4::Capability Implementation of SAF Concept Operational Capability |
| SAF_OperationalCapabilityComposition | Specifies the fact that an Operational Capability consists of other Operational Capabilites. Implementation of SAF Concept Operational Capability composed of Operational Capability |
| SAF_OperationalCapabilityDependency | Specifies the fact that an Operational Capability depends on another Operational Capability. Aliases: UAF::CapabilityDependency Implementation of SAF Concept Operational Capability depending on Operational Capability |
| SAF_OperationalCapabilityGeneralization | Specifies the fact that an Operational Capability is specialized by other Operational Capability. Aliases: UAF::CapabilityGeneralization Implementation of SAF Concept Operational Capability specialized by Operational Capability |
| SAF_OperationalCapabilitySupport | Specifies the fact that an Operational Story is supported by Operational Capabilities. Implementation of SAF Concept Operational Story supporting Operational Capability |
| SAF_OperationalContext | An Operational Context is representing a separate Usage Scenario with a specific configuration of Operational Performers, these are interacting in the Scenario exhibiting a specific identified Operational Capability. One or more Operational Contexts meaningful for the Operational Domain are to be identified. Aliases: UAF::HighLevelOperationalConcept Implementation of SAF Concept Operational Context |
| SAF_OperationalContextRole | An Operational Context Role represents a participant in an Operational context. It is interacting with other roles of the given Operational Context. Specific characteristics and features or, in case of persons or organizational units, knowledge and skills are assigned to a role necessary for the execution of the performed Operational Processes. Implementation of SAF Concept Operational Context Operational Context Role Operational Performer |
| SAF_OperationalExchangeType | Specifies the type of Operational Item Exchange between Operational Context Roles or Operational Processes. Implementation of SAF Concept Operational Exchange Type |
| SAF_OperationalExchangeTypeComposition | Specifies the fact that an Operational Domain Kind may consists of zero or more Operational Domain Kinds. Implementation of SAF Concept Operational Exchange Type composed of Operational Exchange Type |
| SAF_OperationalPerformer | An Operational Performer is an element of the Operational Context that is capable to perform Operational Process Activities contributing to a specific identified Operational Capability. An Operational Performer may be any kind of organization, person, or even a system playing a role in one or more Operational Contexts. Aliases: UAF::OperationalPerformer Implementation of SAF Concept Operational Performer |
| SAF_OperationalPerformerActing | Specifies the fact that an Operational Performer acts in an Operational Story. Implementation of SAF Concept Operational Story acting in Operational Performer |
| SAF_OperationalPerformerComposition | Specifies the fact that an Operational Performer consists of one or more Operational Performers. Implementation of SAF Concept Operational Performer composed of Operational Performer |
| SAF_OperationalPerformerExhibit | Specifies the fact that an Operational Performer exhibits an Operational Capability under specific environmental conditions. Implementation of SAF Concept Operational Capability exhibiting Operational Performer |
| SAF_OperationalPerformerRole | Specifies the fact that an Operational Performer consists of one or more Operational Performers. Implementation of SAF Concept Operational Performer composed of Operational Performer |
| SAF_OperationalProcess | An Operational Process captures activity-based operational behavior including scenarios, activity actions, and operational exchange flows, e.g., including information, materials, natural resources, etc. Aliases: UAF::Operational Activity NAF::Logical Activity Implementation of SAF Concept Operational Process |
| SAF_OperationalProcessAction | Specifies the fact that an Operational Process is used in context of another Operational Process. Aliases: UAF::OperationalAction Implementation of SAF Concept Operational Process Operational Process Usage Operational Process |
| SAF_OperationalProcessEnabling | Specifies the fact that an Operational Process contributes to the provision of one or more Operational Capabilities in the field. Aliases: UAF::MapsToCapability Implementation of SAF Concept Operational Capability enabling Operational Process |
| SAF_OperationalProcessRefinement | Specifies the fact that an Operational Story is refined by one or more Operational Processes. Implementation of SAF Concept Operational Story refining Operational Process |
| SAF_OperationalSketch | Specifies a free form sketch depicting a concept. Implementation of SAF Concept Operational Sketch |
| SAF_OperationalState | Describes a state (or mode) of on operational level. Implementation of SAF Concept Operational State |
| SAF_OperationalStory | The Operational Story represents one or more Operational Use Cases in the Usage Scenario identified by the Operational Context. The Operational Story is described as narrative story-telling. Implementation of SAF Concept Operational Story |
| SAF_P1_PCXD | Implementation of Physical Context Definition Viewpoint Purpose: The Physical Context Definition Viewpoint identifies the various contexts the SOI is used in, along with the associated external entities sharing a physical interface with the system. For each context, the applicable environmental conditions shall be defined. The physical context helps identify the interface requirements needed to integrate a system into its environment in a given context. Presentation: A block definition diagram (BDD) depicting the elements available in a specific context. At least one BDD is used per identified context featuring * one block representing the Physical System, i.e., the system of interest * one block representing the specific Physical System Context * several blocks representing Physical Context Elements such as Physical User, Physical External System, and Physical Environment that are present in the Physical System Context * composition relationships attaching the Physical Context Elements and the Physical System to the Physical System Context block |
| SAF_P1_PCXE | Implementation of Physical Context Exchange Viewpoint Purpose: The Physical Context Exchange Viewpoint focuses on the identification of the physical interfaces with external entities and relevant documentation. It is used to capture interface design requirements, applicable standards, protocols and format specifications, that are agreed upon the interfaces. Presentations:
|
| SAF_P1_PCXE_Table | Implementation of Physical Context Exchange Viewpoint Purpose: The Physical Context Exchange Viewpoint focuses on the identification of the physical interfaces with external entities and relevant documentation. It is used to capture interface design requirements, applicable standards, protocols and format specifications, that are agreed upon the interfaces. Presentations:
|
| SAF_P2_PETD | Implementation of Physical Exchange Type Definition Viewpoint Purpose: The Physical Exchange Type Definition Viewpoint captures type definitions on design level for any exchanged or stored items, e.g., information, material, or energy, of the Physical Domain. Its purpose is to define these item types, their properties and their relationships. It also shows the traceability of these items to the conceptual layer (Functional and Logical Domain) Presentations:
|
| SAF_P2_PETD_Table | Implementation of Physical Exchange Type Definition Viewpoint Purpose: The Physical Exchange Type Definition Viewpoint captures type definitions on design level for any exchanged or stored items, e.g., information, material, or energy, of the Physical Domain. Its purpose is to define these item types, their properties and their relationships. It also shows the traceability of these items to the conceptual layer (Functional and Logical Domain) Presentations:
|
| SAF_P2_PSTD | Implementation of Physical Structure Definition Viewpoint Purpose: The Physical Structure Viewpoint is used to model the internal structure of the SOI and to identify the internal system elements making up the SOI. The SOI breakdown structure identifies system elements and finally at the implementation level hardware, software, and mechanics. The SOI breakdown structure determines items that are reused and make-or-buy (COTS) items. The Physical Structure Viewpoint is elaborated for each candidate physical SOI architecture. It provides the basis for further assessment of the architecture candidates by identifying the system elements in each candidate solution. Presentation: A block definition diagram (BDD) featuring the physical system block and physical blocks for any kind of physical element, HW or SW elements, the system is composed of. These elements are connected to the system block by means of aggregation relationships. Note: Multiple relationships to a kind of element are allowed meaning, that this kind of element is used in several roles. |
| SAF_P4_PCXI | Implementation of Physical Context Interaction Viewpoint Purpose: The Physical Context Interaction Viewpoint describes the System external behavior based on the exchange between Physical SOI and Physical Context Elements Usage in a given Physical System Context. It depicts the sequence of interactions between the Physical SOI, the Context Elements and the exchanged Physical Items needed to the conceptual functions and exchanges. Presentation: A sequence diagram featuring the flow of control between SOI and Context Elements Roles of a Physical Context. Note: This diagram depicts the sending and receiving of messages between the interacting entities called lifelines, where time is represented along the vertical axis. The lifelines representatives are part properties typed by a Physical Context Elements. |
| SAF_P4_PIEX | Implementation of Physical Internal Exchange Viewpoint Purpose: The Physical Internal Exchange Viewpoint serves for the identification and definition of interfaces of elements of the physical system. also, the delegation of system element interfaces to the physical system boundary interfaces is covered. The Physical Internal Exchange Viewpoint * identifies system element interfaces on a physical level * states to which other physical elements the interfaces are connected to * assigns physical interface definitions to interfaces * defines the usage of interfaces, e.g., if only a subset of the interfaces is used * defines the delegation of physical system element interfaces to physical system boundary interfaces Presentations:
|
| SAF_P4_PIEX_Table | Implementation of Physical Internal Exchange Viewpoint Purpose: The Physical Internal Exchange Viewpoint serves for the identification and definition of interfaces of elements of the physical system. also, the delegation of system element interfaces to the physical system boundary interfaces is covered. The Physical Internal Exchange Viewpoint * identifies system element interfaces on a physical level * states to which other physical elements the interfaces are connected to * assigns physical interface definitions to interfaces * defines the usage of interfaces, e.g., if only a subset of the interfaces is used * defines the delegation of physical system element interfaces to physical system boundary interfaces Presentations:
|
| SAF_P4_PITI | Not implementing a concept |
| SAF_P5_PIFD | Implementation of Physical Interface Definition Viewpoint Purpose: The Physical Interface Definition Viewpoint captures definitions for physical interfaces. It allows to adopt long-lived standards and to harmonize physical interface definitions to improve interchangeability, interoperability, and portability. Presentations:
|
| SAF_P8_PFUM_Matrix | Implementation of Physical Functional Mapping Viewpoint Purpose: The Physical Functional Mapping Viewpoint supports the analysis of the assigment of system functions and system partial functions to physical system elements. The result shall be computed from the assigment of functions to logial system elements and the assignment of logical system elements to physical system elements Presentation: A FBS_to_PBS mapping matrix featuring * Functional Breakdown Structure (FBS) * Physical Breakdown Structure (PBS) * mapping (it is a derived relationship) from system functions and system partial functions to physical SOI elements |
| SAF_P8_PLOM_Matrix | Implementation of Physical Logical Mapping Viewpoint Purpose: The Physical Logical Mapping Viewpoint supports the definition of the mapping of conceptual system elements to physical system elements and conceptual exchange types to physical exchange types. This allows to trace how concepts are physically implemented and provides feedback to the System Architecture Definition process to consolidate or confirm the alignment physical implementations with their specifying concepts. Presentation: A assignment matrix featuring *Conceptual elements * Physical Elements * Realization relationship from physical elements element roles to conceptual elements |
| SAF_PhysicalContext | Specifies the fact that a context for a System of Interest is defined on Physical Level. Implementation of SAF Concept Physical System Context |
| SAF_PhysicalContextRole | Specifies the fact that a Physical Context Element exists in a given Physical System Context. Implementation of SAF Concept Physical System Context Physical Context Element Role Physical Context Element |
| SAF_PhysicalContextRole_SoI | Specifies the fact that a Physical SOI exists in a given Physical System Context. Implementation of SAF Concept Physical System Context Physical SOI Role Physical System |
| SAF_PhysicalEnvironment | The Physical Environment in the Physical Domain, outside the SOI scope, interacting with the SOI. E.g. air, dirt, sun, road. Implementation of SAF Concept Physical Environment |
| SAF_PhysicalExchangeType | Specification for any kind of physical item (energy, material, information, etc.) to be exchanged on Physical Level. This is the realization of the specification made by System Domain Kinds. Implementation of SAF Concept Physical Exchange Type |
| SAF_PhysicalExternalSystem_deprecated | Not implementing a concept |
| SAF_PhysicalHardware | Pure Hardware Elements. Similarity with the V-Model "hardware unit". Implementation of SAF Concept Hardware Element |
| SAF_PhysicalInterfaceDefinition | Specifies the exchange capabilities of an interaction point on Physical Level. Implementation of SAF Concept Physical Interaction Point Definition |
| SAF_PhysicalInternalRole | Implementation of SAF Concepts |
| SAF_PhysicalItem | Not implementing a concept |
| SAF_PhysicalRealization | Implementation of SAF Concepts |
| SAF_PhysicalResource | tangible & intangible resources are types of Assets. The NIST SP 800-160v1r1 - Engineering Trustworthy Secure Systems describes them following: „There are many different types of assets. Assets are broadly categorized as either tangible or intangible. Tangible assets include physical items, such as hardware, computing platforms, other technology components, and humans. Intangible assets include humans, firmware, software, capabilities, functions, services, trademarks, intellectual property, data, copyrights, patents, image, or reputation.“ Implementation of SAF Concept Tangible Resource |
| SAF_PhysicalSoftware | Pure Software Elements. Similarity with the V-Model "software unit". Implementation of SAF Concept Software Element |
| SAF_PhysicalSystem | Implementation of SAF Concepts |
| SAF_PhysicalSystem_deprecated | Not implementing a concept |
| SAF_PhysicalUser | The Physical User is the representation for a human in the physical domain, outside the SOI scope, interacting with the SOI. Implementation of SAF Concept Physical User |
| SAF_Process | Unit of Work in Systems Engineering. Implementation of SAF Concept Process |
| SAF_ProtectionNeed | Not implementing a concept |
| SAF_Refuter | A party asserting counter-claims. Implementation of SAF Concept Refuter |
| SAF_RefuterCounterClaimMaking | Specifies the fact that a counter-claim is made by a defined refuter. Implementation of SAF Concept CounterClaim making Refuter |
| SAF_RepresentsEA | Specifies that a SAF Element represents an EA Element. Implementation of SAF Concept Any EA Element represents Any SAF Element |
| SAF_Risk | Implementation of SAF Concept Risk |
| SAF_SecurityAssuranceLevel | NIST SP 800-89: "The level of assurance (e.g., HIGH, MEDIUM, or LOW) that a claimed signatory possesses the private signature key." Implementation of SAF Concept Security Assurance Level |
| SAF_SecurityContext | The Security Context describes all internal and external elements, boundaries, interconnections and assumptions that referes to the security of a system or an asset. DIN ISO 31000:2018-10 defines: "The context of the risk management process should be derived from an understanding of the external and internal environment in which the organisation operates and should reflect the specific environment of the activity to which the risk management process is applied." Implementation of SAF Concept Security Context |
| SAF_SecurityEnviromentalElement | An abstract element representing a Security Context Element occurring in the environment of an asset. Implementation of SAF Concept Security Enviromental Element |
| SAF_SecurityMeasures | Implementation of SAF Concept Security Measures |
| SAF_SecurityObjective | The Security Objectives are defined as the CIA-Triad (Confidentiality, Integrity, Availability) (Synonym: Security Attribute, Security Propaty) FIPS PUB 199 - Standards for Security Categorization of Federal Information and Information Systems: "The FISMA defines three security objectives for information and information systems: CONFIDENTIALITY “Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information…” [44 U.S.C., Sec. 3542 ] A loss of confidentiality is the unauthorized disclosure of information. INTEGRITY “Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity…” [ 44 U.S.C., Sec. 3542] A loss of integrity is the unauthorized modification or destruction of information. AVAILABILITY “Ensuring timely and reliable access to and use of information…” [44 U.S.C., S EC. 3542 ] A loss of availability is the disruption of access to or use of information or an information system." Implementation of SAF Concept Security Objective |
| SAF_SecurityRecuirements | Implementation of SAF Concept Security Requirements |
| SAF_SeverityLevel | Implementation of SAF Concept Severity Level |
| SAF_Stakeholder | An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. It may be involved in any life cycle phase of the System. The Stakeholder represents a class or kind of Stakeholders. Stakeholders have a certain involvement: Stakeholder Involvement captures the influence of a project specific Stakeholder on the System. Stakeholder Involvement is characterized by * Contact Person * Kind of involvement * Life Cycle Phases involved * Relevance decision if and up to which degree Stakeholder is considered * Rationale for decision when Stakeholder is not considered Implementation of SAF Concept System of Interest Stakeholder |
| SAF_StakeholderRelation | Explains relations between the Stakeholders of the System and other relevant System parties. It helps to understand the Stakeholder community and to approach the right point of contact for clarification of project relevant issues. Implementation of SAF Concept to related to from |
| SAF_StakeholderRepresenting | Specifies the fact that a SOI Stakeholder is representing an Operational Performer. Implementation of SAF Concept Operational Performer representing System of Interest Stakeholder |
| SAF_StakeholderRequirement | A Stakeholder Requirement is a Requirement imposed by a Stakeholder. Stakeholder Concerns are refined by Stakeholder Requirements applicable for the SOI. The Stakeholder Requirements are a result of discussions and agreements of how the SOI addresses the Concerns of the respective Stakeholder. Implementation of SAF Concept Stakeholder Requirement |
| SAF_StakeholderRequirementImposition | Specifies the fact that a Stakeholder Requirement is provided by Stakeholders. Implementation of SAF Concept System of Interest Stakeholder imposed Stakeholder Requirement |
| SAF_StakeholderRequirementRefinement | Implementation of SAF Concepts |
| SAF_Standard | Specifies a standard which shall potentially be complied by the system or a part of the system. Implementation of SAF Concept Standard |
| SAF_StandardCategory | Specifies categories in which the standard could be categorized , e.g., a data exchange format or a protocol standard, or categories as national, company or international standard. Implementation of SAF Concept Category Of Standard |
| SAF_StandardCategoryAssignment | Specifies the fact that a standard is categorized by one or more categories. Implementation of SAF Concept Category Of Standard categorized as Standard |
| SAF_StandardChapter | Not implementing a concept |
| SAF_StandardDependingOn | specifies that a standard depends on an other. Implementation of SAF Concept Standard depends on Standard |
| SAF_StandardSuperseding | Specifies the fact that a standard supersedes one or more other standards. Implementation of SAF Concept Standard superseding Standard |
| SAF_StandardizationOrganization | An organization of standardization, e.g., International Organization for Standardization (ISO), Object Management Group (OMG), etc. Implementation of SAF Concept Standardization Organization |
| SAF_SystemCapability | 1) A System Capability is an operation or task that performs an action to produce a specific performance-based outcome. NOTE that a system capability represents the potential to perform an action. In contrast, an operational capability may integrate several physical system capabilities to produce a specific outcome to achieve a mission objective. [Wasson2006, SystemAnalysis+Design+Development] 2) System Capabilities, as system assets, characterize the mechanical, electrical, optical, or processing features that enable a system to function, process mission resources, make decisions, and achieve a required level of success based on performance. A system capability is broader in scope than simply a functional element (and performance bounding elements), especially in large, complex ecosystems. It represents a physical potential - strength, ability, endurance - to perform an outcome-based action for a given duration under a specified set of operating environment conditions. [Wasson2006, SystemAnalysis+Design+Development] Aliases: UAF::Capability NAF4::Capability Implementation of SAF Concept System Capability |
| SAF_SystemCapabilityComposition | Specifies the fact that a System Capability consists of other System Capabilities. Implementation of SAF Concept System Capability composed of System Capability |
| SAF_SystemCapabilityDependency | Specifies the fact that a System Capability requires another System Capability. Aliases: UAF::CapabilityDependency Implementation of SAF Concept System Capability depending of System Capability |
| SAF_SystemCapabilityEnabling | Specifies the fact that an Operational Capability integrates System Capabilities to produce a specific outcome to achieve a mission objective. Implementation of SAF Concept Operational Capability enabling System Capability |
| SAF_SystemCapabilityGeneralization | Specifies the fact that a System Capability is specialized by another System Capability. A CapabilityGeneralization is a taxonomic relationship between a more general Capability and a more specific Capability. Aliases: UAF::CapabilityGeneralization Implementation of SAF Concept System Capability specialized by System Capability |
| SAF_SystemCapabilitySatisfaction | Specifies the fact that a System Capability satisfies one or more Stakeholder Requirements. Implementation of SAF Concept Stakeholder Requirement satisfying System Capability |
| SAF_SystemCapabilitySupport | Specifies the fact that a System UseCase is supported by System Capabilities. Implementation of SAF Concept System Use Case supporting System Capability |
| SAF_SystemDomainKindAsset | Implementation of SAF Concept Security Context SDK is Asset in Security Context Conceptual Exchange Type |
| SAF_SystemFunctionalRequirement | Functional Requirements specify System Functions of the System. Implementation of SAF Concept Functional Requirement |
| SAF_SystemFunctionalRequirementConstraint | Specifies the fact that a Non-Functional Requirement constrains Functional Requirements. Implementation of SAF Concept Non-functional Requirement bounded by Functional Requirement |
| SAF_SystemFunctionalRequirementRefinement | Specifies the fact that a System Function is refined by Functional Requirements. Implementation of SAF Concept System Function refining Functional Requirement |
| SAF_SystemNonFunctionalRequirement | Non-Functional Requirements specify the quality of System Functions, or non-functional requests like legal conformance. Implementation of SAF Concept Non-functional Requirement |
| SAF_SystemOfInterestConcern | Any kind of interest a Stakeholder has. Note: Redundant with the meaning of "Need"? Implementation of SAF Concept System of Interest Concern |
| SAF_SystemPartialFunction_deprecated | Specifies the fact that a System Partial Function is a decomposed part of a System Function and defines details of the System Function it belongs to. Implementation of SAF Concept System Partial Function |
| SAF_SystemProcess | Specifies the fact that a System Process captures system behavior as a specific sequence of actions or tasks, and system exchanges including information, materials, energy, etc. Implementation of SAF Concept System Process |
| SAF_SystemProcessEnabling | Specifies the fact that a System Process contributes to the provision of one or more System Capabilities in the field. Implementation of SAF Concept System Capability enabling System Process |
| SAF_SystemProcessRefinement | Specifies the fact that a System Use Case is refined by one System Process. Implementation of SAF Concept System Use Case refining System Process |
| SAF_SystemRequirement | System Requirements specify System Functions, non-functional properties, or constraints of the System. Implementation of SAF Concept System Requirement |
| SAF_SystemRequirementDerivation | Implementation of SAF Concepts |
| SAF_SystemRequirementRefinement | Implementation of SAF Concepts |
| SAF_SystemState | Describes a state (or mode) of something on system level that can have distinct states. Implementation of SAF Concept System State |
| SAF_SystemUseCase | The System Use Cases are a table of content of the services provided by the System of Interest to its System Actors. A System Use Case is only the abstract of the depicted System behavior and represents the purpose. While the main System of Interest interaction actors participating in this Use Case are identified, the behavior itself is specified by a Use Case Activity, Note: The intended use (and also misuse in so called "black use cases") of the System of Interest is captured in free text; story telling at a coarse level of detail which is understandable to Customers (non engineering stakeholders in general). Implementation of SAF Concept System Use Case |
| SAF_SystemUseCaseEnabling | Specifies the fact that a System Use Case enables the realization of an Operational Story. Implementation of SAF Concept Operational Story enabling System Use Case |
| SAF_TargetMisuseCase | Implementation of SAF Concept Target Misuse Case |
| SAF_Term | Specifies the fact that a term is usually defined by a standard, but can also be defined as part of system development work. Implementation of SAF Concept Term |
| SAF_ThreatScenario | Implementation of SAF Concept Threat Scenario |
| SAF_Viewpoint | Implementation of SAF Concepts |
| SAF_Vulnerability | Implementation of SAF Concept Vulnerability |
| SysML ActivityDiagram | Not implementing a concept |
| SysML BlockDiagram | Not implementing a concept |
| SysML InternalBlockDiagram | Not implementing a concept |
| SysML RequirementDiagram | Not implementing a concept |
| SysML SequenceDiagram | Not implementing a concept |
| SysML StateMaschineDiagram | Not implementing a concept |
| SysML UseCaseDiagram | Not implementing a concept |
| FlowProperty typed by SAF_ConceptualExchangeType | Realized Concepts: Conceptual Exchange Type typing Conceptual Interaction Point Property |
| FlowProperty contained in SAF_ConceptualInterfaceDefinition | Realized Concepts: Conceptual Interaction Point Property specifying detail of Conceptual Interaction Point Definition |
| ProxyPort typed by SAF_ConceptualInterfaceDefinition | Realized Concepts: Conceptual Interaction Point Definition defining Conceptual Interaction Point |
| attribute realizingConnector of type Connector at InformationFlow | Realized Concepts: Operational Connection allowing Operational Item Exchange, Conceptual Connection allowing Conceptual Item Exchange, Physical Connection allowing Physical Item Exchange |
| ItemFlow typed by SAF_ConceptualExchangeType | Realized Concepts: Conceptual Exchange Type typing Conceptual Item Exchange |
| ItemFlow typed by SAF_PhysicalExchangeType | Realized Concepts: Physical Exchange Type typing Physical Item Exchange |
| FlowProperty typed by SAF_PhysicalExchangeType | Realized Concepts: Physical Exchange Type typing Physical Interaction Point Property |
| ProxyPort typed by SAF_PhysicalInterfaceDefinition | Realized Concepts: Physical Interaction Point Definition defining detail of Physical Interaction Point |
| FlowProperty contained in SAF_PhysicalInterfaceDefinition | Realized Concepts: Physical Interaction Point Property specifying detail of Physical Interaction Point Definition |
| SAF_PhysicalInterfaceDefinition contained in ProxyPort | Realized Concepts: Physical Interaction Point is part of Physical Interaction Point Definition |
| attribute concern of type SAF_SystemOfInterestConcern at Stakeholder | Realized Concepts: System of Interest Stakeholder having System of Interest Concern |
| attribute subject of type SAF_OperationalContext at UseCase | Realized Concepts: Operational Story taking place in Operational Context |
| attribute subject of type SAF_ConceptualContext at UseCase | Realized Concepts: System Use Case taking place in Conceptual System Context |
| attribute PreConditionStates of type State at SAF_SystemUseCase | Realized Concepts: System Use Case has pre condition System State |
| attribute PostConditionStates of type State at SAF_SystemUseCase | Realized Concepts: System Use Case has post condition System State |
| attribute saf_aspect of type SCM_AspectColumn at SCM_Viewpoint | Realized Concepts: Viewpoint belonging to Aspect |
| attribute saf_domain of type SCM_DomainLayer at SCM_Viewpoint | Realized Concepts: Viewpoint belonging to Domain |
| attribute logical_element of type SAF_ConceptualSystem at SAF_PhysicalItem | Realized Concepts: Conceptual System specifying Physical System |
| ProxyPort contained in SAF_PhysicalItem | Realized Concepts: Physical Interaction Point applying to Physical System |
| SAF_ConceptualInternalRole contained in SAF_ConceptualSystem | Realized Concepts: Conceptual System Conceptual Internal Role Conceptual System |
| attribute function of type SAF_Function at SAF_PhysicalItem | Realized Concepts: System Partial Function allocated to Physical System, System Function allocated to Physical System |
| Parameter typed by SAF_ConceptualExchangeType | Realized Concepts: Conceptual Exchange Type typing General Function Usage Exchange Point |
| SAF_Term contained in SAF_Standard | Realized Concepts: Term defined by Standard |
| SAF_Standard contained in SAF_Standard | Realized Concepts: Standard including Standard |
| SAF_Term contained in SAF_Glossary | Realized Concepts: Glossary contains Term |
| SAF_Glossary contained in SAF_Standard | Realized Concepts: Standard contains Glossary |
| ObjectFlow typed by SAF_OperationalExchangeType | Realized Concepts: Operational Exchange Type characterising Operational Process Usage Exchange |
| attribute diagrams of type SAF_Diagram at SAF_Viewpoint | Realized Concepts: View conforming to Viewpoint |
| SAF_OperationalState contained in StateMachine | The State is not directly contained in the performer, but with a state machin in between. Realized Concepts: Operational Performer beeing in Operational State |
| StateMachine contained in SAF_OperationalPerformer | The State is not directly contained in the performer, but with a state machin in between. Realized Concepts: Operational Performer beeing in Operational State |
| SAF_SystemState contained in StateMachine | Realized Concepts: Conceptual Exchange Type beeing in System State, Conceptual System beeing in System State |
| StateMachine contained in SAF_ConceptualExchangeType | Realized Concepts: Conceptual Exchange Type beeing in System State |
| StateMachine contained in SAF_ConceptualSystem | Realized Concepts: Conceptual System beeing in System State |
| attribute PreConditionStates of type SAF_OperationalState at SAF_OperationalProcess | Realized Concepts: Operational Process has precondition Operational State |
| attribute PostConditionStates of type SAF_OperationalState at SAF_OperationalProcess | Realized Concepts: Operational Process has postcondition Operational State |
| attribute PostConditionStates of type SAF_SystemState at SAF_Function | Realized Concepts: System Function has postcondition System State |
| attribute PreConditionStates of type SAF_SystemState at SAF_Function | Realized Concepts: System State has precondition System Function |
| attribute PostConditionStates of type SAF_SystemState at SAF_SystemProcess | Realized Concepts: System Process has postcondition System State |
| attribute PreConditionStates of type SAF_SystemState at SAF_SystemProcess | Realized Concepts: System Process has precondition System State |
| ItemFlow typed by SAF_OperationalExchangeType | Realized Concepts: Operational Exchange Type characterising Operational Item Exchange |
| EnumerationLiteral contained in SAF_ProtectionNeed | |
| SAF_FunctionAction contained in SAF_SystemProcess | Realized Concepts: System Function System Function in System Process System Process |
| SAF_FunctionAction contained in SAF_Function | Realized Concepts: System Function System Partial Function in System Function System Partial Function |
| SAF_ContextAction contained in SAF_SystemProcess | Realized Concepts: Context Function Context Function in System Process System Process |
| Message contained in Interaction | Realized Concepts: System Context Interaction Scenario containing System Context Chronological Message, Physical Context Interaction Scenario containing Physical Context Chronological Message |
| SCM_AspectColumn | Columns (aspects) of the SAF viewpoint matrix Used for specifying SAF. |
| SCM_Attribute | Defines a relationship between attribute type and attribute owner, implementing a SAF concept. The name of the relation specifies the name of the attribute Used for specifying SAF. |
| SCM_ChangeRecord | used to track changes in the SAF specification |
| SCM_Concept | A concept used in MBSE. May be a class, an association or an association class Used for specifying SAF. |
| SCM_ConcernRationale | The rationale explaining why a SAF_VPStakeholder has a specific concern (which should be addressed by one or more SAF Viewpoints. Used for specifying SAF. |
| SCM_ContainedIn | Defines a relation where the instances of the client(sterotype or metaclass) is contained in instances of the the supplier (stereotype or metaclass). This is used to specify an inplementation of a SAF concept Used for specifying SAF. |
| SCM_DerivedRelationship | a derived relationship among SAF_Concepts which is important for views and stakeholders, but not a primary information The rule of derivation must be specified and is used if the relationship is exposed in a view. This shall be always used together with SAF_Concept on relationships. Used for specifying SAF. |
| SCM_DocTarget | defines a path for doc generation. Experimental. |
| SCM_DomainLayer | Domains(rows) of the saf matrix Used for specifying SAF. |
| SCM_FramesConcern | The relationship between a SAF Viewpoint to a concern defining that the Viewpoint frames (adresses) this concern. Used for specifying SAF. |
| SCM_InformationItem | An information item required by a standard, e.g. ISO 29148 |
| SCM_Maturity | Specifies the maturity of SCM Elements i.e. Viewpoints Used for specifying SAF. |
| SCM_ProcessRequirement | Requirement to specify content for an information Item. |
| SCM_RealizationKind | defines the kind of realization if it is not able to derive from a stereotype or metaclass |
| SCM_RealizeConcept | Specifies the fact that a stereotype or an UML Metaclass is used to realize a SAF concept. |
| SCM_TypedBy | Defines a realization where the instances of the client(sterotype or metaclass) is typed by instances of the the supplier (stereotype or metaclass). Used for specifying realizations of SAF Concepts in the SAF Specification. |
| SCM_VPConcern | Concern of an engineering Stakeholder, to describe their concerns adressed by SAF viewpoints. Used for specifying SAF. |
| SCM_VPStakeholder | A stakeholder having concerns framed by viewpoints. These stakeholders are only used in the SAF specification model to capture concerns of viewpoints. They may not be used in a system model. Used for specifying SAF. |
| SCM_VP_Package | Used for the root package of a viewpoint spec. Document generation and validations rely on this. |
| SCM_View | Used to mediate between SCM_Concepts and SCM_Viewpoints. Concepts are exposed by the SCM_View, specifying the conceptual content of the Viewpoint. Used for specifying SAF. |
| SCM_Viewpoint | Extends SysML Viewpoint by attributes needed by SAF Documentation. Used for specifying SAF. |
Used SysML Stereotypes
report used SysML and UML objects