ACIS CDR Software RIDS
Last updated:
Thu Nov 30 00:38:00 EST 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.10.4 BEP/FEP Exposure Handshake Protocol
6 TC 6 §17.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
- ISSUE SUBJECT
- Lack of support for EPHIN signals
- INITIATOR/PHONE
- Allyn Tennant, 205/544-3424
- ORGANIZATION
- MSFC ES84
- SUBMISSION DATE
- 6-14-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.14). 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.14. ACIS will generate a
Software Housekeeping record (Table 64) and a Command
Error record. 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- Section §3.2.14 has been
added to the Software Requirements Specification (SDM02) describing the
software response to the EPHIN signal. The implementation is described in
§12.0 and §30.4.5 of the Software
Detailed Design Specification (SDM03).
- IMPLEMENTER
- ACIS/FORD
- IMPLEMENTATION DATE
- 11/29/95
![[INDEX]](/icons/index.xbm)
Tracked Comment 2
- ITEM REVIEWED
- SDM02 ACIS Science Instrument Software
Requirements Specification (36-01103)
- VERSION
- B
- ISSUE SUBJECT
- Suggestion to eliminate window list packets
- INITIATOR/PHONE
- Patrick Broos, 814/863-5505
- ORGANIZATION
- PSU
- SUBMISSION DATE
- 6-11-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- Added text to §3.2.1.3.8 of SDM02
stating that "if more than one parameter block is used to configure a run
(such as a Timed Exposure Parameter Block plus its 2-D Window List), they
may be concatenated into a single packet when dumped to telemetry" . This
is implemented in SDM03 in step 7 of §33.5.3, which
states that "If a window list is used for the run, dumpParameters() gets
the address and length of the list buffer using
windowBlock.getBufferAddress() and windowBlock.getPacketLength(), and
appends the window list to the main parameter block within the telemetry
packet buffer" .
- IMPLEMENTER
- ACIS/FORD
- IMPLEMENTATION DATE
- 11/29/95
Tracked Comment 3
- ITEM REVIEWED
- SDM02 ACIS Science Instrument Software
Requirements Specification (36-01103)
- ISSUE SUBJECT
- The semantics of the "start of run time-stamp"
- INITIATOR/PHONE
- Patrick Broos, 814/863-5505
- ORGANIZATION
- PSU
- SUBMISSION DATE
- 6-11-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- We've added FEP readout time stamps to the Faint Exposure Mode Records
(Table 21 and Table 23 of SDM02, and
IP&CL fields named "FEP Timestamp" ). Note that the BEP restarts the CCDs
before each bias computation, and again before each science run, and both
start times are reported in the telemetry. We've also added a lengthy
explanation of time stamping, entitled "Appendix D - ACIS Time to S/C
Time Guidelines" .
- IMPLEMENTER
- ACIS/FORD
- IMPLEMENTATION DATE
- 11/29/95
Tracked Comment 4
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- §2.9 In-line
assembler code
- INITIATOR/PHONE
- Steve Purinton, 205/544-3804
- ORGANIZATION
- MSFC EJ33
- SUBMISSION DATE
- 6-25-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- We shall move all assembler code into separate files, e.g. startup.S and
fepintr.S for the FEP and startup.S and bepintr.S for the BEP. This will
be described in a rewritten §2.9 of SDM03 and
detailed in §39.0 and §13.0 of that document.
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 5
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- §4.10.4 BEP/FEP
Exposure Handshake Protocol
- INITIATOR/PHONE
- Steve Purinton, 205/544-3804
- ORGANIZATION
- MSFC EJ33
- SUBMISSION DATE
- 6-25-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.10.4. We will update
SDM02 to state this more clearly.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- After canvassing the ACIS science team, we have decided to eliminate the
requirement that dropped frames should be synchronized between the FEPs.
We retain the requirement that FEPs shall only process complete frames,
but no longer insist that if one FEP drops a frame, all the other FEPs
should drop the same frame. This is reflected in a rewritten §3.2.1.3.11 of SDM02 and
extensive simplifying changes to SDM03, e.g. §41.5 and §43.5.
- IMPLEMENTER
- ACIS/FORD
- IMPLEMENTATION DATE
- 12/31/95
Tracked Comment 6
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- §17.15 Class
ChLoad Blk
- INITIATOR/PHONE
- Steve Purinton, 205/544-3804
- ORGANIZATION
- MSFC EJ33
- SUBMISSION DATE
- 6-25-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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 §17.15 to this new
section.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- The management of parameter blocks is fully described in §20.0 of SDM03. The relationship
between type, function, and location is detailed in Table 22 of that
document. We'll update the "TBD" in §17.3.1 to point to §20.0.
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 7
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- Classes, subclasses, objects, etc.
- INITIATOR/PHONE
- Dennis Pierce, 310/814-1704
- ORGANIZATION
- TRW
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- All classes and objects are listed in the "Table of Contents" for SDM03.
We intend to add a sorted index to future versions of this document and
to its Web version, "http://acisweb.mit.edu/sdetail-01" .
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 8
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- Class Category Diagram
- INITIATOR/PHONE
- Dennis Pierce, 310/814-1704
- ORGANIZATION
- TRW
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- We intend to add several Class Category diagrams to SDM03. We have not
yet done so.
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 9
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- Error Handling
- INITIATOR/PHONE
- Dennis Pierce, 310/814-1704
- ORGANIZATION
- TRW
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- Error messages from FEP to BEP are described in §4.10. Command error
scenarios are discussed in §16.5.2. Non-fatal
Software Housekeeping error messages are described in §28.0, and fatal errors are
discussed in §29.0.
- IMPLEMENTER
- ACIS/FORD
- IMPLEMENTATION DATE
- 11/29/95
Tracked Comment 10
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- Processing Time
- INITIATOR/PHONE
- Dennis Pierce, 310/814-1704
- ORGANIZATION
- TRW
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- RELATED ITEM(S)
- TC 15
- DISCREPANCY/PROBLEM
- In §16.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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- All ACIS serial commands are shown with 0.25 second latency in version
TBD of IP&CL. We have not yet asked the authors of SOP-01 to include a discussion of this restriction
in their ACIS Operations Handbook.
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 11
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- FEP checking BEP commands
- INITIATOR/PHONE
- Leon Rogson, 310/814-4788
- ORGANIZATION
- TRW R9/1857
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- RELATED ITEM(S)
- TC 16
- DISCREPANCY/PROBLEM
- In a number of cases the FEP checks the BEPs command before executing
them (see §41.6.1).
Computers should not check up on computers.
- DEVELOPER'S COMMENTS
- We'll review these checks and replace them with asserts where
appropriate.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- Since the shared memory used for the BEP-FEP mailbox uses soft, i.e. non
radiation hardened, RAM, it will be subject to occasional bit flips. Our
policy is to copy the parameter blocks to rad-hardened D-cache as soon as
possible (usually within a few milliseconds), and then to check all
fields for validity. If an error occurs, an appropriate error code is
passed back in the mailbox reply (see §4.10.4) and the BEP
will report it in software housekeeping. The tests are described in §41.6.2, §42.6.3, §43.6.2, and §44.7.3.
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 12
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- Priorities
- INITIATOR/PHONE
- Leon Rogson, 310/814-4788
- ORGANIZATION
- TRW R9/1857
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- The BEP task priorities shown in Table 6 of §4.3.13 are
"logical" rather than "physical" . In practice, we intend to run all
tasks at the same priority unless it is necessary to "tune" the system to
give a higher priority to a particular activity, e.g. the Command
Interrupt. We shall determine this during integration testing.
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 13
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- Interface Definitions
- INITIATOR/PHONE
- Leon Rogson, 310/814-4788
- ORGANIZATION
- TRW R9/1857
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- We have made many changes to §4.0 to clarify the various
hardware interfaces. Our use of objects to "hide" these and other
interfaces within the BEP is a result of our design methodology, and we
intend to add some explanation of this to §3.0, including a map
pointing to the sections of SDM03 that describe the various internal
software interfaces.
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 14
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- FEP Data Flow Diagram
- INITIATOR/PHONE
- Leon Rogson, 310/814-4788
- ORGANIZATION
- TRW R9/1857
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- DISCREPANCY/PROBLEM
- Figure 172 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 of §3.5. 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- Figure 5 of §3.5 has been
embellished. Each high-level FEP function has been given either a data
flow diagram (Figure
172 and Figure
179) or a calling hierarchy diagram (Figure 170, Figure 171, Figure 176, Figure 175, Figure 178, and Figure 182).
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 15
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- 250 ms Time Limit
- INITIATOR/PHONE
- Leon Rogson, 310/814-4788
- ORGANIZATION
- TRW R9/1857
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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.
- DEVELOPER
- TRW/ROGSON
Tracked Comment 16
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- FEP Range Value Check
- INITIATOR/PHONE
- Leon Rogson, 310/814-4788
- ORGANIZATION
- TRW R9/1857
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- RELATED ITEM(S)
- TC 11
- DISCREPANCY/PROBLEM
- In §38.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
- DEVELOPER
- ACIS/FORD
Tracked Comment 17
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- FEP to BEP
- INITIATOR/PHONE
- Leon Rogson, 310/814-4788
- ORGANIZATION
- TRW R9/1857
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- RELATED ITEM(S)
- TC 18
- DISCREPANCY/PROBLEM
- In §38.5, 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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- Having dropped the necessity for all FEPs to ignore the same frames (see
TC 5 ), the BEP is no longer required to poll a
mailbox for messages initiated by the FEP. Instead, all FEP-to-BEP
communication takes place through the ring buffer which is polled by the
BEP. No FEP-to-BEP interrupt is used. When the BEP wishes to know the
status of a FEP, it sends it a BEP_FEP_CMD_STATUS request through its
command mailbox and receives a FEPstatus record in reply, as described in
§4.10.4.8.
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 18
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- Ring Buffer Space
- INITIATOR/PHONE
- Leon Rogson, 310/814-4788
- ORGANIZATION
- TRW R9/1857
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- RELATED ITEM(S)
- TC 17
- DISCREPANCY/PROBLEM
- In §41.5.1-§41.5.4, 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 §41.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.
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- Having dropped the necessity for all FEPs to ignore the same frames (see
TC 5 ), we have removed the FEP-to-BEP mailbox and
redesigned the BEP-to-FEP mailbox so that the FEP will handle incoming
BEP commands while waiting for the ring buffer to become unblocked. This
is discussed in §38.6.20
(low level) and in §40.6.3 (high level).
According to our analysis, this removes the last remaining FEP-to-BEP
interface problem.
- IMPLEMENTER
- ACIS/FORD
Tracked Comment 19
- ITEM REVIEWED
- SDM03 ACIS Science Instrument Software
Detailed Design Specification (36-53200)
- VERSION
- 01
- ISSUE SUBJECT
- Patch grouping
- INITIATOR/PHONE
- Leon Rogson, 310/814-4788
- ORGANIZATION
- TRW R9/1857
- SUBMISSION DATE
- 6-26-95
- TEAM NAME
- ACIS Flight Software, Ford
- 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" .
- DEVELOPER
- ACIS/FORD
- IMPLEMENTATION
- Patch Management is the subject of §14.0. In summary, a BEP reset
may be caused either by a RESET command or by a system crash. If the
former, the current patch list will be applied. If the latter, the patch
list will be ignored. It is therefore the responsibility of the uplink
command system to ensure that sufficient time has elapsed after sending a
series of patches to ACIS before sending a RESET command. We shall note
this in a future version of IP&CL, and also recommend to the authors of
SOP-01 that they include this in their document.
- IMPLEMENTER
- ACIS/FORD