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]](/icons/index.xbm)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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