2021-03-11_nasa-hdbk-1005_baseline.pdf

APPROVED FOR PUBLIC RELEASE—DISTRIBUTION IS UNLIMITED

NOT MEASUREMENT SENSITIVE

NASA TECHNICAL HANDBOOK

NASA-HDBK-1005

Office of the NASA Chief Engineer Approved: 2021-03-11

NASA SPACE MISSION ARCHITECTURE FRAMEWORK (SMAF)

HANDBOOK FOR UNCREWED SPACE MISSIONS

DOCUMENT HISTORY LOG

Status Document

Revision

Change

Number

Approval Date Description

Baseline 2021-03-11 Initial Release

FOREWORD

This NASA Technical Handbook is published by the National Aeronautics and Space

Administration (NASA) as a guidance document to provide engineering information; lessons learned; possible options to address technical issues; classification of similar items, materials, or processes; interpretative direction and techniques; and any other type of guidance information that may help the Government or its contractors in the design, construction, selection, management, support, or operation of systems, products, processes, or services.

This NASA Technical Handbook is approved for use by NASA Headquarters and NASA

Centers and Facilities. It may also apply to the Jet Propulsion Laboratory (a Federally Funded

Research and Development Center [FFRDC]), other contractors, recipients of grants and cooperative agreements, and parties to other agreements only to the extent specified or referenced in applicable contracts, grants, or agreements.

This NASA Technical Handbook establishes an Uncrewed Mission Architecture Framework intended to increase the value of the scientific investigations; improve effectiveness of end-to-end mission development, including leveraging digital engineering techniques; enhance institutional capability management; and improve collaborative application of digital models and products across NASA's science portfolio.

Requests for information should be submitted via “Feedback” at https://standards.nasa.gov.

Requests for changes to this NASA Technical Handbook should be submitted via MSFC Form

4657, Change Request for a NASA Engineering Standard.

Original Signed By Adam West for 3/11/2021

Ralph R. Roe, Jr. Approval Date

NASA Chief Engineer

TABLE OF CONTENTS

SECTION PAGE

DOCUMENT HISTORY LOG

FOREWORD

TABLE OF CONTENTS

LIST OF APPENDICES

LIST OF FIGURES

LIST OF TABLES

1. SCOPE

1.1 Purpose

1.2 Applicability

2. APPLICABLE DOCUMENTS

2.1 General

2.2 Government Documents

2.3 Non-Government Documents

2.4 Order of Precedence

3. ACRONYMS, ABBREVIATIONS, SYMBOLS, AND DEFINITIONS

4. DIGITAL ENGINEERING ENVIRONMENT ENABLING AN

ARCHITECTURE FRAMEWORK FOR UNCREWED SPACE

MISSIONS

4.1 General Principles of Architecture Framework Application

4.2 Applying an Architecture Framework in a Project

4.3 The Role of Mission Architecture in a Project Life Cycle

4.4 Overview of the Space Mission Architecture Framework (SMAF)

4.4.1 Science Viewpoint

4.4.2 Engineering Viewpoint

4.4.3 Project Implementation Viewpoint

4.4.4 Mission Operations Viewpoint

4.4.5 Enterprise/Mission Concept Viewpoint

TABLE OF CONTENTS (Continued)

LIST OF APPENDICES

APPENDIX PAGE

A Introduction and Rationale for the Architecture Framework for Uncrewed

Space Missions

B Guidance for Creating SMAF Products

C Key Documents Associated with the Space Mission Architecture Framework

(SMAF)

D Models Used with Space Mission Architecture Framework (SMAF)

Products

E Space Mission Architecture Framework (SMAF) Viewpoints Mapped to

Project Review Criteria

F References

G Acronyms, Abbreviations, Symbols, and Definitions

TABLE OF CONTENTS (Continued)

LIST OF FIGURES

FIGURE PAGE

1 Content Areas

2 SMAF Content in the Context of a Project

3 Context Diagram of the Science View, Including View Products

4 Context Diagram of the Technical Solution View, Including Products

5 Context Diagram for the Product Realization View, Including Products

6 Context Diagram of the Project Implementation View, Including Products

7 Context Diagram for the Mission Operations View, Including Products

8 Context Diagram for the Enterprise View, Including Products

9 Overall Crosscutting Categories of Stakeholder Concerns

10 Flowdown and Traceability of Needs, Goals, and Objectives

11 SMAF Scope Diagram

12 Summary of SMAF View Content

13 Summary of Mission Architecture Framework Content Exchanged by

Viewpoints

14 Mission System Decomposition

15 Context Diagram for the Science View

16 Context Diagram for the Technical Solution View

17 Context Diagram for the Product Realization View

18 Context Diagram for the Project Implementation View

19 Context Diagram for the Mission Operations View

20 Context Diagram for the Enterprise View

LIST OF TABLES

TABLE PAGE

1 SMAF Stakeholders, Participants, Viewpoints, Views, and View Products

2 Participant Responsibilities for SMAF View

3 SMAF Taxonomies for Systems, Requirements, and Organizations

4 MCR Criteria

5 SRR Criteria

6 MDR/SDR Criteria

7 PDR Criteria

8 CDR Criteria

NASA SPACE MISSION ARCHITECTURE FRAMEWORK (SMAF)

HANDBOOK FOR UNCREWED SPACE MISSIONS

1. SCOPE

1.1 Purpose

This NASA Technical Handbook provides guidance for establishing a mission architecture as part of an acquisition framework for a NASA uncrewed space mission. Note that in this context, acquisition refers to a larger context than the procurement; rather, it refers to the acquisition of a capability. Acquisition of such a capability encapsulates the conception of an idea, the development of a Mission to realize that idea, and the management of the design, build, integration, test, and operation of that Mission. The framework is applied to a specific project using an appropriate methodology. This NASA Technical Handbook is focused on project formulation and execution in the context of NASA’s operating model, as defined in NASA

Policy Directive (NPD) 1000.3, The NASA Organization. In the context of this NASA Technical

Handbook, a project is typically sponsored by a NASA program within the NASA Headquarters

Science, Space Technology, or Human Exploration and Operations Mission Directorates (SMD, STMD, or HEOMD) and represents a specific investment having defined goals, objectives, requirements, and life-cycle cost, as well as a timeframe with a beginning, and an end. This

NASA Technical Handbook implements relevant NASA policies, processes, and standards as defined in NASA Procedural Requirements (NPR) 7120.5, NASA Space Flight Program and

Project Management Requirements; NPR 7123.1, NASA Systems Engineering Processes and

Requirements; NASA/SP-6105, Revision 2, NASA Systems Engineering Handbook; and other governing documents. Specifically, Systems Engineering (SE) activities are guided by the SE

Engine in NASA/SP-6105, Revision 2, Section 2.1.

It is also noted that a key objective of this version of the NASA Technical Handbook is to create an initial starting point for a continuing and evolving discussion across NASA for embracing

System Architecture Development in a consistent manner. This dialogue will help NASA evolve to more interoperable digital work processes. It is expected that this NASA Technical Handbook represents a starting point that will help bring various Center cultures to the discussion of

Architecture, and it is expected to evolve, consistent with the dialogue.

1.2 Applicability

This NASA Technical Handbook is applicable to uncrewed space missions concerned with scientific discovery, including, but not limited to, an entire spacecraft or one or more scientific instruments. It provides guidance and support from which a project can draw to efficiently develop a mission architecture for a project and for the system described by that architecture that will successfully perform the mission. These projects formulate and implement uncrewed science missions that are planned, realized, and ultimately operated through the science, project management (PM), and engineering efforts of the responsible NASA Center for use primarily by system engineers and architects, scientific investigators, program managers, and support staff, who should be familiar with the NASA project life cycle, requirements, and model-based approaches for applying the SE process defined in NPR 7120.5, NPR 7123.1, NASA-STD-7009, Standard for Models and Simulations, and NASA-STD-1006, Space System Protection Standard.

Depending on mission objectives, the guidance in this NASA Technical Handbook can be applied with customization to replace the science content with equivalent technology-related goals, objectives, mission and system designs, and operations.

This NASA Technical Handbook is approved for use by NASA Headquarters and NASA

Centers and Facilities. It may also apply to the Jet Propulsion Laboratory (a Federally Funded

Research and Development Center [FFRDC]), other contractors, recipients of grants and cooperative agreements, and parties to other agreements only to the extent specified or referenced in their applicable contracts, grants, or agreements.

This NASA Technical Handbook, or portions thereof, may be referenced in contract, program, and other Agency documents for guidance.

2. APPLICABLE DOCUMENTS

2.1 General

References are provided in Appendix F.

2.2 Government Documents

None.

2.3 Non-Government Documents

None.

2.4 Order of Precedence

2.4.1 The guidance established in this NASA Technical Handbook does not supersede or waive existing guidance found in other Agency documentation.

2.4.2 Conflicts between this NASA Technical Handbook and other documents are to be resolved by the delegated Technical Authority.

3. ACRONYMS, ABBREVIATIONS, AND DEFINITIONS

See Appendix G.

4. DIGITAL ENGINEERING ENVIRONMENT ENABLING AN

ARCHITECTURE FRAMEWORK FOR UNCREWED SPACE

MISSIONS

4.1 General Principles of Architecture Framework Application

As uncrewed space missions get more complex and involve more partners, a greater need exists for working collaboratively. It is essential that information be expressed in a formal manner that supports more rigorous integration and analysis, and then to capture and manage the information in a form consistent with automation in all aspects of its use. This approach is widely referred to as digital engineering and implemented in a controlled environment that provides the necessary tools and methods. A complete SE environment defines both an architecture framework and a methodology through which the framework is realized in a system. One barrier to working in this manner is the consistency with which systems are described internally and externally to an organization. This NASA Technical Handbook describes a broad application of the principles and methods of digital engineering, specifically Model-Based Engineering (MBE) as a way to manage complexity, enhance information management and communication, and make the many processes involved in a mission more efficient, repeatable, and rigorous. A central tenet of MBE is that a project should start with models and end with documents, rather than the reverse, to realize the payoffs in efficiency, quality, reduced rework, and cost and schedule savings that motivate the model-based approach.

The International Organization for Standardization (ISO) defines an Architecture as the fundamental concepts or properties of a complex entity in its environment embodied in its elements and relationships and in the principles of its design and evolution. When properly implemented, an SE process establishes a system architecture. (Refer to ISO/International

Electrotechnical Commission [IEC]/Institute of Electrical and Electronics Engineers [IEEE]

42010, Systems and Software Engineering – Architecture Description.) Similarly, ISO defines an

Architecture Framework as a common practice for creating, interpreting, analyzing, and using architecture descriptions within a particular domain of application or stakeholder community.

This NASA Technical Handbook defines an architecture framework specifically for the domain of uncrewed space missions within the context of the NASA stakeholder community that will help NASA to move toward digital engineering tools and methods. Appendix A provides a fuller explanation of the goals addressed by SMAF, especially in terms of improving quality and productivity in SE processes and of more consistently meeting stakeholder expectations and concerns. Architecture frameworks can be of value whether applied in the context of digital engineering or not.

This architecture framework employs a set of foundational concepts and terms that are widely accepted in the Systems Architecture community including:

a. Stakeholder: In general usage, a Stakeholder is an individual, group, or organization having a significant and recognized interest in a system or project. This NASA Technical

Handbook defines two roles that parties to a project can exercise: Stakeholder and Participant.

Stakeholders are parties who are external to a project organization and who have concerns for budget and other resources, policies and approved practices, science data and other mission outcomes, safety and environmental matters, and other aspects; they are also referred to as

External Stakeholders. Participants are individuals or organizations that belong to a Project Team and are responsible for satisfying stakeholder concerns; they may be considered to be Internal

Stakeholders. Some parties have responsibilities that cross project boundaries and therefore have elements of both Stakeholder and Participant roles, and some parties may change roles over the course of a project life cycle. This is further discussed in Appendix A.

b. Architecture: The fundamental concepts or properties of a system or other complex entity in its environment embodied in its elements, relationships, and principles of design and evolution (ISO/IEC/IEEE 42010); an architecture is expressed in an Architecture Description, which is commonly organized into Viewpoints and Views that capture structural, functional, and other aspects of the system or entity as well as the constraints that apply to its development and operation.

c. Viewpoint: A set of related concerns identified by one or more stakeholders. A

Viewpoint translates these concerns into the specification of one or more Views and thereby defines part of the content of an architecture description. A Viewpoint typically addresses stakeholder concerns that are common to multiple systems or projects and is therefore reusable whenever those concerns arise.

d. View: A View is composed of a set of products that may be models or other artifacts whose structure and content depend on the methodology employed in conjunction with the architecture framework. A View focuses on a particular area of an architecture and establishes truth for that area. A View also includes source materials relevant to the area with which it is concerned and may be created from a repository of source materials. The creation and maintenance of a View are the responsibility of one or more Participants.

e. View Product (or simply Product): An individual product within a View embodies specified content of an architecture description. The concepts, structure, format, content, analysis techniques, and other aspects of a product are defined by the architecture framework. Like

Viewpoints and Views, products are often reusable from project to project with tailoring to the specifics of a given project. In a model-based environment, many Products can be automatically generated, in whole or in part, from models.

4.2 Applying an Architecture Framework in a Project

The architecture framework should be instantiated in a specific project in accordance with the following general principles:

a. The foundation of the project should be a high-quality mission architecture that addresses the concerns of all stakeholders as defined in Appendix A. Following the structure and methods of this NASA Technical Handbook to create a full set of architecture viewpoints

(Viewpoints) helps ensure this is achieved for any given mission architecture. Furthermore, application of this NASA Technical Handbook across the NASA portfolio helps normalize mission architectures and facilitates compliance with applicable policies, directives, and standards.

b. Modern Program Management and Systems Engineering are model-based, in that models such as requirements tables, product breakdown structures, bills of materials, GANTT1 charts, performance models, and many others are used extensively to convey information.

Modeling approaches and supporting tools vary significantly across various stakeholder groups, both within and external to a program or project. While uses of modeling may vary, the information conveyed by models has to be consistent when shared across the boundaries of stakeholder groups. The various content areas shown in Figure 1, Content Areas, employ a corresponding variety of models, described in Appendix D, tailored to the specific needs of a project and designed to facilitate model interoperability and information exchanges internally and externally.

1 A Gantt chart is a type of bar chart that illustrates a project schedule, named after its inventor, Henry Gantt, who designed such a chart around the years 1910–1915.

Products are created at various points in the project life cycle and evolve across its phases. Most are created in basic form in early phases, then refined and fleshed out in detail as the project progresses, often including an approval and baselining process. Appendix B describes products in terms of their evolution to a mature form, with successive versions generally associated with various life-cycle phases and project reviews.

4.4 Overview of the Space Mission Architecture Framework (SMAF)

As described in section 4.1, this NASA Technical Handbook describes an architecture framework that aligns with standards and practices of the global SE community, especially

ISO/IEC/IEEE 42010, Systems and software engineering – Architecture description. Following these standards, a framework is organized into Viewpoints, Views, and Products that describe a complex entity such as a system in terms of the interests and concerns of various Stakeholders and Participants. Table 1 summarizes the SMAF structure, and the following sections summarize the Viewpoints and Views. Each product has a short identifier for easy reference. Appendix B gives details of the products that make up each View.

Table 1 captures several significant aspects of the architecture framework.

a. The overall structure of the SMAF has three tiers: Stakeholders and Participants as defined in Appendix A, Viewpoints as defined in section 4.1, and Views containing View

Products, also defined in section 4.1 of this NASA Technical Standard.

b. Appendix A distinguishes Stakeholders (“External Stakeholders”) and Participants

(“Internal Stakeholders”) who have recognized roles and concerns and who are, respectively, external and internal to a project organization. Table 1 identifies the primary organizations and individuals in these categories and maps them to Viewpoints, with each Viewpoint having a

Participant that is primarily responsible for creating and maintaining its products.

c. Architecture content can be conveniently characterized as chiefly associated with the earlier, Conceptual or Formulation stages of a project or with later, Realization or

Implementation stages. In many cases, a particular product is first created during an early stage and then refined with details as technical and programmatic decisions are made across a project’s life cycle. This distinction is indicated in Table 1 with color coding and in some cases further described in the Notes. For example, the Technical Solution and Product Realization Views under the Engineering Viewpoint are both the responsibility of the Engineering Team, with the first of these primarily conceptual in content and the second primarily concerned with system implementation.

d. The majority of the listed products represent well-known information entities from the NASA SE process, and many are also explicitly associated with entry and success criteria of various Life Cycle and Technical Reviews in accordance with NPR 7123.1, Appendix G.

e. Although not explicitly called out as a View in Table 1, requirements are essential and pervasive elements of a valid SE process and span the entire project life cycle from early concept definition through system development and mission operations. In particular, product

Soln-3 is a System Requirements Document holding the current requirements baseline; and other products deal with project scope, requirements verification and validation, allocation of requirements to design, and other aspects of requirements engineering.

Notes:

(1) This Product may take the form of an Announcement of Opportunity (AO) or other description of Project/Mission scope.

(2) The Concept Study Report (CSR) is created by the entire Project Team; for a two-step AO, it is the proposal submitted in competition for a mission and documents all aspects of the Mission Concept as assessed against stakeholder concerns and mission success criteria. It is held in the Enterprise View because it is primarily directed to a NASA Headquarters Mission Directorate.

(3) The architecture begins in the Conceptual/Formulation phase of the project life cycle and progressively becomes a Realization/Implementation product as detailed design is completed and physical detail is added to model elements.

(4) The Test Plan begins in the Conceptual/Formulation phase and becomes a Realization/Implementation product as detailed design and accompanying test procedures are defined.

(5) Operational Plans include launch and trajectory/orbit control along with mission activities and other aspects of flight dynamics.

(6) System and Product Specifications include successive system configurations associated with preliminary and final design, integration and test, transport and storage, and the operational system.

create functional definitions of the entities making up the system, describe the behaviors of the system and its constituents, define data and data flows, document internal and external interfaces, and identify constraints that impact the design space available to the project. It reflects the concerns of the Principal Investigator, the Engineering Team, and the Project Manager. Figure 4, Context Diagram of the Technical Solution View, Including Products, shows the context of the

Technical Solution View with a tabulation of included products.

c. Viewpoints. Views and Products promote consistency and reusability in project reviews and in science, engineering, and PM activities across the project life cycle and potentially among successive projects.

Appendix F lists references, and Appendix G defines terms and acronyms used in this NASA

Technical Handbook.

APPENDIX A

INTRODUCTION AND RATIONALE FOR THE

ARCHITECTURE FRAMEWORK

FOR UNCREWED SPACE MISSIONS

A.1 PURPOSE

This Appendix provides the goals, motivation, and rationale for a Space Mission Architecture

Framework (SMAF) targeted to NASA uncrewed space missions.

A.2 GENERAL

This Architecture Framework is intended to:

a. Increase the value of the scientific investigations through:

(1) Tighter coupling between science objectives and mission architecture based on enhanced insight into traceability of goals and objectives to requirements, design, and implementation.

(2) Improved understanding of the mission architecture as it evolves throughout the life cycle to enhance collaboration between the Science, Engineering, and PM teams involved in a project.

(3) Increased support for technical and programmatic decisions such as mission de-scope, extended mission options, and other operational trade-offs.

b. Improve effectiveness of end-to-end mission development, including leveraging model-based engineering techniques, specifically by:

(1) Providing more explicit guidance on content of the products used in Project Life

Cycle review product, described in NPR 7120.5, NPR 7123.1, NASA-STD-7009, NASA-STD-1006, and other directives, including materials such as front-end definition of expected functional behavior, simulation, and interfaces to improve mission software design, development, integration, verification and validation

(V&V), and maintenance, with special emphasis on the inclusion of relevant industry standards.

(2) Better aligning expectations between the Project Team (Science, Engineering, and

PM) and external reviewers, through clearer definition of the products used to communicate entrance and success criteria for project reviews.

(3) Enabling easier and more effective management of hardware and software reuse per the requirements of NPR 7150.2, NASA Software Engineering Requirements, through greater standardization of SE and PM products, processes, design patterns, test cases, documentation, and modeling; specifically:

A. Managing system integration (interfaces).

B. Managing integration of other models.

C. Facilitating capture and dissemination of lessons learned.

D. Improving management of technical readiness level (TRL) maturation and its impact on mission cost, schedule, performance, and risk.

c. Enhance institutional capability management by:

(1) Providing insight into the short-term, project-level needs for and utilization of the technical workforce, assets, tools, standards, and methods.

(2) Providing insight into the long-term, Center-level needs for and utilization of workforce, assets, tools, standards, and methods.

d. Improve collaborative application of digital models and products across the science portfolio by:

(1) Specifying standardized ways to define, request, offer, and exchange information between stakeholders across the full systems life cycle.

(2) Applying a standardized taxonomy for WPs and other artifacts.

By aligning with this structure, a project will realize the maximum benefits derived from proven methodologies, standardized materials and presentations, and increased confidence in the completeness and correctness of system formulation and implementation. Specifically, the

SMAF will:

a. Provide a vehicle for ensuring the completeness of a mission architecture;

b. Provide guidance on creating and documenting mission architecture content; and

c. Promote a standard approach for developing, presenting, and reviewing mission architectures.

A.3 INTRODUCTION

This NASA Technical Handbook and an accompanying repository of reference materials providing background information, procedures, and examples, along with technical and programmatic guidance for applying the SMAF to uncrewed space missions. Additional handbooks complete the description of the model-based SE approach with tailoring for various mission system categories and modeling methodologies. The SMAF identifies Stakeholder and

Participant concerns and correlates them across interdisciplinary perspectives (Viewpoints). The

SMAF is structured to align with NASA’s operating model and to identify and satisfy the expectations and concerns of mission stakeholders. Viewpoints represent the primary concerns and interests of the various organizations and stakeholders involved in a project. Viewpoints specify Views that contain products that capture the detailed information needed to define a mission architecture and to satisfy Stakeholder needs.

In the SMAF construct, a Space Mission Architecture is composed of:

a. Mission Science Goals and Objectives,

b. Mission System Architecture,

c. Project/Organizational Architecture,

d. An Enterprise Architecture (Resources Model), and

e. Natural and Organizational Environment of a Mission and Project.

The SMAF bridges existing gaps among the Science, Management, and Engineering communities involved in a mission, as well as those among Agency, Center, and project organizations. The SMAF also establishes a common and repeatable structure for project proposals to enhance their overall quality and simplify the task of evaluating competed proposals.

A.4 MEETING STAKEHOLDER NEEDS

The SMAF enables a uniform, consistent, and effective approach to creating, documenting, and presenting information about an uncrewed space mission architecture. It is predicated on a model-based approach. However, to facilitate its adoption and use in projects, the framework references existing documents, referred to as key documents and tabulated in Appendix C, as well as other artifacts that are familiar to NASA personnel. In the near term, these will continue to furnish the primary content of many project reviews and are used across the project life cycle to enable concept definition, technology development, design, fabrication, integration and test, launch, operations, and disposal of a mission system.

A.4.1 Primary Stakeholders

This section addresses the concerns of stakeholders who are directly and continually involved in a project. The primary parties to a project are of two kinds: External Stakeholders

(“Stakeholders”) who are outside the project organization and Internal Stakeholders

(“Participants”) who make up a project team. Additional stakeholders whose concerns occur at a higher level and whose involvement is less frequent include Congress, various Federal agencies, the academic community, the aerospace industry, and potential international and academic partners, as well as the general public through education and outreach. At some point in a project’s life cycle, any of these parties is likely to be concerned with any given area of architecture content. However, to achieve a logical and consistent SMAF structure, this NASA

Technical Handbook focuses on the primary concerns of specific stakeholders. Stakeholder concerns commonly involve mission/project scope, technical issues, safety and mission assurance, project management, and resources, as well as other concerns peculiar to an individual

Stakeholder. In some cases, these concerns can be seen as risks and addressed through the project risk management process. Figure 9, Overall Crosscutting Categories of Stakeholder

Concerns, summarizes this overall view of External and Internal Stakeholders and their concerns.

c. Ensuring that the instrument payload of each Observatory is functionally defined, technically mature, and capable of collecting the required data;

d. Ensuring that the spacecraft bus is defined, characterized, and technically mature to perform the mission and to accommodate and support the instrument payload;

e. Ensuring that all required onboard and ground science data processing, telemetry, archiving, and dissemination are defined and that required resources will be available when needed; and

f. Ensuring that appropriate plans and processes are defined so that the interested science community has timely access to data products, algorithms, archived data, and other content and that there is efficient interaction between the project science team and the larger science community so that the latter can input relevant information and request data to optimize the overall science return.

A.4.1.2 NASA Headquarters, Mission Directorate, and Center Director and Staff

Every NASA mission contributes to the agency mission "To reach for new heights and reveal the unknown so that what we do and learn will benefit all humankind." Accordingly, leadership at the Agency and Center levels has a vital interest. Depending on the Class and other characteristics of a mission, approval authority for project initiation and continuation at Key

Decision Points will be established at an appropriate level.

The Enterprise/Mission Concept Viewpoint deals with the following concerns:

a. Ensuring that projects are selected, approved, planned, funded, and implemented to effectively support a Mission Directorate program and the overall Center and Agency mission and science portfolio;

b. Ensuring that the maximum science return is obtained from a mission and disseminated to the appropriate scientific community;

c. Ensuring that an appropriate Safety and Mission Assurance program is implemented and documented for a mission;

d. Ensuring that current and planned Center resources (facilities, equipment, workforce, infrastructure, etc.) and technology development efforts can support the project over its life cycle and can use project outcomes to sustain resources for future projects;

e. Ensuring that all applicable Agency and Center policies, procedures, guidelines, standards, and other documentation are appropriately applied in a project; and

f. Ensuring that a project positively reflects credit on the Agency and Center from the perspective of other external stakeholders (e.g., Congress and the general public).

A.4.1.3 Center Engineering Community

Depending on the organization of the Center implementing a project and mission, one or more engineering and technology directorates have oversight of the technical aspects.

The Engineering Viewpoint deals with the following concerns:

a. Ensuring that required engineering standards and processes are in place, appropriately tailored and balanced against currently available technology and techniques to enable formulation and implementation of a successful mission;

b. Ensuring that Measures of Effectiveness (MoEs), Measures of Performance (MoPs), Technical Performance Measures (TPMs), and other metrics are identified and tracked;

c. Ensuring that necessary technical baselines are defined and managed for each project milestone;

d. Ensuring that a project has the necessary engineering resources to implement its mission;

e. Ensuring that the design for an uncrewed mission provides the necessary resources

(hardware and software) to perform the mission with the required level of autonomy;

f. Ensuring that the technical content of each project review satisfies review objectives and provides a sound basis for decisions about project continuation and required corrective actions; and

g. Ensuring that technical status and concerns are provided to the Center and Agency leadership and to other participating organizations.

A.4.1.4 Center Mission/Project Management Community

One or more Mission/Project Management directorates have oversight of the planning, project control, resource management, project life-cycle reviews, and other aspects of project implementation. The SMAF identifies two Viewpoints that capture the concerns of this

Stakeholder group.

The Project Implementation Viewpoint deals with the following concerns:

a. Ensuring that all applicable policies and processes are implemented, especially in accordance with NPR 7120.5 and Center supplementary requirements, and that they support successful mission/project formulation and implementation;

b. Ensuring that a project identifies issues, concerns, adverse events, and other matters of interest to Center and Agency leadership in a timely fashion and receives support for issue resolution;

c. Ensuring a project maintains a robust and continuing dialog with Stakeholders to ensure their expectations are understood and properly addressed;

d. Ensuring that a project involving collaboration across NASA Centers, other

Government agencies, international partners, and other external entities has in place adequate mechanisms for coordination of activities, issue resolution, organizational roles and responsibilities, and other aspects of effective partnership; and

e. Ensuring that a project identifies required facilities, equipment, staffing, and other resources in a timely fashion and that these are provided when needed.

The Mission Operations Viewpoint deals with the following concerns:

a. Ensuring that a project accomplishes all required planning, coordination, and preparation for launch, flight operations, and disposal of the mission system; and

b. Ensuring that a project has adequately defined a Mission Operations Center, Science

Operations Center, access to telemetry and communications networks, and other mission support facilities and services.

A.4.1.5 Chief Safety and Mission Assurance Officer (CSO)

The CSO is a special Stakeholder who exercises both External and Internal Stakeholder roles as the representative to a project of Center and Agency SMA organizations and as a member of the project team ensuring an adequate and effective SMA activity is performed. The SMAF does not define a separate Viewpoint for the specialized and project-specific concerns of the CSO, and these are accounted for under the Project Implementation Viewpoint.

CSO concerns include ensuring that:

a. The project implements an appropriate quality assurance program;

b. The project thoroughly identifies and implements a Risk Management Plan to identify, assess, mitigate, and track all major technical and programmatic risks commensurate with the project class (e.g., acceptable risk level in Class A vs. Class D);

c. The project thoroughly identifies hazards to personnel and equipment and implements a hazard management plan to assess, control, and track hazards;

d. The project applies consistent definitions and a safety and mission success taxonomy.

A.4.2 Participants

This section addresses the concerns of the “Internal Stakeholders” who constitute a Project Team and are responsible for implementing a mission and project that satisfy the needs and expectations of the Primary Stakeholders.

A.4.2.1 Principal Investigator (PI) and Science Team

As noted earlier, once the science content of a mission is defined and documented in a Science

Concept, the PI and team transition to a Participant role and work within the Project Team to complete the formulation and implementation of the mission. To satisfy the concerns of the

Science Community Stakeholder, the Science Team develops a Science View aimed at ensuring that:

a. Science needs, goals, and objectives of the mission are properly identified, analyzed, and documented in collaboration with the Systems Engineering Team, and captured in the requirements baseline for the mission;

b. The instrument payload of each Observatory is technically mature, fully characterized, calibrated, and capable of collecting the required data;

c. The spacecraft bus provides all required instrument accommodation;

d. All required onboard and ground science data processing telemetry, archiving, and dissemination are fully defined and supported by required resources;

e. Science data products are fully defined, adequate to meet the science goals of the mission, and governed by an appropriate Science Data Management Plan; and

f. Ground data systems are defined, developed, delivered, and verified to process mission science data prior to launch and operations.

A.4.2.2 Mission Systems Engineer (MSE), with Instrument Systems Engineer(s) (ISE), Discipline Engineering Team Leads, and Other Engineering Staff

The Engineering Team transforms the science needs, goals, and objectives of a mission into a mission system that can satisfy them within constraints of schedule and resources and with acceptable risk. Depending on the organizational structure of the Center implementing the mission, there may be an identified Assembly, Integration, and Test (AIT) Team which is responsible for these activities. The Engineering Team develops two Views that are specified by the Engineering Viewpoint.

The Technical Solution View is primarily focused on Mission Formulation during Phases A and

B of the NASA Project Life Cycle. Specific concerns addressed by this View include:

a. A high-quality SE process to translate the project’s science needs, goals, and objectives into a robust, reliable, affordable, supportable, and fully documented mission system design; the process is documented in a SEMP;

b. An assessment of mission architectural constraints and application of design patterns and other tools to identify and analyze design trade-offs and other detailed analysis to develop mission system architectures that will meet the technical requirements with acceptable cost, schedule, and risk;

c. A complete, consistent, balanced, verifiable, and feasible requirements baseline that accurately reflects mission goals and objectives while balancing cost, schedule, performance, and risk, including supporting plans for V&V;

d. Definition and management of the technical baselines for each project milestone;

e. Identification and tracking of TPMs and other metrics to assess design maturity and provide early warning of technical issues;

f. Application with appropriate tailoring of applicable standards and processes that are balanced against currently available technology and techniques;

g. Technical content of each project review that accurately reflects the current technical baseline and is prepared and presented to satisfy stakeholder expectations for entrance and success criteria, pass the review, and disposition resulting actions;

h. Integration of the activities of engineering discipline teams; and

i. Timely notification of technical status, concerns, actual or potential problems, and risk actions to the Project Management and Science Teams with recommended corrective actions to minimize their impacts.

The Product Realization View is focused primarily on Mission Implementation during Phases C and D of the NASA Project Life Cycle. Specific concerns addressed by this View include:

a. Design, fabrication, assembly, integration, and test of the mission system to satisfy mission requirements;

b. Continued integration of the activities of engineering discipline teams;

c. Analysis and management of mass, power, thermal, and other physical budgets to ensure adequate margins and maintain a balanced mission system design;

d. Integration of the mission system with its launch vehicle; and

e. Integration of the Flight Segment with the Ground Segment for the mission.

A.4.2.3 Project Manager (PM), with the Ground Segment Manager, Launch Manager, Observatory Manager, and PM Staff

The Project Management Team, which includes the overall Project Manager, managers for the

Ground and Launch Segments, and their staffs, is responsible for programmatic actions in accordance with NPR 7210.5 and NPR 7120.8 across the project life cycle. The Project

Implementation View is aimed at ensuring that:

a. Project planning, budget, schedule, and resources are current and accurate and that they support successful project execution;

b. All applicable Baselines and Project Control Plans of the Project Plan are similarly correct, current, and adequate;

c. The project appropriately tailors and implements all applicable policies, procedures, standards, and other documentation;

d. The Project Team properly prepares for program reviews, satisfies all entrance and success criteria, passes each review, and dispositions actions arising from each review;

e. All aspects of the project (science, engineering, launch services, ground support, logistics, etc.) are properly defined, planned, coordinated, and adequately resourced; and

f. Status and concerns are provided to higher organizational levels, including timely notification of required resources, actual or potential problems, and recommended corrective actions to minimize their impact.

A.4.2.4 Mission Operations Team

This specialized team is responsible for safe and effective operations from launch through orbital flight and ultimately disposal. The Mission Operations View is focused on Phases E and F of the project life cycle and is aimed at ensuring that:

a. The proposed mission concept of operations (CONOPS) identifies existing and future operational elements; defines operational interfaces; and envisions people, processes, and procedures that are compatible with existing infrastructure, practices, and operational doctrine;

b. All necessary operational plans, procedures, requirements, and budget projections are fully defined, validated, and understood prior to Pre-Launch Acceptance Review (PLAR), including all launch and post launch mission phases and associated activities;

c. The facilities, equipment, software, staffing, training, and other aspects of the Mission

Operations Center (MOC) are established and verified ready for launch and operations; and

d. Networking and telemetry for launch and on-orbit operations are available and verified to have the required operability for the mission, including connectivity among Flight

Dynamics, the Science Operations Center (SOC), and the MOC.

A.4.2.5 Chief Safety and Mission Assurance Officer (CSO)

As noted earlier, the CSO is both a Stakeholder who provides liaison between a project and the

Center and Agency SMA organizations and as a Participant who works within a Project Team to ensure SMA is properly defined and implemented. The Project Implementation View includes a

Safety and Mission Assurance Plan under the Project Plan, and the associated project management processes include Quality Assurance and other activities associated with SMA. The concerns of the CSO are identified in section A.4.1.5 of this NASA Technical Handbook.

A.4.2.6 Enterprise View

Although Agency and Center leadership are not part of a Project Team, this View contains the

Products that are required for effective interaction between a project and higher echelons of the

Center and Agency. The concerns of the Enterprise Stakeholder are identified in section A.4.1.2 of this NASA Technical Standard.

A.4.3 Requirements Flowdown and Traceability

An essential aspect of meeting Stakeholder needs involves ensuring that needs, goals, and objectives are rigorously and traceably flowed down from national and Agency levels to programs and then to the missions sponsored by a program, its associated projects, and systems.

A mission, project, and system are intimately related but distinct in their natures and purposes.

SMAF Viewpoints are impacted in important ways by the need to support this flowdown and traceability. The key terms are defined in Appendix G in this NASA Technical Handbook; and satisfied in a system implementation as documented in the Product Realization Viewpoint. This

Viewpoint also creates the technical content of a CSR for Center and Agency evaluation;

provides the starting point for Mission Operations planning; and furnishes cost, risk, schedule, resource needs, and other data to the Project Implementation Viewpoint.

c. The Product Realization Viewpoint transforms the functional architecture into a point design (physical architecture), accompanied by acquisition, fabrication, integration, test, and other aspects of achieving a system that meets science needs, goals, and objectives. It interacts intimately with the Technical Solution Viewpoint to resolve issues, define interfaces, establish feasible performance parameters, achieve acceptable risk levels, and, in general, optimize system design. It supports detailed Mission Operations planning in areas such as spacecraft commanding and housekeeping, fault management, design for reliability, detailed data and communications definitions, and many other operational specifics. It provides important technical content to a

CSR.

d. The Project Implementation Viewpoint is the focus of project execution and interacts closely with all the others. It maintains management plans, schedules, budgets, risk and configuration status, external coordination, and many other factors in planning, managing and controlling the project. Importantly, this Viewpoint provides current and projected resource needs to Center and Agency levels to ensure these will be available when needed by the project.

e. The Mission Operations Viewpoint is the basis for planning and executing the actual space mission, including launch vehicle integration, launch and orbit insertion, checkout and commissioning activities, trajectory/orbit control, conjunction assessment and avoidance, and ultimate disposal/decommissioning. It provides important inputs to requirements and design based on the practical considerations of safety, flight dynamics, environmental factors, and other considerations. It largely establishes the capabilities of the Mission and Science Operations

Centers (MOC/SOC).

f. The Enterprise/Mission Concept Viewpoint is concerned with ensuring that the project is properly harmonized with larger Center and Agency goals and strategic plans and that adequate communication and oversight provisions are in place. A mission and project typically begin with an AO that serves as a Scope Definition Document and establishes the policy and guidance for the formulation and implementation of the mission. It therefore interacts with all the other Viewpoints to provide direction and to receive and process status, issues, resource needs, and other information to ensure the mission/project is correctly defined and implemented to meet

Center and Agency objectives.

Figure 13, Summary of Mission Architecture Framework Content Exchanged by Viewpoints, is a

Viewpoint Interdependency Matrix that summarizes content exchanged among Viewpoints. At the top, Figure 13 also summarizes external inputs to the content of the various Viewpoints. In the matrix in Figure 13, the cell on the diagonal corresponding to the Viewpoint that is providing content traces to the right in the upper part of the matrix or to the left in the lower part to the cell in the column of the receiving Viewpoint. The top row of the matrix summarizes important external information sources, physical constraints, policy and legal requirements, and other influences bearing on a space mission architecture.

Figure 13—Summary of Mission Architecture Framework Content Exchanged by

Viewpoints (from the Source Viewpoint, read horizontally to the column of the receiving Viewpoint)

Example: Consider the flow of SMA guidance offered by a Mission Directorate through an AO.

This example assumes an SMA process is required for the mission. This guidance flows from the

- Laws of Physics

- Legacy Missions

- Partner

Capabilities

- Enabling

Technologies

- Tools & Methods

- Community Stds

- Laws/Regulations

- Available

Products

- Environment

- Laws/Regulations

- Agency and

Program

Coordination

- Laws of Flight

Dynamics

- Conjuncting

Objects

- National Policies/

Priorities/ Goals/

Budgets/

Science

Viewpoint

- Science Validation of Technical

Solution

- System Science

Constraints

- Legacy Science

Data

- Legacy Payload

Data

- Payload

Buy/Build/Reuse

Options

- Science

Planning/Budget/

Schedule/Risk et al.

Data

- Science

Status/Issues

- Payload

Operations Data

- Instrument

Commands/

Timelines

- Science Content of CSR

- Science Resource

Needs/Status

- Science

Discoveries/

Revelations

- Product Design

Data

- Payload

Accommodation

Design Data

Technical

Solution

Viewpoint

- Design

Specifications

- Engineering

Planning/Budget/

Schedule/Risk et…