Canadian Space Agency

Canadian SpaceAgency

Agence SpatialeCanadienne

NCAGE Code: L0889

FOR CANADIAN SPACE AGENCY USE ONLY This document and the information contained herein are not to be used for any purpose other than to accomplish

Canadian Space Agency programs and projects whether they are completely Canadian initiatives or in cooperation with International Partners. The contents of this document are not to be disclosed or transferred in whole or in part,

to any third party without the prior written consent of the Canadian Space Agency.

© HER MAJESTY THE QUEEN IN RIGHT OF CANADA 2020

CSA-SE-GDL-0001

Canadian Space Agency

Systems Engineering Mission Tailoring Guidelines

Initial Release

July 2020

CSA-SE-GDL-0001 Initial Release

ii

This Page Intentionally Left Blank


iii

PREFACE

Proposed changes to the currently approved baselined version shall be submitted as Change Requests per the CSA Configuration Management process for evaluation and submission for approval. Approved changes shall be incorporated in the next revision.

Prepared by:

John Beck Senior Systems Engineer

Space Exploration

Date

Recommended by:

Tony Pellerin Systems Manager

Space Exploration

Date

Recommended by:

Gilles Brassard Systems Manager, Engineering

Space Utilization

Date

Recommended by:

Alfred Ng Manager, Project/Programs Portfolio

Space Science and Technology

Date

Recommended by:

Daniel Rey Systems Engineering Manager

Space Exploration

Date


iv

Recommended by

Nicodemo Giurleo Acting Manager , Safety and Mission Assurance

Programs and Integrated Planning

Date

Approved by:

Ralph Girard Director, Sun-Earth System Sciences

Space Utilization

Date

Approved by:

Steeve Montminy Acting Director, Engineering Development

Space Science and Technology

Date

Approved by:

Erick Dupuis Director, Space Exploration Development

Space Exploration

Date

Approved by:

Melanie Winzer Executive Director, Programs and Integrated Planning

Programs and Integrated Planning

Date

RGirard

Sticky Note

Acting


v

REVISION HISTORY

Rev. Description Initials Date

IR Initial Release (Released for use with LEAP as a test case)

JRB July 2020


vi

TABLE OF CONTENTS

1 INTRODUCTION ........................................................................................................................1

1.1 PURPOSE .......................................................................................................................................................... 1 1.2 SCOPE .............................................................................................................................................................. 1 1.3 APPLICABILITY ................................................................................................................................................ 2 1.4 DOCUMENT STRUCTURE .................................................................................................................................. 2

2 DOCUMENTS ............................................................................................................................3

2.1 APPLICABLE DOCUMENTS ................................................................................................................................ 3 2.2 REFERENCE DOCUMENTS ................................................................................................................................. 3 2.3 OTHER DOCUMENTS AND PUBLICATIONS......................................................................................................... 4

3 GUIDELINES FOR EFFECTIVE SPACE PROGRAM TECHNICAL MANAGEMENT ......................5

3.1 OVERALL PHILOSOPHY FOR SPACE PROGRAM SUCCESS .................................................................................. 5 3.2 MISSION CLASS SELECTION ............................................................................................................................. 5 3.3 MISSION DEFINITION ........................................................................................................................................ 6

3.3.1 Technical Factors .................................................................................................................................. 6 3.3.2 Programmatic Factors ........................................................................................................................... 9

3.4 PROGRAM IMPLEMENTATION ......................................................................................................................... 10 3.4.1 Technical Management ........................................................................................................................ 10

4 SYSTEMS ENGINEERING PRACTICES TAILORING .................................................................12

4.1 SYSTEMS ENGINEERING METHODS AND PRACTICES ...................................................................................... 12 4.2 TECHNICAL REVIEWS ..................................................................................................................................... 12 4.3 DOCUMENTS (CDRL) .................................................................................................................................... 13 4.4 SYSTEM ENGINEERING MANAGEMENT PLAN ................................................................................................. 13 4.5 TECHNOLOGY READINESS AND RISK ASSESSMENTS ...................................................................................... 14

5 ACRONYMS AND ABBREVIATIONS .........................................................................................16

APPENDICES ...................................................................................................................................18

A SE METHODS AND PRACTICES - MISSION TAILORING GUIDELINES ...................................19

B TECHNICAL REVIEW STANDARD - MISSION TAILORING GUIDELINES ................................29

C CDRL COMPENDIUM - MISSION TAILORING GUIDELINES .................................................33

D SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP) - MISSION TAILORING

GUIDELINES ...................................................................................................................................38

E CSA PROJECT RISK CLASS DEFINITIONS ............................................................................47

F CSA S&MA MISSION CLASSIFICATION MATRIX ................................................................48

F.1 S&MA MATRIX PER MISSION CLASS ........................................................................................................ 48


vii

LIST OF TABLES

TABLE PAGE TABLE 4-1 – SYSTEMS ENGINEERING TAILORING SUMMARY ............................................................................. 15

TABLE A-1 – SYSTEMS ENGINEERING METHODS AND PRACTICES SIMPLIFICATION GUIDELINES PER MISSION CLASS ................................................................................................................................................. 19

TABLE B-1 – TECHNICAL REVIEW GUIDELINES FOR EACH MISSION CLASS ..................................................... 29 TABLE B-2 – TECHNICAL REVIEW RESPONSIBILITY GUIDELINES PER MISSION CLASS .................................. 32 TABLE C-1 – TECHNICAL DOCUMENTATION PER MISSION CLASS ..................................................................... 33 TABLE D-1 – SEMP REQUIREMENTS PER MISSION CLASS .................................................................................. 38 TABLE E-1 – CSA PROJECT RISK CLASS DEFINITIONS ........................................................................................ 47 TABLE F-1 – S&MA LEVELS MATRIX ........................................................................................................................ 48


1

1 INTRODUCTION

1.1 PURPOSE

These guidelines have been prepared to assist Systems Engineers and others to select, interpret, and implement CSA space program system engineering practices in accordance with the relevant CSA Mission Class1. These Mission Classes are defined in document CSA-PIP-GDL-0001 “Project Risk Class Selection Guidelines” (AD-01).

It is expected that these guidelines will be used by CSA program implementers, initially to prepare the program definition documents, such as the Statement of Work (SOW) and its included Contract Data Requirements List (CDRL), and subsequently to execute successful, efficient projects.

The defined CSA Mission Classes are shown in Table A-1 of AD-01, and reproduced here as Table E-1, for convenience.

1.2 SCOPE

This document is for use by Systems Engineers and others, e.g., Project Managers, both at CSA and at all other organizations involved in the development of space systems for or with the CSA. These guidelines:

a) Give general advice as to how to define and manage the system engineering aspects of programs of all sizes according to their mission class, with particular emphasis on delivering smaller, efficient (Class C/D) missions.

b) Show how the requirements in existing Systems Engineering (SE) documents can be tailored according to the mission class.

These guidelines have been written primarily from a Systems Engineering viewpoint, but also implicate aspects of the Project Management and Safety and Mission Assurance (S&MA) domains. Authoritative Guidelines for these are to be found elsewhere; for instance, AD-01 includes a table (Table B-1)2 that defines the appropriate S&MA requirements and plans per mission class.

These guidelines apply primarily to space missions, but can also be used for other missions, such as research and technology demonstrations carried out in balloons, sounding rockets, or aircraft.

1 Note that the terms Mission, Program, Project Risk, Project, Payload and Class, Classification are used somewhat synonymously in this and other CSA tailoring documents (e.g., AD-01), depending on the particular context. In this document we generally use the term Mission Class, as it is used regularly by systems engineers in the space community. 2 Reproduced as Table F-1in this document and may not be the latest version. See AD-01 for latest version.


2

1.3 APPLICABILITY

This document is particularly applicable to Class C and D programs, which are amenable to considerable tailoring from Class A and B requirements.

(The existing SE document suite was written to encompass all classes, but primarily addresses Classes A and B, as they have the most exacting requirements, which can be considerably de-scoped for Classes C and D.)

1.4 DOCUMENT STRUCTURE

The main body of this document is in six sections:

Section 1. An introductory section giving an overall description of the document’s purpose, scope, and applicability.

Section 2. A listing of Applicable, Reference, and Other documents.

Section 3. Describes the overall philosophy for tailoring according to the mission class, provides general guidelines for managing and implementing successful, efficient programs, and gives specific advice on several important topics. This section is primarily applicable to Class C and D programs.

Section 4. This section and Appendices A through D, give guidelines and tables for tailoring the requirements specified in particular SE documents. It is applicable to all classes, although most tailoring will be for Classes C and D.

Appendices A – D. Tailoring Tables:

A. Systems Engineering Methods and Practices (AD-02)

B. Technical Reviews Standard (AD-03)

C. CDRL Compendium (AD-04)

D. Systems Engineering Management Plan (SEMP) Template (AD-05)

Appendices E, and F provide for reference only and may not be the latest versions:

E. CSA Project Risk Class Definitions

F. CSA S&MA Mission Classification Matrix


3

2 DOCUMENTS

2.1 APPLICABLE DOCUMENTS

The following documents of the exact issue date and revision level shown are applicable and should be read in conjunction with this document to the extent specified herein.

AD Document Number Revision Livelink

Reference Title

CSA-PIP-GDL-0001 Latest Project Risk Class Selection

Guidelines

CSA-SE-PR-0001 C Systems Engineering Methods and

Practices

CSA-SE-STD-0001 B Technical Reviews Standard

CSA-SE-STD-0002 A CDRL Compendium

CSA-SE-PL-0001 B Systems Engineering Management

Plan (SEMP) Template

CSA-ST-GDL-0001 D Technology Readiness and Risk

Assessment Guidelines

(AD-03 to AD-05 are future revision numbers after pending revisions)

2.2 REFERENCE DOCUMENTS

The following documents provide additional information or guidelines that either may clarify the contents or are pertinent to the history of this document.

RD Document Number Revision Livelink

Reference Title

RD-01 NASA NPR 8705.4

Effective Date: June 14, 2004

Expiration Date: June 14, 2019

Risk Classification for NASA Payloads (Updated w/change 3), Appendix B - Classification Considerations for NASA Class A-D Payloads

RD-02 NASA SP-2016-6105 Rev 2 Systems Engineering Handbook,

Table 3.11-1 Example of Program/Project Types

RD-03 CSA-PM-GG-0010 C Investment Governance and

Monitoring Framework (IGMF)

RD-04 CSA-DID-450-IR-SEMP

IR DID-450 – Systems Engineering

Management Plan (SEMP)


4

2.3 OTHER DOCUMENTS AND PUBLICATIONS

The following documents and publications provide additional information to supplement the contents of this document.

DD Item Livelink Reference

DD-01 Reducing Space Mission Cost, James R. Wertz and Wiley J. Larson, Space Technology Library, Microcosm Inc.

In CSA Library

Ref. TL 872 R44 1996

DD-02 The Logic of Microspace (The Space Technology Library, Vol. 9), Rick Fleeter

In CSA Library

Ref. TL 975.4. F544 2000

DD-03

IAC-18-D1.5.2

A New Approach to Mission Classification and Risk Management for NASA Space Flight Missions

Francesco Bordia*, The Aerospace Corporation

Christopher J Scoleseb, NASA Goddard Space Flight Center

DD-04 GAO-19-262SP

United States Government Accountability Office (GAO) NASA Assessments of Major Projects, May 2019

DD-05

NASA Standing Review Board Handbook for NPR 7120.5D

Effective Date: November 12, 2009

Expiration Date: March 6, 2012

DD-06 Lessons (Being) Learned: Managing a More

Cost-Effective NASA Mission John Scherrer – CYGNSS Project Manager, SwRI, CESAS Sept 17-19, 2014

DD-07 GSFC-STD-1000G Goddard Space Flight Center

Rules for the Design, Development, Verification, and Operation of Flight Systems

DD-08 Lessons Learned Study Final Report For the Exploration Systems Mission Directorate. Led by The Langley Research Center, August 20, 2004

DD-09 Cost-Effective Earth Observation Missions: Outcomes and Visions from the International IAA Study. Paper SSC06-II-2, 20th Annual AIAA/USU Conference on Small Satellites

DD-10 NASA Public Lessons Learned System, https://llis.nasa.gov/


5

3 GUIDELINES FOR EFFECTIVE SPACE PROGRAM TECHNICAL MANAGEMENT

3.1 OVERALL PHILOSOPHY FOR SPACE PROGRAM SUCCESS

“…disciplined execution in accordance with proven best practices is the greatest single contributor to a successful program.”3

The major considerations that affect the success of a program (i.e., the likelihood that the product will meet performance requirements, operate reliably for the mission design life, and meet cost and schedule targets) are:

1. A clear definition of program goals and constraints (both technical and programmatic)

2. Appropriate technical, management, and quality oversight

3. Efficient communications between client and implementer

4. Ownership of the program and product by the implementing team and organization

5. Availability of expert advice

6. Active consideration of advice from lessons learned from related previous programs.

The above considerations are true for programs of all mission classes. This is true, even though, compared to Class A/ B missions, Class C/D missions usually will have reduced requirements with respect to parameters such as performance, lifetime, and reliability.

The principal difference is that Class C/D programs will have simplified engineering, S&MA, and program management practices, with reduced formality and documentation, and with extensive reliance on industrial partners internal processes..

The following sections provide guidance to the selection, definition, and implementation of programs according to the mission class, with emphasis on Class C/D missions. This guidance should be taken as being indicative rather than prescriptive, and should be implemented judiciously, bearing in mind the particular circumstances of the program to which it being applied. It has been derived from many sources in both government and industry (see documents list, above) and some advice may not always be appropriate to a particular CSA program.

3.2 MISSION CLASS SELECTION

Once the broad outlines of a mission have been established, the nominal mission/project risk class will be selected by the project manager, and others, for recommendation to Executive Project Sponsor in accordance with the CSA Project Risk Class Selection Guideline (AD-01) and the CSA IGMF (RD-03). Section 3 of AD-01 outlines the selection process and the responsibilities of the other personnel involved (e.g., S&MA, Systems Engineering).

The mission class decision is a key step which establishes and captures in the program documentation the risk tolerance of the mission, or in other words, the acceptable risk of mission failure. The mission class will determine the Systems Engineering, S&MA, and Project Management approaches to be used.

3 From DD-08


6

A single particular class may be selected for the entire mission, or they may be separately selected for individual elements of the space and ground systems involved. For example a satellite may be defined as Class B, but with individual payload instruments defined as Class C or D.

3.3 MISSION DEFINITION

This is the most critical stage in any program. It is at this stage, and even earlier at the Announcement of Opportunity (AO) release, where it is vital to clearly define requirements, as this is when many decisions will be made that determine the ultimate outcome of the program. The Mission Goals and Objectives Document (MGO) and the Mission Requirements Document (MRD)(which can be used to capture the higher level mission goals and objectives) will be key deliverables in this phase. Stakeholder needs and expectations must be clearly captured and the mission success criteria (MSC) well defined. If the Mission Objectives are well written they will form a measurable set of MSC. Typically these are pass-fail criteria and can be met at various stages over Mission lifetime.

For Class A and B projects, the mission definition phase will likely be long and complex, often involving external partners, governed by lengthy and complex authorization and procurement processes, and preceded by several study phases. These missions are not addressed as such here, although much of the advice given below is applicable to all classes.

For Class C/D projects, although they are still subject to CSA governance and project management practice, Section 4 and the tables in the Appendices should be consulted in order to tailor the requirements of the SE documentation suite when defining the program requirements for these mission classes.

Additionally, in defining the mission requirements and program parameters, other factors to consider are:

3.3.1 Technical Factors

1. Performance Requirements. Class C/D programs at CSA generally have a major science or technology demonstration component, with the Principal Investigator (PI) or lead researcher, who often will be from an outside organization such as a university, having a major role in defining the performance requirements. As controlling the program’s scope is critically important in a cost-limited situation, the CSA definition team must work closely with the PI to ensure that requirements are achievable within the program’s projected resources. For instance, it is important to clearly distinguish between requirements that must be met and those that are only goals. Requirements should be defined and communicated to all parties involved as early as possible (e.g., from the Announcement of Opportunity stage) and onwards.

2. Resource budgets: Mass, volume, power, computer CPU and memory capacity, etc., should be specified with the highest initial margins possible. This will provide flexibility when it is necessary later on to exercise trade-offs between performance and resources.

3. Mission lifetime, reliability, fault tolerance and redundancy. These parameters are inter-related. The major drivers affecting them will be the EEE Parts quality and how much redundancy and fault-tolerance, e.g., fail-safe or “must work” functionality, has been designed-in.


7

Some guidance as to the choice of EEE Parts can be found in the S&MA Matrix in AD-01, and a copy of this has been placed here in Appendix F for reference. Due to the high cost of space-qualified parts, there should be maximum use of Commercial Off the Shelf (COTS) components (especially for nano- and micro-sats). Parts reliability can be enhanced by burn-in, although a trade-off must be made between the costs of self-screening and buying MIL-STD or space-qualified parts.

Where ionizing radiation is a concern, this should be identified early, as choices may have to be made between procuring (expensive and long-delivery) rad-hard parts or performing radiation testing. For electronics inside the spacecraft structure, most COTS electronic parts are good to a total ionizing dose of 10-20 krad, which corresponds to at least 10 years of operation in LEO.

The effect of SEUs on microcircuits must always be considered. Computer systems should be designed to be tolerant of these, or include mitigation techniques such as watchdog timers or automated power cycling.

Redundancy will normally not be a feature of Class D programs, but may be selectively incorporated for Class C. Sub-systems where redundancy can often usefully be applied are Attitude Control, Power, Computers, and Communications.

Small missions with limited design life (less than a year) do not warrant performing reliability analyses or FMECAs.

Good practice is to design most of the software aboard the spacecraft to be uploadable post-launch, and smart enough to reboot itself if it does not hear from the ground for a long period.

4. Launch Environment: Parameters such as shock, vibration, acoustics, and temperature should be defined as narrowly and accurately as possible. If the launch vehicle can be specified early, this will obviate the need to envelope environmental requirements for several vehicles. Conditions during transport to the launch site and on the pad prior to launch will also be a consideration.

5. On-Orbit Environmental Requirements, such as vacuum, temperature, EMC, micro-meteorites, atomic oxygen, microgravity, can be important design drivers and should be defined as accurately as possible.

6. Space Debris, De-orbiting, and Planetary Protection:

The number of satellites and amount of debris in orbit is increasing year by year, and planetary missions are becoming more frequent. International agreements and regulations are becoming more and more stringent, and must be taken into account. Typical factors to consider are:

1. Adequate fuel load for debris avoidance;

2. Adequate fuel load and command ability for de-orbiting;

3. Tolerance of materials and coatings to high-temperature sterilization for planetary protection;

4. The Artemis accords;

5. The ISO standard for space-debris mitigation.


8

7. Model Philosophy. Class C programs will usually apply a Protoflight approach, where the item that will be flown will be subjected to qualification-level environmental testing before launch. Class D programs may launch the flight item with limited, or no, environmental tests beforehand. Class C and to an extent Class D programs will precede the flight unit with breadboard and developmental models of all or parts of the system. In some cases, Class C programs may build a fully representative Engineering Model.

8. Technical Reviews. Formal technical reviews are often expensive propositions involving many personnel and extensive documentation. However, their objectives can be met with minimal risk by selectively tailoring their number, scope, and formality. Being focussed on smaller elements of the program, subsystem design reviews are also effective and cost efficient. Section 4.2 and Appendix B give guidance in this respect.

9. Test Program. “… integration and testing is the phase in which problems are most likely to be found and schedules tend to slip”4. To reduce flight build risk, programs should plan for the maximum use of Flatsat5 and physical engineering models in place of mathematical or software models.

10. Technology Readiness and Risk Assessments (TRRAs). To avoid later “surprises” it is important, early in the program, to accurately assess the Technology Readiness Level (TRL) of each technology element (mission component). When performed thoroughly, i.e., by following the procedure in CSA’s TRRA Guidelines (AD-06), a TRRA will provide accurate TRL assessments and identify those elements that merit special attention and further technology development

The Guidelines specify several stages in the process at which CSA concurrence or agreement is required. If respected, these early interactions minimise the time and effort involved in reviewing the final TRRA report.

Note6 that “technology is often estimated to be at a higher level of maturity than it actually is, as the assessments are frequently self-performed by the project and are not always independently validated. As a result, officials may lack a true understanding of technology risks and their impacts on the project, which in turn can lead to cost and schedule growth.”

11. Verification and Validation. CSA’s Systems Engineering Methods and Practices document (AD-02) has extensive sections (5.5. and 5.6, respectively) on Verification and Validation. The formality of these processes will depend on the Mission Class and size of the program. Class A/B missions will require much formality and documentation. Table A-1shows how these processes can be simplified for Class C/D programs.

4 Per the US GAO 2019 assessments of NASA Major Projects (DD-04). 5 A Flatsat is a high-fidelity test bed for spacecraft electrical subsystems with the components laid out on a laboratory bench. 6 Per the US GAO 2019 assessments.


9

3.3.2 Programmatic Factors

Although these are strictly the responsibility of mission and project management, they are mentioned here briefly due to the strong linkage between technical and programmatic factors in all space programs.

1. Cost Control

Although cost control is important in all space programs, it is particularly important in Class C/D programs where funding is limited and stringent project management practices and controls must be employed. It must also be borne in mind that any serious attempt to reduce costs will involve some elements of compromise, most likely by trading requirements: i.e., by making trade-offs between mission requirements, reliability, lifetime, etc., and the technical solutions available at low cost.

An excellent compilation of cost reduction practices is contained in the book: Reducing Space Mission Cost by Wertz and Larson (DD-01). Although written in the 90’s the book contains much pertinent advice and a good collection of case-studies.

2. Statement of Work (SOW)

Along with the MRD, the SOW is one of the key documents produced at the beginning of the program. Careful crafting of its provisions, which should bear in mind the technical and programmatic factors mentioned above, will define the scope of the program. A key section will be the Contract Data Requirements List (CDRL), which is addressed in Section 4.3 of this document.

3. Risk Management

Maintaining close control over program risks is vital to project success. The process for managing risk should be defined at program initiation and directed at early identification and evaluation of programmatic and technical risks, which will enable the project to make appropriate design and implementation adjustments. Regular meetings of a Risk Management Board (RMB) or similar group are essential and must be planned for. The RMB must include both program and technical staff. The size of the RMB will vary according to the risk tolerance accepted for the mission.


10

3.4 PROGRAM IMPLEMENTATION

Having tailored the initial technical and program parameters to the mission class in the mission definition phase, a similar philosophy should be followed during the program implementation phases. The following paragraphs provide advice on effective project implementation, with emphasis on simplification practices well suited to Class C/D projects.

3.4.1 Technical Management

1. Engineering & Science Teams

It is desirable to have small and focused teams. Thus it is better to have a few personnel dedicated at 100% to the project, rather than several splitting their time amongst several. Of course, knowledgeable technical specialists may be called upon for short periods. This advice applies to both the CSA’s and the contractor’s technical management teams.

Scientists and Engineering teams at contractors should be tightly integrated, with CSA engineers and scientists participating as necessary, with close communication channels and without making them communicate with each other only through the CSA, or only when the CSA is there to mediate discussions.

2. CSA oversight of Contractor

CSA’s knowledge of the organization or company implementing the project and confidence in their management and technical capabilities will have a strong bearing on the level of oversight CSA applies. Some aspects of this oversight to consider when tailoring requirements for Class C/D projects are:

Have a goal of reducing contractor reporting and documentation by increasing the number of informal progress meetings, TIMs, peer-to-peer contacts and/or inspection points.

Use tailored contractor’s institutional documents for processes rather than writing one-time project-specific documents.

Reduce the number of deliverable documents appropriate to the class of mission-

3. Meetings and Reviews (see also Section 4.2)

Wherever possible, eliminate formal reviews and maintain visibility with table-top reviews and frequent regular voice or video conferences.

Encourage the contractor to perform internal peer-to-peer review and also encourage informal TIMs with CSA ahead of important reviews. Approach the design reviews as opportunities to improve the design and increase chances of mission success.

Provide more flexibility to the contractor on the format of the deliverables documents. The focus should be on the chances of mission success.

Invite external experts, perhaps members of standing review boards. Capture their comments and recommendations with Request For Action (RFA) forms (ref. AD-03) during the meeting. The RFA tracking shall be combined with the RID tracking.

4. Engineering Management

Systems Engineering Method and Practices should be tailored as described in Section 4.1 and Table A-1.


11

Technical management must be flexible and be prepared to make changes to specifications, hardware/software configurations, and test regime parameters, such as pass/fail criteria, on the fly.

Although the intent is to always achieve the project initial performance goals, one must be very careful to avoid scope creep and be prepared to support difficult decisions regarding trade-offs between performance and cost.

The Risk Management process is an extremely useful tool to maintain visibility and control of technical (and programmatic) issues. Regular meetings of the RMB are essential, even if the meetings are held informally and not all members are present. The size of the RMB will depend on the mission size, but it is important that the RMB include both program and technical staff.

Emphasis should be placed on building and testing prototype or engineering models7. Testing should be carried out in relevant (i.e., as close to operational as possible) environments and configurations as possible. Any anomalies that arise during testing must be investigated as thoroughly as necessary to determine the root cause.

5. Software Management

Software is an increasingly important component of space missions and its management merits close attention.

For Class A/B programs, a more comprehensive amount of software documentation deliverables is expected (ref. AD-02) than for Class C/D. The amount of detailed scrutiny prior to key decision points is higher, and it is also expected that software-specific reviews will be considered as entry criteria for major system reviews (e.g. SRR, PDR and CDR). Software requirements, architecture, functional/behavior/data models, and code reviews are amongst target topics for these software-specific reviews.

No recommendation for a specific software development life-cycle model is made in this document. For example: the spiral model, the iterative model, waterfall, agile, or any other development life-cycle model. Each has its strengths and weaknesses, and no one model is best for every situation or for every business type. It should, however, be generally expected that for Class A/B projects with clearly understood requirements, the standard waterfall model will provide good performance. The waterfall model, although rarely applied integrally, is also a standard by which all software documentation is defined.

A large, multi segment program may also apply more than one life-cycle model, depending on the classification of the various software configuration items to be delivered and integrated. For example, ground support equipment software will not benefit much from applying the same level of rigor as for embedded guidance and navigation control software.

7 DD-05: Maximum use of physical engineering models to reduce flight build risk – spend money now to save later.


12

4 SYSTEMS ENGINEERING PRACTICES TAILORING The systems engineering practices described in the documents listed below can be tailored according to the tables referenced in the Appendices below. These tables should always be read in conjunction with the documents to which they apply, as bare paragraph titles may be misleading as to their content.

Additionally, Table 4-1, below, provides a very brief summary of SE items open to tailoring.

4.1 SYSTEMS ENGINEERING METHODS AND PRACTICES

The comprehensive Systems Engineering Methods and Practices document (CSA-SE-PR-0001, AD-02) was written to apply to all Mission Classes. As such, it principally addresses Class A and B missions, with low risk tolerance and involve considerable oversight and formality. Programs developing these types of mission would normally require adherence to most of the methods, practices and documents specified, whereas a Class C or D program (with higher risk tolerance ) will simplify or even omit a number of them.

Table D-1 shows guidelines for these possible simplifications or omissions. The table entries specifically address the content of each paragraph referenced in AD-02, and must be read in conjunction with that paragraph.

Note that these are only guidelines. The boundaries between Classes are not rigid; the practices to be employed on any particular program will be very mission-specific, and will need to be determined beforehand by the CSA Program Authority and SE and S&MA Leads.

4.2 TECHNICAL REVIEWS

CSA’s Technical Review Standard (CSA-SE-STD-0001, AD-03) provides specific directives for the conduct of formal technical reviews that are held throughout the life cycle of CSA space missions. The Standard was written to apply to all mission classes, but while a large Class A or B program might normally hold most of the reviews described, a Class C or D program would hold far fewer. Appendix B, below, provides guidelines for establishing the number of reviews held. and their formality, according to mission class.

When reviews are held, although most agenda items designated in the Standard will likely have to be addressed to some degree, it may be possible, particularly in Class C/D programs, to reduce the scope and formality of the meeting, by:

a) Reducing the scope of the meeting. For example, at a PDR, omitting discussion of Objective 10) Government Policies, Security and International Laws Requirements. Note that it is unlikely that this type of scope reduction can be employed to any great extent, otherwise the ultimate goal of achieving a thorough review will not be attained.

b) Holding pre-design reviews. These are small reviews with fewer participants and provide early feedback to the engineering teams. Additionally, subsystem design review prior to formal reviews at the system level should be encouraged.

c) Reducing the formality and scope of CSA oversight activities as per Table B-2, which is a guideline for the recommended oversight activities per mission class. Note that these are guidelines only; the practices to be employed on any particular program must be determined beforehand by the CSA Program/Technical Leads, in collaboration with the Contractor.


13

d) Note that these guidelines apply only to the Technical Reviews described in the Technical Review Standard. Other authorities, particularly Program Management and S&MA will hold their own reviews, as well as participating in many technical reviews.

e) Class A/ B/C programs involving external partners (e.g. NASA) will likely have additional reviews imposed, e.g., Safety Reviews.

Table B-1 shows guidelines for establishing the number of reviews held and their formality, per mission class. The table is organised by mission phase. For specific details of any review, see the Technical Reviews Standard, AD-03.

Table B-2 shows how the oversight requirements for reviews can be tailored according to mission class. It is based on the functions described in Section 4.1 of AD-03.

4.3 DOCUMENTS (CDRL)

CSA-SE-STD-0002 provides exhaustive lists of known documents that may be developed, either by the CSA or a Contractor, throughout the life of a project. It can be used as a reference when developing the SOW CDRL.

Nevertheless, for any single mission and mission phase, a much smaller set of documents will be selected. The CSA should ask themselves the following questions: why is this CDRL Item required? Is the content covered in another document? Is it a contractual obligation? Do we need this document in every phase of the project? Etc.

To aid this selection, Appendix C is a tabular set of guidelines for tailoring the list of engineering documents called up in a CDRL to match the CSA mission class. It is based on a typical set of engineering documents such as would be produced in a CSA program and called up in the CDRL defined in the SOW. Note that in Revision A of the CDRL Compendium a recommended Core set of deliverables has been highlighted in boldface; however this selection has more items than the basic list in Appendix C.

Note that these are only guidelines: the boundaries between mission classes are not rigid, and the list of documents required by any particular program will be very mission-specific and will have to be determined beforehand by the CSA Program Authority and SE and S&MA Leads.

4.4 SYSTEM ENGINEERING MANAGEMENT PLAN

CSA-SE-PL-0001 is intended to serve as a template that will be used by Canadian Space Agency (CSA) Systems Engineers to produce a CSA Project SEMP. Such a document is unlikely to be written for smaller, e.g., Class C/D missions. However, the CSA document is useful as it provides a template for a Contractor SEMP if that is required.

Contractors may be required (in their proposal or per the program SOW) to produce a SEMP; in which case CSA Data Item Description DID-450-IR-SEMP (RD-04) can be used as a template for the format and content required.

Even if a SEMP is not required it is likely that the Contractor will be requested to incorporate a description of their technical management practices and processes as part of a Program Plan, such as would be required to supplement a proposal.


14

Appendix D is a table that addresses each of the SEMP requirements, and identifies those that are of special importance to Class C/D programs and should be included in a contactor’s SEMP, or its equivalent. Note that many comments mirror those in Table A-1 (SE Methods and Practices Simplification Guidelines Per Mission Class).

4.5 TECHNOLOGY READINESS AND RISK ASSESSMENTS

The process for identifying Critical Technology Elements (CTEs) described in the current issue of the TRRA Guidelines (AD-06) has been considerably simplified since earlier editions, and will be carried out in the same way for all Mission Classes. The number of elements addressed will vary with the size of the program, and there is room for tailoring in respect of how the results are reported. As described in the Guidelines, the options are: full report, report included in project report, or summary form using a standardized template.


15

TABLE 4-1 – SYSTEMS ENGINEERING TAILORING SUMMARY

SE Element SE Sub-Element Class A Class B Class C Class D

Technical Reviews

(see also Table B-1)

MRR, SRR Yes Yes Yes Yes, limited scope

SDR Yes Yes Recommended Yes, limited scope; combine with SRR

PDR, CDR, etc. Unit, sub-system,

system Unit, system

System, TIMs at lower-level

TIMs

AR Unit, sub-system,

system Unit, system System only System only

PSR, LRR System only System only System only System only

Review approval rights CSA CSA CSA N/A

RIDs Classification, resolution plan, and closure

subject to approval of CSA RID owner Smaller programs may omit the cumbersome RID process. Can be supplemented by RFAs

Model Philosophy

New or Modified Designs

EM + PFM or EQM + FM or EM, QM +FM

EM + PFM or

EQM + FM or

EM, QM +FM

DTM/EM + PFM DTM + FM

Space Heritage Designs FM FM FM FM

Test Program

Acceptance testing

(Functional, environmental)

Unit, sub-system, system


System Functional +

Interface check and safety verification

Qualification testing

(Functional, environmental)



System Limited or None


16

5 ACRONYMS AND ABBREVIATIONS

AIT Assembly. Integration, and Test

AO Announcement of Opportunity

CADM Configuration And Data Management

CADMS ?

CDRL Contract Data Requirements List

CM Configuration Management

COTS Commercial Off-The-Shelf

CTE Critical Technology Element

DID Data Item Description

DTM Development Test Model

EEE Electronic, Electrical, Electromechanical

EIDP End-Item Data Package

EM Engineering Model

EMC Electro-Magnetic Compatibility

EPR Engineering Peer Review

ERT External Review Team

FM Flight Model

FMECA Failure Modes Effects and Criticality Analysis

GAO (US) Government Accounting Office

GIRDGDIR General Design & Interface Requirements

IGMF Investment Governance and Monitoring Framework

ISO International Organization for Standardization

ISS International Space Station

KOM Kick-Off Meeting

KPP Key Performance Parameters

LCC Life-Cycle Cost

LEO Low Earth Orbit

LEOP Launch and Early Orbit Phase

LRR Launch Readiness Review

MIL-STD Military Standard

MOST Microvariability and Oscillations of STars

MRD Mission Requirements Document

MRR Mission Requirements Review

MSC Mission Success Criteria


17

PA Product Assurance

PDR Preliminary Design Review

PFM ProtoFlight Model

PI Principal Investigator

PM Project/Program Manager

PSR Pre-Shipment Review

PtP Peer to Peer

RFA Request For Action

RB Review Board

RBM Review Board Meeting

RID Review Item Discrepancy

RMB Risk Management Board

S&MA Safety and Mission Assurance

SDP Software Development Plan

SDR System Design Review

SE Systems Engineering

SEMP Systems Engineering Management Plan

SEU Single Event Upset

SOW Statement Of Work

SRR System Requirements Review

TIM Technical Interchange Meeting

TRM Technical Review Meeting

TRRA Technology Readiness and Risk Assessment

T-V Thermal Vacuum

WoG With other Government


18

APPENDICES


19

A SE METHODS AND PRACTICES - MISSION TAILORING GUIDELINES

TABLE A-1 – SYSTEMS ENGINEERING METHODS AND PRACTICES SIMPLIFICATION GUIDELINES PER MISSION CLASS

Para., Figure, Table, and Appendix numbers refer to items in CSA-SE-PR-0001 (AD-02). This table should be read in conjunction with the referenced document.

CSA-SE-PR-0001 B Paragraph

Number Title Class A

Class B

Non-human Space or Science/Robotic

Missions)

Class C

Smaller Science or Technology Missions

(e.g., ISS Payload)

Class D

N/A Type per NASA NPR 8705.4 Human Space or Large Science/Robotic Missions

Non-human Space or Science/Robotic Missions

Small Science or Robotic Missions


(ISS payload)

N/A Type per CSA-PIP-GDL-0001 Earth observation satellite, deep space,

human rated

Smallsat, operational microsat, ISS external

payload

Scientific or academic Microsat, ISS internal

experiments

Stratospheric Balloons, academic nanosats, grants

and contributions

3 MISSION PHASES AND ACTIVITIES

Lead-in paragraph

3.1 Project Phases Definitions

(Phases 0 through F) As described

Smaller programs may combine or even omit Phases, e.g., combine

Phases 0 and A

Smaller programs may combine or omit Phases

Controlled Baselines Formally controlled (see Para. 3.1 and Fig. 3-1) Less formally controlled

3.2 Description of Activities (in each Phase)

As described All activities will be needed to some extent, but with less formality and documentation

3.3 System Definition Sequence Descriptive section, generally applicable to all programs

3.4 Systems Nomenclature Descriptive section, generally applicable to all programs

4.0 GENERAL REQUIREMENTS

List of sub-sections

4.1 SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP)

CSA SEMP required (to CSA template CSA-SE-PL-0001 AD-05).

Contractor SEMP required, see DID-450 (RD-04).

Contractor SEMP required see DID-450 (RD-04).

Contractor SEMP optional. Description of Technical Management required in Program Management Plan to CSA SE Methods and Practices required

Not usually required


20



Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.2 SYSTEMS ENGINEERING MANAGEMENT AND CONTROL

List of topics

4.2.1 SE Management General statement regarding SE responsibilities and functions. Applicable to all programs to a greater or lesser extent

4.2.2 Technical Organization Heading

4.2.2.1 Technical Manager (Systems Manager/Chief Engineer)

Dedicated role in large projects. Leads technical team. Duties as described

Smaller projects will combine Technical Manager/Systems Engineer roles

4.2.2.2 Systems Engineer May be more than one, each assigned to major subsystem (e.g. bus or payload). Duties as described for each subsystem

Usually only one, could be combined with other roles (e.g., Technical Manager, Speciality Engineer)

4.2.2.3 Speciality Engineers Level of effort required will depend on program. Mission science team may contribute

4.2.3 Responsibility Allocation Develop the SE Management section of the Project Management Plan

4.2.4 Systems Engineering Working Group (if required)

Only for large programs Unlikely to be required Not required Not required

4.2.5 Reporting Technical Reviews and Audits

List of topics

4.2.5.1 Progress Monitoring Periodic written reports and meetings. Bi-weekly status teleconferences.

Periodic written reports and status reviews (teleconference)

Periodic teleconference status reviews. Inputs to program monthly reports

Teleconferences and notes as needed

4.2.5.2 Technical Reviews See CSA Technical Reviews Standard CSA-SE-STD-0001

4.2.5.3 Technical Interchange Meetings

As required As required. TIMs or PtP meetings will be main vehicle for technical information sharing in smaller programs

4.2.5.4 Configuration Audits S&MA responsibility, see CSA-CM-PL-0001. Size and formality will depend on mission size and class.

4.2.5.5 Contractors’ Systems Engineering Capability Assessment (by CSA)

Formal audit only if required by SOW

Assessed informally Assessed informally Assessed informally

4.2.5.6 5.2.5.6 Contractors’ SEMPs Review (by CSA SE)

Required Not required (no SEMP)

4.2.6 Design and Development Plan Required Only if required by SOW, but desirable

May be part of Program Plan


21



Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.2.7 Technology Readiness Levels TRRA needed as per CSA-ST-GDL-0001B, along with Technology Development Plan and Roadmap. GDL-0001B allows for tailoring of reporting requirements.

Some small programs may omit

4.2.8. Interface Management General principle “maintain a positive control of all hardware and software interfaces” is applicable to all classes. Class A, B will have formal IRDs, ICDs, whereas Class C, D could incorporate I/F requirements and details into other documents or control with drawings alone

4.2.9 Technical Performance Measures (TPMs) and Margin Philosophy

Formal tracking processes and documentation required Tracked and reported as part of routine systems engineering progress monitoring (see 5.2.5.1)

4.2.10 Environmental Engineering Intrinsic Systems Engineering responsibility for all classes

4.2.11 Human Factors Engineering Crew safety, procedures, etc. will be rigorously controlled in human-rated programs.

Intrinsic Systems Engineering responsibility where applicable

Important consideration for ISS payloads, otherwise Intrinsic Systems Engineering responsibility where applicable


4.2.12 Software Development May require formal Software Development Plan Software development engineering should use approved processes. No “spaghetti code”! (ISO/IEC 29110 is a good example of a lightweight standard well adapted for teams below 25 persons).

4.2.12.1 Software Class Software Class is not the same as Mission Class

4.2.12.2 Software Type Descriptive definitions only

4.2.12.3 Software Documentation Required as per CSA-SE-PR-0001 Table 4.3 Guidelines Less formality required, dependent on mission

4.2.12.4 Software Development Planning

Can use existing CSA or Contractor documents.

4.2.12.5 Software Implementation and Verification Planning


4.2.12.6 Software Activities Formal tracking processes and documentation required Tracked and reported as part of routine systems engineering progress monitoring (see 5.2.5.1)

4.2.13 Schedule and Cost Activities are Intrinsic Systems Engineering responsibility for all classes. All Mission Classes may require Design-to Cost and Life Cycle Costing. Concurrent Engineering can be used in all Classes, and can be very effective in small programs.


22



Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.2.13.1 Schedule SE schedule established in SDP

Schedule control and reporting are intrinsic SE tasks

4.2.13.2 Cost Effectiveness Cost-effectiveness consideration is intrinsic SE task and trade-off studies may be implemented in all Mission Classes

4.2.13.3 Design-to-Cost Implementation is complex in large projects, and cost will be traded against performance, which generally has higher priority

May be forced on smaller projects, even at the expense of performance

4.2.13.4 Life Cycle Cost Applicable in Phase 0 & A and to CSA only (see Appendix B). Applicability depends on program

4.2.14 Risk Management Programs will likely require a formal Risk Management Plan and tracking

Part of routine SE and Project Management Plan activities

4.2.15 Procurement Routine SE and speciality engineer task

4.2.16 Documentation Lead-in paragraph

4.2.16.1 Systems Engineering Documentation

Contract Data Requirements List (AD-3) will be tailored for each mission. Refer to Systems Engineering Documentation Guidelines By Mission Class ref Table C-1

4.2.16.2 CDRL and DIDs Contractor format may be accepted if pre-approved per SOW.

Contractor format usually acceptable; DIDs as guidelines. See Table C-1

4.2.16.3 Documents Review Paragraph addresses documents subject to formal reviews. Note that RID tracking may be a Program Management or CADM responsibility. Current norm is to use CADMS.

Appendix D of CSA Technical Reviews Standards gives guidelines for tailoring review requirements to mission class

4.2.17 Configuration Management Lead-in paragraph Very small programs may dispense with complex CADM procedures Changes may be documented as part of the revision block for changes which do not impact performance or build documentation.

4.2.17.1 Configuration Baseline Control

Formal configuration control will be applied Configuration control not formally applied, but must be maintained with careful SE/CADM oversight.

See Table F-1

4.2.17.2 Product Tree Important document. Needed for all programs. Also see utilization as Product Breakdown Structure in TRRA Guidelines CSA-ST-GDL-0001

4.2.17.3 Requirements, Specifications and Drawing Trees

Normally only produced for larger programs May be produced informally according to specific circumstances


23



Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.2.17.4 Documentation Tree Normally only produced for larger programs May be produced informally according to specific circumstances

4.2.17.5 Change Management Formality of activity will depend on CADM procedures implemented

4.2.17.6 Contactor’s Change Process Formality of activity will depend on CADM procedures implemented

4.3 REQUIREMENTS ENGINEERING

Lead-in paragraph. Requirements Generation Process in Fig. 5.2 is generally applicable to all programs. Smaller programs may simplify, combine, or omit MRD and SRD

4.3.1 Responsibilities All programs will conform. Smaller programs may not have Supporting Group.

4.3.2 Requirements Generation General paragraph. Note that Traceability Matrix only implemented for large Class A/B missions

4.3.2.1 Mission Requirements Development

Extent and timing of activity will depend on mission objectives and complexity

4.3.2.2 Operations Requirements Development

Extent and timing of activity will depend on mission objectives and complexity. Formal traceability only needed for large Class A/B missions

4.3.2.3 Systems Requirement Development

Extent and timing of activity will depend on mission requirements and complexity. Formal traceability only needed for large Class A/B missions. Documentation tailored to Mission Class, see Table C-1

4.3.2.4 Software Requirements Development

Extent will depend on mission requirements and complexity

4.3.2.5 Mission Conceptual Design Development

Extent and timing of activity will depend on mission objectives and complexity

4.3.2.6 Preliminary System Conceptual Design Development

Extent and timing of these activities will depend on mission objectives and complexity. On smaller programs these activities will be merged. Note that Test Requirements Development is an important activity that is sometimes under-prioritized

4.3.2.7 System Conceptual Design Development

4.3.2.8 Preliminary Concept of Operations Development

4.3.2.9 Concept of Operations

4.3.2.10 Test Requirements Development

4.3.3 Requirements Attributes Lead in paragraph

4.3.3.1 Requirements Classes Descriptive paragraph


24



Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.3.3.2 Requirements Types Descriptive paragraph

4.3.3.3 Requirements Characteristics Process applicable to all missions. Formal traceability only needed for large Class A/B missions

4.3.3.4 Requirements Criticality Process applicable to all missions. For use of TPMs, see 5.2.9.

4.3.4 Requirements Maintenance Process applicable to all missions. Formal traceability and configuration control only needed for large Class A/B missions

4.4 REQUIREMENTS ANALYSIS, FUNCTIONAL ANALYSIS/ALLOCATION AND SYNTHESIS/DESIGN

Overview of process

4.4.1 Requirements Analysis Formality of process will depend on Mission Class and size of program

4.4.2 Functional Analysis Formality of process will depend on Mission Class and size of program

4.4.3 Synthesis/Design High-level description of engineering tasks. Formality of process will depend on Mission Class and size of program

4.5. VERIFICATION Lead-in paragraph

4.5.1 Verification Objectives Descriptive paragraphs

4.5.2 Verification Methods

4.5.2.1 Analysis

4.5.2.2 Review of Design

4.5.2.3 Demonstration

4.5.2.4 Inspection

4.5.2.5 Test Descriptive paragraph. Model philosophy is described in Para. 5.5.4.2

4.5.3 Verification Strategy and Verification Plan

Formality of process will depend on Mission Class and program parameters. Requirements Verification Matrix, Requirements Compliance Matrix, and Software Verification Plan required only for large Class A/B missions

4.5.4 Space Environmental Qualification Program

Lead-in/descriptive paragraph. See following sub-paragraphs for verification/model philosophy

4.5.4.1 Verification Philosophy Always Qualification plus Acceptance

Qualification plus Acceptance. Could be Protoflight

Usually Protoflight or simple Acceptance

4.5.4.1.1 Qualification Verification Descriptive paragraph N/A

4.5.4.1.2 Protoflight Verification N/A Descriptive paragraph


25



Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.5.4.1.3 Acceptance Verification Descriptive paragraph

4.5.4.2 Model Philosophy and Definitions

Lead-in/descriptive paragraph. See following sub-paragraphs for Model details

4.5.4.2.1 Breadboard Model (BBM) Used in all programs at various levels of assembly. Usually in early stages

4.5.4.2.2 Demonstration Model (DM) or Prototype

Used in many programs at various levels of assembly. Usually in early stages In some cases may be flown as Flight Model

4.5.4.2.3

Engineering Model (EM)

Used in all Qualification plus Acceptance programs at various levels of assembly

Could be EQM Optional, or can have Development Test Model (DTM)

4.5.4.2.4 Engineering Qualification Model (EQM) [Qualification Model (QM)]

Only QM (Flight design and construction; tests at full Qualification levels and durations)

Often EQM. (Flight design but not necessarily flight parts and processes; tests at Qualification levels)

Usually not required

4.5.4.2.5 Protoflight Model (PFM) N/A

Often used. ((Flight design; tests at Qualification levels) but reduced duration)

Usually just one item, i.e., FM with no qual. level testing.

4.5.4.2.6 Flight Model (FM) Tests at acceptance levels Applicable unless PFM

Often limited testing, e.g., functional and thermal, but not full environmental

4.5.5 Verification Process Lead-in paragraph

4.5.5.1 Verification Process Activities

Principles apply to all programs. Formality of process will depend on Mission Class and size of program. Verification Plan and Report required only for large Class A/B missions

4.5.5.2 Verification Deficiencies Descriptive paragraph. Formality of process will depend on mission size and complexity

4.5.5.3 Reengineering Descriptive paragraph. Formality of process will depend on mission size and complexity

4.5.6 Verification Categories Lead-in paragraph

4.5.6.1 Requirements Verification

General principles apply to all programs. Extent of implementation and formality of process will depend on Mission Class and size of program.

4.5.6.2 Factory Acceptance Verification

4.5.6.3 Deployment Verification


26



Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.5.6.4 End-to-end System Testing

4.5.6.5 Operational and Disposal Verification

4.5.6.6 PA Verification

4.5.6.7 Configuration Verification

4.5.7 Verification Implementation Lead-in paragraph. (Usually S&MA are involved also)

4.5.7.1 Verification Execution General principles apply to all programs. Verification compliance matrix required only for Class A/B missions

4.5.7.2 Verification Documentation Generally applicable; see following sub-paragraphs

4.5.7.2.1 Verification and Compliance Matrices

Applicable Applicable Applicable May be used

4.5.7.2.2 Verification Test Plan Applicable Applicable Usually not used Not used

4.5.7.2.3 Test Specification Applicable May be used Usually omitted Not used

4.5.7.2.4 Verification Test Procedures Required for all tests. Formality of documentation and comprehensiveness will depend on mission

4.5.7.2.5 Verification Test Reports Required for all tests. Formality of documentation and comprehensiveness will depend on mission

Often no report. Intent is met by completed test result sheets.

4.5.7.3 Verification Test Reviews TRR and TDR held

TRR and TDR may be held

TRRs and TDRs held informally or omitted

4.5.7.4 Verification Tools and Simulator

Descriptive generalisations. Applicability will be program-specific 4.5.7.5 Hardware-in-the-Loop

4.5.7.6 Contracts Deliverables Verification

4.6 VALIDATION Lead-in/descriptive paragraph. Formality of process will depend on mission class and size; e.g., Class D validation is normally by operating during the mission itself.

4.6.1 Validation Objectives Descriptive paragraph

4.6.2 Validation Methods Descriptive paragraph

4.6.3 Validation Strategy and Validation Plan

Principles apply to all programs. Formality of process will depend on Mission Class and size of program. Verification Plan required only for large Class A/B missions

4.6.4 Validation Process Lead-in/descriptive paragraph. ConOps document required only for large Class A/B missions


27



Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.6.4.1 Validation Process Activities Process applies to all programs. Formality of process will depend on Mission Class and size of program. Verification Plan required only for large Class A/B missions

4.6.4.2 Validation Deficiencies Descriptive paragraphs. Formality of process will depend on mission size and complexity. ConOps document required only for large Class A/B missions 4.6.4.3 Pass Verification but Fail

Validation

4.6.5 Validation Implementation Lead-in paragraph

4.6.5.1 Validation Execution General principles apply to all programs. Formal Validation Report required only for Class A/B missions

4.6.5.2 Validation Documentation Generally applicable; see following sub-paragraphs

4.6.5.2.1 Validation Compliance Matrix Applicable May be used Usually not used Not used

4.6.5.2.2 Validation Test Plan Applicable May be used Usually not used Not used

4.6.5.2.3 Test Specification Applicable May be used Usually omitted Not used

4.6.5.2.4 Validation Test Procedures Required for all tests. Formality of documentation and comprehensiveness will depend on mission

4.6.5.2.5 Validation Test Reports Required for all tests. Formality of documentation and comprehensiveness will depend on mission

Often no report. Intent is met by completed test result sheets or successful flight operation

4.6.5.3 Validation Test Reviews TRR and TDR held TRR and TDR may be held

TRRs and TDRs held informally or omitted

4.6.5.4 Validation Tools and Simulator

Tools used will be program specific

4.7 SYSTEMS ENGINEERING ANALYSES

Lead-in paragraph

4.7.1 Scope of Analysis Effort Descriptive paragraph. Extent and formality of analyses will depend on mission size and complexity

4.7.2 General Analysis Process General advice. Extent and formality of process will depend on mission size and complexity

4.7.3 Analysis Reports Extent and formality of reports will depend on mission size and class

4.7.4 Analysis and Design Tools General advice. See para. 5.1 for SEMP applicability.

4.7.5 Trade-off Studies Descriptive paragraph and general advice. Extent and formality of studies and analyses will depend on mission size and complexity

4.7.6 Logistics Support Analyses Descriptive paragraph. Extent of LSA and logistics planning and implementation will depend on mission size and complexity


28



Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.8 SYSTEMS ENGINEERING INTERFACES

Lead-in paragraph. The interfaces in the following paragraphs apply to a greater or lesser extent to all programs. The extent and formality of the interactions will depend on mission size and complexity.

Some specific points are mentioned below:

4.8.1 CSA Mission Sponsor On smaller programs the Mission Manager function may be performed by the Scientific Authority or merged with the Technical Manager function.

4.8.2 External Stakeholders Note that the classifications Type A and B are not the same as Mission Class A, B referenced in BBBBBB

4.8.3 CSA Project Management Formality and extent of interactions will depend on the mission class and program parameters.

4.8.4 CSA Engineering Specialists

4.8.5 CSA Safety & Mission Assurance

4.8.6 CSA Configuration Management

Systems Engineering will often be members of the Change Review Board (CRB) and/or CCB (Change Control Board).

4.8.7 CSA Operations & Logistics No specific comments

4.8.8 Contractors


29

B TECHNICAL REVIEW STANDARD - MISSION TAILORING GUIDELINES

TABLE B-1 – TECHNICAL REVIEW GUIDELINES FOR EACH MISSION CLASS

This table should be read in conjunction with the referenced document.

Mission Phase Review Title Class A Class B Class C Class D Notes

Concept studies, Phase 0, Pre-Phase A, Mission Definition

Mission Concept Review (MCR)*

Required (system level)


May be combined into one meeting e.g. MRR

May be combined into one meeting e.g. MRR (limited scope)

Typically in NASA programs; usually internal at CSA

Mission Requirements Review (MRR)*

CSA programs

Phase A Operations Requirements Review (OpRR)



May be omitted May be omitted Could be combined with SRR

System Requirements Review (SRR)*

Required Required Required Recommended (limited scope)

NASA end Phase A with a System Design Review (SDR)

System Definition Review (SDR)*

Required Required Recommended Recommended (limited scope). Can be combined with SRR or PDR

Held at the end of Phase A

Phase B Preliminary Design Review (PDR)*

Required at system, sub-system and unit levels

Required at system and sub-system levels

Required at system level

TIMs at lower levels

Recommended Could be TIMs

Formality of the meetings will depend on the program scope.

Phase C Critical Design Review* Required at system, sub-system and unit levels

Required at system and sub-system levels

Required at system level


Recommended. Could be TIMs

Test Readiness Review (TRR)



May be omitted at sub-system level

May be omitted at sub-system level

These meetings also held in Phase D

Test Data Review (TDR)

Mission Operations Review (MOR)




Recommended (system level)

Formality of the meetings will depend on the program scope


30


Production Readiness Review (ProRR)/ or Manufacturing Readiness Review (MRR)

Will be held Will be held May be held Unlikely to be held

PRR held when three or more copies of the system are required.

Phase D Flight Validation and Verification Review (FVVR)



Recommended (system level) may be combined into one meeting

Recommended (system level). Could be combined with AR

Held after the integration of the Flight System and prior to the compatibility test

Ground Validation and Verification Review (GVVR)

Held after the integration of the Ground System and prior to the compatibility test

Compatibility Test Review (CTR)



Recommended (system level

Could be TIM Held after a successful compatibility test between the Flight and Ground Systems

Acceptance Review (AR)* Required for flight and qual. items at system, sub-system and unit levels

Required for flight and qual. items at system, sub-system and unit levels

Required for flight and qual. Items at system level


Required. Could be TIMs or HRMs

Also held during Phase C for Engineering and Development Models and Prototypes

Flight Readiness Review (FRR)*



Recommended. Usually combined

Could be combined with AR

Operations Readiness Review (ORR)*



Pre-Shipment Review (PSR) Required (system level)


May be combined with AR

Usually combined with AR

Held prior to the shipment of the Flight System to the launch site

Launch Readiness Review (LRR)*




Could be TIM Held after the Flight System is integrated into launch vehicle and launch preparation has been successfully completed

Phase E Commissioning Review (CR)*



Recommended (system level)

Could be TIM Held at the beginning of Phase E, after the LEOP and commissioning

Decommissioning Review (DR)*




Could be TIM Held at the end of Phase E


31


Other meetings Technology Readiness and Risk Review (TRRA)

TRRAs are held as required during Phases 0, A, B, and C/D. Normally, TRRAs are held in conjunction with early control gate reviews (e.g., MCR, MRR, SDR) and sometimes at later ones (e.g. PDR, CDR)

Hardware Review Meeting (HRM)

Non-flight equipment only



May replace Acceptance Review for Flight equipment without software

HRMs are held as required during the development phases of a project, where they may replace Acceptance Reviews for intermediate deliverables

Software Review Meeting To be added

Ancillary meetings common to formal reviews

Kick-Off Meeting (CSA) Required Required Optional Usually not held Internal meeting held before formal reviews

RID Disposition Meeting Required Required Required when RIDs used.

RIDs not normally used.

Project Team Closing Meeting (CSA)

Required Required Optional Usually not held For CSA Project Team

Review Board Meeting (CSA)

Required Required Optional Usually not held

Close-Out Report Required Required May be necessary

May be necessary Prepared by CSA Project Team

NOTES:

1. Reviews marked with an asterisk (*) are Major Control Gates at the system level. Others are Interim Reviews.

2. For each program the definitive list of reviews required by CSA will be specified in the SOW CDRL. Additionally, contractors will hold their own reviews for various system components.


32

TABLE B-2 – TECHNICAL REVIEW RESPONSIBILITY GUIDELINES PER MISSION CLASS

Review Body

(see Section 4.1) Review Body Function Class A Class B Class C Class D

CSA Project Team: In-house project

Perform work. Manage interfaces with partners. Manage sub-contractors.

N/A Present work and documentation to CSA peers and ERT

CSA Project Team: Contracted project

Oversee Contractor’s work. Manage interfaces with partners.

Formally review Contractor’s work and documentation. Raise & Track RIDs/RFAs. Prepare closeout report

Review Contractor’s work and documentation. TIMs meetings. Raise & Track RID and RFAs

Contractor Project Team Perform Work. Manage sub-contractors.

Formally deliver documentation and presentations to CSA Project Review Team, RB, and ERT.

Prepare RID dispositions. Resolve and close RIDs. Prepare Closeout Report

Limited formal document deliveries to CSA, but all available for review. Presentations made to CSA Project Review Team, and ERT at review meeting.

CSA Review Team (shown for contracted project; in-house project will use internal independent group)

Review Contractor documentation and presentations

Review Contractor’s documentation. Raise RIDs. Attend KOM, TRM, and RDM.

Negotiate RID dispositions with Project Team. Track and resolve RIDs and Action Items to closure.

Review Contractor’s work and documentation. TIMs or Engineering Peer Review (EPR) meetings. Raises RIDs.

CSA Review Board Top reviewing authority Approve Review Plan. Chair or co-chair and participate in KOM, TRM, RBM. Approve ands sign Closeout Report

Approve deliverables. Chair or co-chair and

participate in review meetings. Simplify membership of the review board.

External Review Team (ERT) (Optional)

Review In-house work, independent review of Contractor work

Review Contractor’s work and documentation. Raise RIDs. Selectively attend KOM, TRM, RDM, and RBM

Selectively support CSA and Contractor teams and reviews as needed. Can be invited by Contractor

Required Meetings associated with TRM KOM, (TRM), RDM, RBM, EPRs/TIMs EPRs/ TIMs


33

C CDRL COMPENDIUM - MISSION TAILORING GUIDELINES

TABLE C-1 – TECHNICAL DOCUMENTATION PER MISSION CLASS

This table is derived from the CDRL Compendium, but is not a one-to-one match. It is designed to show a typical basic set of SE documents that might be generated in CSA project.

Systems Engineering Requirement

SE Document Class A Class B Class C Class D Notes

CSA Applicable Documents listed in the contract Statement of Work (SOW)

Systems Engineering Methods and Practices

(SEMP) Template

Applicable Documents; Statement of Compliance may be required.

Applicable Documents

Applicable or Reference Documents

Applicable or Reference Documents

The CSA SOW will also include a list of other Reference documents that will be available to the Contractor

Technical Reviews Standard

Applicable Document Applicable or Reference Document

Software Management Plan

Technology Readiness and Risk Assessment Guidelines

Applicable Document Applicable Document

Applicable as specified Applicable as specified

Contract Document Requirements List (CDRL) and accompanying Data Item Descriptions (DIDs) in SOW

CDRL/DIDs (selected from CSA CDRL Compendium and DID Repository). Typical examples are listed in this table, below.

Applicable as specified in SOW




Timing of Contractor’s document submissions will be as per the CDRL

High-level contractor-provided Plans

SEMP (to CSA template?)

Mandatory Required Documents, for CSA Approval

Required Documents as per SOW for CSA Approval

Required Documents as per SOW for CSA Approval or Review. Plans could be presented as PowerPoint slides at e.g., the KOM

As per SOW for Review or Acceptance, but generally not requested. Plans could be presented as PowerPoint slides at e.g., the KOM.

Contractor format is generally acceptable for all documents, provide all relevant items in the respective DID are addressed

Mission Operations Plan

Verification & Validation Plan

System Test Plan


34



Equipment Test Plans (Thermal, T-V, Vibration, Acoustics, Shock, Balance)

Technology Development Plan

EMC Control and Test plan

Shipping & Handling Plan

Spares Plan

Fracture Control Plan If applicable If applicable If applicable If applicable

Requirements Documents provided by CSA

Science Concept All Documents (and subsequent changes) under CSA and contractor Configuration Control

All Documents (and subsequent changes) under CSA and optionally Contractor Configuration Control

All Documents (and subsequent changes) at least under CSA configuration control.

Particularly in Class C & D programs, some of these documents may be written collaboratively between Client and Contractor.

Mission Concept

Science Requirements

Mission Requirements

System Requirements

Mission Operations requirements

Environmental Requirements and Test Specification (ERTS)

All Documents (and subsequent changes) under CSA and contractor Configuration Control


Generally not supplied as separate documents. Requirements maybe in other documents or specifications. Interfaces controlled by ICDs and drawings

Requirements in other documents or specifications. Interfaces controlled by ICDs and drawings

General Design & Interface Requirements (GIRD)

Interface Requirements Document (IRD)

Verification Requirements Document

Generally not supplied. Generally not supplied.


35



Resource budgets (power, mass, consumables, etc.)

All Documents (and subsequent changes) under CSA and contractor Configuration Control


All Documents (and subsequent changes) at least under CSA configuration control

Particularly in Class C & D programs, some of these documents may be written collaboratively between Client and Contractor.

Contractor configuration control, perhaps with CSA assistance

Requirements Documents provided by CSA (cont.)

Interface Control Drawings/Document

Planetary Protection requirements

Contamination Control requirements

Required TPMs/KPPs

Contractor's Compliance Matrix to above requirements documents.

Required Required May be required Normally not required

Plans and Procedures provided by the Contractor

Training and Logistics Plan

Deliverable as per SOW CDRL. For CSA Approval.

Under Contractor CADM control.

Deliverables also under CSA CADM control.

Deliverable as per SOW CDRL. For CSA Approval.

Under Contractor CADM control

Deliverable as per SOW CDRL. For CSA Approval or Review.

May be under Contractor CADM control

Deliverable as per SOW CDRL. For CSA Review or Acceptance

May be subject to CSA review.

Operational modes

EMC test procedures

Vibration/acoustics/shock Test Plan

Vibration/acoustics/shock Test Procedures

Thermal T-V Test Plan

Thermal/T-V Test Procedures

Dynamic Balance Test Procedure

Handling & Shipping procedures

Integration Plans

Integration Procedures

Planetary Protection plan


36



Contamination Control Procedures

Plans and Procedures provided by the Contractor (cont.)

Calibration Test Procedures

Software Development Plan

Assembly, Integration & Test Plan

Verification Plan(s)

Budgeting etc. Documents provided by the Contractor

Verification Matrix Deliverable Documents as per SOW CDRL. For CSA Approval

Deliverable Documents as per SOW CDRL. For CSA Approval

Deliverable Documents as per SOW CDRL. For CSA Approval or Review

Possible deliverable Documents as per SOW CDRL. For CSA approval or Review.

Some of these tracking documents may be combined.

Risk identification & tracking

Resource budget tracking

TPMs

Error budgets

KPPS

Analyses and Reports provided by the Contractor per CDRL.

(Limited list. Dependent on the Program type and complexity, many other reports and analyses may be generated.)

Optical analyses (ray traces, etc.) as applicable

Deliverable Documents as per SOW CDRL (Remainder retained by Contractor). For CSA Approval,r Review or information dependent on document type

may be subject to CSA review.

Policies/arrangements for document retention and availability at the Contractor’s premises will have to be established.

For class C/D expecting less documents for approval and more for information.

Radiation analyses

EMC analyses

EMC test results

Fracture control analyses

Thermal models & analyses

Finite Element Model analyses

Worst Case Analyses

Technology Readiness and Risk Assessment Report


37



Contractor Drawings and Specifications, etc. (Limited list, many other items may be generated.)

Interface Control Drawings

Deliverable as per SOW CDRL, e.g., as part of EIDP. For CSA Approval or Review



Review or Acceptance

Deliverable as per SOW CDRL, e.g., as part of EIDP. For CSA Approval Review or Acceptance

Documents with data needed by external parties (Interface drawings, calibration data, etc.) require greatest scrutiny.

Lower-tier documents non-deliverable, but policies/arrangements for document retention and availability at the Contractor’s premises for use during mission operations or future programs will have to be established.

Parts and materials SCDs

Reliability Analyses

As-designed drawings

System Specification

Unit Specifications

Software Specifications

As-built drawings

Calibration test results

End-Item Data Package


38

D SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP) - MISSION TAILORING GUIDELINES

TABLE D-1 – SEMP REQUIREMENTS PER MISSION CLASS

Note that many entries mirror those in Table A-1 (SE Methods and Practices per Mission Class). The term “Systems Engineer” is used in a general sense to indicate either the lead systems engineer, a particular systems engineer (or engineers), or the systems engineering function.

CA-SE-PL-0001

Paragraph Number

Title Class A

Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

N/A Type per NASA NPR 8705.4 Human Space or Large Science/Robotic Missions

Non-human Space or Science/Robotic Missions

Small Science or Robotic Missions

Smaller Science or Technology Missions (ISS

payload)

N/A Type per CSA-PIP-GDL-0001 Earth observation satellite, deep space,

human rated

Smallsat, operational microsat, ISS external

payload

Scientific or academic Microsat, ISS internal

experiments

Stratospheric Balloons, academic nanosats, grants

and contributions

3 PROJECT OVERVIEW Title

3.1 Mission Description

General paragraphs 3.2 Project Objectives and

Constraints

3.3 System Description

3.4 Project Phases and Reviews As per SE Methods & practices (AD-02) para. 3.1.

These Programs may simplify Phases and reduce number of reviews (see Table B-1)

4 APPROCHES AND TECHNIQUES

Title/Introduction See of Table A-1, para. 5.2.5.1.

4.1 Systems Engineering Process Implementation of SE Methods and Practices will be modified to match Mission Class per Table A-1.

4.2 SE Management And Control Descriptive paragraph

4.2.1 SE Management Descriptive paragraph; see also Table A-1, para. 5.2.1.

4.2.2 Technical Organization Complexity of Technical Organization will largely depend on program size, but will also be affected by required formality, e.g., Class C/D programs will require fewer, but more focussed technical staff.

4.2.3 Responsibility Allocation Responsibilities will be modified according to mission class. In Class C/D missions, much responsibility will be delegated from CSA to contactors and scientists.


39

CA-SE-PL-0001

Paragraph Number

Title Class A

Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.2.4 Systems Engineering Working Group (SEWG)

Not used at CSA. Only applicable to very large programs where CSA may be members of external partner SEWGs.

4.2.5 Reporting Technical Reviews and Audits

Introduction

4.2.5.1 Progress Monitoring Extent and formality will depend on mission class and program size.

4.2.5.2 Technical Reviews See also Table B-1. RIDs not normally used.

4.2.5.3 Technical Interchange Meetings

Explanatory para. TIMs useful in all programs and will largely replace formal reviews in Class C/D programs.

4.2.5.4 Configuration Audits Explanatory para. Formal configuration audits unlikely; S&MA choice

4.2.5.5 Contractors’ Systems Engineering Capability Assessment

Usually performed by assessing Contractor’s SEMP. Audits by CSA unlikely.

SEMP optional. Statement of compliance to CSA SE Methods and Practices required Not usually required

4.2.5.6 Contractors’ SEMPs Review Only large programs likely to have Contractor SEMP. Others may have section in Program plan.

4.2.6 Design and Development Plan CSA no longer practises Concurrent Engineering

4.2.7 Technology Readiness Levels Process is described in CSA-SE-GDL-0001. See also Table A-1, para. 5.2.7.

4.2.8 Interface Management Generally applicable to all classes. See also Table A-1, para. 5.2.8.

4.2.9 Technical Performance Measures Management

Formal tracking processes and documentation required and should be described.

Tracked and reported as part of routine systems engineering progress monitoring

4.2.9.1 Technical Performance Measures

4.2.9.2 TPM Parameters

4.2.9.3. Implementation of the TPM Process

4.2.9.4 TPM Variances Impact on Cost and Schedule

4.2.9.5 Higher-level System TPM

4.2.10 Environmental Engineering Intrinsic Systems Engineering responsibility for all classes, but unlikely to be a designated activity in CSA programs


40

CA-SE-PL-0001

Paragraph Number

Title Class A

Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.2.11 Human Factors Engineering Crew safety, procedures, etc. will be rigorously controlled in human-rated programs.


Important consideration for ISS payloads, otherwise Intrinsic Systems Engineering responsibility where applicable


4.2.12 Software Development May require formal Software Engineering Management Plan

Formal Software Engineering Management Plan not required

4.2.12.1 Software Documentation Required as per CSA-SE-PR-0001 Table 5.3 Guidelines

Less formality required, dependent on mission

4.2.12.2 Software Development Planning




4.2.12.3 Software Implementation and Verification Planning




4.2.12.4 Software Activities Formal tracking processes and documentation required

Tracked and reported as part of routine systems engineering progress monitoring (see CSA-SE-PR-0001, 4.2.5.1)

4.2.13 Schedule and Cost Activities are Intrinsic Systems Engineering responsibility for all classes. All Mission Classes may require Design-to Cost and Life Cycle Costing. Concurrent Engineering is not employed within CSA, but can be used by Contactors or other participants for all Classes, and can be very effective in small programs.

4.2.13.1 Schedule SE schedule established in SDP

Schedule control and reporting are intrinsic SE tasks

4.2.13.2 Cost Effectiveness Cost-effectiveness consideration is intrinsic SE task and trade-off studies may be implemented in all Mission Classes

4.2.13.3 Design-to-Cost Implementation is complex in large projects, and cost will be traded against performance, which generally has higher priority

May be forced on smaller projects, even at the expense of performance

4.2.13.4 Life Cycle Cost See para. 5.2.13.4 of Table A-1

4.2.14 Risk Management Programs will likely require a formal Risk Management Plan and tracking

Part of routine SE and Project Management activities


41

CA-SE-PL-0001

Paragraph Number

Title Class A

Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.2.14.2 Risks Classification and Quantification

As per Risk Management Plan Part of routine SE and Project Management activities 4.2.14.3 Risks Mitigation

4.2.14.4 Risk Items and Actions Maintenance

4.2.15 Procurement Title

4.2.15.1 Requests for Proposals

Routine SE duties

4.2.15.2 Proposals Evaluation

4.2.15.3 Procurement Support

4.2.16 Documentation Title

4.2.16.2 CDRL and DIDs Routine SE duties; formality will depend on program class

4.2.16.3 Documents Review

4.2.17 Configuration Management SE will use CSA CADM.

Will usually rely on Contractor CADM, with CSA assistance if desired.

4.2.17.1 Configuration Baseline Content

Formal configuration control will be applied Configuration control not formally applied, but must be maintained with careful SE/CADM oversight.

4.2.17.2 Change Management Formality of activity will depend on CADM procedures implemented

4.2.17.3 Contractor's Change Process

4.3 REQUIREMENTS ENGINEERING

Descriptive lead-in paragraph. Requirements Generation Process in Fig. 5.2 is generally applicable to all programs. Smaller programs may simplify orcombine MRD and SRD

4.3.1 Requirements Generation General paragraph.

4.3.1.1 Mission Requirements

Extent and timing of activity will depend on mission requirements and complexity. Formal traceability only needed for large Class A/B missions. Documentation tailored to Mission Class, see Table B-1.

4.3.1.2 Operations Requirements

4.3.1.3 Systems Requirements Document


42

CA-SE-PL-0001

Paragraph Number

Title Class A

Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.3.1.4 Subsystems/Element Specifications

4.3.1.5 Software Requirements Development

4.3.1.6 Mission Conceptual Design

4.3.1.7 Preliminary System Conceptual Design

4.3.1.8 System Conceptual Design

4.3.1.9 Preliminary Concept of Operations

4.3.1.10 Concept of Operations

4.3.1.11 Test Requirements

4.3.2 Requirements Maintenance Process applicable to all missions. Requirements Maintenance Plan and formal traceability and configuration control only needed for large Class A/B missions

4.4 REQUIREMENTS ANALYSIS, FUNCTIONAL ANALYSIS/ALLOCATION AND SYNTHESIS/DESIGN

Generic activity, carried out to some extent in all programs

4.5 MANUFACTURE, SOFTWARE AND AIT

Title

4.5.1 Manufacturing

SE review and approval of documents and activities applies to all programs. Formal documentation mostly in Class A/B programs. See Table C-1.

4.5.2 Software Development

4.5.3 Assembly, Integration and Test

4.5.3 Handling, Storage and Shipping

4.6 VERIFICATION Introductory para.

4.6.1 Verification Strategy and Verification Plan

Formality of process will depend on Mission Class and program parameters. Requirements Verification Matrix, Requirements Compliance Matrix, and Software Verification Plan required only for large Class A/B missions


43

CA-SE-PL-0001

Paragraph Number

Title Class A

Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.6.2 Space Environmental Qualification Program

Verification and Model Philosophy will depend on Mission Class and program parameters

4.6.3 Verification Process Principles apply to all programs. Formality of process will depend on Mission Class and size of program. Verification Plan and Report required only for large Class A/B missions. Optional for class C/D.

4.6.4 Verification Categories Title

4.6.4.1 Requirements Verification

Review, monitoring, and support to these activities applies to all programs. Level of effort and formality will depend on Mission Class and program parameters

4.6.4.2 Factory Acceptance Testing

4.6.4.3 Deployment Verification

4.6.4.4 End-to-End System Testing

4.6.4.5 Operational and Disposal Verification

4.6.4.6 Product Assurance Verification


4.6.5 Verification Implementation Title

4.6.5.1 Verification Execution Monitoring activities apply to all programs. Level of effort and formality will depend on Mission Class and program parameters.

4.6.5.2 Verification Documentation

The Systems Engineer will review all verification documents. Extend and formality of documentation will depend on program class. See Table C-1.

4.6.5.2.1 Verification and Compliance Matrices

4.6.5.2.2 Verification Test Plan

4.6.5.2.3 Test Specification

4.6.5.2.4 Verification Test Procedures

4.6.5.2.4 Verification Test Reports

4.6.5.3 Verification Test Reviews Systems Engineer will support. Formality of review will depend on program class. See Table B-1.

4.6.5.4 Verification Tools and Simulator Oversight of these activities is an intrinsic SE responsibility. Extend will depend on the mission class and program

parameters. 4.6.5.5 Hardware-in-the-Loop


44

CA-SE-PL-0001

Paragraph Number

Title Class A

Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.6.5.6 Contracts Deliverables Verification

4.7 VALIDATION Lead-in/descriptive paragraph. Formality of process will depend on mission class and size; e.g., Class D validation is normally by operating during the mission itself.

4.7.1 Validation Strategy and Validation Plan

Formal System Validation Plan only required in Class A/B programs.

4.7.2 Validation Process Formal Validation process only implemented in Class A/B programs.

4.7.3 Validation Implementation Title

4.7.3.1 Validation Execution Monitoring activities apply to all programs. Level of effort and formality will depend on Mission Class and program parameters.

4.7.3.2 Validation Documentation

The Systems Engineer will review all verification documents. Extend and formality of documentation will depend on program class. See Table C-1.

4.7.3.2.1 Validation Compliance Matrix

4.7.3.2.2 Validation Test Plan

4.7.3.2.3 Test Specification

4.7.3.2.4 Validation Test Procedures

4.7.3.2.5 Validation Test Reviews

4.7.3.4 Validation Tools and Simulator

Oversight of these tools and any relevant documents is an intrinsic SE responsibility. Extend will depend on the mission class and program parameters.

4.8 SYSTEM ANALYSIS Analyses will be performed to a greater or lesser extent in all programs. Formality and extent will depend on the mission class and program parameters.

4.9 SE INTERFACES SE staff will interface with listed personnel to a greater or lesser extent in all programs. Formality and extent will depend on the mission class and program parameters.

4.9.1 CSA Mission Sponsor SE staff will interface with Mission Sponsor to a greater or lesser extent in all programs. Formality and extent will depend on the mission class and program parameters.

4.9.2 External Stakeholders SE staff will interface with External Stakeholders to a greater or lesser extent in all programs. Formality and extent will depend on the mission class and program parameters.

4.9.3 CSA Project Management Interface

Title

4.9.3.1 Work Breakdown Structure


45

CA-SE-PL-0001

Paragraph Number

Title Class A

Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.9.3.2 Schedule SE staff will support the PM and other listed personnel/functions to a greater or lesser extent in all these activities. Formality and extent will depend on the mission class and program parameters. 4.9.3.3 Cost Estimates

4.9.3.4 Risk Management

4.9.3.5 Procurement

4.9.3.6 Management of Physical Assets

4.9.3.7 Systems Engineering Activities Reporting

4.9.3.8 Problem Resolution

4.9.3.9 Technical Management and Contract Management

4.9.3.10 Formal Reviews

4.9.3.11 Phase Transitions

4.9.4 CSA Engineering Specialists The Systems Engineer will interface with engineering specialists, who are normally participants in all programs to a greater of lesser extent.

4.9.5 Safety and Mission Assurance Interface

The Systems Engineer will collaborate with the S&MA engineer, monitor PA activities, review documents, and lead resolution of technical problems in the activities listed. Formality and extent will depend on the mission class and program parameters. See also Table E-1.

4.9.5.1 Reliability Program

4.9.5.2 Safety Reviews

4.9.5.3 Contractor’s PA Activities

4.9.5.4 Material Review Boards

4.9.5.5 Launch Campaign Reviews

4.9.5.6 Reciprocal Data Exchange

4.9.6 Configuration Management

The Systems Engineer will collaborate with the CM engineer in the activities listed. Formality and extent will depend on the mission class and program parameters. See also Table E-1.

4.9.6.1 Functional and Physical Architecture

4.9.6.2 CIs Identification



46

CA-SE-PL-0001

Paragraph Number

Title Class A

Class B


Missions)

Class C


(e.g., ISS Payload)

Class D

4.9.6.4 Configuration Review Board/Configuration Control Board

4.9.6.5 Change Management

4.9.7 Operations and Logistics Interface

Title

4.9.7.1 CSA Operations Planning

The Systems Engineer will participate in the activities listed. Formality and extent will depend on the mission class and program parameters. In general these specific activities/documents only apply to class A/B programs, although the SE will be involved in operations and logistics planning as described in Section 4.8.7 of AD-02.

4.9.7.2 Operations Plans Support

4.9.7.3 Logistic Support Analysis

4.9.7.4 Operations Documentation and Reviews

4.9.7.5 Launch and Early Orbit Phase (LEOP) Support

4.9.7.6 Commissioning, Operations and Utilization

4.9.7.7 Launch Services Provided Relations

4.9.7.8 Routine Operations Support

4.9.7.9 Decommissioning

4.9.8 Contractor Relations The Systems Engineer will maintain relations with his Contractor counterpart(s) in the activities listed. Formality and extent will depend on the mission class and program parameters


47

E CSA PROJECT RISK CLASS DEFINITIONS1

TABLE E-1 – CSA PROJECT RISK CLASS DEFINITIONS

(for reference only)

Parameter Class A (Typical) Class B (Typical) Class C (Typical) Class D (Typical)

Outcome(s)2 Data services,

OGD Operations, Quality of Life to Canadians,

International Partnerships

Same as for Class A or C Technology demonstration (with operations), scientific

research.

HQPs, characterization, technology demonstration

(non-operational).

Risk to Safety3 High if control process fails. Safety Hazard control is

absolutely required.

Medium to High Low to Medium Very Low to Low

Risk of Mission Failure Very Low, through redundancy, extensive testing,

rigorous S&MA

Low, through redundancy, testing, S&MA

Medium, limited redundancy, testing and S&MA budget

limited

High, negligible redundancy. Little or no testing and S&MA

Impact of Loss4 National strategic,

International Partners relations

WoG stakeholders capabilities CSA plans and priorities Limited to CSA Branch

Mission Complexity Very High to High High to Medium Medium to Low Medium to Low

Design Life >5 years 3-5 years 1-3 years < 1 year

Required and/or Availability requirement

High, linked to mission success

Medium to High Low to Medium Low or Undefined

Ownership of Residual Risk (Operational)

Mostly or all Government Mostly Government Mostly Industry (or Academia) N/A

Examples (typical) Earth Observation Satellite, Deep Space, Human-rated

Smallsat, operational microsat. ISS external payload

Scientific or academic microsat. ISS internal

experiments

Stratospheric balloons, academic nanosats, grants and

contributions.

1 These are not rigid definitions, but should be used as a guide to determine the Mission Class and hence the Project Management, Systems Engineering, and S&MA approaches to be used. This table is for reference only, the PIP guidelines take precedence. 2 As identified in CSA’s pre-project business case. 3 Safety refers to: human life, public and private property, and the environment. 4 “Loss” in this context means an unrecoverable failure which adversely affects outcomes.


48

F CSA S&MA MISSION CLASSIFICATION MATRIX

F.1 S&MA MATRIX PER MISSION CLASS

Table F-1, below, has been copied from CSA-PIP-GDL-0001, IR-Draft, Project Classification System (AD-01), for reference when reading this document. The version in the latest revision of the Project Classification System document shall be used for program definition purposes.

TABLE F-1 – S&MA LEVELS MATRIX

(for reference only)

S&MA Element S&MA Sub-Element Class A

(Typical)

Class B

(Typical)

Class C

(Typical)

Class D

(Typical)

Pre-contract CSA verifications1

ISO 9001 or AS-9100 Quality Management System (QMS)

Third-party certification for full2 supplier chain

Third-party certification for Prime and Tier 1 Subs

Third-party certification for Prime only

N/A

Process and capability audit by CSA

Prime Contractor and Tier 1 Sub-Contractors

Prime Contractor and Tier 1 Sub-Contractors

Prime Contractor only N/A

Audit action plan Binding Contractor action plan and timeline to address CSA audit observations N/A

Product Assurance Requirements (PAR)

CSA Baseline PAR RCM-type PAR Science Mission PAR Microsat PAR Safety req. only

PAR approval and change authority

CSA CSA CSA N/A

PA CDRLs PA CDRLs Full3 set Full set Reduced3 set Safety + test reports

Technical Reviews

SRR Yes Yes Yes As necessary

PDR, CDR, MRR Unit, sub-system, system Unit, system System, TIMs @ lower-level System, TIMs

Acceptance review Unit, sub-system, system Unit, system System only System only

Review approval right CSA CSA CSA CSA

RIDs Classification, resolution plan, and closure subject to approval of CSA RID owner

Model Philosophy New or Modified Designs EM + PFM or EQM + FM EM + PFM or EQM + FM PFM FM

Space Heritage4 Designs FM FM FM FM

Single string design Single string design/SPF Prohibited Prohibited Prohibited in critical6 apps. Discouraged

Test program Acceptance testing Unit, sub-system, system Unit, sub-system, system System Interface check and

safety verification Qualification testing Unit, sub-system, system Unit, sub-system, system System

Reliability prediction Numerical analysis Yes Yes No No

EEE Parts

Quality Level5 (For SPF and critical6 apps.)

NASA Level 1 NASA Level 2 NASA Level 2

Industrial or automotive grade Quality Level5

(For non-critical6 apps.) NASA Level 2 NASA Level 3 Industrial or automotive

grade

DCL Yes, for CSA approval Yes, for CSA approval Yes, for CSA approval Yes, for CSA approval

NSPARs Yes, for CSA approval Yes, for CSA approval No No

Parts Control Boards Yes Yes Yes No


49

S&MA Element S&MA Sub-Element Class A

(Typical)

Class B

(Typical)

Class C

(Typical)

Class D

(Typical)

Materials

Selection Space-Qualified Space-Qualified Space-Qualified Best practices7

Pure9 Tin Prohibited10 Prohibited10 Prohibited in critical6 apps. Discouraged

Printed Wiring Boards IPC-6012 Class 3/A8 IPC-6012 Class 3/A8 IPC-6012 Class 3 IPC-6012 Class 2

Processes Selection Space-Qualified Space-Qualified Space-Qualified Best practices7

Workmanship NASA 873911 NASA 873911 NASA 873911 Best practices7

CADM

CADM Plan + System Yes Yes No No

Requirement Traceability Yes Yes Yes Yes

Revision Control Yes Yes Yes No

Footnotes:

1. Pre-contract CSA verifications”, although contractor financial capability is verified prior to contract award by Public Services and Procurement Canada (PSPC), for contracts and contractors of all sizes, there is currently no analogous pre-contract award verification of a contractor’s technical capability to deliver upon requirements. This type of verification will set a common understanding of expectations as to targeted areas that need to be resolved early in the project by the contractor in order to retire risk.

2. “Full” supplier chain means the list of suppliers of hardware and software from the prime contractor down to unit-level providers.

3. “Full” set of PA CDRLs corresponds to approximately 25 document types with associated Data Item Descriptions (DIDs), which can each apply to multiple sub-assemblies. “Reduced” set means that some documents are not required (e.g. reliability analysis, NSPARs, CADM plan, etc.) or that the Contractor is required to do the work without having to deliver an associated document to CSA (e.g. the Contractor may have to derate parts and document its work, without having to do so according to a specific format or to produce a document deliverable for CSA review or approval).

4. “Space heritage designs” in this context means properly documented designs that possess evidence of meeting equally harsh (or harsher) testing and operational requirements (i.e. vibration, shock, radiation, thermal, etc.) than those of the actual project.

5. “Quality Level” means parts quality level as defined in NASA’s EEE-INST-002 . ESA equivalences are permitted as specified in the CSA PAR.

6. “Critical application” in this context means an application which is required to meet project outcomes as defined in the project’s business case.

7. “Best practices” corresponds to best practices as set and documented by partner space agencies, or company-owned best practices with demonstrated successful flight heritage.

8. Some relaxation of IPC-6012 Class 3/A is permitted in the PAR, as a result from consultations with Canadian Space Industries.

9. “Pure tin” means tin alloyed with less than 3% of another metal.

10. Space-qualified mitigations will be entertained on a case-by-case basis with a Request for Deviation (RFD) submitted for CSA approval.

11. The PAR defines acceptable ESA and industry equivalents (e.g. J-STD-001 with Space Addendum).

Canadian Space Agency

Documents

Transcript of Canadian Space Agency