Integration of Systems and Software Engineering within the APS-137 Radar Branch of Surveillance Systems

1. Integration of Systems and Software Engineering within the APS-137 Radar Branch of Surveillance Systems Craig S. Young Deana A. Seigler Systems Engineering Manager Software Engineering Manager APS-137 Programs APS-137 Programs craigs@raytheon.com seigler@raytheon.com 972-952-4616 972-952-4988

2. Integrating Systems and Software Engineering - A Call to Action • As processing power increases, more functionality is migrating from Hardware to Software implementations • With most functionality implemented in software, the line between Systems and Software Engineering blurs • Integrating the systems and software engineering processes is essential to effective program execution • This is the story of how we evolved the process on APS-137 programs. Your mileage may vary!

3. ASUW Improvement Program (AIP) APS-137B (V)5 Mission Capabilities • Surface Search • Periscope Detection • Multi-Target Track-While-Scan • Navigation / Weather • Hi-Res Inverse Synthetic Aperture (ISAR) • Synthetic Aperture Radar (SAR) • 1st squadron deployed May 98

4. AN/APS-137A(V)5 to B(V)5 Radar Configuration A(V)5/B(V)5 Common A(V)5 Mod for B(V)5 A(V)5 Only B(V)5 Only Radar Set Computer Signal Data Converter Radar Set Control-Interface Control Indicator Transmitter (TWT-CFA) Receiver Pulse Compressor Synchronizer- Exciter Programmer Power Supply Antenna Transmitter (Air Cooled TWT) Receiver-Exciter- Processor Radar Set Control 2 AMD-2093 27,700 LOC 1,700 New 1 68030 20 i860 1 68040 16,500 LOC 3,500 New 31,500 LOC All New

5. Step 1 - The AIP SAR ProgramRequirements and Configuration Management • Where we started: • Cost and schedule overrun on FFP program resulted in internal audit and associated personnel changes • 8000 “requirements” in a home-grown database tool • Dedicated requirements manager as single focus for all requirements • Requirements written for convenience of the tool • Trace incomplete - Much of existing trace wrong • No ownership of requirements by development teams • No configuration control of requirements • Tailored IPDS sitting in program officelateral file • Software Team were the only folks with their process act together!

6. “Craig’s Commandments” for Requirements Management on APS-137 Programs • People Implement Requirements – Requirements shall be written for humans to understand, not databases • Each development lead shall be responsible for managing the requirements at their level in the system hierarchy and the flowdown of requirements to the next level – There shall be no single-point bottleneck for requirements management • The requirements shall be easily accessible by anyone on the team – There shall be no single-point bottleneck for accessing requirements documentation • “Ownership” of the requirements shall be pushed down to the level of the folks who are to implement them • The requirements trace shall be just a set of pointers between requirements at different levels in the system, and shall not embody the requirements details themselves • The process for changing requirements shall be short, easy to understand and follow, documented, and released to configuration control

7. Implementing “Craig’s Commandments” • Judicious application of the “KISS” Principle • Eliminate the “Requirements Manager” job • Make requirements management everyone’s job • Push “ownership” to the leads for that level of the system hierarchy • Eliminate design from the “requirements” • 8000 became 800 • Only 15 System-level requirements! • Document requirements in a tool that everyone can understand and use • For APS-137, this meant going document-centric • Make the trace just a trace • We traced by hand using an Excel spreadsheet

8. Tracing by Hand - A Method to the Madness • Requirements “Owners” were forced to read and understand the requirements • Initial database scheme with automated parser meant that many requirements were untouched by human hands! • Forcing function to streamline requirements, eliminate design, focus on key care-abouts • When you have to do it by hand for each requirement, you’re motivated to minimize the number of requirements! • End Results • Fewer requirements, better stated requirements, better understood requirements

9. Software Configuration Management for Everyone! • Documentation Release Procedure developed • Established Responsibility, Authority, and Accountability (RAA) for documentation approval, release, and change at each level of the system hierarchy • Managed by Software Configuration Management (SCM) across all disciplines • Utilized Document Management System (DMS) as “master” • Shared data server established for easy access to documentation and to manage the document lifecycle

10. Requirements Change Management • Requirements Change Procedure developed • Established RAA and procedure for Requirements Change Notices (RCN) across all disciplines • File structure on data server established to manage life cycle • RCN’s audited by SCM during document release process

11. Benefits to the AIP SAR Program • 18-Nov-98 - Successful ONE DAY FCA with customer • 15 System-level requirements • 48 WRA-level requirements • No deficiencies • Deployed Today: • 27 USN • 5 Norway • 11 Japan (licensed prod) • 12 Netherlands (under contract)

12. AN/APS-137C(V)5 Radar Set Control Mission Capabilities • Extended B(V)5 SAR Imaging Range • Improved Navigator from Sandia • Precision Targeting Capability • Elevation Data (DTED) • Library of targets within radar • Digital 4X Zoom • Point-To-Point Range and bearing • Under contract for Lot 4 and backfit of Lot 1-3 Radars 24 i860 1 68040 1 PPC 21,000 LOC 4,500 New 48,000 LOC 16,500 New Receiver-Exciter- Processor

13. Step 2 - The ELCID Program • ELCID program was underway prior to implementing the process changes on AIPSAR • Cost overruns on this Cost Plus contract resulted in a re-scope of the effort mid-stream • Stop-Work on UHR-ISAR • AIPSAR processes were migrated to ELCID • Requirements reworked • Document control and change process put in place • Personnel shuffles • Tighter integration between systems and software team • Raytheon left holding the bag on Sandia Navigator algorithm and software

14. Systems Participation in Software Integration • Systems Engineer became mission software developer for the Navigator • Worked in SW Development Environment • Followed SW process • SE/SW Pair for Image Formation Development • SE worked algorithms and SW implemented changes concurrently • Both performed code inspection prior to testing • Simulation and real-time results compared using same input data streams

15. Benefits to the ELCID Program Radar-Only Spec CEP Measured Absolute CEP 1 ft resolution • 29-Aug-00 - Successful ONE DAY FCA • 18 System-level requirements • No deficiencies • Deployed Today: • 18 New Production C(V)5s • 9 B(V)5 Retrofits • Outstanding performance in actual military operations • Featured in recenttechnical conferences • Performing well inOperation Enduring Freedom

16. Step 3 - The Global Hawk Program • El Segundo received contract to add maritime modes to the Global Hawk radar. • Excellent match for the UHR ISAR effort that was stopped on ELCID since both radars contain i860 processors. • Our first attempt at working across former company boundaries. • McKinney effort was limited to Systems and Software Engineering for the ISAR mode.

17. Algorithms - Requirements or Design? • Software only program. No hardware changes. • Combined System Segment Specification (system performance) and the Software Requirements Specification (software performance) into one document. • Performance of software needed to match performance of algorithm simulation. • Matlab simulation and some software already existed from the ELCID program. • Focused our effort on ensuring the software structure matched the algorithm simulation. • Systems Engineers participated in software code reviews. • Verified software performance by processing same data through both simulation and mission software. • Systems and Software Engineers worked side by side in the lab debugging problems.

18. Configuration Control for Simulations • Matlab simulation of the algorithms was the basis for software design. • Needed to control changes to the simulation to ensure all changes ended up in the software. • SCM showed SE how to use Continuus • SE found tool easy to use • Added benefit was the ability to capture baselines of working versions of the simulation

19. Common Risk Management • Programs need to manage risks and the software process requires risk management • Global Hawk was a software only program • No need for different risk management processes • Risk management performed at program level with both SE and SW represented. • SW Eng would identify risk and SE Eng would identify impact to the system performance. • PM also attended to ensure we focused on cost/schedule impact too.

20. Benefits to the Global Hawk Program • Successful 3 month demonstrationin Australia. • 11 missions with over 250 hours of flight time • Participated in Tandem Thrust exercise • UAV demonstrated coastal & maritime surveillance capability. • Proved out UHR ISAR algorithmsand reduced risk for the Navy UHR ISAR program. • In 2004, Australia plans to order4 Global Hawks equipped with the maritime capability.

21. Step 4 - UHR-ISAR Program UHR ISAR Radar Set Control-Interface Radar Set Control • $6M contract to add UHR ISAR and other capabilities to the APS-137 radar. • Pick up where ELCID stopped. • Incorporate algorithm changes made on Global Hawk. • Once again, engineering effort is just Systems and Software. • ISAR mode added to REP WRA with a new software version • Staff is 4 Systems Engineers and 8 Software Engineers • Many of the people who worked the Global Hawk program are working UHR ISAR. 23,500 LOC 2,500 New 28,000 LOC 300 New 57,600 LOC 9,600 New Receiver-Exciter- Processor

22. This is In - Using the Thin Spec for System-Level Requirements • Software cost estimates start with a Thin Spec • Contains high level definition of requirements • Documents the basis of the cost estimate • Systems Engineers adapted this concept for system level requirements • System Thin Spec becomes appendix to SOW and defines performance criteria for FCA. • Enhancements also being made to radar’s interface with Lockheed’s aircraft computer • Navy serves role of system integrator • Thin Spec concept embraced by Navy to document requirements for interface between Raytheon and Lockheed

23. Taking Credit where Credit is Due - Validation of Software Requirements at the System Level • Lesson learned from ELCID execution • Some redundancy between Design Verification Testing (DVT) and software Formal Qualification Testing (FQT) • UHR ISAR to test requirements at highest level possible • Take credit for verification of lower-level requirements via trace from high-level requirements • Only test at the lower-level those items that cannot be tested at a higher level • SQE has bought-in to reviewing artifacts of DVT vs. witnessing FQT execution • Both SE and SW involved in developing test documents • Regression Test Procedure for legacy requirements • Shore Test Plan, Flight Test Plan and Lab Test Plan for the new UHR ISAR requirements

24. Common Action Item Tracking with Continuus • Wanted common tool to track action items across all disciplines • CaWeb is the standard tool, but we had heard rumors of poor response time • Software team uses Continuus to track AIs • Assigned a new hire who had never used either tool to evaluate both and recommend approach • CaWeb had slow response time, support was not available and reports could not be easily customized. • Continuus was already being used and was supported by SCM • Selected Continuus, documented the process, and SCM trained the entire team.

25. Benefits to the UHR ISAR Program • Schedule baselined with the customer in December 2000 • Program end date has not slipped • Executed Shore Test in Hawaii • At least one Systems and one Software engineer on-site at all times • SW engineer recorded raw data and images • Systems engineer extracted raw data and fed into simulation • SE and SW compared image from simulation to the image that was recorded on the radar • Currently conducting Flight Test with SE and SW participation

26. Next Steps - One Team, One Process • Received Processor Upgrade Contract in Oct 2001 • Will replace obsolete processors and add add additional processing capability for the future • Software engineer is filling role of Lead Systems Engineer • Plan to combine current Hardware Configuration Management (CM) Plan with the existing Software CM Plan and incorporate Systems Engineering Work Product Management • Evolution of the APS-137 production line means more functionality will migrate from HW to SW • Our roadmap also includes combining legacy boxes • Development process still has room for improvement • Just starting on the CMMI journey • Consolidated Plans • Separate plans exist today • SEMP, SDP, ICCATS, Tailored IPDS, etc. • ONE CONSOLIDATED MASTER PLAN

27. And in conclusion….. • These techniques worked for APS-137, but your mileage may vary • AIPSAR - ~100 engineers • ELCID, Global Hawk, UHR-SAR - < 20 • Smaller programs more conducive to open, integrated communications • Good engineers made this work for APS-137 • Good processes do not take the place of bad engineers! • Blindly following processes without thought leads to trouble! • One size does not fit all! Tailor to the tasks at hand!

28. Craig Young • Craig Young received a B.S.E. degree in Computer Engineering from Tulane University, New Orleans, LA in 1985, and is currently the Systems Engineering Manager for the AN/APS-137 family of maritime surveillance radars at Raytheon in McKinney, Texas. • Craig joined Texas Instruments in 1985, and spent the early part of his career working with advanced terrain following/terrain avoidance radar concepts before transitioning to maritime surveillance radar systems in 1995. • Craig has been involved in systems and software engineering process development throughout his career, including tailoring of TI’s Integrated Product Development Process (IPDP) to study contracts, and helping to develop assessments for the Systems Engineering Capability Maturity Model (SECMM). • Craig served as the systems engineering representative to the Software Engineering Process Group (SEPG) at TI in 1993-94, helping to rewrite the software operating instructions (SOIs) for applicability software developed across all engineering disciplines.

29. Deana Seigler • Deana Seigler received a B.S. degree in Computer Engineering from Auburn University in 1993 and a M.S. degree in Management and Administrative Sciences from The University of Texas at Dallas in 1997. • Deana is currently the Software Engineering Manager for the AN/APS-137 family of maritime surveillance radars at Raytheon in McKinney, Texas. She is also the Lead Engineering for the APS-137 Processor Upgrade program. • Deana joined Texas Instruments in 1993 and spent the first two years working in the Information Technology area. In 1995, she transitioned to working mission critical software for the APS-137 maritime surveillance radar. • Deana has served in the roles of individual contributor, CSCI Lead and Software Lead on various projects within the APS-137 Radar branch • Deana has received the Certified Software Development Professional (CSDP) designation from the IEEE Computer Society.