LWIP Project
From Deos
Jump to navigationJump to search
This effort is in support of the SLS_Program.
Description
This project is for the development of the LWIP (lightweight IP) network stack to DO-178B level D.
Tasks
Initial Budget: $256,159
TTD: $355,079
Current ETC: $31,404
Current EAC: $386,483
| Delivery | Due Date | Estimated Delivery | Delivered | Percentage Complete |
|---|---|---|---|---|
| [5] Ip fragment reassembly optimization | 14-Sep-07 | 14-Sep-07 | 08-Aug-07 | 100% |
| [1] Partitioned driver support | 21-SEP-07 | 13-Sep-07 | 13-Sep-07 | 100% |
| Version 1.11.x - aka 1.11+. Early 1.12.0 features | 1-Feb-08 | 1-Feb-08 | 4-Feb-08 | 100% |
| Version 1.13.0 | 09-Dec-07 | 29-Feb-08 | 21-Feb-08 | 100% |
| Version 1.15.0(renamed from 1.14.0) - last planned release for lwIP, to be used as the cert candidate | 04-Apr-15 | 04-Apr-15 | 04-Apr-15 | 100% |
| [3] Certification Candidate Release | 21-Dec-07 | 16-Jun-08 | 17-Jun-08 | 100% |
| [5] PCR 4737 (rcvbuf) integration | 8-Aug-08 | 8-Aug-08 | ' | 100% |
| [4] Software Accomplishment Summary Release | 01-Mar-08 | 18-Aug-08 | Pushed out due to high priority implementation of PCR 4737 | 100% |
Delivery [5] IP reassembly optimization
- Feature Description: Increase the performance/reliability of the reception of ip fragments. The goal is to receive 50 3k packets/s, as sent using the grs simulator tool.
| Task | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|
| 5.1 Do some preliminary groundwork to seek out pre-existing solutions, and engage the community. | N/A | Tom Taranowski | Resource availability | 4 | 4 | 4 | 0 |
| 5.2 If no adequate pre-existing solutions exist, work up a design. | N/A | Tom Taranowski | Resource availability | 8 | 6 | 6 | 0 |
| 5.3 Implement the modifications/debug. | N/A | Tom Taranowski | Resource availability | 16 | 18 | 18 | 0 |
| 5.4 Do performance/robustness testing to ensure that it meets requirements. | N/A | Tom Taranowski | Resource availability | 16 | 12 | 12 | 0 |
| 5.5 Tune performance as needed. | N/A | Tom Taranowski | Resource availability | 16 | 2 | 2 | 0 |
| Totals | 60 | 42 | 42 | 0 | |||
Delivery [1] Partitioned driver support
- Feature Description: Fully functional for GRAS project - Allows the user to run level A certified Ethernet drivers
| Task | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|
| 1.1 Gap analysis. Determine RTIP features that need to be ported to lwIP to support partitioned drivers. | N/A | Tom Taranowski | Resource availability | 8 | 8 | 8 | 0 |
| 1.2 Code Development | 1.1 | Tom Taranowski | Resource availability | 32 | 68 | 68 | 0 |
| 1.3 Acceptance testing | 1.2 | Tom Taranowski | Resource availability | 16 | 10 | 10 | 0 |
| Totals | 56 | 86 | 86 | 0 | |||
Version 1.12.0
| Task | Status | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|---|
| PCR:4718 - Enhanced inetaddr to support multihoming | Will be released early in preliminary 1.11+ release. | N/A | Tom Taranowski | Resource availability | 40 | 76 | 68 | 0 |
| PCR:4719 - Stack becomes a slack hog on TCP connection establishment | Resolved. Determined to be a integration/testing problem. | N/A | Tom Taranowski | Resource availability | 12 | 0 | 0 | 0 |
| PCR:4724 - Test Harness Does not Work with LwIP Stack | Issues with test harness resolved. No release to lwIP required. | N/A | John Kimball | Resource availability | 108 | 15 | 15 | 0 |
| PCR:4722 - select() First Parameter Issue (e.g., gdbserver does not work) | Will be released in preliminary 1.11+ release. | N/A | Tom Taranowski | Resource availability | 64 | 12 | 12 | 0 |
| PCR:4721 - Mysterious stability issues on GBAS configuration | See PCR description. Diagnosed as issue with an error in the application code that the stack did not catch. PCR:4738 | N/A | Tom Taranowski | Resource availability | 0 | 216 | 0 | 0 |
| Totals | 444 | 359 | 359 | 0 | ||||
Version 1.13.0
| Task | Status | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|---|
| PCR:4720 - Fragments are dropped under worst case GRAS load | Scheduled for release on the 1.12 release date. Estimate adjusted from 108 to 140 worst case on 1/30, based on meeting with SLS | N/A | Tom Taranowski | Resource availability | 108 | 105 | 105 | 0 |
| Totals | 108 | 105 | 105 | 0 | ||||
Version 1.15.0(renamed from 1.14.0) test-result driven release
| Task | Status | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|---|
| Ad hoc testing | N/A | N/A | Tom Taranowski | none, customer testing is complete. Need to roll the release into cygwin and then do a quick retest to ensure the release is correct. | 40 | 74 | 74 | 0 |
| Totals | 40 | 74 | 74 | 0 | ||||
IGMP analysis
| Task | Status | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|---|
| IGMP testing | N/A | N/A | Tom Taranowski | Dropped due to GRAS project status. | 40 | 40 | 20 | 0 |
| Totals | 40 | 40 | 20 | 0 | ||||
Delivery [3] Certification Candidate Release
- Feature Description: Sufficient verification steps complete to achieve high confidence executables will not need further changes.
The following was taken from comments made by John Riedmann:
The strategy for DO-178B level D activities is that we'll use the same procedures as for DO-178B level A, but we won't perform all of those procedures (for example, because code reviews aren't required for level D). So instead of being a different process for level D, it's really just a subset of the level A process. The only DO-178B plan documents we expect to update is the PSAC, and Appendix C, which shows which DO-178B objectives we'll satisfy for level D, and whether we'll satisfy them with independence. The only procedure we expect to update is the integration review checklist.
Development and Review Status Summary
Note: Unless noted otherwise, all estimates below are in terms of effort hours.
| Task | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|
| 3.1 DO-178B Plan updates PCR 4363 | N/A | John Riedmann | Resource availability | 40 | 40 | 11 | 0 |
| 3.2 Requirements Development - - There will be 1 level of requirements based on the socket interface defined by the level A Socket API Library. Trace tags will be included. Protocol-based requirements may be added depending on customer needs. | N/A | Tom Taranowski G Craig Johnson |
Resource availability | 336 | 433 | 418 | 15 |
| 3.3 Code Development - No need to comply with our coding standards, and no need for trace tags. See the Network_Project for details. | 3.2 | Tom Taranowski | Resource availability | 136 | 263 | 260 | 0 |
| 3.4 Software life cycle audit #1 | 3.2, 3.3 | Kelly Leonard | None | 16 | 13 | 13 | 0 |
| 3.5 Test Case Development | 3.2 | Uzeir Karagic | Resource availability | 152 | 877 | 877 | 0 |
| 3.6 Test Procedure Development | 3.2, 3.5 | Uzeir Karagic, Dipesh Pokhrel | Resource availability | 304 | 1004 | 999.5 | 0 |
| 4.1 Requirements review | 3.2 | John Riedmann | Resource availability | 165 | 165 | 154.5 | 0 |
| Totals | 1149 | 2792 | 2686 | 0 | |||
Delivery [5] PCR 4737 release
- Feature Description: Includes implementation of PCR 4737, rcvbuf fix.
| Task | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|
| backport rcvbuf fixes from 1.3 baseline | Thomas Taranowski | 1.3 baseline does not port cleanly | 16 | 16 | 16 | 0 | |
| requirements and test updates | Thomas Taranowski, independant reviewer | 32 | 32 | 32 | 0 | ||
| customer integration | customer not ready to integrate | Thomas Taranowski, Chris Pow | 40 | 40 | 40 | 0 | |
| Totals | 88 | 88 | 88 | 0 | |||
Delivery [4] Software Accomplishment Summary Release
- Feature Description: Indicates all verification steps complete.
| Task | Dependency | Assignee | Risk | Original Estimate | Current Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|---|---|
| lwIP configuration how-to and user documents | Thomas Taranowski | None | 20 | 30 - increased 2 hours for milestone[5] pcr4737 implementation | 30 | 0 | |
| 4.2 Software life cycle audit #2 and #3 | 4.1 | Kelly Leonard | None | 16 | 16 | 16 | 0 |
| 4.3 Requirements coverage analysis - To show test coverage of requirements only; no tracing of code to requirements. | 4.1 | Tom Taranowski | Resource availability | 40 | 3 - increased 1 hour for milestone[5] pcr4737 implementation | 2 | 2 |
| 4.4 Conformity inspection - SQA build Witness | 4.3 | Kelly Leonard | None | 8 | 8 | 8 | 0 |
| 4.5 Integration review - No need to complete section on compiler identification and ABC-compliance. | 4.4 | Uzier Karagic + Kelly Leonard | None | 8 | 8 | 2 | 0 |
| 4.6 Run for score, including SQA witnessing, and test results review | 4.4 | Tom Taranowski, Kelly Leonard | Issues with test reproducibility on different workstations | 8 | 32 - increased 4 hours for milestone[5] pcr4737 implementation | 51.5 | -12 |
| 4.7 Verification audit | 4.6 | Kelly Leonard | None | 16 | 16 | 8 | 0 |
| 4.8 Certification documents: SAS, SLCECI, SCI | 4.6 | John Riedmann | Resource availability | 40 | 40 | 30 | 10 |
| 4.9 Population of certification archive (PCA) | 4.6 | Tom Taranowski | Resource availability | 8 | 8 | 8 | 0 |
| 4.10 Software conformity audit | 4.9 | Kelly Leonard | None | 16 | 16 | 8 | 0 |
| Totals | 325 | 178 | 163.5 | 0 | |||
Metrics
| Task | Metric | Notes |
|---|---|---|
| Requirements Development | 418 hours to develop 109 requirements = 8 hours/req. | Requirements were derived from existing API documentation (posix standard). Includes time to incorporate peer comments and fixes, as well as build updates. |
Future stuff
In order to focus future effort, and acquire funding to keep the network stack viable, we are documenting future needed enhancements here.
Projects we want to implement
| Item | Dependancy | Rationale | Time estimate | PCR |
|---|---|---|---|---|
| rtip replacement release misc tasks (do we update training material in first pass?) | none | need to replace rtip with lwIP. | 80 Temporary increase in support commitment, requires other task completion. | PCR 5145 |
| Port up to 1.3 baseline | none | Needed to track stack enhancements, and tap community for fixes and enhancments | 24 | PCR 5145 |
| Increase socket API robustness by fixing up issues with API | 1.3 port | reduces code development time for customers | 80 | misc |
| Test/debug lwIP with vmware e1000 driver | none | vmware support, needed for general rollout | 16 | PCR 4628 |
| Test/debug ppc support | none | Needed to support general rollout | 40 | PCR 4362 |
| Open source test suite | none | Reduce long term maintenance costs, and increase stack quality | 80 | |
| lwIP specific driver | none | increased driver performance, eliminates shim layer code and context switch overhead, simpler implementation | 160 hours to adapt current driver, and stack mods | |
| The waterline -- items above this line are critical to the long-term viability of the stack. | ||||
| socket API enhancements (recvall, sendall, send/recv to/from MO or PR | Increase efficiency of large file transfer, simplify user code | 80 | ||
| argc, argv support. | latest kernel | argc and argv support allows easier runtime specification of operating parameters. | 80 | |
| snmp subagents | none | SNMP is typically required to manage larger networks | 160 | |
Other considerations
- ftpserver
- neglected. Needs to be versatile enough to avoid user forks
- users complain about performance, implementation of custom lwIP socket API would greatly enhance performance
- driver development
- how to standardize on driver implementations. Do we need a driver development guide, or is an 'official' example enough. Will come into play when lwIP specific drivers are implemented.
- Current driver development is expensive because of level A requirement. Kernel DMA capabilities would eliminate this requirement. May not save money, because future users will likely want a certified driver/stack combination
- stack certification
- Plan is to revert to level E after SLS.
- What are the impacts of making level E releases after a certified release (level D)
- Should we 'encourage' higher DAL releaeses on a customer requested basis? Seems like they would be cheap after our initial work on the requirements and test development.
- lwIP rollout
- No current plans to migrate RTIP users to lwIP.
- New projects should prefer lwIP
- Can we get schedule/buddget to commit to a timeline?
- Upcoming projects
- AGM - simple requirements. Need high performance ftp.
- CMU - 4 drivers. Project anarchy.
