Table of Contents
Previous Chapter
Table of Contents
Previous Chapter
Fault detection and isolation requirements specified by the ACIS Contract End Item are met by the Diagnostic, Memory, Housekeeping, and Patching features described in the "System Features" section of this document.
The instrument software shall perform self-test operations as an integral part of its normal activities. These include at least the following:
Back End Processor redundancy requirements are not handled by the ACIS Science Instrument Software, but are instead covered by independently commandable, redundant Back End Processor hardware subsections.
Front End Processor redundancy requirements are covered by having multiple Front End Processors. By allowing commandable selection of CCDs, the software indirectly provides the capability to select which Front End Processors are in use (see Section 3.2.7.3.1). This also applies to the Detector Electronics Assembly subsections and CCDs.
There are no critical or semi-critical situations over which the ACIS Science Instrument Software has control. Therefore, the software has no requirements addressing these types of situations.
If the instrument re-boots due to a fatal error or watchdog reset, the ACIS Science Instrument start-up software shall not install any patches. The software will idle, waiting for commands.
If a Front End processor resets due to a fatal error or watchdog reset, it will send no further science data to the Back End processor for the remainder of the science run.
In the event that the instrument receives a parameter block whose computed integrity check code (CRC or Checksum) does not match the one contained within the block, the software will indicate the error in the Command Echo, but still overwrite the parameter block located at the identified slot.
If the instrument is then commanded to perform a run using a corrupted parameter block (either corrupted during transmission, or corrupted on-board), the software will indicate the condition in the command response, assume that the Imaging/Spectroscopy selection from the block is valid, and use the block to determine whether an Imaging or Spectroscopy run was desired, and then use one of the appropriate default parameter blocks for the run. The activated mode will run until a "Stop Run" command is received.
If the instrument attempts to use a default parameter block whose integrity check code is invalid, the instrument will indicate the condition in software housekeeping, and idle, waiting for commands.
In order to minimize data loss due to dropped commands, if a run has been started and another "Start Run" or "Recompute Bias" command is received, ACIS will indicate the condition in the command echo, proceed to shutdown the current run, and then start to execute the new request.
In order to ensure the validity of the internal Back End Processor Tick counter (BEP Tick Counter) the handling time of the timer interrupt, plus all other interrupts with a higher priority, plus the longest period during which interrupts are disabled, shall be at least 20% shorter than the fastest timer tick responded to by the system.
The ACIS Science Instrument Software design shall comply with the standards described and/or referenced by the ACIS Software Development Plan.
The ACIS hardware contains two types of memory; Single-Event Upset (SEU) Immune (current estimates are a couple of bit-flips per year), and bulk memory (current estimates are for 1-100 bit-flips per day). All processor code and stack shall be located in SEU Immune RAM. Any other data, which, if used after being corrupted, can cause the software to crash or corrupt SEU Immune RAM, shall either be located in SEU Immune RAM or be error-checked prior to its immediate use. If a corruption is detected, the software shall indicate the error, and either correct or work-around the corruption.
Given these design constraints, for each processor, the system can expect up to 2 SEU-induced resets per year, and 100 single-bit data corruptions per day.
The ACIS Science Instrument Software shall be designed and documented such that a knowledgeable party, other than MIT personnel, is capable of using and maintaining the instrument software after delivery of the ACIS instrument.
The ACIS Science Instrument Software is designed specifically for the ACIS hardware. No portability requirements exist, other than that needed to ease testing and provide flexibility to small hardware changes during system development.
In order to support third party (namely, the AXAF Science Center) maintenance of the ACIS software, all tools which directly affect the software delivered as part of the ACIS instrument, and all tools needed to maintain the instrument shall be transferrable to a third party.
Next Chapter