SAF Ontology Elements
The Elements of the SAF Ontology are listed in the following Table. The Table contains two kinds of Elements:
- Relations between Elements that are subject or objects. These are documented in a "triple Form", e.g. Function - Has- Parameter.
- Elements used as subject or objects
| Concept | Documentation | Base Concept | Specific Concept | Viewpoint |
|---|---|---|---|---|
| 1..* Security Context 1 System Of Interest | specifies the fact, that a system of interest exists in a security context. | |||
| 1..* Security Context 1..* Security Context Element | ||||
| 0..* Operational Performer capable performing 0..* Operational Process | Specifies the fact that an Operational Performer performs an Operational Activity. Traceability from Operational Activities to Operational Performers is derived via assignment of Operational Action to Operational Roles. Aliases: UAF::IsCapableToPerform | Operational Process Mapping Viewpoint | ||
| 1 Adversary ADV use Attack Path to attack SO 1 Security Objective | The Aversary uses an Attack Vector to attack a Security Objective of an Asset. | Security Context Viewpoint | ||
| 0..* Adversary ADVusesAV 1..* Attack Vector (old) | ||||
| 1 Argument AGTsupportingCLM 1..* Claim | Specifies the fact that a claim is supported by one or more arguments via a claim-argument relation. | Argumentation Assurance Viewpoint | ||
| 0..* Abstract Physical Element APEbeeingInSSE 0..* System State | Specifies the fact that a Physical System Element can be in distinct states. | |||
| 1 Abstract Physical Element APEimplementingGFN 1..* General Function | ||||
| 1 Target Misuse Case AVoccuresInMUS 1 Attack Vector (old) | ||||
| Abstract Physical Element | Abstract element representing physical structure items keeping properties and relations applicable to all physical items. | Physical SOI , Software Element , Physical Element , Hardware Element | ||
| 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.” | Security Enviromental Element | Security Context Viewpoint | |
| Affected Acteurs | ||||
| Any EA Element | Represents any conceptual entity of an Enterprise Architecture model. | EA Traceability Viewpoint | ||
| Any SAF Element | A concept used only together with relational concepts to specify that the relation goes to any other SAF Concept. | EA Traceability Viewpoint | ||
| 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. | Claimable Item | Argument Decomposition , Argument Substitution , Argument Concretion | Argumentation Assurance Viewpoint |
| Argument Concretion | This argument concept is used when a claim needs to be given a more precise definition or interpretation. | Argument | ||
| Argument Decomposition | This argument concept is used to claim that a conclusion about the whole object or property can be deduced from the claims or facts about constituent parts. Decomposition argument blocks can also be used to incorporate defeaters into the case. | Argument | ||
| Argument Substitution | This argument concept is used to claim that if a property holds for one object, then it holds for an equivalent object. Similarly, if a property holds for some object, then an equivalent property will also hold for the same object. The nature of the equivalence will vary with the object and property and will need to be defined. | Argument | ||
| Aspect | Aspects capture a set of characteristics or features of the Entity of Interest in its Environment to address Concerns within an Architecture Description. | Framework Viewpoint Overview Viewpoint | ||
| 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.“ | Intangible Resource , Tangible Resource , Security Context Element | SF is Asset in Security Context , SDK is Asset in Security Context | Asset Identification Viewpoint |
| Assumption | Security Context Element | Security Context Viewpoint | ||
| 1 Target Misuse Case Attack Action 1 Adversary | Threat Szenario Viewpoint | |||
| Attack Vector (old) | Security Context Element | Security Context Viewpoint | ||
| Availability | Availability is a Security Objective. Availability: Ensuring timely and reliable access to and use of information. [44 U.S.C., Sec. 3542] | Security Objective | Impact Analysis Viewpoint | |
| 0..* CounterClaim CCMcounteringCIM 0..* Claimable Item | Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is countered by one or more claims. | Argumentation Assurance Viewpoint | ||
| 1..* Context Function CFNallocatedToLCE 1 Conceptual Context Element | Specifies the fact that a Context Function is assigned to a Logical Context Element. Note: This fact may be derived from the Usage of Function of a Context Function allocated to a Logical Context Element. | |||
| 1 Claim CLMbeingMadeAboutSBC 0..1 Subject of Claim | Specifies the fact that a claim is made about an identified subject matter. | Argumentation Assurance Viewpoint | ||
| 0..* Claim CLMsupportingCIM 0..* Claimable Item | Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is supported by one or more claims. | Argumentation Assurance Viewpoint | ||
| 1 Claimant CLTmakingCLM 1..* Claim | Specifies the fact that a claim is made by a defined claimant. | Argumentation Assurance Viewpoint | ||
| 1 Consequence CON has Effect On AA 1 Affected Acteurs | ||||
| 1 Compliance Statement CSTconfirmingSHR 1 Stakeholder Requirement | Specifies the fact that a Stakeholder Requirement has certain States of Compliance. | Stakeholder Requirement Definition Viewpoint | ||
| Category Of Standard | 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. | Common Standards Definition Viewpoint | ||
| 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. | Claimable Item | Argumentation Assurance Viewpoint | |
| Claimable Item | 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. | Claim , Argument | ||
| Claimant | A party asserting claims. | Argumentation Assurance Viewpoint | ||
| Compliance Statement | Used in the communication between Stakeholder (Customer) and Contractor. Compliance Statements are the first answer to the Stakeholder Requirements and are usually together with the Stakeholder Requirements part of the contract. They are valuable input for the System development and System Requirement elicitation. Information status: * not compliant (with explanation / rationale) * partially compliant (with explanation / rationale) * fully compliant | Stakeholder Requirement Definition Viewpoint | ||
| 1 Conceptual Scenario Participation Conceptual Chronological Message 1 Conceptual Scenario Participation | Ordered sequential occurrence of exchanges between Conceptual Interaction Scenario Participants. | System Internal Interaction Viewpoint | ||
| 1 Conceptual Interaction Point Conceptual Connection 1 Conceptual Interaction Point | Specifies the connection of two interaction points on Logical Level. Note: Connections between logical components indicate that item flows are passed from one output of a source component to one or more inputs of target components. | System Context Exchange Viewpoint , System Internal Exchange Viewpoint | ||
| Conceptual Context Element | Represents an abstract element in the given System Context on Conceptual Level, outside the SOI scope, interacting with the SOI. | Conceptual External System , Conceptual Environment , Conceptual User | ||
| 1..* Conceptual Context Element Conceptual Context Element Role 1..* Conceptual System Context | Specifies the fact that a Conceptual Context Element acts in a given Conceptual System Context. | System Context Role | System Process Viewpoint , System Context Exchange Viewpoint , System Context Definition Viewpoint , System Context Interaction Viewpoint | |
| Conceptual Environment | A Conceptual Environment in the Conceptual Domain, outside the SOI scope, interacting with the SOI. E.g., air, dirt, sun, road. | Conceptual Context Element | System Use Case Viewpoint , System Context Definition Viewpoint | |
| Conceptual Exchange Type | 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. | System Exchange Type Definition Viewpoint , System Interface Definition Viewpoint , System Internal Exchange Viewpoint , Physical Logical Item Mapping Viewpoint | ||
| Conceptual External System | A Conceptual External System in the Conceptual Domain, outside the SOI scope, interacting with the SOI. E.g., power grid, mobile network, fresh water system (in a house). | Conceptual Context Element | System Use Case Viewpoint , System Context Definition Viewpoint | |
| Conceptual Interaction Point | Specifies the existence of an interaction point on Conceptual Level. | System Requirement Traceability Viewpoint , System Context Exchange Viewpoint , System Interface Definition Viewpoint , System Internal Exchange Viewpoint | ||
| Conceptual Interaction Point Definition | Specifies the exchange capabilities of an interaction point on Conceptual Level. | System Context Exchange Viewpoint , System Interface Definition Viewpoint , System Internal Exchange Viewpoint | ||
| Conceptual Interaction Point Property | Specifies a detail of an interaction point on Logical Level. | System Interface Definition Viewpoint , System Internal Exchange Viewpoint | ||
| Conceptual Interaction Scenario | Ordered sequence of exchanges of information, energy, or material between Conceptual Interaction Scenario Participants. | System Internal Interaction Viewpoint | ||
| 1 Conceptual System Conceptual Internal Role 0..* Conceptual System | Specifies the fact that a Conceptual System may consist of Conceptual Systems (a white box perspective on a conceptual system). | System Structure Definition Viewpoint , System Internal Interaction Viewpoint , System Function Mapping Viewpoint , Physical Logical Mapping Viewpoint | ||
| Conceptual Item Exchange | Specifies the exchange that is to take place on a connection of two interaction points on Conceptual Level. | System Context Exchange Viewpoint , System Internal Exchange Viewpoint | ||
| 1 Conceptual System Conceptual SOI Role 1..* Conceptual System Context | Specifies the fact that a Conceptual System acts as SOI exists in a given Conceptual System Context. | System Context Role | System Process Viewpoint , System Context Exchange Viewpoint , System Context Definition Viewpoint , System Context Interaction Viewpoint | |
| 0..* Conceptual Internal Role Conceptual Scenario Participation 0..* Conceptual Interaction Scenario | Specifies the fact that a Conceptual Internal Role participates in a Conceptual Interaction Scenario. | System Internal Interaction Viewpoint | ||
| Conceptual System | Describes a conceptual system as specification for an implementation of a system. It is used in both functional and logical architectures on any hierarchy level. | Logical Context SOI_ Deprecated | System Structure Definition Viewpoint , System Internal Exchange Viewpoint , System Function Mapping Viewpoint , Physical Logical Mapping Viewpoint , System Context Definition Viewpoint | |
| Conceptual System Context | Specifies the fact that a System Context for a System of Interest is defined on Conceptual Level. | System Use Case Viewpoint , System Context Exchange Viewpoint , System Context Definition Viewpoint | ||
| Conceptual User | The Conceptual User is the representation for a human in the Conceptual Domain, outside the SOI scope, interacting with the SOI. | Conceptual Context Element | System Use Case Viewpoint , System Context Definition Viewpoint | |
| Concern | Specifies an information need that a stakeholder of the SAF needs to be satisfied within an MBSE approach using SAF. | Framework Stakeholder and Concern Definition Viewpoint | ||
| 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] | Security Objective | Impact Analysis Viewpoint | |
| 1 Interaction Point Connection 1 Interaction Point | Specifies the connection of two interaction points. | |||
| 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." | Impact Analysis Viewpoint | ||
| Context Function | 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. | General Function | System Process Viewpoint , System Functional Breakdown Structure Viewpoint | |
| 0..* Context Function Context Function in System Process 0..* System Process | Specifies the fact that a Context Function is used in a System Process. | General Functional Usage | System Process Viewpoint , System Functional Breakdown Structure Viewpoint | |
| CounterClaim | A party's claim is a counter-claim if one party asserts claims in response to the claims of another. | Argumentation Assurance Viewpoint | ||
| Description | ||||
| Domain | Domain captures viewpoints that belong together within typical SE workflow stages. | Framework Viewpoint Overview Viewpoint | ||
| 1..* Evidence EVCreinforcingAGT 1..* Argument | Specifies the fact that an argument is reinforced by one or more evidence via a argument-evidence relation. | Argumentation Assurance Viewpoint | ||
| Effect | Effect on System , Effect on Operator , Effect on People , Effect on Environment | |||
| Effect on Environment | Effect | Impact Analysis Viewpoint | ||
| Effect on Operator | Effect | Impact Analysis Viewpoint | ||
| Effect on People | Effect | Impact Analysis Viewpoint | ||
| Effect on System | Effect | Impact Analysis Viewpoint | ||
| 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. | Argumentation Assurance Viewpoint | ||
| Exchange | Specification for general item exchange (energy, material, information, etc.). | |||
| Exchange Kind | Specification for a general kind of item (energy, material, information, etc.) to be exchanged. | |||
| 1..* Functional Requirement FRboundedByNFR 0..* Non-functional Requirement | Specifies the fact that a Non-Functional Requirement constrains Functional Requirements. | System Requirement Definition Viewpoint , System Requirement Traceability Viewpoint | ||
| 1..* Functional Requirement FRrefiningSFN 1 System Function | Specifies the fact that a System Function is refined by Functional Requirements. | System Requirement Traceability Viewpoint | ||
| Functional Requirement | Functional Requirements specify System Functions of the System. | System Requirement | System Requirement Definition Viewpoint | |
| 1 Grid GDcontainingAT 1..* Aspect | Specifies that the grid is composed of several aspects. | Grid Definition Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| 1 Grid GDcontainingDN 1..* Domain | Specifies that the grid is composed of several domains. | Grid Definition Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| 1 Grid GDcontainingVP 1..* Viewpoint | Specifies that the grid contains multiple viewpoints | Grid Definition Viewpoint | ||
| 1 General Scenario Participation General Chronological Message 1 General Scenario Participation | Ordered sequential occurrence of exchanges between General Interaction Scenario Participants. | |||
| General Context | Specifies a General Context. | System Context , Operational Context , Security Context | ||
| General Context Element | Specifies a General Context Element. | System | Operational Performer , System Context Element , Security Context Element | |
| 1..* General Context Element General Context Element Role 1..* General Context | Specifies the fact that a General Context Element exists in a given General Context. | System Role | Operational Context Role , System Context Element Role | |
| General Function | Specifies a General Function. It is used as base Class for specific System or Context Functions, or Partial Functions. | System Function , System Partial Function , Context Function | ||
| General Function Exchange Point | A Exchange Point of a Function | |||
| General Function Usage Exchange Point | Exchange point of functional usage. | System Process Viewpoint , System Functional Refinement Viewpoint | ||
| General Functional Exchange | Specifies the fact that an General Functional Exchange between General Function Usage Exchange Points Parameters is taking place. | System Process Viewpoint , System Functional Refinement Viewpoint | ||
| 1 General Function General Functional Usage 0..* General Function | Specifies a General Usage of a General Function within one or more other General Functions. | System Function in System Process , Context Function in System Process , System Partial Function in System Function | System Function Mapping Viewpoint | |
| General Interaction Scenario | Ordered sequence of exchanges of information, energy, or material between General Interaction Scenario Participants. | |||
| General Physical Role | General concept of usage of system elements in the context of other system elements on physical level. | Hardware Element Role , Software Element Role , Physical Software Role , Physical Element Role , Physical Hardware Role | ||
| General Scenario Participant | ||||
| 0..* General Context Element Role General Scenario Participation 0..* General Interaction Scenario | Specifies the fact that a System Role participates in a General Interaction Scenario. | |||
| Glossary | specifies a coherent set of terms. | |||
| Goal | A Goal is defined as an end state that a Stakeholder intends to achieve. Goals are generally expressed using qualitative words; e.g., “increase”, “improve”, or “easier”. Goals can also be decomposed; e.g., “increase profit” can be decomposed into the Goals “reduce cost” and “increase sales”. However, it is also very common to associate concrete objectives with Goals, which can be used to describe both the quantitative and time-related measures which are essential to describe the desired state, and when it should be achieved. | |||
| Grid | The grid manages the viewpoints in grid cells assigned to the categories of an domain (row) and an aspect (column). | Grid Definition Viewpoint | ||
| Hardware Element | Pure Hardware Elements. Similarity with the V-Model "hardware unit". | Abstract Physical Element | Physical Structure Definition Viewpoint , Physical Internal Exchange Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| 1 Hardware Element Hardware Element Role 0..* Hardware Element | Specifies the fact that a hardware structure comprises hardware elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| Intangible Resource | 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.“ | Asset | Asset Identification Viewpoint | |
| 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] | Security Objective | Impact Analysis Viewpoint | |
| Interaction Point | Specifies the existence of an interaction point. | |||
| Interaction Point Definition | Specifies the exchange capabilities of an interaction point on Physical Level. | |||
| Interaction Point Property | Specifies a detail of an interaction point. | |||
| L0-Unlikely | Likelyhood Parameter | |||
| L1-Rather Unlikely | Likelyhood Parameter | |||
| L2-Likely | Likelyhood Parameter | |||
| L3-Very Likely | Likelyhood Parameter | |||
| L4-Almost Certain | Likelyhood Parameter | |||
| 1..* Conceptual Context Element LCEactingInSUC 1..* System Use Case | Specifies the fact that a Logical Context Element acts in one or more System Use Cases. | System Use Case Viewpoint | ||
| 0..* Conceptual Interaction Point LCPboundedByPLS 0..1 Physical Layer Stack | Specifies the fact that a Logical Interaction Point is constrained to be implemented on a particular Physical Layer Stack. | |||
| 1..* Conceptual Environment LENconceptingPEN 1..* Physical Environment | Specifies the fact that a logical Environment Entity is a concept for a Physical Environment Entity. | |||
| 1..* Conceptual External System LESconceptingPES 1..* Physical External System | Specifies that the Logical System is a concept for a Physical System. | |||
| 0..* Conceptual System LETbeeingInSSE 0..* System State | Specifies the System States a Logical Element can be in. | System State Viewpoint | ||
| 1..* Conceptual System LETimplementingGFN 1..* General Function | Specifies the fact that a Logical Element is responsible to implement a System Function. Note: Logical Elements don't "implement" anything, they pass the function implementation task to Physical Elements. | System Function Mapping Viewpoint | ||
| 0..* Conceptual Item Exchange LIEboundedByPL 0..1 Physical Layer | Specifies the fact that a Logical Item Exchange is constrained to be implemented on a particular Physical Layer. | |||
| 0..* Conceptual Item Exchange LIEboundedByPLS 0..1 Physical Layer Stack | Specifies the fact that a Logical Item Exchange is constrained to be implemented on a particular Physical Layer Stack. | |||
| 0..* Conceptual Item Exchange LIEimplementsOIE 0..* Operational Item Exchange | specifies that this exchange in the FD implements (possibly partly) that exchange in the OD | |||
| 1..* Conceptual User LURconceptingPUR 1..* Physical User | Specifies that the Logical user is a concept for a Physical User. | |||
| Likelyhood Parameter | Security Context Element | L0-Unlikely , L1-Rather Unlikely , L2-Likely , L3-Very Likely , L4-Almost Certain | Threat Szenario Viewpoint | |
| Logical Context SOI_ Deprecated | Represents the Logical SOI in the System Context on Logical Level. | Conceptual System | ||
| Need | A User has a Need in order to reach a certain Goal. Note: "Buying sugar to bake a birthday cake". | |||
| Non-functional Requirement | Non-Functional Requirements specify the quality of System Functions, or non-functional requests like legal conformance. | System Requirement | System Requirement Definition Viewpoint | |
| 1 Operational Capability OCYcomposedOF 0..* Operational Capability | Specifies the fact that an Operational Capability consists of other Operational Capabilites. | Operational Capability Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| 0..* Operational Capability OCYdependingON 0..* Operational Capability | Specifies the fact that an Operational Capability depends on another Operational Capability. Aliases: UAF::CapabilityDependency | Operational Capability Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| 1 Operational Capability OCYspecializedBY 0..* Operational Capability | Specifies the fact that an Operational Capability is specialized by other Operational Capability. Aliases: UAF::CapabilityGeneralization | Operational Capability Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| 0..* Operational Capability OCYsupportingOSY 0..* Operational Story | Specifies the fact that an Operational Story is supported by Operational Capabilities. | Operational Capability Mapping Viewpoint | ||
| 1 Operational Interaction Scenario OIScontainingOCM 0..* Operational Chronological Message | Specifies the fact that an Operational Interaction Scenario contains one or more Operational Chronological Messages. | |||
| 1..* Operational Interaction Scenario OISrefiningOSY 1 Operational Story | Specifies the fact that an Operational Story is refined by one or more Operational Interaction Scenarios. | |||
| 1..* Operational Performer OPRactingInOSY 1..* Operational Story | Specifies the fact that an Operational Performer acts in an Operational Story. | Operational Story Viewpoint | ||
| 1 Operational Performer OPRcomposedOF 0..* Operational Performer | Specifies the fact that an Operational Performer consists of one or more Operational Performers. | Operational Performer Definition Viewpoint | ||
| 1 Operational Performer OPRexhibitingOCY 0..* Operational Capability | Specifies the fact that an Operational Performer exhibits an Operational Capability under specific environmental conditions. | Operational Capability Mapping Viewpoint | ||
| 0..* Operational Performer OPRspecializesOPR 0..1 Operational Performer | Specifies the fact that an Operational Performer may be a specialization of an other Operational Performer. | Operational Performer Definition Viewpoint | ||
| 0..* Operational Performer OPbeeingInOSE 0..* Operational State | Specifies that an Operational Perfomer can have certain states. Note: Of course an item is in only one distinct state at a certain time. The multiplicity means that an Item can have a set of possible states, and a state can be used to specify possible States for several operational performers. | Operational State Viewpoint | ||
| 1..* Operational Story OSYtakingPlaceInOCT 1 Operational Context | Specifies the fact that an Operational Story occurs in a certain Operational Context. Note: When parts of an Operational Story do occur in several contexts, they shall be duplicated. | Operational Story Viewpoint | ||
| Operational Capability | 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 | System Capability Definition Viewpoint , System Capability Mapping Viewpoint , Stakeholder Requirement Definition Viewpoint , Operational Capability Definition Viewpoint , Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | ||
| 1 Operational Scenario Participation Operational Chronological Message 1 Operational Scenario Participation | Ordered sequential occurrence of exchanges between Operational Interaction Scenario Participants. | Operational Context Interaction Viewpoint | ||
| 1 Operational Context Role Operational Connection 1 Operational Context Role | Specifies the connection between Operational Context Roles in an Operational Context allowing Operational Item Exchange. Aliases: UAF::OperationalConnector | Operational Context Exchange Viewpoint | ||
| Operational Context | 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 | General Context | Operational Story Viewpoint , Operational Context Definition Viewpoint , Operational Context Exchange Viewpoint | |
| 1..* Operational Performer Operational Context Role 1..* Operational Context | 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. | General Context Element Role | Operational Context Interaction Viewpoint , Operational Context Definition Viewpoint , Operational Process Viewpoint , Operational Context Exchange Viewpoint | |
| Operational Exchange Type | Specifies the type of Operational Item Exchange between Operational Context Roles or Operational Processes. | Operational Process Viewpoint , Operational Context Exchange Viewpoint , Operational Exchange Type Definition Viewpoint | ||
| Operational Interaction Scenario | Ordered sequence of exchanges of information, energy, or material between Operational Interaction Scenario Participants. | Operational Context Interaction Viewpoint | ||
| Operational Item Exchange | Specifies the Operational Item Exchange that is to take place on an Operational Connection. Aliases: UAF::OperationalExchange | Operational Context Exchange Viewpoint | ||
| Operational Performer | 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 | General Context Element | Stakeholder Identification Viewpoint , Operational Story Viewpoint , Operational Context Definition Viewpoint , Operational Process Viewpoint , Operational Performer Definition Viewpoint , Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | |
| Operational Process | 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 | Operational Process Viewpoint , Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | ||
| 1 Operational Process Operational Process Usage 0..* Operational Process | Specifies the fact that an Operational Process is used in context of another Operational Process. Aliases: UAF::OperationalAction | Operational Process Viewpoint | ||
| 1 Operational Process Usage Operational Process Usage Exchange 1 Operational Process Usage | Specifies the fact that an Operational Process has an exchange with another Operational Process in context of an operational process usage. | Operational Process Viewpoint | ||
| 1..* Operational Context Role Operational Scenario Participation 0..* Operational Interaction Scenario | Specifies the fact that an Operational Context Role participates in an Operational Interaction Scenario. | Operational Context Interaction Viewpoint | ||
| Operational Sketch | Specifies a free form sketch depicting a concept. | Operational Story Viewpoint | ||
| Operational State | Describes a state (or mode) of on operational level. | Operational State Viewpoint | ||
| 1 Operational State Operational State Transition 1 Operational State | Describes an allowed transition between two states on operational level. | Operational State Viewpoint | ||
| Operational Story | 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. | System Use Case Viewpoint , Operational Story Viewpoint , Stakeholder Requirement Definition Viewpoint , Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | ||
| Operational Triggering Event | specifies an event causing a state transition on operational level | |||
| 0..* Physical Connection PCCapplyingToPCN 0..1 Physical Connector Compatibility | Specifies the fact that a Physical Connector Compatibility Assertion shall apply to a Physical Connection. | |||
| 1 Physical Connector Compatibility PCCassertsCompatibiltyForPCPD 2 Physical Interaction Point Definition | Specifies the Physical Interaction Point Definition the Physical Compatibility Assertion is valid for. | |||
| 1 Physical Connection PCNallowingPIE 0..* Physical Item Exchange | Specifies the fact that a Physical Item Exchange is allowed on the Physical Connection. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint | ||
| 1 Physical Interaction Point PCPOverPCP 1 Physical Interaction Point | Specifies the fact that a physical interaction point communicates / transfers / flows / over an other physical interaction point. Used to define layered physical interfaces, and show layer relationships between interfaces. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| 1 Physical Interaction Point Property PCPPOverPCPP 1 Physical Interaction Point Property | Specifies the fact that a physical interaction point property communicates / transfers / flows / over an other physical interaction point property. Used to define layered physical interfaces, and show layer relationships between interface details. | Physical Interface Definition Viewpoint | ||
| 0..* Physical Interaction Point PCPisPartOfPIPD 1 Physical Interaction Point Definition | specifies that a physical interaction point can be a part of a physical interaction point definition. This fosters reuse and allows structuring of definitions. | Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| 0..1 Physical Layer PEKisAssignedToPL 0..* Physical Exchange Type | Specifies the fact that a Physical Exchange Kind is assigned to a particular Physical Layer. | |||
| 1 Physical Interaction Point Definition PIPDdefiningDetailOfPIP 0..* Physical Interaction Point | Specifies the fact that a Physical Interaction Point Definition defines the exchange capabilities of a Physical Interaction Point. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| 0..* Physical Interaction Point Property PIPPspecifyingDetailOfPIPD 1 Physical Interaction Point Definition | Specifies the fact that a Physical Interaction Point Property is a detail of a Physical Interaction Point Definition. | Physical Interface Definition Viewpoint | ||
| 0..* Physical Interaction Point PIPapplyingToAPE 1 Abstract Physical Element | Specifies the fact that a Physical Interaction Point applies to an Abstract Physical Element. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint | ||
| 0..* Physical Interaction Point PIPapplyingToPCE 1 Physical Context Element | Specifies the fact that a Physical Interaction Point applies to a Physical Context Element. | Physical Context Exchange Viewpoint | ||
| 0..* Physical Layer Ordering PLOisValidInPLS 1 Physical Layer Stack | Specifies the fact that a Physical Layer Ordering is valid within a particular Physical Layer Stack. | |||
| 1 Physical Interaction Point Physical Connection 1 Physical Interaction Point | Specifies the connection of two physical interaction points. Note: Connections between physical components indicate that item flows are passed from one output of a source component to one or more inputs of target components. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint | ||
| Physical Connector Compatibility | Specifies the fact that two Physical Interaction Point Definitions are compatible and how the Physical Interaction Point Properties are mapped. | |||
| Physical Context Element | Abstract element of a System Context on Physical Level, outside the SOI scope, interacting with the SOI. | Physical Environment , Physical External System , Physical User | ||
| 1..* Physical Context Element Physical Context Element Role 1..* Physical System Context | Specifies the fact that a Physical Context Element exists in a given Physical System Context. | Physical Context Definition Viewpoint | ||
| Physical Element | A composition of Hardware and Software Elements. Similarity with the V-Model segments and system. See [VXT]. | Abstract Physical Element | Physical Structure Definition Viewpoint , Physical Internal Exchange Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| 1 Physical Element Physical Element Role 0..* Physical Element | Specifies the fact that a physical structure comprises physical elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| Physical Environment | The Physical Environment in the Physical Domain, outside the SOI scope, interacting with the SOI. E.g. air, dirt, sun, road. | Physical Context Element | Physical Context Definition Viewpoint , Physical Context Exchange Viewpoint | |
| Physical Exchange Type | 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. | Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint , Physical Logical Item Mapping Viewpoint , Physical Exchange Type Definition Viewpoint | ||
| Physical External System | The Physical External System in the Physical Domain, outside the SOI scope, interacting with the SOI. E.g. power grid, mobile network, fresh water system (in a house). | Physical Context Element | Physical Context Definition Viewpoint , Physical Context Exchange Viewpoint | |
| 1 Physical Element Physical Hardware Role 0..* Hardware Element | Specifies the fact that a physical structure comprises hardware elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| Physical Interaction Point | Specifies the existence of an interaction point on Physical Level. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| Physical Interaction Point Definition | Specifies the exchange capabilities of an interaction point on Physical Level. | Physical Interface Definition Viewpoint | ||
| Physical Interaction Point Property | Specifies a detail of an interaction point on Physical Level. | Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| Physical Item Exchange | Specifies the exchange that is to take place on a Physical Connection. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint | ||
| Physical Layer | Specifies a Physical Layer, usually used for communication. | |||
| 0..1 Physical Layer Physical Layer Ordering 0..1 Physical Layer | Specifies an order among two physical layers. This order is valid within a Physical Layer Stack | |||
| Physical Layer Stack | Specifies a detail of an interaction point on Physical Level. | |||
| Physical SOI | Represents the Physical SOI on Physical Level. | Abstract Physical Element | Physical Context Definition Viewpoint , Physical Context Exchange Viewpoint , Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint | |
| 1..* Physical SOI Physical SOI Role 1 Physical System Context | Specifies the fact that a Physical SOI exists in a given Physical System Context. | Physical Context Definition Viewpoint | ||
| 1 Physical Element Physical Software Role 0..* Software Element | Specifies the fact that a physical structure comprises software elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| Physical System Context | Specifies the fact that a context for a System of Interest is defined on Physical Level. | Physical Context Definition Viewpoint | ||
| Physical User | The Physical User is the representation for a human in the physical domain, outside the SOI scope, interacting with the SOI. | Physical Context Element | Physical Context Definition Viewpoint , Physical Context Exchange Viewpoint | |
| Process | Unit of Work in Systems Engineering. | |||
| ProfileItem | SAF Stereotype , SysML Stereotype , UML Metaclass | |||
| 1 Refuter RFTmakingCCM 1..* CounterClaim | Specifies the fact that a counter-claim is made by a defined refuter. | |||
| 1..* Stakeholder Rationale 1..* Concern | Specifies why a stakeholder has a concern. Typically that has to do with the work a stakeholder has to do within an MBSE approach. | Framework Stakeholder and Concern Definition Viewpoint | ||
| Refuter | A party asserting counter-claims. | Argumentation Assurance Viewpoint | ||
| Risk | Security Context Element | Security Risk Analysis Viewpoint | ||
| S0-No Effect | Severity Level | Impact Analysis Viewpoint | ||
| S1-Minor | Severity Level | Impact Analysis Viewpoint | ||
| S2-Major | Severity Level | Impact Analysis Viewpoint | ||
| S3-Hazardous | Severity Level | Impact Analysis Viewpoint | ||
| S4-Catastrophic | Severity Level | Impact Analysis Viewpoint | ||
| SAF Stereotype | A stereotype of the SAF Profile Model | ProfileItem | Framework Viewpoint Implementation Viewpoint | |
| SAL1-Low | Security Assurance Level | |||
| SAL2-Medium | Security Assurance Level | |||
| SAL3-High | Security Assurance Level | |||
| 0..* System Context Element SCEactingForOPR 1 Operational Performer | Specifies the fact that a System Context Element is acting for the benefit of an Operational Performer. | |||
| 1..* System Context Element SCErepresentedBySSH 0..* System of Interest Stakeholder | Specifies the fact that a System Context Element is represented by a SOI Stakeholder. | Stakeholder Identification Viewpoint | ||
| 1 System Context Interaction Scenario SCIScontainingLCM 0..* System Context Chronological Message | Specifies the fact that a System Context Interaction Scenario contains one or more System Context Chronological Messages. | |||
| 1 System Capability SCYcomposedOF 0..* System Capability | Specifies the fact that a System Capability consists of other System Capabilities. | System Capability Definition Viewpoint , System Capability Mapping Viewpoint | ||
| 0..* System Capability SCYdependingON 0..* System Capability | Specifies the fact that a System Capability requires another System Capability. Aliases: UAF::CapabilityDependency | System Capability Definition Viewpoint , System Capability Mapping Viewpoint | ||
| 0..* System Capability SCYenablingOCY 1 Operational Capability | Specifies the fact that an Operational Capability integrates System Capabilities to produce a specific outcome to achieve a mission objective. | System Capability Definition Viewpoint | ||
| 0..* System Capability SCYsatisfyingSHR 0..* Stakeholder Requirement | Specifies the fact that a System Capability satisfies one or more Stakeholder Requirements. | |||
| 1 System Capability SCYspecializedBY 0..* System Capability | 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 | System Capability Definition Viewpoint , System Capability Mapping Viewpoint | ||
| 0..* System Capability SCYsupportingSUC 0..* System Use Case | Specifies the fact that a System UseCase is supported by System Capabilities. | System Capability Mapping Viewpoint | ||
| 1 Conceptual Exchange Type SDK is Asset in Security Context 1 Security Context | Asset | Asset Identification Viewpoint | ||
| SE Concept | specifies a SE concept to be supported by SAF | relatesTo | Framework Concept Definition Viewpoint , Framework Viewpoint Implementation Viewpoint | |
| 1 System Function SF is Asset in Security Context 1 Security Context | 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.“ | Asset | Asset Identification Viewpoint | |
| 1..* System Function SFNallocatedToAPE 1 Abstract Physical Element | Specifies the fact that a relationship is derived from the assignment of Functions to Logical Elements and the assignment of Logical Elements to Physical Elements. | Physical Functional Mapping Viewpoint | ||
| 1 System Function SFNboundedByNFR 0..* Non-functional Requirement | Specifies the fact that a Non-functional Requirement constrains System Functions. | |||
| 0..* System Function SFNhasPostconditionSSE 0..* System State | Specifies the fact that a System Function can perform a particular set of transitions, resulting in the related target System States. | System State Viewpoint | ||
| 0..* System State SFNhasPreconditionSSE 0..* System Function | Specifies the fact a System Function may have System States as precondition. This means that the Function is only provided in distinct States. | System State Viewpoint | ||
| 0..* System Function SFNsupportingSCY 0..* System Capability | Specifies the fact that a System Function supports one or more System Capabilities. | System Capability Mapping Viewpoint | ||
| 1..* Stakeholder Requirement SHRimposedBY 1 System of Interest Stakeholder | Specifies the fact that a Stakeholder Requirement is provided by Stakeholders. | Stakeholder Requirement Definition Viewpoint | ||
| 1..* Stakeholder Requirement SHRrefiningCRN 1..* System of Interest Concern | Specifies the fact that a Stakeholder Concern is refined by Stakeholder Requirements. | Stakeholder Requirement Definition Viewpoint | ||
| 0..* Stakeholder Requirement SHRrefiningOCY 0..* Operational Capability | Specifies the fact that an Operational Capability is refined by Stakeholder Requirements. | Stakeholder Requirement Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| 0..* Stakeholder Requirement SHRrefiningOSY 0..* Operational Story | Specifies the fact that an Operational Story is refined by Stakeholder Requirements. | Stakeholder Requirement Definition Viewpoint | ||
| 0..* System Of Interest SOIactingForOPR 1 Operational Performer | Specifies the fact that a SOI is acting for the benefit of an Operational Performer. | |||
| 1..* System Partial Function SPFNallocatedToAPE 1 Abstract Physical Element | Specifies the fact that a System Partial Function is assigned to an Abstract Physical Element. Note: This fact may be derived from the Usage of Function of a System Partial Function allocated to a Physical SOI Element Role | Physical Functional Mapping Viewpoint | ||
| 1..* System Partial Function SPFNallocatedToLET 1 Conceptual System | Specifies the fact that a System Partial Function is assigned to a Logical SOI Element. Note: This fact may be derived from the Usage of Function of a System Partial Function allocated to a Internal Logical Element Role | |||
| 0..* System Process SPSenablingOPS 0..1 Operational Process | Specifies the fact that a System Process enables the accomplishment of an Operational Process. | |||
| 0..* System Requirement SRderivingFromSR 1 System Requirement | Specifies the fact that System Requirements are derived from a Stakeholder Requirement. Note: This is the relationship of requirements of different architectural levels. When the team responsible for the subsystem has direct access to the full upstream requirements set, then no subcontractor relationship needs to be established. | System Requirement Definition Viewpoint , System Requirement Traceability Viewpoint | ||
| 0..* System Requirement SRderivingFromSTKR 1..* Stakeholder Requirement | Specifies the fact that a System Requirement is derived from a Stakeholder Requirement. Note: It may be used in a customer supplier relationship situation and supports the V Model concept of "External Unit Specification". See [VXT]. | System Requirement Definition Viewpoint , System Requirement Traceability Viewpoint | ||
| 0..* System Requirement SRrefiningLICP 0..* Conceptual Interaction Point | Specifies the fact that a Logical Interaction Point is refined by System Requirements. | System Requirement Traceability Viewpoint | ||
| 0..* System Requirement SRrefiningSCY 0..* System Capability | Specifies the fact that a System Capability is refined by System Requirements. | System Requirement Traceability Viewpoint , System Capability Mapping Viewpoint | ||
| 0..* System Requirement SRrefiningSUC 0..* System Use Case | Specifies the fact that a System Use Case is refined by System Requirements. | System Requirement Traceability Viewpoint | ||
| 1 System of Interest Stakeholder SSHhavingCRN 1..* System of Interest Concern | Specifies the fact that a Stakeholder has certain Concerns. | Stakeholder Identification Viewpoint | ||
| 1 System of Interest Stakeholder SSHrelatedToSSH 0..* System of Interest Stakeholder | 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. | Stakeholder Identification Viewpoint | ||
| 0..* System of Interest Stakeholder SSHrepresentingOPR 1..* Operational Performer | Specifies the fact that a SOI Stakeholder is representing an Operational Performer. | Stakeholder Identification Viewpoint , Operational Performer Definition Viewpoint | ||
| 1 System of Interest Stakeholder SSHrepresentingUSR 0..* User | Specifies the fact that an User is represented by Stakeholders. | |||
| 0..* System Use Case SUCenablingOSY 0..* Operational Story | Specifies the fact that a System Use Case enables the realization of an Operational Story. | System Use Case Viewpoint | ||
| 0..* System Use Case SUChasPostConditionSSE 0..* System State | Specifies the fact that a System Use Case may have System States as Postcondition. | System Use Case Viewpoint | ||
| 0..* System Use Case SUChasPreConditionSSE 0..* System State | Specifies the fact that a System Use Case may have System States as Precondition. | System Use Case Viewpoint | ||
| 0..1 System Use Case SUCrefiningSHR 0..* Stakeholder Requirement | Specifies the fact that a Stakeholder Requirement is refined by System Use Cases. | |||
| 1..* System Use Case SUCtakingPlaceInLSC 1 Conceptual System Context | Specifies the fact that a System Use Case takes place in a Logical System Context. | System Use Case Viewpoint | ||
| Security Assurance Level | NIST SP 800-89: "The level of assurance (e.g., HIGH, MEDIUM, or LOW) that a claimed signatory possesses the private signature key." | SAL1-Low , SAL2-Medium , SAL3-High | Security Risk Analysis Viewpoint | |
| Security Context | 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." | System Context , General Context | Asset Identification Viewpoint , Security Context Viewpoint | |
| Security Context Element | An abstract element representing a Security Context Element. Base class for specific kinds of Security Context Elements. | General Context Element | Asset , Security Enviromental Element , Attack Vector (old) , Assumption , Severity Level , Target Misuse Case , Threat Scenario , Likelyhood Parameter , Risk | Asset Identification Viewpoint , Security Context Viewpoint |
| 1 Security Context Element Security Context Element Role 1 Security Context | ||||
| Security Enviromental Element | An abstract element representing a Security Context Element occurring in the environment of an asset. | Security Context Element | Adversary | Security Context Viewpoint |
| Security Measures | Security Risk Analysis Viewpoint | |||
| Security Objective | 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." | Confidentiality , Integrity , Availability | Asset Identification Viewpoint , Impact Analysis Viewpoint | |
| Security Requirements | Security Risk Analysis Viewpoint | |||
| Severity Level | Security Context Element | S0-No Effect , S1-Minor , S2-Major , S3-Hazardous , S4-Catastrophic | Impact Analysis Viewpoint | |
| Software Element | Pure Software Elements. Similarity with the V-Model "software unit". | Abstract Physical Element | Physical Structure Definition Viewpoint , Physical Internal Exchange Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| 1 Software Element Software Element Role 0..* Software Element | Specifies the fact that a software structure comprises software elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| Stakeholder | specifies someone (typically a role) having an information need within an MBSE approach. | Framework Stakeholder and Concern Definition Viewpoint | ||
| Stakeholder Requirement | 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. | System Requirement Definition Viewpoint , System Requirement Traceability Viewpoint , Stakeholder Requirement Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| Standard | Specifies a standard which shall potentially be complied by the system or a part of the system. | Common Standards Definition Viewpoint | ||
| Standardization Organization | An organization of standardization, e.g., International Organization for Standardization (ISO), Object Management Group (OMG), etc. | Common Standards Definition Viewpoint | ||
| Subject of Claim | Note: A claim cannot be generic, it has to be about something, it has to have a defined subject, e.g., system safety. | Argumentation Assurance Viewpoint | ||
| SysML Stereotype | A stereotype from sysml | ProfileItem | Framework Viewpoint Implementation Viewpoint | |
| System | An abstract element representing a System. | System Of Interest , General Context Element | ||
| System Capability | 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 | System Requirement Traceability Viewpoint , System Capability Definition Viewpoint , System Capability Mapping Viewpoint | ||
| System Context | Specifies the fact that a context for a System of Interest is defined. | General Context | Loss Context , Security Context | |
| 1 System Context Scenario Participation System Context Chronological Message 1 System Context Scenario Participation | Ordered sequential occurrence of exchanges between System Context Interaction Scenario Participants. | System Context Interaction Viewpoint | ||
| System Context Element | An abstract element representing a System Context Element. Base class for specific kinds of Context Elements. | General Context Element | Adversary | |
| 1..* System Context Element System Context Element Role 1..* System Context | Specifies the fact that a System Context Element exists in a given System Context. | General Context Element Role | ||
| System Context Interaction Scenario | Ordered sequence of exchanges of information, energy, or material between System Context Interaction Scenario Participants. | System Context Interaction Viewpoint | ||
| System Context Role | General role of a Logical System Context. | Conceptual Context Element Role , Conceptual SOI Role | ||
| 0..* System Context Role System Context Scenario Participation 0..* System Context Interaction Scenario | Specifies the fact that a System Context Role participates in a System Context Interaction Scenario. | System Context Interaction Viewpoint | ||
| System 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. | General Function | System Process Viewpoint , System Requirement Traceability Viewpoint , System Functional Breakdown Structure Viewpoint , System Functional Refinement Viewpoint , System Capability Mapping Viewpoint , System Function Mapping Viewpoint , Physical Functional Mapping Viewpoint | |
| 0..* System Function System Function in System Process 0..* System Process | Specifies the fact that a System Function is used in a System Process. | General Functional Usage | System Process Viewpoint , System Requirement Traceability Viewpoint , System Functional Breakdown Structure Viewpoint | |
| System Of Interest | An abstract element representing a SOI. Base class for specific kinds of SOIs. | System | ||
| System Partial Function | 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. | General Function | System Functional Breakdown Structure Viewpoint , System Function Mapping Viewpoint | |
| 0..* System Function System Partial Function in System Function 0..* System Partial Function | Specifies that a System Partial Function is used in a system function | General Functional Usage | System Functional Breakdown Structure Viewpoint , System Functional Refinement Viewpoint | |
| System Process | 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. | System Process Viewpoint , System Requirement Traceability Viewpoint , System Functional Breakdown Structure Viewpoint , System Capability Mapping Viewpoint | ||
| System Requirement | System Requirements specify System Functions, non-functional properties, or constraints of the System. | Functional Requirement , Non-functional Requirement | System Requirement Traceability Viewpoint , System Capability Mapping Viewpoint | |
| 1 System System Role 0..* System | Specifies, that a system is part of a system. | General Context Element Role | ||
| 1..* System Of Interest System SOI Role 1 System Context | Specifies the fact that a System SOI exists in a given System Context. | |||
| System State | Describes a state (or mode) of something on system level that can have distinct states. | System State Viewpoint | ||
| 1 System State System State Transition 1 System State | Describes an allowed transition between two system states of an item that can be in distinct States. | System State Viewpoint | ||
| System Triggering Event | an event that trigges a state transition | |||
| System Use Case | 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). | System Use Case Viewpoint , System Requirement Traceability Viewpoint , System Capability Mapping Viewpoint | ||
| System of Interest Concern | Any kind of interest a Stakeholder has. Note: Redundant with the meaning of "Need"? | Stakeholder Identification Viewpoint , Stakeholder Requirement Definition Viewpoint | ||
| System of Interest 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 | Stakeholder Identification Viewpoint , Stakeholder Requirement Definition Viewpoint , Operational Performer Definition Viewpoint | ||
| Tangible Resource | 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.“ | Asset | Asset Identification Viewpoint | |
| Target Misuse Case | Security Context Element | Threat Szenario Viewpoint | ||
| Term | Specifies the fact that a term is usually defined by a standard, but can also be defined as part of system development work. | Common Terms Definition Viewpoint | ||
| Threat Scenario | Security Context Element | Threat Szenario Viewpoint | ||
| UML Metaclass | A metaclass from UML | ProfileItem | Framework Viewpoint Implementation Viewpoint | |
| 1..* General Functional Usage USAGEallocatedTo 1 Conceptual Internal Role | Specifies the fact that a Usage of Function is allocated to a Usage of System Element. | System Function Mapping Viewpoint | ||
| User | Representation for a human in the Logical Domain, outside the SOI scope, interacting with the SOI. Note: This seems to be highly redundant with definition of "Role". | |||
| 0..* Viewpoint VPbelongingToAT 1 Aspect | specifies that a viewpoint belongs to one aspect. | Grid Definition Viewpoint , Framework Viewpoint Definition Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| 0..* Viewpoint VPbelongingToDN 1 Domain | specifies that a viewpoint belongs to one domain. | Grid Definition Viewpoint , Framework Viewpoint Definition Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| 0..* Viewpoint VPframesCN 1..* Concern | Specifies that a Viewpoint frames one or more concerns. That means that the views conform to that viewpoint satisfy the information need expressed by the concerns. | Framework Viewpoint Definition Viewpoint | ||
| 0..* View VWconformingToVP 1 Viewpoint | specifies that a view conforms to a viewpoint. | Grid Definition Viewpoint | ||
| View | A architecture view comprises portion of an architecture description and addresses information-relevant concerns framed by a architecture viewpoint. | Grid Definition Viewpoint | ||
| Viewpoint | A architecture viewpoint defines set of conventions for the creation, interpretation and use of an architecture view to frame one or more concerns | Framework Viewpoint Definition Viewpoint , Framework Viewpoint Implementation Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| Vulnerability | Threat Szenario Viewpoint | |||
| 1..* System Function allocatedTo 1 Conceptual System | Specifies the fact that a System Function is assigned to a Conceptual System. Note: This fact may be derived from the Usage of a System Function in a System Process allocated to a System Conceptual SOI Role. | |||
| 1 Conceptual Connection allowing 0..* Conceptual Item Exchange | Specifies the fact that a Conceptual Item Exchange is allowed on the Conceptual Connection. | System Internal Exchange Viewpoint | ||
| 1 Operational Connection allowing 0..* Operational Item Exchange | Specifies the fact that an Operational Item Exchange is allowed on the Operational Connection. | |||
| 1 Connection allowing 0..* Exchange | Specifies the fact that a connection allows Exchange to happen | |||
| 0..* General Functional Exchange appearing in 1 General Functional Usage | Specifies the fact that a Functional Exchange appears within a general Functiona Usage. | System Functional Refinement Viewpoint | ||
| 0..* Conceptual Interaction Point applyingTo 1 Conceptual System | Specifies the fact that a Conceptual Interaction Point applies to a Conceptual System. | System Context Exchange Viewpoint , System Internal Exchange Viewpoint | ||
| 0..* Conceptual Interaction Point applyingTo 1..* Conceptual Context Element | Specifies the fact that a Conceptual Interaction Point applies to a Conceptual Context Element. | System Context Exchange Viewpoint | ||
| 0..* Conceptual Exchange Type beeing in 0..* System State | Specifies that a Conceptual Exchange Type can have certain states. Note: Of course an item is in only one distinct state at a certain time. The multiplicity means that an Item can have a set of possible states, and a state can be used to specify possible States for several Conceptual Exchange Types. | System State Viewpoint | ||
| 0..* Standard categorized 0..* Category Of Standard | Specifies the fact that a standard is categorized by one or more categories. | Common Standards Definition Viewpoint | ||
| 1 Operational Exchange Type characterising 0..* Operational Item Exchange | Specifies the fact that an Operational Exchange Type characterises an Operational Item Exchange. | |||
| 1 Operational Exchange Type characterising 0..* Operational Process Usage Exchange | Specifies the fact that an Operational Exchange Type characterises an Operational Process Usage Exchange. | Operational Process Viewpoint | ||
| 1 General Functional Exchange coming from 1 General Function Usage Exchange Point | Specifies the fact that a General Functional Exchange is coming from a General Functional Usage Exchange Point. | |||
| 1 Conceptual Exchange Type composed of 0..* Conceptual Exchange Type | Specifies the fact that a Conceptual Exchange Type consists of one or more Conceptual Exchange Types. | System Exchange Type Definition Viewpoint | ||
| 1 Operational Exchange Type composed of 0..* Operational Exchange Type | Specifies the fact that an Operational Domain Kind may consists of zero or more Operational Domain Kinds. | Operational Exchange Type Definition Viewpoint | ||
| 0..* Any SAF Element conform to 0..* Standard | Specifies, that a SAF Element may be conform to one or more Standards. | Common Standards Definition Viewpoint | ||
| 1 Conceptual Interaction Scenario containing 0..* Conceptual Chronological Message | Specifies the fact that an Conceptual Interaction Scenario contains one or more Conceptual Chronological Messages. | |||
| 1 Glossary contains 0..* Term | specifies that a glossary contains a number of terms. A term is contained only in one glossary. | |||
| 0..* Standard contains 0..* Glossary | specifies that a standard may contain one or more glossaries. | |||
| 1 Operational Process Usage controlled after 1 Operational Process Usage | Specifies the sequencing of Operational Processes in time. | Operational Process Viewpoint | ||
| 1 General Functional Usage controlled after 1 General Functional Usage | Specifies a sequential execution of Functions. | System Process Viewpoint , System Functional Refinement Viewpoint | ||
| 0..* Term defined by 1 Standard | Specifies the fact that a term is defined by a standard. | Common Terms Definition Viewpoint | ||
| 1 Conceptual Interaction Point Definition defining 0..* Conceptual Interaction Point | Specifies the fact that a Conceptual Interaction Point Definition defines the exchange capabilities of a Conceptual Interaction Point. | System Interface Definition Viewpoint , System Internal Exchange Viewpoint | ||
| 0..* Standard depends on 0..* Standard | specifies that a standard depends on an other. | Common Standards Definition Viewpoint | ||
| 0..* Any SAF Element derives from 0..* Any EA Element | Specifies that any SAF element may derive from any EA elements. | EA Traceability Viewpoint | ||
| 0..* Conceptual Exchange Type deriving from 0..1 Operational Exchange Type | Specifies the fact that a Conceptual Exchange Type on system level is derived from an Operational Exchange Type. | |||
| 0..* Operational Process enabling 0..* Operational Capability | Specifies the fact that an Operational Process contributes to the provision of one or more Operational Capabilities in the field. Aliases: UAF::MapsToCapability | Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | ||
| 0..* System Process enabling 0..* System Capability | Specifies the fact that a System Process contributes to the provision of one or more System Capabilities in the field. | System Capability Mapping Viewpoint | ||
| 1 Exchange from 1 System | Specifies that an exchange comes from a system | |||
| 1 General Functional Exchange going to 1 General Function Usage Exchange Point | Specifies the fact that a General Functional Exchange is going to a General Functional Usage Exchange Point. | |||
| 0..* Operational Process has postcondition 0..* Operational State | Specifies the fact that a Operational Process can perform a particular set of transitions, possibly resulting in one of the related Operational States as a postcondition. | Operational State Viewpoint | ||
| 0..* System Process has postcondition 0..* System State | Specifies the fact that a System Process can have a particular set of transitions resulting in the System States as postcondition. | |||
| 0..* Operational Process has precondition 0..* Operational State | Specifies the fact that the Operational Process is only provided in distinct Operational States. The states ar a precondition for the Opeational Process to be able to perform. | Operational State Viewpoint | ||
| 0..* System Process has precondition 0..* System State | Specifies the fact that a System Process may have System States as precondition. This means that the System Process can only be executed in distinct states. | |||
| 1 System having 1..* General Function | Specifies, that a system has general functions. | |||
| 1 System having 0..* Interaction Point | Specifies the fact that a System has one or more Interaction Points. | |||
| 1 ProfileItem implements 1..* SE Concept | specifies that a stereotype from the SAF profile implements a concept | Framework Viewpoint Implementation Viewpoint | ||
| 1..* SAF Stereotype implements 1 Viewpoint | specifies, that one ore more SAF Stereotypes implement a viewpoint. Note: Multiple Stereotypes are used if there are alternate presentations. | Framework Viewpoint Implementation Viewpoint | ||
| 1 System Use Case including 0..* System Use Case | Specifies the fact that a System Use Case includes other System Use Cases. The included use case is then no longer a full System Use Case, but a partial System Use Case. | |||
| 0..* Standard including 0..* Standard | Specifies the fact that a standard is part of another standard. | Common Standards Definition Viewpoint | ||
| 0..* Any SAF Element informed by 0..* Any EA Element | Specifies that any SAF element may be informed by any EA elements. | EA Traceability Viewpoint | ||
| 0..* Interaction Point Property is detail of 1 Interaction Point Definition | Specifies the fact that an Interaction Point Property is a detail of an Interaction Point Definition. | |||
| 1..* SE Concept isProvidedBy 0..* Viewpoint | Specifies, that one or more SE Concepts are provided by the Viewpoints Views | Framework Viewpoint Definition Viewpoint | ||
| 0..* Standard issued by 1 Standardization Organization | Specifies the fact that a standard is issued by an organization of standardization. | Common Standards Definition Viewpoint | ||
| 0..* Operational Context Role performing 0..* Operational Process Usage | Specifies that an Operational Context Role uses an Operational Process in the context of an other Operational Process. | Operational Process Viewpoint | ||
| 0..* Conceptual Context Element Role performing 0..* Context Function in System Process | Specifies the fact that a Context Function is expected to be carried out by the Logical Context Element in this System Context. | System Process Viewpoint | ||
| 1..* Conceptual SOI Role performing 1..* System Function in System Process | Specifies the fact that a System Function is expected to be carried out by the SOI in this System Context. | System Process Viewpoint | ||
| 1..* Physical Exchange Type realizing 1 Conceptual Exchange Type | Specifies the fact that a Conceptual Exchange Type is realized by Physical Exchange Types. | Physical Logical Item Mapping Viewpoint , Physical Exchange Type Definition Viewpoint | ||
| 1 General Functional Usage receiving input through 0..* General Function Usage Exchange Point | Specifies the Input of a Functional Usage. | |||
| 1 General Function receiving input through 0..* General Function Exchange Point | Specifies the Input of a General Function. | |||
| 0..* Operational Process refining 1 Operational Story | Specifies the fact that an Operational Story is refined by one or more Operational Processes. | Operational Process Mapping Viewpoint | ||
| 0..1 System Process refining 1 System Use Case | Specifies the fact that a System Use Case is refined by one System Process. | System Requirement Traceability Viewpoint | ||
| 1 General Function Exchange Point related to 1 General Function Usage Exchange Point | specifies that a General Functional Exchange Point is related to a General Function Usage Exchange Point | |||
| 1 SE Concept relatesTo 0..* SE Concept | specifies that a SE concept may be related others. Relations are also concepts and may be subject or object of other relations. | SE Concept | Framework Concept Definition Viewpoint , Framework Viewpoint Definition Viewpoint | |
| 0..1 Any SAF Element represents 0..1 Any EA Element | Specifies that a SAF Element represents an EA Element. | EA Traceability Viewpoint | ||
| 1 Any SAF Element satisfyingSHR 0..* Stakeholder Requirement | Specifies the fact that a Stakeholder Requirement is satisfied by SAF Model Elements. | |||
| 1 General Functional Usage sending output through 0..* General Function Usage Exchange Point | Specifies the Output of a Functional Usage. | |||
| 1 General Function sending output through 0..* General Function Exchange Point | Specifies the Output of a General Function. | |||
| 1..* Conceptual System specifying 1 Abstract Physical Element | Specifies the fact that one or more Logical Element specifies exactly one Physical Element. Rationale: If more than one Physical Element would offer to realize the functionality specified by a Logical Element the responsibility would be ambiguous. It is okay to assign several Logical Elements to one Physical Element. This means all specified functionality assigned to the Logical Elements is to be implemented by the Physical Element. Note, that typically the usage of logical elements in a context is mapped to the usage of physical elements in a context (allocation of usage). Thus this relationship between the definitions is derived. | |||
| 1..* Conceptual Internal Role specifying 1 General Physical Role | Specifies that a usage of a Logical Element specifies functions for the usage of a Physical Element. | Physical Logical Mapping Viewpoint | ||
| 0..* Conceptual Interaction Point Property specifyingDetailOf 1 Conceptual Interaction Point Definition | Specifies the fact that a Conceptual Interaction Point Property is a detail of a Conceptual Interaction Point Definition. | System Interface Definition Viewpoint , System Internal Exchange Viewpoint | ||
| 1 Standard superseding 0..* Standard | Specifies the fact that a standard supersedes one or more other standards. | Common Standards Definition Viewpoint | ||
| 1 Exchange to 1 System | Specifies that a exchange goes to a system | |||
| 0..1 System Triggering Event triggering 0..* System State Transition | specifies that an System Triggering Event triggers a System State Transition. | System State Viewpoint | ||
| 0..1 Operational Triggering Event triggering 0..* Operational State Transition | Specifies that an Operational Triggering Event triggers an Operational State Transition | Operational State Viewpoint | ||
| 1 Conceptual Exchange Type typing 0..* Conceptual Item Exchange | Specifies the fact that a Conceptual Exchange Type defines the type of a Logical Item Exchange. | System Internal Exchange Viewpoint | ||
| 1 Conceptual Exchange Type typing 0..* Conceptual Interaction Point Property | Specifies the fact that a Conceptual Exchange Type defines the type of a Conceptual Interaction Point Property. | System Interface Definition Viewpoint , System Internal Exchange Viewpoint | ||
| 1 Conceptual Exchange Type typing 0..* General Function Usage Exchange Point | Specifies the fact that a Conceptual Exchange Type defines the type of a Function Parameter. | |||
| 1 Physical Exchange Type typing 0..* Physical Item Exchange | Specifies the fact that a Physical Exchange Kind defines the type of a Physical Item Exchange. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint , Physical Exchange Type Definition Viewpoint | ||
| 1 Physical Exchange Type typing 0..* Physical Interaction Point Property | Specifies the fact that a Physical Exchange Kind defines the type of a Physical Interaction Point Property. | Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint , Physical Exchange Type Definition Viewpoint | ||
| 1 Interaction Point Definition typing 0..* Interaction Point | Specifies the fact that an Interaction Point Definition defines the exchange capabilities of an Interaction Point. | |||
| 1 Exchange Kind typing 0..* Interaction Point Property | Specifies the fact that a Exchange Kind defines the type of a Interaction Point Property. | |||
| 1 Exchange Kind typing 0..* Exchange | Specifies the fact that a Exchange Kind defines the type of a Exchange. | |||
| 1..* System Use Case uses 0..* System Function | Specifies the fact that a System Function is used in a System Use Case, e.g., as a Trigger, Action, or Task. Note: This is a derived relationship. | |||
| 1..* System Use Case uses 0..* Context Function | Specifies the fact that a Context Function is used in a System Use Case, e.g., as a Trigger, Action, or Task. Note: This is a derived relationship. |