SSP 50038-Rev C.pdf

SSP 50038

Revision C

Computer-Based Control System Safety Requirements

International Space Station Program

February 2020

EAR 99. This publication does not contain information which falls under the purview of the U.S. Munitions List (USML), as defined in the International

Traffic in Arms Regulations (ITAR), 22 CFR 120-130, and is not export controlled via the ITAR. This publication also does not contain information within the purview of the Export Administration Regulation (EAR), 15 CFR 730-744, and is not export controlled via the EAR. Additional release to the general public requires approval through the appropriate NASA release process.

National Aeronautics and Space Administration International Space Station Program Johnson Space Center Houston, Texas Contract No.: NNJ12GA46C

EXPORT CONTROLLED – See Title Page for more information.

REVISION AND HISTORY

REV. DESCRIPTION PUB. DATE

- Initial Release to meet Product Group Statement of Work costing activities (Approved by NASA Team of Primary Responsibility (TPR))

04-04-94

A Revision A per SSCN 000085

Interim release (Approved by NASA TPR)

12-21-94

B Revision B per SSCN 000261 Eff. 09-16-96 11-17-95

C Revision C per SSCN 15546, Eff. 04-29-2020

For traceability, Requirement Titles were added for deleted requirements.

10-14-2020

EXPORT CONTROLLED – See Title Page for more information.

i

PREFACE

COMPUTER-BASED CONTROL SYSTEM SAFETY REQUIREMENTS

Effective safety for the International Space Station (ISS) dictates that effective control for computers, and the associated software and hardware, be established. The requirements specified herein are considered a minimum set of requirements for computer-based control of systems. Changes to this document will be controlled through the ISS formal change process.

The contents of this document are intended to be consistent with the tasks and products to be prepared by Program participants. Computer-Based Control System (CBCS) Safety Requirements shall be implemented by ISS participants and internal activities for flight computer-based control systems and facilities for the development and maintenance of the flight software.

This document is developed and maintained by the Computer Safety and Software Assurance Branch. SSP 50038, Revision C is established as a Multilateral document requiring approval by the International Partners (Agenzia Spaziale Italiana [ASI], Canadian Space Agency [CSA], European Space Agency [ESA], and Japan Aerospace Exploration Agency [JAXA]). The State Space Corporation Roscosmos [Roscosmos] approval is not required as SSP 50038 does not apply to the Russian Segment, as the Computer-Based Control System requirements for Russia are contained in SSP 50094, NASA/RSA Joint Specifications/Standards Document for the ISS Russian Segment.

The initial baseline release is under the control of the Space Station Control Board (SSCB). The SSCB delegates the control and approval authority for future updates and/or revisions to the Multilateral Safety & Mission Assurance Control Board

(MS&MACB).

See Directive Approval

Willie Lyles

Manager, International Space Station Multilateral

Safety & Mission Assurance/Program Risk

National Aeronautics and Space Administration

DATE

ii

INTERNATIONAL SPACE STATION PROGRAM

COMPUTER-BASED CONTROL SYSTEM SAFETY REQUIREMENTS

CONCURRENCE

FEBRUARY 2020

iii

INTERNATIONAL SPACE STATION PROGRAM

COMPUTER-BASED CONTROL SYSTEM SAFETY REQUIREMENTS

CONCURRENCE

FEBRUARY 2020

iv

TABLE OF CONTENTS

PARAGRAPH PAGE

1.0 INTRODUCTION ................................................................................................................... 1-1

1.1 PURPOSE ............................................................................................................................. 1-1

1.2 APPLICABILITY AND SCOPE .............................................................................................. 1-1

1.3 PRECEDENCE ...................................................................................................................... 1-1

1.4 VERB APPLICATION ............................................................................................................ 1-1

2.0 DOCUMENTS ....................................................................................................................... 2-1

2.1 APPLICABLE DOCUMENTS................................................................................................. 2-1

2.2 REFERENCE DOCUMENTS ................................................................................................ 2-1

3.0 COMPUTER-BASED CONTROL SYSTEM SAFETY REQUIREMENTS .............................. 3-1

3.1 SYSTEM LEVEL CBCS SAFETY REQUIREMENTS ............................................................ 3-1

3.1.1 GENERAL CBCS REQUIREMENTS ..................................................................................... 3-1

3.1.1.1 SAFE INITIALIZATION .......................................................................................................... 3-1

3.1.1.2 SAFE TERMINATION ........................................................................................................... 3-1

3.1.1.3 OFF-NOMINAL POWER CONDITIONS ................................................................................ 3-2

3.1.1.4 ACTIONS FOR OVERRIDE .................................................................................................. 3-2

3.1.1.5 COMMANDS OUT OF SEQUENCE ...................................................................................... 3-2

3.1.1.6 INADVERTENT MEMORY MODIFICATION ......................................................................... 3-2

3.1.1.7 RECOVERY FOR CBCS ANOMALY .................................................................................... 3-3

3.1.1.8 INPUT VALIDATION ............................................................................................................. 3-3

3.1.1.9 FLIGHT SOFTWARE DEVELOPMENT ................................................................................ 3-3

3.1.1.10 FLIGHT SOFTWARE DOCUMENTATION (DELETED) ........................................................ 3-4

3.1.1.11 INTEGRITY CHECK .............................................................................................................. 3-4

3.1.1.12 COMMUNICATIONS SECURITY .......................................................................................... 3-4

3.1.1.13 PREREQUISITE CHECKS .................................................................................................... 3-4

3.1.1.14 SAFETY CRITICAL MONITORING ....................................................................................... 3-5

3.1.1.15 DISARMING AN ARMED COMMAND .................................................................................. 3-5

3.1.2 CBCS MUST WORK/MUST NOT WORK FUNCTION REQUIREMENTS ............................ 3-5

3.1.2.1 CBCS MUST WORK FUNCTION REQUIREMENTS ............................................................ 3-7

3.1.2.1.1 FAULT TOLERANT APPROACH .......................................................................................... 3-7

3.1.2.1.1.1 COMMAND FAULT TOLERANCE ........................................................................................ 3-7

3.1.2.1.1.2 TWO UNIQUE COMMANDS (CRITICAL) (DELETE) ............................................................ 3-8

3.1.2.1.1.3 ONE OPERATOR ACTION ................................................................................................... 3-8

3.1.2.1.1.4 REDUNDANT COMMAND PATH .......................................................................................... 3-8

3.1.2.1.1.5 REDUNDANT COMMAND PATH INDEPENDENCE ............................................................ 3-8

3.1.2.1.1.6 RESPOND TO LOSS OF FUNCTION (DELETED) ............................................................... 3-9

3.1.2.2 CBCS MUST NOT WORK FUNCTION REQUIREMENTS ................................................... 3-9

3.1.2.2.1 FAULT CONTAINMENT APPROACH ................................................................................... 3-9

3.1.2.2.1.1 PREREQUISITE CHECKS (DELETED) ................................................................................ 3-9

3.1.2.2.1.2 REMOVAL OF INHIBIT - FCA ............................................................................................... 3-9

3.1.2.2.1.3 CHANGE OF THE STATE OF INHIBIT - FCA ....................................................................... 3-10

3.1.2.2.1.4 PROVIDE INHIBIT STATUS.................................................................................................. 3-10 v

3.1.2.2.1.5 INDEPENDENT PARAMETER FOR FCA ............................................................................. 3-10

3.1.2.2.1.6 OPERATOR SETABLE PARAMETER FOR FCA ................................................................. 3-10

3.1.2.2.1.7 ONE OPERATOR ACTION ................................................................................................... 3-11

3.1.2.2.1.8 DATA FOR MANUAL SAFING - FCA .................................................................................... 3-11

3.1.2.2.1.9 INDEPENDENT CONTROL OF INHIBITS ............................................................................ 3-11

3.1.2.2.2 THE CONTROL PATH SEPARATION (CPS) APPROACH................................................... 3-12

3.1.2.2.2.1 PROVIDE INHIBIT STATUS.................................................................................................. 3-12

3.1.2.2.2.2 SEPARATE CONTROL PATHS (SCP) ................................................................................. 3-12

3.1.2.2.2.3 CHANGE OF THE STATE OF INHIBIT - CPSA .................................................................... 3-12

3.1.2.2.2.4 INDEPENDENT PARAMETERS FOR SCP .......................................................................... 3-12

3.1.2.2.2.5 OPERATOR CONTROLLABLE PARAMETER...................................................................... 3-13

3.1.2.2.2.6 INDEPENDENT ACTION FOR INHIBITS .............................................................................. 3-13

3.1.2.2.2.7 DISTINCT FUNCTIONALITY FOR SCP ................................................................................ 3-13

3.1.2.2.2.8 SOFTWARE INHIBIT MONITOR (DELETED) ....................................................................... 3-13

3.1.2.2.2.9 DATA FOR MANUAL SAFING - CPSA ................................................................................. 3-13

3.1.2.2.2.10 REMOVAL OF INHIBIT - CPSA ............................................................................................ 3-13

3.1.2.2.3 FAIL-SAFE APPROACH ....................................................................................................... 3-14

3.1.2.2.3.1 PROPAGATION OF FAULTS................................................................................................ 3-14

3.1.2.2.3.2 CONTROLLED SYSTEM FAILURE DETECTION ................................................................. 3-14

3.1.2.2.3.3 FAILURE RESPONSE .......................................................................................................... 3-14

3.1.2.2.3.4 PROVIDE INHIBIT STATUS.................................................................................................. 3-15

3.1.2.2.3.5 INDEPENDENCE .................................................................................................................. 3-15

3.1.2.2.3.6 PROCEDURAL FAULT TOLERANCE .................................................................................. 3-16

3.1.2.2.3.7 TIME TO EFFECT ................................................................................................................. 3-16

4.0 VERIFICATION REQUIREMENTS ........................................................................................ 4-1

4.1 RESERVED ........................................................................................................................... 4-1

4.2 RESERVED ........................................................................................................................... 4-1

4.3 COMPUTER-BASED CONTROL SYSTEM SAFETY REQUIREMENTS .............................. 4-1

4.3.1 SYSTEM LEVEL CBCS SAFETY REQUIREMENTS ............................................................ 4-1

4.3.1.1 GENERAL CBCS REQUIREMENTS ..................................................................................... 4-1

4.3.1.1.1 SAFE INITIALIZATION .......................................................................................................... 4-1

4.3.1.1.2 SAFE TERMINATION ........................................................................................................... 4-1

4.3.1.1.3 OFF-NOMINAL POWER CONDITIONS ................................................................................ 4-1

4.3.1.1.4 ACTIONS FOR OVERRIDE .................................................................................................. 4-1

4.3.1.1.5 COMMANDS OUT OF SEQUENCE ...................................................................................... 4-1

4.3.1.1.6 INADVERTENT MEMORY MODIFICATION ......................................................................... 4-2

4.3.1.1.7 RECOVERY FOR CBCS ANOMALY .................................................................................... 4-2

4.3.1.1.8 INPUT VALIDATION ............................................................................................................. 4-2

4.3.1.1.9 FLIGHT SOFTWARE DEVELOPMENT ................................................................................ 4-2

4.3.1.1.10 FLIGHT SOFTWARE DOCUMENTATION (DELETED) ........................................................ 4-2

4.3.1.1.11 INTEGRITY CHECK .............................................................................................................. 4-2

4.3.1.1.12 COMMUNICATIONS SECURITY .......................................................................................... 4-2

4.3.1.1.13 PREREQUISITE CHECK ...................................................................................................... 4-2

4.3.1.1.14 SAFETY CRITICAL MONITORING ....................................................................................... 4-2 vi

4.3.1.1.15 DISARMING AN ARMED COMMAND .................................................................................. 4-3

4.3.1.2 CBCS MUST WORK / MUST NOT WORK FUNCTION REQUIREMENTS .......................... 4-3

4.3.1.2.1 CBCS MUST WORK FUNCTION REQUIREMENTS ............................................................ 4-3

4.3.1.2.1.1 FAULT TOLERANT APPROACH .......................................................................................... 4-3

4.3.1.2.1.1.1 COMMAND FAULT TOLERANCE ........................................................................................ 4-3

4.3.1.2.1.1.2 TWO UNIQUE COMMANDS (CRITICAL) (DELETED) ......................................................... 4-3

4.3.1.2.1.1.3 ONE OPERATOR ACTION ................................................................................................... 4-3

4.3.1.2.1.1.4 REDUNDANT COMMAND PATH .......................................................................................... 4-3

4.3.1.2.1.1.5 REDUNDANT COMMAND PATH INDEPENDENCE ............................................................ 4-3

4.3.1.2.1.1.6 RESPOND TO LOSS OF FUNCTION (DELETED) ............................................................... 4-4

4.3.1.2.2 CBCS MUST NOT WORK FUNCTION REQUIREMENTS ................................................... 4-4

4.3.1.2.2.1 FAULT CONTAINMENT APPROACH ................................................................................... 4-4

4.3.1.2.2.1.1 PREREQUISITE CHECKS (DELETED) ................................................................................ 4-4

4.3.1.2.2.1.2 REMOVAL OF INHIBIT - FCA ............................................................................................... 4-4

4.3.1.2.2.1.3 CHANGE OF STATE OF INHIBIT - FCA ............................................................................... 4-4

4.3.1.2.2.1.4 PROVIDE INHIBIT STATUS.................................................................................................. 4-4

4.3.1.2.2.1.5 INDEPENDENT PARAMETER FOR FCA ............................................................................. 4-4

4.3.1.2.2.1.6 OPERATOR SETABLE PARAMETER FOR FCA ................................................................. 4-4

4.3.1.2.2.1.7 ONE OPERATOR ACTION ................................................................................................... 4-4

4.3.1.2.2.1.8 DATA FOR MANUAL SAFING - FCA .................................................................................... 4-5

4.3.1.2.2.1.9 INDEPENDENT CONTROL OF INHIBITS ............................................................................ 4-5

4.3.1.2.2.2 THE CONTROL PATH SEPARATION (CPS) APPROACH................................................... 4-5

4.3.1.2.2.2.1 PROVIDE INHIBIT STATUS.................................................................................................. 4-5

4.3.1.2.2.2.2 SEPARATE CONTROL PATHS ............................................................................................ 4-5

4.3.1.2.2.2.3 CHANGE OF STATE OF INHIBIT - CPSA ............................................................................ 4-5

4.3.1.2.2.2.4 INDEPENDENT PARAMETERS FOR SCP .......................................................................... 4-5

4.3.1.2.2.2.5 OPERATOR CONTROLLABLE PARAMETER...................................................................... 4-5

4.3.1.2.2.2.6 INDEPENDENT ACTION FOR INHIBITS .............................................................................. 4-6

4.3.1.2.2.2.7 DISTINCT FUNCTIONALITY FOR SCP ................................................................................ 4-6

4.3.1.2.2.2.8 SOFTWARE INHIBIT MONITOR (DELETED) ....................................................................... 4-6

4.3.1.2.2.2.9 DATA FOR MANUAL SAFING - CPSA ................................................................................. 4-6

4.3.1.2.2.2.10 REMOVAL OF INHIBIT - CPSA ............................................................................................ 4-6

4.3.1.2.2.3 FAIL-SAFE APPROACH ....................................................................................................... 4-6

4.3.1.2.2.3.1 PROPAGATION OF FAULTS................................................................................................ 4-6

4.3.1.2.2.3.2 CONTROLLED SYSTEM FAILURE DETECTION ................................................................. 4-6

4.3.1.2.2.3.3 FAILURE RESPONSE .......................................................................................................... 4-6

4.3.1.2.2.3.4 PROVIDE INHIBIT STATUS.................................................................................................. 4-7

4.3.1.2.2.3.5 INDEPENDENCE .................................................................................................................. 4-7

4.3.1.2.2.3.6 PROCEDURAL FAULT TOLERANCE .................................................................................. 4-7

4.3.1.2.2.3.7 TIME TO EFFECT ................................................................................................................. 4-8

APPENDIX

A ACRONYMS AND ABBREVIATIONS ................................................................................... A-1

B GLOSSARY ........................................................................................................................... B-1 vii

C CBCS REQUIREMENTS APPLICABILITY FLOWCHART .................................................... C-1

D OPEN WORK ........................................................................................................................ D-1

TABLE

D-1 TO BE DETERMINED ITEMS ............................................................................................... D-1

D-2 TO BE RESOLVED ISSUES ................................................................................................. D-1

1-1

1.0 INTRODUCTION

1.1 PURPOSE

Computer-Based Control Systems (CBCS) use computer hardware and software as an integral part of the System Safety Process. CBCS safety is the application of engineering and management principles, criteria, and techniques to provide hardware failure and software error tolerance to minimize risks associated with the use of computers to control hazards.

CBCS requirements will be applied to systems with computer or complex-electronic control whose inadvertent operation, or failure, can result in a critical or catastrophic hazard.

1.2 APPLICABILITY AND SCOPE

These requirements apply to computer-based or complex electronic-based control systems that control a safety-critical process or device. A computer-based or complex electronic-based control system includes any hardware, software, or firmware used to prevent a catastrophic or critical hazardous event, regardless of the media the software or firmware resides on. This includes any Commercial Off the Shelf (COTS) software integrated into the CBCS design.

CBCS requirements are applied at the system level. CBCS requirements do not need to be applied to lower level components, such as sensors or actuators, if system level compliance can be established.

See Appendix C for requirements applicability flowchart.

Revision C of this document applies to CBCS development, maintenance, operations or related activities started after the initial date of issuance.

1.3 PRECEDENCE

In the event of a conflict between the text of SSP 50038, Revision C, and the references cited herein, the text of this SSP 50038 takes precedence. Nothing in this document, however, supersedes the requirements outlined in SSP 51721, ISS Safety Requirements Document. CBCS requirements allocations previously agreed to (e.g., ISS Prime Item Development Spec (PIDS), International Partner (IP) Segment Spec, or SSP 50808, International Space Station (ISS) to Commercial Orbital Transportation Services (COTS) Interface Requirements Document (IRD)) remain unchanged with the release of SSP 50038, Revision C.

1.4 VERB APPLICATION

Every requirement containing a “shall” is binding and must be verified. Goals and statement of facts are nonbinding. Rationales are included for each of the requirements. They are located below the binding requirements and are identified by italics. The rationales are intended to provide clarification, justification, purpose, and/or source of the requirement. It is important to note that the rationales are not binding and

1-2 only provide supporting information. In the event of an inconsistency between the requirement and the rationale, only the requirements shall be binding and take precedence.

2-1

2.0 DOCUMENTS

2.1 APPLICABLE DOCUMENTS

The following documents include specifications, models, standards, guidelines, handbooks, and other special publications. The documents listed in this paragraph are applicable to the extent specified herein. Inclusion of applicable documents herein does not supersede the order of precedence identified in Paragraph 1.3 of this document.

SSP 30309 Safety Analysis and Risk Assessment Requirements Document

SSP 50974 International Space Station Onboard IT Security Requirements for USOS Systems

SSP 50989 International Space Station IT Security Policy for Onboard Systems

SSP 51721 ISS Safety Requirements Document

2.2 REFERENCE DOCUMENTS

The following documents contain supplemental information to guide the user in the application of this document. These reference documents may or may not be specifically cited within the text of this document.

NASA-HDBK 8739.23 NASA Complex Electronics Handbook for Assurance Professionals

NASA-STD 8719.13 Software Safety Standard

SSP 30599

SSP 41000

Safety Review Process

System Specification for the International Space Station

SSP 50808 International Space Station (ISS) to Commercial Orbital Transportation Services (COTS) Interface Requirements Document (IRD)

3-1

3.0 COMPUTER-BASED CONTROL SYSTEM SAFETY REQUIREMENTS

This section defines the requirements for computer-based control of hazards. The approaches identified provide requirements, which will implement the necessary and sufficient hazard controls. These approaches are based on the type of hazard being controlled and are to be applied on a hazard-by-hazard basis.

3.1 SYSTEM LEVEL CBCS SAFETY REQUIREMENTS

A CBCS shall provide hazardous function control where the inadvertent activation or deactivation of the function, or capability, could result in an identified critical or catastrophic hazard. [CBCS-0001]

3.1.1 GENERAL CBCS REQUIREMENTS

This section of the Computer-Based Control System requirements is applied to all CBCS designs, irrespective of function, including those that implement a single control to a hazard.

3.1.1.1 SAFE INITIALIZATION

The CBCS shall safely initialize to a known safe state and no unplanned/spurious signals shall be generated during initialization and mode transitions between must and must not work functions. [CBCS-0010]

Rationale: The intent is to make sure that when initialized, the system cannot initialize to a state that will be unsafe. In this case, a safe state is defined as having no identified hazards present and no active system processes which could lead to an identified hazard. In order to be a “known” safe state the end state must be deterministic.

Methods to achieve this would include Power-On Self-Test (POST) and Built-In-Test

(BIT) functions that check for system health and status as part of initialization.

Additionally, this requirement applies when transitioning between must and must not work states. For example, the initialization or state transition of a vehicle flight control system would be different while docked, versus while in free flight. In the context of a propulsion system, one would not want a system to come up with a fuel/oxidizer valve open while docked. As another example, if memory has been initialized to a null state, then the input and output queues should likewise be empty. Unplanned or spurious signals could be interpreted by the effectors as a command and resulting in unsafe condition and are, therefore, specifically verified not to be present during initialization.

3.1.1.2 SAFE TERMINATION

The CBCS shall perform an orderly termination of a function to a known safe state upon receipt of a termination command or detection of a termination condition. [CBCS-0020]

Rationale: The objective of this requirement is to reduce the potential for a shutdown to cause problems in other parts of the system. The project should develop a list of hazardous effectors and the scenarios in which those effectors are hazardous. The system should place hazardous effectors in a safe state for each particular scenario.

3-2

3.1.1.3 OFF-NOMINAL POWER CONDITIONS

A CBCS shall continue to operate safely, generating no spurious signals, during off-nominal power conditions or contain design features; which safe the CBCS during off-nominal power conditions. [CBCS-0030]

Rationale: The system should be able to operate safely not only during nominal conditions, but also during off-nominal conditions. For example, some power supplies have power conditioning to compensate for over-voltage and under voltage, and, with such conditioning, one would want to protect from brown outs. One would require energy storage in the power supply to enable the avionics to shut down safely. A safe state may mean a state with reduced functionality, until the system can either resume normal operations or a safe power down can be achieved.

3.1.1.4 ACTIONS FOR OVERRIDE

Overrides shall require at least two independent actions by the operator. [CBCS-0040]

Rationale: The two operator actions requirement provides mitigation against unintended activation of the override. Overrides are intended to allow operators to bypass limits or constraints in an off-nominal troubleshooting situation. Due to the inherently hazardous nature of overrides, it is desirable to ensure the operators are fully aware of the consequences in a potentially high risk situation. Because of this overrides should only be used for off-nominal conditions and should be implemented if the hazard being controlled do not exist during the override or if the Time To Effect (TTE) of the hazard allows operational personnel to implement alternate controls. Overrides with respect to this requirement are not equivalent to an inhibit.

3.1.1.5 COMMANDS OUT OF SEQUENCE

Where execution of commands out of sequence can cause a hazard, the CBCS shall reject commands received out of sequence. [CBCS-0050]

Rationale: Rejecting commands received out of sequence is intended to mitigate potential hazards associated with commands issued spuriously or otherwise sequenced improperly. For command sequencing that is part of the hazard control strategy, the computing system may need to implement a strategy in a certain order, and without that order, the system may remain in or enter a hazardous condition.

Note: Commands out of sequence requirement is a specific case of prerequisite checks discussed in Requirement 3.1.1.13.

3.1.1.6 INADVERTENT MEMORY MODIFICATION

A CBCS shall detect and recover from inadvertent memory (includes both temporary and long-term memory) modification while in operation. [CBCS-0060]

Rationale: Memory modifications may occur due to radiation-induced errors, uplink errors, configuration errors, or other causes, so the computing system must be able to detect the problem and recover to a safe state.

3-3

For example, there have been cases aboard the International Space Station in which the computing system’s memory checksum function detected incorrect data loads, enabled isolation, and performed a safe recovery. Memory correction features may be used to enable such a recovery. As an example, computing systems may implement error detection and correction, software executable and data load authentication, periodic memory scrub and space partitioning to provide protection against inadvertent memory modification. For this requirement, memory includes, but is not limited to, Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Erasable Programmable Read Only Memory (EPROM), Electronically Erasable Programmable Read Only Memory (EEPROM), Hard Drive, Solid State Memory and Flash Memory. Where inadvertent memory modification is not correctable, recovery should be an orderly transition to a known safe state.

3.1.1.7 RECOVERY FOR CBCS ANOMALY

A CBCS shall detect and recover to a known safe state in the event of an anomaly within the CBCS. [CBCS-0070]

Rationale: The intent of this requirement is to establish a safe state following detection of incorrect or incomplete processing. TTE concerns may necessitate isolation via error handlers instead of transition to a redundant string/reboot type recovery. Where TTE is not a concern, or is sufficiently long, transition to a redundant string/reboot may be allowable.

A typical anomaly may include events such as: Single Event Upset (SEU), processor miscompare, voted out processor, or unhandled arithmetic exception. They may be environmental (e.g., temperature, radiation) or due to an undetected coding or design error. Interrupt and exception handlers, BIT, watchdog timers, or other mechanisms for determining incorrect or incomplete processing should be implemented. A typical response to an error of this type would include a reset of the effected processor to a predetermined, known, initial configuration (safe state).

3.1.1.8 INPUT VALIDATION

The CBCS shall be capable of discriminating between valid and invalid inputs from sources external to the CBCS and remain or recover to a known safe state in the event of an invalid external input. [CBCS-0080]

Rationale: This requirement ensures that only valid input from external sources is incorporated into the control system state. External input includes commands and data (including new software images), as well as measurements from sensors attached directly to the CBCS. The equipment controllers receiving input, such as commands from external sources, must validate whether the command is a known command and perform parameter limit checking.

3.1.1.9 FLIGHT SOFTWARE DEVELOPMENT

The CBCS developer shall develop safety-critical flight software in accordance with a formal software development process. [CBCS-0090]

3-4

Rationale: The intent of this requirement is to ensure the provider follows a formal software development process when creating safety-critical software. That process should include software requirements definition, design, implementation, verification, maintenance, and retirement phases. It should also incorporate software quality assurance, configuration management, problem reporting and corrective action, reliability, maintainability, safety, verification and validation, independent verification and validation, certification, and operational use of the software.

Note: Software development plans that meet or exceed NPR 7150.2, NASA Software Engineering Requirements or equivalent are considered compliant with this requirement.

3.1.1.10 FLIGHT SOFTWARE DOCUMENTATION (DELETED)

3.1.1.11 INTEGRITY CHECK

The CBCS shall perform integrity checks when data or commands are exchanged across transmission or reception lines and devices. [CBCS-0110]

Rationale: This requirement ensures that the data or commands are not corrupted in transmission and that the data or command that was sent is the same as the data or command that was received. An integrity check ensures the data and commands are well-formed and not corrupted. Typically, this requirement can be met through the selection of communication protocols that include features like Cyclic Redundancy Checks (CRCs), checksums, or hashes.

3.1.1.12 COMMUNICATIONS SECURITY

The CBCS shall meet the requirements of SSP 50974, International Space Station Onboard IT Security Requirements for United States On-orbit Segment (USOS) Systems or equivalent standard for unauthorized access and other security concerns.

[CBCS-0120]

Rationale: This requirement is intended to ensure the security and integrity of communication. This also assures commands are from a valid and trusted source.

A certification of compliance with SSP 50974 or equivalent (e.g., SSP 50989, International Space Station IT Security Policy for Onboard Systems for IPs) demonstrates compliance with this requirement.

Note: This requirement does not require the CBCS to protect against malicious commanding by an authorized trusted source. Nor is it specifically intended to protect audio or video communications. Program/project leadership should assess the need for these protections and establish their requirements accordingly.

3.1.1.13 PREREQUISITE CHECKS

The CBCS shall perform prerequisite checks for the safe execution of hazardous commands. [CBCS-0130]

A. Where a prerequisite check can prevent the execution of a hazardous command, the status of that parameter shall be made available to crew and ground operators.

3-5

B. In cases where the addition of prerequisite checks may increase the risk due to increased complexity or time criticality, the rationale shall be presented to support not applying prerequisite checks for specific hazardous commands.

Rationale: This requirement is intended to ensure the safe execution of hazardous commands by checking that conditions are appropriate to the execution of the command. Examples include state or mode checks, sequential dependencies, sensor or effector state.

3.1.1.14 SAFETY CRITICAL MONITORING

The CBCS provides for automated detection and safing of identified CBCS controlled hazards by:

A. The CBCS shall generate and collect data relating to the operational performance, configuration, status, and failures that impact hazards or hazard controls.

[CBCS-0150-A]

B. The CBCS shall provide automated detection and safing for critical and catastrophic hazards with a TTE of less than 24 hours. [CBCS-0150-B]

Rationale: The purpose of this requirement is to ensure operational insight into system health that affects hazards controlled by the CBCS. It also provides for automated responses for hazards controlled by the CBCS with a short (less than 24-hour) TTE.

The CBCS will need to provide detection, notification, and response for any hazards it controls within the 24-hour TTE. The reason behind this requirement is to minimize the need for crew or ground intervention for a system that is continuous operation.

Note: This would allow for manual safing in cases that the CBCS only provides a portion of the control. In these cases, the CBCS would provide notification that operator action is required.

3.1.1.15 DISARMING AN ARMED COMMAND

Where two step commanding is required, a mechanism for disabling the armed command shall be provided. [CBCS-0160]

Rationale: The purpose of this requirement is to ensure that an accidentally, prematurely or inadvertently armed command does not remain armed indefinitely.

Typical examples would include time-out, a disarm command, or a disarm if the command following the arm is not the fire command.

3.1.2 CBCS MUST WORK/MUST NOT WORK FUNCTION REQUIREMENTS

The following paragraphs provide requirements for Must Work Functions (MWF) and Must Not Work Functions (MNWF). MWF and MNWF requirements are only applied where the CBCS operates more than one of the controls to the hazard. For the MWFs, the Fault Tolerant Approach is focused on ensuring the independence of each of the control strings and protecting against their inadvertent deactivation. For the MNWFs, the Fault Containment Approach (FCA) and Control Path Separation Approach (CPSA) approaches focus on ensuring independence of inhibits and protecting against their

3-6 inadvertent removal, resulting in activation of the MNWF. The Fail-Safe Approach (FSA) focuses on providing an independent capability for identifying anomalous system behavior and performing appropriate safing. The FSA is only applied if there is no MWF associated with the MNWF. A MWF is a function which, if not performed, results in a critical or catastrophic hazard as identified in the hazard reports.

Example 1) Environmental Control – Loss of atmospheric conditioning for temperature, O2 concentrations, and toxin (CO2) removal results in loss of life.

Example 2) Guidance, Navigation, and Control (GNC) - Loss of GNC functions can result in a collision, uncontrolled reentry, or similar hazards resulting in loss of crew and vehicle.

A MNWF is a function which, if performed inadvertently or at an in-opportune time, results in a critical or catastrophic hazard as identified in the hazard reports.

Example 1) Radio Frequency (RF) Transmitter Activation – inadvertent activation of an

RF radiation source while an Extravehicular Activity (EVA) or Visiting Vehicle is present can result in damage to and/or loss of the EVA crewman or vehicle electronics.

Example 2) Inadvertent pyro activation deploy parachutes can result in debris and loss of vehicle return capability.

A function can be both a MWF and a MNWF. MNW functions are frequently MW within a specific window of operation. When a function is both MW and MNW, both sets of requirements are applied.

Example 1) Thruster activation is MW in the context of providing the capability to move a vehicle, but MNW while being grappled by the Space Station Remote Manipulator System (SSRMS).

Example 2) Pyro activation for parachute deploy is MW on descent, but MNW prior to that event.

Another type of function that often does not fit neatly into one of these two categories is the closed loop control system. These systems are often safe while operating within specific constraints, but need to be safe when these constraints are exceeded.

Example 1) SSRMS can safely operate while all the individual joint sensors and motors are operating correctly. When any of these sensors detect an exceedance or fails, it needs to stop motion and raise a critical alarm. This makes the detection and safing of these types of failures MW.

Example 2) Ku-Band (Ku) antenna can radiate safely as long as its masks are not violated. When it is infringing on a mask, it needs to shut down. One approach is to treat the masking function (detect and safe when the mask is violated) as MW.

Alternatively, since there are no MW functions associated with Ku, the MNW Fail-Safe Approach could be used.

3-7

3.1.2.1 CBCS MUST WORK FUNCTION REQUIREMENTS

The requirements of this section are applicable to the design of CBCS functions whose inadvertent shutdown would cause a hazard.

3.1.2.1.1 FAULT TOLERANT APPROACH

A Computer-Based Control System shall be designed such that no combination of two failures, or two operator actions, or one of each will cause a catastrophic hazardous event. No single failure or operator action will cause a critical hazardous event.

[CBCS-MW-FT-0001]

Rationale: For any catastrophic hazard, there is a requirement to be two failure tolerant.

For critical hazards there is a requirement to be one failure tolerant. This requirement and those that follow in this section are intended to establish that the CBCS does not compromise that overall design requirement.

3.1.2.1.1.1 COMMAND FAULT TOLERANCE

Where loss of a function could result in a hazard, the CBCS shall provide the necessary command fault tolerance to disable the function by one of the two methods below:

A. For CBCS with redundant control string(s) active before disabling primary string, one independent and unique command shall be used to disable each control string.

B. For CBCS with redundant control string(s) activated after disabling the primary string, two independent and unique commands shall be required to deactivate/disable the active control string. [CBCS-MW-FT-0010]

Rationale: This requirement ensures that multiple, unique, and independent commands be used when disabling a Must Work Function.

Case A is dependent on a CBCS that uses multiple computers simultaneously to monitor, collect, and perform operational task. This case also represents CBCS that uses one primary computer system at a time, with redundant computer(s) collecting the same sensor and input data as the primary, and can take immediate control of the system if the primary system goes offline. This case also includes backup systems that are powered off, but are powered on and initialized to a known safe state before disabling the primary control string.

Case B is a CBCS that uses a single primary active computer at a time. The redundant backup computer(s) would be powered off or offline and would require time to initialize before it can take primary operational control of the system. In addition, the primary string is required to be disabled before Failure Detection, Isolation and Recovery (FDIR) or manual operator actions may be used to bring backup system online.

Note: A loss of capability could result from the loss of sensor or command input, control processing, or disabling of effector capability. The typical circumstances where a command would be issued to disable a control string to a Must Work Function will be due to a failure or maintenance activities. Otherwise, it is assumed that all redundant

3-8 control strings are available. In addition, FDIR or manual recovery must meet TTE requirements to preclude the hazard.

3.1.2.1.1.2 TWO UNIQUE COMMANDS (CRITICAL) (DELETE)

3.1.2.1.1.3 ONE OPERATOR ACTION

At least one independent operator action shall be required for each operator initiated command used in the shutdown of a function that could lead to a hazard.

[CBCS-MW-FT-0030]

Rationale: This requirement protects against disabling redundant control strings by protecting against the scripting or combining of the “unique and independent” commands together, such that multiple commands can be issued by a single operator action.

Note: This requirement does not apply to on orbit system-initiated FDIR responses.

3.1.2.1.1.4 REDUNDANT COMMAND PATH

Where the software provides the sole control for safety-critical Must Work Assembly Functions, another non-identical method for commanding the function shall be provided.

[CBCS-MW-FT-0040]

Rationale: This requirement is intended to assure that time critical and safety-critical commanding can be completed in the presence of a failure of the nominal command path. This requirement is applied if the TTE of the hazard precludes the ability to return the software to proper operation or similar operational workaround. Ideally, the non-identical command path should be completely divested from the nominal command path

(e.g., a hardwired control switch versus a 1553 command path). At a minimum, it should include a different command source and path (e.g., Controller 1 over Command Bus 1 vs dissimilar Controller 2 over Command Bus 2).

Note: For the purposes of software upgrades, a means of reverting to a prior version should be provided.

3.1.2.1.1.5 REDUNDANT COMMAND PATH INDEPENDENCE

Alternate or redundant functional paths shall be separate or protected, such that any single credible event which causes the loss of one functional path will not result in the loss of the redundant functional path. [CBCS-MW-FT-0050]

Rationale: This requirement assures that the redundant command paths established under Requirement 3.1.2.1.1.4 are not subject to a single event which can result in the failure of multiple paths.

3-9

3.1.2.1.1.6 RESPOND TO LOSS OF FUNCTION (DELETED)

3.1.2.2 CBCS MUST NOT WORK FUNCTION REQUIREMENTS

The requirements of this section are applicable to the design of CBCS functions whose inadvertent operation would cause a hazard. Within Section 3.1.2.2, CBCS MUST NOT WORK FUNCTION REQUIREMENTS, the provider applies one of these approaches:

• 3.1.2.2.1 FAULT CONTAINMENT APPROACH,

• 3.1.2.2.2 THE CONTROL PATH SEPARATION APPROACH (CPSA)

• 3.1.2.2.3 FAIL-SAFE APPROACH

Rationale: The requirements of this section are applicable to the design of CBCS functions whose inadvertent operation would cause a hazard. There are three approaches to MNWF compliance: Fault Containment, Control Path Separation, and Fail-Safe.

The CBCS provider may choose any one of these three approaches for their MNWF.

The emphasis of Fault Containment is on having independent computers control the removal of each inhibit. The Control Path Separation approach allows independence to be established within a given processor by using a distinct logical separation. The Fail-

Safe approach establishes a fault-tolerant capability for independently identifying system control errors and providing active safing. Fail-Safe is generally applied to systems that have closed loop control: e.g., robotic systems. Additionally, Fail-Safe approach should not be applied to systems that are also Must Work.

Note 1: The reference to inhibit below apply to inhibits used to control a hazard per the hazard reports.

Note 2: For Fail-Safe designs, it should be considered a design goal to minimize computer-to-computer interactions in order to minimize the complexity of detection and failure responses.

Note 3: For Must Not Work Functions, the provider may choose to implement an independent (no common software code, data, sensors, or processors allowed) Failure Tolerant solution rather than applying one of these approaches.

See SSP 51721 – Catastrophic Hazards and Critical Hazards Requirements

3.1.2.2.1 FAULT CONTAINMENT APPROACH

3.1.2.2.1.1 PREREQUISITE CHECKS (DELETED)

3.1.2.2.1.2 REMOVAL OF INHIBIT - FCA

A unique command shall be required to remove each of the inhibits.

[CBCS-MNW-FCA-0020]

Rationale: Unique commands for the removal of each inhibit ensure that a single command cannot affect more than one inhibit. This ensures failure tolerance with respect to commanding of the inhibits.

3-10

3.1.2.2.1.3 CHANGE OF THE STATE OF INHIBIT - FCA

Commands to change the state of inhibits shall be unique for each state.

[CBCS-MNW-FCA-0030]

Rationale: This requirement prohibits a use of a single command to toggle an inhibit between enabled and disabled. This assures that any commands to either open or close an inhibit are deliberate. E.g., A single command that could either open or close an inhibit regardless of its current state would be prohibited under this requirement.

3.1.2.2.1.4 PROVIDE INHIBIT STATUS

For inhibits used to control hazards, the CBCS shall make available to the crew or ground operators the status of monitored inhibits. [CBCS-MNW-FCA-0040]

Rationale: Inhibits used for the control of hazards are safety inhibits. The status of these inhibits, whether they are on or off, is necessary for the safe operation of the vehicle.

It allows the vehicle operators, crew and ground operators, to know whether these inhibits are correctly set or not.

Note: Per SSP 51721- MONITORING – MONITOR CAPABILITIES REQUIREMENTS.

3.1.2.2.1.5 INDEPENDENT PARAMETER FOR FCA

Where hazardous commands can be initiated by a hard-coded automated sequence, a separate, functionally independent parameter shall be checked before issuance or execution of each hazardous command. [CBCS-MNW-FCA-0050]

Rationale: As an exception to the prohibition against combining inhibit removals into scripted sequences, it is sometimes necessary to combine these commands in order to provide time critical automated recovery capability. When this is done, those commands are required to provide this independent parameter check. The separate, functionally independent parameter check is needed to ensure that, before the hazardous command is executed or issued, conditions are appropriate for the safe and necessary execution of the hazardous command. It is a way of reducing the risk of an incorrect execution and to verify that the automated sequence will not create additional hazards.

Note: Where a prerequisite check can prevent the execution of a hazardous command, the status of that parameter should be made available to crew and ground operators.

3.1.2.2.1.6 OPERATOR SETABLE PARAMETER FOR FCA

Where hazardous commands can be initiated by a hard-coded automated sequence, at least one of the functionally independent parameters checked before issuance or execution of a hazardous command shall be operator controllable.

[CBCS-MNW-FCA-0060]

Rationale: The operator’s settable…