OFJ97 Field Journal from Tal Brady - 2/18/97

New "Phase-3" software test results, however, I *can* see (this is the software that would be used on the spacecraft if the tape recorder should break down). I made a really dumb mistake and kept the old memory write protection settings in the new software. Of course the new software caused write protect errors as soon as it started and would not run. I keep forgetting that the simulator that the development team used doesn't use the write protect settings and so doesn't show this mistake. Fortunately, it only took about a hour for me to figure out what was wrong, but the test will have to be restarted tomorrow. It's too long to finish today.

2-19-97
No one has called me about any problems on the spacecraft so things must still be running OK for the encounter. The schedule looks like more Jupiter science today then some Io science tonight. Europa science and closest approach is tomorrow morning. I'll take a look at the Web pages tomorrow morning and see what's up.

They restarted the Phase-3A testing on the testbed this morning and now the software seems to be running correctly. This test should answer the questions from last week about the CDS and the Solid State Imaging instrument working together properly , so I hope it runs to completion without crashing. I'm pretty sure that we will have to make some changes to the flight software based on these results and I want us to get started on them as soon as we can.

Meanwhile, we can start running the final acceptance tests that must be complete for the formal delivery of Phase-3A software in about three weeks. Formal delivery is a delivery of the software and its documentation to the Spacecraft Operations Team and the JPL Software Library. This cannot be done until a rigidly defined set of flight software tests and re-tests have been successfully completed by the development team and on the development team simulation tools. These acceptance tests essentially demonstrate that the delivered flight software will work properly when run on the spacecraft's Control and Data Subsystem (CDS).

We have also made Informal Deliveries to the system testbed in order to allow early testing of the CDS flight software's interaction with the other components (mostly the science instruments) of the spacecraft and their flight software. The "testbed," is basically a spacecraft hardware model consisting of developmental versions of the Control and DataSubsystem, the Attitude and Articulation Control Subsystem (AACS -- the Navigation computer), and the science instrument hardware connected together in the same manner as they are on the real spacecraft. Since the hardware is the closest available to the actual flight hardware (in some cases an identical spare) and the software is the same as that used on the spacecraft, the testbed gives us the best possible model of the way the things we are testing will behave on the Galileo Spacecraft. The testbed is complicated to run and can only run tests slowly, so we only test the way that the CDS flight software works with the hardware and software of the other spacecraft components on the testbed.

The majority of the CDS flight software testing is done on the CDS fast simulation system. This test system simulates the spacecraft hardware using software on a very fast computer. It is much faster and easier to run tests on this test system, but it does not have the real CDS, AACS or instrument hardware and does not have the real instrument software either. Only the CDS software and the AACS software are the same as what is on the spacecraft. Since the hardware is simulated in software, the tests do not have quite the same results as they would on the spacecraft. For example, as I mentioned above, the simulated hardware does not have write protected memory like the real hardware and so a simulator test does not show a write protection setting problem. For this reason, although most of the flight software functions can be tested on the simulator, some functions can only be tested on the testbed. We try to eliminate bugs before sending software to the testbed, but we can't always avoid the problems that crop up when our CDS software has to work with the software that runs other parts of the spacecraft.

Testing the software on the simulator is called subsystem or software integration testing because we are putting together all of the software parts of the Control and Data 'Subsystem' and testing them. Testing the software on the testbed is called testbed testing or system integration testing because we are putting together all the software and hardware on the testbed 'System' and testing how well it all works together. CDS Acceptance testing is normally done after subsystem integration testing and before system integration testing. For the Phase 3 software delivery we informally delivered the flight software before we completed the subsystem integration and the acceptance testing.

Since we did not complete as many of the pre-delivery imaging subsystem integration tests as we expected to, both the acceptance testing and the subsystem integration may also uncover more problems than we would normally expect. I think we'll probably need to make at least one more version of the flight software and test it before the formal delivery.