ACIS Software RIDS

Last updated: Wed Feb 22 12:11:39 EST 1995


Table of Contents


1 Withdrawn Serial Commands paragraph 3.1.4.1
2 Comment Document titles
3 ISWP-0001 Pre-loaded Parameter Blocks
4 ISWP-0002 Lack of SQA activities on EGSE
5 Withdrawn Overclock calculation
6 ISWP-0003 spectroscopy science modes
7 ISWP-0004 parameter block propagation
8 Withdrawn lack of BEP data flow diagram(s)
9 Withdrawn 2.3.2 Common Subsection
10 ISWP-0005 3.1.4.4 Serial Telemetry
11 ISWP-0006 3.2.2.3.14 Bias and overclock values
12 Comment 3.2.2.3.11 Pixel Threshold Processing
13 Withdrawn Figure 10: Telemetry Production Scenario.
14 Comment Requirement Breakout
15 Withdrawn Documentation Tree
16 Comment Radiation Monitoring Flag (3.2.13.2)
17 Comment Discrete Commands and Flags (3.1.4.2)
18 ISWP-0007 Generic Load Parameter Block Command Packet CRC Check (3.2.1.3)
19 Comment Minor Editorial to 3.2.1.3.4 and 3.2.1.3.5
20 ISWP-0008 No Diagnostic Flag Listed
21 Comment No Standby Flag Listed
22 Comment Refinement of Parameter Block Definition
23 Comment On-line Boot
24 Withdrawn Overclock data type
25 Withdrawn para 3.2.2.3.8 Spatial Histogram Processing
26 Comment Front End Event-finding Mode: 3.2.2.3.12 (p. 54)
27 ISWP-0009 Bad Pixel and Column Maps: 3.2.2.3.13 (p.55]
28 Withdrawn requirements matrix
29 ISWP-0010 Software timing information
30 ISWP-0011 software interfaces
31 ISWP-0012 multiple instances of length
32 ISWP-0013 Boot Modifier Flag
33 Comment Science Run
34 Comment Error processing in ACIS Science Run, p.37
35 Withdrawn timed maps
36 Comment old programmers
37 Withdrawn custom event processing
38 ISWP-0014 Fatal error recovery
39 ISWP-0015 backlogged data & Radiation Counter, p.104
40 Withdrawn classes to create C++ objects
41 ISWP-0016 Error returns
42 Withdrawn Booting from ROM
43 Withdrawn ACIS Time Stamp
44 Withdrawn start up services
45 Withdrawn permanent memory error
46 Withdrawn I/O library
47 Comment no minor frame interrupt
48 ISWP-0017 time to handle
49 Withdrawn parity error in backend processor
50 Withdrawn count field
51 Withdrawn packet length error
52 Withdrawn "client" of the command packet object
53 Comment ACIS word
54 Comment all interfaces established
55 Comment table 12
56 Comment What happens upon error?
57 Withdrawn Timing information is needed
58 Comment Why is there a need for an "interface layer
59 Comment Will you have tasks of the same priority?
60 Comment Semaphore management present a single event failure possibility.
61 Withdrawn The set/clear radiation flag conditions are unclear
62 Withdrawn "Length" or "Length-3"?
63 Comment Verbose mode needs to be explained.
64 Comment "may cause reset of telemetry system"

1. Withdrawn item #1

ISSUE SUBJECT
Serial Commands paragraph 3.1.4.1
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
Commands should be detailed in the requirements document for the purpose of design and test.
INITIATOR/PHONE
Steve Purinton 204-544-3804
ORGANIZATION
EJ33
TEAM NAME
Software
DEVELOPER'S COMMENTS
We don't see this as a discrepancy because serial commands are listed in Appendix A of the document. We shall, however, add a reference to this appendix in 3.1.4.1. A complete bit-level description of serial commands and parameter blocks, and of ACIS serial telemetry, will be presented at the ACIS SW CDR in a TBD format as part of ACIS IP&CL.;
[INDEX]

2. Comment #1

ISSUE SUBJECT
Document titles
DISCREPANCY/PROBLEM
Documents should reflect the required deliverables on the contract. These are defined by the Data Procurement Document DPD. The Software Management Plan, Software Configuration Management Plan, Software Development plan, Software Quality Assurance Plan, and Software Standards and Procedures should be volumes or sections of the Management Plan SMA01. The mmi 8075.1 is a guide for content, phase, reviews, etc.
INITIATOR/PHONE
Steve Purinton 205-544-3804
ORGANIZATION
EJ33
DATE
10/25/94
TEAM NAME
Software
DEVELOPER'S COMMENTS
The documents will be given numbers that indicate that they are descendent from SMA01--the Software Requirements Specification will be numbered SDM02, the Software Preliminary Design Specification will be DM03, and the Software Management and Design Plans will be SMA01_P.
[INDEX]

3. RID ISWP-0001 (t-r-2)

ISSUE SUBJECT
Pre-loaded Parameter Blocks
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
Para 3.2.1.3.2. Having a set of "loadable" parameter blocks implies knowledge of the onboard configuration. The ASC will not have this knowledge because it does not do mission planning. The offline software at the OCC performs this task. To perform a upload the offline software would have to schedule observations then upload a set of parameter blocks. This fairly complex sequence cannot be tested because ACIS is delivered before the offline software is built or available for testing.
CONSEQUENCES IF NOT CORRECTED
Untested feature in software
INITIATOR'S SUGGESTED CORRECTIVE ACTION
Restrict preload parameter blocks to those in ROM and a single block uploaded with an observation for immediate execution
INITIATOR/PHONE
Steve Purinton 205-544-3804
ORGANIZATION
EJ33/NASA
DATE
October 25, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We do not see this as a significant issue in the preliminary ACIS design. We had assumed that multiple ACIS parameter blocks would be useful in reducing the size of stored OBC commands. The situation should be discussed at the PDR team meeting.
REMARKS
A Systems Engineering TIM will be held to resolve the requirements and capabilities between ACIS, ASC and the OCC/OFLS. A Systems Engineering Team will ensure existing working groups (MPSWG & CWG) resolve capabilities.
ACTIONEE
EJ33/S. Purinton
SUSPENSE DATE
February 3, 1994
[INDEX]

4. RID ISWP-0002 (t-dp-3)

ISSUE SUBJECT
Lack of SQA activities on EGSE
ITEM REVIEWED
36-01212-02
DISCREPANCY/PROBLEM
No software quality assurance activities performed by MIT/CSR SQA on Electronic Ground Support Equipment (EGSE) used to calibrate and validate various aspects of the ACIS instrument, as stated in CSR/MIT Software Quality Assurance Plan (9/27/94), paragraph 2 APPLICABILITY . The requirements of CQ 5330.1A, paragraph 2.0 defines the software categories to which SQA requirements are potentially applicable. Subitem 3 covers software used for testing or acceptance of deliverable software or hardware.
CONSEQUENCES IF NOT CORRECTED
No assurance of the development process of this software will specified requirements or system performance requirements.
INITIATOR'S SUGGESTED CORRECTIVE ACTION
MIT/CSR SQA shall provide SQA activities on software used for the testing or acceptance of deliverable software or hardware.
INITIATOR/PHONE
George Mitchell 205-544-8577
ORGANIZATION
CR32/PRC
DATE
10-25-94
TEAM NAME
Software
DEVELOPER'S COMMENTS
ACIS EGSE is under a parallel management structure. A RID should be issued against the GSE CEI Specification. We'll then remove any mention of EGSE SQA from our flight software documents.
REMARKS
The EGSE software SQA will be removed from DM01 and will be added to the EGSE CEI Specification.
ACTIONEE
B. Blozie
SUSPENSE DATE
2-17-95
[INDEX]

5. Withdrawn item #2

ISSUE SUBJECT
Overclock calculation
RELATED ISSUES
t-d-32
ITEM REVIEWED
36-01103-03 DR DM06
DISCREPANCY/PROBLEM
When computing the overclock level, the possibility of a zero-point correction (i.e. a mean value) for the overclock value is only considered. Such a characterization of the overclock value is reasonable when the overclock is not ramped or structured. In some cases, a linear or spline fit to the overclock region may be more appropriate.
CONSEQUENCES IF NOT CORRECTED
In principle, there could be some loss of energy resolution, but the effect would probably be small.
INITIATOR/PHONE
McNamara 617-496-7718 SAO/ASC
ORGANIZATION
SAO
DATE
26 Oct 1994
DEVELOPER'S COMMENTS
The overclock value is not expected to change from row to row. Separate averages will be computed for each CCD quadrant, to be used for event detection in the next exposure to be processed. A presentation on bias and overclocking will be made during the PDR team meeting.
[INDEX]

6. RID ISWP-0003 (t-r-5)

ISSUE SUBJECT
spectroscopy science modes
ITEM REVIEWED
S/W Requirements Spec.
DISCREPANCY/PROBLEM
This section does not adequately describe the requirements for special science modes involving the transmission gratings. The bright source mode presently mentioned (in which the central CCD, containing the 0th order image, is exposed for less time than the outer CCDs), while avoiding photon pileup in the 0th order image, involves a significant decrease in observing efficiency for the highest-energy parts of the spectrum. It is unlikely to be utilized.
CONSEQUENCES IF NOT CORRECTED
The gratings will be under-utilized, and their full science potential not tapped.
INITIATOR'S SUGGESTED CORRECTIVE ACTION
Two potentially far more useful modes that should be included in the requirements spec are:
  1. A variation of the mode presently described, in which only a subarray of the central CCD is read out, while all rows of the other 5 CCDs are read out. With a suitably chosen number of rows in the subarray, it would be possible to obtain several shorter exposures on the central chip for each 2.6 sec exposure on the other chips, thus reducing the amount of observing dead time for the central CCD.
  2. Perform short exposures on *all* 6 CCDs for every N "normal" exposures, where N would be a selectable parameter. Given a suitable choice for N, pileup could be avoided in the short-exposure dataset (allowing one to extract the 0th order image PHA spectrum), while the entire spectrum could still be reconstructed from a uniform, "normal" exposure dataset.
INITIATOR/PHONE
Joel Kastner 617-253-3875
ORGANIZATION
MIT/ASC
DATE
26 Oct 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Considerable apprehension has been expressed by ACIS hardware developers that CCDs that are not clocked synchronously may produce electronic interference that will degrade the overall system performance. We have therefore concentrated on providing an operating mode identical to suggestion 2) above. This is achieved by adding hardware to the DEAs that implement a loop instruction in the PRAM command language that directs CCD clocking. Suggestion 1) will also be studied-it would require a different throttling algorithm in the BEP to guarantee a "democratic" reporting of events when the downlink bandwidth is fully utilized.
REMARKS
Block 13, mode 2 has been accepted and mode 1 has been studied and rejected.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
Added 'Primary and Secondary Exposure Times' and 'Exposure Duty Cycle' to Table 11 of 36-01103. Their use in spectroscopy science modes is described in 3.2.4 of that document.
[INDEX]

7. RID ISWP-0004 (t-d-6)

ISSUE SUBJECT
parameter block propagation
RELATED ISSUES
ISWP-0001
ITEM REVIEWED
Prelim. Design Spec.
DISCREPANCY/PROBLEM
It is not clear from the document how the design would allow the association of an observation with a particular parameter block, or how the parameter values used to configure the instrument would be obtained from (or input to) the telemetry stream.
CONSEQUENCES IF NOT CORRECTED
It will be difficult to determine the instrument's state during a particular observation.
INITIATOR'S SUGGESTED CORRECTIVE ACTION
Include a concise discussion of the flow of parameter blocks to and from the on-board computer, and of how these blocks will be relatable to associated science data.
INITIATOR/PHONE
Joel Kastner 617-253-3875
ORGANIZATION
MIT/ASC
DATE
26 Oct 1994
DEVELOPER'S COMMENTS
Parameter blocks will contain a unique 32-bit identifier, created at ASC, included in the OBC command, sent to ACIS, and echoed in the event data telemetry blocks. We'll explain this more fully in the Requirements Specification and in the Preliminary Design Spec. It will become cleared in the bit-level descriptions of parameter blocks and downlink telemetry to be submitted to the CDR.
REMARKS
An identifier will be added to the parameter block. The Systems Engineering team will ensure the ASC has the requirement to generate and track the identifier. The identifier will be in the IP&CL.;
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
Added 'Parameter Block Identifier' fields to Tables 11, 13, 26, and 28 of 36-01103, and a 'Get Parameter Block Identifier' function to Table 32 of 36-02402.
[INDEX]

8. Withdrawn item #3

ISSUE SUBJECT
lack of BEP data flow diagram(s)
DISCREPANCY/PROBLEM
No data flow diagram is included for data processing by the back end processors.
CONSEQUENCES IF NOT CORRECTED
The design description will be incomplete
INITIATOR'S SUGGESTED CORRECTIVE ACTION
Include a data flow diagram(s) for the BEP that is analogous to that provided in Sec. 15.0 for the FEP.
INITIATOR/PHONE
Joel Kastner 617-253-3875
ORGANIZATION
MIT/ASC
DATE
26 Oct 1994
DEVELOPER'S COMMENTS
We don't consider it necessary to include a BEP dataflow diagram in this document. A dataflow diagram of BEP science processing is included in the Requirements Spec., Figure 20, p. 45. It doesn't appear in the Preliminary Design Document because we are using object oriented design methodology to design this multi-tasking system, for which the overview of Figure 13, combined with that of the various managers is more useful. The FEP, which is a single task, is being designed by structured methodology, for which the dataflow diagram of Figure 16 is more appropriate and useful.
[INDEX]

9. Withdrawn item #4

ISSUE SUBJECT
2.3.2 Common Subsection
RELATED ISSUES
ISWP-0003
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
The ACIS hardware now has individual common sections for each CCD, raising the possibility that each CCD may be read out with different clocking parameters. Nowhere in this document is the software's capability to support different clocking schemes for the separate CCDs discussed. If there a reason why different clocking schemes cannot be supported (for either hardware or software reasons) it should be discussed in the appropriate document and the impact on other special modes, such as subarray reads, examined.
CONSEQUENCES IF NOT CORRECTED
Underutilization of existing hardware and/or confusion about the present capabilities.
INITIATOR'S SUGGESTED CORRECTIVE ACTION
explicitly state if the software supports different clocking parameters for the different CCDs.
INITIATOR/PHONE
Paul Plucinsky 617-496-7726
ORGANIZATION
SAO/ASC
DATE
26 Oct 1994
DEVELOPER'S COMMENTS
See response to ASC comment on ISWP-0003.
[INDEX]

10. RID ISWP-0005 (t-r-8)

ISSUE SUBJECT
3.1.4.4 Serial Telemetry
ITEM REVIEWED
36-02402-01 36-01103-03
DISCREPANCY/PROBLEM
The requirements document states "The (telemetry) formats shall provide enough information to allow data sets to be interpreted in situations where one or more previous data sets has been corrupted or lost." I cannot find the sections in the design document which explain these formats and how they ensure that the data can be reconstructed.
CONSEQUENCES IF NOT CORRECTED
Possible data loss.
INITIATOR'S SUGGESTED CORRECTIVE ACTION
Explain how the data can be reconstructed in at least the following two scenarios: a) the BEP fills its event buffer and stops processing CCD frames b) data is corrupted in the transmission process
INITIATOR/PHONE
Paul Plucinsky 617-496-7726
ORGANIZATION
SAO/ASC
DATE
26 Oct 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll add text to the preliminary design spec. to explain that (a) events from different exposures or different CCDs will never be grouped in the same telemetry packet, and (b) packets will contain a synchronization code, exposure number, and CCD number. Temporary loss of telemetry will not therefore affect the recovery of subsequent packets. If the BEP output buffer is full, the BEP will tell the FEPs to drop entire exposures rather than risk reporting partial frames.
REMARKS
Accept per block 14 and will add text to the Software Requirements with the description of the policy for detecting processor saturation and the dropping of exposures and detection of same.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
Added a description of the 'Start of ACIS Telemetry Packet Indicator' to Table 5 of 36-01103, and a discussion of data packets and saturation behavior to 3.2.1.3.10 and 3.2.1.3.11 of the same document. The packet format is further described in Table 27 of 36-02402.
[INDEX]

11. RID ISWP-0006 (t-r-9)

ISSUE SUBJECT
3.2.2.3.14 Bias and overclock values
RELATED ISSUES
Item 5
ITEM REVIEWED
36-02402-01 36-01103-03
DISCREPANCY/PROBLEM
The note under Figure 22 states that the bias and overclock levels are sent with the pixel data in faint mode and not in "graded mode". 1) I do not see in the design document section 11.4.2 "Event representation" where the bias value is included 2) Will any information on the bias be included in the "graded mode" ?
CONSEQUENCES IF NOT CORRECTED
Required data not included with each event
INITIATOR'S SUGGESTED CORRECTIVE ACTION
Explain how bias and overclock values are sent with the data in faint and "graded" mode.
INITIATOR/PHONE
Paul Plucinsky 617-496-7726
ORGANIZATION
SAO/ASC
TEAM NAME
Software
DEVELOPER'S COMMENTS
This is currently under study. It will be included in a presentation on bias and overclocking to be made during the PDR team meeting.
REMARKS
Means of downlinking the bias values evaluated during design. The ability to trickle the bias within the downlink depends upon hardware. Other methods are operational and may include time during SIM movement, maneuvers, etc.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
Pixel bias values are either downlinked in Faint-Bias Mode or are trickled down as Pixel Bias Map Telemetry. The former is described in 3.2.2.3.22 and Table 22 of 36-01103, and the latter in 3.2.2.3.24 of the same document. Bias values are accessed in the BEP via the 'Get Pixel Bias' function described in Table 37 of 36-02402.
[INDEX]

12. Comment #2

ISSUE SUBJECT
3.2.2.3.11 Pixel Threshold Processing
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
A counter of pixel threshold crossings is created and telemetered. Does this counter include or exclude bad pixels ? Is this counter sent with each CCD exposure ? Is there also a counter for number of events accepted as X-rays? Are there independent counters for each CCD ? In my naive view of the CCD world, it is possible to classify four "types" of pixel threshold crossings which are all included in this counter: a) threshold crossing counter 1: real X-rays 2: cosmic rays/ charged particles 3: hot pixels (supposedly in the bad pixel map. 4: flickering pixels (not in the bad pixel map) b) accepted event counter 1: real X-rays 2: flickering pixels. Now we will know the number of bad pixels in the bad pixel map, thus (a-b) - (# of bad pixels) = cosmic ray/particle background rate. If these two counters are indeed available for each CCD, I believe we have all the useful information we could hope to have.
CONSEQUENCES IF NOT CORRECTED
Insufficient diagnostic information to diagnosis detector problems.
INITIATOR'S SUGGESTED CORRECTIVE ACTION
Define the existence of the two counters and state what the counters actually count.
INITIATOR/PHONE
Paul Plucinsky 617-496-7726
ORGANIZATION
SAO/ASC
DATE
October 26, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
A count of threshold crossings and identified X-ray events are maintained in the BEP exposure log and will be included in the telemetry stream as an "exposure report" described in 11.6.4. Two additional counts are maintained-bad pixels and those whose bias map values suffered a parity error during the Science run. A discussion of these items will be included in a presentation on bias and overclocking to be made during the PDR team meeting.
[INDEX]

13. Withdrawn item #5

ISSUE SUBJECT
Figure 10: Telemetry Production Scenario.
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
Are there two separate boxes for "application-specific code" for a reason ?
CONSEQUENCES IF NOT CORRECTED
Mild confusion.
INITIATOR'S SUGGESTED CORRECTIVE ACTION
Explain or correct.
INITIATOR/PHONE
Paul Plucinsky 617-496-7726
ORGANIZATION
SAO/ASC
DATE
October 26, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
This comment was withdrawn during the teleconference. Since the BEP is a multi-tasking system, it is quite natural that a manager should accept messages from more than one source.
[INDEX]

14. Comment #3

ISSUE SUBJECT
Requirement Breakout
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
The document does not have a traceable requirement structure. Currently, there are more than one traceable requirement per section number. If it is a true requirements document, it should have all requirements spelled out and numbered separately.
CONSEQUENCES IF NOT CORRECTED
Lower level requirement documentation will not be able to make direct traces from lower level requirements to higher level requirements.
INITIATOR'S SUGGESTED CORRECTIVE ACTION
Break out requirements from current paragraph format into an individually numbered requirement format for purposes of traceability.
INITIATOR/PHONE
Andrew Keys (205)544-8038
ORGANIZATION
EO37/MSFC/NASA
DATE
October 20, 1994
DEVELOPER'S COMMENTS
A complete Requirements Traceability Matrix is being prepared and will be submitted to CDR as a separate ACIS document. For PDR, we'll include a small subset of this matrix as an appendix to the Requirements Spec.
REMARKS
MIT/Blozie, EO37/Keys and TRW/Rogson should talk.
[INDEX]

15. Withdrawn item #6

ISSUE SUBJECT
Documentation Tree
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
Include a documentation tree as a part of each document or as a separate reviewable document.
INITIATOR/PHONE
Andrew Keys (205)544-8038
ORGANIZATION
EO37/MSFC/NASA
DATE
October 20, 1994
DEVELOPER'S COMMENTS
The Documentation Tree is Figure 1 of the SW Development Plan, #36-12-9-2. We believe that this is the appropriate place for it. Each remaining SW document contains references to specific documents that apply to it, along with a reference to the Development Plan.
[INDEX]

16. Comment #4

ISSUE SUBJECT
Radiation Monitoring Flag (3.2.13.2)
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
This flag should be able to be set manually from the ground or the OBC for testing purposes. Reflect this change in the scenario of section 3.2.13.2, and in Table 3 of section 3.1.4.2. (It is acknowledged that the ground could set configurable radiation level threshold to such an unreasonably low level that the flag is set by the radiation monitor - but this is approach is very indirect.)
CONSEQUENCES IF NOT CORRECTED
Inability to test (from the ground) the reaction of ACIS to asserted radiation monitor flag.
INITIATOR/PHONE
Andrew Keys (205)544-8038
ORGANIZATION
EO37/MSFC/NASA
DATE
October 20, 1994
DEVELOPER'S COMMENTS
The Radiation Monitor signal is a discrete RCTU command. ACIS flight SW will test it through CTUE simulation. A RID has been issued against the OBC software requirements specification to send a simulated Radiation Monitor signal to ACIS.
[INDEX]

17. Comment #5

ISSUE SUBJECT
Discrete Commands and Flags (3.1.4.2)
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
The Standby Flag in Table 3 of section 3.1.4.2 should be able to be set manually from the ground or the OBC (as well as by the S/C Power Control) for testing purposes.
CONSEQUENCES IF NOT CORRECTED
Inability to activate (from the ground) the ACIS low power consumption mode.
INITIATOR/PHONE
Andrew Keys (205)544-8038
ORGANIZATION
EO37/MSFC/NASA
DATE
October 20, 1994
DEVELOPER'S COMMENTS
The Standby signal is a discrete RCTU command. ACIS flight SW will test it through CTUE simulation. A RID has been issued against the OBC software requirements specification to send a simulated Standby signal to ACIS.
[INDEX]

18. RID ISWP-0007 (t-r-14)

ISSUE SUBJECT
Generic Load Parameter Block Command Packet CRC Check (3.2.1.3)
RELATED ISSUES
Item 51
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
Specify that the CRC is checked by the ACIS Software upon receipt. Also specify what occurs if the CRC check fails. Is there any indication back to the OBC/Ground Systems that the Command Block failed CRC check?
CONSEQUENCES IF NOT CORRECTED
Loss of Parameter Blocks possible if rejected because of bad CRC.
INITIATOR/PHONE
Andrew Keys (205)544-8038
ORGANIZATION
EO37/MSFC/NASA
DATE
October 20, 1994
DEVELOPER'S COMMENTS
Present plans call for a command or parameter block with bad CRC to be disregarded, and a report to be written to the downlink telemetry. After receiving a bad command, ACIS will wait until no further serial commands are received within a TBD timeout interval, then its input FIFO will be flushed and ACIS will wait for the next serial command. We'll rewrite the Preliminary Design Specification to make these activities clearer to the reader.
REMARKS
Policy for bad CRC will be added to the SW requirements.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
Parameter block CRC handling and error recovery is discussed in 3.3.5 of 36-01103.
[INDEX]

19. Comment #6

ISSUE SUBJECT
Minor Editorial to 3.2.1.3.4 and 3.2.1.3.5
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
Both sections reference Table 6 where they should reference Tables 7 and Table 8 respectively.
INITIATOR/PHONE
Andrew Keys (205)544-8038
ORGANIZATION
EO37/MSFC/NASA
DATE
October 20, 1994
DEVELOPER'S COMMENTS
We'll update the document.
[INDEX]

20. RID ISWP-0008 (t-d-15)

ISSUE SUBJECT
No Diagnostic Flag Listed
ITEM REVIEWED
ACIS SI SW Prelim Design Spec
DISCREPANCY/PROBLEM
In Section 7.1, Figure 7 lists all ACIS commands according their system features. The "Set Diagnostic Flag" and "Clear Diagnostic Flag" discrete commands are not mentioned. These commands are implied from Table 3 of the ACIS SI SW SRS as being commands that the ground (or OBC?) can issue.
CONSEQUENCES IF NOT CORRECTED
No method would be provided to set or clear the diagnostic flag in the hardware status registers..
INITIATOR/PHONE
Andrew Keys (205)544-8038
ORGANIZATION
EO37/MSFC/NASA
DATE
October 20, 1994
DEVELOPER'S COMMENTS
The Set/Clear Diagnostic Flag signals are discrete RCTU commands that are not sensed by ACIS software. They are described in the ACIS IP&CL; tables. It is most likely that they will only be used during preliminary testing and that ACIS flight hardware will not respond to them in any way.
REMARKS
ACIS will remove the "set and clear diagnostic flag" from software documents.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
Mention of the Diagnostic Flag has been expunged from 36-01103.
[INDEX]

21. Comment #7

ISSUE SUBJECT
No Standby Flag Listed
ITEM REVIEWED
ACIS SI SW Prelim Design Spec
DISCREPANCY/PROBLEM
In Section 7.1, Figure 7 lists all ACIS commands according their system features. The "Set Standby Flag" and "Clear Standby Flag" discrete commands are not mentioned. These commands are implied from Table 3 of the ACIS SI SW SRS as being commands that the S/C Power Controller can issue.
CONSEQUENCES IF NOT CORRECTED
No method would be provided to set or clear the diagnostic flag in the TBD
INITIATOR/PHONE
Andrew Keys (205)544-8038
ORGANIZATION
EO37/MSFC/NASA
DATE
October 20, 1994
DEVELOPER'S COMMENTS
The Set/Clear Standby Flag signals are discrete RCTU commands. They are described in the ACIS IP&CL; tables. ACIS flight SW will test them through CTUE simulation. Although the flag will be available to the BEP software as part of a hardware status register, there are currently no plans to use it.
[INDEX]

22. Comment #8

ISSUE SUBJECT
Refinement of Parameter Block Definition
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
A draft of ACIS parameter blocks dated June 7, 1994 specifies the sizes in bits of each field included in a Time-Exposure Parameter Block, a Continuous-Clocking Parameter Block, a 2-Dimensional Processing Window Parameter Block, a 1-Dimensional Processing Window Parameter Block, and overall Command Packet Formats. This level of detail should be included in the SRS's parameter block definitions - including quantity of occurrences of each field, bit lengths of each field, and total number of bytes for each type of parameter block.
CONSEQUENCES IF NOT CORRECTED
Incomplete parameter block definitions.
INITIATOR/PHONE
Andrew Keys (205)544-8038
ORGANIZATION
EO37/MSFC/NASA
DATE
October 20, 1994
DEVELOPER'S COMMENTS
Parameter blocks are listed in Appendix B of this document, and their contents are described in the referenced pages. A complete bit-level description of serial commands and parameter blocks, and ACIS serial telemetry, will be presented at the ACIS SW CDR in a TBD format as part of ACIS IP&CL.;
[INDEX]

23. Comment #9

ISSUE SUBJECT
On-line Boot
RELATED ISSUES
ISWP-0013, Item 42
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
The "on line boot", i.e. booting from the commands being passed to ACIS, may be too long and therefore difficult to implement.
INITIATOR/PHONE
Bill Peterson
ORGANIZATION
TRW
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
On Sheets #32 and #42, Leon Rogson has suggested a method of booting that would practically eliminate the need for the "uplink boot". We'll study whether it makes sense to include it at all, e.g. for pre-launch testing.
[INDEX]

24. Withdrawn item #7

ISSUE SUBJECT
Overclock data type
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
(1) SRS 3.2.2.3.6 (p. 52): I assume the Overclock Level will be stored as a non-negative integer. This is not stated.
INITIATOR/PHONE
Eric Martin
ORGANIZATION
TRW
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Sizes and ranges of numeric items are not specified at this level of design. The Overclock Level will, however, be a set of 4 non-negative integers, one per CCD quadrant, computed from one FEP exposure frame and applied to the next that is processed.
[INDEX]

25. Withdrawn item #8

ISSUE SUBJECT
para 3.2.2.3.8 Spatial Histogram Processing
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
(2) SRS 3.2.2.3.8 (p. 53): The first paragraph of this section needs to be clarified
INITIATOR/PHONE
Eric Martin
ORGANIZATION
TRW
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
This is currently under study. It will be included in a presentation on bias and overclocking to be made during the PDR team meeting.
[INDEX]

26. Comment #10

ISSUE SUBJECT
Front End Event-finding Mode: 3.2.2.3.12 (p. 54)
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
(3) SRS 3.2.2.3.12 (p. 54): I assume the pulse height of the center pixel must exceed the values for each individual surrounding pixel. This is not clear.
INITIATOR/PHONE
Eric Martin
ORGANIZATION
TRW
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
3.2.2.3.12 will be reworded to clarify the event-finding mode, including the case of equal pixel values.
[INDEX]

27. RID ISWP-0009 (t-r-21)

ISSUE SUBJECT
Bad Pixel and Column Maps: 3.2.2.3.13 (p.55]
ITEM REVIEWED
ACIS SI Software Reqs Spec
DISCREPANCY/PROBLEM
(4) SRS 3.2.2.3.13 (.55; second paragraph): "If the center pixel is in the [Bad Pixel and Column Map] ...". What about bad pixels in the surrounding 8?
INITIATOR/PHONE
Eric Martin
ORGANIZATION
TRW
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
3.2.2.3.13 will be updated to better describe the treatment of bad pixels-for the purposes of grading, they are considered to have zero value, but their presence will be indicated in faint mode.
REMARKS
Paragraph 3.2.2.3.13 will be rewritten to clarify
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
Treatment of 'bad' pixels in the BEP is described in the re-worded 3.2.2.3.13 of 36-01103.
[INDEX]

28. Withdrawn item #9

ISSUE SUBJECT
requirements matrix
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
There is no requirements matrix showing how each paragraph in the document is to be tested. Paragraph 5 refers to a requirement traceability matrix, but this is not a part of the package.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
A complete Requirements Traceability Matrix is being prepared and will be submitted to CDR as a separate document. For PDR, we'll include a small subset of this matrix as an appendix to the Requirements Spec. Note: this comment should be merged with Andrew Keys' comment on sheet 14.
[INDEX]

29. RID ISWP-0010 (t-r-23)

ISSUE SUBJECT
Software timing information
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
Software timing information and budgets are conspicuously absent. 3.3 mentions some parameters, in particular the ability to process over 1000 threshold crossings per CCD per second, but this is never broken down or associated with the functional requirements in previous paragraphs.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll study this and discuss it at the PDR reviewers team meeting.
REMARKS
ACIS will establish the timing budget by Software CDR and will provide the scenarios for which the budget applies.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
6-30-95
[INDEX]

30. RID ISWP-0011 (t-r-24)

ISSUE SUBJECT
software interfaces
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
The operating system controlling the backend processor is mentioned but its characteristics are not defined. Neither are the software interfaces between the backend processor and the front end processor explained.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We believe that this comment was withdrawn. We referenced the Nucleus RTX operating system manual in the Requirements Specification. The interface between the FEPs and the BEP wasn't designed when the PDR material was presented. It will be described fully in the CDR materials.
REMARKS
ACIS will describe the FEP/BEP interfaces in the Software Design Document.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
6-30-95
[INDEX]

31. RID ISWP-0012 (t-r-25)

ISSUE SUBJECT
multiple instances of length
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
Many of the command packets have multiple instances of length information. Such information is only necessary if more than one section of the packet is of variable length.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Redundant lengths will be identified and removed.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
Redundant length fields have been removed from the telemetry packet contents described in Tables 16-25 (timed exposure mode), and 30-37 (continuous exposure mode) of 36-01103.
[INDEX]

32. RID ISWP-0013 (t-r-26)

ISSUE SUBJECT
Boot Modifier Flag
RELATED ISSUES
Item 23, Item 42
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
p.32, 102 - Boot Modifier Flag: The whole method of booting and updating patches should be reviewed with an eye on simplification. A hardware switch should be made available that the bootstrap software can reset before it starts applying patches. When a patch causes the boot to fail, a subsequent boot will see that the hardware switch has been reset, and this would cause it to boot in its original, pristine, unpatched fashion. The idea of patching during a boot process directly from an external input seems to violate the premise that AXAFI is an unattended spacecraft. Also this system would prevent unnecessary, continuous looping if a "patch from input" fails.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll study this method of booting. Comments #23 and #42 should be merged with this. It is not clear, however, whether situations might not arise in which an "uplink boot" was the only way of restarting ACIS.
REMARKS
ACIS will rename "Boot from uplink" to "Load from uplink" and add the capability to bypass patches.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
The logic to be followed when rebooting after a watchdog reset is described in 3.2.11.2 of 36-01103, and the operation of loading from command input is discussed in 3.2.12 of the same document.
[INDEX]

33. Comment #11

ISSUE SUBJECT
Science Run
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
P35 - Change Science Run to ACIS Run, HRC is also science.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll change our documents to call it "ACIS Science Run".
[INDEX]

34. Comment #12

ISSUE SUBJECT
Error processing in ACIS Science Run, p.37
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
P37 - Dispatch Command should have an arrow to Send Telemetry showing that the reception of bad commands results in the creation of a bad command report which is telemetered to the ground. Error processing of incoming signals should be a standard operation in ACIS, as it is within the OBC.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Path to "Write Error Log" was omitted from Figure 16. It will be squeezed in someplace.
[INDEX]

35. Withdrawn item #10

ISSUE SUBJECT
timed maps
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
P42-44 - The timed maps should have more explanation attached to them. They look like timing diagrams, and if possible, should have timing information attached to them.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
These are Sequence Diagrams as defined in the work by Booch referenced in Table 1 of the Preliminary Design Spec. Their ordinates are not intended to be interpreted as common timelines.
[INDEX]

36. Comment #13

ISSUE SUBJECT
old programmers
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
P57 Identify the Grade Code as being hexadecimal. 0x021 could be interpreted by old programmers as 000 010 001 (octal) which is not what was intended.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll change the document to make it clear that constants beginning 0x are always hexadecimal.
[INDEX]

37. Withdrawn item #11

ISSUE SUBJECT
custom event processing
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
P64 - "If the loaded parameter block requires custom event processing windows.." This capability is not mentioned in other modes, yet seems orthogonal to other parameters. Is this an oversight?
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We think that this comment was withdrawn. Event processing windows are explained in some detail (2-D for timed exposure mode in 3.2.2.3.18, 1-D for continuous exposure mode in 3.2.3.3.2).
[INDEX]

38. RID ISWP-0014 (t-r-29)

ISSUE SUBJECT
Fatal error recovery
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
P96 - Fatal error recovery should not include a good faith attempt at finishing the current data dump to telemetry. Put a "fatal error occurred" message in the telemetry bucket and re-boot.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We explained that we only intended to flush out the current telemetry "item" (i.e. block.) This is being performed by a separate DMA. When this completes, we'll send a short error message and then reboot.
REMARKS
ACIS will add text from block 14.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
The steps to be taken to recover from a fatal error, i.e. attempting to flush only the current telemetry packet to the RCTU, etc., are described in a reworded 3.2.9.3.6 of 36-01103.
[INDEX]

39. RID ISWP-0015 (t-r-30)

ISSUE SUBJECT
backlogged data & Radiation Counter, p.104
ITEM REVIEWED
36-01103-03
DISCREPANCY/PROBLEM
P104 - if the radiation counter goes off, the CCDs are unpowered. However, there is no reason to stop sending backlogged data to Telemetry. This should be stated here.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We intend to continue sending data when the radiation counter is asserted. This will be affirmed in the document.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
When the radiation monitor signal is received, the ACIS BEP will continue to process backlogged event data from the FEPs, but initiate no fresh exposures. This is described in a rewritten 3.2.13.2 of 36-01103.
[INDEX]

40. Withdrawn item #12

ISSUE SUBJECT
classes to create C++ objects
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
You use classes to create C++ objects. In general, however, the classes seem to be a single instance of the object so that I tend to question its usefulness.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We believe that this comment was withdrawn. While some parts of the BEP system, e.g. the command manager, employ mostly static class instances, others more naturally use dynamic classes, e.g. those relating to the 6 FEPs, 6 DEAs, 10 CCDs, and multiple event and telemetry packets.
[INDEX]

41. RID ISWP-0016 (t-d-31)

ISSUE SUBJECT
Error returns
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
Error returns, how the ground learns of on-board problems, and how the on board system reacts to discovered problems is somewhat sketchy and should be amplified. What happens after the back end processor has reset?
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Our intention is that the OBC should not respond to ACIS problems. We believe that there will be sufficient information in the downlink telemetry to permit the problem to be diagnosed. In particular, after ACIS reboots, it will transmit a telemetry record indicating the reason for the reboot, i.e. uplink command, watchdog reset, or BEP software. A description of the contents of this reboot record will be added to the Preliminary Design Spec.
REMARKS
ACIS accepts per block 14 less the first sentence.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
2-17-95
IMPLEMENTATION
The contents of the 'Startup' telemetry packet has been added to 36-01103 in 3.2.9.3.5. It will not appear in the Preliminary Design Specification (36-02402), but will be present in the Detailed Design Specification to be reviewed at CDR.
[INDEX]

42. Withdrawn item #13

ISSUE SUBJECT
Booting from ROM
RELATED ISSUES
Item 5, Item 23, ISWP-0013
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
page 17, 4.2.2 Suggest you modify the flow chart as follows: Booting from ROM should be safe for the five years in orbit. Booting from code passed to it from the OBC looks very risky. Too many handshakes, too many steps, especially for a large boot file. If booting from one ROM is not deemed safe enough, include two with the appropriate wiring to go first to one and then to the other. The method described below completely satisfies completely one fault failure tolerant as described. So is the proposed method, but this one involves only internal handshaking while the other one involves both internal and external handshaking. Notice that some portion of code must be available from ROM for either system to work since both depend on checking the value of a flag.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
This should be merged with comments to RID ISWP-0013.
[INDEX]

43. Withdrawn item #14

ISSUE SUBJECT
ACIS Time Stamp
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
Page 18, 4.2.3 As far as I know there is no ACIS Time Stamp, just the normal RCTU timing signals: Main Frame Signal Science Frame Signal 1 millisecond signal Which of these is being referenced? How is the referencing done? We discussed this in the past, but I don't recognize our discussion in this document! The discussion is found in 5.2.5.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
ACIS maintains a count of the number of elapsed 1.024 MHz spacecraft clock pulses. It is latched against the Science Frame Signal, and against internal ACIS events, in order to time ACIS operations relative to the Science Signal, and hence to UTC.
[INDEX]

44. Withdrawn item #15

ISSUE SUBJECT
start up services
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
Page 19 - 4.2.7, start up services belong to the boot ROM, no reason to have them globally available.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Our design favors a very simple bootstrap loader, little more than a copy operation. All other startup software will execute in the BEP operating system.
[INDEX]

45. Withdrawn item #16

ISSUE SUBJECT
permanent memory error
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
Page 21, 4.3.2 There is a clear single fault failure in this figure. A permanent memory error in the backend processor's memory can cause a permanent failure of a front end processor. This could easily be made more fault tolerant if two areas of code were prepared in the backend processor, and the front end processor would pick alternately from one or the other upon boot.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We believe that this comment was withdrawn. The FEPs are "booted" directly from the BEP by sending commands to copy the FEP code from BEP ROM to FEP I-cache. Rogson's suggestion, while ingenious, does not apply to this situation.
[INDEX]

46. Withdrawn item #17

ISSUE SUBJECT
I/O library
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
Page 21, 4.3.3 Portions of the I/O library look standard enough to be carried in some kind of ROM. Is this to be done?
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Yes, in the sense that all software will be stored in ROM, and copied to cache at boot time. We don't want to execute it from ROM because that would generally slow us down.
[INDEX]

47. Comment #14

ISSUE SUBJECT
no minor frame interrupt
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P24 There is no minor frame interrupt. I believe you are referring to the science frame interrupt mentioned as item 6.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
This is a typo which will be fixed. "Science Frame Interrupt" was the intended item.
[INDEX]

48. RID ISWP-0017 (t-d-34)

ISSUE SUBJECT
time to handle
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P25. The design requirement on "the time to handle... interrupts..." should be in the requirements document.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll add an interrupt timing requirement to section 3.3 of the Software Requirements Specification.
ACTIONEE
MIT/P. Ford
SUSPENSE DATE
6-30-95
[INDEX]

49. Withdrawn item #18

ISSUE SUBJECT
parity error in backend processor
RELATED ISSUES
ISWP-0007
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P27. 5.2.3 As stated above (p21, 4.3.2) a hard parity error in 0x0BFFFFFFC of the backend processor, can eliminate a front end processor.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
The address in question is located in ROM, not RAM. I remember that we explained this to Rogson and that he withdrew the comment.
[INDEX]

50. Withdrawn item #19

ISSUE SUBJECT
count field
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P28. The method employed indicates that the count field in the ACIS command packed does not count itself. This must be communicated to the off-line software for proper handshaking.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll make sure that the definition of the count field in the ACIS serial IP&CL; matches that in the requirements specification.
[INDEX]

51. Withdrawn item #20

ISSUE SUBJECT
packet length error
RELATED ISSUES
ISWP-0007
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P28. There should be no attempt to "recover" from a packet length error, nor any attempt to find the start of the next packet. If there is an error, ACIS should wait for a "reset" command. This interface must be developed between ACIS and FSW. The speed of response and the amount of time ACIS is unavailable to receive the next command packet must be established since the OBC can send commands out at the rate of around 1 per 65 sec.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
See the response to ISWP-0007.
[INDEX]

52. Withdrawn item #21

ISSUE SUBJECT
"client" of the command packet object
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
It is difficult to see who the "client" of the command packet object is. It would seem that the object is the master instead with all other objects being its clients. Please explain more fully!
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Unlike some styles of OOD, our command packet objects (CPO) do not contain their own methods. Rather, they contain a type field that causes the various handlers that receive the CPO to choose particular methods.
[INDEX]

53. Comment #15

ISSUE SUBJECT
ACIS word
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P30. The ACIS word is sampled once every 32 seconds. That is the standard measurement interval for all instrument readings in the engineering telemetry.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll update the document accordingly
[INDEX]

54. Comment #16

ISSUE SUBJECT
all interfaces established
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P33, 5.2.8 - At a PDR level, the hardware should be better defined, and all interfaces established!
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We believe that we have defined the hardware and interfaces to a level of detail sufficient for PDR. Our RCTU interfaces are fully described, and the interfaces between DEA and BEP and between FEP and BEP are probably described more accurately in the SW Preliminary Design Specification than they were in any document submitted to the ACIS hardware PDR. A bit-level description of the serial commands, and parameter and telemetry blocks will be included in the ACIS IP&CL submission to CDR in a TBD format.
[INDEX]

55. Comment #17

ISSUE SUBJECT
table 12
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P34, table 12!
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
This typo, Table 9 instead of Table 12, will be fixed.
[INDEX]

56. Comment #18

ISSUE SUBJECT
What happens upon error?
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P36, 5.3.2 What happens upon error? How is this communicated to the BEP? Does the BEP keep statistics? Does it pass the information to the ground? What means does it use to pass the into to the ground? (Science or engineering telemetry?)
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
FEP errors will be included in the "Report Status to Back End" function described in section 14.0 on p.79. The BEP will include the information in the "FEP Report" mentioned in section 11.6.5 on p.72.
[INDEX]

57. Withdrawn item #22

ISSUE SUBJECT
Timing information is needed
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P38. 5.3.5 - 5.3.10 Timing information is needed to evaluate the adequacy of both the processor chosen, and the algorithm eventually arrived at.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
This is currently under study. It will be included in a presentation on bias and overclocking to be made during the PDR team meeting.
[INDEX]

58. Comment #19

ISSUE SUBJECT
Why is there a need for an "interface layer
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P40. 6.1 Why is there a need for an "interface layer" to the Nucleus RTX? Does it not have well defined interfaces?
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Since the Mongoose uses the same machine language as the MIPS-3000 CPU in DEC Stations, we intend to test most of the ACIS flight software in the latter. Hence the need for an "interface layer" to insulate the common code from Mongoose and MIPS-3000-dependent features.
[INDEX]

59. Comment #20

ISSUE SUBJECT
Will you have tasks of the same priority?
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
Will you have tasks of the same priority? Can you eliminate the round robin time slice mechanism for task with the same priority? It seems you can by setting NU_Relinquish(), Also that you won't be using it.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
All tasks will have fixed priorities.
[INDEX]

60. Comment #21

ISSUE SUBJECT
Semaphore management present a single event failure possibility.
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P42 Semaphore management present a single event failure possibility. A hard error on any of a semaphore's bits could permanently lock up resources.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll study this situation.
[INDEX]

61. Withdrawn item #23

ISSUE SUBJECT
The set/clear radiation flag conditions are unclear
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P47. The set/clear radiation flag conditions are unclear. A small finite state automaton is needed for evaluation.
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll reword our explanation of how ACIS responds to the set/clear radiation flags.
[INDEX]

62. Withdrawn item #24

ISSUE SUBJECT
"Length" or "Length-3"?
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P47. "Length" or "Length-3"?
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll fix the table. The text should actually read "3 through Length-2".
[INDEX]

63. Comment #22

ISSUE SUBJECT
Verbose mode needs to be explained.
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P50. Verbose mode needs to be explained. Telemetry is a FIFO what does "attempt to echo" mean?
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
Verbose mode is described in section 3.2.14, p.105 of the Requirements Spec. From the perspective of the command manager, the "telemetry system" is synonymous with the telemetry manager, and "attempts to echo" means that the command manager encapsulates the command in a telemetry packet and enqueues it for down-linking. We'll reword section 7.4.4 to make this clearer.
[INDEX]

64. Comment #23

ISSUE SUBJECT
"may cause reset of telemetry system"
ITEM REVIEWED
36-02402-01
DISCREPANCY/PROBLEM
P56 Explain "may cause reset of telemetry system". Certainly not the on board system, perhaps the internal system?
INITIATOR/PHONE
Leon Rogson 310-814-4788
ORGANIZATION
TRW SE&I;
DATE
October 27, 1994
TEAM NAME
Software
DEVELOPER'S COMMENTS
We'll clarify this.
[INDEX]

Peter G. Ford [pgf@space.mit.edu]