<br/> 1. Referenced documents. This section shall list the number, title, revision, and date of all documents referenced in this plan. This section shall also identify the source for all documents not available through normal Government stocking activities. <br/>2. Format. Contractor’s format acceptable. The SAD shall adhere to the format described under Content. <br/>3. Content: This section shall be divided into paragraphs as needed to establish the context for the planning described in later sections: <br/><br/>3.1. Document management and configuration control information. Identify the version, release date, and other relevant management and configuration control information associated with the current version of the document. Include a change history, highlighting significant changes from version to version. <br/><br/>3.2. Purpose and Scope of the SAD. Explain the SAD’s overall purpose and scope. Explain the criteria for deciding which design decisions are architectural (and therefore documented in the SAD) and which design decisions are non-architectural (and there documented elsewhere). <br/><br/>3.3. How the SAD Is Organized. Provide a narrative description of the seven major sections of the SAD (as identified by this DID) and the overall contents of each. <br/><br/>3.4. Stakeholder Representation. <br/>3.4.1. Stakeholders and their concerns. Provide a list of the stakeholder roles considered in the development of the architecture described by this SAD. For each, list the<br/>concerns that the stakeholder has that can be addressed by the information in this SAD. A convenient way to represent this information is as a matrix, where the rows list stakeholder roles, the columns list concerns, and a cell in the matrix contains an indication of how serious the concern is to a stakeholder in that role. The following stakeholders shall be considered: <br/>a. Application software developers <br/>b. Infrastructure software developers <br/>c. End users <br/>d. Project Segment Teams <br/>e. Application system engineers <br/>f. Application and platform hardware engineers <br/>g. Security engineers and certifiers <br/>h. Safety engineers and certifiers <br/>i. Communications engineers <br/>j. System of system engineers <br/>k. Chief Engineer/Chief Scientist <br/>l. LSI Program management <br/>m. Government Program management (including those concerned with licensing) <br/>n. System integration and test engineers <br/>o. External test agencies <br/>p. Operational system managers <br/>q. Trainers <br/>r. Maintainers <br/>s. Other Service representatives <br/>t. Auditors (LSI internal, GAO, etc.) <br/><br/>3.5. Representatives of standardization activities <br/>3.5.1. Stakeholder Scenarios for Using the SAD. For each stakeholder role identified in Section 1.4.1, detail a few short scenarios that explain how that stakeholder would use specific sections of the SAD to help address concerns. <br/><br/>3.6. Viewpoint and View Definitions <br/>3.6.1. Introduction to Viewpoints. Provide a short textual definition of a viewpoint and how the concept is used in this SAD. <br/>3.6.2. Describe each viewpoint used in the SAD using the following outline. The SAD shall include at least the following viewpoints: <br/>3.6.2.1. Communications viewpoint. Views conforming to this viewpoint show the communication paths used by software-initiated or software-carried messages, and the software elements that send and receive information along those paths. Views conforming to this viewpoint provide the basis for analysis to determine whether necessary communication bandwidth and performance will be achieved to enable the system to meet all of its operational requirements that depend on communication. <br/>3.6.2.2. Data load viewpoint. Views conforming to this viewpoint show data required and provided by software elements, and show where that data is stored, how it is backed up and recovered in the event of loss. Views conforming to this viewpoint provide the basis for analysis to determine whether units will have access to the necessary information. <br/>3.6.2.3. Information assurance viewpoint. Views conforming to this viewpoint show the location and flow of classified or otherwise sensitive information in the system, as well as elements that provide essential services that must be protected from denial-of-service attacks. Views conforming to this viewpoint provide the basis for analysis to determine whether the system’s information assurance needs will be met. <br/>3.6.2.4. Safety viewpoint. Views conforming to this viewpoint show elements that provide safety-critical functionality and how they are used. Views conforming to this viewpoint provide the basis for analysis to determine whether the system’s safety needs will be satisfied. <br/>3.6.2.5. Cyber Security viewpoint. Views conforming to this viewpoint show elements that provide cyber security functionality and how they are used. Views conforming to this viewpoint provide the basis for analysis to determine whether the system’s cyber security needs will be satisfied. Considerations: <br/>3.6.2.5.1. Separation Kernel. <br/>3.6.2.5.2. Separation of portions of Operational Flight Program that use data from external sources and reuse of unsecure code. <br/>3.6.2.5.3. Use of time and space partitioning. <br/>3.6.2.5.4. Use of information flow control. <br/>3.6.2.5.5. Data validation of any data from external sources. <br/>3.6.2.5.6. Use of sanitization. <br/>3.6.2.5.7. Use of encryption. <br/>3.6.2.5.8. Use of watchdog timers. <br/>3.6.2.5.9. Use of non-volatile memory storage for Operational Flight Program. <br/>3.6.2.5.10. Separation of control instructions and data. <br/>3.6.2.5.11. Health and fault monitoring and reporting. <br/>3.6.2.5.12. System degraded states. <br/>3.6.2.5.13. Host-Based Security System (HBSS) incorporation. <br/>3.6.2.5.14. Authentication and lowest level privilege access. <br/>3.6.2.5.15. Common Attack Pattern Enumeration and Classification (CAPEC) <br/>3.6.2.5.15.1. Design and architecture considerations <br/>3.6.2.5.15.2. Selection of programming language(s) <br/>3.6.2.5.15.3. Use of COTS and open source code <br/>3.6.2.6. Reliability viewpoint. Views conforming to this viewpoint show elements that provide mission-critical functionality, how they are used, and any redundancy or failover capabilities provided to assume that functionality in the event of failure. Views conforming to this viewpoint provide the basis for analysis to determine whether the system’s reliability needs will be satisfied. <br/>3.6.3. Viewpoints <br/>3.6.3.i Name the viewpoint. <br/>a. Abstract. Provide a brief overview of the viewpoint. <br/>b. Stakeholders and Their Concerns Addressed. Describe the stakeholders and their concerns that this viewpoint is intended to address. List questions that can be answered by consulting views that conform to this viewpoint. Include significant questions that cannot be answered by consulting views conforming to this viewpoint. <br/>c. Elements, Relations, Properties, and Constraints. Define the types of elements, the relations among them, the significant properties they exhibit, and the constraints they obey for views conforming to this viewpoint. <br/>d. Language(s) to Model/Represent Conforming Views. List the language or languages that will be used to model or represent views conforming to this viewpoint, and cite a definition document for each. <br/>e. Applicable Evaluation/Analysis Techniques and Consistency/Completeness Criteria <br/>f. Viewpoint Source. Provide a citation for the source of this viewpoint definition, if any. <br/>3.7. How a view is documented. Describe the documentation organization for documenting a view. <br/><br/>3.8. Relationship to Other SADs. Describe the relationship between this SAD and other architecture documents, both system and software. <br/><br/>3.9. Process for Updating this SAD. Describe the process a reader should follow to report discrepancies, errors, inconsistencies, or omissions from this SAD. Include necessary contact information for submitting the report. If a form is required, either include a copy of the blank form that may be photocopied, or give a reference to an on-line electronic version. Describe how error reports are handled, and how and when a submitter will be notified of the issue’s disposition. <br/><br/>3.10. Architecture background <br/><br/>3.10.1. Problem Background. In this section, explain the constraints that provided the significant influence over the architecture. Structure the information in the following sections: <br/>3.10.2. System Overview. Describe the general function and purpose for the system or subsystem whose architecture is described in this SAD. <br/>3.10.3. Goals and Context. Describe the goals and major contextual factors for the software architecture. Include a description of the role software architecture plays in the life cycle, relevant acquisition factors, the impact of the LSI model, the effects of incremental development, and the relationship to system engineering results and artifacts. <br/>3.10.4. Significant Driving Requirements. Describe behavioral and quality attribute requirements (original or derived) that shaped the software architecture. Include any scenarios that express driving behavioral and quality attribute goals, such as those crafted during a software architecture evaluation. <br/><br/>3.11. Solution Background. In this section, provide a description of why the architecture is the way that it is, and a convincing argument that the architecture is the right one to satisfy the functional and quality attribute goals levied upon it. Structure the information in the following sections: <br/>3.11.1. Architectural Approaches. Provide a rationale for the major design decisions embodied by the software architecture. Describe any design approaches applied to the software architecture, including the use of architectural styles or design patterns, when the scope of those approaches transcends any single architectural view. Provide a rationale for the selection of those approaches, and why they were chosen over other approaches that were seriously considered but ultimately rejected. Describe any relevant COTS/GOTS issues, including any associated trade spaces, <br/>3.11.2. Analysis Results. Describe the results of any quantitative or qualitative analyses that have been performed that provide evidence that the software architecture is fit for purpose. If an architecture evaluation has been performed include the analysis sections of its final report. Refer to the results of any other relevant trade studies, quantitative modeling, or other analysis results. <br/>3.11.3. Requirements Coverage. Describe the requirements (original or derived) addressed by the software architecture. Include those requirements or constraints that are derived from higher-level SADs. <br/>3.11.4. Summary of Changes in Current Version. For versions of the SAD after the original release, summarize the actions, decisions, decision drivers, analysis and trade studies results that became decision drivers, requirements changes that became decision drivers, and how these decisions have caused the architecture to evolve or change. <br/>3.12. Product Line Reuse Considerations. When a product line is being developed, this section details how the software covered by this SAD is planned or expected to be reused in order to support the product line vision. In particular, this section includes a complete list of the variations that are planned to be produced and supported. "Variation" refers to a variant of the software produced through the use of pre-planned variation mechanisms made available in the software architecture. It may refer to a variant of one of the modules identified in this SAD, or a collection of modules, or the entire system or subsystem covered by this SAD. For each variation, the section identifies the increment(s) of the software build in which (a) the variation will be available; and (b) the variation will be used. Finally, this section describes any additional potential that exists to reuse one or more of the modules or their identified variations, even if this reuse is not currently planned for any increment. <br/><br/>3.13. Views. Describe each view using the outline below. The SAD shall contain one view for each viewpoint listed in Section 3.6. <br/>3.13.i Name and View description. Describe the purpose and contents of the view. Refer to the viewpoint description in Section 3.6 to which this view conforms. <br/>a. View packet overview. Show the set of view packets in this view, and provide rationale that explains why the set is complete and non-duplicative. <br/>b. Architecture background. Provide any architecture background (including significant driving requirements, design approaches, patterns, analysis results, and requirements coverage) that applies to this view. <br/>c. Variability mechanisms. Describe any architectural variability mechanisms (e.g., adaptation data, compile-time parameters, variable replication, and so forth) described by this view, including a description of how and when those mechanisms may be exercised and any constraints on their use. <br/>d. View packets. For each view packet in the view, describe it using the following outline: <br/>3.13.i.j View packet # j <br/>a. Primary presentation. Present the elements and the relations among them that populate this view packet, using an appropriate language, languages, notation, or tool-based representation. <br/>b. Element catalog <br/>1. Elements. Describe each element shown in the primary presentation, along with the values of its relevant properties, which are described in the viewpoint to which this view conforms. <br/>2. Relations. Describe any additional relations among elements shown in the primary presentation, or specializations or restrictions on the relations. <br/>3. Interfaces. Specify the software interfaces to any elements shown in the primary presentation that must be visible to other elements. <br/>4. Behavior. Specify any significant behavior of elements or groups of interacting elements shown in the primary presentation. <br/>5. Constraints. List any constraints on elements or relations not otherwise described. <br/>6. Context diagram. Provide a context diagram showing the context of the part of the system represented by this view packet. Designate the view packet’s scope with a distinguished symbol, and show interactions with external entities in the vocabulary of the view. <br/>7. Variability mechanisms. Describe any variabilities that are available in the portion of the system shown in the view packet, along with how and when those mechanisms may be exercise. <br/>8. Architecture background. Provide rationale for any significant design decisions whose scope is limited to this view packet. <br/>9. Related view packets. Provide section references for related view packets, including the parent, children, and siblings of this view packet. Related view packets may be in the same view or in different views. <br/><br/>3.14. Relations among views <br/>3.15. General relations among views. Describe the general relationship among the views chosen to represent the architecture. Discuss consistency among those views, and identify any known inconsistencies. <br/><br/>3.16. View-to-view relations. For each set of views related to each other, show how the elements in one view are related to elements in another. <br/><br/>3.17. Referenced materials. Provide citations for each reference document, giving enough information so that a reader of the SAD could be reasonably expected to locate the document. <br/><br/>3.18. Directory. Provide an index of all element names, relation names, and property names. For each entry, identify where in the SAD it was defined, and each place it was used. <br/>3.18.1. Index. Provide an index of all element names, relation names, and property names. For each entry, identify where in the SAD it was defined, and each place it was used. <br/>3.18.2. Glossary. Provide a list of definitions of special terms used in the SAD. If terms are used in this SAD that are also used in a parent SAD and the definition is different, explain why. <br/>3.18.3. Acronym list. Provide a definition of the acronyms used in the SAD. <br/><br/>3.19. Appendixes. Appendixes may be used to provide information published separately for convenience in document maintenance (e.g., charts, classified data). As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. <br/><br/>End of DI-SESS-82043 <br/>