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:
- 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
- Material from the 'November' meeting incorporated into DCE SDD Top-Level Design by 12/6/1999. (Rob) - Done
- Draft of the Top-Level Design to be released on 12/6/1999 for review by UCB. (Rob/Ken) - Done
- UCB to deliver redlines of Top-Level Design by 12/13/1999. (Daniel) - Done
- Material from the 'November' meeting incorporated into DCE SDD Detailed Design by 12/17/1999. (Rob/Allison/Ken) - Done
- Draft of the Detailed Design to be released on 12/17/1999 for review by UCB. (Rob/Allison/Ken) - Done
- UCB to deliver redlines of Detailed Design by 1/04/2000. (Daniel/Geoff)- Done
- UCB responses to actions items from the 'November' meeting delivered by 1/04/2000. (Daniel/Geoff/Barry)- Done
- UCB travels to Boulder for the 'January' meeting (DCE SDD Development II) from 1/04 - 1/06/2000. (Daniel/Geoff/Rob/Allison/Ken)- Done
- UCB/BATC/CU responses to actions items from the 'January' meeting delivered by 1/13/2000. (Daniel/Geoff/Rob/Allison/Ken)- Done
- All redlines and material from the 'January' meeting incorporated into DCE SDD by 1/18/2000. (Rob/Allison/Ken)- Done
- DCE SDD released for internal review by BATC/UCB/CU on 1/18/2000. (Rob/Ken)- Done
- All redlines from the internal review of the DCE SDD due by 1/24/2000. (BATC/UCB/CU)- Done
- All redlines from internal review incorporated into DCE SDD by 1/31/2000. (Rob/Allison/Ken)- Done
- DCE SDD released for formal review by the entire HST Software Team on 1/31/2000. (Rob/Ken)- Done
- DCE SDD scrubbed for Action Items from the 'October' meeting (DCE Software Design Review) by 2/4/2000. (Ken)- Done
- DCE FSW "Delta" Design Review at CASA-ARL, set for 2/18/2000 at 9:00AM. (Ken)- Done
- August - October, 2000: Significant Change to DCE FSW Development Approach - See DCE SDD Information for details.- In Progress
DCE Software Design Document
Action Items from the 'February 2000' DCE "Delta" Software Design Review
Action Items from the 'January 2000' Meeting (DCE SDD Development II)
- Daniel: Provide Memory Map of the 8051 Internal Registers.
- 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: 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
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
- Daniel: Provide an ABS file with Symbol information included.
- 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.
- 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".
- Geoff: Remove the commands LFDPEEK and LFDPROM from the FUV Detector ICD Appendices.
- 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.)
- 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)."
- 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.
- Rob: Create a drawing to show how the three different executable code images (BOOT, LCA, UCA - as above) occupy different memory areas.
- 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)
- 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.
- Daniel: Provide the correct order for Task Execution within the Executive
- According to Daniel, the existing Executive Loop Diagram closely approximates the order of Task execution. No change is required.
- Geoff: Verify actuator turn-on sequence at a hardware level.
- Geoff: Provide Figure 3.1-3 and Hardware Information to Rob when the updated
ICD is released.
- 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.
- 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.
- 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.
- 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.
Action Items from the 'October 1999' DCE Software Design Review