canadian space agency
TRANSCRIPT
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
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
v
REVISION HISTORY
Rev. Description Initials Date
IR Initial Release (Released for use with LEAP as a test case)
JRB July 2020
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
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)
CSA-SE-GDL-0001 Initial Release
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/
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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
Unit, sub-system, system
System Functional +
Interface check and safety verification
Qualification testing
(Functional, environmental)
Unit, sub-system, system
Unit, sub-system, system
System Limited or None
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
18
APPENDICES
CSA-SE-GDL-0001 Initial Release
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
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 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
CSA-SE-GDL-0001 Initial Release
20
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
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
CSA-SE-GDL-0001 Initial Release
21
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
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
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
Can use existing CSA or Contractor documents.
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.
CSA-SE-GDL-0001 Initial Release
22
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
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
CSA-SE-GDL-0001 Initial Release
23
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
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
CSA-SE-GDL-0001 Initial Release
24
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
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
CSA-SE-GDL-0001 Initial Release
25
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
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
CSA-SE-GDL-0001 Initial Release
26
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
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
CSA-SE-GDL-0001 Initial Release
27
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
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
CSA-SE-GDL-0001 Initial Release
28
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
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
CSA-SE-GDL-0001 Initial Release
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)
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)
Required (system level)
Required (system level)
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
TIMs at lower levels
Recommended. Could be TIMs
Test Readiness Review (TRR)
Required at system, sub-system and unit levels
Required at system, sub-system and unit levels
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)
Required (system level)
Required (system level)
Required (system level)
Recommended (system level)
Formality of the meetings will depend on the program scope
CSA-SE-GDL-0001 Initial Release
30
Mission Phase Review Title Class A Class B Class C Class D Notes
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)
Required (system level)
Required (system level)
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)
Required (system level)
Required (system level)
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
TIMs at lower levels
Required. Could be TIMs or HRMs
Also held during Phase C for Engineering and Development Models and Prototypes
Flight Readiness Review (FRR)*
Required (system level)
Required (system level)
Recommended. Usually combined
Could be combined with AR
Operations Readiness Review (ORR)*
Required (system level)
Required (system level)
Pre-Shipment Review (PSR) Required (system level)
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)*
Required (system level)
Required (system level)
Required (system level)
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)*
Required (system level)
Required (system level)
Recommended (system level)
Could be TIM Held at the beginning of Phase E, after the LEOP and commissioning
Decommissioning Review (DR)*
Required (system level)
Required (system level)
Required (system level)
Could be TIM Held at the end of Phase E
CSA-SE-GDL-0001 Initial Release
31
Mission Phase Review Title Class A Class B Class C Class D Notes
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
Non-flight equipment only
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.
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
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
Applicable as specified in SOW
Applicable as specified in SOW
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
CSA-SE-GDL-0001 Initial Release
34
Systems Engineering Requirement
SE Document Class A Class B Class C Class D Notes
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
All Documents (and subsequent changes) under CSA and optionally 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.
CSA-SE-GDL-0001 Initial Release
35
Systems Engineering Requirement
SE Document Class A Class B Class C Class D Notes
Resource budgets (power, mass, consumables, etc.)
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.
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
CSA-SE-GDL-0001 Initial Release
36
Systems Engineering Requirement
SE Document Class A Class B Class C Class D Notes
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
CSA-SE-GDL-0001 Initial Release
37
Systems Engineering Requirement
SE Document Class A Class B Class C Class D Notes
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
Deliverable as per SOW CDRL, e.g., as part of EIDP. For CSA Approval or Review
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
CSA-SE-GDL-0001 Initial Release
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
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
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.
CSA-SE-GDL-0001 Initial Release
39
CA-SE-PL-0001
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
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
CSA-SE-GDL-0001 Initial Release
40
CA-SE-PL-0001
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
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
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
Can use existing CSA or Contractor documents.
Can use existing CSA or Contractor documents.
Can use existing CSA or Contractor documents.
4.2.12.3 Software Implementation and Verification Planning
Can use existing CSA or Contractor documents.
Can use existing CSA or Contractor documents.
Can use existing CSA or Contractor documents.
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
CSA-SE-GDL-0001 Initial Release
41
CA-SE-PL-0001
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
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
CSA-SE-GDL-0001 Initial Release
42
CA-SE-PL-0001
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
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
CSA-SE-GDL-0001 Initial Release
43
CA-SE-PL-0001
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
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.4.7 Configuration 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
CSA-SE-GDL-0001 Initial Release
44
CA-SE-PL-0001
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
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
CSA-SE-GDL-0001 Initial Release
45
CA-SE-PL-0001
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
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
4.9.6.3 Configuration Verification
CSA-SE-GDL-0001 Initial Release
46
CA-SE-PL-0001
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
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
CSA-SE-GDL-0001 Initial Release
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.
CSA-SE-GDL-0001 Initial Release
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
CSA-SE-GDL-0001 Initial Release
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).