1. Purpose

The purpose of this document is to recommend the kinds of content that should appear in a software architecture description for NASA projects. Although the examples used in this topic are mostly drawn from flight software, the recommendations apply equally to ground and other types of less critical software. These recommendations are intended to promote understanding of software architecture among stakeholders, to enable effective architecture reviews, and to facilitate future reuse. These recommendations are informal in the sense that they provide a number of details beyond NASA's top level requirements associated with software architecture and design preparation (e.g., SWE-056, SWE-057, SWE-058, SWE-059, and SWE-111.)

In preparing an architecture description, one must decide how much detail is appropriate. As Garlan and Lattanze point out, "architecture is design, but not all design is architectural," ¹⁷¹ so what is "architectural"? According to IEEE Standard 1471-2000, architecture is defined as "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution" ²¹⁰. According to Bass, Clements, and Kazman, "An architecture is a description of system structures, of which there are several (module decomposition, process, deployment, layered, etc.). Architecture is the first artifact that can be analyzed to determine how well its quality attributes are being achieved, and it also serves as the manifestation of the earliest design decisions, and is a re-usable abstraction that can be transferred to new systems." ²³⁹

It is important to note that the description of a software architecture is not the same as the architecture itself. A system can have great software architecture with a weak description, or weak software architecture with a great description. The purpose of this document is to help architects make the architecture description informative and complete so that it provides a good basis for understanding and assessing the architecture.

Documenting Software Architectures: Views and Beyond ²⁹⁵--- is an example of an excellent reference that provides good insight into the effective use of views. This document deliberately uses the phrase "architecture description" rather than "architecture description document" (ADD) to avoid the implication that an architecture description must exist as a conventional n-page paper document. Architecture description languages and modeling tools can, in principle, provide "live" architecture descriptions that can be examined in real time from multiple viewpoints.

2. Structure of this Topic

This section of the Software Engineering Handbook is organized simply as a list of recommended contents, with a rationale for each recommendation. This discussion does not recommend any particular outline for software architecture descriptions, but does offer three examples in section 5. Example Outlines. The only suggestion with respect to outline is that if a reader is interested in a specific topic, such as "architectural drivers", it will be easy to scan the table of contents and find where that is addressed.

3. Recommended Contents

3.1 Architecture Terminology

Where appropriate, architects are encouraged to use terminology from international standard ISO/IEC/IEEE 42010, Systems and software engineering — Architecture description ²¹⁰, for the obvious reason that the terminology is well-defined in a widely used international standard. 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.

3.2 Mission Overview

As the preceding figure shows, 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.

3.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.

Example:

3.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.

Example drivers:

• 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.

3.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.

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.

3.6 Stakeholders and Concerns

Every system has many stakeholders. Among these are: customer, owner, user, operator, architect, systems engineer, designer, developer, tester, installer, maintainer, vendor, and subcontractor. A software architecture description identifies major stakeholders, lists their software-related concerns (sometimes called "care-abouts"), and addresses those concerns through appropriate views. Failure to identify all the concerns can lead to unplanned events, rework, and schedule delay.

Examples:

3.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.

Examples:

• 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.

3.8 Measures of Performance

NPR 7123.1A, 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.

3.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.

Examples:

• 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.

3.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 typically describes the prototype and its results, as an objective comparison between the old way and new way. See 3.14 Prototypes.

Examples:

• 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))?

3.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 UML (Unified Modeling Language) , OMG (Object Management Group), SysML (Systems Modelling Language), and AADL (Architecture Analysis & Design Language), but architecture descriptions need not be restricted to such diagrams.

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 3.14 Architecture Frameworks (Views and Viewpoints) for additional ideas.

3.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.

3.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 DoDAF (Department of Defense Architecture Framework), MoDAF (British Ministry of Defence Architecture Framework), TOGAF (The Open Group Architecture Forum), RASDS (Reference Architecture for Space Data Systems), Krutchen 4+1, RM-OPD (Reference Model of Open Distributed Processing), 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.

Example:

The Department of Defense Architecture Framework, 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.

3.14 Prototypes

Whenever an architecture contains an idea that's new, or at least novel within the community, it's natural for some stakeholders to be concerned about risk, whether technology risk, verification risk, schedule risk, or operational risk. An effective way to address such concerns is to build and demonstrate an executable prototype.

Example:

In the Mars Pathfinder mission one engineer advocated a new idea of prioritized telemetry packets, in contrast to conventional channelized telemetry. The idea was not well understood by some stakeholders and was resisted until that engineer built a simple working prototype. The prototype illustrated how the idea worked in a live demo, and allowed observers to see how it behaved in different scenarios. Suddenly the light bulb went on, and the idea was accepted enthusiastically. The moral of this story is that a prototype can be an essential part of an architecture description, in some cases. Also see 3.10 Architectural Alternatives (Trade Studies).

3.15 Heritage Analysis

Most software built for today's missions involve significant "heritage" or "legacy" from an earlier mission, whether in architecture, design, or code. 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. 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.

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.

3.16 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. In essence, this is the flip side of Heritage Analysis; if Ariane 4 had documented its force limitation, Ariane 5 Flight 501 might have avoided disaster.

3.17 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. 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.

3.18 Fault Management

Due to its complexity, fault management has often been a source of problems in the integration and testing phase of flight systems. Because of this fault management deserves to 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, its behavior in the face of concurrent and/or nearly simultaneous faults and responses, and it's ability to support diagnosis, whether automated or human-in-the-loop. For more information, see the Fault Management Community of Practice on NASA Engineering Network (NEN) ²⁶⁰.

3.19 Non-Concerns

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 3.15 Heritage Analysis.)

3.20 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.

4. Common Weaknesses

This section lists common weaknesses seen in architecture descriptions.

4.1 Ambiguous Context Diagram

Most architecture descriptions provide a top-level diagram that aims to provide readers with "the big picture," and while such a diagram is always useful, it is sometimes unclear about the boundaries of the system being described.

4.2 Driving Requirements Missing

Every system has driving requirements, but when they are not clearly identified, readers have to infer what they are from other statements.

4.3 Architectural Decisions and Rationale Not Identified

The architecture is presented as a fait accompli, a fact, with no mention of the decisions that were made and their rationale.

4.4 Inappropriate Detail

Avoid description details that are inappropriate to the system, as defined in the context diagram. Such details might be about entities outside of the system, or might be details about subsystem internals that, while interesting, are not relevant to the system's architecture.

4.5 Unequal Coverage of Software Functionality

Setting aside non-concerns, the document doesn't give equal coverage to its subsystems.

4.6 Too Lengthy

Some architecture descriptions are so huge (hundreds of pages) that it's hard to see the essential architectural concepts amidst all the details. A system may be big, but the architectural concepts governing usually can be described more succinctly.

4.7 Important Information Buried

Anything that strongly influences architectural decisions is to be clearly identified up front, whether as a driving requirement or constraint or concern of an influential stakeholder. It's annoying to readers when any such material is buried in a subsection and has to be "discovered." One document, for example, had a statement in a fifth-level subsection about how their program office regarded a particular approach as crucial to success.

4.8 Diagram Lacks Legend

Diagrams that lack legends can be confusing to and/or misinterpreted by readers. Often, authors erroneously assume that the meanings of their boxes and lines are obvious, or that color distinctions and solid-versus-dashed lines are obvious. Diagrams that adhere to a standard such as UML or SysML or AADL do not need a legend on each diagram, but it is very useful to provide a notation summary as a reminder for reviewers who are less familiar with the standard.

5. Example Outlines

Although the purpose of this document is to recommend content in architecture descriptions, some readers have asked for an example outline. Accordingly, this section shows three outlines from different sources. It is not our intent to endorse these outlines, but rather to show some thoughtful examples.

5.1 Example Outline (SEI Template)

The outline below is based on the Software Engineering Institute's (SEI) "Views and Beyond" method for documenting software architectures, as described in Clements, et al. ²⁹⁵. The Software Engineering Institute's architecture web site provides a template, available as a free download ²⁹⁶, that describes in detail what each section typically contains. Even if you plan to use a different outline, the template is worth reading.

1   Documentation Road map
1.1    Document Management and Configuration Control Information
1.2    Purpose and Scope of the SAD
1.3    How the SAD is Organized
1.4    Stakeholder Representation
1.5    Viewpoint Definitions
1.5.1    <Insert name of viewpoint> Viewpoint Definition
1.5.1.1    Abstract
1.5.1.2    Stakeholders and Their Concerns Addressed
1.5.1.3    Elements, Relations, Properties, and Constraints
1.5.1.4    Language(s) to Model/Represent Conforming Views
1.5.1.5    Applicable Evaluation/Analysis Techniques and Consistency/Completeness Criteria
1.5.1.6    Viewpoint Source
1.6    How a View is Documented
1.7    Relationship to Other SADs
1.8    Process of Updating this SAD
2    Architecture Background
2.1    Problem Background
2.1.1    System Overview
2.1.2    Goals and Context
2.1.3    Significant Driving Requirements
2.2    Solution Background
2.2.1    Architectural Approaches
2.2.2    Analysis Results
2.2.3    Requirements Coverage
2.2.4    Summary of Background Changes Reflected in Current Version
2.3    Product Line Reuse Considerations
3    Views
3.1    <Insert View Name> View
3.1.1    View Description
3.1.2    View Packet Overview
3.1.3    Architecture Background
3.1.4    Variability Mechanisms
3.1.5    View Packets
3.1.5.1    View packet # j
3.1.5.1.1    Primary Presentation
3.1.5.1.2    Element Catalog
3.1.5.1.3    Context Diagram
3.1.5.1.4    Variability Mechanisms
3.1.5.1.5    Architecture Background
3.1.5.1.6    Related View Packets
4    Relations Among Views
4.1    General Relations Among Views
4.2    View-to-View Relations
5    Referenced Materials
6    Directory
6.1    Index
6.2    Glossary
6.3    Acronym List
7    Sample Figures & Tables

5.2 Example Outline: TestGen

Students in a software architecture class taught by Prof. David Garlan (Carnegie Mellon University) prepared the architecture description document whose outline is shown below. The document describes "TestGen," a tool to help a test engineer create test suites conforming to ISO/IEC 9646-3: 1998 regarding open systems in information technology ⁴⁵⁵.

1 Introduction

    1.1 TestGen System
    1.2 Business Context

2 Architectural Drivers
    2.1 Functional Requirements
    2.2 Constraints
    2.3 Quality Attributes

3 Architectural Decisions
    3.1 To Use the Traditional Structure of a Compiler
    3.2 To include all BNF Grammar in the Parser
...
    3.7 To Use a Visitor Pattern
    3.8 To Divide the Generation Part and Formatting Part

4 Component & Connector Architectural View
    4.1 Component & Connector viewtype and its style(s)
    4.2 C & C View: Data-shared Style and Call-return Style

5 Module Architectural View
    5.1 Module View-type and its style(s)
    5.2 Module View: Decomposition Style

6 Allocation Architectural View
    6.1 Allocation Viewtype and its Style(s)
    6.2 Allocation View: Implementation Style

7 Mapping Between Architectural Views

8 Architectural Alternatives
    8.1 Code Generation: Static vs. Dynamic
    8.2 C Code Formatting: COTS formatter vs. internal formatter
    8.3 Rule Description: Translation Rule File vs. Rule Engine

9 Architectural Approach Analysis
    9.1 Scenario 1: To generate C code understandable for a test engineer
    9.2 Scenario 2: To find a reason of failure for a test engineer
    9.3 Scenario 6: To include additional functions
    9.4 Tradeoff Summary

10 Future Extension

11 ATAM Process Evaluation

12 Appendix
    12.1 Glossary
    12.2 References
    12.3 Quality Scenarios
    12.4 Acme Textual Description
    12.5 FSP Source

5.3 Example Outline: SMAP

The Soil Moisture Active Passive (SMAP ) mission is an Earth-orbiting science mission with the objective of providing three years' of measurements of soil moisture and soil freeze/thaw state over the entire globe. The outline shown below was used in the SMAP architecture description document, authored by Alex Murray (JPL), which was formally reviewed by the NASA Software Architecture Review Board ³²³.

6. Resources

6.1 Tools

7. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

NASA Study of Flight Software Complexity: Lesson Learned 2050.  "Flight software development problems led NASA to study the factors that have led to the accelerating growth in flight software size and complexity. The March 2009 report on the NASA Study on Flight Software Complexity contains recommendations in the areas of systems engineering, software architecture, testing, and project management." ⁵⁷¹