ACIS CDR Software RIDS

Last updated: Mon Jul 17 18:16:53 EDT 1995


The following comments survived the ACIS Flight S/W Review process and will be tracked by MSFC software management. No specific close-out dates have been assigned.

Tracked Comments from S/W PDR


1 TC 1 Lack of support for EPHIN signals
2 TC 2 Suggestion to eliminate window list packets
3 TC 3 The semantics of the "start of run time-stamp"
4 TC 4 2.9 In-line assembler code
5 TC 5 4.9.7 BEP/FEP Exposure Handshake Protocol
6 TC 6 14.15 Class ChLoad Blk
7 TC 7 Classes, subclasses, objects, etc.
8 TC 8 Class Category Diagram
9 TC 9 Error Handling
10 TC 10 Processing Time
11 TC 11 FEP checking BEP commands
12 TC 12 Priorities
13 TC 13 Interface Definitions
14 TC 14 FEP Data Flow Diagram
15 TC 15 250 ms Time Limit
16 TC 16 FEP Range Value Check
17 TC 17 FEP to BEP
18 TC 18 Ring Buffer Space
19 TC 19 Patch grouping

RIDs Outstanding from S/W CDR

Three RIDS were closed out on June 30, 1995.


Tracked Comment 1

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Allyn Tennant, 205/544-3424
ORGANIZATION
MSFC ES84
DATE
6-14-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Lack of support for EPHIN signals
DISCREPANCY/PROBLEM
There appears to be no software support, in the detailed design specification, for the radiation-high/low flag that is being passed to ACIS from the spacecraft OBC. (Top level requirements for this are in the ACIS Science Instrument Software Requirements Specification, 3.2.13). The current concept is that the spacecraft will not track ACIS internal states and will continue to send ACIS any stored commands that occur during high radiation events. This makes keeps the OBC software simple (as it should be for this function) but it implies some requirements on the ACIS software. ACIS could respond to the high radiation flag in several ways, many of which have a serious impact on the software. In particular, the ACIS software should try to minimize science data loss, and so the software will need to restart the instrument in the correct state and recalculate a bias if needed.
INITIATOR'S SUGESTED ACTION
The ACIS team (hardware and software) needs to decide exactly what actions the ACIS instrument should take when it gets a radiation high signal. Once this is decided, the appropriate requirements should flow into the software requirements and specifications. The ACIS team should also better define what "radiation high" really means to allow spacecraft software people to make sure that the OBC sends ACIS the correct signals.
DEVELOPER'S COMMENTS
An EPHIN alert terminates the current science run, shuts down the CCDs, and drains the telemetry buffers, as stated in 3.2.13. ACIS will generate a Software Housekeeping record (Table 63) and a Command Error record (Table 62). Once the EPHIN alert ends, the BEP executes the most recent "start-run" command, unless a "stop-run" command was received at a later time. The new science run will be preceded by a bias calibration. We'll describing in detail how the BEP responds to fresh commands while the EPHIN alert is in effect, and what it does when the alarm is de-asserted.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 2

ITEM REVIEWED
SDM02 ACIS Science Instrument Software Requirements Specification (36-01103)
VERSION
B
INITIATOR/PHONE
Patrick Broos, 814/863-5505
ORGANIZATION
PSU
DATE
6-11-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Suggestion to eliminate window list packets
DISCREPANCY/PROBLEM
In the current design, if a science run includes a list of windows to control the processing of pixels/events, that window list is telemetered in a window list packet which immediately follows the parameter block packet at the beginning of the run. It appears that the information in the window list packet could easily be included at the end of the parameter block packet. This change would eliminate one packet type from the design, presumably simplifying the documentation and the flight software. The sets of information in parameter block packets and window list packets are conceptually identical--they describe the configuration of the instrument. Unifying the telemetry of these two sets improves the comprehensibility of the design. This change will significantly reduce the complexity of the ground software.A large number of error conditions in the current design that the ground software must detect and report will be eliminated.
INITIATOR'S SUGESTED ACTION
Revise the definition of parameter block packets to include a variable length array of window descriptors at the end of the packet. Eliminate window list packets completely.
DEVELOPER'S COMMENTS
This looks like a very good idea, provided it doesn't increase the length of parameter blocks beyond the 512-byte limit imposed by the SI ICD.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 3

ITEM REVIEWED
SDM02 ACIS Science Instrument Software Requirements Specification (36-01103)
INITIATOR/PHONE
Patrick Broos, 814/863-5505
ORGANIZATION
PSU
DATE
6-11-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
The semantics of the "start of run time-stamp"
DISCREPANCY/PROBLEM
Given the information in the current document, it appears that calculating the time that data were clocked out of a CCD is complex. Section 3.2.1.3.9 states that the "start of run time-stamp" does not directly record the time that the first integration began--a time delay correction that depends on the parameter block must be calculated on the ground. The document is not clear on how the time used to calculate bias is accounted for. If the Exposure Number field inside Exposure Record packets counts the exposures used for bias, then the time spent calculating bias is accounted for "automatically" . However, this would mean that the first value of the Exposure Number field seen in telemetry may not be zero, placing a burden on the ground software to figure out what value it should expect so it can detect missing exposures. If, on the other hand, the Exposure Number field does not count the exposures used for bias, then the ground software must deduce how long the bias calculation took so it can recover timing for the entire run. If the parameter block packet was lost, this may be impossible. Regardless of when the "start of run time-stamp" is latched, the document does not clearly state how the ground software can determine the exposure rate (TE mode) or row rate (CC mode).
INITIATOR'S SUGESTED ACTION
Would it be possible to change the semantics of the "start of run time-stamp" so that it is latched when the integration of the first telemetered exposure begins (after all setup and bias)? This would eliminate the need to calculate some of these error-prone corrections on the ground. The complete algorithm for calculating CCD readout times must be documented, including the method the ground software must use to determine the exposure rate or row rate.
DEVELOPER'S COMMENTS
Exposure numbers are set to zero at the start of each bias calibration and science run. Exposure duration can easily be computed by differencing the FEP readout times reported in consecutive exposure records (they're missing from Table 21--our mistake). The start-of-exposure time of the first frame is a constant offset from the "Science Run Start Time" (which we did remember to include in Table 21), with the understanding that the very first exposure will be discarded. We'll add an appendix to the Detailed Design Specification describing how to determine all relevant times.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 4

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Steve Purinton, 205/544-3804
ORGANIZATION
MSFC EJ33
DATE
6-25-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
2.9 In-line assembler code
DISCREPANCY/PROBLEM
In-line assembler used when a compiler will produce different results if changed.
CONSEQUENCES IF NOT CORRECTED
Software Maintenance will be difficult.
INITIATOR'S SUGESTED ACTION
Write a module entirely in assembler or C or C++.
DEVELOPER'S COMMENTS
This is a feature of our compiler, which is itself under configuration control. However, we will separate all assembler from C++ since this will make it easier for us to unit-test the mongoose module.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 5

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Steve Purinton, 205/544-3804
ORGANIZATION
MSFC EJ33
DATE
6-25-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
4.9.7 BEP/FEP Exposure Handshake Protocol
DISCREPANCY/PROBLEM
Tracking of exposure number seems cumbersome.
CONSEQUENCES IF NOT CORRECTED
Missed exposures by some FEPs.
INITIATOR'S SUGESTED ACTION
Provide exposure number (if important) from BEP to FEP when the exposure is started. Or if BEP exposure is >1 different from internal exposure wait until next DEA frame update signal and correct exposure number (m+1).
DEVELOPER'S COMMENTS
It is necessary to count exposure numbers in order to reconstruct the precise exposure epoch. The saturation requirement (3.2.1.3.11 of SDM02) calls for FEPs to drop entire exposures. On the recommendation of our science team, we have interpreted this to mean that, if one FEP is unable to process any part of an exposure, all FEPs must drop that same exposure entirely, for which it is necessary to establish the FEP-BEP handshake described in 4.9.7. We will update SDM02 to state this more clearly.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 6

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Steve Purinton, 205/544-3804
ORGANIZATION
MSFC EJ33
DATE
6-25-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
14.15 Class ChLoad Blk
DISCREPANCY/PROBLEM
Unnecessary.
CONSEQUENCES IF NOT CORRECTED
Simplify design and match ground capabilities.
INITIATOR'S SUGESTED ACTION
Execute a parameter block immediately or execute one in memory. Modify by loads.
DEVELOPER'S COMMENTS
The requirement for multiple parameter blocks is stated in 3.2.1.3 of SDM02. The details are contained in the "BEP Parameter Block" module, which was unavailable at SDM03 CDR release time. The current design calls for 4 blocks--two for timed exposures (default and RCTU-supplied), and two for continuous clocking (default and RCTU-supplied). We consider it advantageous to retain the multiplicity in order to recover from several abnormal conditions, e.g. command loss, EPHIN recovery, etc. We'll add a cross-reference from 14.15 to this new section.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 7

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Dennis Pierce, 310/814-1704
ORGANIZATION
TRW
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Classes, subclasses, objects, etc.
DISCREPANCY/PROBLEM
Impossible to find references to the different classes, subclasses, objects, etc.
INITIATOR'S SUGESTED ACTION
Add an index.
DEVELOPER'S COMMENTS
An index of class and object names will be added to SDM03.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 8

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Dennis Pierce, 310/814-1704
ORGANIZATION
TRW
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Class Category Diagram
DISCREPANCY/PROBLEM
Need for a layered description and/or diagram showing the hierarchical relationship between the different classes. In 3.3 BEP Class Categories and Category Relationships, five class categories are described but no information about their relationships to the other classes in the system is given (at least early on where a good overview of the typing system of ACIS would be most helpful in orienting the reader/user in this complex system). Booch in Ch. 5: The Notation describes the use of top-level classes and class categories to show class relationships. I found that the resulting diagram is too unwieldy to be helpful.
INITIATOR'S SUGESTED ACTION
It would be extremely helpful if the hierarchical relationships between the classes were provided on several different levels and all within a section near the beginning of the document and independent of the class relationships diagrams (which provide both superclass/subclass information as well as other class relationships, such as association, has, using etc.). In order to get a quick feel for the organization of the system as a whole. Previous generations of design documents showed a functional decomposition of their system and since much of this functional decomposition is now represented using classes, such a hierarchy diagram is important.
DEVELOPER'S COMMENTS
One or more Class Category diagrams will be added to SDM03.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 9

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Dennis Pierce, 310/814-1704
ORGANIZATION
TRW
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Error Handling
DISCREPANCY/PROBLEM
There's very little on error conditions, their classification, expectation, and how they are to be handled, especially software errors.
DEVELOPER'S COMMENTS
Paragraphs will be added to SDM03 describing software housekeeping messages, fatal error conditions, and asserts.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 10

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Dennis Pierce, 310/814-1704
ORGANIZATION
TRW
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Processing Time
RELATED ITEM(S)
TC 15
DISCREPANCY/PROBLEM
In 13.4.2, it is mentioned that commands will not be sent more that 4 per second. What if they are sent faster? Are they lost, is an exception handler defined, etc.
DEVELOPER'S COMMENTS
Add ACIS inter-packet timing constraints to IP&CL. We recommend adding a section to SOP-01 detailing the expected execution times of particular command sequences, e.g. LOAD_PARAMETER, followed by START_RUN, followed by STOP_RUN.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 11

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Leon Rogson, 310/814-4788
ORGANIZATION
TRW R9/1857
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
FEP checking BEP commands
RELATED ITEM(S)
TC 16
DISCREPANCY/PROBLEM
In a number of cases the FEP checks the BEPs command before executing them (see 23.6.1). Computers should not check up on computers.
DEVELOPER'S COMMENTS
We'll review these checks and replace them with asserts where appropriate.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 12

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Leon Rogson, 310/814-4788
ORGANIZATION
TRW R9/1857
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Priorities
DISCREPANCY/PROBLEM
The system (BEP) does not seem to require more than one priority, or even to need fixed timings. Its tasks are to perform commands gotten from the RCTU and some background housekeeping. If a command setup takes a long time, then the observing time is affected, but I need to be convinced that it would not be affected anyhow. You can simplify enormously if you do this. The background task could execute whenever inter-process queries require waiting for the FEP to respond.
DEVELOPER'S COMMENTS
We'll think about this.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 13

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Leon Rogson, 310/814-4788
ORGANIZATION
TRW R9/1857
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Interface Definitions
DISCREPANCY/PROBLEM
It would have been useful to define the interfaces between [the overall concepts, such as memory management, telemetry management, queue usage]. Some [concepts] (handle interrupts, access to I/O registers) seem to be simply place holders for interface definitions.
DEVELOPER'S COMMENTS
A map will be added to SDM03 to point to the section defining the particular interface.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 14

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Leon Rogson, 310/814-4788
ORGANIZATION
TRW R9/1857
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
FEP Data Flow Diagram
DISCREPANCY/PROBLEM
Figure 109 is the closest we come to an overall FEP program data/control flow. It would be very useful to have such an overall flowchart showing the control loop of the FEP, and the overall data flow of the FEP.
DEVELOPER'S COMMENTS
FEP dataflow is shown in Figure 5 on p.49. The section on the fepCtl command handler, which was not ready in time for CDR, contains a more detailed description of FEP control. We'll add a simplified flow chart.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 15

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Leon Rogson, 310/814-4788
ORGANIZATION
TRW R9/1857
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
250 ms Time Limit
RELATED ITEM(S)
TC 10
DISCREPANCY/PROBLEM
In 3.6.3, why the 250 msec time limit? Why do all processCmd() implementations need to complete within 250 msec? (a) the OBC sends a buffer to ACIS at a high bandwidth, therefore the buffer must be placed in a temporary area before processing. Since the OBC can hold 10 512-word buffers (10240 bytes), an area of that size should be set aside. (b) the OBC can also send buffers to ACIS in a continuous stream, but this occurs at < 2 Kbps, so a buffered approach should work given the ACIS throughput. (c) if the 250 msec refers to telemetry, there is no need for a telemetry response to be placed in the telemetry frame next in line. In fact, if I understand ACIS methodology, there may be a considerable amount of data already in the pipeline for the next telemetry frame.
DEVELOPER'S COMMENTS
This constraint, which was imposed in order to simplify ACIS command management, should be directed to the OFLS.
ACTIONEE
TRW/ROGSON
[INDEX]

Tracked Comment 16

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Leon Rogson, 310/814-4788
ORGANIZATION
TRW R9/1857
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
FEP Range Value Check
RELATED ITEM(S)
TC 11
DISCREPANCY/PROBLEM
In 22.5.2.1.4, why is the FEP checking for range values? Having one program (FEP) check another (BEP/OBC/Ground Software) is unnecessary.
DEVELOPER'S COMMENTS
See the developer's comment to TC 11
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 17

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Leon Rogson, 310/814-4788
ORGANIZATION
TRW R9/1857
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
FEP to BEP
RELATED ITEM(S)
TC 18
DISCREPANCY/PROBLEM
In 22.5.3, FEP to BEP, a) Why does the FEP not know when to start the next exposure? Doesn't the BEP tell it when to do this; b) Why does the FEP interrupt the BEP? Why cannot the BEP poll the mailbox as the FEP polls the mailbox from the BEP? Can a wild FEP cause the BEP to crash through a tight interrupt loop?
DEVELOPER'S COMMENTS
The current design appears necessary in order that the FEPs drop the same exposures when their ring buffers become blocked (a science requirement). We'll study this again to see whether we can discover a simpler algorithm.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 18

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Leon Rogson, 310/814-4788
ORGANIZATION
TRW R9/1857
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Ring Buffer Space
RELATED ITEM(S)
TC 17
DISCREPANCY/PROBLEM
In 23.5.2-23.5.5, what happens if there is less space than necessary on the ring buffer? Does the FEP process and wait until buffer space is available? Does it stop processing?
CONSEQUENCES IF NOT CORRECTED
Possible gridlock if a BEP_FEP_CMD_STOP command is sent from BEP to FEP when the ring buffer is full.
DEVELOPER'S COMMENTS
This is explained in 23.5.1 of SDM03--the FEP continues to process the current image frame, but prevents the hardware thresholder from reading the following frames. Once it finishes processing the frame, it informs the BEP and waits until told which frame to process next. We'll think further about avoiding gridlock when BEP_FEP_CMD_STOP is sent to the FEP.
ACTIONEE
ACIS/FORD
[INDEX]

Tracked Comment 19

ITEM REVIEWED
SDM03 ACIS Science Instrument Software Detailed Design Specification (36-53200)
VERSION
01
INITIATOR/PHONE
Leon Rogson, 310/814-4788
ORGANIZATION
TRW R9/1857
DATE
6-26-95
TEAM NAME
ACIS Flight Software, Ford
ISSUE SUBJECT
Patch grouping
DISCREPANCY/PROBLEM
How do you ensure that an "add patch" or "delete patch" is not in the midst of processing when a "reset" occurs.
DEVELOPER'S COMMENTS
We must ensure that patches are applied and removed in groups, so that partially complete groups cannot be applied. This may necessitate our adding a "patch group ID" and "end of patch group flag" .
ACTIONEE
ACIS/FORD
[INDEX]