AFGS Boot Project
Provide an initial and verified Boot as a means to support the AFGS_Program.
Description
Boot, which will receive control after the embedded Bios has completed its operation, will be responsible for three primary tasks:
- Checking to ensure Bios performed hardware initializations correctly
- Ensuring that all Deos required hardware is initiailized and functioning properly (e.g., initialization and power-up BIT)
- Implement proper data/control flow to/from Deos
Current Status - BEHIND SCHEDULE
Risk items resolved. Just cranking through the list of tasks to complete. See Resolved Issues Below for details.
Tasks
Initial Budget: $168,910
YTD: $431,800
Current ETC: $0
Current EAC: $431,800
| Milestones | Due Date | Estimated Delivery | Delivered | Percentage Complete |
|---|---|---|---|---|
| Initial Release | 18-APR-2006 | 18-APR-2006 | 18-APR-2006 | 100% |
| [1] Performance Enhanced Release | 14-FEB-2007 | 14-FEB-2007 | 14-FEB-2007 | 100% |
| [2] Full Functionality Release* | 10-APR-2007 | 25-APR-2007 | 24-APR-2007 | 100% |
| 3.14 Run for score | N/A | 28-SEP-2007 | 28-SEP-2007 | 100% |
| [3] Verified Release | 04-JUN-2007 | 05-OCT-2007 | 05-OCT-2007 | 100% |
Tasks for Milestone [3] Verified Release
| Task | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|
| 2.6 Pentium-M errata analysis | 2.1 | Bill Cronk | None | 50 | 20 | 20 | 0 |
| 2.7 Complete code development: hardware initialization, PBIT, errata handling. | 2.2,2.6,2.9 | John Kimball, Dennis Irwin | None | 160 | 174 | 174 | 0 |
| 2.8 Ad-hoc testing of completed code. | 2.7,2.9 | John Kimball, Dennis Irwin | None | 80 | 128 | 128 | 0 |
| 2.9 Reliable Verification Testing Environment | None | Dennis Irwin, John Kimball | None | 160 | 329 | 329 | 0 |
| 2.95 Spec Changes*** | None | John Kimball, Dennis Irwin | None | 80 | 37 | 37 | 0 |
| 3.0 Formalize Requirements | 2.4 | John Kimball, Bill Cronk | None | 80 | 104 | 104 | 0 |
| 3.1 Software life cycle audit #1 (Requirements) | 3.0 | Kelly Leonard | None | 16 | 6 | 6 | 0 |
| 3.2 Requirements review | 2.1 | Gary Kindorf | None | 60 | 66 | 66 | 0 |
| 3.3 Test Case Development | 2.1, 2.9 | Eli Barzilai | None | 40 | 143 | 143 | 0 |
| 3.4 Test Procedure Development | 2.1, 2.3, 2.9 | Eli Barzilai, et. al. | None | 120 | 978 | 978 | 0 |
| 3.5 Software life cycle audit #2 (Code) | 3.4 | Kelly Leonard | None | 16 | 13 | 13 | 0 |
| 3.6 Code review | 3.2 | Gary Kindorf, Mike Horgan | None | 80 | 184 | 184 | 0 |
| 3.7 Test Case Review | 3.2, 3.3 | John Kimball, Gary Kindorf, Mike Horgan | None | 24 | 86 | 86 | 0 |
| 3.8 Test Procedure Review | 3.4, 3.7 | Mike Horgan, et. al. | None | 60 | 166 | 166 | 0 |
| 3.9 Software life cycle audit #3 | at least 3 TP reviews | John Riedmann | None | 16 | 16 | 16 | 0 |
| 3.10 Requirements coverage analysis | 3.6, 3.7 | Mike Horgan | None | 8 | 8 | 8 | 0 |
| 3.10.1 Executable Object Code Analysis | 3.6, 3.7 | John Kimball | None | 8 | 22 | 22 | 0 |
| 3.11 Conformity inspection - SQA build Witness | 3.8 | Craig Johnson | None | 8 | 8 | 8 | 0 |
| 3.12 SCAT/ABC qualification | 3.8 | Mike Horgan | None | 8 | 8 | 8 | 0 |
| 3.13 Integration review | 3.10, 3.10.1, 3.11, 3.12 | Craig Johnson | None | 8 | 12 | 12 | 0 |
| 3.14 Run for score, including SQA witnessing, and test results review | 3.13 | Craig Johnson | None | 8 | 12 | 12 | 0 |
| 3.15 Structural coverage analysis | 3.14 | John Kimball | None | 8 | 21 | 21 | 0 |
| 3.16 Verification audit | 3.15 | Craig Johnson | None | 8 | 8 | 8 | 0 |
| 3.17 Certification documents: SAS, SLCECI, SCI | 3.15 | Bill Cronk, Gary Kindorf, John Kimball | None | 40 | 34 | 34 | 0 |
| 3.18 Population of certification archive (PCA) | 3.17 | John Kimball | None | 8 | 9 | 9 | 0 |
| 3.19 Software conformity audit | 3.18 | Craig Johnson | None | 8 | 8 | 8 | 0 |
| Totals | 1162 | 2600 | 2600 | 0 | |||
*** This task tracks updates to requirements and code caused by changes to specs which were received after initial completion of requirements and code (for instance, PCR 4504, PCR 4512). Reviewing such changes is done under the existing review tasks.
Risks
None.
Resolved Issues
AFGS Boot is Grey
During investigation of this problem, it was determined that the changes in Version 1.0.4 were warranted. One should compare Version 1.0.4 to Version 1.0.2 for simpler understanding of the changes as Version 1.0.3 was simply an attempt to isolate/bound the root cause.
Integration at ALT
Version 1.0.2 resolved this issue.
Discrete Inversion Release
Version 1.0.2 resolved this issue.
PCI PERR/SERR
- Description: The safety analysis unsure whether we need to 'do something' with regards to PERR/SERR as they can lead to Hazardously Misleading Information (HMI) scenarios for the flight crew.
- Status: Meeting with GMS indicates that we have no hardware ability to respond to PCI errors (i.e., hardware mod. required). Procedding, at risk, as if these errors can be ignored (our only course of action given current hardware).
Random Hardware States
The assertions that: 1) BIOS and hardware will be the same on *all* boards; and 2) BIOS will transition control to Boot code with hardware in the same state on all boards; are now proving to be true.
Software Verification Environment
- Description: Testing is a huge concern for the team. Getting the emulator working has been slow going, and not all required hardware is present.
Additionally, there is concern that testing methods must be developed for various features, such as power interrupts and discrete inputs, that the emulator will not support. Issues in this category include:
- Emulators do not maintain a connection with the boards long enough to perform any meaningful work/testing.
- Compact flash connection to farm targets still in work
- Mitigation: There are two strategies:
- Until June 8th, the team will continue to work (requesting support from Steve Pearce 1-602-436-6081 of AGM2 and Geoff Hetzel 1-714-7311661 x123 of American Arium) in order to get a reliable Software Verification Environment. Add the end of this time their goal will be achieved or abandoned in favor of the second strategy.
- An alternative software verification environment, which does not require emulator or any special hardware support, will be *invented*. This is the strategy with presumably the most variables/unknowns. Several team members are beginning to think along these lines. If it looks like this will become the preferred approach more time will be spent to chart an approach and estimate the effort required.
- Status: An alternative software verification environment has been developed which will enable test procedure development to proceed.
Pentium-M errata
- Description: Task 2.6 Pentium-M errata analysis of Tasks for Milestone [3] Verified Release captures the need to perform this analysis. The Pentium-M errata has a potential (all be it small) to increase the scope of the planned worked for this component.
- Mitigation: Complete Task 2.6 Pentium-M errata analysis as soon as practical in order to quantify the work increase (if any) in a timely manner.
- Status: Will use the Pentium-M errata analysis done performed in the context of the AGM program.
Time Partitioning Concerns
Telecon to resolve COTS hardware issues was held Tuesday March 27, 2007 with ID&C and GMS (see AFGS COTS Hardware Issue Response).
Emulator Power Supplies
New power supplies were purchased and placed 'on the farm'. While power is no reliable this unfortunately *did not* solve all reliability issues with the Software Verification Environment (see Risks above).
BIOS Approach
Consensus has been reached regarding the BIOS approach and verifiability of the same. Specifically:
- BIOS and hardware will be the same on *all* boards
- BIOS will transition control to Boot code with hardware in the same state on all boards
- Boot can/will depend upon the above when performing the tasks listed in the Description
Watchdog timer
The Software Verification Environment does not allow for testing the software hardware integration aspect of this feature. Therefore, Boot software will be tested to ensure that it properly implements Watchdog requirements. A systems integration test will need to ensure that Boot PBIT actually tests/ causes a Watchdog trip (i.e., the software/hardware integration aspect of this function).
Power-loss Warmstart & Coldstart
These issues are addressed by the following: Our understanding of hold-up and our current plan re what to do re warmstart/coldstart -- Thu Apr 12 15:05:07 MST 2007
Telecon Decisions
Thermal Management, Netdetect, and PBIT interrupt-mask test issues are addressed by the following: Notes on decisions from 4/18 telecon -- Thu Apr 19 06:27:33 MST 2007.
The Persistent HBM PBIT flag will be placed in a sector currently set aside for the boot image on the bootable compact flash device.
