2006 Issue 1




through Integrated

Systems and Software


Ask ETMQ online


Editor’s Supplement

A Message from Dr. Peter Pao

2005 Issue 4:

Enabling Mission Success

(page 10) – the acronym for

WISDM should be defined as

Weapon Information System and

Data Management, not Weapon

Integrated System of Data



Acting Vice President of Engineering, Technology, Manufacturing & Quality

A friend told me many years ago that “In a given program, Systems Engineers

understand the needs of the customer and invent and define the solutions,

Hardware Engineers design and build hardware that supplies the building blocks

and Software Engineers provide software that integrates the hardware into the

system, gives it life and transforms it into a solution.”

Software is the realization of system design, so it is imperative for us to approach

systems and software as integral to each other. With systems and software as our

focus this issue, we consider it in the context of Mission Assurance. Whether it’s the

migration of technology to software-intensive system implementations (page 4),

Raytheon’s role in defining systems modeling language (page 6), or the critical

elements of Mission Systems Integration (page 8), you will learn what drives us to

perform. And performing as a prime is the discussion at hand for Dr. David

Usechak, who shares his experience in Distributed Common Ground Station

programs (page 10).

This issue addresses the critical need for integrated diagnostics and prognostics

(page 12) and how to apply Mission Assurance attributes to net-centric architectures

(page 20). And you will always find helpful information in our regular sections

on CMMI (page 26), Design for Six Sigma (page 27) and IPDS (page 28).

These are powerful tools that help us achieve our goals of Mission Assurance.

Another tool is education. We are proud to introduce the Systems Engineering

Development Program (SEtdp), and our system engineering development class,

which celebrates its first wave of graduates (page 30). Also for our even younger

audiences, please take a moment to read about MathMovesU (page 32), Raytheon’s

math and science initiative designed to prepare our future engineers with the critical

education necessary to ensure our nation’s future competitiveness.

Technology, knowledge sharing, education and preparedness — all of these elements

add to Mission Assurance by providing us with the tools we need to provide our

customers with the right products and services every time. We must always set the

bar a little higher and ensure constant technological evolution.

In April, we celebrate exceptional achievements in technology by congratulating the

2005 Excellence in Technology award winners (page 31). Their work keeps us sharp,

drives our technology and is key to the success of our company.

Also in April, please join me in welcoming Taylor W. Lawrence, Ph.D., Raytheon’s

new vice president of Engineering, Technology and Mission Assurance, effective

April 10, 2006. Dr. Lawrence is going to lead our organization into a new era, and

we are pleased to welcome him aboard.

Peter S. Pao

technology today is published

quarterly by the Office of Engineering,

Technology, Manufacturing & Quality

Vice President (acting)

Dr. Peter Pao

Managing Editors

Mardi Balgochian Scalise

Lee Ann Sousa

Editorial Assistant

John Cacciatore

Art Director

Debra Graham

Publication Coordinator

Carol Danner

Expert Reviewer

Kevin Marler


Tom Brozenec

John Gunther

Cathy Ibrahim

Vanessa Leong


Achieving Mission Assurance: The Migration of Technology

to Software-Intensive System Implementations 4

Information Assurance Reference Architecture 4

Systems Modeling Language and Mission Assurance 6

Mission Systems Integration:

A key driver for achieving Mission Assurance 8

A Customer Interview: Dr. David Usechak 10

Designing for Health: A methodology for integrated

diagnostics/prognostics 12

Engineering Perspective: Kenneth Kung 15

HRL Technology NCS Transition 16

Mission Assurance and the UML Profile for DoDAF/MODAF 18

Applying Mission Assurance Attributes to

Net-Centric Architectures 20

Eye on Technology

EO/Lasers 22

Processing 23

RF Systems 24

Materials and Structures 25

CMMI Accomplishments – v1.2 Model Update 26

DFSS: A Tool for Mission Assurance at a System Level 27

Developing IPDS v3.0 28

Systems Engineering Technical Development Program 30

Excellence in Technology 2005 Award Winners 31

MathMovesU 32

Patent Recognition 34

Future Events 36


As we prepared this issue, we couldn’t help but think of how much we rely on technology.

From cell phones and Blackberries to laptops and workstations, they are all critically

dependent on systems and software integration. In recent news headlines, there has

been talk of Blackberries going away — how would we get through the day? Or what if

we didn’t have a cell phone or laptop for a day? It’s not a pretty picture.

But just imagine one of our warfighters who is counting on getting the most accurate,

uncompromised information on time, every time to execute his mission. What if the network-centric

systems, on which his and so many other lives depend, delivered vital information

too slowly for him to respond; or worse yet, that information was intercepted by

enemy forces? This sobering thought brings to mind a comment from an Army colonel

who once said that he hoped that the engineers at Raytheon thought that what they

were doing was more than just a job — and they do. Our customers demand the very

best cutting-edge technology that Raytheon has to offer.

As consumers, we also demand constant improvement and innovation in technology; it

has to meet our needs in this ever-busy world. As editors, we continually strive to meet

your needs. Tell us what you want to see in technology today. What do you like, and

where do we need to improve? What features can we add that will give you more useful

information and make this magazine a better resource for you? When we say we

want your feedback, it’s not just a line. Drop us one and tell us how we can make this a

magazine you can’t wait to read. Email us at We’re

standing by to hear from you.

Mardi Balgochian Scalise Lee Ann Sousa



Achieving Mission Assurance:

The migration of technology to

software-intensive system implementations

Now more than ever, our customers’

desires and the current state of

technology demand that systems

and software engineering be viewed as an

integrated discipline. Here at Raytheon,

software engineering and systems engineering

technology have been integrally linked

for many years.

The Raytheon Systems Engineering

Technology Network (SETN) and Software

Technology Network (SWTN) have the

responsibility to foster technology transfer

and promote communications by linking the

engineering community throughout all of

Raytheon, thereby ensuring a competitive

advantage through leveraged technology,

synergistic product development and technical

reuse. In recent decades, as the line has

blurred between systems and software

development, the two networks have provided

a united front to solve technology

issues facing the company.

Integrated systems and software engineering

is at the core of virtually all product and

system development at Raytheon. For one

thing, it plays an important role throughout

the entire development life cycle — from

initial concept studies, through design and

development, to pre-planned product

upgrades during the operation and maintenance

phase. Applicable methods and techniques

have been developed by engineers

across different projects, at different geographical

locations and for different customers.

Yet, by sharing the same processes

and tools, engineers across the company

can exchange information and experiences

to reduce the total ownership cost, maintain

development schedules and apply best

practices. For example, we note that all

Raytheon businesses are now focused on

deploying Mission Systems Integration (MSI)

processes and approaches. Core MSI tech-


nologies include system architecture development

and the associated developmental

methodology. Both technology networks

have jointly sponsored the enabling technologies;

several of them, in fact, are highlighted

in this issue of technology today.

The magazine you hold in your hands highlights

some of the key issues addressed by

the SWTN and SETN. Raytheon aspires to be

the definitive Mission Assurance (MA)

provider for our customers, meaning they

have “no doubt” that Raytheon’s products

will meet all mission objectives. To be successful

in this objective, we must have a

wealth of technology to solve the problems

that they encounter. But that’s not all. We

must also have the processes and discipline

required to execute our solutions flawlessly.

This issue features topics addressing specific

MA initiatives within the company, as well

as how underlying technologies such as

architectures, modeling languages, MSI,

health management systems and dual technology

development and transition relate to

MA at Raytheon. We are also pleased to

introduce the people behind the technology

by profiling some of the engineers who

have made key contributions toward the

advancement of systems and software


We hope you enjoy the material and

encourage all Raytheon employees to

participate in one or more technology

networks. For a listing of all technology

networks and their Technology Interest

Groups, please visit


Steve Jackson, Director and SWTN Chair,

Dr. Kenneth Kung, Principal Engineering






A New Beginning

Information Assurance (IA) is a term

which comprises the technical and

managerial measures designed to

ensure the confidentiality, possession or

control, integrity, authenticity, availability,

and utility of information and information

systems. This term, which has spread from

government use into common parlance, is

sometimes used synonymously with the

term “information security.” Without IA,

data that passes from one system to the

next cannot be trusted; for example, information

could be released to unauthorized

personnel or, worse, to an adversary who

might use the acquired information to

develop counter measures. Another potentially

undesirable outcome is system unavailability,

resulting in delayed critical commands,

which might lead to a failure to execute a

mission. Robust IA is particularly important in

net-centric systems where the fundamental

raison d’etre of the system is providing seamless

data and information flows on demand

to users through an interconnected grid.

Therefore, it’s imperative that we in the

engineering community ensure the integrity

of data resident on and passing through our

systems. Decision-makers must be able to

assume that the information they obtain is

non-corrupted. It is for this reason that

robust Information Assurance architectures

are a fundamental enabler to net-centric

operations; Raytheon must ensure that

interrelated systems operate seamlessly and

as securely as possible. Therefore, one can

reasonably conclude that before Mission

Assurance can be achieved, particularly in a


Policy/Decision Support


GIG Management

Assured Command and Control Missions


GIG Infrastructure

Defend the

Network and



People Technology

Rules Filters

Defend the




Status Information


Policies & Control


Garrison Operations

Defense in Depth Strategy

Defend the




Government Departments and Agencies Intelligence Community Coalition Commercial Services

net-centric environment, there first must be

Information Assurance.

What Constitutes Information Assurance?

For a network-centric system to operate

effectively, Command and Control Systems

must take input from various sensors,

process it into information and then analyze

it into knowledge. Commanders then use

this knowledge to issue commands in

reaction to the situation. Throughout this

process, the confidentiality of information,

the integrity of applications and data, and

the availability of various systems at the

critical time must all be guaranteed.

Confidentiality deals with the access control

of the information contained in the system.

Only authorized and authenticated users

may have access to the need-to-know

information. Integrity service protects the

application from unwanted or accidental

modification. It also protects data during

creation, modification and deletion processes.

System availability must be guaranteed,

especially during the critical time of

mission execution. Together these form

Information Assurance.

Information Assurance Reference Architecture (OV-1)


Defend the


Antivirus | HAIPE | Firewall | Network Intrusion Detection System


Commands & Control



The Right Information



Rules Filters


Status Information

Deployed Operations

Black Core Posts/Camps/Stations SIPRnet/INPRnet Joint Networks JTR JNMS Component Force



Figure 1. Global information infrastructure defenses must be managed, deployed and

implemented to maintain confidentiality, integrity and availability of services.



Raytheon’s IA Reference Architecture

In the past, Raytheon developed IA architectures

for delivered systems on a case-bycase

basis. Applying the architecture this

way resulted in little systematic reuse of

products or designs. In 2005, Raytheon

addressed this shortcoming by developing

an IA reference architecture — a generalized

architecture that addresses a domain

by defining its features and functions. The

foundations of this development were laid

at the IA Reference Architecture Team

Architecture Blitz Session held in October

2005. At this session, the team employed

the Zachman Framework to organize the

reference architecture; three rows and six

columns of Zachman cells were captured.

For a more detailed discussion of how the

Zachman Framework was employed, please

contact the author. For more information

about the Zachman Framework, visit

The result of the Blitz Session was an IA

reference architecture composed of six main

principles. The principles were reached via

consensus to guide the rest of the architecture


1. Flexibility – Adversaries are unpredictable;

our architecture must be easily adaptable.

2. Defense in depth – Specifically, since

adversaries are both inside and outside

the defined perimeter of our networkcentric

system, IA must be provided at

every level.

3. Divide and conquer – Divide the problem

into smaller spaces and tackle them one

at a time.

4. Keep it simple – Select only a few

indicators to sense the overall IA state.

5. Minimum cost – Use COTS, GOTS,

strategic partner products, universities

results, government labs, etc. to reduce

the cost of the ultimate system.

6. The best defense is a good offense – No

defense can withstand constant attacks;

therefore we must design our defensive

mechanisms to counterattack via the

Information Operation Attack mechanism

(which is beyond the classification of the

open literature).

One particular artifact of our IA reference

architecture is the DoDAF Operational View

OV-1 shown in Figure 1. This figure shows

the three operational levels: national level

where the global security policy is modified

according to the cyber situation; GIG IA

Management, which issues orders to various

systems to change their IA parameters

and receives status information from them;

and individual operational nodes in the

information infrastructure (both in garrison

operations and in deployed state). Other

DoDAF artifacts produced include AV-1, AV-2,

OV-2, OV-5, OV-6, TV-1 and TV-2. Please

contact the author for a copy of these views.

If you are interested in learning how the IA

reference architecture was built, the project

overview will be presented at the 5th

Annual Systems and Software Engineering

Symposium, to be held in Denver, Colo.,

March 28–30, 2006. Raytheon engineers

and customers are welcome.

Dr. Kenneth Kung

Principal Engineering Fellow



Systems Modeling Language (SysML)

and Mission Assurance

How Raytheon’s role in defining SysML

can lead to better systems

Integrated Systems Modeling

For decades, the holy grail of systems engineering

has been the practical application

of a truly model-driven approach to system

development. This approach differs from

more traditional document-driven or

database-driven approaches to systems

engineering 1 by representing system

requirements, functionality, structure,

interfaces and performance in a single

integrated system model 2 . Figure 1 represents

the concept of a system model as a

framework for defining, capturing and

representing system characteristics. These

include not only basic physical attributes

(e.g., mass, volume, power consumption),

but also a definition of key system relationships,

operations and behaviors, along with

traceability to system requirements.

Note that a system model is not merely a set

of diagrams. Rather, a true system modeling

tool generates diagrams from an underlying

model; when the model is changed, the

diagrams are automatically updated

onscreen. Many tools, methods, techniques

and notations have been used to develop

systems models 3,4,5,6 . It is most important to

use an approach that ensures the resulting

system model will be semantically consistent

and complete — in other words, free

from ambiguity and inconsistency, and adequately

complete to serve as a solid starting

point for more detailed system design.


Figure 2 depicts the use of a system model

as the centerpiece of system engineering

activity. When successfully employed, the

ability to represent system requirements,

functionality, structure, interfaces and performance

in a single integrated system

model facilitates a quantum leap in system

design quality, modularity and productivity.

System specifications and design

Figure 1. A system model captures form and function in a rigorous hierarchical framework.

documentation are generated “on the fly”

based on the data in the system model,

effectively becoming simply tailored views

into the model. Once the system model

becomes the “working fluid” of systems

engineering, the day-to-day emphasis shifts

from generating and

maintaining documents

to expressing and analyzing

system concepts in

the model. The impact of

successfully deploying an

integrated system model

for mission analysis and

architecture, system design

and specification, performance

analysis, specialty

engineering, and verification

analysis and execution

has been discussed

elsewhere (technology

today, vol. 3, issue 2).

System Modeling Needs a Language

While model-driven systems engineering

approaches have been successful on a small

number of programs, widespread adoption

of systems models has been problematic.

Many of the reasons for this are cultural,

though there are some technical challenges

as well. One of the significant technical

challenges to widespread practical employment

of integrated system models is the

lack of a clear, unambiguous, standard language

for system modeling. A number of

software and systems modeling tools have

advanced their own languages, notations

and methods for expressing systems modeling

concepts, but no single tool has provided

the breadth to adequately express the

scope of a truly integrated system model.

To date, no tool has been successful at

transferring anything but the most primitive

concepts to another tool. The adoption of a

standard comprehensive language for systems

engineering promises to address both

of these tool-related issues.

SysML Supports System Modeling

For the past three years, Raytheon has participated

in an industry-wide team to design

a language that is specifically tailored for

large-scale integrated system modeling.

Based on the popular UML (Unified Modeling

Language) for object-oriented software

development, this new “dialect” is referred

to as SysML and provides a much broader

capability to model requirements, nested

hierarchies, physical flows and characteristics,

and mathematical relationships between

model elements. Particular emphasis has

been placed on making the language usable

Figure 2. Model-driven systems development leverages this framework

to focus on systems definition and analysis rather than document


and intuitive to the average systems engineer.

While the power of UML is still available in

SysML, systems can be effectively modeled

without the need to study all of the concepts

of traditional object-oriented design.

As shown in Figure 3, SysML’s four “pillars”

specifically add capability in the areas of

1) structure (hierarchical definition and

usage of blocks/parts/connectors/ports);

2) behavior (hierarchical state machine;

function/activity flow, data flow and interaction/sequence

modeling); 3) the addition

of a formal concept of requirements and

specifications to the language; and 4) the

addition of a new rigorous formalism for

expressing mathematical relationships

among system properties. The expressive

power of this latter “parametric” capability

has been demonstrated by Dr. Russell Peak

at Georgia Tech on moderately complex

mechanical engineering problems. Most

importantly, SysML introduces several crosscutting

concepts (traceability and verification

of requirements, allocation of function,

flow and structure, and value binding for

mathematical equations) that can be leveraged

to ensure consistency and completeness

of the resulting system model. SysML

certainly appears to be robust enough to

meet the challenge of supporting modeldriven

system development at Raytheon.

SysML Implementation and

Mission Assurance Payoff

The first release of SysML is in the final

stages of approval. As of this writing, two

variants of the updated version 1.0 specification

have been submitted to the Object

Management Group (OMG) for evaluation

and adoption. A critical review of these submissions

is underway by both the OMG and

the International Council on Systems

Engineering (INCOSE). The issues raised during

these reviews will be categorized into

short-term and long-term fixes. Raytheon is

making every effort to ensure that the initial

version of SysML will adequately address

the short-term issues and will therefore be

approved by the OMG without delay.

Longer-term issues should be addressed by

a planned update to the SysML specification.

Raytheon’s direct contribution to

SysML has focused on allocations (which

are widely used in systems engineering, but

the concept is new to UML) and the sample

problem (the first direct application of

SysML to solve a “real world” problem,

including the operational concept,

Figure 3. SysML relies on four pillars and cross-cutting associations to formalize

system definition.

requirements, behavior, structure and performance

of the power management subsystem

of a hybrid sport-utility vehicle).

Once SysML 1.0 has been approved by the

OMG, SysML-based tools will become

prevalent, and integrated system modeling

will become more practical and more transportable.

Deployment of SysML at Raytheon

will help make reference architectures a

practical reality, both at the corporate

(strategic) level and business (product line)

level. SysML also compliments the Raytheon

Enterprise Architecting Process 7 (REAP) by

providing a standard representation of basic

architectural concepts and enables the

Integrated Product Development System

(IPDS) by making standardized training and

system design repositories possible.

SysML is broad enough in scope to be used

to describe not just the basic system design,

but also key system characteristics of interest

to reliability engineers, test engineers,

manufacturing engineers and logisticians.

At last a common language will be available

that will facilitate not only system specification,

but also Reliability/Maintainability/

Availability (RMA) analysis, performance

prediction and even predictions of overall

mission success. As tools and processes

become available that are based on SysML,

Raytheon will be leading the way implementing

integrated systems models on key

programs, providing early and accurate

visibility of Mission Assurance concerns into

the design process. Many key Department

of Defense customers recognize the need

for integrated systems models in order to

provide architectural quality and design

consistency to their programs. To this end,

systems models are being developed on

several of Raytheon’s major programs.

Raytheon could benefit immediately by

employing a standard language like SysML

and establishing neutral-format system

model libraries. It is a high priority for

Raytheon that SysML be adopted as a

standard without delay.

Rick Steiner, Engineering Fellow

Systems Engineering Technology

Network Chair, Raytheon representative

to SysML Submission Team

1. Systems Engineering Handbook, International Council

on Systems Engineering (INCOSE), INCOSE-TP-2003-016-

02, Version 2a, 1 June 2004

2. Tutorial: Topics in Modern Requirements Development,

R. Steiner and J. M. Green, San Diego INCOSE, 11 May 2002

3. The Design-Methods Comparison Project, T. Bahill et. al.,

IEEE Transactions on Systems, Man, and Cybernetics-Part

C: Applications and Reviews, Vol. 28, No. 1, Feb. 1998

4. Engineering Complex Systems With Models and

Objects, D. Oliver, McGraw-Hill, 1997 ISBN0-07-048188-1

5. Doing Hard Time, B. Douglass, Addison Wesley. 1999

ISBN 0-201-498370-5

6. Process for System Architecture and Requirements

Engineering, D. Hatley and I. Pirbhai, Dorset House,

2000 ISBM 0-932633-41-2





Rolf Siegers is chief architect of

Raytheon’s Garland, Texas

Engineering Center and leads the

Raytheon Enterprise Architecture

Process (REAP) initiative. Rolf has

spent most of his 22 years at

Raytheon working all phases of

system development and deployment for largescale,

software-intensive classified programs in

Intelligence and Information Systems.

Rolf first became interested in formalized architecting

techniques about 10 years ago, developing

and deploying a Software Architecture

Team (SWAT) concept to address cross-IPT

architectural issues for programs at his site.

Rolf implemented this concept across several

multi-discipline architecture teams including

PMACS II, SCC-SIVAM and the MIND programs.

His experience leading these multi-site, multicompany,

multi-culture architecture teams

resulted in the identification of dozens of common

architectural issues that are now used as

a tasking baseline for new SWAT deployments.

Rolf and several colleagues began the initial

work on REAP in 1999. REAP was baselined in

IPDS in November 2002 and has been established

as the Raytheon-wide standardized

architecting process.

Rolf has spent recent years working to enhance

Raytheon’s architecture competencies across all

business areas, focusing on proposal and program

deployments, customer understanding,

training, certifications, architecture reviews, reference

architectures, industry communications

and collaborations with standards organizations.

He has taught architecture courses to

hundreds of Raytheon engineers. Rolf collaborates

with several industry working groups

focused on maturing the architecture discipline,

including Zachman International, The Open

Group, Software Engineering Institute, INCOSE

and the Systems Architecture Forum.

Rolf sees enterprise architecture as a critical

enabler supporting Raytheon’s focus on

Mission Assurance and Mission Systems

Integration, providing a real opportunity for

business growth and supporting Gate -1 and

Gate 0 customer engagements. “Requirements

specifications and ConOps documents are no

longer sufficient to drive systems development.

We must have a clear understanding of the

customer’s goals at one or more levels above

the system we are developing to ensure they

achieve their mission goals and objectives and

to support them in defining the future state of

their acquisitions,” Rolf says.

Rolf holds degrees in computer science and

mathematics. He is in the inaugural Wave of

the Raytheon Certified Architect Program and is

certified as a TOGAF-8 Architect, ATAM®

Evaluator (Software Engineering Institute) and

Software Architecture Professional (Software

Engineering Institute).



Mission Systems Integration:

A key driver for achieving Mission Assurance

Mission Systems Integration (MSI) is

an evolving system and software

engineering practice that encompasses

both net-centricity and an enterprise

of system-of-systems products. By carefully

determining and validating capabilities

desired by our customers, evolving solutions

via the reuse of existing well-understood

and verified systems and applying standard

horizontal integration processes, we can

provide solutions that have lower risk and

higher confidence for mission satisfaction.

Driven by the Evolving Market

Upon careful observation, it is apparent

that our customers are now rarely investing

in new major or strategic systems that

provide unique stand-alone capabilities.

Instead, they are seeking new capabilities

by extracting, combining and adapting

elements of existing systems. They expect

to invest in the interconnection and interoperation

of existing systems and not in

new systems intended to operate alone.

Examples of this approach can be seen in

planning for the Next Generation Air Traffic

Control System, which focuses on interconnecting

and interoperating existing commercial

and military systems without investing

in new air traffic control elements. It

can also be seen in earth-imaging operations

that concentrate on integrating

command and control functions and data

from a wide variety of sensors, while

severely limiting investment in new platforms

and sensors. This reality makes it

essential for the engineering community to

have a deep understanding of the nature

and performance of existing systems to a

degree that allows evolving, morphing,

adapting and interconnecting elements

from various existing systems. Such interconnections

can be used to create new

system-of-systems, providing capabilities

that satisfy new and complex missions.

The success of this approach depends on

skill and speed in system understanding and

integration. Achieving “first to demonstrate”

and “first to market” at a cost far

below the original contributing systems will

determine who dominates MSI opportunities.

Raytheon is uniquely positioned for

such accomplishments. As never before, it

is our business to provide interconnection

and interoperation of existing operational

system elements to create new capabilities

that will satisfy a family of customer mission

scenarios. Indeed, new systems, when

designed using reference architectures and

evaluated with existing well-understood

and validated modeling and simulation

elements, will allow us to aggressively

respond to new mission opportunities.

Reference architectures provide reusable

open standard frameworks that can be

adapted for a particular customer application

in a specific domain. For example, a

command and control reference architecture

provides a starting framework for

command and control that can be tailored

and adapted for an Army “communicationon-the-move”

system. Using common

frameworks as points of departure for

design will allow reuse of system elements.

This approach ensures the value and viability

of our existing component, subsystem and

system designs as elements in new

system solutions. If a system element does

not have interfaces that comply with open

standards and is readily interoperable with

other heterogeneous system elements, it

has little value as a resource for future solution

offerings. Our skill at encapsulating

legacy systems into these frameworks will

also determine our market share.

The Critical Elements of MSI

To understand the new paradigm in depth

and to clearly appreciate how it provides a

high degree of Mission Assurance, let’s

break down the three elements of MSI. The

first aspect of MSI is the focus on understanding

and mapping a customer mission

into a family of scenarios that must be

satisfied. The decomposition of a wellunderstood

mission into its essential scenario

set allows a family of required capabilities

to be defined. A rigorous exploration

of the mission by defining and evaluating a

family of scenarios ensures that we understand

the key performance parameters and

capabilities desired by the customer.

This is independent of the implementation

approach, which will be derived from existing

assets combined with some degree of

interface adaptation. The focus must be on

analyzing the scenarios that define the mission

in order to define a family of capabilities

that must be provided by the new system

offering. Cost and schedule advantages

are gained by using existing systems and

system elements to the greatest extent possible.

The capability set establishes the

requirements for the “new” system, which

may be the horizontal integration of existing

systems to create a new system-of-systems


This process of exploring mission needs

through scenario definition and capability

evaluations is depicted in Figure 1. The

solution that provides the capabilities

required is composed of a combination of

existing systems and/or subsets of systems.

The family of scenarios is evaluated by



Customer Mission Attributes



Capabilities Required











Figure 1. Determination of solution set




using modeling and simulation assets.

These evaluation assets are tied to scenarios:

If a new system must execute an existing

scenario, then the model and simulation

modules used to evaluate that scenario

should be reusable.

The scenario correspondence with simulation

and modeling assets provides the connection

needed to pull those assets forward

into new system representations. This, in

turn, enables rapid model development and

execution through the reuse of established,

validated model components with only minimal

modification. Variants in scenarios will

determine the extent of modifications

needed for the new application. Use of an

open standard interoperable environment

when creating models and simulations

allows this interconnection and reuse of

model elements with a minimum of adaptation

and interface design. This approach

greatly increases the assurance that the mission

being addressed by the new system

solution is the right mission and that the

predicted performance has a high degree of

accuracy and traceability to actual operational

system elements. A primary goal is to

rapidly provide an initial design instantiation

of the new system which can be evolved

over time with increasing levels of fidelity.

The second aspect of MSI is focusing on the

family of existing systems, which can be

exploited for capabilities to be combined

into new solution sets. If we have properly

architected our systems, then we will have

the ability to combine a wide variety of

whole or partial systems to provide new

capabilities that satisfy new missions. This

rapidly creates robust and mature solutions

with a minimum of new investment.

Existing systems will provide elements of

new system designs.

Finally, we consider the integration activity

critical to performing successful MSI — that

is, the ability to rapidly interconnect diverse

elements of different systems and to execute

operational scenario threads with limited

investment in new design. Such expertise

will increase our viability as a capability

provider. The value and performance challenge

resides in the interfaces. As our proficiency

evolves, we must explore system-ofsystems

interactions by horizontally integrating

our test assets and defining end-toend

scenario sets that establish the performance

levels of the new synergistic system

design. The ability to rapidly reconfigure

testbeds and evaluation assets within a

New System

A + B + partial C + Δ as needed










Model/Simulation A Model/Simulation B





Figure 2. Model reuse and system-of-systems


standard service-oriented development environment

will ensure success. Figure 2 illustrates

this new enterprise approach.

The new system-of-systems solution consists

of a synergistic integration of System

A, System B and parts of System C.

Additional design elements and corresponding

evaluation assets are added as needed.

The capability required of the new system is

represented by the three scenarios which

have been evaluated for prior systems. The

applicability of these scenarios allows the

reuse of existing modeling and simulation

assets. The new system model is then

Model A + Model B with some interface

and performance additions. Minimizing

additions is a key to high levels of MA.

Different models representing different scenarios

can be interconnected to explore

mission definitions and solution alternatives

in near-real time with our customers.

Achieving this enterprise approach will differentiate

Raytheon from our competitors.

Mission Assurance is enhanced by an MSI

approach to engineering practice that

employs a comprehensive understanding of

the capabilities needed to satisfy a customer’s

mission, the synergistic integration

of elements of existing operational systems,

and the flexible application of existing

validated simulation and modeling assets.

This approach allows us to offer our

customers solutions that are well-understood,

mature and aggressively focused on

satisfying their mission.

Leif De Wolf, NCS Systems Engineer


Feature: Customer Interview

The U.S. Air Force recently selected Raytheon

as the prime contractor to develop the Air

Force Distributed Common Ground System

(DCGS) Block 10.2 upgrade. As a customer

representative for the Army’s DCGS-A program,

Dr. David Usechak is highly knowledgeable

in this field.

Dr. Usechak has 35 years experience in program

management, engineering, software and

system development, integration, and testing

of Command and Control, Communications,

Computers, Intelligence, Surveillance and

Reconnaissance (C4ISR) systems for the U.S.

Army. He also co-authored an article on the

subject that appeared in a recent issue of

Defense Acquisition Review Journal.Called

“Net-Centric Warfare and Its Impact on

System-of-Systems,” the piece drew upon his

experiences working with the Army’s DCGS-A

program, a direct counterpart to the Air

Force’s DCGS program.

technology today sat down with Dr. Usechak in

January to discuss how net-centric warfare and

best practices, recent lessons learned on the

DCGS program, and trends in technology can

impact Mission Assurance. Jon Edmondson,

Net-Centric Architectures Technology Interest

Group co-chair, conducted the interview.

Edmondson (J.E.): Dr. Usechak, could you

tell us what your involvement with the

DCGS program has been?

Usechak (D.U.): I’m currently supporting

the Army DCGS-A program, which is a

counterpart program to the Air Force’s DCGS,

as part of the overall DCGS structure —

one for each service. The senior decisionmakers

decided that all the services should


The Air Force Distributed Common Ground Station

Block 10.2 Upgrade

An interview with Dr. David Usechak

get together and produce an RFP package.

The Air Force had already put together an

RFP package on the 10.2 program, which

was being held back for four to six weeks

to allow the other three services to take a

look and maybe restructure it so it could

support them, too.

J.E.: What is the key lesson learned from

the DCGS Block 10.2 experience?

D.U.: The technology that’s driving the way

industry and government conduct acquisitions.

For example, the government might

not need to award a contract to a prime

contractor like they used to and then have

them build everything from soup to nuts.

From a prime contractor’s point of view, this

technology that we are talking about in the

DIB (DCGS Integration Backbone) now says,

“Prime contractor, you are not going to do

business with the government the way you

used to do business, because it’s all changing.”

So a major paradigm shift is occurring

in both the government and the industry.

J.E.: For clarification, the paradigm shift is

specifically from what to what?

D.U.: In the past, the government would

put together a complete RFP package and

award it to a prime contractor, who was

totally responsible for development from

A to B. Now the contractor might be

responsible for just integration, not for the

development, say, of some of the components.

That’s because some of these components

— software, in this case — could

be coming from other sources like government

and industry. There’s no restriction on

where it comes from. So now the prime

contractor isn’t a developer and designer

like before; they’re just an integrator.

J.E.: Are the armed services tackling this

migration to the net-centric acquisition

approach independently, or is there any

effort to coordinate at a joint level?

D.U.: It’s a yes and no answer. Through the

networking group, the services are sharing

information, sharing lessons learned and

sharing ideas. As far as execution, each

service is executing what they think is best

for their respective service. When you look

at the military services, they all do business

in the field differently. For example, even

though they are both on the ground, you

would think the Marines and the Army

would do business almost identically. But

there are variations in how they do business

in the field — and that’s not going to

change overnight. The other point is that

each fielding service schedule is slightly

different, meaning when they need to start

fielding their respective systems to their field.

J.E.: Could you describe some of the

emerging mechanisms that could be used

to maximize the use of open standards and

minimize the use of proprietary standards

as net-centric development moves forward?

D.U.: From my point of view, the standards

have to be selected from reputable groups

like the IEEE or the W3C. One thing I need

to point out about standards is that they do

not guarantee interoperability, ease with

integration and so forth. The other portion

of this issue has to be solved by all the military

services, and that’s coming up with a

set of interface specifications. For example,

if you take a Simple Object Access Protocol

(SOAP) standard and hand it to two different

people, they will read the standards and

mechanize the SOAP implementation of the

standard and you’ll probably have two different

implementations. Taken separately

that’s okay. The question is: If I have these

two implementations against the same standards,

will they work if I take product from

A and product from B and do a swap? If I

take product A from vendor A and put it in

product B’s systems, will it work? The

answer is probably … but you’ll have to do

some minimal rework to make it work.

J.E.: So open standards that are accompanied

by reference implementations are more useful?

D.U.: I think they are, because now you’re

starting to eliminate people’s interpretation

of standards. It’s like I said: If you give the

standard to two people, you’re going to get

potentially two different interpretations of

the same standard, which would result in

two different implementations, which could

then result in the implementations not

being interoperable or swappable. If you

could reduce this fuzziness or vagueness in

what the authors meant, it should at least,

in theory, make it more robust. From a government

point of view, they now can go to

different vendors and have a fair amount

confidence that they can take a product

from vendor A, stick it in vendor B’s system

and it will work with only a little bit of

rework. Everything is not perfect, but what

you’re doing is reducing development time,

time to market, testing time and integrations.

I don’t think we’ll ever get to zero,

but this certainly helps.

J.E.: One of the things you’ve pointed out is

the misconception that a Web-based application

is automatically a net-centric application.

I was curious about the converse:

Would you say that net-centric applications

are automatically Web-based applications?

D.U.: I’m not sure Web-based means netcentric,

and net-centric doesn’t necessarily

mean Web-based. I believe that the bulk of

what we build today is heavily Web-based.

For example, if you mechanize the Java RMI,

you can go out across the net and there’s no

Web stuff in that. But I don’t think I need a

Web application to mechanize an RMI operation

in a net-centric environment.

J.E.: One of the things that I found interesting

in your article was the discussion of a

collaborative UML process with a user-tocapture

workflow pattern. How did that collaborative

process work?

D.U.: We experimented with that here in the

DCGS-A program. It got mixed reviews. We

need to get the user side of the house more

educated on how to do that — so it’s an

education thing that we have to solve.

J.E.: Has there been any progress recently

with the development of a metadata management


D.U.: Within the DCGS acquisition domain,

we’ve established a Multi-Execution Team

(MET) and a MET Working Group (METWG),

and they established a metadata sub-working

group that has been charged with trying

to resolve these issues. But we’re far from

having a total solution to this whole thing.

So here again it’s going to be some trial and

error. This is new for a lot of people.

J.E.: One of the lessons learned you mentioned

is that integration becomes the main

schedule-driver — not software development

— in the net-centric development

model. And a lot of that was due to the

mismatching of different non-developmental

products. Is this an issue of interface

behavior or just formats of the interfaces

between products?

D.U.: It’s a combination of both. Earlier I discussed

having a set of interface specifications

based on those standards and the

hope there is to mitigate some of those formats.

I don’t think we’ll ever drive the problem

to zero. This goes back to the net-centric,

open standards issue and the paradigm

shift in acquisition.

J.E.: How can the DoD community overcome

the fact that it’s only a small consumer, market-wise,

of commercial products? How can

the DoD influence the commercial developers

and software vendors to provide better

clarification on their interfaces so that they

can be more easily integrated?

D.U.: The DoD can make their needs known,

but we are not driving the market anymore,

so I don’t think the DoD is in a super position

now. The DoD can get more actively

involved in the standards committees to try

to help, to steer them, to provide lessons

learned and possible solutions. In addition,

DoD could say, “We need a solution that

will be referenced — and by the way, the

commercial market would like to have this

capability, too.” Then, you may end with a

joint venture between the DoD and the

commercial world.

J.E.: Back in the ‘90s you were the Army’s

COE chief engineer. To what extent do you

feel optimistic that these net-centric transformation

initiatives can overcome some of

the issues that the COE and the DII COE

were unable to fully address?

D.U.: The DoD learned some hard lessons in

the way that DII COE was going. Again, the

technology has now changed a lot of that.

Back in the DII COE we had to segment the

software — well, we don’t have to do that

anymore. The NCES program is trying to use

the open standards; they’re trying to modernize

the software using the newer technology.

That doesn’t mean it’ll be 100 percent

perfect, but I think that NCES is about

80 to 90 percent commercial. That should

overcome a significant number of issues,

such as integration and interoperability.

J.E.: You’ve mentioned several times that

the state of the technology enables a lot of

the capabilities that are envisioned in netcentric

services. What are some of the key

enabling technologies that are now more

mature than before?

D.U.: Let’s go back to Web services; look at

the underpinnings of UDDI, for example.

Like DCE (Distributed Computing

Environment), it’s nothing more than a fancy

address book which permits you the ability

to look up some information — for example,

someone’s address. We didn’t have that

kind of stuff back then. In the Army, on the

C2 side, in the middle-to-late ‘90s, we had a

look-up table, but it wasn’t as broad as

what it is today. Then there’s the Simple

Object Application Protocol interface and

another technology that has made life a lot

easier is the emergence of XML.

J.E.: These are all software technologies?

D.U.: Yes. If you look at our systems today,

they are very heavily software-dependent;

that is, a good 90 percent of them are

based on software. It’s like going to the

hardware store and buying the nuts and

bolts — it’s almost a no-brainer.

J.E.: Are there any additional points you

want to make about the impact on acquisition

that didn't make your article?

D.U.: Yes. It’s the overall acquisition and

development paradigm shift both for the

government and the commercial industry. I

believe some companies have recognized

that this shift is coming, and I’d like to think

they’re preparing themselves for the next

wave of RFP packages that the government

is going to release. That way they’ll be in a

better position to compete and hopefully

win. In my biased opinion, given Raytheon’s

experience on DCGS 10.2 programs, they

should be in a very good position to successfully

compete compared to their competitors.

But their competitors are not sitting twiddling

their thumbs; they’re trying to get smart.

J.E.: There’s the idea of using open standards

and using off-the-shelf applications.

The commercial marketplace is a huge behemoth

that’s going to meander in terms of

standards. Can the DoD look into the future

to see what those standards are going to

look like in 10 years?

D.U.: Standards will continue to evolve. But

that’s why I go back to the market —

because things are not going off on a

tangent unless there’s a sudden breakthrough

in technology. And I don’t see that

occurring, so this is going to be a slow

migration. The commercial world is not too

widely different than the military. They just

can’t throw the baby out with the bath

water. They sink all of their money into their

current systems … but you know the old

saying: “If it ain't broke, don’t fix it.”



Designing for Health:

A methodology for integrated diagnostics/prognostics

©2005 IEEE. Reprinted in part, with permission from IEEE Catalog Number: 05CH37671C, ISBN: 0-7803-9102-0

The integrated health management system

(HMS) complies with the new

Department of Defense (DoD) 5000.2

Instruction: Integrated Defense Acquisition,

Technology and Logistics Life Cycle

Management Framework 1 and supports the

needs of the end user by enabling improvement

in one of the critical measurements of

the end user: system readiness or operational

availability (Ao). The HMS attributes

of the system are key in complying with

this metric by providing sufficient on-board

and off-board health monitoring, fault

detection (FD), fault isolation (FI) and fault

reporting capabilities while minimizing false

alarms and re-test okays.

HMS is the capability to make intelligent,

informed and appropriate decisions about

maintenance and logistics actions based on

diagnostics/prognostics information.

Diagnostics is the function of determining

whether or not a component is capable of

performing its specified functions and

involves a high degree of fault detection

and fault isolation capability with a standard

goal of minimizing false alarms.

Prognostics, meanwhile, is the function

which includes predicting and determining

the useful life and remaining performance

life of components.

Meeting system Ao requirements relies

heavily on a systems engineering health

management design influence process that

provides traceability and feedback opportunities,

thus guiding design maturation. This

article discusses how an integrated HMS

enables Mission Assurance.

Life Cycle Framework

The DoD 5000.2 instruction divides the life

cycle framework into the five program

phases depicted in Figure 1.


Figure 1. DoD 5000.2 Guidebook Life Cycle Framework





User Needs & Technology Opportunities




An integrated health management design

influence process is vital for each of these

phases. Figure 2 illustrates each step of this

integrated health management design

process as it relates to the corresponding

life cycle phase. The following sections

describe, in detail, how this methodology is

used to support each phase.

Concept Refinement Phase

During the Concept Refinement phase (see

Requirements block in Figure 2), our HMS

methodology focuses on refining the initial

support and logistics concept for the life

cycle of the product. All possible product

support strategies, options and trade studies

(i.e., Ao vs. support costs) are completed

during this phase. The health management

outputs from this phase are studies

and analyses that document and shape the

preferred maintenance concept as defined

for the program. The maintenance concept

drives the product capability of removing

the correct faulty item at the right time satisfying

MA. This HMS strategy lays the

groundwork for the Technology

Development phase.

Technology Development Phase

System Development

& Demonstration

Design Readiness


During the Technology Development phase

(see Requirements block in Figure 2), the

HMS methodology focuses on reducing

technology risk and determines the optimized

HMS need for diagnostic/prognostic

Production &


FRP Decision


Operations &


technology integration into the system

design. Review of historical HMS factory/

field data from similar legacy systems is

very useful to aid in identification of HMS

diagnostic/prognostic hardware and software

features for the new system. HMS

technologies are researched extensively to

determine what is available and the degree

of maturity for technology insertion into

systems2 . New and emerging health diagnostic/prognostic

technologies are

reviewed, considered and planned as a part

of the technology readiness levels (TRLs).

Local HMS architectures are defined

through requirements and trade studies

while considering testing needs throughout

the life cycle of the product. Specifically,

trade studies such as cost/benefit analyses

are performed to determine what diagnostic

and prognostic features are affordable in

the design. Some important considerations

in a cost/benefit analysis include:

When and where will the product be

tested and where will maintenance

actions occur?

Should particular features be implemented

embedded (on board) or external (off


What is the estimated cost to implement

particular features?

What cost avoidance will particular features

provide over the life cycle (e.g.,

through minimizing maintenance and


Figure 2. Integrated health management system design process

User Needs & Technology Opportunities






System Trade




(Perf & Test)

Test Strategy

(Embedded vs.






& Technology






Analysis/Design Influence



(Health Modeling-


Test Verticality)






Model Failure


(Effect on Perf)

Feature Extraction

to Identify


to be Monitored

System Development


System Development

& Demonstration

Design Readiness






Identify Rel/Saf/


Critical Items

Partition Functions

& Develop Built-In/

External Test


Sensor Type

(Physical vs.


HMS Algorithm



The four primary HMS architecture design

best practices are as follows:

Functionally apportion the hardware to

aid in fault isolation

Decouple embedded diagnostic and

prognostic software code from mission

code; this allows standalone, up-front

testing during hardware integration and

facilitates code maturation

Provide built-in fault or data logs that

store parametric and fault code data;

these facilitate continued maturation of

the HMS design over the life cycle

Ensure test boundaries widen (due to tolerances)

at higher level tests to reduce

false alarms

The total test environment including integration,

validation, verification, factory, field

maintenance levels and depot testing is

considered when creating an optimized

HMS strategy and design approach that is

the best value solution over the life cycle of

the program. HMS requirements are

reviewed and refined during this phase and

risk mitigation plans put in place.




Through Test

(HW Available)

Production &


FRP Decision


Demonstration Phase

Reasoner Development

Develop Health

Baseline Curve

HMS Data

Pre Processing-


Algorithms Coded

Historical Field




Data Collection


HMS Assessment



Demonstration Phase

Operations &





HMS Data


and Maturation


Deployment &


Support Phases

The HMS concept is demonstrated through

planning, trade studies and preliminary topdown

testability/diagnostic dependency

models. These models are created to partition

hardware/software HMS solutions,

define tests to optimize the best testability

design strategy and mitigate risk during the

program’s System Development and

Demonstration phase.

HMS design influence, the dependency

modeling process and analysis enables the

identification of candidates for diagnostic/

prognostic technology insertion. Failure rates,

cost, predictive capability, sensors and processing

intelligence (reasoner) are all factors

for final determination and recommendation.

Exit criteria for the Technology Development

phase of a program includes the generation

of performance specifications that contain

HMS requirements necessary to meet overall

support (FD, FI, Ao) and life cycle cost

objectives. These specifications drive HMS

needs into the design during the System

Development and Demonstration phase.

System Development and

Demonstration Phase

During the System Development and

Demonstration phase (see Analysis/Design

Influence, Testing and Reasoner

Development blocks in Figure 2), the HMS

planning and execution focuses on reducing

integration and manufacturing risk, ensuring

operational supportability, reducing the

logistics footprint and ensuring affordability.

The HMS methodology starts with product

characterization during this phase. Product

characterization involves modeling the

system functionality along with failure probabilities

and dependencies. Some examples

of product characterization include detailed

functional dependency and Bayesian modeling

3 . Top-down testability analyses are used

in the derivation of subsystem hardware,

software and test equipment (factory, field

and depot) requirements to support the

HMS strategy. Testability analyses are iterated

throughout the design phase to refine

and optimize the diagnostic/prognostic test

strategies. The hardware diagnostic/prognostic

features and firmware/software algorithms

are embedded within the analyses

for traceability. This traceability along with

test verticality reduces the risk of “could not

duplicates” (CNDs) and “re-test okays”

(RTOKs). Critical items in the system are

identified for HMS focus to support safety

or mission reliability. Failure mechanisms

need to be identified, understood (i.e., the

“physics” of a failure) and analyzed for

their effects on system performance

(i.e., Failure Mode, Effects and Criticality

Analysis). Simulating these failure mechanisms

assists in developing a knowledge

base of multiple failure scenarios and their

impact on system performance.

The next step is identifying feature parameters

that can be extracted for inferring a

failure or an incipient fault (parameter

whose value is nearing a defined threshold

that infers or indicates an impending

Continued on page 14



Catherine Keller was fascinated

with the big picture right from the

start. In fact, at an early age she

wanted to become an astronomer,

taking as many classes on the

subject as she could. What better

way to learn how the world works

than to study the most universal topic of all?

Her instincts would soon pay off.

While Catherine was still at Pomona College in

Claremont, Calif., the local division of General

Dynamics recruited her to work with some of

their missile programs. As it happened, astronomy

students were routinely recruited to work

on electro-optical sensors. “My advisor was on

sabbatical my senior year so I ended up writing

my thesis on a solid state physics topic: the use

of mercury-cadmium-telluride in infrared detectors.

I laugh when I look back on how that

worked out; Mercad was considered very exotic

then. It was great to get hands-on experience

while I was still in school.”

After graduation Catherine entered into phase

two of her multi-faceted career. She landed a

job at Hughes Missile Systems in the San

Fernando Valley, a stone’s throw from her

home. At the same time, she attended USC as a

Hughes Fellow, where she obtained a master’s

in electrical engineering in Systems and

Communications. “I worked a variety of different

assignments in my career, because I always

wanted to see the bigger picture,” says Keller.

“It took me several years but I finally realized

that meant I was a systems engineer at heart,

not a designer. I really love making the connection

between what the customer needs and

what solutions we can offer.”

Today Catherine is the 2006 lead for Raytheon’s

Systems Engineering (SE) Council, composed of

the SE leadership from all of the company's

businesses. She is also the technical director for

the 900-person Systems Development Center in

Space and Airborne Systems Engineering located

in El Segundo, Calif. Her responsibilities

focus on two primary areas: technology strategy

and technical review.

When it comes to defining Mission Assurance

(MA) for SE, Catherine, a certified Raytheon Six

Sigma Expert, again applies her “big picture”

philosophy. To her MA means more than

just ensuring that the customer’s needs and

priorities are accurately represented in the

delivered product. “Mission Assurance is an

attitude about how we do our work. It has to

be part of the engineering culture, the technical

conscience on a program.”

Raytheon Six Sigma is a trademark of Raytheon



Designing for Health

Continued from page 13

failure). The correct sensors, real or virtual

(inferring information beyond the specified

use), need to be identified to monitor the

selected parameters. Therefore, parameters

must be selected that are compatible with

the maturity of sensor technology. Sensor

selection and placement starts with the

testability analysis/model. It is used to identify

failure modes, their failure effect propagation,

signal-to-noise ratios, propagation

time and gain. The figure of merit selection

step focuses on maximizing detectability

and identifiability of the failure mode while

minimizing the number of sensors. The

optimization step takes all of these factors

through a statistical analysis to provide the

optimal number of sensors and their placement.

The performance assessment step

monitors false positives, false negatives and

time delay for the purpose of updating the

figure of merit weighting for better resolution

(detectability and reliability) of the

sensing architecture.

A test plan is developed with the objective

of collecting baseline and fault data for

training/validating diagnostic and prognostic

algorithms. The HMS testing phase

begins during hardware and software integration

and verification. The diagnostic/

prognostic features implemented in hardware

are tested and verified. Failure propagation

is checked to ensure fault paths are

correctly modeled. Failure mechanisms

identified for prognostics are characterized

by inserting faults and monitoring the

effects (through the sensors) in simulated

expected environments.

Historical data is used wherever possible to

characterize the system in the environment

for a typical intended mission of the system.

When historical data is nonexistent,

environmental factors and mission scenarios

are simulated during testing, where feasible,

to fine-tune characteristics with the

objective of reducing false alarms and false

negatives. Collected data during the testing

phase is used to develop and mature diagnostic

and prognostic algorithms.

Diagnostic and prognostic algorithms are

developed during characterization and finetuned

throughout the testing phase.

A baseline diagnostic/prognostic health

curve is established to start the HMS

implementation into the system. As data is

collected, the curve is updated. The health

curve shows the probabilities of wear,

present sensor observation and mission

scenario; it then fuses these together to

provide a trend observation. This trend

observation is used to diagnose a failure

and/or predict the probability that a failure

will occur in a certain mission time frame.

A reasoner is developed using the dependency

models as a foundation for diagnosing

health and/or predicting failures for conditioned-based

maintenance (CBM). It reads

the sensor data and filters it using statistical

and/or intelligent techniques such as Bayesian,

Fuzzy Logic, Neural networks, etc. 4 .

Pre-processing algorithms are developed to

manipulate streams of data by filtering and

extracting the features outlined in the product

characterization. The data is fused

together, associated into categories and

correlated while comparing it to the health

curve in the modeling and evaluation section.

Predictive maintenance decisions are

made and reported out through the control

logic. Implementation of the reasoner

technology can be embedded on-board the

operating system or off-board using

external support and test equipment. The

reasoner provides the health intelligence

necessary for use in the production/deployment

and operation support phases.

Production/Deployment and

Operation/Support Phases

During the Production/Deployment and

Operation/Support phases (see Fielding

block in Figure 2), the HMS capability supports

Mission Assurance, exceeding the

required operational/support requirements

and providing sustainment in the most costeffective

manner over the life cycle. HMS

data collection and maturation is vital in the

Production/Deployment and Operation/

Support phases. Environmental factors that

may not be comprehended in analysis and

testing contribute in various ways to the

HMS algorithms. As a result, the product is

further characterized and algorithms are

fine-tuned during these system operational

phases as data is collected and analyzed. A

failure, reporting, analysis and corrective

action system (FRACAS) is an effective

means to collect, analyze and correct any

HMS shortcomings. New HMS technology is

inserted into the system through spiral

development resulting in continual

improvement. Data collection is key to HMS

maturation whether it's for newly designed

systems or for systems fielded for several

years. This process can be used on existing

fielded systems by using the field data to

characterize the product and improve the

design for HMS. A mature data collection

system improves HMS architectures for

future programs.

The HMS capability is fully tested and its

usefulness is maximized between the production

factory, fielding and depot activity

during these phases. An integrated HMS, in

a real-time operational mode, is able to

leverage the health information to reconfigure

or change mission objectives if critical

system capability is lost. This results in a

positive impact on mission success. Also,

the same health data can be relayed realtime

to the maintenance facility to prestage

spare parts, tools and personnel for

each repair level which reduces turnaround

time and increases the overall Ao.


System readiness is vital to supporting the

warfighter’s needs. A robust health management

system enables the warfighter and

maintainer to quickly access the health of a

system through diagnostics and the probable

failure impact of a mission through

prognostics, increasing probability of mission

success. This systems engineering

approach to integrated diagnostics and

prognostics provides the foundation to supporting

the total test environment with

traceability of requirements through analysis

and implementation while reducing false

alarms and CNDs.

Raymond Beshears

Larry Butler


1. DoD 5000.2 Guidebook Life Cycle Framework,

A Publication of the Defense Acquisition University,

2. Raytheon HMS information repository is located at



3. Bayesian reference:


4. Neural Networks and Fuzzy Logic reference:



How Systems and Software

Engineering Supports Mission


What is Mission Assurance and how can

system and software engineering contribute

to its success? A significant portion of this

issue of technology today has been dedicated

to addressing this question. Yet, beyond

the detailed technology, it would behoove

all of us in the engineering community to

reflect momentarily upon those end users of

our products.

Consider, for example, a soldier who finds

himself pinned down by enemy fire. The

soldier must eliminate the enemy position,

often times with friendly forces in close

proximity. The soldier may choose to use a

Raytheon product, like the Javelin. Clearly,

in such situations the missile must perform

without error. The very lives of our armed

forces depend upon it. Such a scenario,

though fictitious, is realistic and is an excellent

example of the importance of Mission

Assurance — our products must work as

claimed for the warfighter on the ground.

Such examples should leave those of us in

the engineering community with a desire to

truly understand how to achieve “no

doubt” results for all Raytheon products.

Thus, the very important question: Exactly

how does a system achieve Mission

Assurance? It is, of course, true that there

are many contributing factors — yet we

claim that integrated systems and software

engineering are among the most important.

Systems engineering deals with the fundamental

problem of how the “system” must

behave and operate; software engineering,


Kenneth Kung


meanwhile, provides the flexibility to provide

the needed features. These two disciplines

are at the forefront of ensuring that

all Raytheon systems perform consistently in

a way that our customers desire and expect.

Progressing by Leaps and Bounds

System and software engineering (particularly

as an integrated discipline) has come a

long way over the past several decades. It

used to be that mainframe computers and

microcomputers were quite unreliable, and

multiple system crashes were just an accepted

part of your day. As a result, it was very

difficult to rely on computers for any lifesafety

systems. Case in point: The air traffic

control systems that Raytheon delivered in

the 1960s relied more on hardware components

to provide the overall air picture to

controllers and flight strips were physically

handed off from one operator to another.

Today, operators can perform this same

hand-off with just a few clicks.

Designing Software-Intensive Systems

Today, we have much more mature and

complex technologies that allow us to

design software-intensive systems. Behind

these systems are many software and hardware

components that must work with

each other. For instance, object-oriented

system engineering and Unified Modeling

Language allow us to specify and design

unambiguously. We’re also in the midst of

researching how to better create system of

systems, and eventually, systems of elements.

Some of the articles in this issue illustrate

the advances we’re making. And while

progress is certainly being made, there’s no

doubt that more work is still needed in

system and software engineering.



HRL Technology NCS Transition

HRL Laboratories, LLC (,

is one of the country’s few industrially

funded research laboratories. And

Raytheon, along with Boeing and General

Motors, is one of its three LLC members.

Like the other members, Raytheon participates

with HRL in independent research

projects and contracted research and development.

Private research that is funded by

a member and focuses on the technology

needs of that member is called directed

research (DR).

This article examines a Raytheon DR project

that focuses on adversarial planning, an

automated search for ways to achieve goals

in the presence of adversaries that actively

oppose you. The project has developed

technology embodied in four invention disclosures.

Furthermore, a successful transition

of the technology to programs in the

Command and Control (C2) business area is

underway. Future military planning systems

will require such technology to successfully

execute their missions.

Project Overview

The Adversarial Planning HRL DR project is

sponsored by the Network Centric Systems

(NCS) Technology Office, which is directed

by Dr. Kevin Riley. Dr. Joan Mahoney of NCS

manages the project, while Mike Howard of

HRL is the principal investigator (PI).

Considered a branch of game theory, adversarial

planning was one of the first problems

studied by artificial intelligence

researchers in the 1950s. But the classical

research was limited to two-player, turntaking,

fully-observable, zero-sum games

(such as checkers) that could be solved by a

pure combinatorial search. Real-world problems,

like maneuver warfare or logistics, are

significantly more complex and, therefore,

require heuristically-derived solutions and

involve many tradeoffs.

Our initial algorithms for adversarial planning

demonstrated that the classical search

strategy, as measured by execution speed,

performed quite poorly. To improve performance,

our current strategy (implemented

in C++) uses an iterative local search,

heuristics and other ideas, from top planners

in the International Planning Competition




Figure 1. Adversarial planning system


With this approach, we’re now competitive

in several domains designed for the competition,

including a satellite observation

scheduling domain. The software has

also been applied to an urban attack scenario

developed jointly by NCS and HRL,

showing relevance to real-world battle

space planning.

The software solution developed by the

project is implemented as a client-server

system (see Figure 1). The user can generate

multiple courses of action and play out

various “what if” scenarios. In an adversarial

context, the system plans for each adversary

and iteratively finds conflicts and resolutions

for each. The output is a contingency

plan for each adversary; in other

words, it identifies their particular weaknesses

and ways to compensate. The result

is an interactive planning system that integrates

human judgment capabilities with

the computational power of planning algorithms.

Multiple decision support clients can

benefit from multiple plan servers. The

client-server architecture provides performance

benefits (multiple plans may be calculated

in parallel on different servers) and

reliability benefits (a multiple server system

can survive the loss of a server). These multiple

robustness features, in combination,

provide increased confidence in the ultimate

success of a mission which might

depend upon these solutions.

This project was presented at the Raytheon

SE/SW Symposium in April 2005. In the same





Route Planning

Weapons Trajectory Analysis

Key Terrain Analysis...




Goals & Feedback





Contingency Plans

for Each Adversary

year, three patent applications — for the

system, the user interaction capabilities and

a metric optimization technique — were

submitted to the U.S. Patent and Trademark

Office. A new disclosure on the adversarial

planning method was submitted to Raytheon

in November 2005 for consideration.

The software was demonstrated at the NCS

site in Fort Wayne, Ind., in July 2005 to

business and engineering management and

site technical staff. Raytheon representatives

from DD(X), Advanced Field Artillery Tactical

Data Systems (AFATDS), Distributed

Common Ground System-Navy (DCGS-N)

and NCS IR&D attended. Subsequently, NCS

personnel met with the PI at HRL and

reviewed the software for applicability to

future software builds. NCS see this capability

being used in future releases of current

programs. It could, for example, address a

commander’s generation and evaluation of

competitive plans in time-constrained situations

and with limited and uncertain information.

The ability to quickly create, review

and modify multiple plans increases Mission

Assurance by reducing the risk of settling

for a less effective plan due to limited time.

The software has also matured such that it

can be included in responses to Broad

Agency Announcements (BAAs) from the

U.S. Army Communications-Electronics

Command Research, Development and

Engineering Center (CERDEC), Defense

Advanced Research Projects Agency

(DARPA) and others with planning needs.

Technology Transition Strategy

The technology transition strategy is to

leverage HRL DR investment to develop

advanced technology for inclusion in operational

systems. The Adversarial Planning

System resulted from a cooperative

HRL/NCS effort. Significant collaboration

occurred in the following areas:

Shared domain knowledge HRL understood

the technology — but not the application.

HRL needed to understand how the

planning capability would be used. NCS

provided time and expertise from subject

matter experts in military operations and

hosted visits to NCS labs and training facilities

to support knowledge transfer.

Shared software The focus of the research

was the planning problem. However, there

was also a need for visualization, with standard

military symbology, to present the

results in a manner familiar to users. To avoid

diluting the primary efforts, NCS provided

GUI software available from a previous IR&D.

Shared results Periodic communication

using telecons, e-mail and document

attachments were used to keep HRL and

NCS mutually informed of the other’s

progress, problems and plans.

Shared responsibility Twice annually, HRL

prepared status reports and presentations.

NCS reviewed the information and provided

feedback prior to presentation. NCS attended

the presentations and scored the projects.

Shared recognition HRL and NCS jointly

prepared a presentation for the Raytheon

2005 SE/SW Symposium. The HRL PI made

the presentation; both the HRL researchers

and the NCS project manager were credited

as authors. HRL prepared invention disclosures,

and NCS reviewed them and submitted

assessments to the company’s

Intellectual Property (IP) Center.

Shared transition planning The HRL PI

supported a Technology Transition

Workshop at an NCS site with representatives

of multiple programs. A follow-up

meeting was held at HRL and a tentative

transition point was identified.

Lessons Learned

Consideration of the NCS transition experience

on this project points to some lessons

that are transferable to other Raytheon-HRL

projects. They include:

Development and transition take

three-to-five years. The Adversarial

Planning project spent much of the first

year understanding the problem; it

started to pay off late in the second year

and produced most of the novel discriminators

in the third year.

Plan for technology transition. Find

specific program requirements early and

develop a scenario that illustrates the

needs. Provide real or simulated data.

The more effort devoted to this step, the

more relevant the results.

Focus on the hard problems. Don’t

dissipate the researcher’s concentration.

Keep in touch. Researchers can focus

more on the technology than on program

needs; close interaction with sponsors

maintains balance.

Applying these lessons contributes to mission

success in collaborative projects with HRL.

Future Activities

A 2006 DR project, entitled Adaptive

Adversarial Reasoning, is funded to extend

the planner with cognitive capabilities and

integrate it with HRL analogical reasoning

software and fuzzy graph pattern-matching

software. The project will be coordinated

with a complementary project, Knowledge

Management Architecture for C2, which

targets development of a knowledge storage,

organization and retrieval system to support

rapid search and selection of patterns for the

Adaptive Adversarial Reasoning system. In

the future, deployed military systems will

depend heavily on such technology to successfully

accomplish their missions.

In 2006, sponsorship will be shared between

IDS and NCS; the system will also be applied

to IDS maritime domain problems.


Successful transition of HRL-developed

technology into Raytheon programs

requires frequent interaction and mutual

support. Active collaboration and frequent

communication reduce the risk of misunderstandings.

Judicious sharing of Raytheon

resources assures that HRL effort is focused

on the difficult technical challenges facing

our customers.

Steve Ignace, Systems Engineer


Hung Nguyen’s passion has

always been mathematics.

While working on his doctoral

thesis in mathematics at the

University of California,

Berkeley, Hung decided that a

few electrical engineering

courses might expand his knowledge of the

“real world.” Hung never formed a strong connection

with the engineering field, so in 1985,

when Raytheon offered Hung a position with its

Radar Systems Group in El Segundo, Calif., he

didn’t think he’d be staying for long.

Hung’s first task involved designing, implementing,

testing and integrating the signal processing

portion of the HPRF mode for the F-14D APG

71 radar system that was developed for the

F-14D Tomcat fighter jet. To get the job done, he

had to digest an inordinate amount of technical

information. For a man with little interest in

real-life applications and a passion for pure

mathematics, this represented a steep transition.

Thankfully, Hung received precious mentoring

from a host of senior software engineers; some

of them, like Ta-Lee Teng and Les Saizan, are still

at Raytheon today.

Delving further into software and radar systems,

Hung found that the pipeline architecture of the

signal processors used in the APG 71 radar system

intrigued him. As part of the software mode

development, he had to review his work in the

systems integration laboratory. This phase of the

assignment turned out to be a turning point for

Hung’s career at Raytheon. He discovered that

there was a world of information yet to be

understood and yearned to know everything

about the entire radar so he could make sure

new functionalities and developments worked

seamlessly as a whole.

Hung has worked alongside, and learned from,

some very talented engineers who excelled in

systems integration. Chuck McNett taught Hung

how to use hardware to diagnose software

issues, while Howard Waldman showed him how

to use software to troubleshoot hardware. Most

importantly, though, Waldman impressed upon

Hung that all anomalies could be explained if

one digs deep enough.

Today, Hung is considered one of the top system

troubleshooters at Raytheon. He is also a principal

fellow and serves as chief scientist of the

APG 79 Radar program.

“Reflecting upon my 20 years at Raytheon, I am

grateful that the company gave a mathematician

an opportunity to work on radar systems,”

said Hung. “Raytheon saw my potential before

I realized it myself. Everything that I know today,

I have learned from the many fine engineers I

worked with over the years – and I am still continuing

to learn. I firmly believe that there are

opportunities for people with different backgrounds

and skill sets to flourish at Raytheon.”



For Dr. D. Joel Mellema, senior

principal engineering fellow, the

transition from being a particle

physicist to a radar engineer

presented some interesting

challenges. One striking difference

between the two roles is the fact that the end

goal of academic research is very different from

the end goal of developing a product for a

customer in defense of the nation. On the

other hand, many of the technical disciplines

involved in real-time data collection are applicable

both to physics experiments and sensor

engineering. In fact, there are many similarities

between a real-time sensor and a modern

physics experiment that “senses” nature by

collecting and analyzing data in real time. Even

the underlying concepts of radar engineering

did not seem so strange, probably because

radar was invented by a bunch of physicists in

the first place!

Early in his career, Joel was a research associate

in the physics department at the California

Institute of Technology, where he worked on

experiments in elementary particle physics at

the Fermi National Accelerator Laboratory.

These experiments involved esoteric matters

like being the first group to find direct evidence

of quarks inside of π mesons.

Over the years, Joel has been involved with a

variety of systems and software engineering

activities at Raytheon/Hughes including several

SAS programs like the F/A-18 APG-79 radar,

the U-2 ASARS-2A radar and the Global Hawk

radar. His primary interests include real-time

embedded digital processing, computer

architecture and digital signal processing.

Joel has also worked on recent SAS advanced

technology initiatives and program pursuits.

He was a member of the team that won a

significant award from DARPA on the AACER

program — a program that will develop

Raytheon’s strategically important Microstrip

Transverse Device Electronically Scanned

Antenna. He’s also been involved with

Raytheon’s activities involving a disruptive

new digital processing technology.



Mission Assurance and the UML Profile for


Architecture Frameworks and

Mission Assurance

As military systems become increasingly

information-intensive and network-centric,

the basic approach to requirements definition,

system and enterprise architectures,

design, integration and test is rapidly evolving

to a model-based

strategy to help

ensure mission success.


models provide the

authoritative representation

of evolving

designs, drive

trade studies and


analyses, and create

the specifications

and other

artifacts used to

implement individual

systems and,

ultimately, net-centric


The highlighted

area in Figure 1,

from the DoD Office

of the Secretary of

Defense, illustrates

the key role of


frameworks and

underlying models Figure 1. DoD strategic architecture plan

(source :

in support of their 40/6023/Truman_Parmele_StratPlan2004-2007.pdf)

strategic plans

through the coming decade.

An object-oriented modeling methodology,

using the Unified Modeling Language (UML),

provides the tools and discipline to manage

complexity, clearly define performance and

interface parameters, manage configuration,

and demonstrate compliance with enterprise

architectures and standardization mandates.

The Department of Defense Architecture

Framework (DoDAF) (

nii/doc/DoDAF_v1_Deskbook.pdf) and the

United Kingdom Ministry of Defense

Architecture Framework (MODAF)

( are evolving frameworks

for building modern military systems. An

architecture-driven system development

process is a key enabler to ensuring the

accurate definition and representation of

functional capabilities that are such important

elements of Mission Assurance (MA).

The Model Driven Architecture (MDA)

initiative and the standards that help define

it provide a set of guidelines for structuring


expressed as

models and

the mappings

between those



both DoDAF/


MDA standards,

and then

linking them to

a powerful

Object Oriented


Engineering 1



supported by


tools, sets the

foundation for

a model-based

approach that

enables true

MA for both

civilian and

military systemof-systems


Figure 2 illustrates the standards context for

the UPDM effort, including architecture

frameworks, system modeling, modeling

languages and data interchange formats.

Note the relationships among the levels, as

architecture frameworks depend on system

modeling approaches (structured and

object-oriented) to define the various views

of the architecture and system models

depend on languages and data exchange

standards to specify and share the architecture

model descriptions.

A Model-Based Approach to

Mission Assurance

The Object Management Group’s (OMG)

Systems Engineering Domain Special Interest

Figure 2. UPDM standards context

Group (SE DSIG) and the OMG C4I Task

Force, within the context of the MDA initiative,

is in the process of defining Systems

Modeling Language (SysML) for Systems

Level Modeling. For more information, see

the article on page 6 titled, “Systems

Modeling Language and Mission Assurance,”

or visit SysML.htm.

For information on the UPDM frameworks,


The profile includes representations for modeling

system architecture and consists of a

system viewpoint (DoDAF System View)

along with related technical standards

(DoDAF Technical View) within the context of

a business viewpoint (DoDAF Operational

View). UPDM will also allow the architecture

model to include representations of an enterprise

capability and strategic intent (MODAF

Strategic Viewpoint) and the process steps

associated with the procurement of systems

(MODAF Acquisition Viewpoint).

The UPDM will provide for the standardized

modeling of general operational capabilities,

military services activities, operational nodes,

system functions and services, input-output

ports, communication protocols, system

interfaces, system performance parameters,

and physical properties and metrics. In addition,

UPDM will allow for the modeling of

related architecture concepts such as DoD’s

doctrine, organization, training, material,

leadership and education, personnel, and

facilities (DOTMLPF). It will also allow for the

equivalent UK Ministry of Defense Lines of

Development elements.

Available Tools

Currently, tool vendors are challenged to

support a range of DoDAF variants (e.g.,

MODAF) that have been created to address

the needs of several nationalities. In MODAF,

for example, a UML metamodel is being

defined to support XMI-based file exchange

between tools and repositories. In addition,

the DoDAF specification is characterized by

the underlying Core Architecture Data Model

(CADM) that is now being integrated into a

wider range of tool suites. Without a common

underlying metamodel, interoperability

across DoDAF tools — and definitely with

MODAF tools — will be increasingly difficult.

The ever-growing complexity and scale of

modern military systems characterized by

emerging system-of-systems design and network-centric

operations requires a collaborative

system engineering and architecting

effort across companies, military services and

nations. The absence of an industry standard

makes it difficult and costly to create, reuse,

consolidate, sustain and distribute architecture

models in collaboration. SysML, which

will soon achieve formal approval of Version

1.0, extends the proven power of UML in

software engineering to the broader challenges

of system engineering and is the

leading candidate to fill this void and enable

the necessary tool developments.

UPDM and Mission Assurance

Within the umbrella of OMG, Raytheon,

other aerospace companies and commercial

tool vendors are working together to help

define the UPDM specification and reference

implementations. UPDM attempts to address

the current deficiencies in both models and

tools for DoDAF and MODAF — and a combined,

collaborative effort offers the best

path forward. A key element of Mission

Assurance is the ability to clearly characterize

the structure, behavior, constraints and state

of a system in support of well-defined missions.

Integrated models that capture the

system level, software and hardware

architectures are a critical aspect of an endto-end,

model-driven system approach to

Mission Assurance. A UML Profile for DoDAF

and MODAF is a significant step in

that direction.

Ron Williamson, Ph.D., NCS Architect

1. For more information regarding OOSE, see the

Raytheon Technology Networks Seminar, TNS976, entitled

“Using Reference Architecture in Raytheon’s Corporate

Architecture Practice” by Dr. Mike Borky and the System

Engineering Technology Network's SEOO TIG (Technology

Interest Group).


Robert C. Rassa is director of

system supportability for

Raytheon Space and Airborne

Systems (SAS) in El Segundo,

Calif. Bob is responsible for

making SAS products more

supportable. Because he serves

as Raytheon’s primary generic

(non-program) interface with our customers in

the systems engineering/programs environment,

Bob is able to do this by influencing systems

engineering content and process at the senior

levels of Office of the Secretary of Defense and

the armed services.

Bob founded and still chairs the National

Defense Industrial Association’s Systems

Engineering Division, where he leads a team of

several hundred senior industry leaders. The goal

is to positively influence Department of Defense

(DoD) programs so that they include more systems

engineering content. As such, Bob invented

an integrated, satellite-facilitated electronics/

avionics maintenance system that, for the most

part, is used on all new DoD weapon systems.

The system incorporates interactive electronic

tech manuals, real-time diagnostics information

and asset tracking.

To provide process best practices in systems

engineering, Bob helped develop the Capability

Maturity Model Integration (CMMI®) product

suite. He is also the industry sponsor of the

CMMI Project and serves as chair of the CMMI

Steering Group that manages CMMI and its

steward, the Software Engineering Institute.

CMMI integrates systems engineering, software

engineering and hardware design engineering

processes with program management and

supply chain process.

To further the exploration and implementation

of good systems engineering practices and

methodologies, Bob recently founded the new

Institute of Electrical and Electronics Engineers

(IEEE) Systems Council to bring the might of

that organization to bear on addressing systems

engineering issues. An IEEE fellow, Bob is also

the executive vice president of the IEEE

Aerospace and Electronic Systems Society and

past president of the Instrumentation and

Measurement Society, both of which focus

heavily on military and defense systems.

To keep up on communications between industry

and our DoD counterparts, Bob founded and

chairs several major National Defense Industrial

Association (NDIA) annual conferences, including

the Systems Engineering Conference, the

CMMI Technology Conference and User Group,

and the Net-Centric Operations Conference.

Finally, Bob served as principal author and coordinator

of the NDIA’s formal report on the “Top 5

Systems Engineering Issues” in early 2003 that led

to the recent DoD policies requiring systems engineering

plans and content on defense programs.

CMMI is registered in the U.S. Patent and

Trademark Office by Carnegie Mellon University.



Applying Mission Assurance Attributes to Net-Centric Architectures

Net-Centricity is a foundation of

the Global Information Grid

(GIG), an important architectural

concept that enables information

availability and service sharing among

various customer user communities —

and one that critically impacts

Mission Assurance.

Clearly communicating the concept of

the GIG and explaining how net-centric

architectures (NCAs) provide Mission

Assurance (MA) has historically been a

struggle and is frequently the subject of

much confusion and debate. Eliciting concrete

definitions of these concepts, along

with examples to provide better understanding,

is highly desirable. Even more

desirable would be the development of a

process that demonstrates their meaning

and value for the entire Raytheon engineering

community developing NCAs.

Accordingly, at Raytheon’s 2005

SETN/SWTN (Systems Engineering/Software

Engineering Technology Network)

Workshop held this past September, the

NCA Technology Interest Group (TIG) and

the Architecture Process TIG jointly recommended

a special TIG project. This project

would identify and assess the quality attributes

and particular architectural features of

NCAs that improve both the development

efficiency and quality of those architectures

that must support MA. The project would

first develop a simple process framework

to aid in the desired assessment. The

Raytheon Technology Networks approved

the project in October 2005. This article

provides an overview of the project along

with accomplishments to date and a brief

description of future plans.

Project Overview

The project strategy is to select and use a

candidate, representative net-centric system

architecture to provide a useful context for

gauging its impact on MA. The project plan

then calls for the selection and use of a

methodology (e.g., the Architecture

Tradeoff and Analysis Method ® (ATAM ® )

or the Zachman Framework, among other

possibilities) to help assess and define the


selected NCA’s ability to support Mission

Assurance. In particular, the project seeks

to investigate specifically chosen quality

attributes related to MA — including availability,

modifiability, performance, security,

testability and usability — to identify, capture

and select those features such as

design patterns, heuristics and standards of

NCAs which best support MA.

Phase 0


& Prep

Phase 1



Phase 3



the ATAM


The end goals of the project are to:

develop recommended approaches for

identifying MA-related characteristics

(i.e., attributes) for NCAs;

identify MA-related architectural constructs

for incorporating those attributes

in NCAs;

describe recommendations for capturing

MA-related constructs in standard architectural

documentation artifacts (e.g.,

ATAM templates, DoDAF views); and

describe the selected methodology and

its application in developing architectures.

It should be noted that assessing the selected

architecture itself (i.e., determining the

specific architecture’s adequacy in addressing

MA attributes) is not a particular goal

of the project, but merely a means to an

end. The results of the assessment, however,

may be useful to the selected architecture’s


Project Accomplishments

The project first selected a candidate

net-centric architecture from an ongoing

Raytheon project to serve as the notional

example for the assessment. (Due to customer

proprietary reasons, the details of

the project are not disclosed here.) A


Exchange understanding about ATAM and eval process

Present the





Identify the




the QA

Utility Tree

Analyze the



Investigation (evaluation and architecture teams


& Prioritize


Analyze the



Present the


Testing (eval, arch & stakeholder teams)

Produce final report


Phase 2



variety of factors was used to select the

architecture, including its size (i.e., neither

so small that its assessment would be trivial

nor so large that it couldn’t be assessed

within the project’s cost and schedule

constraints), availability of architectural

information and access to program



the ATAM

1/2 HR - ST

Figure 1. Evolution of ATM process into ATO Lite process

Present the




Identify the Generate

Architectural the QA

Approaches Utility Tree

Investigation (evaluation and architecture teams

Brainstorm Analyze the

& Prioritize Architectural

Scenarios Approaches

Testing (eval, arch & stakeholder teams)



Present the



Next, the project determined the assessment

methodology to be used; namely, an

“abridged” version of ATAM. ATAM was

developed by the Software Engineering

Institute (SEI) as an extensive, robust

architecture evaluation methodology to

determine a software architecture’s suitability

for its intended purpose. In essence,

ATAM examines the adequacy and consequences

of architectural decisions as they

relate to the program’s quality and business

goals. Note that while the SEI does not

publicize ATAM’s use for system architecture

evaluation, our team found it to be

directly applicable to the aims of our project.

Since assessing the candidate architecture

wasn’t an end goal of the project, we

identified a subset of ATAM activities that

would be sufficient for the project’s purpose.

This subset is a less formal, less

thorough, and less time- and cost-intensive

execution of ATAM. As such, we focused

squarely on Mission Assurance-related

concerns. One of the benefits of this

“abridged” version of ATAM, hereafter

referred to as “ATO (Architecture Trade Off)

Lite,” is that it can be applied as part of the

initial architecture development (i.e., in a

“forward looking” fashion, as opposed to

evaluating a generated architecture in a




offline -

2 hour


to clarify

Start with

check list

Figure 2

“backward looking” fashion). Figure 1 provides

an overview of the full ATAM process

and how we evolve it into an ATO Lite

process. We estimate that applying the ATO

Lite process requires a lot less effort than

that required for a complete ATAM assessment,

yet (importantly) we believe that it

still provides a significant portion of the

value that a complete ATAM assessment

offers. We do so by eliminating the formality

and scope of the meetings and documentation

and focusing on generating the

utility tree, quality attributes and scenarios.

Using the selected architecture’s business

drivers, the project identified ATAM Utility

Tree-derived quality attributes and their

major concerns. (In this context, the term

“concerns” refers to specific focus areas

within a quality attribute, while “business

drivers” are derived from customer-level

documents such as business goals and mission

objectives). The result is shown in the

upper-left part of Figure 2, which depicts

a snap shot of the “Modifiability” quality

attribute and identified concerns. This

example for one particular quality attribute

demonstrates the process; it is, of course,

necessarily repeated for each quality

attribute of interest.

Each quality attribute is then broken down

into concerns as applicable to the subject

mission, (Figure 2, upper right). One or more

scenarios are then developed to further

demonstrate a concern. These concerns are

eventually analyzed and assessed in detail

with the help of a template (Figure 2,

lower right).

A “scenario” is a specific, implementable

example situation that demonstrates a specific

concern. Assessment is done at the

scenario level. In software engineering

terms, a scenario is akin to a use case; in

tactical terms, it has the flavor of a tactical

situation (TACSIT).

Conclusion and Future Plans

As of this writing, the project’s remaining

tasks include: conducting the assessment

using the ATO Lite process; identifying recommended

architectural constructs (e.g.,

design patterns, heuristics and standards,

among other possibilities) to support

Mission Assurance in NCAs; and completing

the documentation of the project’s

results and presenting them at Raytheon’s

5th Annual Systems and Software

Engineering Symposium, March 28–30 at

the Marriott Tech Center in Denver, Colo.

Naturally, this special TIG project has had a

limited budget and schedule. Therefore,

with additional time and budgetary

resources, the results of the project could

certainly be refined and extended. For

example, it would be useful to apply the

project’s approach to a second candidate

architecture (perhaps one from a slightly

different problem and customer domain) to

refine and extend the set of quality attributes

and concerns and the recommended

architectural constructs.

In addition, an excellent follow-on activity

would be the actual development of the

design patterns, heuristics and standards

that the project identified as reusable

artifacts in order to make them available

for use on multiple programs. We’re also

hopeful that, as a result of this project,

other programs may use the methodology

and project results to help assess their own

architectures, thus enriching and maturing

the methodology even further.

Jon Edmondson and Edwin Lee

Co-Chairs, Net-Centric Architectures

Technology Interest Group


1. Clements, P.; Kazman, R.; & Klein, M. Evaluating

Software Architectures: Methods and Case Studies,

Boston, MA, Addison-Wesley, 2002.

2. Bass, L; Clements, P.; Kazman, R.; Software

Architecture in Practice, Boston, MA: Addison-

Wesley, 2003

3. Class Book, ATAM Evaluator Training, Carnegie

Mellon, SEI, 2005

4. DoD Architecture Framework, Version 1.0, Feb,

2004. DoD Architecture Framework Working Group

5. The Open Group Architecture Framework V.8.1,

Enterprise Edition, The Open Group

6. Class Book, Implementing and Managing

Enterprise Architecture, Barnett Data Systems and

The Zachman Institute for Framework Advancement,

April, 2004

7. A Framework for Information System

Architecture, by J. A. Zachman, IBM System Journal,

Vol. 38, No 2&3, 1999

Reference Web Links

Raytheon Net-Centric Architecture TIG: http://home.


Raytheon Architecture Process TIG: http://home.ray.


Software Engineering Institute ATAM:

The Software Engineering Institute (SEI) is a federally

funded research and development center sponsored by

the U.S. Department of Defense and operated by

Carnegie Mellon University.



Aircraft Self-Protection:

Defeating Infrared-Guided

Missiles with Lasers

Raytheon Missile Systems in Tucson, Ariz.,

is leading a multi-business team to develop

the Scorpion Aircraft Self-Protection system

for U.S. Navy and U.S. Air Force customers.

The Scorpion system is being designed to

autonomously detect the launch and threatening

flight of an infrared-guided missile

toward the aircraft and then point a modulated

laser beam into the seeker of the

threat missile, causing it to sharply veer off

course. Figure 1 illustrates one-half of the

system as it would be installed on the AH-1Z

Cobra Assault helicopter. There would be an

identical pod on the starboard wing.

Poised to Compete in the Market

The projected market for self-protection

systems in both military and commercial aircraft

is in the billions of dollars over the

next two decades. Although there are wellestablished

vendors currently in the market,

Raytheon can be highly competitive since

the Scorpion system is based on components

already in production for other uses.

For instance, the component that points the

jam laser beam at the threat missile is a

slightly modified AIM-9X sensor, and the

component that senses the incoming threat

is already flying on F-16 fighter aircraft. The

Raytheon system, because of the AIM-9X

heritage, will also be much lighter, much

less expensive and much more reliable than

the competition’s systems.

Leading-Edge Technology

Figure 1. The AH-1Z Cobra Assault helicopter with the conceptual

Scorpion Aircraft Self-Protection System


Figure 2 illustrates the various components

of an individual Scorpion pod. The function

of the two missile-warning sensors is to

detect the radiation emitted from the threat

missile and provide a pointing direction

from the aircraft to the threat. These sensors,

built by Raytheon Electronic Warfare

Systems, use two-color, mid-infrared focal

planes from Raytheon Vision Systems. Onecolor

versions of this sensor are currently in

production in Goleta, Calif.

The images produced by the missile-warning

sensors are processed in the processor

using missile-warning algorithms from the

Naval Research Laboratory. The processor is

directly evolved from the AIM-9X Electronics

unit, where several cards will be modified

and some additional processor cards will

be added.

E O / L A S E R S

Aft missile



Forward missile

warning sensor

The pointer has two major functions: (1) to

determine the validity of the threat, and (2)

to direct a laser beam (co-aligned with the

pointer line-of-sight) toward the threat missile.

The pointer is a derivative of the AIM-9X

sensor, where an additional small telescope

has been added next to the existing receive

telescope. The laser will be a two-band,

mid-infrared, passively-cooled, semiconductor

laser built for Raytheon by Aculight in

Bothel, Wash. The pod, which holds the

components and allows attachment and

interface to the aircraft, is being designed

and built by Raytheon Technical Services

Company in Indianapolis, Ind.

Demonstration Plans

The Scorpion program is currently executing

two contracts (one each for the Navy and

Air Force), with a combined value of $14

million. After product development, the

plan is to demonstrate the system in the

summer of 2006 — first in the Scorpion

laboratory and then at the Raytheon Missile

Systems outdoor laser range. Follow-on

funding is expected to demonstrate the

system on a helicopter later in 2006.

James Mills



Cryo Engine

Figure 2. The components inside the two identical wing-mounted pods



IBM Cell Processor

Paves Way for New

Multi-threaded Processors

An observation was made in 1965 by

Gordon Moore, co-founder of Intel, stating

that the number of transistors per square

inch on an integrated circuit has doubled

every year since they were invented. Moore

predicted that this trend would continue for

the foreseeable future. He was right ... to a

point. Instead of doubling every year, the

density has doubled every 18 months; this

has become the current definition of

Moore’s Law.

Now the issue that remains is how to

effectively utilize all these transistors.

Increase in Real Performance Lagging

Unfortunately, the increase in real performance

is not commensurate with each new

device generation. Data indicates that only

40 percent improvement in performance

has occurred with each doubling of transistors.

This is primarily due to the push to

improve single thread performance. Adding

architectural complexity to enhance the

instruction level parallelism (ILP) — and ultimately

overall performance — is hindering

the effectiveness of these transistors.

Complexity such as dynamic execution

(rescheduling a serial stream of instructions

in real time so they can execute in parallel),

complex branch prediction logic, out-oforder

execution (to better utilize processing

resources) and large caches are common

techniques used in many state-of-theindustry

components today.

New Breed of Processors

A new breed of processors inspired by the

IBM Cell processor is changing this trend.

The fundamental approach of the Cell

processor’s design sacrifices single threaded

performance optimizations for additional

hardware resources that perform parallel

thread computations. Optimizing for thread

level parallelism (TLP) rather than ILP represents

a significant change in architecture.

A critical examination of Cell processor

implementation — and therefore TLP optimization

— has determined that a much

more efficient use of transistors for certain

applications can be achieved.

The new Cell processor, which is a collaborative

effort among IBM, Sony and Toshiba,

has been designed primarily for the video

game market and will first appear in Sony

PlayStation 3 in spring 2006. It’s expected

to provide an order of magnitude of computing

power far beyond what is currently

achievable with today’s processors. While

optimizing for TLP works wonders for videorendering

applications, it’s also an efficient

architecture for real-time embedded sensor

processing and many of Raytheon’s system


Pursuing System Performance


Multiple teams across Raytheon conducted

a critical and detailed examination of the

Cell processor during 2005. They determined

that significant system performance

improvements can be realized. For example,

radar modes that were once only dreamed

of by system analyst and waveform designers

can now be implemented in an embedded

real-time airborne application.

The Cell processor consists of nine processing

cores and support resources:

One PowerPC Processing Element (PPE)

Eight Synergistic Processing Element (SPE)

512K bytes L2 Cache



Figure 1. A cell processor silicon design and layout of the

processing resource

Element Interconnect Bus (EIB)

Shared Memory Interface Controller (MIC)

FlexIO interface

In essence, each SPE is an independent processing

core connected directly to 256 KB

of private memory. The PPE is a dual-threaded

PowerPC processor connected to the

SPEs through the extremely high bandwidth

EIB. The PPE and SPE processing elements

access system memory through the MIC,

which is connected to two independent

channels of Rambus XDR memory, providing

25 GB/s of memory bandwidth. The connection

to I/O is done through the FlexIO

interface and a Rambus-style interface.

Together they provide 35 GB/s of raw outbound

bandwidth and 25 GB/s of raw

inbound bandwidth, for a total I/O bandwidth

of 60 GB/s.

IBM has announced that the first implementation

of the Cell processor has been tested

and can operate at frequencies above 4 GHz.

At an operating frequency of 4 GHz, the Cell

processor is capable of achieving a peak

throughput rate of 256 GFlops from the

eight SPEs, not including the PPE’s contribution

from its floating point and vector units.

For more information on the Cell processor

and Raytheon’s application, please contact

Steve Kirsch (, Joel

Mellema ( or Ken

Grossman )

Steve Kirsch


Vigilant Eagle

Designed to Protect

the Flying Public

Raytheon is involved with the U.S.

Department of Defense in the development

of an airfield defense system based on highpowered

microwaves (HPMs). Recently this

concept has been refined for civilian application

so it can be made available to the

Department of Homeland Security and

other entities for further development and

application as part of a layered defense for

the civilian surface-to-air missile problem.

The Vigilant Eagle airport protection system

would illuminate the missile body with

electromagnetic energy, disrupting missile

guidance. The electromagnetic beam is precisely

steered and lasts for only a few seconds.

It would be well within OSHA standards

for personnel exposure limits and

pose no danger to civilians in the airport

and vicinity. The HPM beam would also not

interfere with the operation of aircraft or

other devices.

Three-Part System


The Vigilant Eagle concept consists of three

major components: a distributed missile

warning system (MWS), a control center

located in close proximity to air traffic control

and the HPM transmitter, which consists

of a billboard-sized array of highly-efficient

patch antennas linked to solid state cell

phone amplifiers.

The MWS is composed of a pre-positioned

grid of passive infrared sensors, with communication

lines to the control center on

airport property. These sensors are mounted

to cell phone towers or buildings in a manner

that most efficiently covers the required

detection space. And because each missile

detection is confirmed by at least two sensors

in an overlapping grid, it produces an

extremely low false alarm rate.

In addition to providing pointing commands

to the HPM transmitter, the control center

connects to the airport security interface.

Vigilant Eagle determines the launch point

of the missile and can notify security forces,

Vigilant Eagle

significantly lowers

the risk of a

successful terrorist attack

without delivering a

financial blow to the

airline industry.

enabling the capture of the terrorist. Upon

receiving pointing commands from the

control center, the HPM transmitter radiates

energy to interfere with the missiles guidance

and deflect it away from the aircraft.


Cost-Effective Solution

The Vigilant Eagle concept is a highly costeffective

addition to a layered protection

approach when combined with a limited

number of commercial and general aviation

on-board protection systems. If Vigilant

Eagle is installed at the 21 Category One

(most critical) airports as designated by the

Transportation Security Administration

(TSA), nearly 50 percent of all takeoffs and

landings within the U.S. and more than

85 percent of overseas arrivals and departures

will be covered by this technology.

When compared to on-aircraft protection,

Vigilant Eagle is six times more cost effective

to procure and 50 times more cost

effective for operations and maintenance

due to the significant logistics tail required

for on-board systems. What’s more, Vigilant

Eagle requires no aircraft modifications.

Put simply, Vigilant Eagle significantly

lowers the risk of a successful terrorist

attack without delivering a financial

blow to the airline industry.

Jeff Vollin



Aerothermal Capability

Enhancement Initiative

Aerothermal heating. Sounds impressive,

but what is it exactly? Well, it’s when missiles

fly so fast that the air is heated by skin

friction to extremely high temperatures.

Calculating these air temperatures is a fairly

straightforward process, provided you know

the static (still) air temperature, Mach number

and altitude. Even though the static air

temperature at, say, 40,000 feet is cold (-54

degrees Fahrenheit), a missile flying at Mach

5 in that environment “sees” an air temperature

of over 2,000 degrees Fahrenheit!

While this is a fairly straightforward calculation,

it’s considerably more difficult to predict

the temperature response of missile

components that are exposed to this environment

for only a few seconds.

Current analytical prediction tools are based

on flight data taken in the late 1950s and

early 1960s. In most cases, these tools have

provided exemplary predictions resulting in

robust designs that have stood the test of

time. However, competitive pressure, cost

goals and weight restrictions push us to

search for ways to improve our predictive

ability so we can provide more affordable

solutions that are better optimized for

the real conditions that our products

operate within.

In late 2004, Tom Sarama, director of the

Mechanical Engineering Center, Missile

Systems (MS), challenged us to take a closer

look at our tools and see if we could

improve them. Our expert thermal analysts

were consulted, along with our aeromechanics

counterparts, to see if there was a

possibility for improvement. We decided to

go outside of MS to find the answer.



Aerothermal Capability Enhancement team meeting – Tucson, Ariz., March 2005

The team extended an invitation to the

leading aerothermal analysts at Raytheon,

NASA, Sandia Laboratories, ITT Aerotherm,

the U.S. Army, the U.S. Navy, the U.S. Air

Force and leading universities to join in an

assessment of the current state of aerothermal

heating predictive capability. The meeting,

dubbed the “Aerothermal Capability

Enhancement Initiative,” was held in

Tucson, Ariz., in March 2005. This elite

group of aerothermal analysts gathered to

discuss the current state, identify gaps

(weaknesses) and then prioritize them into

an action plan. Most of us recognize this

standard process as our own Raytheon Six

Sigma methodology. The team held a follow-up

meeting in September at the MMTN

(Mechanical and Materials Technology

Network) Symposium in Tucson, Ariz.

Because of these meetings, we now understand

that Raytheon has tools and capabilities

equal to others in the industry — and

that there’s a significant body of work left to

be done. These events provided us with expert

input on exactly what needs to be done and

how best to proceed. The team identified

over 100 different items for improvement,

covering business case development, test

programs, code work, collaboration, mentoring

and material characterization.

As of February 2006, a white paper

proposal is being written to secure government,

Raytheon and academic support.

We plan to vigorously solicit support and

execute our plan to sharpen the tools

we need to provide more competitive

affordable solutions.

Bill Zwick

Raytheon Six Sigma is a trademark of Raytheon




Capability Maturity Model Integration (CMMI)


CMMI ® V1.2

Model Update

Since its announcement in technology

today, 2005 Issue 3, CMMI Version

1.2, planned for release in the summer

of 2006, has undergone some significant

updates. At the time the update was

announced, the Supplier Agreement

Management (SAM) and Integrated Supplier

Management (ISM) process areas were

going to be moved to a Supplier Sourcing

part of the model. Since then, the two

process areas have been combined into

SAM. This process area will be a part of the

core model, with the overlap between the

two process areas being eliminated with

this latest approach. The changes resulted

in two specific practices being moved from

ISM to SAM. The SAM process area will

remain at maturity level 2, raising the bar

to a degree.

The Integrated Project and Process

Development (IPPD) approach has also

changed. The previous technology today

article stated that a new process area called

Work Environment would be added.

Instead, a new specific practice (SP) has

been added to Organizational Process

Development (OPD) and to Integrated

Project Management (IPM) that addresses

the work environment. The OPD SP addresses

establishing guidelines and standards for

the work environment that will be used at

the project level in IPM. In addition to these

changes to the core model, a new goal has

been added to OPD for the +IPPD model.

The two IPPD goals in IPM have been collapsed

into a single goal for +IPPD. Key

practices from Organizational Environment

for Integration have been moved into these


CMMI IPPD process area changes

Version 1.1 Version 1.2











+IPPD Goals. Overall, the +IPPD part of the

model has improved significantly. A recent

pilot of these new materials was performed

in a Class A SCAMPI within Network

Centric Systems in Texas with very encouraging


There are still other changes being worked

such as the naming of the model; at this

time, a final resolution has not been determined.

The Services team has identified

informative material changes to the process









areas to enable better use of the model by

service organizations. Watch for future

updates in technology today or contact

your CMMI expert team member.

For more information contact

Aaron Clouse (,

John Evers ( or

Gary Wolf (

CMMI is registered in the U.S. Patent and Trademark Office

by Carnegie Mellon University.


Design for Six Sigma: A Tool for Mission Assurance

at a System Level

When you mention

Design for Six Sigma (DFSS), you

think of tangible ideas — reduction

in parts count, elimination

of process steps and focus on

reliability of critical components.

These are important focus areas

at Raytheon that help us provide

our customers with better solutions

at lower cost, not only in

initial expenditure but also in

maintenance cost and downtime.

But this is not the only

application for DFSS.

At a system level, consider DFSS as designing

for Mission Assurance; employing

Raytheon Six Sigma TM techniques to ensure

that the system behaves as the customer

expects, and does not exhibit behaviors

that impede mission success. In pursuing

Raytheon’s Mission Assurance goal, we can

apply DFSS principles to a number of less

concrete facets of the system, including

abstract pre-implementation representations

of the system and the processes that

we use to create them. By employing DFSS

before physical design, we can leverage its

power to contain defects and enhance system

performance with a much smaller

investment of time and money. The projects

listed below exemplify the application of

these types of DFSS techniques. These projects

have been completed and documented

while others are currently underway.

National Test Bed Reachback


In the National Test Bed Reachback Project,

Dale O. Brandt, Wayne O’Brien and Tim

Trapp of Intelligence and Information

Systems in Falls Church, Virginia and John

P. Kantelis of Integrated Defense Systems

used DFSS techniques, under the sponsorship

of Robert Keener, to enhance the

process for defining assertions describing

the behavior of an Advanced Battle

Management System. A more accurate and

complete set of assertions supports robust

architecture, enhances the ability to monitor

and correct behavior in safety-critical

systems and enables the development

of more thorough test scenarios for

the system.

Key Characteristics:

Identification, Implementation

and Maintenance Project

In this project, Tony Strickland, Debra

Herrera and Debra Childs of Raytheon

Missile Systems addressed the challenge of

focusing on those aspects of a system that

contribute most to mission success. This

project defines a process for describing

those characteristics of a system —

attributes, features or specifications —

that impact safety and compliance, or

critical performance. The project also

defines a method of identifying key

performance characteristics in system

documentation and controlling them

around nominal value to improve system

performance and reliability.

Closed-Loop Risk and

Opportunity Process Project

Nathan Schwendeman and his team from

Space and Airborne Systems proposed

refinements in processes, metrics and tools

to enhance an organization’s capability to

evaluate program progress based on technical

performance, cost and schedule.

Using input on cost, schedule and performance

risks or opportunities, this project

developed a common approach for programs

to make data-driven decisions that

are closed-loop to the program using DFSS

and other best practice techniques. This

allows the program to evaluate success

and offers an opportunity to better serve

customer needs in an efficient and profitable


These projects represent just a few examples

of how DFSS processes and methods

can be applied to the development of systems.

All of our up-front processes, tools

and artifacts offer opportunities for applying

DFSS. Our challenge going forward is to

find and exploit high-leverage opportunities

to use DFSS tools in systems and software

challenges as well as in more traditional


Larri Ann Rosser

Raytheon Six Sigma is a trademark of Raytheon

Company. R6s is a Raytheon Company trademark

registered in the United States and Europe.



Developing the IPDS v3.0: An enterprise approach

Hopefully you’ve had a chance to look

at the new Integrated Product Development

System (IPDS) v3.0. If not, please visit and let

us know your thoughts — especially on

stages 2–5. The intent of this article,

though, is not to describe the

new IPDS, but instead to describe

the process taken in developing

what you see on the Web. It’s the

result of many people in a variety

of business disciplines across

Raytheon coming together to

accomplish a common goal.

Following the reorganization of six

major businesses back in 2002,

there was a push for organizations

to achieve a Capability Maturity

Model Integrated (CMMI ® ) Staged

Level 3 rating. As IPDS was not

fully compliant at the time, businesses

chose to establish local

processes to complete the gaps,

while recognizing the complexity and navigation

difficulties in using IPDS. What’s

more, the discipline council structure and

membership no longer represented the

businesses as well. Put simply, changes were

needed to get IPDS back on track.

The Raytheon Engineering Common

Program (RECP) is the designated agent to

implement policy to maintain and improve

the IPDS. The RECP organization recognized

that this change was needed and initiated

the formation of the Requirements and

Architecture (R&A) team in 2002, followed

by the IPDS Steering Committee in 2004.

Both of these groups are composed of two

representatives from each business in order

to directly engage the businesses in the

improvements to IPDS.

In short order, the R&A team established a

set of requirements and performed a


System Requirements Review, which led to

the development of the new v3.x architecture.

The Steering Committee, meanwhile,

developed and committed to a new vision

for IPDS that complimented the company’s

vision and goals.

“IPDS is the Raytheon

enterprise system that

defines the standard

organization processes

used by all businesses

to ensure program


Once the goals and requirements were in

place, the R&A team set out to establish the

new architecture of IPDS, resulting in a new

output-focused process structure, three new

groups and a revised council structure

(Figure 1). The three new groups were the

Automation team, Process Asset Library

(PAL) team and the Enterprise Process

Group (EPG).

The Automation team is responsible for the

development of a new Web-friendly database

and automation of the development

and planning (formerly tailoring) processes.

RECP internally organized to bring both the

IPDS and CMMI teams together under the

Process heading, resulting in the new EPG

and improving IPDS into a CMMI-capable

system. The PAL team established a new

asset library, with both an IPDS context and

a business context for assets. The newly

established council structure now contains

membership from the businesses at the discipline

level. As we move forward to the

next release of IPDS, these discipline councils

will integrate the existing stand-alone

processes into the main process, completing

a fully integrated system at the

IPDP level. This system, together

with the dynamic views and other

features developed by the automation

team, will provide the user

customizable displays, ease of navigation

and direct access to

enablers in the users’ context.

As the new architecture is outputfocused

and streamlined to define

the “essential whats,” much of the

IPDS v2.4.0 content will not be in

the task descriptions. Rather than

lose any valid information, the

v2.4.0 content on how to execute

the task will be captured and

made available as reference assets

in the PAL. By mapping the prior

task structure into the new architecture,

we not only retain the history of

where tasks ended up but still provide

access to the enabling information. The

output focus was accomplished by distilling

the v2.4.0 content down into tangible work

products and generating detailed inputprocess-output

(IPO) diagrams for each task.

The IPO diagrams delineate the specific

inputs required to produce the required

output, thus lending itself to the generation

of a task-dependent integrated master

schedule (IMS) as part of the planning

process. The IPO diagrams will be available

(in the near future) to users at the task level

and in bundled native Visio format from the

deployment Web page within the IPDS


CMMI is registered in the U.S. Patent and Trademark Office

by Carnegie Mellon University.

Figure 1







Raytheon Engineering Common Program (RECP))

grow outside the traditional




C ommittee


Guidance Requirements



( R&A)

Provides Requirements

Provides Requirements






( PAL)






project-centric environment

to include


recognized functions

and integrate them





into IPDS as well.


Interprets CMMI

The IPDS Steering




Committee has now







( SE)



( CM)



( ME)


( QA)


( SW)



( TE)




( EPG)



( ARM,









added Program



Technology and

Business Development

to its committee and

Functional Organizations

Integrated Product Development System (IPDS) plans to add Supply

Program Business Supply Chain Information


Chain Management,

Mgmt Dev Mgmt Technology


Human Resources,









Finance, Security and

Export/Import in the


near future (Figure 1).

By inviting the participation

of these

groups, we can now

The next step (in process) is to integrate the One reason why representatives from

expand the scope of IPDS to better achieve

various discipline processes into the IPDP. across Raytheon’s numerous sites were able

the Mission Systems Integrator role and

This is done by first mapping the v2.4.0 dis- to work together so successfully was

support Customer Focused Marketing,

cipline sub-processes into the new IPDP because of the collaboration tools obtained

while moving us closer to a single integrat-

architecture, and identifying the “essential or developed under the RECP funds. Much

ed process for the company. With a truly

whats” and the tangible work products. of this work has been done on a part-time

integrated and common process, Raytheon

From this, the IPO diagrams are generated basis by the business representatives, who

can achieve process robustness for now

to facilitate the capture at the IPDP level. have numerous other responsibilities and

and the future, consistent with a high-

The discipline teams’ memberships now only a very few full-time resources. While

maturity (such as CMMI Level 5) continuous

include representation from the businesses this situation has complicated the develop-

improvement environment, as each busi-

and span numerous sites and locations ment work, the teams have been producness

internally develops new and innovative

within the company. As a result of this partive through the use of teleconferencing,

ideas to bring forward.

ticipation, there will be alignment between Lotus Notes, Sametime, eROOM and other

the IPDS and local processes, enabling collaboration tools.

Raytheon businesses to transition to this

common IPDS architecture beginning this

year. The exact timing for completing the

Per our roadmap for evolving IPDS to be an

enterprise process, the RECP Process team

Steve Clark

John Evers

transitions varies among the businesses is actively working to shape the new IPDS

based on local CMMI appraisal schedules. so that it is consistent with the company’s

Contact your local process group for more. vision. RECP has recognized the need to



Systems Engineering Technical Development Program (SEtdp)

Graduates First Wave of Students

In mid-2003, Raytheon engineering

and learning leaders from Space

and Airborne Systems (SAS), Missile

Systems (MS), Integrated Defense Systems

(IDS), Intelligence and Information Systems

(IIS), Network Centric Systems (NCS) and

Raytheon corporate came together to

address an impending need for systems

engineers. This need was caused by the

retirement of key members of Raytheon’s

systems engineering population along

with the increased demand for technical

leaders for the Mission Systems Integration

(MSI) and system-of-systems programs of

the future.

Leveraging work done within the businesses

and by the Systems Engineering Council,

they used Raytheon Six Sigma TM techniques

to define the problem and identify a goal:

develop 1,000 new MSI and system-ofsystems

chief engineer candidates by 2010.

A cross-business team of key engineering

and learning professionals worked together

to design a learning approach that exposes

students to important customers, technologies,

domains and competencies — consequently,

the Systems Engineering Technical

Development Program (SEtdp) was born.

The very act of collaborating to address this

enterprise need has added value to the

businesses. Jerry Brown, vice president of

engineering for Raytheon’s Missile Systems

business, reports, “The SEtdp program has

helped MS to create a focus on the importance

of systems engineering to our future

growth and a broader perspective on the

capabilities of the entire company. With

each business creating and teaching part of

the program, our top engineers have the

opportunity to visit other sites, develop

relationships and see the best of what

Raytheon has to offer.”

The SEtdp is structured to allow students to

exercise technical and leadership skills

while developing a broad understanding of


Raytheon’s customers and company strategy.

It also facilitates the development of

networks of knowledge and encourages

One Company behavior.

In June of 2004, the first wave of SEtdp

students was selected for the program by

their business leadership team. Since then,

the first wave of students has learned with

our best and brightest engineers and technologists

at the IDS business in Mass., MS

at Tucson Ariz., IIS in Garland Texas, NCS in

McKinney Texas, as well as from one

another on cross-business project teams

addressing current Raytheon challenges

and needs.

At each session, the students have participated

in interactive learning activities

focusing on key technologies and domains

at the host businesses. They have heard the

voice of a range of Raytheon customers

and business leaders, and have worked

with both best-in-class and emerging

methods in systems engineering. There are

currently nine waves of SEtdp in progress.

Starting in 2006, eight new waves will be

launched each year. This year, approximately

190 students will graduate from the

program, and approximately 225 in each

year thereafter.

In March 2006, first-wave students will

attend their final session in Washington

D.C., where they will work with our

business development organization and

Raytheon Technical Services Company to

present the results of their class projects to

a jury of Raytheon engineering leaders.

Lynn Dugle, vice president of Engineering,

Technology and Quality for NCS, heralds

this event: “We have chartered new

ground. Wave 1 of the SEtdp are the

pioneers for a program that accelerates

growing our future lead systems and chief

engineers. The projects that they are working

on will benefit Raytheon and NCS for

years to come.”

The program has been challenging for the

students, both personally and professionally,

but their effort shows results.

Students report gaining valuable insight in

areas to which I have never been exposed

and a good understanding of other business

areas and insight to how we can work

together as One Company to deliver customer

solutions. In fact, just three days

after returning home from his first session,

one student writes, “focusing on the

‘need’ helped in a meeting with the Navy

yesterday. I told them to focus on the

‘need,’ not the implementation — [that alone]

may have been worth the tuition.”

Larri Rosser

Ambrose Nangeroni




Raytheon is proud of its technology and the

innovative people who continue setting

new benchmarks. Congratulations to the

2005 Excellence in Technology award winners

for their outstanding technical contributions

to the company and society. Look

for full coverage of the April celebration

event in the next issue of technology today.

Information Technology

Raytheon Multi-program TestBed SGI

Support Team

Adam C. Feccia

Brad M. Haig

Integrated Defense Systems

Achievement in the development of

Raytheon radar and communication

AESA apertures

Michael G. Sarcione

SBX Radome Development Team

Sharon A. Elsworth

Marvin I. Fredberg

Peter H. Sheahan

Collins RCS & Air Warfare Destroyer

“Reach Back” Team

Terry L. Babcock

Charles Bertelsmeier

Jerry M. Bradshaw

Sean T. Lynch

David Hewish

Intelligence and Information Systems

VOIP: Redwolf Packet Data

Exploitation Team

Mohamed Benalayat

Michael J. Campbell

Richard L. Greenwood

John C. Sessler

Art J. Stefanelli, Jr.

High Performance Storage; Storage

Architecture Team

Van A. Boyd

Jeffrey M. Dunn

Michael W. Smith

Missile Systems

Active Denial System ACTD Team

John W. Gerstenberg

Gil F. Lee

Arlin L. Pierce

Dave R. Sar

Jerry D. Withrow


Development Team

Vinh N. Adams

Wesley H. Dwelly

Rick E. Hindman

Johann Schleiss

Ben Steiger

Achievement in the design of the critical

Standard Missile-3 Block 1 software

algorithm for particle mitigation

Bob J. Shelton

Network Centric Systems

Persistent Surveillance and

Dissemination System-of-Systems Team

Hyong E. Bang

Don A. Ewen

Bob E. Gerard

Phil J. Osip

Lowell W. Wheeler

Achievement in the innovative

development of a software code

generation framework

Alex E. Joseph

Above 2GHz Common Modem

Architecture Team

Michael Heath

David L. Hendry

Clark B. Hockenbury

Mike Kerrigan

Fatemeh Tingley

P-154 Development Team

Clay Carson (NCS)

Doug K. Darlington (NCS)

Gary A. Frazier (SAS)

Todd R. Gattuso (IDS)

Bob C. Gibbons (SAS)

Lindley T. Specht (IDS)

Raytheon Aircraft Company

Composite Paint Matrix Process Team

John D. Galbraith

Larry W. Keefer

Ken W. Minks

Steve L. Roach

Raytheon Systems Limited

Digital GPS Antenna System Team

Steve Clark

Pete Antony McIlroy

Precision Guided Bomb

Warhead IPT Team

Graham Viner (RSL)

Craig L. Wittman (MS)

Raytheon Technical Services Company

Weapons Information System

and Data Management Team

Jack E. Adie

Mark J. Blazejewski

Brenda K. Boorda

David L. White

Joy J. Wycliffe

Space and Airborne Systems

New System Mode Algorithm Team

Johnny M. Bartlett

Brian K. Erickson

Mike McCann

Steve Ruder

Gene Scaife

Small Lightweight Advanced

Modular – Digital Electronic

Protect Development Team

Ryan G. Conolley

Jaime Fitz-Gerald, Jr.

Sandy A. McOwen

Ryan N. Strader

Jack E. White

Multi-Function Radio Frequency

System Antenna Electronics Unit

Demo Team

Mike J. Broome

Jim M. Elliott

Ron J. Hart

Rich P. Heon

Ron Richardson


MathMovesU: The Whole Equation

Raytheon’s national initiative to improve

young students’ perceptions about math

and science has met with rave reviews from

national media, educational organizations

and institutions, and especially Raytheon


Your enthusiasm for MathMovesU and

insightful feedback is driving the program’s

momentum and growth throughout the

country. In addition, your support is

helping fuel a movement for change across

America — a change now recognized in

the highest levels of our government as a

crucial initiative for improvement and a

critical factor in our country’s future performance

in the global marketplace.

Reaching Students Across the Country

Our MathMovesU website (

is designed as an interactive

community and forum for math fans of all

ages. Here you’ll find lots of information,

tools, activities, opportunities and resources

to spur interest, including:

Scholarship and grant applications for

students and Math Heroes

Games and activities

Problem solving for great prizes

Parent/teacher resources

Connection to MATHCOUNTS® volunteer


You may have also heard about

MathMovesU events in and around your

community featuring kid-inspiring celebrities,

pro athletes and other “cool” professionals

such as celebrity skateboarder Tony

Hawk, soccer star Mia Hamm and the

WBA’s Lisa Leslie. These celebrity sponsors

are endorsing MathMovesU through the

website, donating autographed prizes, and

sharing how math makes a difference in

their career. High-profile government officials,

pro athletes and celebrities will also

make guest teacher appearances in major

metropolitan areas on behalf of MathMovesU.

MathMovesU has reached out to national

organizations with expertise in implementing

educational initiatives and programs,

like MATHCOUNTS, a national math enrichment,

coaching and competition program

that promotes middle school mathematics

achievement through grassroots involvement

in every U.S. state and territory.

MATHCOUNTS is one of the most successful

education partnerships involving volunteers,

educators, industry sponsors and

students. The organization will coordinate

MathMovesU participation in upcoming

MATHCOUNTS local, state and national

math competitions.

During the year, MathMovesU will award

scholarships and grants to kids and adults

across the nation to encourage active

“We need to encourage children

to take more math and science,

and to make sure those courses

are rigorous enough to compete

with other nations … Tonight I

propose to … give early help to

students who struggle with

math, so they have a better

chance at good, high-wage jobs.

If we ensure that America’s

children succeed in life, they

will ensure that America

succeeds in the world.”

President George W. Bush,

State of the Union Address, Jan. 31, 2006

participation and enthusiasm for math.

Nomination information and applications

are available online for middle school, high

school and college students and math

heroes (teachers, advocates and volunteers).

The Sum of Our Efforts

With the committed support of Raytheon

leadership, MathMovesU has already made

an impact in the national media, on the

web and in our workplace. Soon you’ll see

MathMovesU in the classrooms, making

progress in our communities and, with your

help, changing minds all over the country.

Check out How You Can Help at and see where you

can make a difference just by spreading the

word, taking initiative, working proactively

and sending us your stories.

We’re not all math whizzes. But we can all

be math heroes. Go figure.

What you can do:

Send friends, family, students, parents, teachers

and math fans of all ages to

to win great prizes like iPods and autographed

merchandise, apply for grants and scholarships,

volunteer at local events, check out resources for

teachers, parents and kids, and learn how math

figures into all kinds of career choices.

Spread the word about MathMovesU through

your community, social networks, school system

and work. Chances are you know an organization,

club, teacher, student or other individual

that would appreciate knowing about

MathMovesU opportunities.

Involve others at work, in the community or

through professional organizations. The

MathMovesU intranet website has posters,

flyers, materials, ideas and information to

generate interest and action.

Volunteer to promote MathMovesU at businesssponsored

events, community forums and

schools as a math club coordinator, coach, mentor

or tutor. Get in touch with your local Community

Relations representative for more information.

Start your own MathMovesU club, event, activity,

or online community. Use MathMovesU

materials available on the company’s intranet

site to support your ideas, and present to others

at planning sessions, club meetings, etc.

Share your MathMovesU success story so other

Raytheon employees can hear your ideas, efforts

and success. Email it to:

MATHCOUNTS is a registered trademark of

the MATHCOUNTS Foundation.


U.S. Patents

Issued to Raytheon

At Raytheon, we encourage people

to work on technological challenges

that keep America strong and develop

innovative commercial products. Part

of that process is identifying and

protecting our intellectual property.

Once again, the United States Patent

Office has recognized our engineers

and technologists for their

contributions in their fields of interest.

We compliment our inventors who

were awarded patents from December

2005 through February 2006.


6972400 Multi-mode vibration sensor laser



6972950 Method and apparatus for cooling a

portable computer (laptop thermal solution)





6973865 Dynamic pointing accuracy evaluation

system and method used with a gun that fires a

projectile under control of an automated fire

control system



6973878 Warhead with aligned projectiles



6974386 Motor drive system with wire-wound

flexible coupling


6974517 Lid with window hermetically sealed to

frame, and a method of making it (AMD: low cost DLP

hermetic lid using low temperature sealing glasses)


6975204 Method and apparatus for preventing

unauthorized use of equipment (remote detection and

disabling of military equipment in unauthorized use)


6975276 System and low-loss millimeter-wave

cavity-backed antennas with dielectric and air cavities


6975682 Multi-bit delta-sigma analog-to-digital

converter with error shaping



6977601 Low power current input delta-sigma ADC

using injection fet reference







6977609 Technique for changing a range gate and

radar coverage (automotive)




6977610 Multiple radar combining for increased

range, radar sensitivity and angle accuracy


6977973 System and method for decoding

manchester data (manchester decoder)




6979119 Sensor system and method for sensing in an

elevated-temperature environment, with protection

against external heating





6979606 Use of silicon block process step to

camouflage a false transistor



6980614 System and method for subband

beamforming using adaptive weight normalization






6982678 Apparatus and method using wavefront

phase measurements to determine goemetrical




6984745 Environmentally benign lead zirconate

titanate ceramic precursor materials


6987473 Digital signal-rate converter and systems

incorporating same



6987479 Conformal Range Migration Algorithm

(CRMA) “karma”





6988338 Lid with a thermally protected window

(low cost optical glass window design for DLP-DMD)


6989537 Compact inverse-telephoto infrared imaging

optical system


6989799 Antenna assembly including a dual flow

rotating union




6989991 Thermal management system and method

for electronic equipment mounted on coldplates

(thermal enhancements for liquid flow through plastic







6990087 Dynamic wireless resource utilization (softstate

adaptive technique for dynamic wireless resource



6991367 Integrated thermal sensor for microwave



6992275 Night vision apparatus




6992629 Embedded RF vertical interconnect for

flexible conformal antenna




6992818 Self-adjusting interferometric outcoupler

and method



6992830 Projection display having an angle-selective

coating for enhanced image contrast, and method for

enhancing image contrast


6993315 Super-regenerative microwave detector


6995709 Compact stacked quarter-wave circularly

polarized SDS patch antenna








6995730 Antenna configurations for reduced radar

comlpexity (automotive)



6996137 Solid-state devices with radial dopant

valence profile



6997564 Digital projection display



6998613 Integrated spectroscopic microbolometer

with microfilter arrays









6999040 Transverse device array phase shifter

circuit techniques and antennas


6999243 Fixed focus, optically athermalized,

diffractive infrared zoom objective lens


7000691 Method and apparatus for cooling

with coolant at a subambient pressure (subambient

cooling system for phased array systems)



7002139 Window mounting for optical sensor




7002154 Optical system for a wide field of

view staring infrared sensor having improved

optical symmetry



7002441 Micro-electro-mechanical switch, and

methods of making and using it




7002510 Method and apparatus for air-to-air

aircraft ranging



7002810 System and method for housing electronic

equipment in a rack




7006031 Interrupt sar image restoration using

linear prediction and range migration

algorithm (RMA) processing




7006034 Fast and slow time scale clutter


International Patents Issued

to Raytheon

Congratulations to Raytheon technologists

from all over the world. We would

like to acknowledge international

patents issued from December 2005

through February 2006. These inventors

are responsible for keeping the company

on the cutting edge, and we salute their

innovation and contributions.

Titles are those on the U.S. patents;

actual titles on foreign counterparts

are sometimes modified and not

recorded. While we strive to list current

international patents, many foreign

patents issue much later than the

corresponding U.S. patents and may

not be reflected yet.




2001288354 Folded cavity-backed slot antenna







2003286659 Advanced digital antenna module




2003295565 Highly adaptable heterogeneous

power amplifier IC micro-systems using flip chip

and microelectromechanical technologies on low

loss substrates




1405119 Fixed focus, optically athermalized,

diffractive infrared zoom objective lens





1260095 Multiplex bucket brigade circuit



1208402 Semi-active focus and thermal

compensation of a centrally-obscured

reflective telescope




1305841 Transparent metallic millimeter-wave




1379892 Solid state modulated beacon

tracking system








121718 Vehicle having a ceramic radome affixed

thereto by a compliant metallic transition element



147193 Shaping optic for diode light sheets






3754091 Microwave antenna having wide angle



Future Events

18th Annual Systems and

Software Technology


Transforming: Business, Security,



May 1–4, 2006

Salt Palace Convention Center

Salt Lake City, Utah

In its 18th year, the Systems and

Software Technology Conference (SSTC)

is the premier joint services systems and

software technology conference in the

Department of Defense (DoD) and co-sponsored

by the U.S. Army, U.S. Marine Corps,

U.S. Navy, Department of the Navy, U.S. Air

Force, Defense Information Systems Agency

(DISA) and Utah State University Extension.

SSTC continues to provide this premier

forum in the DoD to enhance attendees’

professional skills and knowledge of systems

and software technologies and policies,

enabling them to improve the capabilities

they provide to the warfighter.

For more information visit

* * *

Raytheon’s 8th Annual Electro-

Optical Systems Symposium

EO Technology: Addressing

Emerging Threats


May 2–4 2006

Fess Parker Doubletree Resort

Santa Barbara, California

The eighth Annual Raytheon Electro-Optical

System Technology Network (EOSTN)

Symposium is devoted to fostering

increased teaming and technical collaboration

on projects associated with current

developments, capabilities, and future directions

of EO systems and technology.

Government representatives from the DoD,

Army, Navy, Air Force, and MDA will be giving

keynote addresses providing a focus for

the subsequent papers. Opportunities to

speak with customers, Raytheon scientists,

engineers and leaders will be provided

throughout the course of the symposium.

For more information or to register,

visit the Electro-Optics Systems

symposium Website at


* * *

Raytheon’s 7th Annual RF


Expanding the Spectrum of

Systems Solutions


May 15–18, 2006

Intercontinental Hotel

Dallas, Texas

Raytheon announces the eighth annual RF

Symposium devoted to the exchange of

information on RF/microwave, millimeter

wave and associated technology. Sponsored

by the Raytheon RF Systems Technology

Network (RFSTN) and the Analog, RF, MW

Engineering Council (ARMEC), this

companywide symposium provides the

RF/microwave technical communities, business

segments and HRL with a forum to

exchange information on existing capabilities,

emerging developments and future

directions. The symposium fosters the

sharing of Raytheon’s collective expertise

in RF technology and communication

between its technical leaders.

For more information, visit


Do you have a great idea for an article?

We are always looking for ways to connect with you — our engineering, technology, manufacturing

and quality professionals. If you have an article or an idea for an article regarding technical

achievements, customer solutions, relationships, Mission Assurance, etc., send it along. If

your topic aligns with a future issue of technology today or is appropriate for an online article,

we will be happy to consider it and will contact you for more information. Send your article

ideas or suggestions to We want to hear from you!

Raytheon’s Mission

Assurance Forum

Sponsored by the Operations

and Quality Councils

Mission Assurance Mission



June 28–30, 2006

Washington D.C.

Operations, Quality, Environmental Health

and Safety, Raytheon Six Sigma, Supply

Chain, Engineering, IT and all Mission

Assurance professionals are invited to

submit presentations in five tracks: MAP

Made Simple, Delivering on Expectations,

Tools and Training, Supplier Quality and

Managing Risk.

For details or to submit an abstract

online, please visit

* * *

16th Annual INCOSE

(International Council of

Systems Engineering)

International Symposium

Systems Engineering: Shining

Light on the Tough Issues


July 9–13, 2006

Orlando, Florida

Come to Florida and learn how the theme

“Systems Engineering: Shining Light on the

Tough Issues” applies to the broad scope of

systems engineering and how systems engineering

activities in commercial, academic,

and government environments are converging

on new best practices and novel technologies

and methodologies. Many fine

papers, panels and tutorials covering case

studies, developmental work and technical

analysis have been received, reviewed and

scored; and the technical program is being

set. Arrangements are being made for

keynote speakers and special events that

will be both entertaining and fascinating.

For information or to register, please



Copyright © 2006 Raytheon Company. All rights reserved.

More magazines by this user
Similar magazines