DCE Software Design Document (DCE SDD)

History of the Development of the DCE SDD

Summary written on 12/9/1999
Last Updated on 12/4/2000

The following is a summary of the long, and tortured history of the DCE SDD Development Plan:

1. BATC and CU travel to UCB for the 'November' meeting (DCE SDD Development I) the week 11/15/1999. (Rob/Allison/Ken/Daniel/Geoff) - Done
2. Material from the 'November' meeting incorporated into DCE SDD Top-Level Design by 12/6/1999. (Rob) - Done
3. Draft of the Top-Level Design to be released on 12/6/1999 for review by UCB. (Rob/Ken) - Done
4. UCB to deliver redlines of Top-Level Design by 12/13/1999. (Daniel) - Done
5. Material from the 'November' meeting incorporated into DCE SDD Detailed Design by 12/17/1999. (Rob/Allison/Ken) - Done
6. Draft of the Detailed Design to be released on 12/17/1999 for review by UCB. (Rob/Allison/Ken) - Done
7. UCB to deliver redlines of Detailed Design by 1/04/2000. (Daniel/Geoff)- Done
8. UCB responses to actions items from the 'November' meeting delivered by 1/04/2000. (Daniel/Geoff/Barry)- Done
9. UCB travels to Boulder for the 'January' meeting (DCE SDD Development II) from 1/04 - 1/06/2000. (Daniel/Geoff/Rob/Allison/Ken)- Done
10. UCB/BATC/CU responses to actions items from the 'January' meeting delivered by 1/13/2000. (Daniel/Geoff/Rob/Allison/Ken)- Done
11. All redlines and material from the 'January' meeting incorporated into DCE SDD by 1/18/2000. (Rob/Allison/Ken)- Done
12. DCE SDD released for internal review by BATC/UCB/CU on 1/18/2000. (Rob/Ken)- Done
13. All redlines from the internal review of the DCE SDD due by 1/24/2000. (BATC/UCB/CU)- Done
14. All redlines from internal review incorporated into DCE SDD by 1/31/2000. (Rob/Allison/Ken)- Done
15. DCE SDD released for formal review by the entire HST Software Team on 1/31/2000. (Rob/Ken)- Done
16. DCE SDD scrubbed for Action Items from the 'October' meeting (DCE Software Design Review) by 2/4/2000. (Ken)- Done
17. DCE FSW "Delta" Design Review at CASA-ARL, set for 2/18/2000 at 9:00AM. (Ken)- Done

18. August - October, 2000: Significant Change to DCE FSW Development Approach - See DCE SDD Information for details.- In Progress

DCE Software Design Document

DCE Software Design Document (PDF) - Information Outdated

DCE FSW Flow Diagrams - Information Outdated

Action Items from the 'February 2000' DCE "Delta" Software Design Review

• Link to February DCE "Delta" Software Design Review Website

Action Items from the 'January 2000' Meeting (DCE SDD Development II)

1. Daniel: Provide Memory Map of the 8051 Internal Registers.
   • Daniel emailed a page from the Intel 8051 documentation that depicts the Special Function Registers (SFR).
2. Daniel: Provide a drawing of the DCE software development flow. Show how your Design of using a single source code set flows down to a single 'object' file from the compiler, and then how the link phase produces three separate executable images (Boot, LCA, UCA) - based on the absolute memory addressing of these areas.
   • Daniel created a drawing w/notes that shows the DCE FSW Development Flow.
   • Ken recreated the DCE FSW Build Flow drawing using a "vector-format" drawing tool, to simplify inclusion into the DCE SDD.
3. Daniel: Provide a list of the software development tool documentation references not already listed in Section 2. (i.e., Archimedes)
   • Daniel provided the following information about the software tools he uses:

     Archimedes A-51 Assembler Version 5.0
     (c) 1988-1995 Archimedes Software Inc.
     303 Parkplace Center
     Suite G125
     Kirkland, WA 98033
     TEL (425) 822-6300
     FAX (425) 822-8632

     When run, the tools display the following banners:
     a51.exe: MS-DOS MCS-51 MACRO ASSEMBLER A51 V5.02
     l51.exe: MS-DOS L51 LINKER/LOCATOR V3.52
     oh51.exe DOS MCS-51 OBJECT TO HEX FILE CONVERTER V2.1

4. Daniel: Provide an ABS file with Symbol information included.
5. Daniel: Verify that all calculated CRC values are non-zero (for a reasonable input parameter space).
   • Daniel showed that a zero value IS possible. Therefore, it was decided by the meetings participants that the CS FSW will no longer monitor the CRC value to see if it changes from zero to a new value - and use that change to signify the completion of a CRC calculation. Instead, the CS FSW will wait a TBD period of time (modifiable as a patchable constant) and only after that time has expired will it compare the CRC value reported in housekeeping to the expected value.
6. Geoff: Provide a definitive answer to what UCB wants to do about the parameter 'TOGGLE' in the DCE Jump command.
   • Geoff reported on 1/6/2000 that the 'TOGGLE' parameter will remain "As Is".
7. Geoff: Remove the commands LFDPEEK and LFDPROM from the FUV Detector ICD Appendices.
8. Geoff: Create two new DCE HSK mnemonics for the 'Target' HV Voltage. (Note: The names LFHVTGTA and LFHVTGTB were informally agreed upon by the meetings participants.)
9. Ken: Add appropriate contract information to the TBD listed in Section 1.1.
   • The sentence should read: "This document has been prepared in accordance with the requirements of contract NAS5-98043, between Goddard Space Flight Center Code 442, Greenbelt, Maryland, and the Center for Astrophysics and Space Astronomy, University of Colorado - Boulder (CU/CASA)."
10. Rob: Fold-in the pertinent information from the agreement on HV State Bit behavior (see links below) into the DCE SDD, in an appropriate section - possibly Section 4.2.7.
11. Rob: Create a drawing to show how the three different executable code images (BOOT, LCA, UCA - as above) occupy different memory areas.
12. Allison: Create a new CS Macro to 'clear' (i.e., zero-fill) the DCE HVI and AUXI Buffer & Histogram areas.

Behavior of DCE FSW HV State Bits (LFHSTATE)

Technical Evaluation Report (COS-11-0013) discusses the behavior of the DCE FSW HV State Bits (LFHSTATE) in response to recognized "events" which drive HV State Transitions.

Action Items from the 'November 1999' Meeting (DCE SDD Development I)

1. Daniel: Be prepared to review and give a detailed summary of the how Timing works in the DCE Code. e.g., How is 49 ticks per second computed? What is the 170 ticks per second timer based on?
   • (Paraphrased by Ken). The timing interval of 170 ticks per second does NOT exist anywhere in the COS DCE Flight Software. I believe Daniel explained that this number came up during testing of a particular FUSE FSW implementation, and is not present for COS. As for the 49 ticks per second, the real timing number interval is 49.152 msec per tick, and this is a number that comes from stepping down the 16MHz clock. This is described in the DCE SDD in Section 3.2.10.
2. Daniel: Provide the correct order for Task Execution within the Executive Loop.
   • According to Daniel, the existing Executive Loop Diagram closely approximates the order of Task execution. No change is required.
3. Geoff: Verify actuator turn-on sequence at a hardware level.
   • Geoff summarized this in an email dated 11/23/1999.
4. Geoff: Provide Figure 3.1-3 and Hardware Information to Rob when the updated ICD is released.
   • Geoff emailed an updated Figure on 11/29/1999.
5. Daniel, Geoff and UCB: Decide how your plan to report SW and HW Status bits back in HSK. (e.g., HV and Door Status Bits.) Decide which DCE SW items will be new HSK mnemonics, and which will simply be internal variables in the DCE FSW. If you choose to have separate mnemonics for HW and SW Status bits - distribute that information to the FSW Team. Also, update the DCE HSK Database, and Appendix D in the ICD to reflect this decision.
   • (Written by Geoff). In cases where H/W talkbacks are available to the DCE, H/W talkbacks will be reported in Housekeeping. No S/W talkbacks will be reported in this case. In cases where no H/W talkback is available, the housekeeping item will report the S/W talkback. These S/W talkbacks are generally DCE S/W related items and software enables and overrides. There will NOT be H/W and S/W talkbacks for the same housekeeping item.
6. Daniel and Geoff: Figure out what the current DCE FSW Reset Vector does regarding the door and Aux power. Does a reset (either POR and WatchDog) stop the door and shut off Aux power? If the current design is what you propose to keep for COS, make sure we have summarized the DCE reset information properly in the DCE SDD.
   • (Written by Geoff). The DCE FSW Reset Vector will ALWAYS execute DCE "Safe Controls" code - which turns off HV Power and Aux Power, and initializes all Door Settings (Turns OFF Door Power, Sets the Door Direction to "STOP", etc...). The DCE "Safe Controls" algorithm will be described fully in the DCE SDD.
7. Daniel: Summarize the proposal you described for the process of "saving HSK information" in the event of a reset. i.e., document your idea for the scheme of copying the entire Housekeeping Buffer to the transfer area upon a reset.
   • (Paraphrased by Ken). Daniel does not feel that a response is warranted. At the "November" meeting, he suggested a scheme that would preserve the last housekeeping packet in the event of a reset - but he felt that this was not really a scheme that he wished to pursue, nor did he feel that it was necessary - as the CS would already have a complete copy of the last housekeeping packet sent by the DCE FSW prior to it's reset.
8. Barry, Daniel and Geoff: Document the possible Budget and Schedule impact for the proposed modification to your Boot and Operate code images and modes. i.e., The rest of us feel that the current Boot design will NOT be approved as is, without a clear understanding of how modifying the current design will negatively impact schedule and budget.
   • Barry summarized this in an email dated 12/21/1999.

Action Items from the 'October 1999' DCE Software Design Review

• Link to October DCE Software Design Review Website

---

Return to COS Instrument Development

Mail comments to Ken.Brownsberger@Colorado.EDU