- Email: [email protected]
Iras Revisited
Copvright © I FAC Automatic Control in Space Toulouse, France. 1'185
IRAS REVISITED F. Teule*, C. Slippens** and
J.
Gourlay***
"' Fllkkrr SI!fI({' /)i ,'i,illll "" '.\'((lillll((1 ..... {'/"(/.\j!fl({· 1.(( IIImlllln (.\'l.R I *" ",/? IIlhl'll",.,1 i.f ... . NI/,·IIIII 1.((/IfImlllril'.l
Abstract. Following the successful IRAS mission, during which many in-flight system reconfigurations had been programmed in the onboard computer, three explicit experiments were defined for in-orbit execution under ESA contract. The first one was a computer memory reconfiguration through which 3 blocks of 16 k 16-bits RAM memory became available for data storage. In the original configuration, 2 blocks of these belonged to the redundant 32k computer system. Since during the operational mission no back-up mode was ever needed, a ROM implemented back-up mode for the normal safe mode was exercized as the second experiment. The surprising result was that the back-up mode was even more accurate than the original Safe Mode, at least for the experiment circumstances. The back-up mode software in ROM was called by RAM software to provide experiment specific data storage in the extended memories. This approach was also followed for the last experiment in which the satellite recovered from a deliberately saturated reaction wheel (23 Nms). From the data storage it was concluded that the satellite unexpectedly tumbled almost three times before stable recovery. The experiment software development and the execution of the experiments forms a valuable experience for future projects. Ke~ords.
Attitude control, onboard computer, onboard software, reconfiguration, satellite, software engineering.
A new series of well defined in-orbit experiments was proposed to ESA to demonstrate extensively and prominently the benefits of reprogrammability and to assess IRAS long term system performance. Eventually, three experiments were selected for execution in the first months of 1985. Following their successful but (in some cases) surprising performance, the IRAS transmitters were switched off on May 9th, 1985. Reactivation of the systems is not expected, however available IRAS still is. The first part of this paper summarizes the IRAS attitude control system, onboard computer and ground systems. Then a definition and functional evaluation of the three experiments is given followed by a definition of the software changes required and an account of the experiment execution experience.
INTRODUCTION On 22 November 1983 IRAS - a JOlnt project by the Netherlands, United Kingdom and United States completed its task of accurately surveying the infrared sky after 300 days of very successful operation. In addition to an almost compl e te sky survey, numerous pointing observations were
executed providing high spatial resolution or spectral information on a selection of specially interesting infrared sources. The satellite was launched into a sun-synchronous, twilight orbit (inclination 99·, altitude 900 km) on 26 January 1983 and operated from Chilton, in the United Kingdom. The satellite's elements were: Infrared Telescope System, built in the USA, a Iso hous ing the so-ca lled "Du tch Add i t iona 1 Experiment". Superfluid helium kept the detector array temperature at 2.4 K during the satellite's operational lifetime. The spacecraft system, built in the Netherlands, providing all supporting functions like power supply, the radio-frequency subsystem, the central onboard computer and data-storage facility, and attitude control.
IRAS Attitude Control
Already during the science mission a number of in-orbit experiments were done to investigate the presence of helium slosh effects, thermal misalignments (Karsten, Teule 1984) and a different control law (Zwartbol 1984).
The Attitude Control System (ACS) design was largely driven by the survey character of the mission, the high control-accuracy requirements and the need to safeguard the cryogenically cooled telescope stringently against irradiation from the Sun and Earth. The attitude control functions were implemented by software in IRAS's central reprogramrnable On-Board Computer (OBC). Each of the redundant OBCs had its own bus interface with the ACS units. One of the OBCs was active, the other on cold stand-by. Separate Attitude-Control Electronics supervised the ACS operations. The ACS software occupied 15 k 16-bit words of memory.
When the science mission was over, all onboard systems still operated without substantial degradation. During the science mission all sorts of in-flight system optimizations had been loaded to the satellite's programmable onboard computer.
Mission-critical functions were stored in ROM and all operational software in RAM. RAM operations were controlled by a Satellite Operations Plan (SOP), which was transmitted to the spacecraft twice a day and defined a l2h period of I .)
76
F. Teu le, C. Sli ppens and
J
Gou rl a\'
IMAGED FOCAL PLANE
, ' , , ,, , '"
"
f'"
+Z
7
,','I
'I:
X
--.-=== ,
P i g .l. lRAS Pine Attitude Calibrations
\I'I\KIII
I tll!'\' \lc)lll ....
r K ·\( 1-..' , (, 11 '-l.(l\j)j
It lIl''''1
""I
~l'
\1))
Dj 1 t \t BI I H ' «()\ I K· ( " I'll \\1 ()'l )
JK '\~ I-..I'\,l,
I
L-_-.,----,,-_.-.J 1\ 11'()",,, 11l 1 1 (,Kol '1)( 0\1\1
"I)
'--------'
I< I 11'" '01 \ '\, Ilc 11' \11 !l l '\, .... \1 I \ r 11 J I DI III \ 11 01'\11"
KO\! I() K \ \\ I(,j{ot
' ...... 111\1 1\ \ I t ! ' ' \!()[)I\
"
"
RX2
-
~
•
\ l l l l l [) J
- - --- -ii,I -- - -
(11', K \ III l" d
le 111' .... '
,'I),
.. ( \1 lHK \ r le)'\, ... /
I!
I ( I [I'" 111'1 K \ 111 )"
0\1\\
(li\~"'-1
K \\\
F i g . 2 . lRAS Att i tude Control Summary
RX l
'IH
' IO\[) I
,[ l il t
..
1)\
!; .~ l~K~r~~' ..... /
FRAME SYNC
BIT SYNC
Fi g . 3 . DUAL
ANALOGUE
TAPE
RECORDERS
I
lRAS Ope r ations Control Centre
I
IRAS Revisited observations. The attitude-control sampling frequency was 2 Hz. The satellite coordinate frame was chosen such that the X-axis coincided with the telescope pointing direction, the Z-axis was perpendicular to the solar panels, and the Y-axis completed the right-handed orthogonal frame. The attitude about the X- and Y-axis was measured by means of a high-accuracy 64"x64" Fine Sun Sensor (FSS). The attitude about the Z-axis (the scan axis) was controlled using a gyroscope. A V-slit star sensor was incorporated in the focal plane of the experiment for regular calibration of the attitude about the scan axis. At each so-called "Fine Attitude Calibration", the cross-scan attitude error (about the Y-axis) was also determined, by comparing the predicted and the measured time intervals between the passages of a star image over a diagonal and perpendicular slit. If the observed cross-scan attitude error was greater than a predetermined value, the calibration result was rejected. Figure 1 illustrates the calibration method. Note that four different slit pairs were present for redundancy and to increase the number of suitable calibration stars on a selected scan track, by effectively doubling the scan-track width. six Coarse Sun Sensors, which together with the Fine Sun Sensor covered the entire celestial sphe re , were used for Sunacquisition and for the detection of eclipses. For eclipse operations, X- and Y-axis gyroscopes were added to the redundant Z-axis gyroscopes. An Earth-horizon sensor (HSE) measured the attitude about the Z-axis during coarse control operations (for Earth acquisition, RAM initialisation and emergencies). As part of the RAM initialisation sequence, the in-scan attitude calculation process was initialised using the Earth's magnetic field as attitude reference (Coarse Attitude Calibration). The attitude-control actuators were three reaction wheels. Excess angular momentum was unloaded by means of magnetic coils. The Earthts magnetic field was measured with a three-axis Magnetometer, these mesurements being used in the unload algorithms and for the coarse attitude calibrations. Figure 2 summarizes the ACS functional modes. Attitude Safeguard During RAM operations, a ROM resident safeguard function checked each second whether the attitude state (attitude and velocity) was such that the attitude would stay within bounds. If this were not the case, an autonomous fallback to ROM control would be initiated. If, when under ROM control, the sun would leave the Fine Sun Sensor field-of-view or the attitude about the Z-axis would exceed its limit, then the ACS hardware (ACE with FSS and HSE) would detect this and signal it to the OBC selection circuitry.
Onboard Computer The lRAS central onboard computer was an LSI-version of the Philips p800 minicomputer with a 32k, 16-bit addressing capability. The memory of the onboard computer consisted of two parts : a 3k ROM and two blocks of l6k RAM. The RAM blocks could be selected such that they occupied address space 3-l6k or address space l6-32k. All data transfers to and from the onboard computer were done using a general-purpose bus via programmed I/O. The interrupt structure of the onboard computer was therefore fairly simple. The onboard software functions were command
77
handling, experiment data handling, housekeeping data handling and transmission, out-of-limits and status checking, and attitude control. Bulk science data storage for lRAS was achieved with onboard tape recorders, but for a quick health assessment data were stored in the onboard computer memory. In addition, there was provision for Special Data Storage for ad hoc monitoring upon ground request. Telemetry For lRAS, there were two types of telemetry, low speed and high speed. The Low Speed Telemetry provided the ground station with a continuous data stream. Every second, a telemetry frame (LSF) supplied information for real-time operations and diagnostic purposes, including: real-time housekeeping data (64 words) command-verification data (64 words) Memory-dump data (128 words) The LSF was sent to the ground both under RAM- and ROM-control. The High Speed Telemetry stream served to transmit the science data stored on the onboard tape-recorder to the ground. This was done about once every twelve hours during a ground-station pass at 1 Mbps. For attitude reconstruction purposes, the stored science data were accompanied (with a frequency of I Hz) by the Basic Frame Data (BFD), which were mainly sensor outputs and onboard status and attitude information. For detailed inspection of the ACS performance during the science mission, the BFD could readily be accessed.
Control Centre The operations control centre was located at the Rutherford & Appleton Laboratories Chilton, England. The principal components of the ground station and Operations Control Centre were (fig. 3): Antenna and associated equipment Receivers and associated equipment Two PDPll/34 computers and peripherals An ICL2960 computer and peripherals There was no direct link between the PDPll/34 computers and the ICL2960 computer. All data transfer was achieved by magnetic tape. The operations carried out on the PDPll computers were : Satellite commanding and data handling Tracking station performance monitoring Computer control of the tracking antenna Connection to keyboardS, tape and disc-units Data transfer into and from the control centre via the NASA communications system Science data sorting and preprocessing using an attached AP120B array processor Interface between P856 onboard-software development computer and the onboard computer. The principal operations carried out on the ICL2960 computer were: Orbit determination and prediction Observation planning and generation of the Satellite Operations Plan for onboard execution (SOP) Preliminary science analysis Engineering data processing
78
F. Teule, C. Slippens and
Engineering Aids The real-time POPll systems allowed real-time sIc operations monitoring during station passes. Also plots could be generated of the real-time telemetry (LSF) received during a pass. Upon request, hexadecimal memory dumps could be provided, either containing the program memory area (for comparison by hand, in addition to the automated memory checks) or special on board databases. The ICL2960 engineering aids became stepwise available within 3 hours after a pass. They were listings of critical events, detailed health and performance figures (also based on trend analysis), histories and tools developed in the course of the mission for special monitoring of unexpected phenomena. Most of these tools could be operated by the sIc engineers themselves for their own needs and selections. And, these products were all in proper engineering units.
lRAS-REVISITEO EXPERIMENTS Sofar, the systems as they have been during the 10 months science mission, have been described. For the three experiments executed under ESA contract from January until April 1985 a series of adaptations to the onboard and ground systems was necessary. First, the Chilton antenna had meanwhile (i.e. after the lRAS operational mission) been modified to control the AMPTE mission satellites. For the lRAS experiments, this meant that High Speed Telemetry could not be accommodated, only Low Speed Telemetry. Also, commanding from the Chilton antenna was not possible due to the AMPTE operations, through which ground stations of the NASA network were required.
These experiments-environmental issues required to extend the onboard memory capacity for data storage (since the onboard recorders stored data only for High Speed Telemetry). In addition to the thus established post factum monitoring means, watch of the experiment execution in real-time was to be provided by NASA stations. In this way, the demonstrations were to be the most available and convincing to the audience. Another circumstance which largely influenced the choice of experiments and the later onboard reconfiguration details, was the absence of the ICL2960 computer at the operations control centre, which played a vital role in SOP preparation, environmental predictions and as evaluation tool. The absence of the ICL2960 together with the depleted helium onboard, made very accurate experiments from the control point of view, impossible. For high accuracy, regular Fine Attitude Calibrations on known star positions (to be predicted by the ICL2960) would have been necessary. For these calibrations the starsensors in the focal plane of the telescope would have been needed, but these were no longer accurate at ambient temperature after helium depletion. The only available computers were the still operational POPll real-time system and, of course, the p856 computer as onboard software development station. In the course of the experiments preparations, additional grounds tat ions appeared not to be available. However, the Chilton antenna was again modified such that commanding of lRAS became poss ib le.
J.
Gourlay
The result was that all experiments have completely been controlled from the Rutherford and Appleton Laboratories. Ground Set-up for Experiments Figure 4 shows the ground system as it was used for execution of the experiments. The main adaptations made to the existing POPll computer tasks were: interface between P856 onboard software development computer and onboard computer, including the former ICL2960 role therein. capability to cope with experiment dedicated memory configuration of 48 k for data storage processing of onboard experiment data and to provide plots special experiment display format for real-time watch of the experiments. This display format was in addition to the about 50 operational display formats used to monitor the different systems in different mission phases. The most prominent new feature was a direct link from the lRAS control centre to ESTEC in Noordwijk, the Netherlands, using existing networks. This link provided a real-time experiment monitoring facility for a long-distance audience.
The in-Orbit Experiments Three experiments were eventually selected for in-orbit demonstration. The first experiment was a reconfiguration of the onboard computer memories. Through this experiment, three blocks of 16 k 16 bits words of memory would become available for data storage during execution of the other two experiments. The memory could be enlarged by switching the redundant, cold standby, computer RAM memories to the active onboard computer. The data storage should be an uninterrupted series from original 16 k data memory to the additional 32 k thus connected. From the test data stored during execution, the complicated software changes needed for the memory extension and related data handling appeared succes s fu 1. The second experiment was to exercise the Back-up Intermediate Control mode (BIC). This ROM mode served as a back-up mode for Intermediate Control which was the Safe Mode in ROM operations. Intermediate Control used the 2-axis Fine Sun Sensor and an earth Horizon Sensor (HSE) for control. BIC was effectively a back-up for the Z-axis only, in case the HSE should fail. BIC uses a gyro for control which is updated at the poles (either earth north pole or south pole) using the Magnetometers to measure the local magnetic field. The problem of reliable pole detection was transfered to detection of the earth equator from the magnetometer outputs; at the poles the magnetic field direction is stable but not its magnitude. At the equator the situation is the reverse. Therefore, a pole crossing is calculated from equator detections. The polar magnetic field orientation is then used to align the satellite telescope axis with it, the telescope boresight oriented outwards. Since the BIC operations were to be monitored in detail using the 48 k extended memory for data storage, controlled by RAM software, the ROM BIC function was to be called by RAM. True ROM operations would not allow for simultaneous data storage under RAM control. From the data gathered after repeated attempts to execute the experiment (all due to unexpected complexities) it could be concluded that the BIC performance was extremely good. The maximum attitude error at the poles was 4 degrees.
IRAS Revisited While the previous experiment was initiated by a simulated hardware error (HSE unhealthy), the third experiment was to demonstrate ROM recovery from erroneous RAM operations due to a simulated, frozen RAM memory cell. The effect of it would be that the RAM unloading function (with magnet coils) uploaded the Z-axis reaction wheel rather than unloading it. Through saturation of the wheel, gradual loss of control would result at which the ROM resident safeguard function would transfer control to ROM operations for recovery. Again, these ROM operations (Intermediate Control and proper ROM unloading) were to be called by RAM for non-interruption of the data storage. From the data storage, a peculiar recovery sequence was observed. Before regaining stable "ROM" control, the satellite almost made three full turns within 30 minutes. Analysis showed that this was mainly due to a much higher angular moment um in th e wheel at saturation (23 Nms) than assumed as part of the experiment definition (14 Nms). Also, some specialities in the ROM recovery algorithms in Intermediate Control were not quite tuned to the particular circumstances of the ex periment. Their design considerations had mainly been in the area of erroneous separation from the
laucher in the beginning of the mission. Figure 5 shows the remarkabl e attitude excursions and the subsequent satisfactory recovery.
IMPLEMENTATION OF EXPERIMENTS
i~l
datastorage takes place). storage address (the address at which datastorage takes place). As said, from the collected data during experiment execution, it was concluded that the memory extension and the new data handling functions were implemented successfully. Back-up Intermediate Control (Experiment 2) Extending on the results of experiment 1, the software for experiment 2 consists of three parts: 1. extending data storage with relevant parameters
2. 3.
implementation of expe riment control comma nd s replacement of the normal RAM attitude control by the relevant ROM attitude control. Part 1 and 2 were straight forward. Several alternatives existed for the implementation of part 3. Finally it was decided t o ca ll the complete ROM attitude control software after the RAM attitude control software, thus ove rruling th e RAM generated torques by the ROM gene rated torques. Advantages are: it is the mo st e l egant and general solution the implementation can be used again with expe riment 3 the attitude co ntro l used is a comp l e t e and tested set of r outines for the d ifferent axes initialisation of switchover should be handled correctly by the existing software Disadvantages are:
Memory Extension and Data Handling (Experiment 1) The additions and adaptations of the onboard software can be divided in thr ee classes. o Da t a storage. A se t of subroutines has been made to use three blocks for data s t orage purposes . The following software baseline was agreed: storage in the form of fixed format message storage in a circular fashion in the
not enough i s known about timing to be sure
that the wheel torques are calculated before they are issued, since the issue is done by a monitor routine at a fixed time within half the second possible int e r ference between ROM and RAM by the use of th e same variables the amount of software used is so large th at no good overview exists, and o nl y by means of
execu tion the system ca n be tested (given the present software developmen t envi r onmen t)
succession I, 2, 3, etc.
storage at a fixed rate (to be change by ground command). o Data dump. The operational IRAS system used 50% of the low speed frame (LSF) for memory dump data. The onboard software automatically included 256 bytes o f memory data in the 1 Hz LSF; In this way th e full memory contents was dumped in 256 second (each LSF contains the memory address of the first byte of dumpdata in that LSF). The memory dump procedure was modified such that after th e PMY dump (adress ~ to 7FFFH) the DMY address range (8000 H to FFFFH) is dumped 3 times, each time with a different memory block. In this way it is possible t o dump the complete onboard memory without commanding capabilities. o Monitoring and commanding. To operate the datastorage software the following commands are defined : start datastorage. This command clears all 3 datastorage memory blocks and consecutively start datastorage in the first byte of the first block. dump datastorage block n. A full memory dump during "IRAS revisited" requires 512 seconds. For short passes it is nec essary that th e present datadump point can be repositioned by the operational crew. The following data is added to the LSF for operational use of the datastorage routines: data storage block (the blocknumber in which
Execution of Ex per iment 2 Th e software modifications were loaded and linked. During the pass the behaviour of the software looked correct, so it was decided t o let the experiment enabled at the end of the pass. Before the next pass, a fallback to ROM and a switchover to the other OBC had occ urred. The situation was reset with a correction in the
on-board software. A new attempt to test, showed a completely different behaviour than the previous time: it looked as if the ROM attitude control under RAM control had become unstable. A fallback to ROM oc c urred . To comp licate the investigation into the sources of the erroneous behaviour, the experiment
monitoring parameters (part of exper im ent 1) in the LSF had disappeared. A systematic check of all parameters used by both ROM and RAM indicat e d that ROM and RAM software used the same name for the same at titude error but differently scaled. Therefore this usage was erroneo us in the situation where both ROM and RAM attitude-control software was operated each 0.5 second. Since in normal operations in RAM, also use i s
made of ROM located r outi nes, the RAM software resets the ROM attitude control mode to zero, because the used routin e would o th erwise react
depending upon that mode. Due t o this feature the first tryout resulted in a co ntinu ous initialisation of the back-up Int e rmediate Control mode.
80
F. Tcule, C. Slippe ns a nd
Recovery from Saturated Wheel (Experiment 3) For this experiment the necessary software is the software created for experiment and 2 extended with some special parts: 1. Finalizing the datastorage with the specific parameters for this experiment. 2. Implementation of SOP related and RAM attitude control state commands. These commands were required by the experiment definition. 3. Experiment sequencer. 4. New satellite safeguard.
Experiment 3 requires the following modes: a. normal mode with incorrect RWLZ speed to saturate the wheel b. ROM attitude control for recovery c. coarse attitude control (without datastorage) The transition to a. is done on ground command. Transition from a. to b. is based on the normal ROM located attitude safeguard. Transition from b. to c. takes place sufficiently long after the previous transition. After the start, the experiment should be executed autonomously. Therefore a special module had to be made that switches the satellite through the different modes. Another software addition is a safety measure. This experiment can only be executed with all available safety measures disabled : the ROM located safeguard had to be disabled. the redundant OBe switch had to be disabled. As the expected manoeuvres of the spacecraft bypassed the expected safety limite a new safeguard had to be made. A safeguard was made allowing complete freedom of rotation around the Z-axis of the spacecraft, when this axis is more or less pointing towards the sun (no coarse sun sensor illuminated). Apart from the above indicated software modules, this experiment uses the data storage and dumping software of experiment 1 and the ROM attitude control, using software of experiment 2. Execution of Experiment 3 After the software for experiment 3 was loaded and activated, the monitoring of the experiment development during the evening showed an error in the stored data. The saturation of the wheel took longer than expected so the experiment was not yet finalized at the last monitor pass, but the satellite had already recovered from the excess wheelmomentum. The satellite was therefore left unattended with the experiment active. During the morning passes the memory would be dumped, so that in morning all data would b e available for evaluation. Evaluation showed th e following errors: errors in the experiment specific data at the termination of the experiment the behaviour of the satellite became anomalous (but safe) showing a large limit cycle around the Z-axis using only maximal torqueing for the Z-whee 1. Both above given phenomena were caused by software errors at the interface between the old and the new software, caused by a redefinition of a variable between experiment 2 and 3. Apart from these two errors, also the behaviour of the spacecraft at recovery was not according to expectations; the satellite rotated twice around the Z-axis, before ROM attitude control was again in control of the attitude of the satellite. The reasons for the different anomalies were found very soon and it was decided to repeat the experiment with corrected software and a new software module added. The new module would limit the reaction wheel speed in the upload phase, so
J.
Courhl\
that the recovery phase would be done without the rotations around the Z-axis. The attempt to start the experiment gave a new surprise; when it was tried to link (activate) the corrected software for the data storage, the satellite fell back to ROM. The other modules could be linked without problems. After several attempts the experiment was activated with the incorrect data storage. Finally the cause for the anomalous behaviour was found. With the preparation of the correct software a procedure error was made that caused an incompatibility between the source version of the OBS, the object version of the OBS and the onboard version of the OBS. (OBS: onboard software). This incompatibility caused the generation of incorrect linkers (i.e. jump instructions to the start of the new module) so that the fallback was caused by a jump to a bitpattern that could not be executed and therefore caused an instruction-trap to ROM (the self protection of the OBe forces the software back to ROM-state in case of non executable instructions). After correction of the object library the last attempt was made to retry the experiment. This time, antenne drive problems caused the first pass to fail completely. The second pass could be taken, but the state of the antenna drive was still critical and the syst e m could break down any moment. Therefore it was decided to reduc e the experiment to a "forced stepwise test" through the different modes on ground command t o show the correctness of the previous incorrect parts. This attempt proved successful.
SOFTWARE DEVELOPMENT Experiment 1 The preparation and e xecution of the experiment showed that in a well structured software system it is possible to make rather complicated changes in a short time and to implement the changes on board with a minimal disrupti o n of the normal operational usage of the satellite. From the experiment executi o n the following estimates for the experime nt impact during normal operational circumstances are derived: the modification could have been produced by the OBS team within 72 hours in case emergency priority were assigned to the project (i.e. maximum effort, documentation to be generated afterwards, etc.) the operational interruption due to the implementation of the mo dification would be less than 2 orbits. Experiment 2 After the successful and smooth execution of experiment 1, the second experiment encountered much more problems: the initial design of the experiment contained two oversights with respect to interrelation (usage of each other parameters) between ROM and RAM attitude control. Unfortunately one was covered by the other, so that at least two successive test sessions were required to determine the problems. ground problems with the definition of certain variables confused the available material. The experiment required the by-pass of RAM and ROM located safeguards, 80 that the only safety measure left was the onboard computer switch.
RI
I RAS Rc\isiled All this led during the experiment preparation to an onboard computer switch-over, and later the use of the search mode for recovery of the satellite. Both situations were not allowed during the operational life of the satellite and could have endangered the health of the satellite.
flexibility. In such operational environments as these for in-flight software changes, computer-aided support for configuration-control becomes mandatory.
REFERENCES Conclusions from the experiment execution are: in ope ratio nal circumstances experiment 2 should no t have been executed given the present (-operational) software development environment, as this mi gh t have endange red the life of the satellite. for a n operational test of the satellite, the safeguard, that had been disabled fo r this experiment, should have been replaced by a special purpose safeguard. software modifications of this n a ture shou ld hav e been tested with special testtools (one axis simulation, env ironmen tal simulator, etc. ) experiment 2 could have been executed safely by only replacing the Z-axis con trol of RAM by the Backup Intermediate Cont r ol algorithm
Holdaway, R. (1983). Infra-Red Astronomical Satellite. JBIS, special issue Karsten, L./Teule, F. (1984). IRAS Thermal Misalignment, a Lesson for the Future. ESA Journal 1984, Vol 8 Zwartbol, T. et al. (1984). Experiments in modern control onboard IRAS. Procee dings AIAA Guidance and Control Conference. Boom, E. et al (1984). In-flight performa nce o f the Attitude Control Syst em of IRAS. Fokker report TR-R-ACS-84-0 1.
Experiment 3 The softwa r e erro r s made at the generat i on of expe riment 3 boiled down to one point; a redefinition of one of the variab le s used for both expe ri ments 2 and 3 of which the consequences were not correctly a nti cipated at all lo cations. The modifications and additions made to th e code generated for expe rimen t 1 and 2 wer e in it se lf rather simple, but the total s tru cture of the code used for the exper iment was in itself so large and comp l ex tha t the made e rror was more o r les s in e vitable. All th e above me ntioned co d e is generated and loaded without proper testing due to the lack of tools. Conc lu s ions from the experime nt exec ution are: the complexity of the expe riment software comes close to the maximum that can be generated in the present OBS development envi r onment . This ca n be concluded from the type of software er rors and procedural erro rs th at are made. the sequence of exper i ments allowed each expe rimen t to build on the previously made extensions . In view of the earli er remark about complexity, an oth e r sequence would hav e caused seve r e problems with testing of the sof tware . th e experimen t execution i t self was succes s fu 1.
2,.,
loN TE "INlo
I
I
I CO MMAN D
I
L _ __E5LEJ; __
ANTENNA 4"10 STDN DISPL AV
OPE RATORS VDU
COMMAND DISPLAY
TELElHTRY DISPL AY
I I
I I OPER AT ORS CONSOLE AT RA L I L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ .J
~·'i g .
4. Hard\vare Set - uc:> for Ex:")eriments
CONCLUS IONS Much, if not all, of the IRAS ACS flight experience during the operationa l mission in '83 , has been compiled by Boom, 1984 , and is available. In addition t o the nume r ous software changes made during this 10 month science mission, the three IIIRAS revisited" expe rimen t s once more and more prom in en tl y demonstrate: that very complicated in-flight softwa r e changes can be made, without serio usly endange ring the mission. that therefore RAM back-up modes do not necessa rily need th e same detailed implementation as the ROM back-up modes. th a t fa ll-back modes like in IRAS can readily be impleme nted and may operate very satisfactorily. that ROM software for safe modes on ly and as safegua rd of normal RAM opera ti ons is a b enefic ial design co ncept providing suffic i e nt safe ty and maximum system
I ~
I
I
I
.l
./'..
I ru t:,DFl T
\
501425 H't: Vt:"'U' TI t:
~
V' 'v
Horizon Sen30r
I I
i ------1 I I
l I
~ 'i S' .5.
1 I I
i I
\1C .::lS Ure ~:1211 ts
during Experiment 3 (output satu r ate3 ut auout 60 degrees)
~
IRAS REVISITED F. Teule*, C. Slippens** and
J.
Gourlay***
"' Fllkkrr SI!fI({' /)i ,'i,illll "" '.\'((lillll((1 ..... {'/"(/.\j!fl({· 1.(( IIImlllln (.\'l.R I *" ",/? IIlhl'll",.,1 i.f ... . NI/,·IIIII 1.((/IfImlllril'.l
Abstract. Following the successful IRAS mission, during which many in-flight system reconfigurations had been programmed in the onboard computer, three explicit experiments were defined for in-orbit execution under ESA contract. The first one was a computer memory reconfiguration through which 3 blocks of 16 k 16-bits RAM memory became available for data storage. In the original configuration, 2 blocks of these belonged to the redundant 32k computer system. Since during the operational mission no back-up mode was ever needed, a ROM implemented back-up mode for the normal safe mode was exercized as the second experiment. The surprising result was that the back-up mode was even more accurate than the original Safe Mode, at least for the experiment circumstances. The back-up mode software in ROM was called by RAM software to provide experiment specific data storage in the extended memories. This approach was also followed for the last experiment in which the satellite recovered from a deliberately saturated reaction wheel (23 Nms). From the data storage it was concluded that the satellite unexpectedly tumbled almost three times before stable recovery. The experiment software development and the execution of the experiments forms a valuable experience for future projects. Ke~ords.
Attitude control, onboard computer, onboard software, reconfiguration, satellite, software engineering.
A new series of well defined in-orbit experiments was proposed to ESA to demonstrate extensively and prominently the benefits of reprogrammability and to assess IRAS long term system performance. Eventually, three experiments were selected for execution in the first months of 1985. Following their successful but (in some cases) surprising performance, the IRAS transmitters were switched off on May 9th, 1985. Reactivation of the systems is not expected, however available IRAS still is. The first part of this paper summarizes the IRAS attitude control system, onboard computer and ground systems. Then a definition and functional evaluation of the three experiments is given followed by a definition of the software changes required and an account of the experiment execution experience.
INTRODUCTION On 22 November 1983 IRAS - a JOlnt project by the Netherlands, United Kingdom and United States completed its task of accurately surveying the infrared sky after 300 days of very successful operation. In addition to an almost compl e te sky survey, numerous pointing observations were
executed providing high spatial resolution or spectral information on a selection of specially interesting infrared sources. The satellite was launched into a sun-synchronous, twilight orbit (inclination 99·, altitude 900 km) on 26 January 1983 and operated from Chilton, in the United Kingdom. The satellite's elements were: Infrared Telescope System, built in the USA, a Iso hous ing the so-ca lled "Du tch Add i t iona 1 Experiment". Superfluid helium kept the detector array temperature at 2.4 K during the satellite's operational lifetime. The spacecraft system, built in the Netherlands, providing all supporting functions like power supply, the radio-frequency subsystem, the central onboard computer and data-storage facility, and attitude control.
IRAS Attitude Control
Already during the science mission a number of in-orbit experiments were done to investigate the presence of helium slosh effects, thermal misalignments (Karsten, Teule 1984) and a different control law (Zwartbol 1984).
The Attitude Control System (ACS) design was largely driven by the survey character of the mission, the high control-accuracy requirements and the need to safeguard the cryogenically cooled telescope stringently against irradiation from the Sun and Earth. The attitude control functions were implemented by software in IRAS's central reprogramrnable On-Board Computer (OBC). Each of the redundant OBCs had its own bus interface with the ACS units. One of the OBCs was active, the other on cold stand-by. Separate Attitude-Control Electronics supervised the ACS operations. The ACS software occupied 15 k 16-bit words of memory.
When the science mission was over, all onboard systems still operated without substantial degradation. During the science mission all sorts of in-flight system optimizations had been loaded to the satellite's programmable onboard computer.
Mission-critical functions were stored in ROM and all operational software in RAM. RAM operations were controlled by a Satellite Operations Plan (SOP), which was transmitted to the spacecraft twice a day and defined a l2h period of I .)
76
F. Teu le, C. Sli ppens and
J
Gou rl a\'
IMAGED FOCAL PLANE
, ' , , ,, , '"
"
f'"
+Z
7
,','I
'I:
X
--.-=== ,
P i g .l. lRAS Pine Attitude Calibrations
\I'I\KIII
I tll!'\' \lc)lll ....
r K ·\( 1-..' , (, 11 '-l.(l\j)j
It lIl''''1
""I
~l'
\1))
Dj 1 t \t BI I H ' «()\ I K· ( " I'll \\1 ()'l )
JK '\~ I-..I'\,l,
I
L-_-.,----,,-_.-.J 1\ 11'()",,, 11l 1 1 (,Kol '1)( 0\1\1
"I)
'--------'
I< I 11'" '01 \ '\, Ilc 11' \11 !l l '\, .... \1 I \ r 11 J I DI III \ 11 01'\11"
KO\! I() K \ \\ I(,j{ot
' ...... 111\1 1\ \ I t ! ' ' \!()[)I\
"
"
RX2
-
~
•
\ l l l l l [) J
- - --- -ii,I -- - -
(11', K \ III l" d
le 111' .... '
,'I),
.. ( \1 lHK \ r le)'\, ... /
I!
I ( I [I'" 111'1 K \ 111 )"
0\1\\
(li\~"'-1
K \\\
F i g . 2 . lRAS Att i tude Control Summary
RX l
'IH
' IO\[) I
,[ l il t
..
1)\
!; .~ l~K~r~~' ..... /
FRAME SYNC
BIT SYNC
Fi g . 3 . DUAL
ANALOGUE
TAPE
RECORDERS
I
lRAS Ope r ations Control Centre
I
IRAS Revisited observations. The attitude-control sampling frequency was 2 Hz. The satellite coordinate frame was chosen such that the X-axis coincided with the telescope pointing direction, the Z-axis was perpendicular to the solar panels, and the Y-axis completed the right-handed orthogonal frame. The attitude about the X- and Y-axis was measured by means of a high-accuracy 64"x64" Fine Sun Sensor (FSS). The attitude about the Z-axis (the scan axis) was controlled using a gyroscope. A V-slit star sensor was incorporated in the focal plane of the experiment for regular calibration of the attitude about the scan axis. At each so-called "Fine Attitude Calibration", the cross-scan attitude error (about the Y-axis) was also determined, by comparing the predicted and the measured time intervals between the passages of a star image over a diagonal and perpendicular slit. If the observed cross-scan attitude error was greater than a predetermined value, the calibration result was rejected. Figure 1 illustrates the calibration method. Note that four different slit pairs were present for redundancy and to increase the number of suitable calibration stars on a selected scan track, by effectively doubling the scan-track width. six Coarse Sun Sensors, which together with the Fine Sun Sensor covered the entire celestial sphe re , were used for Sunacquisition and for the detection of eclipses. For eclipse operations, X- and Y-axis gyroscopes were added to the redundant Z-axis gyroscopes. An Earth-horizon sensor (HSE) measured the attitude about the Z-axis during coarse control operations (for Earth acquisition, RAM initialisation and emergencies). As part of the RAM initialisation sequence, the in-scan attitude calculation process was initialised using the Earth's magnetic field as attitude reference (Coarse Attitude Calibration). The attitude-control actuators were three reaction wheels. Excess angular momentum was unloaded by means of magnetic coils. The Earthts magnetic field was measured with a three-axis Magnetometer, these mesurements being used in the unload algorithms and for the coarse attitude calibrations. Figure 2 summarizes the ACS functional modes. Attitude Safeguard During RAM operations, a ROM resident safeguard function checked each second whether the attitude state (attitude and velocity) was such that the attitude would stay within bounds. If this were not the case, an autonomous fallback to ROM control would be initiated. If, when under ROM control, the sun would leave the Fine Sun Sensor field-of-view or the attitude about the Z-axis would exceed its limit, then the ACS hardware (ACE with FSS and HSE) would detect this and signal it to the OBC selection circuitry.
Onboard Computer The lRAS central onboard computer was an LSI-version of the Philips p800 minicomputer with a 32k, 16-bit addressing capability. The memory of the onboard computer consisted of two parts : a 3k ROM and two blocks of l6k RAM. The RAM blocks could be selected such that they occupied address space 3-l6k or address space l6-32k. All data transfers to and from the onboard computer were done using a general-purpose bus via programmed I/O. The interrupt structure of the onboard computer was therefore fairly simple. The onboard software functions were command
77
handling, experiment data handling, housekeeping data handling and transmission, out-of-limits and status checking, and attitude control. Bulk science data storage for lRAS was achieved with onboard tape recorders, but for a quick health assessment data were stored in the onboard computer memory. In addition, there was provision for Special Data Storage for ad hoc monitoring upon ground request. Telemetry For lRAS, there were two types of telemetry, low speed and high speed. The Low Speed Telemetry provided the ground station with a continuous data stream. Every second, a telemetry frame (LSF) supplied information for real-time operations and diagnostic purposes, including: real-time housekeeping data (64 words) command-verification data (64 words) Memory-dump data (128 words) The LSF was sent to the ground both under RAM- and ROM-control. The High Speed Telemetry stream served to transmit the science data stored on the onboard tape-recorder to the ground. This was done about once every twelve hours during a ground-station pass at 1 Mbps. For attitude reconstruction purposes, the stored science data were accompanied (with a frequency of I Hz) by the Basic Frame Data (BFD), which were mainly sensor outputs and onboard status and attitude information. For detailed inspection of the ACS performance during the science mission, the BFD could readily be accessed.
Control Centre The operations control centre was located at the Rutherford & Appleton Laboratories Chilton, England. The principal components of the ground station and Operations Control Centre were (fig. 3): Antenna and associated equipment Receivers and associated equipment Two PDPll/34 computers and peripherals An ICL2960 computer and peripherals There was no direct link between the PDPll/34 computers and the ICL2960 computer. All data transfer was achieved by magnetic tape. The operations carried out on the PDPll computers were : Satellite commanding and data handling Tracking station performance monitoring Computer control of the tracking antenna Connection to keyboardS, tape and disc-units Data transfer into and from the control centre via the NASA communications system Science data sorting and preprocessing using an attached AP120B array processor Interface between P856 onboard-software development computer and the onboard computer. The principal operations carried out on the ICL2960 computer were: Orbit determination and prediction Observation planning and generation of the Satellite Operations Plan for onboard execution (SOP) Preliminary science analysis Engineering data processing
78
F. Teule, C. Slippens and
Engineering Aids The real-time POPll systems allowed real-time sIc operations monitoring during station passes. Also plots could be generated of the real-time telemetry (LSF) received during a pass. Upon request, hexadecimal memory dumps could be provided, either containing the program memory area (for comparison by hand, in addition to the automated memory checks) or special on board databases. The ICL2960 engineering aids became stepwise available within 3 hours after a pass. They were listings of critical events, detailed health and performance figures (also based on trend analysis), histories and tools developed in the course of the mission for special monitoring of unexpected phenomena. Most of these tools could be operated by the sIc engineers themselves for their own needs and selections. And, these products were all in proper engineering units.
lRAS-REVISITEO EXPERIMENTS Sofar, the systems as they have been during the 10 months science mission, have been described. For the three experiments executed under ESA contract from January until April 1985 a series of adaptations to the onboard and ground systems was necessary. First, the Chilton antenna had meanwhile (i.e. after the lRAS operational mission) been modified to control the AMPTE mission satellites. For the lRAS experiments, this meant that High Speed Telemetry could not be accommodated, only Low Speed Telemetry. Also, commanding from the Chilton antenna was not possible due to the AMPTE operations, through which ground stations of the NASA network were required.
These experiments-environmental issues required to extend the onboard memory capacity for data storage (since the onboard recorders stored data only for High Speed Telemetry). In addition to the thus established post factum monitoring means, watch of the experiment execution in real-time was to be provided by NASA stations. In this way, the demonstrations were to be the most available and convincing to the audience. Another circumstance which largely influenced the choice of experiments and the later onboard reconfiguration details, was the absence of the ICL2960 computer at the operations control centre, which played a vital role in SOP preparation, environmental predictions and as evaluation tool. The absence of the ICL2960 together with the depleted helium onboard, made very accurate experiments from the control point of view, impossible. For high accuracy, regular Fine Attitude Calibrations on known star positions (to be predicted by the ICL2960) would have been necessary. For these calibrations the starsensors in the focal plane of the telescope would have been needed, but these were no longer accurate at ambient temperature after helium depletion. The only available computers were the still operational POPll real-time system and, of course, the p856 computer as onboard software development station. In the course of the experiments preparations, additional grounds tat ions appeared not to be available. However, the Chilton antenna was again modified such that commanding of lRAS became poss ib le.
J.
Gourlay
The result was that all experiments have completely been controlled from the Rutherford and Appleton Laboratories. Ground Set-up for Experiments Figure 4 shows the ground system as it was used for execution of the experiments. The main adaptations made to the existing POPll computer tasks were: interface between P856 onboard software development computer and onboard computer, including the former ICL2960 role therein. capability to cope with experiment dedicated memory configuration of 48 k for data storage processing of onboard experiment data and to provide plots special experiment display format for real-time watch of the experiments. This display format was in addition to the about 50 operational display formats used to monitor the different systems in different mission phases. The most prominent new feature was a direct link from the lRAS control centre to ESTEC in Noordwijk, the Netherlands, using existing networks. This link provided a real-time experiment monitoring facility for a long-distance audience.
The in-Orbit Experiments Three experiments were eventually selected for in-orbit demonstration. The first experiment was a reconfiguration of the onboard computer memories. Through this experiment, three blocks of 16 k 16 bits words of memory would become available for data storage during execution of the other two experiments. The memory could be enlarged by switching the redundant, cold standby, computer RAM memories to the active onboard computer. The data storage should be an uninterrupted series from original 16 k data memory to the additional 32 k thus connected. From the test data stored during execution, the complicated software changes needed for the memory extension and related data handling appeared succes s fu 1. The second experiment was to exercise the Back-up Intermediate Control mode (BIC). This ROM mode served as a back-up mode for Intermediate Control which was the Safe Mode in ROM operations. Intermediate Control used the 2-axis Fine Sun Sensor and an earth Horizon Sensor (HSE) for control. BIC was effectively a back-up for the Z-axis only, in case the HSE should fail. BIC uses a gyro for control which is updated at the poles (either earth north pole or south pole) using the Magnetometers to measure the local magnetic field. The problem of reliable pole detection was transfered to detection of the earth equator from the magnetometer outputs; at the poles the magnetic field direction is stable but not its magnitude. At the equator the situation is the reverse. Therefore, a pole crossing is calculated from equator detections. The polar magnetic field orientation is then used to align the satellite telescope axis with it, the telescope boresight oriented outwards. Since the BIC operations were to be monitored in detail using the 48 k extended memory for data storage, controlled by RAM software, the ROM BIC function was to be called by RAM. True ROM operations would not allow for simultaneous data storage under RAM control. From the data gathered after repeated attempts to execute the experiment (all due to unexpected complexities) it could be concluded that the BIC performance was extremely good. The maximum attitude error at the poles was 4 degrees.
IRAS Revisited While the previous experiment was initiated by a simulated hardware error (HSE unhealthy), the third experiment was to demonstrate ROM recovery from erroneous RAM operations due to a simulated, frozen RAM memory cell. The effect of it would be that the RAM unloading function (with magnet coils) uploaded the Z-axis reaction wheel rather than unloading it. Through saturation of the wheel, gradual loss of control would result at which the ROM resident safeguard function would transfer control to ROM operations for recovery. Again, these ROM operations (Intermediate Control and proper ROM unloading) were to be called by RAM for non-interruption of the data storage. From the data storage, a peculiar recovery sequence was observed. Before regaining stable "ROM" control, the satellite almost made three full turns within 30 minutes. Analysis showed that this was mainly due to a much higher angular moment um in th e wheel at saturation (23 Nms) than assumed as part of the experiment definition (14 Nms). Also, some specialities in the ROM recovery algorithms in Intermediate Control were not quite tuned to the particular circumstances of the ex periment. Their design considerations had mainly been in the area of erroneous separation from the
laucher in the beginning of the mission. Figure 5 shows the remarkabl e attitude excursions and the subsequent satisfactory recovery.
IMPLEMENTATION OF EXPERIMENTS
i~l
datastorage takes place). storage address (the address at which datastorage takes place). As said, from the collected data during experiment execution, it was concluded that the memory extension and the new data handling functions were implemented successfully. Back-up Intermediate Control (Experiment 2) Extending on the results of experiment 1, the software for experiment 2 consists of three parts: 1. extending data storage with relevant parameters
2. 3.
implementation of expe riment control comma nd s replacement of the normal RAM attitude control by the relevant ROM attitude control. Part 1 and 2 were straight forward. Several alternatives existed for the implementation of part 3. Finally it was decided t o ca ll the complete ROM attitude control software after the RAM attitude control software, thus ove rruling th e RAM generated torques by the ROM gene rated torques. Advantages are: it is the mo st e l egant and general solution the implementation can be used again with expe riment 3 the attitude co ntro l used is a comp l e t e and tested set of r outines for the d ifferent axes initialisation of switchover should be handled correctly by the existing software Disadvantages are:
Memory Extension and Data Handling (Experiment 1) The additions and adaptations of the onboard software can be divided in thr ee classes. o Da t a storage. A se t of subroutines has been made to use three blocks for data s t orage purposes . The following software baseline was agreed: storage in the form of fixed format message storage in a circular fashion in the
not enough i s known about timing to be sure
that the wheel torques are calculated before they are issued, since the issue is done by a monitor routine at a fixed time within half the second possible int e r ference between ROM and RAM by the use of th e same variables the amount of software used is so large th at no good overview exists, and o nl y by means of
execu tion the system ca n be tested (given the present software developmen t envi r onmen t)
succession I, 2, 3, etc.
storage at a fixed rate (to be change by ground command). o Data dump. The operational IRAS system used 50% of the low speed frame (LSF) for memory dump data. The onboard software automatically included 256 bytes o f memory data in the 1 Hz LSF; In this way th e full memory contents was dumped in 256 second (each LSF contains the memory address of the first byte of dumpdata in that LSF). The memory dump procedure was modified such that after th e PMY dump (adress ~ to 7FFFH) the DMY address range (8000 H to FFFFH) is dumped 3 times, each time with a different memory block. In this way it is possible t o dump the complete onboard memory without commanding capabilities. o Monitoring and commanding. To operate the datastorage software the following commands are defined : start datastorage. This command clears all 3 datastorage memory blocks and consecutively start datastorage in the first byte of the first block. dump datastorage block n. A full memory dump during "IRAS revisited" requires 512 seconds. For short passes it is nec essary that th e present datadump point can be repositioned by the operational crew. The following data is added to the LSF for operational use of the datastorage routines: data storage block (the blocknumber in which
Execution of Ex per iment 2 Th e software modifications were loaded and linked. During the pass the behaviour of the software looked correct, so it was decided t o let the experiment enabled at the end of the pass. Before the next pass, a fallback to ROM and a switchover to the other OBC had occ urred. The situation was reset with a correction in the
on-board software. A new attempt to test, showed a completely different behaviour than the previous time: it looked as if the ROM attitude control under RAM control had become unstable. A fallback to ROM oc c urred . To comp licate the investigation into the sources of the erroneous behaviour, the experiment
monitoring parameters (part of exper im ent 1) in the LSF had disappeared. A systematic check of all parameters used by both ROM and RAM indicat e d that ROM and RAM software used the same name for the same at titude error but differently scaled. Therefore this usage was erroneo us in the situation where both ROM and RAM attitude-control software was operated each 0.5 second. Since in normal operations in RAM, also use i s
made of ROM located r outi nes, the RAM software resets the ROM attitude control mode to zero, because the used routin e would o th erwise react
depending upon that mode. Due t o this feature the first tryout resulted in a co ntinu ous initialisation of the back-up Int e rmediate Control mode.
80
F. Tcule, C. Slippe ns a nd
Recovery from Saturated Wheel (Experiment 3) For this experiment the necessary software is the software created for experiment and 2 extended with some special parts: 1. Finalizing the datastorage with the specific parameters for this experiment. 2. Implementation of SOP related and RAM attitude control state commands. These commands were required by the experiment definition. 3. Experiment sequencer. 4. New satellite safeguard.
Experiment 3 requires the following modes: a. normal mode with incorrect RWLZ speed to saturate the wheel b. ROM attitude control for recovery c. coarse attitude control (without datastorage) The transition to a. is done on ground command. Transition from a. to b. is based on the normal ROM located attitude safeguard. Transition from b. to c. takes place sufficiently long after the previous transition. After the start, the experiment should be executed autonomously. Therefore a special module had to be made that switches the satellite through the different modes. Another software addition is a safety measure. This experiment can only be executed with all available safety measures disabled : the ROM located safeguard had to be disabled. the redundant OBe switch had to be disabled. As the expected manoeuvres of the spacecraft bypassed the expected safety limite a new safeguard had to be made. A safeguard was made allowing complete freedom of rotation around the Z-axis of the spacecraft, when this axis is more or less pointing towards the sun (no coarse sun sensor illuminated). Apart from the above indicated software modules, this experiment uses the data storage and dumping software of experiment 1 and the ROM attitude control, using software of experiment 2. Execution of Experiment 3 After the software for experiment 3 was loaded and activated, the monitoring of the experiment development during the evening showed an error in the stored data. The saturation of the wheel took longer than expected so the experiment was not yet finalized at the last monitor pass, but the satellite had already recovered from the excess wheelmomentum. The satellite was therefore left unattended with the experiment active. During the morning passes the memory would be dumped, so that in morning all data would b e available for evaluation. Evaluation showed th e following errors: errors in the experiment specific data at the termination of the experiment the behaviour of the satellite became anomalous (but safe) showing a large limit cycle around the Z-axis using only maximal torqueing for the Z-whee 1. Both above given phenomena were caused by software errors at the interface between the old and the new software, caused by a redefinition of a variable between experiment 2 and 3. Apart from these two errors, also the behaviour of the spacecraft at recovery was not according to expectations; the satellite rotated twice around the Z-axis, before ROM attitude control was again in control of the attitude of the satellite. The reasons for the different anomalies were found very soon and it was decided to repeat the experiment with corrected software and a new software module added. The new module would limit the reaction wheel speed in the upload phase, so
J.
Courhl\
that the recovery phase would be done without the rotations around the Z-axis. The attempt to start the experiment gave a new surprise; when it was tried to link (activate) the corrected software for the data storage, the satellite fell back to ROM. The other modules could be linked without problems. After several attempts the experiment was activated with the incorrect data storage. Finally the cause for the anomalous behaviour was found. With the preparation of the correct software a procedure error was made that caused an incompatibility between the source version of the OBS, the object version of the OBS and the onboard version of the OBS. (OBS: onboard software). This incompatibility caused the generation of incorrect linkers (i.e. jump instructions to the start of the new module) so that the fallback was caused by a jump to a bitpattern that could not be executed and therefore caused an instruction-trap to ROM (the self protection of the OBe forces the software back to ROM-state in case of non executable instructions). After correction of the object library the last attempt was made to retry the experiment. This time, antenne drive problems caused the first pass to fail completely. The second pass could be taken, but the state of the antenna drive was still critical and the syst e m could break down any moment. Therefore it was decided to reduc e the experiment to a "forced stepwise test" through the different modes on ground command t o show the correctness of the previous incorrect parts. This attempt proved successful.
SOFTWARE DEVELOPMENT Experiment 1 The preparation and e xecution of the experiment showed that in a well structured software system it is possible to make rather complicated changes in a short time and to implement the changes on board with a minimal disrupti o n of the normal operational usage of the satellite. From the experiment executi o n the following estimates for the experime nt impact during normal operational circumstances are derived: the modification could have been produced by the OBS team within 72 hours in case emergency priority were assigned to the project (i.e. maximum effort, documentation to be generated afterwards, etc.) the operational interruption due to the implementation of the mo dification would be less than 2 orbits. Experiment 2 After the successful and smooth execution of experiment 1, the second experiment encountered much more problems: the initial design of the experiment contained two oversights with respect to interrelation (usage of each other parameters) between ROM and RAM attitude control. Unfortunately one was covered by the other, so that at least two successive test sessions were required to determine the problems. ground problems with the definition of certain variables confused the available material. The experiment required the by-pass of RAM and ROM located safeguards, 80 that the only safety measure left was the onboard computer switch.
RI
I RAS Rc\isiled All this led during the experiment preparation to an onboard computer switch-over, and later the use of the search mode for recovery of the satellite. Both situations were not allowed during the operational life of the satellite and could have endangered the health of the satellite.
flexibility. In such operational environments as these for in-flight software changes, computer-aided support for configuration-control becomes mandatory.
REFERENCES Conclusions from the experiment execution are: in ope ratio nal circumstances experiment 2 should no t have been executed given the present (-operational) software development environment, as this mi gh t have endange red the life of the satellite. for a n operational test of the satellite, the safeguard, that had been disabled fo r this experiment, should have been replaced by a special purpose safeguard. software modifications of this n a ture shou ld hav e been tested with special testtools (one axis simulation, env ironmen tal simulator, etc. ) experiment 2 could have been executed safely by only replacing the Z-axis con trol of RAM by the Backup Intermediate Cont r ol algorithm
Holdaway, R. (1983). Infra-Red Astronomical Satellite. JBIS, special issue Karsten, L./Teule, F. (1984). IRAS Thermal Misalignment, a Lesson for the Future. ESA Journal 1984, Vol 8 Zwartbol, T. et al. (1984). Experiments in modern control onboard IRAS. Procee dings AIAA Guidance and Control Conference. Boom, E. et al (1984). In-flight performa nce o f the Attitude Control Syst em of IRAS. Fokker report TR-R-ACS-84-0 1.
Experiment 3 The softwa r e erro r s made at the generat i on of expe riment 3 boiled down to one point; a redefinition of one of the variab le s used for both expe ri ments 2 and 3 of which the consequences were not correctly a nti cipated at all lo cations. The modifications and additions made to th e code generated for expe rimen t 1 and 2 wer e in it se lf rather simple, but the total s tru cture of the code used for the exper iment was in itself so large and comp l ex tha t the made e rror was more o r les s in e vitable. All th e above me ntioned co d e is generated and loaded without proper testing due to the lack of tools. Conc lu s ions from the experime nt exec ution are: the complexity of the expe riment software comes close to the maximum that can be generated in the present OBS development envi r onment . This ca n be concluded from the type of software er rors and procedural erro rs th at are made. the sequence of exper i ments allowed each expe rimen t to build on the previously made extensions . In view of the earli er remark about complexity, an oth e r sequence would hav e caused seve r e problems with testing of the sof tware . th e experimen t execution i t self was succes s fu 1.
2,.,
loN TE "INlo
I
I
I CO MMAN D
I
L _ __E5LEJ; __
ANTENNA 4"10 STDN DISPL AV
OPE RATORS VDU
COMMAND DISPLAY
TELElHTRY DISPL AY
I I
I I OPER AT ORS CONSOLE AT RA L I L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ .J
~·'i g .
4. Hard\vare Set - uc:> for Ex:")eriments
CONCLUS IONS Much, if not all, of the IRAS ACS flight experience during the operationa l mission in '83 , has been compiled by Boom, 1984 , and is available. In addition t o the nume r ous software changes made during this 10 month science mission, the three IIIRAS revisited" expe rimen t s once more and more prom in en tl y demonstrate: that very complicated in-flight softwa r e changes can be made, without serio usly endange ring the mission. that therefore RAM back-up modes do not necessa rily need th e same detailed implementation as the ROM back-up modes. th a t fa ll-back modes like in IRAS can readily be impleme nted and may operate very satisfactorily. that ROM software for safe modes on ly and as safegua rd of normal RAM opera ti ons is a b enefic ial design co ncept providing suffic i e nt safe ty and maximum system
I ~
I
I
I
.l
./'..
I ru t:,DFl T
\
501425 H't: Vt:"'U' TI t:
~
V' 'v
Horizon Sen30r
I I
i ------1 I I
l I
~ 'i S' .5.
1 I I
i I
\1C .::lS Ure ~:1211 ts
during Experiment 3 (output satu r ate3 ut auout 60 degrees)
~