On Using Sysml, Dodaf 2.0 and UPDM to Model the Architecture for the NOAA's Joint Polar Satellite System (JPSS) Ground System (GS)

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 enterprise. CV -2, capability taxonomy, diagrams arc used to describe the thread hierarchy, as well as the hierarchy of science products being produced by the progriun. CV-3 , capability phasing, diagrams have been used to document the phasing of the thread development packages across the stakeholders. A CV-4 capability dependency diagram helps document the inter-relations among the threads to understand if inter-thread communication is missing in the thread OV-Sb view. The CV-6 capability to operational activities mapping matrix links operational activities to·the thread capabilities for supporting model validation and gap analyses. In the operations environment, the OV-l (high-level operational concept graphic) provides an executive-level view of the system. The OV-2 (operational flow description) diagram illustrates the performer information exchanges. The OV-Sa (operational activity decomposition tree) diagram describes the activities hierarchy and illustrates the performer ownership of all of the operational activities. Tbe OV-Sb activities for any given performer map into DOORS to a section within that performer's requirement specification document - linking requirements to architecture model. The model generates an OV-3 (operational resource flow) matrix that connects the various information exchanges among the operational activities; these are used in the Interface Requirements Documents to develop IRD reqnirement sections. OV-4 (organizational relationships) diagrams are used to document the complex interactions between the various stakeholder, consumer and support organizations for the JPSS program in both the development and the operations phase. In the system environment, the SV-l diagram for the enterprise illustrates the data exchanges between systems and people throughout the JPSS Ground System. There is an SV-4 (systems functionality description) hierarchy diagram that identifies all of the system functions and their owning systems and personnel, similar to the OV-Sa. A second version of the SV -4 (systems functional flow) diagram' is used t9 illustrate the implementation view of each of the OV-Sb diagrams. The model maintains the SV-Sa (operational activity to system function traceability matrix) and SV-Sb (operational activity to systems traceability matrix) views that map the operational activities to the system functions and systems, respectively. The SV-6 (system resource flow) table displays the data exchanges among the systems and system functions, as well as tracking interface attributes. The DIV-l (conceprual data model) contains the information elements exchanged in the operations environment. The DIV-3, physical data model, contains the data elements exchanged in the systems environment. The DIV-2 (logical data model) views are used on JPSS to track spacecraft data product evolutions through the processing

American Institute of Aeronautics and Astronautics 3 chains as the sensor data transitions from observation to raw data records to sensor data records to environmental data records. These views also help identify the various inputs necessary for the data production. Some SysML package diagrams have been used to help visualize the transition of the existing NPOESS technical baseline to the new JPSS technical baseline. The model establishes a common target for the JPSS era Ground System, while providing a transition map from the NPOESS era baseline to the JPSS era .

•\ t _ _ -.-.. , .... \ ~ I_-""; \f ~'ll~T

--... -""-

, " .. ~ ...... --. -- , j , I ..... , j ...... - -- , • ,I • • I • , • • ..!...... - - ---.....,.~. ~-...- ...... , --- 0- ... - ~ ~ ~ ... 1..... -

- ...... -.r . ~,...... L_",... ~,.

----...... -.-;...... -~ -...,,--..--._ ~~~~~~~~~--~~.-~-~~~~~.~:~~~ Figure 2. OV-1, JPSS High Level Operational Concept

A. JPSS Program Capabilities Table 1. JPSS Satellite Fleet Figure 2 shows an OV-I diagram illustrating the overall JPSS Operational Concept. The environmental '!\alclI11e (hr..,r SCI~lble JPSS ~~1vlce satellites, the elements of the JPSS Ground System (GS), NOAA NPP Full Service: the elements of external entities that provide services to ,JPSS-! Commanding and JPSS, and the elements of the stakeholders who utilize JPSS-2 Data Processing andior process the environmental data are shown in this D artm t f OVI. ep en 0 DMSP Data Acquisition Coriolis and Routing The JPSS satellite fleet is listed in Table I. The Suonti Defense NPP, launched in the fall of 2011, is the first of the fleet TAXA (Japan) GCOM-WI Data Processing and is used as a forerunner to shakeout the JPSS operations GCOM-W2 and systems for providing global environmental 'GCOM-W3 information. JPSS is responsible for providing and GCOM-C! servicing two future JPSS satellites ' (JPSS-! in 20 !6). EUMETSAT Metop Data Routing

American Institute of Aeronautics and Astronautics 4 JPSS will process sensor data from four of the Japan Aerospace Exploration Agency's (JAXA) Global Change Observation Mission (GCOM) weather and climate satellites, and provide communication services to the European Organisation for the Exploitation of Meteorological Satellite's (EUMETSAT) Metop meteorological satellite and the Defense Meteorological Satellite Program (DMSP) satellites. JPSS was chartered to operate the Defense Weather Satellite System (DWSS) satellites that were planned to replace the DMSP satellites, but since the DWSS program waS cancelled in early 2012 the program is awaiting guidance on the path for the post-DMSP defense Weather Follow-On (WFO) satellite program. Table I indicates the owners of the satellites, their satellites, and the types of service that JPSS will provide. JPSS 0 also provides communications services to the National Science Foundation (NSF) facilities in McMurdo Bay, Antarctica and NASA's Space Communications and Networks (SCaN) program providing communications support to Svalbard. JPSS also provides backup access to NOAA Polar Orbiting Environmental Satellites (POES) via Svalbard. The JPSS GS includes: ground stations at Svalbard Island Norway and at McMurdo's Black Island satellite communication facility in Antarctica; the JPSS GS Ground Network's lines between Svalbard and the US, the network's leased lines among facilities in the US, and the US Internet; the Mission Management Center at the NOAA Satellite Operations Facility (NSOF) in Suitland, MD; and, the four Data Processing Nodes (DPNs) at NOAA's National Environmental Satellite, Data, and Information Service (NESDIS) in the NSOF, the Air Force Weather Agency (AFWA) at Offutt AFB, NE, the Navy's Fleet Numerical Meteorology and Oceanography Center (FNMOC) in Monterey, CA [Future], and the Naval Oceanographic Office (NAVO) in Stennis, MS [Future]. Field Terminals and Direct Readout Terminals are being added to the architecture. The Field Tenninals are independently developed data receptors placed around the globe and are capable of receiving data from othe high rate downlink (HRD) that continuously broadcasts selected data in real time as the satellite passes overhead. The Direct Readout Terminals will be small systems that could be portable and that will capture the high rate data continually broadcast from the JPSS satellites alsoo JPSS will not supply these small systems, it is up to any country that is interested in local weather to provide their own terminals. JPSS will provide the software for capturing and processing the data at the terminals. The plan for the JPSS-l era is to reduce end-product latency in the data reporting system by reducing the time between downloads from 90 minutes for each polar orbit download to less than 30 minutes. This can be obtained by do"nloadingOto tenninals closer to the equator and to McMurdo or other architectural options. The JPSS DoDAF architecture model plays a key role in perfonning the requisite trades in achieving this new performance level in a robust, yet cost effective manner. There are other operational performers that are part of JPSS Ground System. These performers include the CalibrationIVaiidation (CalIVal) Node and the Simulation Node. Algorithms for reducing the science instrument data are provided by the science investigators who send them to the NESDIS Center for Satellite Applications & Research (STAR) and to CalNal for verification and/or tuning. Once validated the algorithms are then distribution to the Data Processing Nodes and Field Terminals. ~OAA's Comprehensive Large Array-data Stewardship System (CLASS) archive storage provides the global weather history for JPSS. Other customers are the Science Data System (SDS) that monitors operation of the NPP and its data at NASA Goddard Spaceflight Center (GSFC), the National Weather Service (NWS), and the Naval Research Laboratory (NRL) that performs the operations function for the WindSat instrument on the Coriolis satellite. In the future, the Ground System may also support Free Flyer Projects such as NOAA's Argos Advance Data Collection Unit (AOCS) instrument operations and the US Mission Control Center (USMCC) for operating Search and Rescue (SAR) over land and sea. Various NASA and government entities interface with the JPSS Ground System in support of various mission phases. For example, JPSS receives satellite integration, testing, and launch support for placing JPSS satellites into polar orbit from the Vandenberg AFB Launch System. NASA's SCaN provides communications support for testing oat Vandenberg, during satellite launch, and during early orbit operations from the Space Network (SN) geosynchronous Tracking and Data Relay Satellite System (TORSS) operated at White Sand Complex (WSC) in New Mexico. TDRSS also supports satellite maneuver activities by providing communications services during orbit corrections. For JPSS-l, TDRSS will also be available to support the downlink of Stored Mission Data (SMD) if there are issues using the polar ground stations. Finally, JPSS receives telemetry, tracking & command (IT&C), SMD acquisition support, and ground station support from the NESDIS Fairbanks Command and Data Acquisition Station (FCDAS) [not shown in this version of the OV-I]. The complex JPSS Ground System interface topology (representing 38 external interface control documents in total) can only be managed efficiently using a modeling capability like DoOAF 2.0. The ability to accurately map data items to data flows, and then to interface control document and reqnirements, is imperative for JPSS in meeting its operational commitments and is made possible through the DoDAF SV and DIV components.

American Institute of Aeronautics and Astronautics 5 B. Describing J1'SS Operations OV-4, JPSS Organizational Relations (Figure 3.) displays the relationships among the JPSS Program organizations; ifs stakeholder organizations, and its external support organizations. The JPSS organizational relationships and infonn.tion flows are sbown for the JPSS GS after it bas been developed and banded over to NOAA's·Office of Satellite & Products Operations (OSPO). At this stage, the JPSS Ground Project is in • maintenance support role to OSPO while working to develop the next Block upgrade. The Ground System has interfaces to the space segment developers for operational support (and products) related to the spacecraft and instruments. The Ground Project also has interfaces to international partners; JAXA and

Figure 3. bv-4, JPSS Organizational Relations Kongsberg Satellite ServIces (KSAT) for GCOM-Wl sensor data and EUMETSAT to provide SMD captured at the McMurdo Ground Stations to the EUMETSAT facility in Dannstadt, DE. The Ground System also retains interfaces at McMurdo for DMSP seusor data acquisition and routing back to the Continental United States (CONUS), and routes CoriolislWindSat and POES data from the KSAT stations back to CONUS. The Ground System is primarily focused on the acquisition of sensor data and the reduction of this into time sensitive weather and climate products. To this end, the Ground System has interfaces to the weather and climate data consumers: NESDIS, AFW A, FNMOC, NAVO and (for Suomi NPP) the GSFC SDS). All processed data is sent to NOAA's long-term weather/climate data archive storage system (CLASS). Organizational relationships are a major driver on the JPSS Ground System design, and therefore the OV-4 views (operational and development) encompass an important aspect of the overall NOANJPSS enterprise. These views have become an integral aspect of both JPSS technical and program management, more so than would be seen in the typical NASA mission.

American Institute of Aeronautics and Astronautics 6 -----~ ..• -.------

• -----:---

rr-_"...... -

t __ .~

Fi gure 4. OV-2, Operational Resource Flow Description for the Ground Network

The OV-2 shown in Figure 4 represents the operational resource flow description for the Ground Network. This OV-2 is extracted from a much larger OV-2 that represents the operational resource flow description for the entire JPSS GS. Each of the boxes in the figure represents a JPSS GS operational node that interfaces directly with the Ground Network Node in the center. The nodes internal to JPSS GS are shown in blue while the other colors represent nodes that supply JPSS GS with information (arrowhead to the Ground Network Node) or are users of JPSS information. The operational nodes are the 'performers' of the activities needed to operate the JPSS GS. In the figure, the Ground Network is the performer of the activities needed to handle the routing of data among all of the internal and external nodes in the JPS S GS. The data exchanges are shown as lines with the information that has been captured during the modeling effort between each pair of nodes. The activities involved with sending and receiving the information is internal to the performers shown in this diagram and are shown in the OV-5b diagrams. Information is that which is produced by one activity and is consumed by another for the consumer to be able to perform its following operational activity. Information items are traced in the operational views while the individual data items that make-up the information items are traced in the system ,-iews.

American Institute of Aeronautics and Astronautics 7 -----:;::------_._._----_._- r--··· .. - -- I

I -- . ______. ___• ______~ ... . . --JI -..-~- - -..---- ~~-:--._.J-_ _, . I ~' :::~__ J , C-c; -:::'--, I 1 _·_ · f' ~.- ~ ,.

I- I I,

, ,-

Figur e 5. OV-5a, Hierarchy of the Activities that are Performed by tbe JPSS GS Management & Operations Node

Figure 5 is the portion of the integrated Level 2 (Ground System-wide) performer/activity hierarchy diagram that shows the Management & Operations Node (MON - a performer) hierarchy of the JPSS GS Level 3 activity model. Grcund System reqnirements are driven by Level I reqnirements between the NOAA customer and the GSFC JPSS development organization, and the mission specific reqnirements (e.g., Suomi NPP, JPSS-I) that flow down into the JPSS GS. In addition, there are cross-support agreements with partner missions (e.g., DMSP, Metop, CoriolislWindSat) that create Level I reqnirements on the Ground System and Operations. For Level 2 JPSS GS activities, the driving program level reqnirements (which can span flight, ground and launch segments) are decomposed into the ground portion of the requirement, and then allocated to one or more of the 7 nodes of the GS. Each GS Node is modeled by L2 activities, which encompass the L2 reqnirements contained in the Ground System Requiremel)ts Document (GSRD). In the fignre, the MON is comprised of the following L2 activities in the model: Fleet!Ground Operations, Mission Planning, Flight Operations, Orbit! Attitnde Management, Ground Operations, Analysis and Trending, Training, Manage M&O Node, Upgrade System, Continuity of Operations. The model then decomposes these Level 2 Activities into more detailed Level 3 Activities, which are the basic building blocks of the 34 ConOps use cases, and also contain the requirements for the MON contractor to implement. For JPSS, the model provides complete traceability from L1 through L3, and how these requirements are decomposed and allocated.

American Instimte of Aeronautics and Astronautics 8 1 ___...... -·· ... I·~- --: r -:.:...... ;;.;::- , -,::,,~-- w.? I_ ..•.. : !'::~.~....•... j

..... _ ._ ------.-n-"--"-----+-

...... _.00_...... _.. . --..!....-.--'""- <___-- ...... u._...._-""_ _ - ...... --...... , ...... · __ ~. .-.... _--" ..... --...... -".,.. ---__-...... _"" ._,,--"'...... - - ...... -

Figure 6. OV-5b, Operational Activity Model for the Flight Vehicle Simnlator

Figure 6 depicts the workhorse viewpoint for the JPSS transition effort. The 34 ConOp Threads discussed above were adapted from the NPOESS em through DoDAF 2.0 modeling using OV -5b activity flows to establish the connection between concept of operations, architecture, and requirements. The 'perfonners' in the swim lanes are either ground system nodes, opemtors for a node, or external entities (external interfaces). The OV-5b views are critical in establishing the updated operational vision (capabilities) for the JPSS GS. These views capture the consensus use cases from the vast organizational interests internal to JPSS Ground Project and external stakeholders"

i. Figure 7. OV-6c, Event Trace Description for SMD Handling

American Institute of Aeronautics and Astronautics 9 Figure 7 is the OV-6c, Event Trace Description for Stored Mission Data Handling diagram. The diagram illustrates the sequential and parallel message flows between any two performers. The message flows add temporal ordering detail to the communications that occur between the performers that are shown in the OV- 5b as information exc ~ anges across swimlanes from one perfonner's activity to another's. When sequence and timing ate imperative to the system design, performance or interface structure, the OV -6c is developed to capture this infonnation in the model, which is then reflected in the requirements - or at times in operations procedures and processes. For example, the life cycle flow of weather data algorithms - from end product Ll performance specifications through operational code and metrics - involves various external stakeholders and GS nodes. The OV -6c is used to capture the stages of this flow in order to tie interface flows and functional requirements to the sequence of events and products.

C. The JPSS System Views

_._ f_ ,I,-. .... ,1.1· - j

.., ' " ~ ' ' ' ...~ r..,·.. - . .. , ' .."" ,"-' - -.... ~- ...... - • • _ • • • ...... , - ...... '... .'=0 _. .. ,.'''...,_..-...... -_... , ...... ~ .... - .;; .... I .... • ....· .. • ..""...... - -...... - :;':'C".::~:... , ._._ .....-, _..., .. ~.i": :.:..~. ';'~'" -..... ,:...... ~ ...... "' - ...... • , ___. .ow.....",". . - ~~-_~....,~.,,::' _.:...' : ...... -----r-- \:.;.~~~.~ .__ 0 .. ,• .. ' ...... , .--,..._. --.. z;:.. 4..... :~ .... , ..,. .. ""

Figure 8. SV-l, System Interface Description for Data Acquisition and Routing (DAcqR)

Figure 8 displays the SV-I for the Data Acquisition and Routing (DAcqR) thread, an extraction from the very large overall JPSS GS SV-1. The diagram shows the systems and data exchanges among them that are used to implement the JPSS DAcqR thread. The DAcqR thread moves data from the satellites, through the Ground Stations and Ground Network to the customers that perform their own data processing. JPSS only captures and routes this data for the ctistomers and does not process it. The data exchanges on an SV -I show the atomic data items that are pasoed on each exchange to make-up the information items that pass between the operational units and that are shown in the OV-2's and OV-5b's. This SV-I also displays the requirement documents that control the exchanges.

American Institute of Aeronautics and Astronautics 10 ! ,_. -. -;:.;;;~- i 'j r:=;:'''':':' - If: . j' ,' - - .- _.- :t 'o'I [;:: -;. - - [I" ..:.. ~_ ~~ ' ~ '-::_. I l ~ i II' :.~ ~:':-J" I ,'-:_':1, . ' I "e'T: , . 1-':.·. ..:.... I " i~:j il: r~g ~?FJ. ;;::i f=-~~·j j' 'r:=:J - ~f5 \.H ~. !.!'"_ ~:;; - -1 ;1- i..:.;.;-.. --:::' ~ -- I :: :: :: :,: I-_==_:~'_'.:"'_'~," '1-. f~.·~~~:-~:.:c::..;"".. :_':'.~.~.. ".:.-'J~' . f~·.;;;".-~·.~.·.~.,".:.·.~."--:-·-·. :.·.~.·.·.·.·.J. J F"·=· ..· ..I ' r.. ··c"'·'1 i '~:-"ji : :::: -.' , ":;11 i. iii! !: I ,.~!--,;:d:.... ~ I" 'I' ' .•••..,.. 1 ,I'~~ -,:- . /) ..! :'" :~-l:=1 '. C?'-lF;~ ::"~t '::: ,;. ...:r~;... : -:==--=-j:: ,: :: t.. t.=~ ~ _ - ••• -" ,...... ~- . . L- ,." , ," "

~ \.L~':-;:Ji,-- Figure 9. SV-4, System and Function Hierarchy showing the Mission Management Center (MMC) Functions and some other Systems that Share those Functions

Figure 9 is a portion of the much larger SV-4 that shows the system and function hierarchy. This SV·4 displays the hierarchy for the Mission Management Center (MMC) system where the Mission Operation Node activities are performed. For the JPSS Ground System the transition from Performers and Activities to Systems and Functions occurs when the OV series of views are converted to System Views (SVs). For the JPSS GS, this transition is performed in our MagicDraw (No Magic, Inc.) DoDAF/UPDM toolkit. Operational Activity attributes are assigned to the System Function class boxes shown, thus tying the activities to the functions and, therefore, the operations to the systems. Here the model captures the systems that will execute the actions. These are either 'as·built' for a deployed system or the implementation design in the case of new developments. For the JPSS Ground System, the systems views are a hybrid of existing NPP systems and functions as well as JPSS Block to new/enhanced systems and their requisite functions. Since requirements are linked to activities in the overall technical baseline, and systems implement these activities, the SV space now links systems to requirements (functional, interface, performance and design).

American Instirute of Aeronautics and Astronautics II ------

_~.'...;; I ..... " .... -.. ; I, ",,,_.J :

...... * ...... ,. ...- ...... -~ :"~..- ..., ...... ~, I ... ,.~ , ...... , ,'- ·',- '- (_"'...... 'f-I .~,.~., ~ ...... ~ ...... ~ .. . -_ ... I .~. -' , ...... + -~ ...... 1~~ Ir :~.:;r..:;.~.,'a~:;:"'~ ' · '"' '''' ~' -"" ! .. ' ..... '.• .~ ...... ".• ~ ...... '....,. ----- ==----'- -_ ... - Figure 10. SV -4, System Fuuctional Flow for System Maintenance and Upgrade

Figure 10 displays a second form of the SV -4 that shows the flow of data among the System Function Actions. This SV4 shows the System Function Actions conducted by each System (in the swimlane headers) and the data that flows among the System Function Actions within the systems to accomplish the System Maintenance and Upgrade (SMU) thread. This shows the SV translation of the OV·5b for SMU. By integrating SVs for each OV-5b, the model builds the overall system architecture that spans aU Use Cases,

American Institute of Aeronautics and Astronautics 12 Assigning System and Interface Requirements to Data Exchanges in the Model

Table 2. SV .6/,.:::S~;=o.:::::::='::::":7: to the Coriolis Satellite ,/ .; ".... .• /~ ....1' ...... ,/

0.:- -.- ppgrt - • Mk.:ibI ~ c.-r (MMCJ -.. !il3J Rb:~DISAWANID ~ ..unt SA. >'oN OGS ...... - - ~ D 10 ~ . 1IOn _ CorioII& End of eon.:t c .... VCDU to SA. WN4

IIIf uin(I MiL ~ _-"""=.'-'CGS="""=_---'-=C=,=""""=..=--'-- ______-""""'= '''''''=' __ C-=--______.__ _

Finally, the OV·5 series of diagrams define external interface performers connected to the system. In the case of the JPSS GS there are ronghly 25 key external interfaces on the operational system. Fignre 2 above showed the culmination of these interfaces, but the model allows the engineers to track need lines defines in the Use Cases (ConOps threads via OV·5b) to the interface control documents. All need lines between the JPSS Ground System and a specific external performer (e.g., the NOAA CLASS archive storage) define the interface. The JPSS Ground Project has leveraged the DoDAF 2.0 model to further manage and track the interface requirements across the JPSS GS (external and internal between GS Nodes). The SV·I and SV-4 diagrams illustrate the need lines among various systems supportiog GS nodes (performers). Need lines can represent numerous data types, formats, messages, etc. So the JPSS GS interface Control Documents are structured around Need Lines, similar to how system requirements in the specifications are structured along activities. Table 2, an SV -6 System Resource Matrix for interfacing to the Coriolis satellite, shows this decomposition of need lines into bundles of interface requirements. As the JPSS GS enters the design phase, Interface Control Documents will map functional and physical interfaces, including data mnemonics and definitions, back to IRD requirements, and thus to need lines in the architecture. Giving the JPSS Ground Project engineering team a complete lIl!IPping from implementation to design to requirements and to Use Cases, all captured and managed in the DoDAF 2.0 model

IV. Conclusion The JPSS Ground Project is overseeing the evolution/transition of the NPOESS era ground system into the JPSS era utilizing the power of DoDAF 2.0. Through the exploitation of the system modeling capabilities embodied in the UPDM (via SysML), and as implemented in the MagicDraw tool suite, the JPSS Ground Project has been able to develop a highly detailed and synchronized system model of the future JPSS GS. Through the model we have tied ConOps use cases to activity flows via the OV·5b and, where needed, the OV-6c. The OV activities form the functional containers within each level of the specification tree, allowing for allocation of requirements at each stage. Changes in ConOps Use cases can be reflected in requirements through the traceability afforded via the model. System Views map the operational space into deployed implementation space. Thus tying each system component to the top level requirements and Use Cases In addition, the model has been extended to cover management and defrnition of all external and internal interfaces, from requirements down. The model is also being used to defrne the system implementation and phasing in the transition from NPOESS to JPSS; which is being achieved via strategic course corrections. The JPSS conununity is large and divers. At its core are NOAA, NASA and the various weather organizations of the DoD. The Ground Project includes many NOAA and NASA organizations, and each of the 7 Nodes is a considerable development effort in itself. The viewsl[products from the JPSS GS DoDAF model are critical to establishing a conunon understanding and framework, and for conununicating this across the JPSS conununity. Weather Data Consumers, System Operators, Instrument/Climate Scientists and Engineers all conununicate and coordinate via the GS DoDAF model. It has become an invaluable management tool, beyond just the technical implementation.

American Institute of Aeronautics and Astronautics 13