ACIS Software RIDS

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


 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.;

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.

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

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

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.

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:

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.
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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.;

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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".

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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".

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.

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.

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