Table of Contents Previous Chapter

3.3 Miscellaneous Requirements

3.3.1 Fault Detection and Isolation

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.

3.3.2 Self-Test

The instrument software shall perform self-test operations as an integral part of its normal activities. These include at least the following:

3.3.3 Redundancy Management and Hardware Re-configuration

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 This also applies to the Detector Electronics Assembly subsections and CCDs.

3.3.4 Fault Management

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.

3.3.5 Watchdog Reset and Crash Recovery

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.

3.3.6 Bad Parameter Block Corruption Handling

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.

3.3.7 Start or Bias Commands during a Run

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.

3.3.8 Timer Interrupt Response Time

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.

3.4 Design Constraints

3.4.1 General

The ACIS Science Instrument Software design shall comply with the standards described and/or referenced by the ACIS Software Development Plan.

3.4.2 Memory Types

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.

3.5 Software System Attributes

3.5.1 Maintainability

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.

3.5.2 Transferability/Conversion

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.


Table of Contents Next Chapter