328
9 OBDH Technology of Lunar Lander
performance requirements of the lunar landing mission and provided a strong support
for integration and miniaturization of the system.
3. On-Orbit Maintenance Design
The OBDH software with high autonomy and flexibility had become a key part
between the ground station and spacecraft operation. In order to ensure that the flight
software could provide safe and continuous service during spacecraft operation up
to several years and even more than ten years, it was indispensable to implement onorbit maintenance of spacecraft software. It meant that the ground station could make
some modification of onboard program which were running on spacecraft, including
some modifications, additions and deletions of the software, or even redefinition,
which could be used to modify the integrated electronic performance based on main
status of the electronic system and overcome the problems encountered in operation,
as well as to eliminate the errors that had not been found and excluded in ground
tests. The requirement for on-orbit maintenance of space software might be proposed
at any time, from the launch of the spacecraft to the end of the mission, in order to
modify the operation to satisfy the updated status after launch, or to satisfy any new
requirement added at any time during flight mission, as well as remedial measures that
might lead to functional failure due to degradation of hardware status after running
for a period of time.
Compared with ground software, on orbit maintenance of onboard spacecraft
software had more constraints, and generally it was not easy to maintain in full
sense. In order to implement on orbit maintenance of flight software, at least the
following conditions should be met:
(1) The architecture of flight software must be easy to maintain.
(2) The operational status of the flight procedure, especially the failure, shall be
known as much as possible for the ground.
(3) The onboard computer shall have sufficient design allowance.
(4) The support of the uplink and downlink channels.
(5) The ground simulation environment.
First of all, the flight software should be design for on orbit maintenance. For example,
the real time multi-task operating system used in OBDH software supports the parallel
software architecture of multi sessions operation, which made the software system
have good disassembly performance. It could be controlled flexibly and activated
any session by ground station when it was confirmed. When a session was wrong
and needs to be suspended, a new program could be injected to replace the original
program in RAM as long as it was temporarily suspended by ground station control.
The function could also be checked by memory unload to verify the old and reloaded
programs and data in memory. It was necessary to copy the program from ROM or
EEPROM to RAM, otherwise it was impossible to update the program. It was also
possible to design the standby process in advance so that the new process could be
loaded and activated to realize the new requirements when it was necessary.
On orbit maintenance referred to that the functional defects of spacecraft system
were corrected by telecommand injection through uplink channel, or the functions of
9 OBDH Technology of Lunar Lander
performance requirements of the lunar landing mission and provided a strong support
for integration and miniaturization of the system.
3. On-Orbit Maintenance Design
The OBDH software with high autonomy and flexibility had become a key part
between the ground station and spacecraft operation. In order to ensure that the flight
software could provide safe and continuous service during spacecraft operation up
to several years and even more than ten years, it was indispensable to implement onorbit maintenance of spacecraft software. It meant that the ground station could make
some modification of onboard program which were running on spacecraft, including
some modifications, additions and deletions of the software, or even redefinition,
which could be used to modify the integrated electronic performance based on main
status of the electronic system and overcome the problems encountered in operation,
as well as to eliminate the errors that had not been found and excluded in ground
tests. The requirement for on-orbit maintenance of space software might be proposed
at any time, from the launch of the spacecraft to the end of the mission, in order to
modify the operation to satisfy the updated status after launch, or to satisfy any new
requirement added at any time during flight mission, as well as remedial measures that
might lead to functional failure due to degradation of hardware status after running
for a period of time.
Compared with ground software, on orbit maintenance of onboard spacecraft
software had more constraints, and generally it was not easy to maintain in full
sense. In order to implement on orbit maintenance of flight software, at least the
following conditions should be met:
(1) The architecture of flight software must be easy to maintain.
(2) The operational status of the flight procedure, especially the failure, shall be
known as much as possible for the ground.
(3) The onboard computer shall have sufficient design allowance.
(4) The support of the uplink and downlink channels.
(5) The ground simulation environment.
First of all, the flight software should be design for on orbit maintenance. For example,
the real time multi-task operating system used in OBDH software supports the parallel
software architecture of multi sessions operation, which made the software system
have good disassembly performance. It could be controlled flexibly and activated
any session by ground station when it was confirmed. When a session was wrong
and needs to be suspended, a new program could be injected to replace the original
program in RAM as long as it was temporarily suspended by ground station control.
The function could also be checked by memory unload to verify the old and reloaded
programs and data in memory. It was necessary to copy the program from ROM or
EEPROM to RAM, otherwise it was impossible to update the program. It was also
possible to design the standby process in advance so that the new process could be
loaded and activated to realize the new requirements when it was necessary.
On orbit maintenance referred to that the functional defects of spacecraft system
were corrected by telecommand injection through uplink channel, or the functions of