Disclaimer: System Architecture Framework Specification 
is work in progress
This repository contains both documentation for users of SAF and developers of SAF. To understand how we develop SAF, see how SAF is developed. We always welcome contributions from our MBSE community to improve SAF, see how to contribute to SAF.
The System Architecture Framework Specification application is demonstrated using the Fire Forest Detection System (FFDS) example, courtesy of Tim Weilkiens. The Fire Forest Detection System example is based on the publication SYSMOD - The Systems Modeling Toolbox, 3rd edition Pragmatic MBSE with SysML, Tim Weilkiens
This is the main branch that reflects the current state of development and it is updated as required. See the change report for an information ahout major changes.
The following SAF releases are available, each of which is managed in a separate branch:
The SAF specification is implemented by 3 tool specific profiles which are available in separate github repositories:
- Cameo Systems Modeler (by Dassault Systèmes)
- Engineering Systems Design Rhapsody (by IBM)
- Enterprise Architect (by Sparx Systems)
The SAF Viewpoints are organized as a Grid featuring Domains as rows and Aspects as columns.
The subsequent sections give an overview about the SAF viewpoint specifications, grouped by Domains. The specifications of the SAF viewpoints are available as PDF format, too.
The SAF Operational Domain aims to get an understanding of required organizational or operational entity capabilities, as a foundation and reasoning for to systems to be acquired or developed. The SAF Operational Domain supports the model-based development of a CONOPS - as well as an OPSCON and related life cycle concepts - for an organization or operational entity seeking for an improvement of existing capabilities or in establishing new ones. By identifying Stakeholders and their Requirements the SAF Operational Domain supports the derivation of a complete and consolidated set of Stakeholder Requirements based on operational stories, operational processes, operational capabilities, and operational exchanges.
- Operational Story Viewpoint
- Operational Context Definition Viewpoint
- Operational Context Exchange Viewpoint
- Operational Performer Viewpoint
- Operational Domain Item Kind Viewpoint
- Operational Capability Definition Viewpoint
- Stakeholder Identification Viewpoint
The SAF Functional Domain assumes a conceptual black box perspective onto the system to be developed. It translates Operational Domain usage into the notion of System Functions defining the demanded system behavior and quality attributes - performance, safety, security, etc.; the demanded system behavior as it is perceived by the User or other Entities at the System Boundary (known as usage behavior). The result of the elaboration of the viewpoints in the Functional Domain is a comprehensive System Specification.
- System Domain Item Kind Viewpoint
- System Capability Definition Viewpoint
- System Functional Breakdown Structure Viewpoint
- System Process Viewpoint
- System Functional Refinement Viewpoint
- System State Viewpoint
The SAF Logical Domain assume a conceptual white box perspective onto the system to be developed. The Logical Domain Viewpoints describe the Logical Structure and the distribution of responsibilities for the Functionality of the SOI by means of a network of interacting Logical Elements that are responsible for a set of desired Functions. These Logical Elements and their Interactions are arranged in the Logical Architecture of the SOI. The structure of the Logical Architecture is in general influenced by nonfunctional criteria, e.g., maintainability, safety, and reliability. The Logical Domain is not a different abstraction level - compared to the Functional Domain, but a white box perspective on the same abstraction level.
The SAF Physical Domain diagrams may be used to represent the Product Breakdown Structure, to identify external and internal physical interfaces, to provide diagrams for the system overview, to support the integration planning, to support production planning and to depict the features and variations implied in the system. The physical architecture typically is a combination of re-use elements, COTS elements and make-items for HW as well as for SW. The properties of the selected physical components and their provided resources are identified and modelled. A major concern of the Physical Domain are the physical interfaces, their identification and definition. For that purpose, the Physical Domain provides the diagrams to model interface with different level of detail considering the actual needs for the point of time in the project life cycle. For traceability the Physical Domain defines diagrams showing the mapping of the functional elements and their interfaces to physical elements and their interfaces.
- Physical Interface Definition Viewpoint
- Physical Protocol Stack Definition Viewpoint
The SAF Common Domain provides viewpoints addressing model information that is common to all other domains or that are applicable throughout the model.