Applying DoDAF NASA Orion Mission Communication Navigation and
by user
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