9.01 Software Design Principles There is often a need for modification of the software or data components after delivery to correct faults, improve performance, maintain hardware functionality or other attributes, or adapt to a changed environment. The capability is needed in-flight via the uplink command function and prior to launch via the umbilical link. Additionally, software that is modifiable during operation should be protected from unintended modifications including those caused by single event effects, and hardware problems. This design principle includes the following four aspects: None Lessons that appear in the NASA LLIS 439 or Center Lessons Learned Databases.
View this section on the website
See edit history of this section
Post feedback on this section
1. Principle
1.1 Rationale
2. Examples and Discussion
If dual memory units are incorporated in the design, under no circumstances are the prime and redundant memories to be modified concurrently, or before the operational performance of the change is properly assured in a single unit. Care must be taken during the operation to ensure that the code being replaced is not executing at the time of its replacement.
Typically this is done via direct memory compares of the software version ID and checksum during the upload process and during power on self-test/built in test.
Self-modifying code is error-prone as well as difficult to read, test, and maintain.
Inadvertent modification of memory can be caused by unintended over-writing of code areas, execution in data areas, unused areas, and other areas not intended for execution. Wherever possible, features of the processor and/or operating system should be used to protect against incorrect memory use (for example, disabling the “write enable” switch such that writing to protected memory areas causes interrupts). Initializing unused memory to illegal instructions that cause interrupts when executed is a software technique that may also be used. Techniques such as partitioning of code and data help minimize the potential for unintended modification. Such techniques provide isolation between functionally independent software elements and may even reduce the verification effort and increase its fidelity.3. Inputs
3.1 ARC
The flight software architecture should be designed to protect flight software that is intended to be modifiable during flight from unintended modifications.
The flight software design shall provide the capability to upload new software and replace old modules during the mission.
Software shall be designed to protect against incorrect use of memory with the following considerations:
a. Execution in data areas, unused areas, and areas not intended for execution.
b. Unintended over-writing of code areas.
c. The updating of code/software be limited to a single target memory device under user ground control and monitoring at a time. If dual memory units are incorporated in the design, under no circumstances are the prime and redundant memories to be modified concurrently, or before the operational performance of the change is properly assured in a single unit.3.2 GSFC
3.3 JPL
Note: Protection is typically provided by intentionally enabling a write operation before modifying the software; at all other times, write operations are disabled to protect the software from unintended modifications. Unintended modifications can be introduced through configuration management, design, and operations flaws as well as physics.3.4 MSFC
Rationale: To ensure the integrity of the process, all updates to the program of reprogrammable devices, e.g., flight software loads/updates and sequence memory loads, must be verified by a memory readout or checksum readout. Depending on the application and mission/system consequence, single or multiple readouts may be considered. Program here refers to both loading software and configuration files.
Note: Incorrect use of memory such as execution in data areas, unused areas, and other areas not intended for execution, unintended over-writing of code areas. Wherever possible, features of the processor and/or operating system should be utilized to protect against incorrect memory use. For example, disabling the “write enable” switch such that writing to protected memory areas causes interrupts. Software techniques may also be used such as initializing unused memory to illegal instructions that cause interrupts when executed.
Rationale: Techniques such as partitioning of code and data help minimize the potential for unintended modification. It is a technique for providing isolation between functionally independent software elements and may even reduce the verification effort and increase its fidelity.
Rationale: Software design should include the functionality and capability to allow modification of the software or data components after delivery to correct faults, improve performance, maintain hardware functionality or other attributes, or adapt to a changed environment.
Rationale: Validate that the correct software version is loaded into the electronic component
a. No self-modifying code to be used in flight software.
Rationale: Self-modifying code is error-prone as well as difficult to read, test, and maintain.
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. For example, there have been cases aboard the International Space Station in which the computing system’s memory check sum function detected incorrect data loads and enabled isolation and 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.4. Resources
4.1 References
5. Lessons Learned
5.1 NASA Lessons Learned
9.08 Flight Software Modification
Web Resources
Unknown macro: {page-info}
