On Using Sysml, Dodaf 2.0 and UPDM to Model the Architecture for the NOAA's Joint Polar Satellite System (JPSS) Ground System (GS)
Total Page:16
File Type:pdf, Size:1020Kb
https://ntrs.nasa.gov/search.jsp?R=20120009882 2019-08-30T20:31:32+00:00Z On Using SysML, DoDAF 2.0 and UPDM to Model the Architecture for the NOAA's Joint Polar Satellite System (JPSS) Ground System (GS) Jeffrey L. Hayden' and Alan Jeffiies' Jeffries Technology Solutions, Inc. (JeTSI), Herndon, VA, 20170, USA The JPSS Ground System is a lIexible system of systems responsible for telemetry, tracking & command (TT &C), data acquisition, routing and data processing services for a varied lIeet of satellites to support weather prediction, modeling and climate modeling. To assist in this engineering effort, architecture modeling tools are being employed to translate the former NPOESS baseline to the new JPSS baseline, The paper will focus on the methodology for the system engineering process and the use of these architecture modeling tools within that process, The Department of Defense Architecture Framework version 2,0 (DoDAF 2.0) viewpoints and views that are being used to describe the JPSS GS architecture are discussed. The Unified Profile for DoOAF and MODAF (UPDM) and Systems Modeling Language (SysML), as ' provided by extensions to the MagicDraw UML modeling tool, are used to develop the diagrams and tables that make up the architecture model. The model development process and structure are discussed, examples are shown, and details of handling the complexities of a large System of Systems (SoS), such as the JPSS GS, with an equally complex modeling tool, are described. I. Introduction N February 2010, the US Government restructured the National Polar-orbiting Operational Enviromnental Satellite S),stem (NPOESS) into the National Oceanic and Atmospheric Administration (NOAA)lNational Aeronautics and Space Agency (NASA) Joint Polar Satellite System (JPSS) and the Department of Defense's Defense Weather I Satellite System (DWSS). Since this transition, the DWSS satellite program has been canceled and replaced with the Weather Follow On (WFO) program. As part of the restructutiog of the program, some responsibilities have been shifted to accomplish the enviromnental and climate observing missions. For JPSS, NASA's Goddard Space Flight Center has the responsibility for the acquisition for the afternoon orbit satellites, along with the acquisition, system engineering and integration for the Ground System (GS) for the US next-generation of weather and climate satellites. After the start of the JPSS program, the DWSS, which was to be responsible for the early morning orbit satellites, was cancelled due to lack of funding. The European Organization for the Exploitation of Meteorological Satellites (EUMETSAT) will be relied on for the late morning orbit satellites. The transition from the NPOESS era to the JPSS era is complex. It involves a large number of stakeholders, significant changes in mission scope, a complete change in government organization, project processes and relationships to development contractors, as well as architecturaI modernization. To manage all this change, the program has exploited the tools of the Department of Defense Architecture Framework version 2.0 (DoDAF 2.0) to capture the transition and communicate out to the community what it entails. This study identifies key aspects of how DoDAF 2.0 was used to manage and coordinate the transition. n. Architectur.e Methodology The JPSS Program chose DoDAF 2.0 as the means for describing the very complex operations, systems, interactions, and interfaces of the JPSS Program. Other methods were brielly considered, such as The Open Group , System Architect, JPSS Ground System, Jeffiies Technology Solutions, Inc., 1517 Meadow Chase Drive, Herndon, VA 20170, and AIAA Member Grade for first author. , System Engineer, JPSS Ground System, Jeffries Technology Solutions, Inc., 1517 Meadow Chase Drive, Herndon, VA 20170, and AIAA Member Grade for second author. American Institute of Aeronautics and Astronautics Architecture Framework (TOGAF) and Briton's Ministry of Defense Architecture Framework (MODAF), a framework very similar to DoDAF. TOGAF is most useful for describing higher level enterprise architecture while DoDAF and MODAF are very well suited to describing architecture in high detail; and since a certain amount of familiarity with DoDAF and its products existed on the program, DoDAF 2.0 was chosen as the architecture methodology. '- ."!'-'-"-"" ~" iDIIIMM .... ----_............ '-'" --_0." __. ---,---. ----- ----""'-- --"',....... .. :::.= -- - ·I.::.:...~B! ~ .... r .. ,l -::::r~ • --. ,...,_ -... I .~- ----1__ ..... DI 6 ..... "_'_d~ ._-_....._1-70....- 1 I I -,,..........,_ ... __ J:"I.n'_....... -. _===".l::"•...::n.:_ ..... :~~ _ . __ Figure 1. The DoDAFIUPDM Workflow for the JPSS Program After consideration of several tools (Rhapsody and System Architect by IBM and Enterprise Architect by Sparx Systems), MagicDraw by No Magic, Inc. was chosen due to its advanced abilities.to enable diagramming ofDoDAF 2.0 views with the Unified Profile for DoDAF and MODAF (upDM), a modeling profile based on the standard Unified Modeling Language (UML) and System Modeling Language (SysML) graphical representations. The major advantage of a tool such as MagicDraw is that it enables the architect to layout a project or program in great detail with UML objects (representing organizations, personnel, teams, systems, components, etc.) and then to interconnect the objects with information exchanges among the operational performers and system connectors to tie the systems together. The tool tracks all inputs to the architectural diagrams, generates tables of the interactions over the exchanges and connectors, and generates matrices showing the relationships among the objects. For the JPSS Ground System, the DoDAF model. became the central common reference that tied the development program's Level 2-3 Requirements Specifications, Interface Specifications and 29 Concept of Operations (ConOps) use cases together into a coherent technical baseline; thus achieving traceability and management across the full suite of documents. Requirement documents and ConOps are managed out of a Dynamic Object-Oriented Requirements System (DOORS) database, linked to the DoDAF model elements. Additionally, JPSS, as it transitions from the NPOESS era, is being deployed in blocks of expanding capabilities and modern technologies beyond those identified for NPOESS. The October 20 II launch of Suomi National Polar orbiting Partnership (Suomi NPP) satellite represents Block I of the JPSS Program, while the future deployment of the first JPSS satellite is designated as Block 2. There are sub-block deployments being defined and worked in parallels stages of the mission life cycle. (e.g., 1.2, 1.3 and 1.5). The architecture and requirements are phased across these blocks. American Institute of Aeronautics and Astronautics 2 m. JPSS Architecture Development The DoDAFIUPDM workflow for the JPSS Program is shown in Figure 1. The enterprise definition started in the Capability View (CV) environment. Due to the complexity of the system, the capabilities have been used to separate the JPSS mission into 29 threads of operations needed to accomplish the various and disparate mission details for Block I.S (Suomi-NPP focused). The addition of the second satellite (JPSS-I) adds a further S threads and updates to a few of the previous threads. This provides the transition of decomposition into the Operations environment, where the flows associated with the concept of operations are documented. Each of the 34 threads has its own ConOps document and sets of Operational Views (OV) and System Views (SV) as described using IJPDM diagramming techniques. For each thread, an OV-Sb operational activity model diagram is developed to illustrate the activity flows across Ground System internal and external "performer" interfaces. Each activity in an OV-Sb represents Ground System Level 3 requirements that are captured in DOORS and are associated with each Ground System 'performer' requirements specification document. For select threads, where message timing is important to understand, an OV-6c event trace description diagram is generated to capture the sequencing of messages. The OV- 5b and applicable OV-6c's become the core of the thread Concept of Operations documents that make up a major component of the JPSS Ground System Technical baseline. ConOps documents are managed and generated out of the DOORS database, but linked via the DoDAF architecture. Every thread includes an SV-4 functional flow diagram and an SV-\ system interface description diagram that captures the data exchanges for just that thread. The thread-specific SV -I also identifies the interface documents that are traced to particular exchanges using dependencies. This dependency mapping helps identifY gaps in the interface documentation. The system views are specific to a particular block implementation, so evolutionary views are generated for later blocks. For the Interface Requirements Documents (1RDs), the culmination of thread based SV Is become the interface definition (i.e., names) for all data flows. These data flows are then decomposed into specific giver-receiver interface requirements. The architecture model provides the linkage between requirements in the IRDIDOORS, the ConOps and the overall system architecture model. To support the Ground System development, a number of enterprise views are also developed. The CV-I vision diagram provides the vision statement for the program and illustrates the phasing of the major builds (i.e., blocks) for the