TT_Vol3 Issue2 - Raytheon

technology
today
HIGHLIGHTING RAYTHEON’S TECHNOLOGY
RAYTHEON SYSTEMS AND SOFTWARE TECHNOLOGY
In Support of Mission Systems Integration
Volume 3 Issue 2

A Message from Greg Shelton
Vice President of Engineering,
Technology, Manufacturing & Quality
or
Ask Greg on line
at: http://www.ray.com/rayeng/
2
As we move to becoming an integrator of mission solutions, our capabilities in systems and software
engineering are critical to our success, so we have dedicated this month’s issue to systems
and software technology. I challenge you to think about who our systems engineers are. The
answer is simple — all of us, from the lead system architects and the Integrated Product Team
leads, to the quality and manufacturing engineers and the component and material engineers. As
Ron Carston, a long-time technology leader and friend, states in his profile: “We must all think
like system engineers, no matter what assignments we have. If you don’t understand how your
design affects everyone else’s, or how the overall system functions, you can’t do your job well.”
Think it, act it, be active. I challenge all of you to look for ways to maximize the entire system —
go beyond your immediate role and responsibility.
I encourage you to read the profiles of the Raytheon Fellows featured in this issue. Read about
their professional and life experiences; call on them for advice and mentorship. In each profile,
there is a central focus: the challenge to look outside the box, take on additional challenges —
personally and professionally — and build solid relationships with your customers through
listening, responding and following through. Growing, changing and learning. Our knowledge is
based in our people. You are Raytheon’s greatest asset, and together we need to continue to build
a culture of continuous learning and professional growth.
As I write this, I am en route to the 2003 Excellence in Technology celebration. This year we will
honor 66 recipients — 8 individuals and 13 teams from across the company — at the National
Air and Space Museum’s Steven Udvar-Hazy Center, at which Raytheon has sponsored an exhibit
on air-traffic control in the Engen Tower. I can not think of a better venue — this site that celebrates
technology achievement and excellence of our past, present and future, including Raytheon
products such as the AMRAAM air-to-air missile. We are a technology company. Technology is in
our roots. Join me in congratulating the 2003 Excellence in Technology award recipients for their
continued pursuit of technical excellence, curiosity and passion for success.
Also core to our success as a company is our ability to perform while we provide technology solutions
to our customers. This ability to perform predictably is demonstrated by our recent successes
in Capability Maturity Model Integration® (CMMI). We achieved CMMI Level 5 and Level 3
appraisals in California, Massachusetts, Rhode Island and Texas in 2003, and we are continuing
on our journey for process excellence in 2004 and beyond. Also key to performance excellence is
incorporating Raytheon Six Sigma TM into our designs through Design for Six Sigma and use of the
Integrated Product Development System.
Performance, Relationships and Solutions — the three pillars of customer focus — it is part of
everything we do.
Enjoy the magazine, and share it with your peers and customers. As always, I welcome feedback
and ideas — we just keep getting better!
Sincerely,
Greg

TECHNOLOGY TODAY
technology today is published
quarterly by the Office of Engineering,
Technology, Manufacturing & Quality
Vice President Greg Shelton
Engineering, Technology,
Manufacturing & Quality Staff
Peter Boland
George Lynch
Dan Nash
Peter Pao
Jean Scire
Pietro Ventresca
Gerry Zimmerman
Editor Jean Scire
Editorial Assistant Lee Ann Sousa
Graphic Design Debra Graham
Cover Design Scott Bloomfield
Photography Alain Ekmalian
Publication Coordinator Carol Danner
Contributors
Randy Case
Steve Clark
Vern David
Michael DaBose
Ken Davidson
Lou DiPalma
Nancy Fleischer
Tom Flynn
Chris Grounds
Mark Hama
Steve Ignace
Steve Jackson
Keith Janasak
Stan Krutsick
Kenneth Kung
J. Bryan Lail
Jay Lala
Edwin Lee
Dan Nash
John Panichelli
Bhadra Patel
John Rieff
Wayne Risas
Jeff Rold
John Rudy
Mardi Scalise
Yann Shen
Rick Schiele
Rolf Siegers
Rick Steiner
Doris Tamanaha
TJ Theodore
Mark Warner
Ron Williamson
Don Wilson
Ralph Wood
INSIDE THIS ISSUE
Systems and Software Technology 4
Model Driven Computing 5
Technology Networks 6
Cognitive Computing 7
Reference Architecture Development 8
Avoiding Data Smog: Organizing Knowledge 10
Advanced Tool Sets 12
Growing System Architects 16
Human Factors Engineering 18
Engineering Perspective – Randy Case 19
Raytheon Enterprise Architecture Process (REAP) 20
Systems Integration Using Modeling 22
Interview with Dr. Andries van Dam 23
Leadership Perspective – Peter Pao 24
Design for Six Sigma 25
Joint Systems and Software Engineering Symposium 26
CMMI Accomplishments 27
IPDS Upgrades 28
Excellence in Technology - 2003 Winners 29
Quality: Mission Assurance 30
Patent Recognition 31
Future Events 32
EDITOR’S NOTE
As we put this issue together I was reminded of a recent interview that we
did with a local business publication in which the journalist was amazed that
Raytheon was a not only a developer of software, but also by the amount of
software intellectual property that we hold. Today, the top “branded” software
giants include Microsoft, IBM and Hewlett-Packard — an arena in
which Raytheon is not considered a player. However, if you look at our software
capabilities, the enormous lines of code that we are developing for the
new battle space, and our ability to integrate it into the entire system, it is
astounding. In addition to being an integrator of mission solutions, we are
focused on improving our core competencies in systems and software technologies — getting back
to the basics on which our company was founded.
Working off of our strengths and branding our technology, supported by the pillars of customerfocused
marketing — Performance, Relationships and Solutions — we will have a future filled with
growth and opportunity. Read through this issue of technology today to learn about where we are heading.
I would like to thank our contributors on this issue, as well as past issues, who have worked so
hard in their spare time compiling, writing and editing the feature stories and other articles. For
most of us engineers, creative writing is not something that we like or are comfortable with. I really
believe this since it is 4:00 a.m. and I am trying to get my sections completed to make deadline so
the magazine can go to print. The work you do for this publication is appreciated as we strive to
provide superior learning opportunities to promote our One Company culture.
Jean Scire, Editor
jtscire@raytheon.com
an Product
3

Raytheon
Systems and Software Technology
in Support of Mission Systems Integration
Here at Raytheon,
Software
Engineering and
Systems Engineering
technology have been
working, for several
years, to join forces.
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. As the line has blurred
between systems and software technology
issues, the two networks have provided a
united front to solve the technology issues
the company faces.
Systems and Software Engineering are at
the core of virtually all product and system
development at Raytheon. They are part of
initial concept studies, through design and
development, to the pre-planned product
upgrades during the operation and
maintenance phase. These methods and
techniques have been developed by engineers
across different projects, at different
geographical locations, and for different
customers. By sharing the same process and
tools, engineers across the company can
exchange information and experiences to
reduce the total ownership cost, maintain
development schedules, and apply the best
practices. These advanced approaches
should translate to satisfied customers and
continued growth for Raytheon.
This issue of technology today: Systems and
Software Technology in Support of Mission
4
Systems Integration highlights some of the
key issues addressed by the SWTN and
SETN. Raytheon aspires to be the mission
systems integrator for our customers. To be
successful, we must have a wealth of
knowledge in our tool kit to “solve” the
problems facing our customers.
This issue features topics addressing reference
architectures, intelligent systems technology,
modeling, simulation and analysis,
processes and tools, the Technology
Networks, and people. To make the system
meet our customers’ expectations, we use
the systems and software engineering
technologies described in these articles.
Other technologies, while not discussed in
this issue, are also important and will be
covered in future issues.
We are also pleased to profile some of our
key engineering fellows — to introduce the
people behind the technology — who make
key contributions toward the advancement
of systems and software engineering.
We hope you enjoy the material, and we
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 go to the following url:
http://home.ray.com/rayeng/technetworks/
index.html.
Contributors to the Systems and Software
feature articles are as follows: Randy Case,
Michael DaBose, Lou DiPalma, Tom Flynn,
Chris Grounds, Steve Ignace, Steve Jackson,
Keith Janasak, Stan Krutsick, Kenneth Kung,
J. Bryan Lail, Jay Lala, Edwin Lee,
Bhadra Patel, John Rieff, Rolf Siegers,
Rick Steiner, Doris Tamanaha, TJ Theodore,
Ron Williamson, Don Wilson, Ralph Wood

Model Driven Computing
Leveraging Emerging Technologies
As our products continually become
more complex, and our customers demand
lower risk and higher productivity,
Raytheon’s engineers continue to look for
new ways to develop our systems and software.
Additionally, to grow as a mission
systems integrator, Raytheon must be able
to develop complex system
architectures that meet
customer standards, and
must be able to efficiently
turn those architectures into
working products. An evolving
technology that addresses
these issues is Model-Driven
Computing (MDC).
Model-Driven Computing is
our term for system and
software development driven
and centered on models that
are used to specify systems
and software architecture,
and low-level system design
details. Raytheon, going
beyond the commercial tools
available today, is working
towards merging commercial,
government and university
research into a more complete MDC
strategy. This approach optimizes such tools
and standards as the Unified Modeling
Language (UML), Model Driven Architecture
(MDA) and output from some advanced
research programs funded by the Defense
Advanced Research Project Agency (DARPA).
Raytheon’s MDC approach starts with
important industry standards. UML, today’s
key standard in software systems modeling,
has recently become even more complete
with the release of UML 2.0. UML provides
the foundation for most commercial modeling
tools and is extensively used across
Raytheon. However, although UML is an
expressive and powerful language, it does
not provide for integration of different
model standards, or portability of models
to different platforms. This extension and
advancement of modeling is the goal of
the MDA approach advanced by the Object
Management Group (OMG). MDA provides
key capabilities desired by Raytheon customers,
such as portability of models from
simulations to deliverable hardware, and
sharing of models across multiple domains
(e.g., shipboard defense and missile systems).
UML and MDA, both of which are important
commercial standards, but they do
not, by themselves, provide Raytheon with
a competitive edge. Nor do they provide
aspects of the complex modeling environment
needed by Raytheon when integrating
large-scale systems. Raytheon looks to
merge the best of UML and MDA with
research performed by several universities
and DARPA. This research focuses on
advancing state-of-the-art techniques in
the application of MDC to Distributed,
Real-Time and Embedded Systems. DARPA’s
Model-Based Integration of Embedded
Systems (MoBIES) Program is establishing
an open-source, standards-based tool suite.
Tools and methods from this research allow
the development of domain-specific models
and frameworks in complex, distributed
systems. These products go beyond what is
provided in today’s commercial standards
and tools.
Another primary objective is the improved
control and generation of system software.
One MoBIES technology developer is the
Institute for Software Integrated Systems
(ISIS) at Vanderbilt University. ISIS, as well as
being a major contributor on the MoBIES
program, is working to determine if
DARPA-funded efforts have
a chance of making it into
the mainstream, and to
migrate DARPA-funded tools
to the ECLIPSE Open-Tool
Integration Framework (via
sponsorship from IBM).
Raytheon is directing and
evaluating research in next
generation modeling tools,
such as Vanderbilt
University’s Generic
Modeling Environment,
which are developed under
the industry standard Open
Eclipse Framework.
To secure our leadership in
these important technologies,
Raytheon is actively
developing, evaluating and
leveraging model-driven computing tools
and methods. We also participate in the
development of new standards focused on
real time modeling within the OMG. We
are performing cooperative research with
universities to evaluate new modeling technology
in our domains. We are also founding
members of a new consortium dedicated
to commercializing DARPA software research
(the ESCHER Research Consortium). And we
actively support the sharing of this information
through our technology networks.
Raytheon will continue to be active in all
aspects of Model-Driven Computing. As
standards are stabilized and tools mature
and emerge, this technology will be vital in
helping us to meet our customers’ everchanging
requirements. MDC will continue
to play an important role in helping to
make Raytheon the premier mission
systems integration company. �
5

Using the Technology Networks
to Leverage
Raytheon’s Technology
A critical challenge for Raytheon, indeed
any diverse technology company, is achieving
maximum leverage from our people and
technology. How do we take advantage of
a cutting edge technology solution developed
at one location to simplify other
customer solutions across Raytheon? How
should we communicate technology ideas
across the diverse and talented Raytheon
engineering community? To grow as a
mission systems integration provider, how
can we more tightly integrate our diverse
products? A critical part of Raytheon’s
solution to these issues is Raytheon’s
Technology Networks.
The Technology Networks are formally
organized and officially recognized networking
communities within Raytheon.
These communities provide employees with
common technical interests a way to share
knowledge, experience, lessons learned and
best practices. The Technology Networks
promote a One Company spirit for technical
collaboration and knowledge sharing, and
help advance Raytheon's goal of technology
leadership. Membership in the
Technology Networks is typically open to
any interested individual; leadership roles
are normally appointed by business or
functional leaders. Raytheon’s Technology
Networks are organized by technology
disciplines (see sidebar). Each network
sponsors a number of Technical Interest
Groups (TIGs) that are focused on specific
technologies or related disciplines.
Raytheon’s growth in mission systems integration
is enhanced by the synergy provided
by our Technology Networks. Mission
systems integration requires a synthesis of
Raytheon’s many diverse capabilities and
growth in systems architecture and assurance.
These emerging needs are directly
supported by the Technology Networks
through the TIGs and other network activities.
6
Uniform architecture standards and processes,
for example, have become a key focal
point within the networks. Modeling and
simulation advances are also crucial to
reducing cost and risk in large-scale systems
integration, and the networks have helped
to improve simulation integration across
Raytheon businesses. The networks
provide a proven vehicle for breaking down
company boundaries. In the future, the
Technology Network role will become even
more critical as systems become more
complex, interoperable and networked.
In addition to the TIGs, each Technology
Network sponsors an annual symposium.
These gatherings provide a great opportunity
for Raytheon engineers to share technical
approaches and experiences. The Systems
and Software Technology networks jointly
sponsor one such symposium, which has
been evolving and improving for over 20
years. In 2004, this symposium included
165 presentations, many of which demonstrated
capability and experience in largescale
systems and software integration.
Other symposium tracks were organized
around systems architecture, modeling and
simulation, intelligent systems, model driven
architecture and interoperability, etc.
All employees are encouraged to participate
in Raytheon’s Technology Networks. For
further information please access the
Technology Networks web site:
(http://home.ray.com/rayeng/technetworks/
index.html). �
Technology Networks
at Raytheon
Raytheon’s Technology Networks are
listed below, including examples of
some specific technologies and interest
areas. Networks frequently collaborate
in areas of technology overlap.
Electro-Optical Systems – Focal plane
arrays, high-energy lasers, image processing,
cryogenics, optics, ATR
Mechanical and Materials Engineering
– Structural design, coatings, ceramics,
nanotechnology, composites, interconnects,
packaging, thermal analysis
Processing Systems – Signal processing,
data processing, HW/SW co-design,
board design, parallel processing,
dependable computing, HW reuse
RF Systems – Active arrays, MMICs,
antennas, power control, microwave,
analog and optoelectronic technologies
Software – Network centric systems,
model-driven architectures for real-time
systems, intelligent systems, software
product lines, software tools and languages,
architecture processes
Systems Engineering – Government
and industry standards, object-oriented
systems engineering, modeling and
simulation, architecture process,
information security

Cognitive Computing
A Renaissance in Information Processing Technology
That’s how the Defense Advanced
Research Projects Agency (DARPA)
Information Processing Technology Office
(IPTO) views Cognitive Computing. A cognitive
system knows what it is doing. It can
reason, learn from experience, explain its
actions to the user, be told by the user
what to do, be self-aware and reflect on its
own behavior. Developing the computing
technology that will enable cognitive systems
with such attributes is the focus of
the recently recreated DARPA IPTO office.
Why do we need to impart such humanlike
capabilities to computers? The motivation
is not hard to find. Computer systems
are the backbone of many mission-critical
DoD systems. Looking more broadly,
computing and networking are becoming
pervasive in all aspects of society and the
national infrastructure is critically dependent
on their correct operation. Yet, while
realization of Moore’s law has resulted in
amazing growth in hardware capabilities,
thereby enabling exponentially growing
performance and functionality at ever
decreasing cost, many of the non-functional
properties of information systems have not
kept up. In fact, trustworthiness, productivity,
and effectiveness have all suffered. Systems
have grown more rigid and fragile. They
cannot gracefully change and adapt as user
requirements evolve or when unforeseen
operational conditions are encountered.
Cognitive computing is seen as the revolutionary
technology that will provide the required
quantum leap in non-functional properties.
Figure 1 depicts a strawman architecture
for providing cognitive capabilities. The
main elements of a cognitive system
include perception, communication, reasoning,
learning, and action. Systems today are
designed to be primarily reactive in nature.
They process inputs provided by sensors,
execute various preprogrammed algorithms
and computations and produce outputs
that then affect the external environment.
This is analogous to the lowest level of
human cognition, generally categorized as
a reflexive process. The next higher level of
cognition is a deliberative process. It
involves a degree of prediction
and planning, and
some reasoning. IBM’s
Deep Blue computer,
which defeated the world
chess champion, Gary
Kasparov, can certainly be
thought of as possessing
these attributes.
STM
The highest level of human
Attention
cognition is embodied in a
reflective process. It involves reasoning and
learning. A human can go back over a past
event and reflect on it. One can ask and try
to answer questions such as: What did I do
wrong? What did I do right? How should I
react the next time I’m faced with the same
situation? We generally call this learning from
experience. And since no situation repeats
exactly, we can also reason about what
lessons to apply to the current situation.
Of course, humans can also be taught,
and don’t learn only by making mistakes.
Supervised learning in information
systems is already considered a reasonably
successful story, at least in some
limited application domains. The truly
ambitious DARPA goal is to make breakthroughs
in reasoning and reinforcement
learning in varied environments. This is a
personal favorite of the DARPA Director,
Dr. Tony Tether.
The IPTO research thrusts, illustrated in
Figure 2, parallel various components of
the cognitive agent architecture.
Additionally, there is a line of research to
make the underlying hardware and software
of cognitive systems more robust,
ensuring they are impervious to their own
faults and resilient to external attacks. The
Self-Regenerative Systems program falls in
this class. (More details on the specific
research challenges in each of these areas,
as DARPA sees it, can be found on their
web site: http://www.darpa.mil/ipto)
Is any of this relevant to Raytheon’s business?
If so, how? Raytheon IDS has adopted
a new business model, which will be the
Refletive Processes
Deliberative Processes
Communication
(language,
gesture,
image)
Other
reasoning
Prediction/
planning
Perception Action
Sensors
Reactive Processes
Emotion
Effectors
External Environment
Figure 1. Strawman Architecture of a Cognitive Agent
leading Mission Systems Integrator for the
DoD. It requires core engineering competencies
in large-scale software and system
architecture development, integration, and
validation. As indicated above, the complexities
of such systems have grown along
with their functionality, resulting in a high
degree of fragility and inflexibility. And it is
well recognized that a major fraction of the
Cognitive
Teams
Knowledge
Representation
& Reasoning
Systems that Know
What They’re Doing
Cognitive Architecture
Learning
&
Perception
LTM
(knowledge based)
Concepts
Sentences
Systems
Communication
&
Interaction
Robust Software & Hardware
Infrastructure
Figure 2. Research Thrusts for Cognitive Computing
Applications
Core
Cognition
total development cost is incurred in the
integration and validation phases. The technologies
underlying cognitive systems have
the potential to reduce both these costs
and the high risks attendant in systems
integration. They can enable systems that
not only meet their performance and functional
requirements, but are also flexible,
adaptive, and robust to changing environmental
conditions and faults and attacks,
resulting in high mission assurance-a quality
in demand by both of our customers in
the DoD. �
7

A Customer Focused Process
8
for Reference Architecture Development
At Raytheon, a Common Reference
Architecture process is being developed
within the context of a customer focused
Concept of Operations (CONOPS). Net-
Centric Operations (NCO) provides a relevant
case study that illustrates the core
concepts of this development; NCO which
will be at the heart of all future DoD procurements
over the next 20 years, is a core
aspect of all Raytheon business areas.
Because of the central nature of the
Reference Architecture, it is important the
fundamental patterns defining the architecture
be clear and concise. The NCO case
study patterns, Global Communications
Grid, Infosphere and Common Decision
and Execution Capability (CDEC), provide
an illustrative example of the concept.
Figure 1 illustrates how Reference
Architectures bridge the gap between
Customer-Focused Marketing (CFM)
processes and the implementation of
Figure 1: Reference Architecture Context
domain-specific architectures that build on
legacy systems and emerging technologies.
Modeling and simulation are essential tools
to evaluate the effectiveness of reference
architectures and the resulting domain-specific
architectures. The results of the modeling
and simulation effort provide metrics
that can be used to eliminate, aggregate or
validate the key components, technologies,
and relationships.
The Reference Architecture is continually
updated and refined based on this feedback
loop. It is not the final plan for
implementing system-specific design and
integration, but rather a set of patterns.
It is the responsibility of the organization
accomplishing a systems task to engineer
and build an instance of the Reference
Architecture to suit the needs of a particular
domain, while maintaining compatibility
with the overall common Reference
Architecture.
The skills needed to perform this task are
described in an accompanying article,
“Growing System Architects to Empower
the Warfighter” (on page 16).
When working with our customers it is not
necessary to start from scratch each time.
The DoD community has a significant number
of vision papers which provide a basis
for the Reference Architecture analysis.
These include:
• Transformation Planning Guidance:
Clear, concise approach for transforming
the Department of Defense.
(Apr 03)
• Joint Vision 2020: CJCS’s Vision for
the 21st Century; supercedes JV 2010
released in July 1996. Concept for
Future Joint Operations (CFJO).
• The Army in 2020: The Army’s Vision
for Land Warfare in Support of
JV2020.

• Sea Power 21: NCO’s Vision for
Maritime Operations in the 21st
Century.
• Operational Maneuver From the
Sea: Commandant’s Vision for
Marine Corps Projection of Naval
Power Ashore.
• Air Force Vision 2020: CSAF Vision for
Air Operations into the 21st Century.
To adequately understand these documents,
the CFM process distills the visions down to
a few important statements and then validates
the key themes through customer
interactions. For example, the above vision
documents all have a common theme as
they describe the future:
• “The services want to fight Joint”
• “The services want to mass effects
not forces”
• “The services want to fight Non
Linear”
• “The services want to influence two
to three times more battlespace than
they do today”
• “The services want to be ready to
fight in less time”
To achieve the services’ “Future Vision”,
doctrinal and material changes will follow
as a matter of course. These changes
include:
• The Line of Sight (LOS) engagement
will occur by exception not by rule
• The dominant killer on the battlefield
will be Non-Line Of Sight (NLOS)
weapons
• Persistent situational awareness is
essential to executing these concepts
• The force must be more agile and
deployable
• The way we perform BMC4I today
will have to change
The Reference Architecture provides the
conceptual framework for specifying the
four aspects (social, cognitive, information
and physical) of systems within the bounds
of operational, system and technical views
prescribed by the DoD Architecture
Framework (DoDAF). It also provides architectural
guidelines for domain-specific
implementations, while allowing a range of
design solutions. Finally, it defines the architectural
patterns for discussion and analysis
purposes, how the patterns communicate
with each other, the basic operations associated
with each pattern and the nature of
the communications. In the NCO Case
Study the patterns included:
• Common Decision and Execution
Capability (CDEC) Architectural
Pattern
– A remote, distributed, and nondedicated
BMC2 system that
develops, builds, and executes
optimum real-time kill chains from
all available Communications,
Sensors, C2, Platforms and
Effectors.
• Infosphere Architectural Pattern
– Encyclopedia of past, present and
predicted state
– A combat information
management system that
integrates, aggregates,
and distributes information in
appropriate form and level of
detail to users at all echelons.
• Global Communications Grid
Architectural Pattern
– Communications mechanism for
element interactions
– An integrated wideband
communications, netted sensor, and
advanced data fusion system that
employs the Infosphere and the
CDEC as they are developed.
• Strategic Planning Functional Pattern
– The definition and allocation of
resources for a mission
– Provides strategic to campaign level
planning to include worldwide data
base access and fusion in support of
the Warfighting Function
• Logistics Functional Pattern
– The supply of resources specified in
plans supporting the tactical and
operational application of
combat power
– Includes global logistics and
sustainment elements in support of
the warfighting function
• Execution (warfighting, peacekeeping,
policing, etc.) Functional Pattern
– The enactment of the strategic plan
using the resources supplied and
maintained by logistics
– Contains all the elements required
to effectively employ resources
and effects.
Through Customer-Focused Marketing and
interactions, the CONOPS for Net-Centric
Operations is captured and mapped onto
the Reference Architecture in an iterative
process. The Reference Architecture provides
viewpoints (from the perspective of
key stakeholders) to validate the patterns.
The domain layers are used as constraints
on the development of domain specific
architectures defined by individual programs.
The effectiveness of the resulting
architectures is then evaluated through
modeling and simulation, and limited
objective experiments and demonstrations.
The final results are then fed back into the
Reference Architecture maintenance process
to validate or drive changes to the core
Reference Architecture.
The reference architecture process described
in this article is leading the way to the
development of a seamlessly integrated
network of remoted, distributed, non-dedicated
components, creating warfighter
dominance through information superiority.
The NCO patterns (sensors, effectors and
Command and Control) described above
are used in the Reference Architecture to
provide guidance to the domain-specific
architects in each strategic Raytheon business
area. Raytheon’s domain expertise
spans the breadth of Net-Centric
Operations, from sensing to distributed
command and control, to effects, and
finally to complex systems integration. �
9

AVOIDING DATA SMOG:
Commercial, industrial, and military
knowledge workers frequently find themselves
immersed in data smog, with far
more capability to create information than
to find and retrieve it when needed.
Because of this, huge amounts of amorphous,
unstructured data overwhelm us,
just when we need pertinent actionable
data for informed decisions, e.g., when the
decisions are time-critical. Technologies to
help us manage our search and retrieval
efforts are discussed below (metadata for
data descriptions, taxonomies for data
categories, and ontologies for data relationships).
Such applications have been driven
by commercial needs to identify information
on the Semantic Web and to provide
web services that deliver the right information
to consumers. The value of such
technologies to military applications has
been recognized by DARPA, which
sponsored development and deployment
of the DARPA Agent Markup Language
(DAML) a machine-processable ontology
description language 1 .
Motivation
Problems arise when users and systems
employ different terminology for the same
concepts and information, or the same
terminology for different concepts and
information. However, a number of World
Wide Web Consortium (W3C) 2 thrusts
show promise in improving this situation.
Although the original impetus was Web
knowledge management and e-Commerce,
the resulting benefits clearly can apply to
any situation where a common vocabulary
and established terms and synonyms are
needed. A common language with defined
semantics supports more accurate and precise
retrieval of information by intelligent
software agents.
Definitions
These definitions will help you understand
the language that is being used to describe
W3C initiatives:
Data – specific instances of an information
category. Example: for the category books,
a specific instance is “War and Peace”.
10
Metadata – information that describes
other information (or data about data).
Example: for the category books, information
about the instances includes author,
publisher, date of publication, etc.
Taxonomies – categories of entities
defined for a particular purpose. The term
itself comes from biology, where it is used
to define the single location for a species
within a complex hierarchy. Example: a
taxonomy for publications could include
books, dictionaries, thesauruses, journals,
magazines, newspapers, etc.
Figure 1. Technology Taxonomies Markup
Ontologies – categories of entities and the
relations among them. Example: for the
taxonomy publications, some relations
could be that dictionaries are a subclass of
books, thesauruses are a subclass of books,
journals are disjoint from magazines, etc.
Here the relations are “subclass of“ and
“disjoint from”.
The Semantic Web – an extension of the
current Web where embedded ontology
descriptors specify the meaning of the
information in a manner suitable for
machine processing. The Semantic Web is
similar to Hypertext Markup Language
(HTML), which is interpreted by Web
browsers to format the display of Web
content for human use. These are both
languages that are interpreted by agents
to control interpretation and processing
of content. Current languages are built on
Extensible Markup Language (XML). These
include Resource Description Framework
Mechanisms for
(RDF) to specify properties, and DAML to
specify relations.
Web Services – software that supports
interaction among systems on a network.
One language that supports such interaction
is built on DAML, DAML for Services
(DAML-S) 3 .
Ontologies Applications
Technology Taxonomy – An enterprise
project currently underway will define a
taxonomy to organize technology information.
The objectives are to make it easier to
find specific information and identify subject
matter experts (SMEs). A taxonomy of
technologies at Raytheon is being defined
by analyzing the capabilities and restrictions
of commonly used technology categorization
schemes, notably the Defense
Technical Information Center (DTIC) taxonomy,
the UK Ministry of Defense (MOD)
Taxonomy, and the ACM Computing
Classification System. This effort will define
a controlled vocabulary and create a thesaurus
containing synonyms, to ensure
standardized terminology. Technical papers
and SME biographies will be marked up
using a set of metadata elements to identify
title, subject, description, creator, date,
and other relevant publication characteristics.
A commonly adopted metadata definition
for documents is the Dublin Core 4 ,
which is an option under evaluation.
Figure 1 shows the major components of the
envisioned Technology Taxonomy system.

Organizing Knowledge
Figure 2. Ontology Based Information Markup and Retrieval
Reference Architecture – A reference
architecture models, evaluates, compares,
and improves the implementation and
performance of operational concepts and
system designs to support Network Centric
Operations (NCO) 5 . An established set of
ontologies ensures that common concept
definitions for architecture elements and
information are used in the modeling and
simulation predictions.
Military Application – Military information
users must make life-critical decisions
based on large amounts of time-sensitive,
rapidly changing inputs from multiple sources.
The Common Operating Picture (COP) is a
distributed database, currently packed with
disparate and sometimes incompatible
data. In the future, it will be generated by
human operators and software agents
marking up information from sensors or
sources in accordance with (IAW) military
standardized ontologies.
Figure 2 shows how the marked-up sensor
and source information is stored in the
Information Grid and retrieved by subscribers.
The Common Relevant Operating Picture
(CROP) is obtained by consumers (humans
or software agents) subscribing to relevant
information specified IAW the same
ontologies used to create the COP; information
irrelevant to the consumer’s context
is suppressed. The ontologies are stored
and maintained in the Information Grid,
ensuring identical specifications are accessible
to both producers and consumers
Figure 3 shows the top level processing
architecture to generate the CROP.
Figure 3. Ontology Processing Architecture
Summary
Employing a single, consistently applied
meaning (semantics) for concepts, categories,
and relationships reduces confusion,
misinterpretation, and mistakes by utilizing a
single, consistently applied meaning (semantics)
for concepts, categories and relationships.
This approach also reduces cognitive
overload by supplying users with information
that is relevant to their location, situation,
and responsibilities. Taxonomies and
ontologies support both improvements. �
References
1 www.daml.org – The DARPA Agent Markup
Language Homepage
2 www.w3.org – World Wide Web Consortium W3C
3 www.daml.org/services/ – DAML Services
4 dublincore.org – Dublin Core Metadata Initiative
5 A Customer Focused Process for Reference
Architecture Development, previous article – this
technology today issue
Fellows Profile
Dennis Frailey
Principal Fellow
NCS
Dennis Frailey has a
wealth of experience
spanning his careers as
a college professor and
engineer at Raytheon.
He has designed and developed compilers,
computers, operating systems, user interfaces,
expert systems, simulators, and numerous
application systems; written hundreds of technical
papers; served in several capacities with
professional societies and has given numerous
conference presentations. “Follow your heart
and always pay attention to what’s new,” is
Dennis’ advice to young engineers. He did
exactly that when, as a BS Math graduate in
1966, he opted for graduate school in the
then-emerging field of Computer Science
rather than accepting the well-intentioned
advice of his professors to “go into a more
established discipline.”
Dennis also spent most of his career as a
college professor. After earning his PhD in
Computer Science (Purdue, 1971) he took a
faculty position at Southern Methodist
University (SMU). But he was soon working
part time at Texas Instruments (TI), building
a real-time operating system for marine navigation,
simulation studies, for seismic data
processing and an Algol compiler for the
Advanced Scientific Computer. In 1977 his
roles reversed as he switched to a full-time
position at TI and an adjunct teaching position
at SMU. For the next 25+ years, he always
found opportunities to teach part time — at
SMU, The University of Texas, UCLA, and
National Technological University.
Dennis brings the realities of the workplace to
his courses — and he teaches many, inside
and outside of Raytheon. He builds bridges
between industry and academia — he serves
on industry advisory boards, sponsors university
research programs, and gives technical talks.
“Good education must be founded in real
experience,” says Frailey, noting that his “real
jobs” over the years have included computer
design, software design, project management,
process improvement, proposal writing, and
even writing speeches. He credits effective
communication as a cornerstone of his career.
“I learned on the firing line how to communicate
effectively in a business context. You can
be the most brilliant technical expert in the
world, but if you can’t convince others to
accept your ideas, your career will plateau.”
Why has he stayed with the same company
for 30 years? “Because there are always new
things to learn and real problems to solve.”
11

Advanced Tool Sets
Raytheon recognizes the importance of
mastering emerging engineering methods
and tools to successfully perform its role as
Mission Systems Integrator on large complex
programs. These methods and tools
support holistic systems thinking and promote
engineering best practices for implementing
System of Systems solutions. The
capabilities necessary to excel as a Mission
System Integrator fall into the following
major categories (with modeling and simulation
integrated across all areas):
• Mission Analysis & Architecture
• Performance Analysis & Prediction
• System Design & Specification
• Specialty Engineering
• Verification Analysis & Execution
Activities conducted in each of these areas
rely on specialized subject matter expertise,
information management and engineering
processes and tools. Each capability must
be developed with an eye on the
Integrated System Model (Figure 1) to support
continuous improvement and accommodate
growth as a world-class Mission
System Integrator.
The activities shown in Figure 1 may be
performed independently when working
on small programs, resulting in islands of
analysis, where there is limited sharing of
culture and information between models.
Even if each “island” represented a worldclass
capability, maximum benefit could not
be achieved without a higher level of integration.
The need for Integrated System
Figure 1. An Integrated Model for Advancing
Mission Systems Integration
12
for Systems Engineering
Figure 2. DoDAF Products and Product Interrelationships
Table 1. DoDAF Products Related to the other MSI Capabilities
Models increases as the scope and complexity
of the system or Systems of Systems
(SoS) solution increases. This article
describes efforts currently underway within
Raytheon to establish the framework by
which this integrated model can leverage
Mission Systems Integration (MSI) techniques
for maximum stakeholder benefit.
Mission Analysis & Architecture
The Raytheon Enterprise Architecture
Process (REAP) uses the Department of
Defense Architecture Framework (DoDAF)
to develop, present and integrate architecture
descriptions. DoDAF products are used
to define the operational domains, rules
and constraints by which all systems in the
domain operate to perform specified missions.
DoDAF products set the mission
context, define required activities, identify
participating elements and manage pertinent
mission information. Figure 2 uses a
color-coded number to place each product
into one of four DoDAF views: All,
Operational, System, or Technical Standard.
Icons represent the type of data each product
documents, and lines between products
show the relationships between
objects modeled in each product. These
products also contain information related
to the other MSI models. Table 1 provides a
mapping between DoDAF and these other
models.
DoDAF tools such as Popkin System
Architect (SA) provide editors for each

product; an integrated dictionary
manages the inter-relationships
between them.
Application and use of DoDAF and REAP are
growing within Raytheon through individual
efforts and the efforts of the Architecture
Technical Interest Group (TIG) sponsored by
the Systems Engineering Technology
Network (SETN). The DD(X) program, along
with other programs in Garland, use Popkin
SA for CAF/DoDAF architecture development,
linking their architectural elements to
requirements in DOORS. DD(X) has extended
the Popkin SA meta-model to accommodate
specific interface definition and specification
tree structures.
Raytheon has also used the Ptech Enterprise
tool to develop Zachman and DoDAF views.
Ptech’s concordant knowledge base was
used to create the AV-2 and the OV-3 for a
portion of the Military Information
Architecture Accelerator (MIAA). Raytheon
used the Ptech software to publish a CD,
allowing the customer to examine the architecture
through a web browser and also
exported the OV-5 activity model as code
for a Colored Petri Net simulation.
Other programs use the Extend modeling
tool to run system performance Analysis,
helping them better understand and derive
complex system requirements. Extend has
also helped Missile Systems model Netted
Weapons Systems architectures using simulation
to measure the "power" of alternate
IR&D and NetCentric approaches. Network
Centric Systems has built elaborate Extend
models used to test out SoS architectures,
building executable Concept of Operations.
As the DoDAF products mature, information
can be flowed down to the system analysis
and design models for additional analysis
and refinement at the system level. Table 1
shows how the DoDAF products can provide
useful information to the Performance
Analysis, System Design & Specification,
and Specialty Engineering capabilities. The
following paragraphs define each of these
advanced capabilities in more detail.
Mission Analysis Examples of Information to be Exchanged: Example Exchange
Interface to: Format/Tool: Standard
1. Performance Simplified Mission Scenarios Extend
Analysis Force-on-force performance EADTB
2. System Design DoDAF AV/OV/SV/TV (System context, operational Popkin SA, Ptech, UML 2, XMI,
and interface constraints), Tau, Rose SysML, AP233
Mission Requirements DOORS DXL
Use Cases (mission and system requirements) Use Case templates
3. Specialty System of System Availability and Cost Tradeoffs CALCE PWA SPAR
Engineering CoSysMo, CoCoMo
Ultra-reliability eXpress DiagML
Reliability predictions FMECA Asent
Table 2. Mission Analysis Interfaces and Tools
System Design and
Specification
Raytheon has considerable experience
applying sophisticated system modeling
tools like Foresight, RDD-100, CORE and
StateMate to solve complex system design
problems. These tools are used to develop
static and dynamic holistic models of the
system, as represented in Figure 3. By
carefully controlling the level of abstraction
of the system’s internal components
and interfaces, over-specification and unnecessary
design detail
can be avoided.
Raytheon continues
to gain experience in
using automation to
extract specifications
from well-structured
system models. This
powerful capability
has provided
unprecedented
insight into the
system design as it
matures. By checking
requirements traceability,
functional allocation, interface completeness,
and dynamic execution of the
system model, Raytheon has shown that
the completeness and consistency of the
resulting specification can be assured. In
addition, a well structured system model
provides a flexible framework for relating
performance budgets to system components,
identifying detailed analysis needs
and relating analysis results back to the
overall system context. The analytical techniques
that are used have included closed
form expressions, discrete event models and
network analysis.
The Unified Modeling Language (UML), a
popular software modeling language, is
Figure 3. The Holistic System Model Comprises both
Form and Function for each system alternative
Figure 4. The System Model is a Framework for linking
Requirements and Analysis to System Design
now showing promise as a systems modeling
language. Raytheon is an active participant
in SysML Partners, currently defining
conventions for use of UML 2.0 in Systems
Engineering (http://www.sysml.org). SysML
emphasizes a flexible component-based
model-driven approach to system specification,
promising the encapsulation and reuse
of Object Oriented techniques as well as the
strong interface management necessary for
successful MSI. SysML supports allocation of
function to form and facilitates system tradeoff
and technology upgrade Analysis.
Continued on page 14
13

ADVANCED TOOL SETS
Continued from page 13
Use Cases, a methodology used to identify,
clarify and organize system requirements,
promotes good systems engineering
practices by
segregating analysis
and design. On large
complex systems, it is easy
to get carried away and produce
“Use Case Explosions,”
decomposing use cases as if they were
functional hierarchies. Raytheon is building
on successes in applying Use Case methods
to requirements development. Figure 5
shows a proven method for parsing Mission
Level Use Cases into a minimal set of
Design Level Use Cases.
Figure 5. Structuring and Simplification of Use Cases is Necessary for Complex
System Design
The System Holistic Architecture and
Requirements Process (SHARP) pilot program
initiated by Raytheon IDS in 2003 has
already provided initial standardized guidelines
for complex system specification using
Use Cases. This pilot will continue into 2004,
leveraging Raytheon’s strategic alliance with
IBM/Rational Software, and capitalizing on
the Rational Unified Process for Systems
Engineering (RUP SE). Leveraging on this
work, the Raytheon SEC has also provided
funding to incorporate Object-Oriented
model-driven system design practices and
enablers into IPDS in 2004.
Performance Analysis
After enjoying initial successes implementing
Design-for-Six Sigma (DFSS) on programs,
Raytheon is now moving into a
14
System Design Examples of Information to be Exchanged: Example Exchange
Interface to: Format/Tool: Standard
4. Performance Performance Analysis required & dependencies Extend SysML, AP233
Analysis (Analysis Plan), Performance Budgets and Estimates MatLAB
5. Specialty Composite Reliability/Availability, Asent
Engineering Component Reliability/Availability
Human Factors/Maintainability CAD drawings IGES
HSI layout & operability Jack
6. Verification Capability Verification using Test Plans, DOORS, SysML, DXL
Analysis Procedures and Results Requisite Pro AP233
Test Cases Use Case Templates
Performance Examples of Information to be Exchanged: Example Exchange
Analysis Interface to: Format/Tool: Standard
7. Specialty Related Critical to Quality and Key CALCE PWA Excel
Engineering Performance Parameters Express, Ascent, SPAR
8. Verification Performance Verification using Test Results DOORS, DXL
Analysis OLE
Specialty Eng. Examples of Information to be Exchanged: Example Exchange
Interface to: Format/Tool: Standard
9. Verification Reliability Verification using Test Results DOORS, DXL
Analysis OLE
Table 3. System Design and Verification Interfaces and Tools
broader deployment.
DFSS helps ensure
that the system
meets our customer’s
needs, supports
design optimization
through Critical
Parameter
Management techniques,
and guides
product development
using statistically
enabled engineering
methods
and metrics. One
tool currently being
evaluated within Raytheon is the Six Sigma
Cockpit (SSC) by Cognition, with general
capabilities shown in Figure 6.
SSC provides a framework for requirements
development through Quality Function
Deployment, enabling capture of the Voice
of the Customer and derivation of requirements
using a tiered House-of-Quality
approach. Transfer functions implemented
within the tool model the relationships
between all Critical-to-Quality parameters
(CTQs) and associated input parameters. A
series of scorecards permit tracking all of
the CTQs and input parameters, taking into
consideration the variability of each input
and defined transfer function. Interfaces to
external statistical design tools allow for
leveraging data and analysis performed
outside of the Cockpit.
Specialty Engineering
Raytheon Specialty Engineering is evolving
to support Mission Systems Integration. Our
customers are mandating order-of-magnitude
system reliability improvements to
meet extremely aggressive SoS cost and
availability goals. Methods and tools have
undergone a transformation from a pointestimation
focus to a model-driven simulation
approach that comprehends probabilistic
distributional variability. SoS mission success
and performance objectives are being
improved through simulation-based
Specialty Engineering Measures of
Effectiveness and trades analysis.
The U.S. Army Materiel Systems Analysis
Activity is a key advocate of implementing
“Ultra-Reliability” requirements in many SoS
proposals. Raytheon is addressing these
challenges by implementing design process
and tool changes from the device level
through the system level. During system
requirements analysis, specialty engineering
personnel now take a more active role in
determining and characterizing the end
user’s environment and mission profiles.
Raytheon is working with the University of
Maryland’s Computer Aided Life Cycle
Engineering (CALCE) Electronic Products &
Systems Center to better understand the
impacts that temperature, vibration and
shock have on the performance and expected
life of the product over its entire life
cycle (including production, shipping,

Integrated Object-Oriented database
Figure 6. DFSS as implemented in the Six Sigma Cockpit
storage and mission execution). Tools such
as CALCE PWA allow the Specialty Engineer
to utilize use-case and environmental characterization
data to perform Physics of
Failure-based Analysis to calculate fatigue
life, accounting for probabilistic considerations.
Resulting design improvements in
packaging and mounting/supports have
proven to drastically reduce stresses and
board displacements, thereby significantly
increasing reliability
(http://www.calce.umd.edu).
Specialty engineers are now able to perform
engineering analysis based on a thorough
understanding of failure mechanism modeling
and simulation. Raytheon has successfully
used tools such as Clockwork Solution’s
SPAR (http://www.clockwork-solutions.com)
on the DD(X) program to model and simulate
system performance for a given scenario
of design, operations and maintenance
parameters. By leveraging system configuration
data, including statistical performance properties
of the major subsystems, the system’s
behavior can be simulated through timedependent
Monte Carlo techniques identifying
the most appropriate configuration, operating
doctrine and maintenance practices to
achieve performance and cost objectives.
Achieving Ultra-Reliability performance
required in complex SoS architectures, such
as the U.S. Army’s Future Combat Systems,
requires a comprehensive understanding of
the health of all components. Raytheon is
utilizing tools such as DSI’s eXpress
(http://dsiintl.com) to help assess, derive and
implement an integrated diagnostics and
health management strategy. Specialty engineers
use eXpress’s hierarchical functional
dependency modeling to enable the flow
down of test and diagnostics requirements
House of Quality for capturing
Voice of the Customer
Score cards for measuring and tracking
CYQs and input parameters
Interface to 3rd party
tools for modeling
Transfer Functions
for the optimized balance between embedded,
runtime diagnostics and ground-based
maintenance diagnostics.
Verification Analysis and
Execution
Verification analysis starts during the requirements
analysis phase and continues through
product development, integration and test
phases. Verification tools must a) have
extensible schemas to support program tailoring;
b) provide traceability back to the
system requirements; and c) be able to interface
well with our other engineering design
tools. Most Raytheon programs use DOORS
for Requirements Management. DOORS sup-
Figure 7. Verification Analysis and Execution in
DOORS
ports the extensibility, traceability and interface
requirements necessary to adequately
implement the verification process. NCS has
recently implemented a DOORS Standard
Project Image which is available for use on
all new program starts. It includes a set of
templates useful for verification planning
and execution.
The approach shown in Figure 7 uses four
verification work products: the Verification
Plan, Verification Procedure, Test Preparation
and Results, and the Verification Evidence.
The Verification Plan documents each of the
tasks required to completely
Continued on page 30
Fellows Profile
Robert Schaefer
Principal
Engineering
Fellow
Bob is currently serving
as Chief Engineer on
staff to Robert Kern, VP
of SAS Engineering. He
has worked for Raytheon and the legacy Hughes
Aircraft Company in El Segundo for his entire 35year
career, but has provided technical support
to many other Raytheon sites and businesses
over the course of his tenure with the company.
In his current role, Bob is involved in most of the
tactical and strategic electro-optical and radar
systems within SAS, as well as serving on
Program Independent Review Teams for other
Businesses, such as Missile Systems and Network
Centric Systems.
Bob has found the challenge of working with
cutting edge technology and the integration of
that technology into systems to solve our customers
mission problems to be most fulfilling. He
has had the opportunity to work across multiple
engineering disciplines in helping architect systems
which balance the demands on optomechanical
hardware, controls performance,
electronics processing, software, and the ease of
user interface.
The advice he would give to new engineers joining
Raytheon is to constantly look for ways to
optimize the entire system. Balance the requirements
placed upon the detectors, opto-mechanical
and radar packaging, processors, etc., in such
a way that the performance needed by the customer
to fulfill his mission is accomplished while
still having an affordable, producible product
which serves Raytheon’s business needs as well
as the customers’. Bob recommends constantly
looking for ways to leverage new technology
into our products. New engineers should work to
understand greater parts of the system and seek
out opportunities to extend their roles and
responsibilities over larger parts of those systems
or the integration of multiple systems on platforms.
Being in the right place at the right time
helps, but being knowledgeable on the larger
portions of the system(s) will help open opportunities
for growth and greater contribution to our
Customer and our Company. As new engineers
gain more experience, they need to look for ways
to mentor others by volunteering to teach seminars
in their skill area. As Raytheon expands into
systems of systems activities, a significant
stretching of skills and capabilities will be experienced
at all levels.
Bob graduated from the University of Detroit in
1969 with his Bachelor of Science degree in
Mechanical Engineering, and completed his MS
in Mechanical Engineering at UCLA. He has also
taken the Line Management Development
Training, the Advanced Leadership Training with
Raytheon/Legacy Hughes, as well as completing
the USC Management Policy Institute Program.
15

16
Growing System Architects
to Empower the Warfighter
Webster’s dictionary, defines system as
“a regularly interacting or interdependent
group of items forming a unified whole.”
The DoD defines architecture as “the structure
of components, their relationships, and
the principles and guidelines governing
their design and evolution over time.” The
System Architect (SA), therefore, must be a
person who can look over the system,
understand the relationship among interdependent
groups within the whole, and
provide a vision and guidance for the
design enabling evolution over time for
an architecture to form a unified and
coordinated whole.
The SA is charged with putting together a
system’s framework. Working with the
requirements analyst, the SA may choose to
focus on ease of maintenance, application
performance, compatibility with existing
systems, system cost, safety and risk, or any
combination thereof. Each decision the system
architect makes must be carefully considered;
a wrong move at the beginning of
a project can have damaging effects later in
the system development life cycle.
Today’s acquisition programs demand capability
integrated into a complete engagement
chain (more than the kill chain,
including all the elements necessary for a
mission to achieve any effect in the battlespace).
And the future will surely bring even
further broad integration requirements
across numerous systems, contributing to
the overall Net-Centric Operations capabilities.
The SA must be able to experiment
across a dynamic engagement chain, which
changes over time. This will allow the
warfighter to participate in the experiment
along with humans who enter the loop in
the specific mission. It is critical that we
develop an understanding of the resulting
implications of architecture-wide effects on
the dynamics and intricacies of a complex
System of Elements.
The System of Elements provides a new
approach to looking at the battlespace as
Net-Centric Operations are enabled, removing
restrictions even a System of Systems
approach can incur, where any resource
comes from the most logical place and time
independent of all others (dynamic choosing
of elements such as C2, Sensors,
Comms, and Effectors). This will require a
new doctrinal shift, even for System
Architects with large system experience.
As an example of experimentation for the
SA, a Common Tactical Blackboard (CTB) is
evolving that allows real-time interaction for
the warfighter within a distributed timesensitive
dynamic environment, where simulation
technology enables standards-based
experiments including humans, live test
telemetry, hardware-in-the-loop, or individual
simulations. The CTB provides both the
interactive display hardware and the intelligence
that allows effective presentation of
information to the systems integrator or
warfighter. This fluid, context-sensitive, and
mission aware capability helps these individuals
make decisions quickly, and allows the
warfighter to generate tactical level tasking
that is then executed through autonomous,
semi-intelligent operation capabilities.
The level of autonomy for future weapons
systems will have experimental parameters;
some of the most critical future systems
integration trades will tie to a fundamental
shift in Command and Coordination (the
new C2) concepts, and how much autonomy
can be allowed in Net-Centric
Operations, while maintaining rules of
engagement. Other primary experimental
parameters include the technology options
for aspects of the engagement chain, both
for the specific system to be integrated,
and for other elements of the chain that
will impact the best system integration
approach.
Use of real-time, warfighter-in-the-loop distributed
testbeds to experiment with varying
operational architecture capabilities
melds traditionally separate disciplines for
training systems, modeling and simulation,
algorithm and hardware-in-the-loop testing,
and mission-level experimentation. Building
and continually evolving such distributed
systems is critical to the maturation of the
systems architect for warfighting systems,
allowing real interaction and understanding
relative to the complexities of Net-Centric
operations across many technical disciplines
(i.e., Predictive Battlespace Awareness,
Intelligence Surveillance and
Reconnaissance, Command and Control,
Communications, Mission Planning, Fire
Control, Weapon Systems, Battle Damage
Assessment) within a real-time sensitive
context.
Another connection is needed between the
System Architect and the warfighter in the
field in this type of experimentation.
Because new technologies have been
inserted into the warfighter, a large time
lag in tactics development is created and
true understanding of the warfighter’s
requirements is needed. This contributes to
the huge gap between lab development of
technology and full operational employment
in the field (generally far more than
a decade).

A new process must emerge whereby a
System Architect can experiment with new
concepts (within the broad mission scope)
using interactive interfaces such as the CTB.
This ensures that very early in the process,
highly trained warfighters familiar with
Netted Systems concepts (Cyberwarriors)
are brought in to understand the developing
architecture and to drive requirements
and operational changes, as needed. This
should happen years before the capability is
fully fielded. Only the joint development of
systems architects in industry and government
labs, and cyberwarriors in the military,
will ensure the employment of cutting edge
information age technology, with most of
the tactics for operational use already
developed, in time to use commercially
available information technology for Net-
Centric military operations before it is
already obsolete.
A System Architect must also be familiar
and proficient with the use of tools to
develop the architecture in a well discipline,
methodical, and sustainable way. In today’s
environment, a good understanding of the
DOD Architecture Framework and the
methods to develop its Architecture
Products are essential to allow architectures
to be developed in a consistent manner,
and to provide built-in interoperability
attributes to work with other DoD systems.
Understanding the big picture, such as the
Net-Centric Operation and Warfare (NCOW)
concepts, and the various Reference Models
(RMs) is also important, because it helps the
System Architect integrate various architectures
within the Global Information Grid
(GIG), and encourages the development of
architectures having a common long term
objective. To meet these objectives in a consistent,
cost effective, and meaningful way,
Raytheon has developed the Raytheon
Enterprise Architecture Process (REAP).
REAP consists of a series of views, procedures,
and concepts consistent with Net-
Centric Operations, DOD Architecture
Framework, and directly supports the spirit
of Joint Vision 2020 (JV2020).
Various Businesses within Raytheon employ
skilled architects experienced in developing
systems related to their specific Businesses.
However, such skills are not generally available
across Businesses, objectives resulting
in a lack of broad domain Subject Matter
Experts (SMEs). Even those with prior architecture
experience may not be totally in
step with current development and evolutionary
technologies. An overall program
that gives the opportunity to all Raytheon
Businesses to grow System Architects who
are up to date, visionary, and motivated is
key to Raytheon’s Success as a first tier Lead
Systems Integrator (LSI) company.
Continuing education such as conferences,
workshops, and university programs offer
valuable venues to meet these needs.
Raytheon Technology Networks, and
Technical Interest Groups (TIG) such
as the Net-Centric Architecture and
Interoperability (NCAII) and Architecture
Process, provide other means of increasing
awareness and stimulating interest for
engineers to become System Architects.
The Standards TIG keeps abreast of
Government and Industry Standards, such
as the DoD Architecture Framework
(DoDAF), Joint Tactical Architecture (JTA),
Net-Centric Enterprise Services (NCES),
The Open Group Architecture Framework
(TOGAF). As such, it plays a key role in
defining the future direction of architectures
as it applies to our warfighting
community.
While Raytheon enjoys representations and
involvements in these groups, much
remains to be done in terms of expanding
the scope and encouraging more engineers,
in more businesses, to participate. Raytheon
must develop a culture of visionaries that
appreciate the importance of architecture.
There is a saying, “an ounce of prevention
is worth a pound of cure”. The same holds
true with well thought out systems design
and engineering practices. The DoD is very
much in tune with the key roles that architecture
plays, and future acquisitions are
expected to impose even more Architecture
& Interoperability requirements. Raytheon
must not — and will not — wait for events
to overtake us. �
Fellows Profile
Bob Drean
Principal
Engineering
Fellow
Bob Drean is Chief
Engineer for Intelligence
and Information Systems
Engineering, Aurora, CO.
A few years ago, as I was beginning to teach an
introductory systems engineering class, a woman
in the front row asked me, “Before you begin,
what qualified you to be Chief Engineer”. After a
few seconds of thought I answered, “I’m lucky to
work for a company that values growth since it
fits well with my desire to win. I’ve led many
successful campaigns and, recognizing that, the
company has awarded me with the position I
now have”.
But, given some more time, I would have added
that I have leveraged my engineering capability
to contribute to these campaigns. Indeed,
because of my long history supporting proposals,
studies, and related new business activities, I am
often accused of being a marketer. I find those
accusations humorous since my involvement in
activities normally thought of as marketing has
been peripheral. As capture manager for a number
of successful programs over the past years, I
have certainly been involved in establishing
teaming relationships, determining and executing
winning strategies, and nurturing a strong
relationship with customers — all things that a
good marketer must do. But I have also provided
key engineering leadership to these efforts, and
that is the difference. For example, for the successful
NPOESS effort, while I was capture manager,
I spent the two-plus years of study effort as
the ground chief engineer. I later took on the
added role of demonstration lead.
So what is the real secret of my successful 33
years in our company? I’d say it is recognizing
my own strengths and desires and finding projects
to match. My early years were dedicated to
my interest in planetary exploration. I led systems
engineering roles in fascinating programs
such as Pioneer Venus and the Galileo mission to
Jupiter, as well as studies of missions to Mars,
Comets and Asteroids, even briefing the White
House on a concept for an astronomical base to
be placed on the backside of the moon.
When NASA funding dried up, at least for
Hughes, I took on the challenge of getting
Hughes into the three-axis spacecraft business.
Then as Hughes satellites became a commodity, I
moved to our Colorado facility to focus on
ground systems, which were becoming an area
of increasing technical challenge as mission complexity
demanded high degrees of software complexity
and operations autonomy.
I’ve enjoyed the diversity of projects I have been
involved with at Hughes and Raytheon and offer
this advice to others wondering how to become
an Engineering Fellow: Work hard but have fun.
The second part helps with the first.
17

Fellows Profile
18
Ron Carsten
Chief Engineer.
Missile Systems
As Chief Engineer for
Raytheon Missile
Systems, Ron Carsten
spends his days providing
technical advice to
help the business’ many missile programs succeed.
He has the tools and experience for the
job. He’s been making missiles for 34 years as a
designer, a functional manager and project
leader. “I’ve seen a lot of what can go right and
wrong in engineering design, development and
manufacturing programs,” he says.
Carsten wasn’t always the expert he is today. In
1969, he was just out of The Cooper Union in
New York City with specialties in digital design
and control theory, and he found himself testing
analog power circuits for SAM-D — a forerunner
of the Patriot program — in Raytheon’s Bedford,
Massachusetts, labs. “I wasn’t very good at it,”
he recalled. “I still remember the charity and
patience of Stan Geddes, my first supervisor. He
mentored me through the trauma of my first job
and turned me into a decent circuit designer.”
In 1974, Carsten was asked to join a special
engineering group that was transitioning Patriot
to production at Raytheon’s recently opened
Andover manufacturing facility. “Joining that
team was one of my key career moves,” he said.
“It taught me to appreciate how little things
can count in a big way. I learned what it takes
to make a good design that’s successful in the
field and producible in the factory. Now I know
it in my gut.”
This visceral understanding has served Carsten
well as he progressed through the company’s
ranks, rising through management, and serving
as chief engineer on several programs. “One of
the most important lessons I’ve learned is that
we must all think like system engineers, no matter
what assignments we have,” he notes. “If
you don't understand how your design affects
everyone else’s, or how the overall system functions,
you can’t do your job well. You must have
the discipline and interest to explore beyond
your immediate design responsibility.”
“The whole process should be a journey that will
open up a whole new world of technological and
problem-solving opportunities,” Carsten
explained. “That’s how I’ve honed my skills over
the years. As professionals, we need to stay interested
and curious all the time. We should never
settle for conventional solutions or accept
received knowledge.”
When asked why he’s stayed with the same company
so long, Carsten quickly responded that
Raytheon is an incredibly broad company, and he
has never been bored. “The talented people I work
with are open to new approaches and ideas, and
there are so many opportunities to learn,” he
said. “They also focus on helping each other succeed.
How could you leave a place like that?”
Human Factors
Engineering
One of the more difficult aspects of system
architecture, design and integration is
in designing the system for the human end
user. Why is this task difficult? Well, for one
thing, humans are unpredictable in how
they think, feel, and respond to the end
system. In addition, it is difficult to fully
design for stressful environments in which
the system will be used, such as temperature
extremes, peace/combat situations,
and chemical warfare environments.
Because such factors are often not taken
into account, customers may refer to developed
systems as “user hostile” rather than
“user friendly.”
Figure 1. Designing for the Human
Raytheon addresses human needs by incorporating
best practices from within the
Company, as well as using knowledge
based on academic research. Raytheon’s
primary areas of interest for addressing the
human factor include the Human Computer
Interface (HCI) and Hardware/Workstation
Ergonomics for both single user and crew
environments.
System HCI components often include a
multiplicity of individual subsystems, each
developed with its own look and feel.
These often use object-oriented designs
that are less difficult to code and test
(Figure 1). Although such designs meet
requirements, an interface designer’s perspective
can be quite different from the
perspective of a user in a stressful combat
situation. Training, maintenance, and operational
crew requirements are addressed
through innovations being applied through
Human Factors in new systems, such as
Theater High Altitude Area Defense
(THAAD) and the DD(X) Future Surface
Combatant Program.
Human Factors practices, in designing HCI
for usability by the human, involve the
following:
• Creation of Style Guides, which help
ensure commonality between HCI
subcomponents through recommendations
for HCI design in terms of colors,
fonts, window styles, navigation
methods, and screen components
(e.g., push buttons, pull down menus)
• Task Analysis to help define system
interaction and information require-
ments to meet the mission or task.
Critical Task Analysis focus on which
tasks can be automated and which
must be reserved for the human end
user. Human-centered functional
allocation decisions early in the system
engineering process can profoundly
affect the effort and staff required to
operate the objective system
• Rapid Prototyping of HCI concepts,
which help mature software design
and analysis. This gives the customer
a window into the design “vision” of
the overall HCI
• Usability Testing of HCI concepts with
representative end users, helping to
validate human interaction in a variety
of situations. Usability testing will
primarily analyze performance in
terms of decision/action time and
accuracy of decisions/actions. These
testing results then drive recommendations
for screen design.
Additionally, usability results can

Figure 2. Human Factors in the Design Process
steer other HCI development. For
example, results of THAAD usability
testing have been used to help in HCI
designs for DD(X) watchstander displays
for air defense. Use of simulations
and early human-in-the-loop
testing mitigate poor human interface
designs before they are locked.
By performing these practices, Human
Factors helps verify the usability of software
requirements before the software is actually
developed and tested. As shown in Figure
2, Human Factors is performed concurrently
with Systems and Software design to provide
recommendations and guidance on
developing software requirements that
keep the end user in mind.
Figure 3. Testing Quick Remove/Replace Prototypes in Protective Clothing
Figure 4: Moving to Human-Centered Design
Hardware and Workstation Ergonomics is
performed in a similar manner to HCI development,
with the exception of software
engineering and requirements. In this environment,
Human Factors is concerned with
the ability of system hardware components
to answer the following questions:
• Can the system accommodate physical
extremes of end users, from a 5%
female (5 feet tall, 95 pounds) to a 95%
male (6 feet 4 inches tall, 240 pounds)?
• Can the system accommodate for
extreme temperature or chemical environments
which require heavy clothing
that significantly hamper the end user’s
ability to perform tasks in a timely and
accurate manner (e.g., typing, performing
maintenance, or viewing a screen)?
Human Factors practices in designing hardware/workstations
for usage by humans in a
variety of environments involve the following:
• Incorporating best practices from industry
into hardware designs, such as quick
remove and replace parts (Figure 3) and
fully adjustable work environments
• Mockups / Rapid Prototyping of work
areas and anthropometric assessments
(i.e., human fit), which help ensure the
ability of the human to perform his/her
job before hardware is actually built
(Figure 4).
Human Factors Engineering
at Raytheon is becoming more
of a One Company approach,
leveraging Knowledge
Management and “lessons
learned” of mature projects
into the design of developing
projects. Innovative interfaces,
application of lessons learned
from the Joint Armed Forces,
best practices, modeling,
and usability testing, all are
vital in their
role of providing needed support for
systems engineering to ensure that 21st
century warfighters successfully perform
their mission. �
Engineering
Perspective
Randy Case
Technical Area
Director,Raytheon
Architectures
and Systems
Integration
I was hired in 1977 by E-Systems as a software
developer. As a kid fresh out of school with an
electrical engineering degree and a lot of computer
science (almost a double major), they
thought that I would be a good fit for developing
the real-time controller in a fairly large system
that was mostly near-real-time. When asked
to explain my design, I drew it out on a chalkboard
— and it looked like a series of digital signals
with the command points noted. It ran on a
1975-era HP minicomputer that I had to bootstrap
load with a spool of paper tape before it
would talk to the mainframe and I could download
my code into it. While my somewhat
“spaghetti” code worked well, it proved to me
that my talents should be put to different use
than the development of software. I moved on to
systems and systems architecture.
Today, when I contrast it to 25 years ago, things
are quite a bit different. We are attempting to
build very large systems using robust tools and
processes. The software for DD(X), for example, is
over 10 times the size of the first program I
worked on in Equivalent Lines Of Code (ELOC),
and is coded in higher level languages (instead
of mostly assembly) — over two orders of magnitude
larger. A major difference between my
first program and DD(X) is that the sailors on a
DD(X) ship are trusting their lives to that software
— which adds greatly to the requirements
for performance, quality and robustness of both
the delivered software and the methods used to
develop it. The functional differences are just as
incredible — we now have cognitive computing,
exemplified by the application of DARPA’s
“grand challenge.” We once wondered if a computer
could beat a chess master… now we are
creating independent vehicles that can cross a
rugged desert (even if none finished it). The technology
available to me as a systems architect is
almost beyond belief — look at some of the past
issues of technology today to see what I am
talking about.
But that advance in technology also gives our
customers and us, as Raytheon employees, a
much bigger challenge. The solutions to the
problems that our customers have, that are
partly due to these advances, are very complex.
That says that we must create solutions that
span system and enterprise sizes that were
almost unsolvable a couple of decades ago
(well, NASA did create the space program in the
1960’s, which formed the basis for the processes
and tools that we use today). I believe that the
collection of techniques and capabilities
described in this issue are critical to our ability to
solve problems for our customers. Our customers
can trust Raytheon to deliver solutions.
19

The Raytheon Enterprise
Architecture Process (REAP)
The U.S. Government has clearly established
their direction and expectations for
the way in which complex future systems
will be developed and integrated —
through architecture. There is an everincreasing
emphasis on the importance of
both formalized and enterprise architecture.
Our customers’ expectations, requirements
and evaluations continue to emphasize this
new aspect of the engineering process.
Our competitors are now developing and
maturing their own architecting processes.
Government, industry and academia have
established consortia, certification programs,
and graduate curriculum to
address the educational needs of this
new discipline.
The Office of Management and Budget is
mandating that Departments and Agencies
define and/or describe their own enterprise
architectures, an act which dictates the
need for the lower-level architectures of the
systems these Departments procure.
Reference models now being released
through the Federal Enterprise Architecture
Program Management Office further the
goals of the President’s Management
Agenda. Architecture is an invaluable asset
to all complex systems, but is perceived as
especially critical in the areas of DoD
Transformation, Homeland Security and
Federal IT.
The Raytheon Enterprise Architecture
Process (REAP) is a systems architecting
process that addresses both the needs of
our customers and of Raytheon as a System
Integrator. It extends a traditional focus on
technical architecture to also include business
architecture, providing a comprehensive
view across the enterprise. The REAP
defines an end-to-end architecture process
based on industry and government standards,
including The Open Group
Architecture Framework (TOGAF),
C4ISR/Department of Defense Architecture
Framework, Zachman Framework for
Enterprise Architecture, and the Software
Engineering Institute’s Architecture Tradeoff
Analysis Method SM .
20
Our Competition
Open systems architectures and architecting
methodology are key focus areas of our
major competitors. Lockheed-Martin leads
the way with trademarked and marketed
processes in Architecture-Based Design TM
and ARQuest TM Blueprint. Northrop-
Grumman has their Information Systems
Architecture Analysis Continuum (ISAAC).
IBM has the Enterprise Architecture Method
(EAM). Boeing and General Dynamics promote
their open systems architecture
frameworks, Bold Stroke and OpenWings,
respectively.
We need to make sure that our competitors
don’t get ahead of us in the area of
Architecture Certifications. The 2002 inaugural
class of the new Federal Enterprise
Architecture Certification (FEAC) Institute
contained a number of Lockheed-Martin
employees who completed this rigorous
certification to become certified DoD
Enterprise Architects. Other graduates
include employees from BAE Systems
and Boeing. The Software Engineering
Institute recently established new certification
programs for Software Architects
and ATAM SM Evaluators. Boeing had representatives
in these early courses with a
plan to establish a company-wide resource
pool for ATAM SM evaluators to support
architecture assessments.
The REAP, sponsored by Raytheon’s Systems
Engineering & Technology Council, has
been base-lined as a company-wide process
enabler within Raytheon’s Integrated
Product Development System (IPDS). The
REAP initiative is being approached as a
One Company standard methodology to
address architecture definition, description,
evolution, and assessment throughout
Raytheon. The REAP, and its supporting
reference documents, can be accessed
through Raytheon DocuShare Collection-
31835.
REAP Activities. The REAP is comprised
of five primary activities: Enterprise
Understanding, Architecture Planning,
Business Architecting, Technical Architecting
and Architecture Validation. The REAP activities
are iterative in nature, internally and
externally to one another.
The five REAP activities act as a wrapper
around the phases of TOGAF’s Architecture
Development Method (ADM), providing
supplemental guidance and describing its
relationships to other standards. REAP subprocesses
extending the TOGAF ADM
include those for customer-focused architecting,
quality attribute analysis, architectureconcordance/configuration/consolidation,
DoDAF product generation, ATAM SM ,
and quality attribute assessments.
The completion of these activities results in
a validated architecture package describing
the enterprise from a variety of viewpoints
or perspectives.
Background
The evolution of formal architecting
methods and descriptions within the systems
engineering of complex enterprises
can easily be traced back a decade. The
Department of Defense initiated several
studies in the early 1990s to determine
how to ensure interoperable and cost-effect
military systems. The Defense Science Board
concluded that one key element to achieving
this goal was to “…establish comprehensive
architectural guidance for all
of DoD”.”
REAP Overview
Developing An Architecting Process. Several
key components were identified as being

equired for a robust systems architecting
process:
• methodology the detailed step-bystep
approach on how to develop
an architecture
• products the architectural models
developed to describe the architecture
from a variety of viewpoints
• formats the syntax or modeling
guidelines of the architectural products
• validation a formal review of the
architecture prior to its implementation
• collaboration guidance on how the
architect and architecture team
interact with each other and other
stakeholders
REAP Components. Established industry
and government standards help address
enterprise-wide architectural alignment
between customer mission, business rules,
data, application systems, organization,
and technology. The primary standards
unified within the REAP to fulfill these
components are:
• methodology The Open Group
Architecture Framework (TOGAF),
Enterprise Edition
• products Department of Defense
Architecture Framework (DoDAF),
final draft;
Zachman Framework for Enterprise
Architecture
• formats Unified Modeling
Language (UML), Integrated
Computer-Aided Manufacturing
Definition (IDEF), DoDAF templates
• validation Software Engineering
Institute’s Architecture Tradeoff
Analysis Method (ATAMSM)
The collaboration component of the REAP
is based on heuristics from the software
architecture team model which was
deployed in 1997 at Raytheon’s Garland,
Texas site. This model has been successfully
deployed on a variety of programs
(small and large, single and multi-company,
local and geographically dispersed).
It is important to note that although there
are several “frameworks” integrated within
the REAP, they each address very different
elements of the overall architecting
process and their interrelation is necessary
and complementary.
REAP Deployment. While the REAP is initially
being deployed across Raytheon
businesses, real institutionalization cannot
occur until a formal rollout is deployed
across the Businesses. Internal training
courses are being created in conjunction
with rollout plans. The REAP is undergoing
maturation to address identified gaps and
to incorporate the early lessons learned of
these first deployments.
Summary
The REAP initiative provides a standardized,
repeatable approach to enterprise
architecting for architecture definition,
description, evolution, and assessment
throughout Raytheon. It integrates established
industry and government standards
to support enterprise-wide alignment
between customer mission, business rules,
data, application systems, organization
and technology. It has been baselined
within IPDS and is available throughout
Raytheon.
Ongoing REAP deployments and process
maturation through research, collaboration,
and lessons learned will enable
Raytheon business areas to better address
our customer’s architecture expectations
and allow us to share our own architectural
solutions with one another through
common taxonomy and representation.
Future plans include the creation of product
line architecture templates to provide
architecture teams with a stronger foundation
for how to best approach their
architecting efforts. �
Goal
The primary goal of the REAP initiative is to
develop and mature a standardized, repeatable
systems architecting process that:
• supports integration of our customers’
diverse legacy and future
systems
• supplements our current IPDS architecting
task descriptors with needed
additional detail
• aligns with Federal Enterprise
Architecture (FEA) guidelines/
requirements
• improves system quality
• promotes consistency across Raytheon
• facilitates change management and
decision-making
• enables reuse of architectural solutions
between and within Raytheon
Business Areas
• provides a foundation for future
development of Product Line
Architecture templates
Strategies
The REAP development team identified the
following strategies as key elements to be
addressed during the creation of this systems
architecting process. It was determined
that the REAP should:
• be standards-based (both industry
and government)
• integrate enterprise architecting practices
with systems architecting
• ensure alignment with secure, open
systems development
Additional objectives to complement the
development of a formalized architecting
process include:
• defining a tool standard (perhaps
vendor alliance)
• active involvement/leadership within
Industry Standards bodies in the
architecture arena
• achieving key certifications
(FEAC, SEI)
• external REAP communications (marketing
our expertise)
21

Systems Integration Using Modeling
There are many different reasons to perform
modeling and simulation — in realtime
simulations (e.g., a flight simulator),
training, visualizing a product (as a prototype
or mock-up), or algorithm analysis.
This article will feature two system integration
activities — predictive system modeling,
where the goal is to determine how
the system should work, and performance
modeling, which verifies that the system
being developed will perform as expected.
Predictive System Modeling
Raytheon supports integration and test
activities based on the simulate-emulatevalidate
philosophy facilitated through the
application and execution of electronic
Systems Integration Labs (SIL). This
approach ensures effective integration of
test articles, such as ground sensors integrated
into functional platform suites, while
exposing the sensor and platform integrators
to the minimum possible schedule risk.
A key aspect of this approach uses models
and simulations of individual and combined
sensor systems and its underlying communications
infrastructure (executed on both a
stand-alone basis and in the context of a
complex operational environment). This
simulation step in the systems integration
process provides testers with predictive
analysis on system or subsystem functional
performance prior to expensive emulator
and hardware integration. As a result,
issues are identified early, while minimizing
the impact to the system development and
integration flow.
Each stage of the integration plan is designed
to leverage the success achieved by previous
efforts, to ensure that progressing levels of
system integration become less complicated
and produce fewer unexpected results.
A typical M&S architecture for the SIL
(shown in Figure 1) requires a test article
common modeling approach that includes
design characteristics, performance parameters,
functional characteristics, platform
interface characteristics, communications
links and requirements, environment features,
and a three-dimensional mechanical
model. Individual models must also have a
common interface (e.g., High Level
22
Figure 1. Functional simulation lay employed within a typical Raytheon Systems Integration Lab.
Architecture (HLA)-compliant Federation
Object Model guidelines) and should follow
the data requirements specified by a common
virtual framework (e.g., the OneSAF
Test Bed used for ground combat exercises,
demonstrations, and training). The integrator
may also require building functional,
performance, and logical federate that
characterize integrated system behavior,
(e.g., ground sensor suites on an individual
platform). This “systems integration”
federate describes the combined functional
threads and key interfaces that enable
testing and evaluation of sensor grid
characteristics among shared assets at
higher levels of integration.
Through the SIL test director workstation,
scenario and simulation controls are maintained
to provide use case controls for the
simulation execution. The test director may
also employ an Operator Control Console
surrogate to enable human-in-the-loop
interaction that supports testing and functional
verification at an operational level.
As the SIL matures and testing becomes
necessary to address function interfaces
with other system components, the individual
simulations evolve into sensor emulators.
This enables higher fidelity integration
within the SIL.
Emulators must communicate with the system
under test via the interface methods
planned for the actual system, and must
adhere to the interface message formats
identified by the system ICDs. However, the
SIL will continue to employ the individual
sensor models and the GSS functional mod-
els to provide sensor interoperability when
emulators are unavailable, enabling GSS SIL
to perform distributed interoperability testing
with higher level SILs, and providing a
functional interface for hardware-in-theloop
testing during the later phases of sensor
integration.
Performance Modeling and
Assessment
Raytheon has performed verification using
system models for over 20 years. Large
complex systems (2M LOC and bigger), in
most cases, cannot dedicate the standalone
test time to test all variations of the
system performance requirements. This is
especially true when the external inputs
driving the system are, at best, speculative.
In systems of this nature, the models are
built from smaller models that simulate the
subsystems (that simulate the components).
These typically discrete event models are
maintained within a library. To verify and
validate a system via modeling and simulation,
the model must first be verified, validated
and accredited. One way to do this is
to verify each subsystem model by comparing
its results with the actual hardware. The
analysis of the long-term performance of
the system is made using the verified
model. This analysis is then used to “sell
off” those requirements.
At Raytheon, we see the future for this type
of modeling and simulation as Simulation-
Based Acquisition (SBA), where the demonstration
of capabilities, expected characteristics
and performance can be made before
the system is built. �

An interview with Dr. Andries van Dam,
Vice President for Research, Brown University; and Thomas J. Watson Jr., Professor of
Technology and Education and Professor of Computer Science
Recently, Dr. Andries van Dam and Thomas
J. Watson Jr. met with Lou DiPalma, senior
manager leading the Integrated Warfare
and Sensor Systems Software CPT for
Integrated Defense Systems (IDS)
(Integrated Software Development and
Human Systems Integration Engineering
CPT) for an interview during which Dr. van
Dam provided his insight on a range of
Software/Systems Engineering related topics
as well as the challenges facing the field.
He begins the interview by talking about
Extreme Programming, an alternate
methodology for Software (SW)
Development based on a peer team concept
with the idea of rapid product delivery.
Throughout the interview he provides
insight into Software Development challenges
and how Extreme Programming may
be the next Disruptive Technology that will
significantly change the industry.
Q What do you see as a Disruptive
Technology associated with the development
of software?
A Extreme Programming holds potential
promise as the next Disruptive Technology
associated with SW Development. We’re
still primarily doing top-down design,
spending a considerable amount of time
up-front doing SW design.
Rapid Application Development (RAD) is
being taken to the nth degree in Extreme
Programming. With RAD there are no initial
requirement specifications, no top-down
design. The requirements and design artifacts
are produced after-the-fact to capture
what has been developed. This technique
has successfully been employed in the
development of User Interfaces (UI). The
focus with UI development is to get the UI
out in front of the user early and often in
order to capture the users’ feedback and
fold that back into the next iteration for
release to the user. The objective is to do
usability testing with the prospective end users.
At Brown, I teach a Rapid Prototype Design
and Development course where I found it
to be effective. We certainly need to determine
the applicability of this approach in
other areas. I believe it is critical to determine
a strategy as to when and where
Extreme Programming is applicable and
under what circumstances. With regards to
Real-Time (RT) Systems, I’m not certain it
might ever be appropriate.
Q What do you see as one of the many
challenges facing Software Development?
A Today we are still struggling with SW
development processes and their use, even
with the extensive use of sophisticated
tools. I see the glass as both half full and
half empty. We’ve been monitoring the productivity
we’re achieving associated with
the amount of lines of code being developed,
including the extensive use of sophisticated
tools and environments, like Visual
C++, etc. including the use of templates
and object class libraries. Even with all the
reusability we have not achieved an OoM
(Order of Magnitude) of two OoM in productivity
since these processes began to be
monitored two decades ago.
Q Are there other challenges you see
facing software development?
A Yes — the increased complexity of the
systems we’re required to develop. Software
development has not significantly changed
over the last 20 years. How we build systems
the customer wants with all the appropriate
“ilities” has certainly increased in complexity.
The time and cost of development has
increased. Additionally, as the complexity
has increased, so have the continued overruns
and delayed deliveries. What’s needed
is a more effective way to manage the SW
development; similar to the way HW development
is managed. For instance, the
Graphics Industry continues to develop
systems of significant complexity with an
appropriate set of tools and quality.
The SW development lifecycle is not as disciplined
as that of the HW design. One
approach to effecting a behavior/cultural
change is to maintain and instill a focus and
intensity at the collegiate level about the
importance and criticality of meeting schedules
with appropriate penalties for not meeting
deadlines. Delivery on time is instilled
from the very beginning. The mindset needs
to be shaped to be certain that the appropriate
behavior is realized. It’s not just good
enough to get the job done; time and quality
are critical. We must manage complexity, not
just code size, especially with the systems in
our distributing computing world.
Q Speaking of complexity and the
distributed computing challenge, can you
elaborate on the topic?
A In our current collegiate educational
systems, graduates have a few courses on
distributed computing at best — education
in this area is definitely limited. While students
are in college, they may be introduced to distributed
computing and parallel systems
development, but little is done to indoctrinate
them with the critical verification and
validation component; though the tide is
clearly changing. Similarly, while there is
some exposure to operating systems, students
get little to no exposure to Real-Time
(RT) systems requirements and their development
needs. Very rarely are students
introduced to the hard and soft real-time
system requirements of the kinds of systems
Raytheon Company is responsible for building
and delivering to the warfighter.
The real-time dimension of these systems
definitely adds to the complexity. Employers
are forced to provide this needed training.
At times, this is gained via OJT (On-the-Job
Training, whereby things are left to chance.
It may be appropriate to adjust our collegiate
educational experience for Computer
Engineers and Computer Scientists requiring
them to successfully complete a 5-year
degree program in order to graduate, possibly
receiving a masters’ degree at graduation.
Included in this program of study,
would be a required, degree-related project,
of significant proportion. Our educational
system is not fundamentally adequate to
address the technical, political, educational,
social and financial challenges of today and
tomorrow’s system needs.
Q An increasing number of companies
are looking at outsourcing as a means of
meeting their engineering staffing
demands. Engineering outsourcing is another
challenge facing today’s employers and
their systems development needs.
Continued on page 24
23

VAN DAM INTERVIEW
24
Continued from page 23
A There is a saying that goes like this,
“When you develop critical SW out-ofhouse,
you get out-house results.” The key
here being critical. Employers need to get a
better handle on the management of distributed
teams that continues to plague
project managers in systems development
even within the confines of their own company.
The outsourcing of SW development
to overseas firms, where the communication,
background and vernacular is strained and
severely limited, further exacerbates this.
Higher-educational systems and professional
training organizations can assist in filling
the void and closing the communication
and cultural divides. But there is a potential
for this to escalate to being a horrendous
problem where “out-house” results will
unfortunately be realized. We must accept
that outsourcing is here to stay, including
outsourcing overseas. It is critical that outsourcing
be successful, especially given its
criticality to the survival of the foreign companies
and their supporting culture. We
need to develop better techniques and
approaches to secure successful results that
are mutually beneficially to all involved.
Q Following up on your comments and
concerns associated with the increasing
complexity of today’s and tomorrow’s systems,
can you expand on the concept of
developing reliable software?
A Fielded systems are exposed to all
kinds of external problems. The potential
exists for our systems to be infected by
viruses, time bombs, and the like of which
are not yet known, and for which the existing
virus eradication programs are no
match. We’re in a fool’s paradise if we
don’t address this in earnest today. Cyberterrorism
is a critical challenge we must
tackle head-on in order to have an impact.
The cost to the economy for an attack is
immeasurable. We haven’t yet seen the
extent and severity of such an attack to a
critical component of the U.S. Infrastructure
or national DoD asset. There are technical,
political, educational, social and financial
challenges that must be addressed in order
to realize a process for safeguarding our
development processes. Safeguarding our
systems must be engineered-in and not
engineered after the fact. �
Leadership Perspective
PETER PAO
Vice President of
Technology
Systems and
Software
Engineering and
Mission System
Integration
As our customers are transforming into the
Network Centric Operation era, the integration of
information and systems becomes one of the most
challenging tasks. Mission System Integration (MSI)
is at the heart of the solution. It is critical to our
nation’s ability to defend itself. At Raytheon, we
have the required domain knowledge and integration
expertise to succeed in this market. MSI is a
growing business opportunity for us and an important
part of our growth strategy.
Recently, a small internal team conducted a study
on Raytheon’s capabilities for pursuing the MSI
business. The team identified our strengths as well
as areas that needed improvement. Here are their
findings and the actions we are taking in Engineering
and Technology to move forward on this path:
1. The key to the MSI business is systems engineering
capability, especially architecture and
modeling & simulation.
2. Common mistakes are:
•Misunderstanding customers’ needs
•Late system engineering and architecture
participation
•Inconsistent architecture skills, methodologies
and applications
I believe they are right on target. Technology is
important to all of our programs but, in MSI, the
key discriminators are system engineering and
architecture capabilities. Architecture is not only the
blueprint of how parts are put together to form a
system, it is also the recipe on how the system is to
be operated throughout its life. A good architecture
needs to meet the customer’s immediate requirements.
It also needs to address their future challenges,
such as requirement changes and technology
migrations. This can only be achieved by working
with our customers from the very beginning and
gaining a thorough understanding of their problems
and constraints.
In the last ten years, major progress has been made
in architecture. A common accepted definition and
methodology has emerged. It is gradually becoming
an engineering discipline. We need to establish a
company-wide architecture methodology and apply
it in all of our programs. This will enable us to
speak the same language, enhance our communications
so they are clear and concise, and learn from
our experiences so we can continually improve our
architecture processes and skills.
CMMI® has been one of our focuses to improve
our system engineering capabilities, and we are
doing well. Most, if not all, of our businesses have
achieved CMMI Level 3. Some businesses are even
at Level 5. We need to continue this journey.
To this end, I am pleased to announce a four-column
“MSI Initiative,” which focuses on Architecture
and Modeling & Simulations. The four columns are:
Modeling & Simulation (M&S) — M&S is an
effective tool to communicate with our customers.
We use it to help us understand their problems, and
to try out candidate solutions. A company-wide
M&S framework has been developed to assure
reuse and interoperability for all the M&S tools we
have built throughout the company.
Reference Architecture — We need to develop
reference architecture for our Strategic Business
Areas (SBAs), including Network Centric Operations
and our major product lines, such as service radars,
airborne radars and air-to-air missiles. These reference
architectures guide our individual program
pursuits and product/technology developments.
With these common frameworks, our programs and
products will be interoperable and synergistic. Only
then can we talk about meaningful product and
technology reuse.
Process and Tools — Combining DoDAF,
Zachman, TOGAF and ATAM, we have developed a
company-wide architecture process called Raytheon
Enterprise Architecture Process (REAP). We must all
use it. I agree that today’s REAP still needs work,
but I believe, as in most everything we do, there is
always room for improvement. Only through using
REAP can we can make it the best in the industry.
Only by using the same process can we can pool
our resources to build an effective toolset.
People — We are developing a set of system engineering
and architecture training classes, such as
the System Engineering Technical Development
Program (SETDP). For architecture, we will have an
introduction course, an advanced course and an
architect certification program for accomplished
Raytheon architects. You are our greatest asset, and
we are committed to developing your skills.
You will find that much of this issue of technology
today is dedicated to discussing these four topics in
detail. Systems engineering, architecture, and modeling
and simulation are core competencies we
must possess to grow our business and meet our
customers’ future challenges. Our people are what will
pull it all together and, in turn, enable our success.
I strongly urge you to participate in the MSI
Initiative. Take the challenge and support our efforts
in becoming an integrator of mission solutions.

DESIGN FOR SIX SIGMA -
CRITICAL PARAMETERS MANAGEMENT –
DESIGNING WHAT THE CUSTOMER WANTS
Integrated Defense Systems (IDS) is proactively
and aggressively using Design for Six
Sigma (DFSS) as an important new method
of managing the performance parameters
most important to our customers. Since
many engineers don’t have frequent contact
with customers, how can they ensure
that their designs really meet customer
needs? Skip Creveling, author of Design for
Six Sigma in Technology and Product
Development states: “Few things focus a
team on the most important customer
needs, product requirements, design
parameters, performance metrics and deliverables
for a product’s success better than
Critical Parameter Management (CPM)”.
What is CPM? How does it relate to DFSS?
CPM is the process of defining and managing
the performance parameters most
important to the customer in a predictive,
proactive and robust manner.
Design for Six Sigma focuses on improving
product cost and performance, driven by
customer needs. The three areas of DFSS
are Affordability, Producibility and
Performance. Affordability includes Cost As
an Independent Variable (CAIV), Life Cycle
Costs (LCC) and Design to Cost (DTC) to
ensure that the customer’s short and longterm
cost requirements are met. The
Producibility area emphasizes Design for
Manufacturing and Assembly (DFMA) principles,
statistical tolerance allocation and
other methods to ensure the design can be
produced with no “surprises”. The
Performance area focuses on determining
the performance goals the customer needs
and then robustly designing a product to
meet those goals. The key to success is
actively managing all three areas in an
integrated fashion. How is that done?
Typically, performance, producibility and
affordability are managed by different
processes, databases, tools and people. The
skill sets and information needed in each
area are different. The challenge of DFSS is
not to have a common skill set for all engineers,
but to integrate the knowledge and
information from these three areas. All
DFSS areas have the same focal point —
the customer. Everyone must be aligned
with the customer’s needs, concerns and
desires. But how can an engineer designing
a component for a subsystem in a system
that is integrated with other systems know
what the customer wants? CPM is a
robust, structured method that helps us
understand and actively manage the relationship
of lower level design parameters
to customer needs.
Critical Parameters, called Key Performance
Parameters (KPP) in IPDS, are the performance
parameters that are most important
to the customer. The Department of
Defense states, “A key performance
parameter is that capability or characteristic
so significant that failure to meet the
threshold can cause the concept or system
selection to be reevaluated or the program
to be reassessed or terminated” (DoD
Integrated Product and
Process Development
Handbook). The first
step is asking the
right questions
and listening to the
customer.
Once the KPPs are defined, they must be
managed to ensure customer success,
which implies oversight, organization and
reporting. CPM includes all these aspects,
and is referenced in IPDS as a method for
managing KPPs. The deliverables of CPM
are the “root causes”, the Key Product
Characteristics (KPC), that affect the KPPs.
Transfer functions define the quantitative
or mathematical relationship between a
KPP and the KPCs. Also, defining the KPCs
by probability distributions enables statistical
prediction of the performance of these
KPPs most important to the customer.
In IDS, the selected CPM tool is the Six
Sigma Cockpit® from Cognition
Corporation. This tool provides CPM functions
and also generates the functional performance
tree from the QFD. A good cost
model is critical, and ideally would be
linked to performance and producibility
models. IDS is working with Cognition to
develop this linkage between the cost
model tool, Enterprise Cost
Management®, used for CAIV and the
performance/producibility model tool, Six
Sigma Cockpit®. CPM can highlight supplier
components that do not have robust,
predictive performance data, and other
components that do have easily-defined
transfer functions. If the performance of a
component or subsystem drives customer
satisfaction, we must know how it affects
the customer, and how much it varies.
Without this understanding, customer success
is not ensured. CPM is a structured
way to help ensure all the bases are covered,
and in the words of Skip Creveling,
“CPM lies at the heart of DFSS… The data
it produces is the lifeblood of DFSS.”
- Wayne Risas, Rich Schiele
25

Raytheon 3rd Annual
Joint Systems and Software
Engineering Symposium
More than 500 engineers, technologists
and leaders from around the company
participated in Raytheon’s 3rd Joint Systems
and Software Engineering Symposium hosted
by the El Segundo, Calif. site on March 22-
25, 2004. The symposium allows engineers
from across the country to share technology
and lessons learned, and provides myriad
face-to-face networking opportunities.
This year’s co-chairs were Yann Shen and
Mark Hama from El Segundo, and Ken
Davidson from the Fall Church, Va. site.
Planning for this event is a year-long activity.
Over 150 presentations, eight panels and
many tutorials were offered through a format
of six concurrent tracks. The presentations
were selected from over 370 abstracts
submitted by the 30-member One
Company committee in October 2003. The
30 tracks spanned topics such as intelligent
systems, architecture, reuse, requirements,
information technology and object oriented
technology. Birds of a Feather sessions were
26
structured to allow for additional in-depth
discussion of key subjects. This year, the
event included additional tutorial sessions
which were well-received
and attended.
Greg Shelton, vice president
of Engineering, Technology,
Manufacturing and Quality;
Jack Kelble, President of
Space and Airborne Systems;
and Peter Pao, vice president
of Technology, were the
Raytheon keynote speakers.
Mike Devlin, president of Rational (purchased
by IBM), and Gary Rancourt, IBM’s
Raytheon Business Development Executive,
were the industry keynote speakers, and
Joseph Horvath from the DD(X) program
was the customer keynote speaker.
Greg Shelton focused on Raytheon’s 2003
successes with strong bookings and cash
flow, and provided an overview of the company
strategy and our role as a mission systems
integrator. He spoke about the need
for lead systems engineers and architects —
including a new two-year System
Engineering Leadership Development
Program that will launched this spring.
Jack Kelble shared four predictions for the
next few years:
• Increased Open Architecture, more plugand-play.
• Reverse the pendulum to fewer
Integrated Product Teams because it pulls
folks from interfacing with their peers.
• Raytheon’s profits will increase due to
growth and expanded opportunities.
• The chasm between Software and
Systems Engineering — Jack offered his
experience with merging the SE and SW
organizations to compel them to work
together.
Peter Pao explained the accelerating growth
in Missions Systems Integration and Large
Scale Integration programs. The key discriminators
are capabilities, not technology
— a paradigm shift. Modeling and
Simulation is now designated as one of the
four major pillars of software and systems
engineering.
Mike Devlin spoke of the tools they have
developed and their next thrust into the IT
market.
Gary Rancourt discussed the Raytheon-IBM
Strategic Alliance Agreement. This alliance
has been formed with the goal of increasing
opportunities through growth over five
years and includes access to IBM’s R&D.
Joe Horvath gave a superb talk, lauding
Raytheon and the relationships we have
built together with the Navy based on trust.
You can access all of the presentations from
the 2004 symposium at http://home.ray.
com/rayeng/technetworks/tab6/se_sw2
004/presentations.htm.
Planning for the 2005 4th annual joint
Systems and Software symposium has
already begun. If you are interested in
joining the committee and being part of
this event, contact Ken Davidson at
kdavidson@raytheon.com.
2004 Best Papers Awards were presented to:
Steve Saunders for “Reducing Project
Re-Work By The Use of Model Based Systems
Engineering Processes and Tools”
Rob Raposo and Russ Ellsworth for
“Resolving Intermittent Failures:
A Disciplined Approach”

Capability Maturity Model Integration (CMMI)
ACCOMPLISHMENTS
Raytheon Closes 2003 with More
Successful CMMI® Appraisals
Raytheon completed successful Capability
Maturity Model Integration (CMMI) Level 5
and Level 3 appraisals in California,
Massachusetts, Rhode Island and Texas.
The NCS Northeast Engineering team
attained CMMI Level 3 in systems engineering
and Level 5 in software engineering
after completing a three week SCAMPI
in December. This detailed evaluation of
our engineering capabilities focused on the
DD(X), ACM, SMART-T AEHF, STARS and
VATCAS programs, and also included the
support of program office, configuration
management, supply chain and quality personnel.
The evaluation involved a detailed
review of how well the CMMI model has
been institutionalized and was supported
by detailed interviews by the appraisers
with over 100 employees. Our success
demonstrates the outstanding collaboration
of the talented people in Marlboro and is a
tremendous accomplishment for all of the
NCS Northeast employees. Bob Eckel, vice
president of Air Traffic Management
Systems, Brian McKeon, vice president of
Command and Control Systems and Jerry
Powlen, vice president of Integrated
Communication Systems, offered their
congratulations to everyone on the team.
The Raytheon Fullerton Operations of
Network Centric Systems attained CMMI
Level 5 for software engineering and Level 3
for systems engineering in December. The
ratings are a significant achievement, since
only 20 percent of organizations appraised
have attained CMMI Level 5, according to
the Software Engineering Institute.
The accomplishment involved a significant
portion of the Fullerton organization. Wide
Area Augmentation System (WAAS),
Enhanced Position Location Reporting
System (EPLRS) and Destroyer (Experimental)
DD(X) were the focus programs for the
appraisal. Members of quality assurance,
configuration management, supply chain
management and program management
processes also participated in preparation
and interviews. The Engineering Process
Group led by Dennis Laiola and Amy
Donohue coordinated the effort. Jim
Kashiwada and Jeff Rold were the sponsors.
The synergy between systems and software
disciplines in Fullerton is evidenced by the
use of a common core set of procedures
shared by both disciplines. Using common
procedures is efficient for procedure development,
tailoring, deployment and
improvement activities. The systems area
has already adopted many of the higher
maturity practices. In fact, systems engineering
at Fullerton satisfied all the CMMI
process areas through Level 5 with the
exception of one area in Level 4.
Raytheon’s Space and Airborne
Systems (SAS) business concluded a
successful Level 3 appraisal of its
software and systems engineering
capabilities in November 2003. The
appraisal included various sites
located in southern California.
The SAS California appraisal was not
just geographically challenging, but it
was also a challenge in terms of the
number of business areas included inscope.
The appraised programs involved
were from five different product lines within
SAS and over $800 million in business.
One of them was in a classified area. The
programs appraised were F-18 AESA,
ASTOR, APL-5, F-15 Suite 5, and B2. This
challenging scope made the SAS California
appraisal a significant task, not to mention
the tremendous effort required to prepare.
From mid-2002 through the conclusion of
the appraisal, over 300 people worked on
teams that accomplished the goal.
With the SAS California appraisal, all sites
in SAS have been appraised at a CMM
Level 3 or higher. The California SAS
appraisal is one of the largest (in terms of
in-scope engineering population) reported
to the Software Engineering Institute.
The last issue of technology today
described the innovative approaches taken
by the NCS/SAS North Texas sites during
their recent achievement of CMMI Level 5
software capability appraisal. These same
North Texas sites were separately appraised
at a system engineering Level 3 in
December 2003.
The CMMI maturity levels are increasingly
used by government agencies and contractors
to evaluate the potential for organiza-
Top to Bottom: SAS Enterprise Process Group
(EPG), NCS Fullerton CMMI Team, NCS Northeast
Engineering CMMI Team
tions to produce quality products within
cost and schedule. The integrated maturity
ratings, covering critical engineering disciplines,
indicate an organization’s ability to
provide predictable quality while managing
and controlling project risks to meet commitments.
The major benefits of a mature
organization are the ability to quantitatively
control and make improvements to the
engineering processes, to predict the
expected results of selected processes, and
to improve product quality while reducing
cost. Other benefits include synergy within
the organization to mature other engineering
disciplines in a shorter time.
Nancy Fleischer, Jeff Rold, Dan Nash
®CMMI is registered in the U.S. Patent and Trademark Office by
Carnegie Mellon University.
27

Major IPDS Upgrades
Deployment Expert Training and Process Asset Library
The Integrated Product Development
System (IPDS) contains processes, training,
reference material and tools (enablers)
which define the way that Raytheon does
business. The IPDS Team, working within
the Raytheon Engineering Common
Program (RECP), recently deployed major
upgrades to the training and enabler portions
of the system. Mark Warner of
Intelligence and Information Systems (IIS),
Aurora, Colo., and his Deployment Network
Steering Group have revamped, piloted and
formally deployed a 3 day IPDS Deployment
Expert Training Workshop. Steve Clark of
Integrated Defense Systems (IDS), Bedford,
Mass. and the Process Asset Library (PAL)
team are currently populating an IPDS PAL
that gives users easy access to local (site
and business) enablers.
Deployment Expert Training
A team of Raytheon’s most experienced
Deployment Experts developed a new threeday
IDPS Deployment Expert (DE) Training
Workshop in 2003. They piloted the workshop
in Vienna, Va. last fall. El Segundo,
Calif. hosted a second class in January of
this year. The course materials were released
with IPDS version 2.2.3 in November. The
major goal of having this enterprise-level
training is to ensure competency and reduce
the variability of deployment expertise by
ensuring that all candidates receive training
in deployment techniques and enablers that
have evolved over the past 5 years. Other
goals were to provide an interesting and
effective learning experience for the participants,
and to improve the value quotient
for program teams engaging with IPDS.
Lee Belisle of IIS, Aurora, and the IPDS DE
training sub-team used Raytheon Six
Sigma TM techniques to compile feedback
from students, instructors, and DE clients to
improve the training workshop. Participant
surveys determined the effectiveness of
each module in achieving the desired objective.
Interviews with instructors, program
leadership personnel, and feedback from a
Six Sigma project, conducted by the
Raytheon Learning Institute, provided input
for the voice of the customer. Desirable
and Undesirable Effects were defined and
gaps between the training material and the
DE competency model were identified. The
team then conducted a Pareto analysis to
28
identify areas where maximum improvement
could be realized.
The concerns that surfaced included material
redundancy, long presentation periods
and more theory than application.
Addressing the higher-priority needs resulted
in an updated, more concise presentation
package with additional businessfocused
exercises that progressively build on
one another and provide more hands-on
opportunities to work with the tools.
Mark Warner, Rob Sawyer (IIS Garland,
Texas) and Sean Conley (Raytheon Technical
Services Company LLC, Indianapolis, Ind.)
piloted the approach featuring these
improvements in Vienna last September.
The pilot featured exercises that were structured
around a recent program pursuit specific
to that business environment. Program
personnel added realism to the experience
by supporting the exercises.
Participant feedback was collected over
shorter-than-usual intervals (half-day increments)
in order to capture a more granular
response to the course under construction.
While the initial pilot revealed some timing
imperfections, feedback indicated that the
students in general responded favorably to
the improvements. Feedback and lessons
learned from the pilot were integrated into
the course material and the resulting package
was published with the November
release of IPDS. Nineteen students attended
the second training session this past January
in El Segundo. The next DE Training course is
planned for Garland during the second week
in March, and RECP will conduct additional
workshops to meet demand (approximately
once each quarter). Consult the Deployment
section of IPDS for further info.
Process Asset Library
The IPDS Process Asset Library (PAL) is an
enterprise-wide asset library incorporated
into IPDS. The PAL responds to the requirement
that IPDS integrate and provide easy
access to best practices across Raytheon
businesses. It provides the capability to submit
and/or retrieve IPDS and local site
assets. The IPDS PAL is easily accessed from
the “IPDS PAL” tab on the IPDS homepage:
http://ipds.msd.ray.com/Current/.
The main objective of the IPDS PAL is to
provide a common repository of assets for
businesses and sites in order to promote the
One Company initiative while increasing
cost effectiveness and productivity. The One
Company theme is achieved through the
use of IPDS as the common framework for
asset storage. This is particularly useful for
organizations whose process structure is
based on IPDS. RECP funds PAL management
so the cost effectiveness objective is
achieved. Each business maintains local control
over its assets but does not incur the
overhead costs associated with maintenance,
control, reporting, and measurement.
By sharing process assets across the
Raytheon enterprise, productivity is
increased because each business has access
to all other sites’ assets.
RayPAL currently offers a broad range of
features and functionality. It has versatile
and easy-to- upload (asset contribution) and
download capabilities. It also has a robust
search engine that allows a user to filter his
or her search by CMMI® Process Area, site,
asset type and functional discipline. Asset
submitters can specify which group they
want to endorse their material (Engineering
Process Group, Engineering Council, etc.).
Once an asset is accepted into the library, the
user is automatically notified via e-mail. Asset
usage measures allow the PAL administrator
to report on how often specific items are
downloaded. Users can provide a review
rating (0 to 5 stars) and add comments to
the system for assets that they have downloaded.
The system maintains an average of
all ratings submitted for each asset. The rating
and comments can be viewed prior to
downloading material. Finally, a Users Guide
is available on the PAL homepage of IPDS.
The PAL is a corporate asset designed for
sharing. It provides all of the functionality
required to meet CMMI criteria: accessibility,
control, measurement, accounting and configuration
control. The RayPAL offers a consistent
format for acquiring assets across all
sites. It enhances process and enabler
improvement through ready comparisons to
other sites and is cost effective for your
organization. Falls Church, Va. is currently
using the IPDS Process Asset Library as their
site PAL. We encourage you to submit copies
of your processes and enablers and do likewise.
- John Panichelli, Mark Warner, Steve Clark

As a technology-driven company, Raytheon
places the highest value on technical excellence. Each
year, the company honors achievements in technology
within Raytheon Engineering and Technology. Individuals
and teams across the company, nation and world who
receive this award are recognized for their excellence in
technology, as well as the contribution their technology
makes to the company and society as a whole.
Recipients of this award are joined by the leadership
team, colleagues and guests as we celebrate their
remarkable achievements. This year, we are proud to
present the Excellence in Technology Awards in
Washington D.C. at the National Air and Space Museum’s
new Steven F. Udvar–Hazy Center. This new hangar-home
houses such historical air and space triumphs as the
Space Shuttle Enterprise, Enola Gay, Concorde and 135
other space vehicles. Towering 160 feet over the hangar
is The Donald D. Engen Tower air-traffic control center,
which opened December 15, 2003 on the 100th anniversary
of the Wright brothers’ first flight — thanks to a
$1 million donation and $250,000 donation in kind by
Raytheon. Paired with impressive technology achievements,
the sight is inspirational, exciting and encouraging
as we honor the past, reward the present and look
toward the future.
Raytheon is a healthy technical company and fertile
ground for new ideas and new approaches to meet
diverse business challenges. Our innovation and technology
benchmarks ensure Raytheon’s place in an increasingly
competitive world. Equally important are the ideas that
produce new products, reduce costs, improve quality and
ensure customer satisfaction. All of these ideals are represented
in the Excellence in Technology Awards. The future
is bright and, with engineers like these, we will be part of it.
Please join us in congratulating this year’s winners of the
2003 Excellence in Technology Awards.
2003 EXCELLENCE IN TECHNOLOGY AWARD WINNERS
HRL LABORATORIES, INC.
John A. Roth, Next Generation Infrared Detector Technology
INTEGRATED DEFENSE SYSTEMS
Phillip W. Thiessen, Sea Based X-Band Platform System Definition
DARPA Wide Band Gap Semiconductor Development Team
Steven Bernstein, Nicholas J. Kolias, Patricia M. Kolias,
Jerome E. Lubenau, Joseph A. Smolko
DD(X) Systems Engineering Team
William R. Desrochers, Mark J. Munkacsy, Paul E. Weeks,
Brian H. Wells, Frank L. Zupancic
INTELLIGENCE & INFORMATION SYSTEMS
Solomon A. De Picciotto, Orbital Analysis
Cube Antenna Team
Daniel L. Goulette, Robert H. Mceachern, Charles J. Mitchell,
Theresa Ann Olson, Raphael J. Welsh
DCGS ISR Architecture Team
Tunney A. Dong, Zhen-Qi Gan, Joseph L. Shivers, John M. Terry, Stephen A. Yates
INFORMATION TECHNOLOGY
Marty Tice, Excellence in leveraging the ORION Network as a
Competitive Discriminator
MISSILE SYSTEMS
Chris E. Geswender, Guided Projectiles and Strike Weapons
Marty Rupp, RF Systems Design
Multi-disciplinary Design Analysis and Optimization Capability Team
Alvin R. Balius, Jason B. Blauert, Raymond J. Spall,
Timothy T. Takahashi, Damon C. Turner
NETWORK CENTRIC SYSTEMS
John “Clay” Carson, Technical Excellence in Architecture, Sensor and
Emerging Technologies
FCS Communications Networking Team
Louise E. Borrelli, Timothy J. Hughes, Scott Seidel, Thomas E. Young
Victory Integrated Product Team
Richard Ajer, Richard E. Bornfreund, Mary J. Hewitt,
Ray Salafian, Kenton T. Veeder
RAYTHEON AIRCRAFT COMPANY
Aircraft Taxi Simulation Team
John R.E. Kollman, Deepak K. Mullick
RAYTHEON SYSTEMS LIMITED
Galileo Receiver Development Team
Peter Alan Hellen, Daniel Jan Sojkowski
RAYTHEON TECHNICAL SERVICES COMPANY LLC
Blue Force Tracking Team
Clinton D. Brock, Andrew R. Crum, Christopher J. Girard,
Rimas J. Guzalaitis, Christian P. Mcmahon
SPACE AND AIRBORNE SYSTEMS
Kirk A. Miller, Multi-spectral Targeting System Mechanical Engineering
Modular Digital EW System Integrated Product Development Team
David J. Fairfield, Douglas E. Fullmer, Mark H. Heiser,
Robert S. Loomis, Jay Y. Shu
SAR Autofocus Development Team
Michael Y. Yin, John P. Kilkelly, Rachel L. Lewis,
Helen L. Sun, Michael W. Whitt
Tile Array HTM-4 T/R/ Module Team
Alan L. Kovacs, Jerold K. Rowland, David K. Sakamoto,
Craig K. Shoda, Samuel D. Tonomura
29

Mission Assurance: A Key To Missile
Defense Agency Contract’s Success
There are several definitions of mission assurance, but none of them completely
cover the subject. Perhaps the best one is that it manages inherent risk and allocates
resources to ensure mission success in collaboration with our customer and
suppliers. This requires mobilizing all elements of our organization, including engineering,
program management, production, quality, subcontract and supply chain
management, and many others. It also requires allocating resources, employing
risk management, and building partnerships with customers and suppliers, so
that everyone can work as a team toward the goal of 100-percent success.
Raytheon began emphasizing Mission Assurance in 2003 when the Missile
Defense Agency (MDA) used it as a prime evaluation criterion in several large contract
competitions, including our recent Kinetic Energy Interceptor win. The
agency also employs it to evaluate contracts it has already awarded.
In consultation with Raytheon and other contractors, MDA has released a
170-page document that outlines its view of Mission Assurance. Titled Mission
Assurance Provisions (MAP), this publication defines tasks that reduce mission
success risks to MDA hardware and systems. Essentially, it states that these systems
must be regarded as strategic systems rather than tactical missile systems.
This means that the agency expects levels of mission success that substantially
exceed our performance on previous MDA programs. Put plainly, our MDA
products must work right the first time, every time. The MAP has been posted
on the Raytheon Quality Home Page under Mission Assurance at
http://docushare1.app.ray.com/dscgi/ds.py/View/Collection-52620.
Meanwhile, Raytheon has also been busy defining our own best-in-class Mission
Assurance approach. In support of this effort, a Raytheon Mission Assurance
Council, sponsored by Gerry Zimmerman, vice president of Quality, has been
meeting monthly via telecon since early 2003. Raytheon Six Sigma teams met for
six months and recently completed a competitive analysis of company programs
and practices, as well as those of NASA, the Air Force and other companies. The
result is a unique approach to mission assurance grounded in 27 precepts that
translate into fundamental task blocks. These precepts cover lessons learned from
past failures and successes, best engineering practices geared to first-time-success
systems like launch vehicles, and critical safety applications such as nuclear surety.
The team selected these precepts to fit our product mix, system requirements and
engineering practices. They were also tailored for compatibility with our Design
for Six Sigma and Capability Maturity Model Integration initiatives. Lastly, the
team defined these precepts so that they can be scaled to customer-success
requirements.
All 27 will be posted on the mission assurance web site and are in the process of
being imbedded in the Integrated Product Development System (IPDS).
30
– Vern David, Missile Systems, Raytheon Mission Assurance Council
ADVANCED TOOL SETS
Continued from page 15
verify the system, and provides the
Verification Planning team with a framework
for recording their knowledge about
how they intend to implement system verification
on their program. The Verification
Procedures document the step-by-step
approach used to demonstrate or test the
system capabilities and performance. The
Test Preparation and Results work products
are simple tables used to capture recordables,
comments and pass/fail status
recorded during the execution of a test.
The Verification Evidence summarizes all of
the evidence supporting the analysis, and
shows that the requirements have been
properly verified, with views for analysis,
pass/fail status and signoff. Each template
provides three or four useful views for
managing the Verification data. All templates
can be tailored to support specific
program needs.
By integrating DOORS with the other MSI
analysis tools, a single Integrated System
Verification Model can be achieved that
integrates the system analysis with the system
verification, improving the programs
chances of delivering the right SoS solution
at the right time.
Summary
Raytheon continues to develop the MSI
methods, tools and lessons learned, knowing
that our customers are increasingly
focused on procuring integrated system
solutions. While COTS tools supporting
these MSI activities are constantly improving,
Raytheon must continue to work with
our engineering tool vendors to promote
interoperability, focused on the needs of
Mission Systems Integration. We have
shown our ability to execute these
advanced capabilities at the program level
and must now work together, leveraging
the strength of our Technical Interest
Groups in the Systems Engineering
Technology Network, to share best practices
and be stewards of the knowledge
that will make us all better Mission
Systems Integrators. �

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
January through mid-March 2004.
MICHAEL JOSEPH DELCHECCOLO
JOHN M. FIRDA
MARK E. RUSSELL
6675094B2 Path prediction system and method
BRIAN M. PIERCE
CLIFTON QUAN
6674340B2 RF MEMS switch loop 180° phase bit
radiator circuit
EUGENE R. PERESSINI
6690695B2 Laser with gain medium configured to
provide and integrated optical pump cavity
LLOYD LINDER
6693573B1 Mixed technology MEMS/BiCMOS LC
bandpass sigma-delta for direct RF sampling
ERIC N. BOE
HOYOUNG C. CHOE
ROBERT E. SHUMAN
ADAM C. VON
RICHARD D. YOUNG
6693589B2 Digital beam stabilization techniques for
wide-bandwidth electronically scanned antennas
YUCHOI FRANCIS LOK
6677886B1 Weather and airborne clutter suppression
using a cluster shape classifier
MICHAEL JOSEPH DELCHECCOLO
DELBERT LIPPERT
MARK E. RUSSELL
H. BARTELD VAN REES
KEITH WANSLEY
WALTER GORDON WOODINGTON
6677889B2 Auto-docking system
MICHAEL JOSEPH DELCHECCOLO
JOSEPH S. PLEVA
MARK E. RUSSELL
H. BARTELD VAN REES
WALTER GORDON WOODINGTON
6683557B2 Technique for changing a range gate
and radar for coverage
MICHELLE K. ESTAPHAN
FREDERICK J. FRODYMA
GUY T. RAILEY
DANIEL M. VICCIONE
6683819B1 Sonar array system
KRISHNA K. AGARWAL
GUILLERMO V. ANDREWS
PAUL E. DOUCETTE
GARY A. FRAZIER
JAMES R. TOPLICAR
6693590B1 Method and apparatus for a digital
phased array antenna
DAVID D. CROUCH
ALAN A. RATTRAY
6693605B1 Variable quasioptical wave plate system
and methods of making and using
CHUNGTE W. CHEN
JOHN E. GUNTHER
RONALD G. HEGG
WILLIAM B. KING
RICHARD W. NICHOLS
6693749B2 Low-observability, wide-field-of-view,
situation awareness viewing device
ROBIN A. REEDER
6693922B1 Reeder rod
RICHARD DRYER
6695252B1Deployable fin projectile with outflow device
LARRY W. DAYHUFF
GEORGE OLLOS
6696999B2 Sigma delta modulator
MICHAEL T. BRODSKY
6697811B2Method and system for information management
and distribution
JOHN B. ALLEN
6686997B1 Apparatus and a method for pulse detection
and characterization
MICHAEL F. HAMPTON
ROY P. MCMAHON
6688209B1 Multi-configuration munition rack
JOHN C. EHMKE
SUSAN M. ESHELMAN
CHARLES L. GOLDSMITH
ZHIMIN J. YAO
6700172B2 Method and apparatus for switching
high frequency signals
LACY G. COOK
6700699B1 Dual color anti-reflection coating
PYONG K. PARK
6703982B2 Conformal two dimensional electronic
scan antenna with butler matrix and lens ESA
EDWARD BENNEYWORTH
JOHN BOWRON
ALEXANDRE LIFCHITS
CONRAD STENTON
6704145B1 Air-gap optical structure having the air
gap defined by a layered spacer structure
TERRY A. DORSCHNER
LAWRENCE J. FRIEDMAN
DOUGLAS S. HOBBS
L. Q. LAMBERT, JR.
6704474B1 Optical beam steering system
PAUL K. MANHART
6705737B1 Reflective optical apparatus for interconverting
between a point of light and a line of light
BERINDER BRAR
6706574B2 Field effect transistor and method for
making the same
MICHAEL JOSEPH DELCHECCOLO
DELBERT LIPPERT
MARK E. RUSSELL
H. BARTELD VAN REES
WALTER GORDON WOODINGTON
6707414B2 Docking information system for boats
DOUGLAS RICHARD BAKER
STEVEN EDWARD HUETTNER
STEVEN CRAIG REIN
6707417B2 Accurate range calibration architecture
MICHAEL JOSEPH DELCHECCOLO
JAMES T. HANSON
JOSEPH S. PLEVA
MARK E. RUSSELL
H. BARTELD VAN REES
WALTER GORDON WOODINGTON
6707419B2 Radar transmitter circuitry and techniques
DAVID A. ANSLEY
ROBERT W. BYREN
CHUNGTE W. CHEN
6707603B2 Apparatus and method to distort an optical
beam to avoid ionization at an intermediate focus
MICHAEL JOSEPH DELCHECCOLO
JOHN MICHAEL FIRDA
DELBERT LIPPERT
MARK E. RUSSELL
H. BARTELD VAN REES
WALTER GORDON WOODINGTON
6708100B2 Safe distance algorithm for adaptive cruise
control
KENNETH ALAN ESSENWANGER
6674380B1 Digital-phase to digital amplitude translator
with first bit off priority coded output for input to unit
weighed digital to analog converter
WILLIAM M. MURPHY, JR.
6674390B1 Shipboard point defense system
and elements therefor
RUSSELL D. GRANNEMAN
6677588B1 Detector assembly having reduced
stray light ghosting sensitivity
ROBERT T. FRANKOT
6677885B1 Method for mitigating atmospheric
propagation error in multiple pass interferometric
synthetic aperture radar
STAN W. LIVINGSTON
6677897B2 Solid state transmitter circuit
JAR J. LEE
BRIAN M. PIERCE
CLIFTON QUAN
6677899B1 Low cost 2-D electronically scanned array
with compact CTS feed and MEMS phase shifters
TAHIR HUSSAIN
MARY C. MONTES
6680236B2 Ion-implantation and shallow etching
to produce effective edge termination in high-voltage
heterojunction bipolar transistors
ALEXANDER A. BETIN
ROBERT W. BYREN
WILLIAM S. GRIFFIN
6690696B2 Laser cooling apparatus and method
GERALD A. LUNDE
6692681B1 Method and apparatus for manufacturing
composite structures
ROLAND W. GOOCH
WILLIAM L. MCCARDEL
BOBBI A. RITCHEY
THOMAS R. SCHIMERT
6690014B1 Microbolometer and method for forming
31

Future Events
Raytheon 7th Annual
Electro-Optical Systems
Symposium
CALL FOR REGISTRATION
April 20 – 22, 2004
Manning House
Tucson, Ariz.
The Electro-Optical Systems Technology
Network is pleased to sponsor the Seventh
Annual EOSTN Symposium in Tucson,
Arizona on April 20-22, 2004. This symposium
is open to Electro-Optical
Technologists, Program Managers, and
Technology Directors from across Raytheon
and our customer communities.
This symposium is devoted to fostering
increased teaming and technical collaboration
on current developments, capabilities,
and future directions of EO systems and
technology. The symposium is conducted as
a means to provide an improved understanding
of Raytheon's expertise in these
areas, and to build and cultivate networking
among our technologists and engineering
personnel, within the Technology Interest
Groups.
Presentations on Electro-Optical technology
developments and applications will be given
in the following areas:
• EO Systems
• Test Systems
• LADAR/Laser Systems
• Mechanisms, Controls, & Cryogenics
• Optics
• Focal Plane Arrays
• High Energy Lasers
• Laser Comm
• Image Processing/ATR
To register for EOSTN 2004 or general
information go to:
http://home.ray.com/rayeng/technetworks/
tab6/eostn2004/registration.html
Raytheon 6th Annual
RF Symposium
– One Company –
Advancing Technology for
Customer Success
CALL FOR REGISTRATION
May 3 – 5, 2004
Marriott, Long Wharf
Boston, Mass.
Raytheon announces the Sixth 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 and the RF Engineering
Management Council, this company-wide
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. It will be held at the
Boston Marriott Long Wharf Hotel, Boston,
Massachusetts, May 3 - 5, 2004.
The theme for this year's RF Symposium is
"One Company – Advancing Technology for
Customer Success". In building on this
theme, this symposium will invite customers
to attend and give presentations emphasizing
their system and mission needs. Papers
presented at the symposium technical
sessions will emphasize our advances in RF
systems technologies and the benefits to
our customers. Other activities will include
meetings of the RFSTN Technology Interest
Groups (TIGS), breakout sessions, workshops
on various RF technology topics,
and industry and university displays.
To register for RF Symposium or for general
information go to:
http://home.ray.com/rayeng/technetworks/
tab6/rf2004/
Raytheon 6th Annual
Processing Systems
Symposium
CALL FOR PAPERS –
Coming Soon
September 21 – 23, 2004
Tucson, Ariz.
Raytheon 4th Annual
Mechanical and Materials
Engineering Symposium
CALL FOR PAPERS –
Coming Soon
October 19 – 21, 2004
Dallas, Texas
Copyright © 2004 Raytheon Company. All rights reserved.