4. Recommended Contents
The Software Architecture Review Board (SARB) has identified several aspects of software architecture description of particular importance in flight software for NASA’s space missions. Although these same aspects can be found in the SEI template for a software architecture document , they are not necessarily given the same prominence due to their location within the SEI template’s five levels of headings. The purpose of this guidance, then, is draw special attention to specific aspects of architecture description that the SARB wants to see explicitly addressed in NASA architecture description documents.
4.1 Architecture Terminology
Several sections of the SEI template make it clear that software architects are expected to follow the terminology defined in ANSI/IEEE-1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems . However, where appropriate, architects are encouraged to use terminology from the newer international standard ISO/IEC/IEEE 42010, Systems and software engineering — Architecture description . Important terms include system, environment, stakeholder, concern, view, viewpoint, and rationale. The figure below shows a partial concept map of how different terms relate to each other. For example, every system has one or more stakeholders, and every stakeholder has one or more concerns, and an architecture description selects viewpoints that are addressed to those concerns.
4.2 Mission Overview
A system is intended to fulfill a mission, and software is largely responsible for the behavior of the system (flight and ground systems). As such, it is helpful to readers to provide context for the architectural drivers that follow. Most readers won't be scientists, and external reviewers might come from outside of the aerospace industry, so it's not necessary to go deep into the science objectives. However, it's very helpful to highlight aspects of the mission that give rise to the driving requirements. When using the SEI template, this overview is captured in Section 2.1 (Problem Background) and possibly Section 2.1.1 (System Overview).
4.3 Context Diagram, Context Description
An architecture description is about a system, and that system always exists in a larger context. Clements et al describe this very well:
- "A top-level context diagram (TLCD) establishes the scope for the system whose architecture is being documented, defining the boundaries around the system that shows what's in and what's out. A TLCD shows how the system under consideration interacts with the outside world. Entities in that outside world may be humans, other computer systems, or physical objects, such as sensors or controlled devices. A TLCD identifies sources of data to be processed by the system, destinations of data produced by the systems, and other systems with which it must interact."
A context diagram helps readers avoid confusion about what is in scope and what is not. Also, a context description allows the architect to describe the internal boundaries between the system and the software, and discuss the system architecture as well as the software architecture, and the degree to which the system in which the software resides is a part of the architecture description. When using the SEI template, context diagrams are called for in the View Packet subsection of Section 4.1.
4.4 Architectural Drivers
One of the most important aspects of architecture description is to identify the major architectural challenges. These challenges may appear in the form of functional requirements, quality attribute requirements (sometimes called non-functional requirements), critical resources, and constraints, and are identified as architectural drivers when they have a major influence on design. Explanation of architectural drivers is an opportunity to educate non-software stakeholders about software challenges.
When discussing requirements, it's useful to make a distinction between key requirements (important to the customer) and driving requirements (challenging to meet; will drive cost, schedule, or some other aspect of the system). Some requirements are both, but the distinction is important since the latter shape the architecture.
The SEI template calls for this information in Section 2.1 (Problem Background), which asks for an explanation of “the constraints that provided significant influence over the architecture”, and Section 2.1.3 (Significant Driving Requirements) which asks for “behavioral and quality attribute requirements (original or derived) that shaped the software architecture.”
- EDL (Entry, Descent, and Landing) requires completely autonomous control and exact timing of pyrotechnic events.
- Space Shuttle primary avionics system had to allow astronauts to make most critical decisions, including failover to the backup flight system.
- Fault tolerance design almost always impacts software architecture.
4.5 Critical Resources and Margins
Flight system software often must deal with resources that are severely limited. Such critical resources may include power or energy, nonvolatile storage, bus data rate or latency, uplink or downlink rate, and processor memory or speed. A critical resource is often what makes a requirement "driving". It's important to identify critical resources for the benefit of stakeholders who might not otherwise understand the difficulties that software must face and the tradeoffs to be made.
Critical resources usually have associated margins, and development organizations usually have required margins at each phase to accommodate unforeseen growth. An architecture description shows, for each critical resource, the current best estimate of usage along with the required margin for the current phase.
Curiously, the SEI template makes no mention of resource margins, but it may be that they have lumped that in with “constraints”. Constraints are required in Section 1.5.1 (Viewpoint Definition) and in the view and view packet subsections of Section 3.
Example Critical Resources:
- Non-volatile memory. The development team for Mars Exploration Rover (MER) had to do a lot of work to manage what was stored in a relatively small non-volatile memory.
- Power/energy. Lack of power and energy on MER required careful operational planning with overnight sleep periods and recharge periods.
4.6 Stakeholders and Concerns
Every system has many stakeholders. Among these are: customer, owner, operator, architect, systems engineer, designer, developer, tester, installer, maintainer, vendor, service provider (e.g., telecommunications), and subcontractor. Failure to identify all stakeholders and their concerns (i.e., “care abouts”) can lead to unplanned events, rework, and schedule delays.
Section 1.4 (Stakeholder Representation) of the SEI template addresses this important aspect, and it’s important to engage with the stakeholders, draw out their various concerns, and address those concerns through appropriate views in the architecture description.
Amount of risk due to new technology
Project Systems Engineer
Interactions between flight computer and payload
Want ability to run various tests starting from tester-defined starting states
Want telemetry data organized in ways that facilitate state determination
4.7 Quality Attribute Analysis
Quality attributes that are important in mission software often include availability, modifiability, performance, safety, security, testability, and usability. As Bass et al describe:
"Business considerations determine qualities that must be accommodated in a system's architecture. These qualities are over and above that of functionality ... Systems are frequently redesigned not because they are functionally deficient — the replacements are often functionally identical — but because they are difficult to maintain, port, or scale, or are to slow, or have been compromised by network hackers."
The quality attributes that have the greatest influence on one mission are not necessarily the same on other missions. An architecture description will say several things about quality attributes. For each quality attribute it will define what the attribute means and describe how the attribute will be measured, often in terms of a usage scenario. The attributes are often ranked in importance and difficulty, and the architecture description will explain how the architecture satisfactorily achieves each desired quality.
To help architects be precise about quality attribute claims, NASA’s Software Architecture Review Board generated a quality attribute table ( ) that lists fourteen key quality attributes, identifies different important aspects of each quality attribute and considers each aspect in terms of requirements, rationale, evidence, and tactics to achieve the aspect. This quality attribute table is intended to serve as a guide to software architects, software developers, and software architecture reviewers in the domain of mission-critical real-time embedded systems, such as space mission flight software.
Section 2.1.3 (Significant Driving Requirements) of the SEI template calls for a description of quality attribute requirements and quality attribute goals, but that treatment is limited to driving requirements. Section 2.2 (Solution Background) of the SEI template calls for “a convincing argument that the architecture is the right one to satisfy the behavioral and quality attribute goals levied on it.”
- Quality attribute: Availability/Failure Recovery.
- Scenario: "A user reports an issue with accessing mission data. The ground team determines that there has been a disk failure. The faulty disk is replaced and mission data restored from backup within 24 hours of the problem report."
- Quality attribute: Replicability.
- Description: When the Hubble Space Telescope upgraded a flight processor, the software had to be recoded in C, and its behavior had to replicate the previous software behavior — potentially with the same anomalies — so that operations would not be affected and not require new training.
4.8 Measures of Performance
NPR 7123.1, NASA Systems Engineering Processes and Requirements, recommends that projects establish Measures of Performance (MOPs), a selected set of which is extended to Technical Performance Measures (TPMs). MOPs are quantitative measures of the system's fitness to satisfy stakeholder expectations. TPMs have the additional characteristic of monitoring performance by comparing a TPM's actual value against a time or event-based model of expected values (which are usually derived from histories of previous projects). The architecture description identifies MOPs and TPMs (if any) that relate to the architecture and identify those elements or attributes of the architecture that address these MOPs and TPMs.
The SEI template makes passing reference to “performance characteristics” or even “measure”, but does not call for it for it in any section. However, it is possible that they use the term “behavior” as a more general term that encompasses performance. Perhaps the Behavior and Constraints subsections of Section 3.1.5 collectively address this issue.
- The system must be able to sustain a downlink data rate of 300 Kbps.
- The system must initiate execution of a real-time command within 1 second of receipt.
4.9 Architectural Decisions and Rationale
Architecting is a process of understanding the problem, evaluating possible solutions, and making decisions about design. A good approach to developing a software architecture does not present it as a fait accompli, a fact. An architecture description will identify the big decisions and substantiate them. Rationale is hugely important to those who come aboard a project later, and is hugely important to future architects who may consider reusing an architecture.
The SEI template calls for architecture rationale in two places: Section 2.2.1 (Architectural Approaches), and Section 3.i.5.j.5 (Architecture background).
- Architects for the Core Flight Executive (CFE) software framework decided to provide a publish/subscribe software bus and to clearly distinguish its application program interface (API) from possible implementations. It's important that an architecture description identifies and explains major decisions such as this, including limitations as well as benefits.
- One flight project designed a component-based software architecture in order to make software subsystems more testable and maintainable by virtue of architecturally-prescribed interfaces. The decision facilitated on-orbit FSW updates by reducing the amount of data to uplink.
4.10 Architectural Alternatives (Trade Studies)
While it’s good to state the big architectural decisions, it’s even better to describe what alternatives were considered. This may occur naturally in providing rationale, especially if a decision is the result of a careful trade study. Descriptions of alternatives don’t have to be elaborate; often, readers simply want to know what plausible alternatives were considered and why they were found to be less suitable.
Sometimes an alternative is so appealing—but so radical—that a prototype must be built and demonstrated in order to get serious consideration from stakeholders. In those cases the architectural description describes the prototype and its results, as an objective comparison between the old way and new way.
Trade studies and their results are called for in Section 2.2.1 (Architectural Approaches) and Section 2.2.2 (Analysis Results) of the SEI template.
- The choice between centralized and distributed processing often has wide-ranging effects on quality attributes, and is therefore often subject to a trade study.
- The Radiation Belt Storm Probe (RBSP) project conducted a flight software trade study to compare a software bus architecture (using cFE) to a more “traditional” architecture having tightly coupled inter-task communication.
- Some missions have conducted trade studies concerning the software-based portion of fault protection. Does fault protection go in the “main” processor, or does part of it reside in a separate, simpler processor (or even in a field programmable gate array (FPGA))?
4.11 Multiple Views
An architecture description must address the diverse concerns of its stakeholders. Certainly, an architecture description must address how the design satisfies functional requirements, but there are many other concerns such as cost, schedule, assembly, integration, verifiability, operability, and maintainability. Different concerns require different views of the architecture — views such as structure, behavior, deployment, and operation. The key is to create views that not only address stakeholder concerns but also clearly convey the ideas to the stakeholders. Some views can be well described in the diagrams of unified modeling language (UML), object management groups (OMG), systems modeling language (SysML), and architecture analysis & design language (AADL), but architecture descriptions need not be restricted to such diagrams.
The SEI template is inherently organized for multiple views in Section 3 (Views) and Section 4 (Relations Among Views).
Examples of useful views:
- Run-time: Components with Data Flows.
- Compile-time: module structure (source code tree), layers.
- Fault containment regions.
- Bus traffic shown in terms of average and peak message rate and data volume.
- Deployment: diagrams to document the deployment of software components onto the hardware and/or OS of the target system. This would include an indication of processes utilized, threading, and partitions (if applicable). It would cover process and thread creation and scheduling to document how the software will be deployed on the target system and meet any timing, availability, or other system requirements.
See 4.13 Architecture Frameworks (Views and Viewpoints) for additional ideas.
4.12 Diagrams and Legends
The purpose of every diagram is to visually convey important information with a minimum amount of associated explanation. To that end, a diagram will contain a legend that explains what the boxes and lines and other symbols mean. When standard diagrams are used, such as UML or SysML diagrams, it is still helpful to include a notation summary (perhaps as a reference page) for readers and reviewers who are not as familiar with the notations. Also, when a diagram contains acronyms, it’s helpful to include acronym definitions in the legend, even if they are repeated in the glossary.
The SEI template makes no mention of diagram legends.
4.13 Architecture Frameworks (Views and Viewpoints)
As noted earlier, an architecture description addresses numerous stakeholder concerns, and many architecture thought leaders have thought about how to organize their thoughts—and architecture descriptions—from different viewpoints. As a result, there are now many architecture frameworks for architects to draw upon, such as the Department of Defense Architecture Framework (DoDAF), The British Ministry of Defense Architecture Framework (MoDAF), The Open Group Architecture Framework (TOGAF), Reference Architecture for Space Data Systems (RASDS), Reference Model of Open Distributed Processing (RM-ODP), and Zachman , . Our purpose in mentioning architecture frameworks is not to recommend adherence to a particular framework but simply to point to them as aids in developing views and viewpoints that clearly communicate to stakeholders. In reality, most of this document’s recommendations can be mapped into existing viewpoints.
Krutchen’s “4+1” view model calls for a logical architecture (what the system provides in terms of services), a process architecture (a set of processes distributed across a set of hardware resources), a development architecture (software module organization on the software development environment), a physical architecture (different physical configurations for development, testing, and deployment), and scenarios (instances of use cases that show the four views working together seamlessly).
The DoDAF 2. 0 , organizes architecture descriptions into eight viewpoints named: Project, Capability, Operational, Services, Systems, Standards, Data and Information, and All, as shown in the following figure.
4.14 Heritage Analysis
Most software built for today's missions involve significant "heritage" or "legacy" from an earlier mission, whether in architecture, design, or code or reuse of product line software. Such inheritance can be a smart move for projects, but it is critical to understand the differences between the new mission and the earlier mission and the costs and risks of reuse.
The well-known story of Ariane 5 Flight 501 offers a cautionary tale. Ariane 5 reused code from Ariane 4 that contained a limitation on the forces it was designed to process, and the greater forces in Ariane 5 caused an arithmetic overflow that resulted in the loss of four spacecraft. The lesson here is that architects must carefully examine any heritage with respect to differences between prior usage and planned usage, and document that analysis in the architecture description. This can be especially challenging since designs are often shaped by unstated assumptions.
Fortunately, NASA’s Earth Science Data Systems Software Reuse Working Group has formalized such evaluations in a document “Reuse Readiness Levels (RRLs)” [Marshall 2010] .That document identifies nine topic areas to consider in evaluating a software asset for reuse:
- Documentation: Information that describes the software asset and how to use it.
- Extensibility: The ability of the asset to be grown beyond its current context.
- Intellectual Property: The legal rights for obtaining, using, modifying and distributing the asset.
- Modularity: The degree of segregation and containment of an asset or components of an asset.
- Packaging: The methodology and technology for assembling and encapsulating the components of a software asset.
- Portability: The independence of an asset from platform-specific technologies.
- Standards Compliance: The adherence of an asset to accepted technology definitions.
- Support: The amount and type of assistance available to users of the asset.
- Verification and Testing: The degree to which the functionality and applicability of the asset has been demonstrated.
Surprisingly, the SEI template makes no mention of “heritage software” or “legacy software”. Although the word “reuse” appears in the title of Section 2.3 (Product Line Reuse Considerations), that section is not about reusing existing software, but about making software reusable to support a product line version. The decision to reuse software should be documented in Section 2.2.1 (Architectural Approaches) and the analysis substantiating that decision should be documented in Section 2.2.2 (Analysis Results).
Some questions to address in a heritage analysis:
- If there is major re-use in flight software, to what extent is the avionics hardware being re-used?
- Are the same operations concepts being re-used?
- What is the organizational experience with re-use? Has it produced the claimed benefits in the past? Has re-use in the past required a re-use of people?
- What's different from what was done previously?
- Does the area of re-use make sense, given differences between the new mission and the old mission?
See SWE-027 for a broader discussion on heritage or reused software and additional items to consider.
4.15 Assumptions and Limitations
Architects recognize that the systems they are architecting might well provide heritage for a future project. As such, it is valuable to document any assumptions underlying an architecture and any inherent limitations. Admittedly, this can be difficult because many assumptions are unconsciously made based on mission specifics, resulting in hidden limitations of the system's suitability for future missions.
The SEI template makes passing reference to “assumptions” as externally visible properties, so the rather clear concept of “assumption” gets lost in the common meaning of “properties”. Some treatment of “assumptions” should appear in Section 2.2 (Solution Background) so that known assumptions will get passed along to future architects who need to extend the architecture or apply it in a new context.
Assumption: Disturbances that the attitude control system must correct for will not exceed 1.5 Newton.
4.16 Architectural Principles, Patterns, Invariants, and Rules
Although a system to be built may be large, its architecture can often be described compactly, and more readily understood, in terms of principles that shape the design and architectural patterns that are applied consistently. An architectural pattern, applied uniformly, greatly aids understanding by software designers, developers and reviewers.
While it is extremely useful to document an architecture in terms of principles and patterns, there's no guarantee that downstream designers and developers will consistently adhere to them, meaning that the built system may not possess all the characteristics promised by the architect. As such, it's often important to provide some means for checking adherence to the principles and patterns.
Section 2.2.1 (Architectural Approaches) of the SEI template includes the use of architectural styles or design patterns, and Section 3.1.3 includes patterns.
4.17 Fault Management
Fault management has often been a source of problems in the integration and testing phase of flight systems, so it should be given suitable attention in architecture descriptions. Fault management encompasses topics that often appear under a variety of names such as fault protection; failure modes and effects analysis (FMEA); fault detection, isolation, and recovery (FDIR); fault detection, diagnostics and response (FDDR ); fault detection, notification and response (FDNR), integrated vehicle health management (IVHM ); integrated systems health management (ISHM); caution & warning; and aborts. At a minimum, fault management is to be examined in terms of its interactions with the nominal control system and its behavior in the face of concurrent faults and responses. For more information, see the Fault Management Community of Practice on NASA Engineering Network (NEN) .
The SEI template makes passing mention of “fault handling” in a general paragraph on software architecture and, once again, lumps an important issue under “externally visible properties”. Architects should make sure that fault management is appropriately addressed (and emphasized) in views of behavior.
Systems often have some easy-to-meet requirements, and often build upon mature heritage designs and software. For example, consider a mission that has modest uplink and downlink data rates relative to the proven capabilities of a heritage design that they are reusing and adapting. In that context, downlink data handling might be considered a "non-concern." It is reasonable, and even desirable, to treat these areas of non-concern lightly in the architecture description. However, good practice indicates that such areas first be identified as non-concerns, with good explanations as to why they are non-concerns. (See 4.14 Heritage Analysis.)
Non-concerns can be addressed in Section 22.214.171.124 (Stakeholders and Their Concerns Addressed).
4.19 Glossary and Acronyms
Architecture descriptions will often be reviewed by people outside the project, or even by people outside NASA. These people won’t necessarily understand all the numerous technical terms and acronyms in use, so a glossary and list of acronyms can be very helpful to readers.