Craig S. Young Deana A. SeiglerSystems Engineering Manager Software Engineering Manager

APS-137 Programs APS-137 Programscraigs@raytheon.com seigler@raytheon.com

972-952-4616 972-952-4988

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

Branch of Surveillance Systems

Young/Seigler 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!

Young/Seigler 3

• Surface Search

• Periscope Detection

• Multi-Target Track-While-Scan

• Navigation / Weather

• Hi-Res Inverse Synthetic Aperture (ISAR)

Synthetic Aperture Radar (SAR)

APS-137B (V)5

Mission Capabilities

• 1st squadron deployed May 98• 1st squadron deployed May 98

ASUW Improvement Program (AIP)

Young/Seigler 4

Radar SetComputer

Signal DataConverter

Radar SetControl-Interface

Receiver PulseCompressor

ProgrammerPower Supply

Receiver-Exciter-Processor

AntennaControlIndicator

Transmitter(TWT-CFA)

Radar SetControl

Transmitter(Air Cooled

TWT)

A(V)5/B(V)5 Common

A(V)5 Mod for B(V)5

A(V)5 Only

B(V)5 Only

Synchronizer-Exciter

20 i8601 68040

2 AMD-2093

1 68030

31,500 LOCAll New

27,700 LOC1,700 New

16,500 LOC3,500 New

AN/APS-137A(V)5 to B(V)5 Radar Configuration

Young/Seigler 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!

Young/Seigler 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

Young/Seigler 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

Young/Seigler 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

Young/Seigler 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

Young/Seigler 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

Young/Seigler 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)

Young/Seigler 12

• Extended B(V)5 SAR Imaging Range

• Improved Navigator from Sandia• Precision Targeting Capability

Elevation Data (DTED)Library of targets within radarDigital 4X ZoomPoint-To-Point Range and bearing

• Under contract for Lot 4 and backfit of Lot 1-3 Radars

Mission Capabilities

Receiver-Exciter-Processor

Radar SetControl

24 i8601 680401 PPC

48,000 LOC16,500 New

21,000 LOC4,500 New

AN/APS-137C(V)5

Young/Seigler 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

Young/Seigler 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

Young/Seigler 15

1 ft resolution

Benefits to the ELCID Program

• 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 recent

technical conferences– Performing well in

Operation Enduring Freedom

R1 Max Range7 Flights / 138 Apertures1 Outlier not shown

50% CEP

Radar-Only Spec CEP

Measured Absolute CEP

Young/Seigler 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.

Young/Seigler 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.

Young/Seigler 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

Young/Seigler 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.

Young/Seigler 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.

Young/Seigler 21

Step 4 - UHR-ISAR Program

• $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.

Receiver-Exciter-Processor

Radar SetControl

57,600 LOC9,600 New

23,500 LOC2,500 New

Radar SetControl-Interface

28,000 LOC300 New

Young/Seigler 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

Young/Seigler 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

Young/Seigler 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.

Young/Seigler 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

Young/Seigler 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

Young/Seigler 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!

Young/Seigler 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.

Young/Seigler 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.