Support Processing

1553 Bus Management

Each DPU communicates with the C&DH system over a 1553B bus. A DPU acts as a remote terminal (RT) with the active C&DH system acting as the bus controller (BC). The traffic on the 1553B bus is periodic, repeating every one second major frame. The major frame is divided into 25 minor frames, numbered 0 to 24. Individual messages are distinguished by their transmit or receive subaddress. Each DPU responds to the messages shown in the following table. The table shows the subaddress and minor frame of each message that the DPU handles.

Each second, the C&DH sends the DPU the MET of the next major frame. At the beginning of the next major frame, a sync with data word mode code command tells the DPU that the MET received should be used. The DPU references all data collection to this time sync. Since the sync is sent at a fixed offset into the major frame, the time of data collection is known with respect to time in the C&DH system.

Telecommand packets, containing one or more commands, are delivered in fragments, with up to eight fragments per major frame. The packet will always begin at the start of one of the fragments but could be in any of the eight minor frames.

Each major frame, the C&DH system picks up the non-packetized housekeeping and zero or one telemetry packets. The DPU tells the C&DH system how many packets to take through the vector word that C&DH picks up at the start of every major frame. If the vector word indicates that a packet is ready, the C&DH system picks up the packet near the middle of the major frame. The DPU sets up the non-packetized housekeeping, the next packet, and the vector word at the end of minor frame 23 when it knows that there will be no packet activity until the start of the next major frame. The format of the vector word is shown below. In addition to the packet count, there is a toggle bit that the DPU flips each major frame to indicate that the DPU is still sentient.

To test the DPU's 1553 interface, the C&DH sends a test pattern every sixteen seconds to the data wraparound area and then reads it back.

In addition to the time synchronization and the transmit vector word mode codes shown in the table above, each DPU reponds to several other modes codes. The complete list of mode codes handled by the DPU are shown in the following table. All unused subaddresses and mode codes are illegalized.

Alarms and Monitoring

Alarms report problems found by the DPU software. Each alarm is described by an ID, two values, and a flag. The ID identifies the problem that has occurred and the accompanying values offer additional information. The flag indicates whether the alarm was caused by a transient or a persistent condition. See Appendix 1 for a list of alarms.

The alarms are divided into two groups: one for reporting internal software problems and another for reporting out-of-limit conditions for monitored data. Software problems are all reported as transient alarms. When the problem occurs, the alarm is generated and the software recovers from the problem as best it can.

A collection of environmental data is monitored by the DPU. There are analogs including voltages, currents, and temperatures read and monitored via the DPU's I2C bus The monitoring is event driven: a monitor cycle is performed on each item as it becomes available. For example, each DPU analog is monitored when it is read.

Each monitored item has a lower and upper limit. If an item is out of limits one cycle, but back within limits on the subsequent cycle, a transient alarm is reported. The alarm ID indicates the item being monitored and whether the value was too low or too high. The values accompanying the alarm are the out of limits data and the corresponding limit. If an item is either too high or two low for two consecutive monitoring cycles, a persistent alarm is reported. Again, the ID indicates the item being monitored, etc. The values accompanying the alarm are the second out-of-limits data value and the limit. If enabled via the CXX_MON_CNTRL command, the DPU will also act to eliminate the problem; a high or low response macro designated for the alarm is run.

If the item is out of limits for more than two cycles, indicating that the first response failed to eliminate the problem, more drastic action is taken. Monitors are divided into three classes; the class determines what action is taken. For count rate monitors, the macro is rerun. For temperature monitors, nothing is done. For current or voltage monitors, if enabled via command, the shutdown macro is run.

The following pseudo-code description of the reactions to a high monitor summarizes the discussion above. The low responses are similar.

high once:
	issue transient high alarm

high twice:
	issue persistent high alarm
	if enabled (via CXX_MON_CNTRL command)
		execute high response macro for this alarm

high more than twice:
	case of monitor class
		current/voltage:
			if enabled (via CXX_MON_CNTRL command)
				run shutdown macro
		temperature:
			nop
		count rate:
			if enabled (via CXX_MON_CNTRL command)
				execute high response macro for alarm

Fault Avoidance and Recovery

Many of the DPU's hardware control registers contain triple redundancy and voting logic for each bit. The DPU software periodically rewrites these registers to correct single bit errors.

Each DPU has a watchdog timer. If the watchdog timer is not tickled from time to time, the processor is reset. The watchdog timeout is 2.95 seconds. The watchdog does not run until it has been enabled; once enabled, it can never by disabled except by processor reset, watchdog or otherwise. The DPU monitors all periodic processes every second. If they are all running, the watchdog is tickled. Some aperiodic processes do not participate.

Return to Common Software User's Guide. Report problems to John Hayes.