This software architecture allows each individual program to be relatively simple, and thus maintainable. Additionally, a change to the hardware of one subsystem can be easily accomodated by modifying or replacing one program with minimal impact on the rest of the software.
Although the SAC can run independently of ALIA --
hence its name --
ALIA cannot run
independently of the SAC . The controller program of
ALIA interacts with the SAC
to perform all hardware operations during scan setup.
The data collector also acts as gatekeeper for the other processes at the end of each pass. It waits to hear that all other processes are ready to proceed with the next pass before opening the gate and instructing the other processes to go ahead.
Of course, it is always possible that something has gone wrong and the
things that should have happened at boot time, didn't. If this seems to have
happened, you can manually perform the task by executing the com file
disk$schmidt:[plateproc.control]pixel1_bootme.com.
As a reminder that these disks are not really local, they have been mounted with the prefix h, eg, disk$hgsc2. The h stands for Haven. If Haven is down, the disks will be inaccessible to the Pixels, even if they are accessible to the rest of the cluster.
Similarly, the pixel disks have been crossmounted to Haven. This was done primarily to support computer ops backups.
If the crossmounted disks are not available, ALIA itself will not be impacted; however, further pipeline processing and database updates will most likely be affected.