...

Applying DoDAF NASA Orion Mission Communication Navigation and

by user

on
Category: Documents
21

views

Report

Comments

Transcript

Applying DoDAF NASA Orion Mission Communication Navigation and
Applying DoDAF to NASA Orion Mission Communication
and Navigation Architecture
A. Biswas', J. Hayden2, M. S Phillips3, K. B. Bhasin4, C. Putt4, T. Sartwell3
'NASA Jet Propulsion Laboratory, 4800 Oak Grove Drive, Pasadena, CA 91109
25467 S. Cimarron Road, Littleton, CO 80123-2995, 303-703-6911
3 NASA Goddard Space Flight Center, Greenbelt, Maryland 20771
4NASA Glenn Research Center, Cleveland, Ohio 44135
abiswas.jpl.nasa.gov; jhaydengearthlink.net; Michael.S.Phillipsgnasa.gov; Kul.B.Bhasingnasa.gov; cputtgmsn.com;
Tom.Sartwellggdc4s.com
Abstract NASA's pursuit of the Vision for Space
Exploration (VSE) has motivated the development of an
evolvable communication, navigation and timing
architecture for crewed missions, initially to the
International Space Station (ISS), followed by destinations
to the Moon and eventually Mars. A cost-effective, phased
development, leveraging to the maximum extent possible
existing and upgradable infrastructure, both within and
outside NASA, is being emphasized. The transportation of
cargo and crew to the ISS using the Crew Exploration
Vehicle (CEV), Orion, is currently under development.
During this initial mission phase Internet Protocol (IP)
based communications, servicing an interoperable Systemof-Systems will be developed. The Department of Defense
Architecture Framework (DoDAF) processes and
prescribed products therein are being used to implement an
end-to-end architecture developed using NASA System
Engineering practices. In this paper we will provide an
overview of the architecting process with a few examples of
the NASA applied DoDAF products. 1, 2
(ESMD) within which the manned Constellation Program
(CxP) was established. The Space Communication and
Navigation (SCaN) Program Office was created within the
Space Operations Mission Directorate (SOMD) to
implement needed end-to-end communication and tracking
infrastructure for missions under ESMD.
TABLE OF CONTENTS
As communication and navigation to support space
exploration involves a complex System-of-Systems (SoS),
effective use of engineering processes and methodologies is
being pursued by the NASA SCaN program, throughout
each phase of architecture development. These processes
are intended to better address the interoperability of large
complex systems by integrating the existing systems into an
interoperable and seamless infrastructure to satisfy the
mission requirements. To this end the approach adapted is
to augment NASA System Engineering practices [3] with
selected processes and methodologies prescribed by the
Department of Defense Architectural Framework (DoDAF).
1. INTRODUCTION....................
A series of test flights involving transportation of
cargo and crew to the International Space Station (ISS)
utilizing the crew exploration vehicle (CEV), Orion, will
"spear-head" the mission set. This will be followed by
missions transporting crew and cargo to the Moon.
Eventually transportation to Mars and beyond is envisaged.
The communication and navigation architecture to be
described in this paper is for the initial Orion to ISS
Mission [2]. The primary purpose is to describe the
architecture in a manner that establishes interoperability
between systems owned and operated by separate
organizations within and external to NASA.
1
2. ORION COMMUNICATION AND NAVIGATION PROCESS
OVERVIEW....................
2
3. DoDAF VIEWS .................... 4
4. OPERATIONAL VIEWS ......
.............. 6
5. SYSTEM VIEWS .................... 7
6. CONCLUSIONS....................
7
ACKNOWLEDGEMENTS....................
7
REFERENCES .................... 9
1. INTRODUCTION
DoDAF [4] provides general guidance for
development, usage and management of DoD architectures
with an emphasis on interoperability among large complex
DoDAF guidelines and prescriptions are
systems.
themselves evolving toward capturing "net-centric"
architecting which emphasize providing essential
information to authenticated and authorized users where
and when it is needed. DoDAF affords flexibility in terms
of supporting several alternate methodologies (for example,
structured, object oriented, and activity-driven) and offers a
wide range of products from which suitable selections for
One of the main objectives of NASA's Vision for
Space Exploration (VSE) [1], announced by the President
in January 2004 is, extending human presence across the
solar system starting with a human return to the Moon by
the year 2020, in preparation for human exploration of
Mars and other destinations. In response to the VSE,
NASA established the Exploration Mission Directorate
1
1
2
1-4244-1488-1/08/$25.00 C 2008 IEEE.
IEEEAC paper #1595, Final Version, Updated Dec 13, 2007
1
describing a particular SoS architecture can be made.
Implementing the SCaN communication and navigation
architecture where SoS interoperability is critical, can take
advantage of the features offered by DoDAF.
maximum extent possible. Primary communication linkage
systems belonging to the SCaN Network are listed next:
DoDAF products consist of "views" which are
graphical and/or tabular descriptions of a SoS architecture.
These views are further classified for describing operations
(operational views, OV), and the systems and services
(system views, SV) involved in the operations.
Additionally, the technical standards that apply to the
systems/services and interfaces are described by technical
views (TV). Each of these views have a number of well
defined representations, corresponding to different
perspectives and intended for different users, such as,
managers, designers, builders and operational personnel.
The DoDAF views reside in a presentation layer,
underlying which there is a data layer where defining
attributes and relationships of the architecture can be
documented. DoDAF formalism is also increasingly being
supported by commercially available architecting tools
which not only allow capturing the data layer but also
support modeling and simulation, for validating
architectures [5].
g
The Space Network [6] with a geo-stationary orbiting
(GEO) constellation of Tracking and Data Relay
Satellites (TDRS) and ground-segments located at the
White Sand Complex in Las Cruces, New Mexico and
Guam.
g
The NASA Ground Network [7] comprised of fixed
and mobile assets located in the vicinity of the
Kennedy Space Center (KSC) and possibly at downrange locations covering the ISS Launch trajectory of
Orion.
g
NASA Integrated Services Network (NISN) for routed
data transfer to and from Constellation space vehicles
(Orion and launch vehicle) to Mission Control and
Ground Systems.
g
SCaN Management where network management, and
health and security of the network is monitored.
g
Flight Dynamics Facility (FDF) [8] located at Goddard
Space Flight Center (GSFC) that provides navigational
[ 0wti z
ldWI0
D
pOCMo'f
h
"~ ~ ~ ~ ~ ~ ~tehfiI44es
~ ~ ~ ~ ~Oa
Wl
Devldo6
hitedr d.Oeaion andviow1n
- Showin ahd NecomtositionNof the Orion-IS
t
Figurete
Wisio
arhiecuew
support to missions
2. ORION COMMUNICATION AND NAVIGATION
PROCESS OVERVIEW
Constellation Program owned assets involved in the
Orion-ISS Mission are:
Figure 1 shows the decomposition of the Orion-ISS
Mission architecture. The Constellation Program (CxP)
developed a higher level architecture. The requirements for
the SCaN Program provided communication and
navigation services are derived from the CxP higher level
architecture, as are the concept of operations (CONOPS).
Additionally, the development of an Internet Protocol (IP)
Network is delegated from this higher level architecture.
The Network is based on communications command,
control and intelligence (C31) interoperability
specifications. Based upon the requirements an end-to-end
architecture description for Communications, Navigation
and Networking was created.
The approach followed in formulating an end-to-end
architecture was to use existing NASA infrastructure to the
2
g
The crew exploration vehicle (CEV) Orion, comprised
of a crew module (CM), service module (SM) and
launch abort system (LAS)
g
The crew launch vehicle (CLV) comprised of the solid
rocket booster (SRB) or First Stage (FS) and the Upper
Stage (US)
g
The Mission System (MS) where the mission control
center (MCC) resides
g
The Ground System (GS) comprised of assets at KSC
used primarily for supporting launch and coordinating
search and rescue during recovery following landing of
the CM.
Ascent
Discarded at
tT+lftG 43s:
Discarded at
T'2xmi
_
Prelaunch &
Eard Launch
Other
Figure 2 - Overview of the Concept of Operations for the CEV-ISS mission represented using the OV-1
Other NASA assets include the ISS and non-NASA
US Air Force (USAF) assets for range control during
launch, as well as, possible Department of Defense (DoD)
assets (satellite, ground, ship-board) for supporting voice
communications during various mission phases. Finally
commercially owned non-NASA assets may be used for
search and rescue during re-entry, landing and recovery of
the CM.
complexity associated with achieving a detailed description
the mission was decomposed into the following phases:
Figure 2 shows an end-to-end communication
architecture overview for the Orion-ISS Mission. Here a
coloring scheme (see key at bottom of Fig. 2) is used to
demarcate the ownership of the assets called out above.
The Constellation Program Systems will be connecting
and/or disconnecting with the SCaN networks for
communication and tracking. The SCaN networks interface
with the Constellation Program, space vehicles, Orion and
CLV, and ground segments, MS, and GS during all the
mission phases as shown in Figure 2. The SCaN networks
interface to the ISS and the Air Force, Eastern Test Range
(ETR), shown via the CxP GS in Figure 2.
Utilizing this approach will of course result in
many more diagrams and for the sake of brevity a select
few are presented in this paper. In Figure 3 a Navigation
and Timing architecture diagram for the low-Earth orbit
(LEO) phase of the Orion-ISS Mission is shown. The
communications between the SN satellites and Orion are
used for transferring on-board navigation solutions, derived
using GPS or inertial measurement units (IMU), for
example. In addition radiometrics are also extracted form
the communication link between the SN TDRS satellites
and Orion. The navigation solutions are all forwarded to
the MS. The flight dynamics facility also serves as a
secondary source for navigational processing support.
1. Pre-Launch and Countdown
2. Launch and Ascent
3. Low Earth Orbit including rendezvous with the
ISS
4. Re-entry and Recovery
Though all the mission phases such as pre-launch and
early launch, ascent, rendezvous and docking with ISS and
finally return to Earth are shown in Figure 2, the dynamics
of communication linkages including handover or
switching of data-rates is not represented. Because of the
A description of the basic SCaN-CxP user
interfaces follows; it uses a slightly simplified Open System
Interconnection (OSI) Reference Model (RM) "layered"
representation as shown in Figure 4. In this diagram, a
3
CEV Radiomettic Rahng &et Me urembets
CEV imu & OPS Fmeawftolft
Figure 3 - The Navigation and timing architecture for the LEO-orbit phase of the Orion-ISS mission.
Figure 4 - The Internet Protocol (IP) Networking Architecture for the Orion-ISS Mission. PHY represents Physical Layer; DL - Data Layer; IP - Internet Protocol; HDLC/AOS - High-Rate Data Link
Control; AOS - Advanced Orbiting System
vertical interface between adjacent layers represents a
"service" by the lower layer to the higher layer, while a
horizontal interface between peer entities at the same layer
represents a "protocol" interaction. This figure is an
example of CEV communicating through the SCaN
(=SN+NISN in this case) with the Mission Control Center
(MCC) within the CxP MS.
The end-to-end architectures for Communication,
Navigation & Timing and Networks provide context and
scope of the architectures. These are supplanted for the
DoDAF All Views. Figure 5a shows how the operational
views, each with a unique perspective, are built from the
context and scope set by the All Views. The CONOPS are
then described using OV-1. These CONOPS are again
described for different mission phases listed in Section 2.
The OV- 1 is used to establish the organizational
relationships or OV-4. Operational activities for each
phase are then captured in activity flow diagrams, OV-5,
which can be described in further detail using event traces
or OV-6. Based upon activity flows established in the OV5, the information exchanges needed between the
operational nodes, OV-2, are developed. Finally OV-3 or
3. DoDAF VIEWS
Next the DoDAF views will be presented. The build
sequence of the DoDAF views presented here is based upon
the scheme represented in Figure 5 below.
4
the information exchange matrix was developed. Once
again for the sake of brevity, in this paper we show a
selected set of OV's in Section 4 below.
matrix. SV-4's represent functional hierarchies and flows.
The SV-4's must be consistent with the activity hierarchy
and flow diagrams established in OV-5. In fact the OV-5
and SV-4 diagram development is an iterative process
culminating in SV-5 where a matrix mapping the activities
to functions is the product.
SV-6 is a detailed
In Figure 5b the system description sequence is
shown. The System Views are of greater interest to the
AV-1
Destr.ptL nofthe
Arch ledure
_~~~~~T
the Arc
Utad .n
I
r
Wa
Figure 5- DoDAF build sequence for (a) Operational Views, (b) System Views and (c) Technical Views
communication interface description where attributes and
performance characteristics of communication links can be
tabulated. Finally the SV-8 serves as a roadmap for needed
upgrades or technologies.
builders and implementers and must show how the
communications, navigation and timing operations in the
OV's are accomplished. Some of the differences between
SV's and OV's are that while OV's show information
exchange needs, SV's show data pathways and interfaces
exactly the way they are supposed to occur in order to
facilitate the information exchange called out in the OV's.
The SV-1 depicts the system nodes and interfaces between
them. The level of detail represented can vary from
showing inter-nodal interfaces to intra-nodal interfaces. In
SV-1 we also introduce unique names and numbers for
system nodes and interfaces. In SV-2 the communication
description is added to the interfaces, in other words
frequency bands and other data transfer attributes are
introduced. The SV-3 is a system-to-system connectivity
Figure 5c shows the decomposition of the All View
into a single Technical View where the technical standards
used in the system and services views are tabulated.
Next, selected views of the Orion-ISS Architecture will be
presented.
5
Jettison at
TDRS East
=T+2rr 43s
.......m
Orion (CM, SM) -
LAS
Ares (US) --
Jetison at
_T+2ma ls
SCaN
Netwo:rk
Links
Orion
(LAS,
Cm, SM)
CLV MEL Data
Ares (US)
\\
..
r
Ares (FS)
Rada
Transponders,
1 on FS,
I
on
Us
i
FTS Link to
End of FS
BurnT+O to
*T+2m Wls
Cormruniation Nodes
Conrunfircation Links
SCaN Nodes
Constelation Nodes
Other ComTmunication Nodes
SCaN Network Users
SCaN Network
SCaN Links
Other Linlks
Red
Dk
Dk
Blue
BIUe
Yellow
Figure 6 OV-1 Operational Concept of the Launch Phase
-
After its burn the FS is jettisoned and the Upper Stage (US)
continues to lift Orion. By this time the LAS has also
separated for nominal launch scenarios. Bi-directional
communication between Orion and MS continues utilizing
the SN assets until US separation occurs concluding the
ascent phase. Figure 6 also shows the SCaN management
and FDF operational nodes used for network monitoring
and navigational support during launch and ascent.
4. OPERATIONAL VIEWS
The OV- 1 shown in Figure 6 captures the
CONOPS for the launch and ascent phase. During early
ascent Orion comprised of the CM, SM and LAS stack on
CLV is lifted by the SRB. During this stage bi-directional
communications between Orion and MS occurs with relay
services provided by SCaN assets, specifically, the satellite
labeled TDRS East, the White Sands Complex (WSC) and
the NASA Integrated Service Network (NISN). Command,
telemetry and other mission data is exchanged between MS
and Orion with the aid of these services. Furthermore, MS
can re-broadcast mission information to GS and other
ground assets via NISN.
An example of an activity flow diagram for launch of
Orion, OV-5, is shown in Figure 7. Here the methodology
used is the basic Integrated Definition Method (IDEF)
diagrams [9]. At the bottom lower left of Fig. 7 the IDEFO
schema is shown. Specific activities are labeled and
numbered within the green shaded boxes. The flow of
activities are also indicated along with the controls and
mechanisms involved.
Thus the possible outcomes
resulting from the flow of activities during the launch of
Orion are represented in this diagram.
The Air Force Eastern Test Range (ETR) assets involved
during launch are shown. Radar assisted skin tracking of
the launch vehicle for range safety is planned. An Air
Force ground antenna located at Kennedy Space Center
(KSC), TEL4, receives mission Engineering and flight
instrumentation information downlinked from the CLV
during the early launch phase. The downlink allows
storing launch vehicle engineering data during the early
test flights. The Air Force also transmits flight termination
commands from the Flight Termination System (FTS), if
needed, for non-nominal launches.
The OV-2 or information exchange between
operational nodes is shown in Figure 8. The operational
nodes are shown connected by unidirectional "needlines".
Furthermore the types of information exchanged are
annotated on each needline. Fig. 8 represents a high level
OV-2 representing all the phases of the mission.
6
r
Reatiy;
Uii d
Cues CLI
Tumory
Bask IEFO
Ac#ft Dlagra
Input
tdechanis m
Figure 7- Operational Activity Flow Diagram, OV-5, for the Launch of Orion
5. SYSTEM VIEWS
6. CONCLUSIONS
Figure 9 shows the system/service-nodes and their
interfaces for the launch and ascent phase of the Orion-ISS
Mission. Once again the colors designate the SCaN, CxP
and Air Force assets in use during launch and ascent. The
interfaces are identified by a unique number as are the
system nodes. This numbering scheme can be used, for
example, to associate attributes and relationships between
system elements and nodes in more detailed descriptions
that are derived from the SV- 1. This level of detail is not
addressed in this paper but, as an example, the SV-6 or
data exchange matrix and SV-7 or systems performance
parameters matrix can be mapped back to the SV- 1 with
the help of these unique numbers.
A high-level overview of the architecting process being
dapted by the SCaN Architecture team within NASA has
been described. The System Views are further described
through technical standards that apply to the systems and
services. These standards are under development and will
form the subject of future reports. The architecture
description afforded by combining NASA system
engineering practices and DoDAF formalism is new and
adds a whole new dimension to architecting of complex
system-of-systems. Noteworthy among these is the ability
to utilize commercially developed modeling tools.
The SV- 1 can also be further decomposed to
describe interfaces between sub-systems that reside within
each system node. Figure 10 shows an example of a more
detailed SV that describes the interfaces between
networking layers for communications while Orion is
docked to the ISS. This diagram shows smaller blocks
utilizing color code to represent the OSI layers (see Figure
4) within which the hardware resides and operates. In order
to preserve clarity only the critical nodes in the
communication chain are shown, although the other nodes
represented are also still present.
The work described was carried out jointly by the Jet
Propulsion Laboratory, California Institute of Technology
under contract with the National Aeronautics and Space
Administration.
ACKNOWLEDGEMENTS
7
Iwe f
o--".4:-->
_.-.
L
a
1w1e~~~~~lnplmened
by
C6negtMdbh
I~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I4%e
iiring,
vbicp
Med
Schid
Na alio
~~~~*
*~~~~~~~~~~NV
Figure 8- Operational information exchange diagram, OV-2, for the Orion-ISS Mission
Spada Systemns
Gtroud Systems
4=>
. *
s=l
L-
LFn
~
IE90
A
=n
IFOOQI
r
1EQQ04
IF006
1F0003
_
1
SCaN Nodes
Constellation Nodes
Other Communictation Nodes
-
intra-SCaN Links
Intra-Constellation Links
User Links
Figure 9-SV-1 or system/service interface description for the launch and ascent phase of the Orion-ISS Mission.
8
Mr
_
ScaN
Consw1won Nes
UUers Uodes
_
-
-
LxtaC&N
LUniks=Nafoik
kvhnC£stellalf10 Llnhk
User Lirks
no
o*
Phy
Figure 10- Networking diagram showing more detailed interfaces for the low-Earth orbit phase of the Orion-ISS
Mission while the Orion is docked to the ISS.
[6] Space Network User's Guide, 450-SNUG, June 2002,
REFERENCES
[1] The Vision for Space Exploration, February 2004,
[7] Ground Network (GN) User's Guide, 453-GNUG,
Revision 1, February 2005.
npd
[8] Space Communication and Data Services Catalog,
September 12, 2003, Rev. 6
[2] K. Bhasin, C. Putt, J. Hayden, S. Tseng, A. Biswas, B.
Kennedy, E. Jennings, R. Miller, J. Hudiburg, D. Miller,
A. Jeffries, T. Sartwell, "Architecting the
Communication and Navigation Networks for NASA's
Space Exploration Systems, " IEEE System of System
Engineering Conference, San Antonio, TX, 16-18 April,
2007.
[9] Integrated Definition Methods Website,
[3] R. Shisko et al., NASA System Engineering Handbook,
NASA SP 6105, June 1, 1995, Document ID
19960002194.
[4] DoD Architecture Framework Version 1.5, Volumes I
and II, April 23, 2007,
[5]_Fojrt
e.xample VI i1t/jic drpsCdORs
[5] For example, Vitech Corps, CORE.
9
Fly UP