Modeling Space Data Systems Architectures 6 Nov 2008

Modeling Space Data Systems Architectures 6 Nov 2008 Peter Shames NASA Jet Propulsion Laboratory, California Institute of Technology 6 Nov 2008 JPL Modelling Early Adopters (MEA)

Topics • Why views of system architectures? • Challenges of space system architectures – Existing terrestrial approaches must be adapted for space – Need a common architecture methodology and information model – Need appropriate set of viewpoints for the space domain • Reference Architecture for Space Data Systems (RASDS) – Description of set of viewpoints – Extension into Space Systems in general – Examples of use • Relationship to other methods – Do. DAF and others – Sys. ML – Adding RASDS viewpoints to Sys. ML 6 Nov 2008 JPL Modelling Early Adopters (MEA) 2

What is System Architecture and … • System architectures are complex, multi-faceted things – – – – – Hardware structures Software elements Functional composition Control and data flows Environment and interactions Organizational interfaces & contracts End-to-end communications paths Science, user, & operator interfaces And don’t forget the interactions among these, electrical, power, thermal, dynamic, etc • Where do you “stand” to get a view of all this? 6 Nov 2008 JPL Modelling Early Adopters (MEA) 3

… why Views? • As with any programming or system engineering activity … – Breaking a problem into pieces makes it more manageable – Smaller pieces are easier to work with – Logical coherence within a “piece” better supports reasoning about behavior and properties • Views are perspectives on an architecture, intended to give us useful leverage in understanding and analyzing the system – But, we need to be clear about what is represented in any given viewpoint, and – We also need to model the relationships among the elements shown in different views … – A structural element may also act as an electrical ground plane and a thermal shield • So how to we arrive at a useful set of views and … – How does this relate to the current methods that are in vogue, I. e. Sys. ML and Do. DAF? 6 Nov 2008 JPL Modelling Early Adopters (MEA) 4

Architecting and Engineering Space Systems is Hard • Many Stakeholders – Organizations (NASA, international partners, contractors) – Competing requirements (cost, schedule, risk, science, technology, survivability, maintainability, buildability) • Many different system aspects – – – Logical (functionality, information, control) Physical (hardware, software, environment) Interoperability and cross support Science & operational capabilities Autonomous and human mediated operations …motion • Long and complex system (of systems) lifecycle – Development phases • Requirements, design, implement, I&T, V&V • Operations and sustaining – Cradle to grave lifecycle – Mission view vs infrastructure view 6 Nov 2008 JPL Modelling Early Adopters (MEA) 5

System Architecture Model Objectives • Provide clear & unambiguous views of the design • Show relationship of design to requirements and driving scenarios Even document driven design processes concerns in the model • Separate design benefit from clear presentation to maintain of of freedom to do trades degreesarchitectural elements and design. Required tool capabilities and MBE elements • Detail the model & views to the level appropriate for shown like this. further systems engineering, support evolving design • Enable concurrent design of spacecraft, ground systems, science operations, control systems, and components • Establish system engineering (SE) controls over the allocations and interfaces • Provide executable models of the interactions (future) 6 Nov 2008 JPL Modelling Early Adopters (MEA) 6

Existing System Architecture Methods Inadequate for Space • Existing methods tacitly assume modeled objects are fixed in space and are usually in continuous and instantaneous communication – Do. DAF, RM-ODP, TOGAF, Zachman, Krutchen 4+1, … • Space systems tend to violate these assumptions – Therefore, any of these modeling methodologies must be adapted to describe space systems • Viewpoints must accommodate complex logical and physical interactions – UML, Sys. ML provide design diagrams, but do not directly support the necessary viewpoints – Do. DAF has only three “views” and is intended to support system acquisition, not really design 6 Nov 2008 JPL Modelling Early Adopters (MEA) 7

RM-ODP & RASDS Characteristics • The specification of a complete system in terms of viewpoints. • The use of a common object model for the specification of the system from every viewpoint. • The use of views to tailor user or domain specific analyses of the system. • The definition of a modeling infrastructure that provides support services for system applications, hiding the complexity and problems of defining mission specific models. • The definition of a set of common transformation functions that provide general services needed during the design and development of space systems. • A framework for the evaluation of conformance of models and designs based on conformance points. 6 Nov 2008 JPL Modelling Early Adopters (MEA) 8

Space Data System Several Architectural Viewpoints Business Concerns Organizational perspective Enterprise Physical Concerns Node & Link perspective Connectivity Functional Computational Concerns Functional composition Information Communications Data Concerns Relationships and transformations Protocol Concerns Communications stack perspective Derived from: RM-ODP, ISO 10746 Largely compliant with IEEE 1471 -2000 6 Nov 2008 JPL Modelling Early Adopters (MEA) 9

RASDS Semantic Information Model Derivation Process RASDS as Architectural Framework * Engineering Viewpoint • System Design & Construction Enterprise Viewpoint Connectivity Viewpoint Functional Viewpoint Information Viewpoint Communications Viewpoint • Organizations • Connectivity • Components & connectors • Physics of Motion • End to End View • External Forces • Performance • Functional Structure • Information & information management • Protocols & comm standards • Functional allocation • People • Distribution of functions and trade-offs • Use Case. Scenarios • Development • Contracts/Agreeme nts • Validation & verification Augment to Capture: • Based on RMODP** • Mission Design & Drivers • Cross Support Service • Mass • Thermal Extended by: MBED Project, Shames & Skipper 6 Nov 2008 • Cross Support Services • Power • Enterprise Risks • End to End View • End to end Information Transfer Mechanisms • Structure • Cost • End to End View • Scenarios Augment to Capture: • Requirements • Functional Behavior & interfaces • Orbit • Propulsion JPL Modelling Early Adopters (MEA) * Reference Architecture for Space Data Systems (RASDS) ** Reference Model Open Distributed Processing (RMODP, ISO 10746 spec) 10

RASDS Top Level Object Ontology Composed Of Perspective (Viewpoint) Organization • Mission • Requirements • Objectives • Goals • Scenarios Fulfilled. By Composed. Of • Defines Objects • Defines Relations • Defines Rules • Exposes Concerns Owns/Operates Fulfills Calls Function • Logical structure • Behavior • Interfaces • Constraints Information Produces Consumes Is. Allocated. To • Data • Metadata • Rules Composed. Of Contains. Instances Node Provides. Service Uses Implemented. On Communication • Protocol stack • Standards • Type • Attributes • Ports • Location Affects Connect. Via Environment • Physical Environs • Attributes Connect. To. Port Associated. With Link • Type • Attributes 6 Nov 2008 JPL Modelling Early Adopters (MEA) 11

Space Data System Architectural Notation Object with Interface Object Encapsulation Management Node (physical location) Node Encapsulation (physical aggregation) Service External Concerns Logical Link 6 Nov 2008 Physical Link JPL Modelling Early Adopters (MEA) Space Link (rf or optical) 12

Mars Exploration Program Example Enterprise View Instr S Instrument Integration Cross- Support Agreements MEx Proj Science PI Org DSMS NASA/ JPL MMO Tracking Agreements Enterprise Concerns: Requirements Objectives Roles Policies Activities Configuration Contracts / agreements Lifecycle / Phases 6 Nov 2008 Mars Exploration Program Federation MSL Proj MRO Proj Operations Agreements ICDs Service Z Exo. Mars Prog S ESA MRO Ops S/C Contractor JPL Modelling Early Adopters (MEA) 13

Functional View Example Functional Objects & Interactions Monitor & Control Mission Planning Mission Analysis Spacecraft Analysis Directive Generation Directive Management Data Repository Data Acquisition Orbit Determ LT Data Repository Tracking Functional Concerns: Behaviors Interactions Interfaces Constraints 6 Nov 2008 Directive Execution JPL Modelling Early Adopters (MEA) Radiometric Data Collect 14

Connectivity View Nodes & Links SPACECRAFT Mission Planning Computer Spacecraft Transceiver Internet S/C Bus Space Link Spacecraft Control Computer 6 Nov 2008 Ground Tracking Station Command & Data Handling Computer ACS Computer JPL Modelling Early Adopters (MEA) Science Instrument Connectivity Concerns: Distribution Communication Physical Environment Behaviors Constraints Configuration 15

Connectivity View Mapping Functional Elements to Nodes Science Spacecraft Monitor & Directive Control Execution Data Acquisition Repository Attitude Control Comm Mgmt Radiometric Data Collect Tracking Station 6 Nov 2008 Science Institute Radiometric Data Collect Tracking LT Data Repository (Archive) Mission Planning Directive Generation Data Repository Data Monitor & Directive Generation Repository Control Management Spacecraft Mission Analysis Orbit Determ Traj Design S/C Control Center JPL Modelling Early Adopters (MEA) Allocation View: Implemented Functions End to End Behavior Performance Throughput Trade studies 16

Communications Viewpoint Protocol Objects End-To-End Command Processing GROUND SYSTEM Command Generation SPACECRAFT Payload Commands Command Execution C&DH Packet Tracking Station TC Space Data Link (Relay) SLE CLTU TCP/ IP PPP Packet (Relay) Packet TC Space Frame Data Link SLE CLTU TCP/ IP Packet 6 Nov 2008 TCP/ IP RF Generation RF Onboard Generation Physical TCP/ IP Onboard Physical JPL Modelling Early Adopters (MEA) Communications Concerns: Standards Interfaces Protocols Technology Interoperability Suitability 17

MSL End-End Network Architecture Example Connectivity Overview MSL Planning and Control Center MSL Rover Command Generation C&DH Large SSR MRO Control Center C&DH Cmnd File Processing Relay Command Generation Cmnd Integ File Prep Relay File Handling File Mgmt In-situ delivery DSN Space Data Link Delivery Team Overlay MSL MRO DSMS Contractor XMTR Rover Command Execution Electra Relay Command Execution Space Link Processing Link Prep 6 Nov 2008 SSR MRO Spacecraft File Xfer SDST Deep Space Link Data Flow Overlay Uplink Downlink Relaying JPL Modelling Early Adopters (MEA) Payload Instr Command Execution Electra - lite In-situ Delivery Proximate Link Performance Overlay Processor speed CPU requirements Link capacities Throughput Storage capacities 18

Relationship to Other Methods • Comparison table of architecture methods – RASDS, RM-ODP, Do. DAF, Krutchen, Zachman • Brief discussion of Do. DAF – Do. DAF & RASDS Elements – Do. DAF Products & RASDS Views (more in backup) • Sys. ML adaptation for system architecture – Diagram types and views – Mapping to RASDS 6 Nov 2008 JPL Modelling Early Adopters (MEA) 19

Comparison of Architecture Methods RASDS RM-ODP Do. DAF Krutchen 4+1 Zachman Enterprise Operational (RUP-SE adds this) People Functional Computational System Logical Function Connectivity Engineering (node & alloc, not environment & interactions) System (not environment & interactions) Process & Physical (not environment & interactions) Network (not environment & interactions) Information Operational & System Process (subset) Data Communications Technical (not protocol stacks & EEIS) System (partial) & Technical (standards only) Operational Engineering (development) Derived from: Maier, ANSI/IEEE 1471 and 6 Nov 2008 System Engineering Scenarios Motivation & Time Development JPL Modelling Early Adopters (MEA) 20

Do. DAF (Notional) RASDS (Notional) Performs Operational Activity Is implemented by Generates or consumes Owns Hosts System Function Enterprise Object Operational Node System Node Functional Object Hosts Interacts over Connects Node Generates or consumes Is exchanged between System Data Performs Link Is exchanged over Information Object “RAS-DAF” Operational Activity Performs Owns Is implemented by System Function Generates or consumes 6 Nov 2008 Ent Obj / Ops Node Hosts (System) Node Is exchanged between System Data Performs Hosts Connects Generates or consumes Information Object JPL Modelling Early Adopters (MEA) Functional Object Interacts over Link Is exchanged over Implemented by Protocols 21

Sys. ML Diagram Types Source: Sys. ML Partners 6 Nov 2008 JPL Modelling Early Adopters (MEA) 22

Mapping RASDS into Sys. ML • No simple one for one mapping • RASDS uses Viewpoints to expose different concerns of a single system • Sys. ML uses specific diagrams to capture system structure, behavior, parameters and requirements – Several Sys. ML diagrams, focused on different object classes, may be usefully applied to any given RASDS Viewpoint • Extended Sys. ML Views may be used to define the relationships between Viewpoints and Diagrams • Sys. ML methods & tools can support more accurate fine grained modeling of structure, relationships and behavior than was expected of RASDS • But, Sys. ML needs to be adapted, via a profile or some other method, to guide use of appropriate views 6 Nov 2008 JPL Modelling Early Adopters (MEA) 23

Mapping RASDS into Sys. ML • Enterprise – Organizational structure & behavior diagrams – Use case, activity, and sequence diagrams – Requirements & constraints for rules, policies & agreements • Connectivity – Physical structure, composition, behavior & class diagrams – Parametric diagram for physical link & environment characterization • Functional – Logical structure, behavior & class diagrams – Activity, state chart, parametric, & timing diagrams • Informational – Information class & parametric diagrams • Communication – Protocol structure & behavior diagrams – State machine, sequence, activity & timing diagrams 6 Nov 2008 JPL Modelling Early Adopters (MEA) 24

Enterprise View Using Sys. ML Use Case Diagram <> Enterprise: Use Case Mars Exploration Program Federation <> Agency ABC <> Science Team <> <> Cross Support Agreement Agency QRS <> <> Mission Operations Team <> TT&C Service B Operations Contract Science Team <> <> GTN B Relay Service A <> Mission Q Mission A <> 6 Nov 2008 <> <> Instr C Service Operations Team <> JPL Modelling Early Adopters (MEA) Instrument Team <> Instrument Integration 25

Connectivity View (Nodes & Links) Using Sys. ML Components (Spacecraft) Spacecraft CDH : Cmd. Data. Handling. System s: Sensor dm : Data. Manager Cmnd. In Port sci. Instr : science. Instrument Sensor. Data. Done. Port ecu : Execution Control Unit Instr. Cmnd Port ap : Aperture Obs. Fin Port oc : Obs. Control ic : Instr. Control Take. Obs Telem. Port Tele. Cmnd. Port dl : Down. Link ul : Up. Link Derived from: Sys. ML Partners 6 Nov 2008 ap: Mechanical JPL Modelling Early Adopters (MEA) RFAntenna 26

Connectivity View (Nodes & Links) Using Sys. ML Components (MOS & TT&C Systems) MOS : Mission. Ops. System dm : Data. Manager Obs. Req Port TT&C : Track. Telem. Command Telem Port TM : Telemetry Telem. Data Telem. Done. Port MOP : Mission Ops. Planning Cmnd. Data DL Port dl : Down. Link Tele Cmnd Port Re Trans UL Port TC : ul : Up. Link Telecommand RF Ant Cmnd Port SC : Send. Cmnd Pt : Pointing. Data 6 Nov 2008 JPL Modelling Early Adopters (MEA) Ant: Mechanical 27

Connectivity View (Composition) Using Sys. ML Components Spacecraft CDH : Cmd. Data. Handling. System dm : Data. Manager Data. Done Port sci. Instr : science. Instrument AP: S: Mechanical Sensor Data Cmndin Port ecu : Execution Control Unit Instr. Cmnd Port Ap : Aperture Obs. Fin Port oc : Obs. Control MOS : Mission. Ops. System Telem Port dm : Data. Manager TT&C : Track. Telem. Command TM : Telemetry Telem. Data Telem. Done Port Obs. Req Port MOP : Mission Ops. Planning Take Obs Cmnd. Data DL Port Telem. Port Tele. Cmnd. Port dl : Down. Link Tele Cmnd Port Re Trans UL Port TC : Telecommand ul : Up. Link RF Ant IC : Instr. Control dl : Down. Link ul : Up. Link RFAnt RF: link [Ka. Band] RF: link [X-band] Cmnd Port SC : Send. Cmnd Pointing Data Pt : Pointing Ant: Mechanical Global structure inherited by each kind of Spacecraft … … and constrained for each kind 6 Nov 2008 JPL Modelling Early Adopters (MEA) 28

Functional View Using Sys. ML Activity Diagram Mission Ops retrans. Req Plan Obs. Seq 6 Nov 2008 obs. Complete Prepare Cmnd planned. Obs TT&C Network S/C Control Instrument Spacecraft Ground System • Showing component allocations (optional) ready. Cmnd Xmit Cmnd Recv Cmnd Finish Obs. Seq Accept Data Recv Data Execute Cmnd retrans. Data. Req Store Data Transmit Data Instr Cmnd Take Obs JPL Modelling Early Adopters (MEA) 29

Informational View Using Sys. ML Class Diagram • Reusable, refinable information structure: <> Instr. Cmnd. File describes <> Instr. Cmnd. List <> Instr. Cmnd. Meta. Data 1. . * 1 1. . * <> <> Instr. Cmnd. Semantics Derived from: Sys. ML Partners 6 Nov 2008 <> Instr. Cmnd. Structure Global representation inherited by each kind of Information Object JPL Modelling Early Adopters (MEA) 30

Communication View (Protocol Objects) Using Sys. ML Component Diagram MOS : Mission. Ops. System SC : Send. Cmnd Port SC : Space. Craft MOP : Mission Ops. Planning <> Cmnd. In Port TC : ECU : Execution Tele. Cmnd Control Unit <> TP: Transport. Layer <> IP: Internet. Layer <> LL: Link. Layer <> PL: Phys. Layer RF: link [Xband] Cmnd. Data: RF Derived from: Sys. ML Partners 6 Nov 2008 JPL Modelling Early Adopters (MEA) 31

Communication View Using Sys. ML State Machine Diagram <> TP: Transport. Layer ev. Send / transmit. Count=0 Sending ev. Done. Send / ++transmit. Count Idle tm(Wait Time) [transmit. Count

Developing Useful Viewpoints • Viewpoint Specification Examples – IEEE 1471 & RASDS Approach – Stakeholders, concerns, modeling language, consistency & completeness • Extensions to RASDS needed for Space System MBE – May need extended Physical (Connectivity) view – May need other views (Service) • Alignment with JPL SE Practices – Viewpoint excerpt from Rules! Doc ID 75012 6 Nov 2008 JPL Modelling Early Adopters (MEA) 33

Viewpoint Elements - Functional Example • Stakeholders: system engineers, acquirers, developers, users, and maintainers • Concerns: the functions that are required for the system to meet its requirements and execute its All five RASDS viewpoint elements scenarios. Are documented in CCSDS 311. 0 -M-1 • Modeling Language: functional objects and relationships, interfaces, behaviors, constraints • Consistency & Completeness Methods: every requirement maps to at least one function, no requirement is not mapped to a function, no function is not mapped to a requirement, and there is structural data and control flow consistency 6 Nov 2008 JPL Modelling Early Adopters (MEA) 34

Typical Functional Views • Functional Dataflow view – An abstract view that describes the functional elements in the system, their interactions, behavior, provided services, constraints and data flows among them. Defines which functions the system is capable of performing, regardless of how these functions are actually implemented. • Functional Control view – Describes the control flows and interactions among functional elements within the system. Includes overall system control interactions, interactions between control elements and sensor / effector elements and management interactions. 6 Nov 2008 JPL Modelling Early Adopters (MEA) 35

Viewpoint Elements - Connectivity Example • Stakeholders: system engineers, sub-system engineers, acquirers, developers, operators, users, and maintainers • Concerns: implemented functions, allocation to the physical structures of the system, their connections, and how they interact with the environment • Modeling Language: engineering objects (S/W or H/W), physical objects (nodes) and their connections (links), physical behavior, motion and interactions, the environment, constraints • Consistency & Completeness Methods: every functional element maps to at least one physical element, no functional element is not mapped, no physical element is not mapped to a function, and there is structural integrity and consistency 6 Nov 2008 JPL Modelling Early Adopters (MEA) 36

Typical Connectivity (& Physical) Views • • 6 Nov 2008 Data System view – Describes instruments, computers, and data storage components, their data system attributes and the communications connectors (busses, networks, point to point links) that are used in the system. Telecomm view – Describes the telecomm components (antenna, transceiver), their attributes and their connectors (RF or optical links). Navigation view – Describes the motion of the major elements of the system (trajectory, Connectivity Views use different subsets path, orbit), including their interaction with external elements and forces that are outside of the control of the same physical objects, butto understand system behavior system, but that must be modeled with it are (planets, asteroids, solar pressure, gravity) examined from different perspectives Structural view – Describes the structural components in the system (s/c bus, struts, and use different attributes. panels, articulation), their physical attributes and connectors, along with the relevant Space System (mass, stiffness, attachment) structural aspects of other components MBE may require Thermal view – Describes the active andpassive thermal components in the system other views and object types. (radiators, coolers, vents) and their connectors (physical and free space radiation) and attributes, along with thermal properties of other components (i. e. instruments as thermal sources (or sinks), antennas or solar panels as sun shade) Power view – Describes the active and passive power components in the system (solar panels, batteries, RTGs) within the system and their connectors, along with the power properties of other components (data system and propulsion elements as power sinks and structural panels as grounding plane) Propulsion view – Describes the active and passive propulsion components in the system (thrusters, gyros, motors, wheels) within the system and their connectors, along with the propulsive properties of other components JPL Modelling Early Adopters (MEA) 37

• Connectivity (& Physical) Viewpoint Component / Connector (Node / Link) Examples Data System – Components (CPU, instruments, SSR) – Connectors (network, data bus, serial lines, backplane) • Telecomm – Components (transmitter, receiver, antenna) – Connectors (RF link, optical link, waveguide) • Structural – Components (S/C bus, physical link, arm, struct attrib of other components) – Connectors (joint, bolt (incl explosive), weld) • Power – Components (solar panel, battery, RTG, switches, power attrib of other components) – Connectors (power bus) • Thermal – Components (cooler, heater, thermal attrib of other components) – Connectors (heat pipe, duct, free space radiation) • Propulsion – Components (motor, wheel, thruster) – Connectors (contact patch, gravity ) 6 Nov 2008 JPL Modelling Early Adopters (MEA) 38

JPL SE Practices, Doc 75012 Table 3. Architectural Viewpoints • 1 Programmatic – – • 2 Functional – – • a. Selection of technology and standards to develop the space system. b. Standards and technologies chosen to provide the communications, processing, functionality and presentation of information in the space system. . . 7 Lifecycle Phases – – – 6 Nov 2008 a. Allocation of abstract functions to selected physical components of the system. b. Selection of approach for designing and implementing software components. c. Design of control systems, consideration of subsystem interactions, control system elements, and elements of system under control. . . 6 Technical Infrastructure and Standards – – • a. Semantics of the information and the information processing performed b. Information managed by the space system and the structure, content, semantics, type, and relationships among the data used within the system. . . 5 Software Engineering – – – • a. The physical decomposition of the space system into components that interact across connectors. b. The physical aspects of the space system and the external environment within which it operates, the physical behavior (and motion) of the components relative to the environment. . . 4 Information – – • a. Functional decomposition of the system into objects that interact at interfaces b. Behavior of the functional elements and their functional relationships. . . 3 Physical – – • a. Purpose, scope, and objectives b. Organization, including the work breakdown structure. . . a. Development b. Integration c. Assembly, test, and launch operations (ATLO) [verification and validation (V&V)]. . . JPL Modelling Early Adopters (MEA) 39

Summary • • Many different methods can be used to model space system and data system architectures RASDS / IEEE 1471 concepts of viewpoints and related formal methods can be directly used to support space data system designs – Several projects have used RASDS successfully, ask for details – An approach for adapting Sys. ML to add useful views has been presented – There is work being done on UML for ODP and Do. DAF profiles • Even in a “document driven” process adopting an appropriate set of views is a powerful way to structure information – Word & Power. Point – This is aligned with latest JPL SE Practices, Doc 75012 • Moreover, adoption of a formalized modeling environment based on Sys. ML will aid description of complex system architectures – Templates or profiles supported by the tools themselves (and adaptable) – Links and relationships managed by tools – Formalized models, integrated requirements & design • Next Steps: Develop an architecture profile for use at JPL – Use Sys. ML tool in combination with RASDS or adapted views – Document a basic practice for doing model based design in this environment – Use the approach & tool on a real project 6 Nov 2008 JPL Modelling Early Adopters (MEA) 40

BACKUP 6 Nov 2008 JPL Modelling Early Adopters (MEA) 41

Definitions of Do. DAF Views 6 Nov 2008 JPL Modelling Early Adopters (MEA) 42

Do. DAF Elements and Their Relationships (Partial and not Exact) Operational Activity Performs Is Implemented By System Function Generates or Consumes Hosts System Data Operational Node Owns System Node Is Exchanged Between Source: Takahiro Yamada, SAWG Chair 6 Nov 2008 JPL Modelling Early Adopters (MEA) 43

Correspondence Between RASDS and Do. DAF Elements RASDS Elements Operational Nodes (OV-2) Enterprise Objects (EV) Needlines (OV-2) Enterprise Interactions (EV) Information Elements (OV-3) Information Objects (IV) Operational Activities (OV-5) Enterprise Operations (EV) Systems Nodes (SV-1) Nodes (CV) Systems (SV-1) Sub-nodes (CV) System Interfaces (SV-1) Links (CV) Key Interface (SV-1) Cross-support interface (CV) System Functions (SV-4) Functional Objects (FV) System Data (SV-6) Information Objects (IV) Source: Takahiro Yamada, SAWG Chair 6 Nov 2008 JPL Modelling Early Adopters (MEA) 44

Correspondence Between RASDS and Do. DAF Views (1/2) DODAF View and Product RASDS Viewpoint Overview and Summary Information (AV-1) None Integrated Dictionary (AV-2) None High-Level Operational Concept Graphic (OV-1) None Operational Node Connectivity. Description (OV-2) Enterprise Viewpoint Operational Information Exchange Matrix (OV-3) Information Viewpoint Organizational Relationships Chart (OV-4) Enterprise Viewpoint Operational Activity Model (OV-5) Enterprise Viewpoint Operational Rules Model, etc (OV-6) None Logical Data Model (OV-7) Information Viewpoint Systems Interface Description (SV-1) Connectivity Viewpoint Systems Communications Description (SV-2) Comm. Viewpoint Systems-Systems Matrix (SV-3) None Source: Takahiro Yamada, SAWG Chair 6 Nov 2008 JPL Modelling Early Adopters (MEA) 45

Correspondence Between RASDS and Do. DAF Views (2/2) DODAF View and Product RASDS View Systems Functionality Description (SV-4) Functional Viewpoint Operational Activity to Systems Functionality Traceability Matrix (SV-5) Relationships defined Systems Data Exchange Matrix (SV-6) Information Viewpoint Systems Performance Parameters Matrix (SV-7) Connectivity Viewpoint Systems Evolution Description (SV-8) None Systems Technology Forecasts (SV-9) None Systems Functionality and Timing Descriptions (SV-10) None Physical Schema (SV-11) Information View Technical Standards Profile (TV-1) (partially, Comm. Viewpoint) Technical Standards Forecast (TV-2) None Source: Takahiro Yamada, SAWG Chair 6 Nov 2008 JPL Modelling Early Adopters (MEA) 46

Unified Object Representation Management Interfaces: How objects are configured controlled, and reported upon Object Service Interfaces: How services are requested & supplied Core Functions What the object does External Interfaces: How external elements are controlled Concerns: Issues Resources Policies 6 Nov 2008 JPL Modelling Early Adopters (MEA) 47

Information Objects Relationship to Functional View S/C Event Plans Observation Plans Directive Generation Command Execution Directive Execution Actual Data Objects Operation Plans Commands Realization Data Models Realization Command Schema & Structure Definition Operations Plan Schema & Structure Definition 1. . n Information Object Data Object Representation Information Semantic Information 6 Nov 2008 Information Objects are exchanged among Functional Objects Instantiation Abstract Data Architecture Meta-models S/C Commands Instrument Commands Structure Information Data Object Representation Information Semantic Information Structure Information JPL Modelling Early Adopters (MEA) Information Concerns: Structure Semantics Relationships Permanence Rules