modeling space data systems architectures 6 nov 2008 peter shames nasa jet propulsion laboratory,...

Modeling Space Data Systems Modeling Space Data Systems ArchitecturesArchitectures

6 Nov 2008

Peter ShamesNASA Jet Propulsion Laboratory, California Institute of Technology

6 Nov 2008 JPL Modelling Early Adopters (MEA) PS 2

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– DoDAF and others– SysML – Adding RASDS viewpoints to SysML


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, etc

• Where do you “stand” to get a view of all this?


… 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. SysML

and DoDAF?


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

• 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

…motion


System Architecture Model Objectives

• Provide clear & unambiguous views of the design• Show relationship of design to requirements and

driving scenarios• Separate design concerns in the model to maintain

degrees of freedom to do trades• Detail the model & views to the level appropriate for

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)

Even document driven design processes benefit from clear presentation

of architectural elements and design. Required tool capabilities and MBE elements

shown like this.


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– DoDAF, 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, SysML provide design diagrams, but do not directly

support the necessary viewpoints– DoDAF has only three “views” and is intended to support

system acquisition, not really design


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.


Space Data System Several Architectural Viewpoints

EnterpriseBusiness ConcernsOrganizational perspective

ConnectivityPhysical ConcernsNode & Link perspective

FunctionalComputational ConcernsFunctional composition

InformationData ConcernsRelationships and transformations

CommunicationsProtocol ConcernsCommunications stack perspective

Derived from: RM-ODP, ISO 10746Largely compliant with IEEE 1471-2000


RASDS Semantic Information Model Derivation Process

RASDS as Architectural Framework *Connectivity

Viewpoint•Connectivity

•Components & connectors

•Physics of Motion

•End to End View

•External Forces

•Performance

Enterprise Viewpoint

•Organizations

•People

•Use Case-Scenarios

•Contracts/Agreements

* Reference Architecture for Space Data Systems (RASDS)

** Reference Model Open Distributed Processing (RMODP, ISO 10746 spec)

Functional Viewpoint

•Functional Structure

•Functional Behavior & interfaces

•End to End View

•Cross Support Service

Communications Viewpoint

•Protocols & comm standards

•End to end Information Transfer Mechanisms

•Cross Support Services

Information Viewpoint

•Information & information management

•Scenarios

•End to End View

Augment to Capture:

•Structure

•Power

•Mass

•Thermal

•Orbit

•Propulsion

Engineering Viewpoint

•System Design & Construction

•Functional allocation

•Distribution of functions and trade-offs

•Development

•Validation & verification

• Based on RMODP**

Augment to Capture:

•Mission Design & Drivers

•Requirements

•Cost

•Enterprise Risks

Extended by: MBED Project, Shames & Skipper


RASDSTop Level Object

Ontology

Function

• Behavior

• Interfaces

• Constraints

• Logical structure

Link

• Type

• Attributes

Communication

• Protocol stack

• Standards

Organization

• Requirements

• Objectives

• Goals

• Scenarios

• Mission

FulfilledBy

Fulfills

IsAllocatedTo

ComposedOf

Composed Of

ComposedOf

ContainsInstances

Produces

Consumes

ConnectVia

ConnectToPort

Uses

ProvidesService

AssociatedWith

ImplementedOn

Information

• Data

• Metadata

• Rules

Owns/Operates

Node

• Type

• Attributes

• Ports

Calls

Environment

• Physical Environs

Affects

• Location

• Attributes

Perspective(Viewpoint)

• Defines Objects

• Defines Rules

• Exposes Concerns

• Defines Relations


Space Data System Architectural Notation

Object Object withInterface Object

Encapsulation

Node(physical location)

LogicalLink

Space Link(rf or optical)

PhysicalLink

Management

Service External

Concerns

Node Encapsulation(physical aggregation)


Mars Exploration Program Example Enterprise View

Mars ExplorationProgram Federation

MSL Proj

MRO Ops

MMO

Service Z

DSMSMRO Proj

NASA/JPL

S/C Contractor

MEx Proj

Prog S

ExoMars Prog

ESA

OperationsAgreements

Cross- SupportAgreements

Enterprise Concerns:RequirementsObjectivesRolesPoliciesActivitiesConfigurationContracts / agreementsLifecycle / Phases

Instr SInstrumentIntegration

SciencePI Org

TrackingAgreements ICDs


Functional ViewExample Functional Objects & Interactions

MissionPlanning

MissionAnalysis

SpacecraftAnalysis

Monitor &Control

DirectiveGeneration

DataAcquisition

Orbit Determ

TrackingRadiometricData Collect

LT DataRepository

DataRepository

DirectiveExecution

DirectiveManagement

Functional Concerns:BehaviorsInteractions InterfacesConstraints


Connectivity ViewNodes & Links

Mission PlanningComputer

SpacecraftControl

Computer

Space Link

Internet

GroundTrackingStation

Command &Data Handling

Computer

ACSComputer

S/C Bus

ScienceInstrument

SpacecraftTransceiver

Connectivity Concerns:DistributionCommunicationPhysical Environment BehaviorsConstraints Configuration

SPACECRAFT


Connectivity ViewMapping Functional Elements to Nodes

Science Spacecraft Science Institute

S/C Control CenterTracking Station

MissionPlanning

DirectiveGeneration

LT DataRepository

(Archive)Data

Repository

MissionAnalysis

SpacecraftAnalysis

Monitor &Control

Orbit Determ

RadiometricData Collect

DirectiveManagement

DataRepository

Tracking

TrajDesign

DirectiveGeneration

CommMgmt

Monitor &Control

DataAcquisition Tracking

RadiometricData Collect

DataRepository

DirectiveExecution

AttitudeControl

CommMgmt

Allocation View:Implemented FunctionsEnd to End BehaviorPerformanceThroughputTrade studies


Communications Viewpoint Protocol Objects

End-To-End Command Processing

CommandGeneration

CommandExecution

TC SpaceData Link

SLECLTU

Packet (Relay)

TC SpaceData Link

RFGeneration

Commands

TCP/IP

PPP

SLECLTU

TCP/IP

PPP

TC SpaceData Link (Relay)

RFGeneration

Tracking Station

C&DH

GROUNDSYSTEM

OnboardPhysical

OnboardPhysical

Packet

Payload

TCP/IP

TCP/IP

SPACECRAFT

Packet

Frame

Packet

Communications Concerns:Standards

InterfacesProtocols

TechnologyInteroperabilitySuitability


MSL End-End Network Architecture Example Connectivity Overview

RelayCommandGeneration

Space Data LinkDelivery

DSN

FilePrep

MROControl Center

C&DH

Payload

MSL Rover

SSR

InstrCommandExecution

RoverCommandExecution

Electra- lite

RelayCommandExecution

Cmnd FileProcessing

C&DH

Relay

MRO Spacecraft

Large SSR

FileMgmt

FileHandling

Electra

In-situdelivery

In-situDelivery

SDST

XMTR

LinkPrep

Space LinkProcessing

Deep Space Link

ProximateLink

RoverCommandGeneration

MSL Planning andControl Center

FileXfer

CmndInteg

Team Overlay MSL MRO DSMS Contractor

Data Flow Overlay Uplink Downlink Relaying

Performance Overlay Processor speed CPU requirements Link capacities Throughput Storage capacities


Relationship to Other Methods

• Comparison table of architecture methods– RASDS, DoDAF, Krutchen, Zachman

• Brief discussion of DoDAF– DoDAF & RASDS Elements– DoDAF Products & RASDS Views (more in

backup)

• SysML use for system architecture– Diagram types– Mapping to RASDS


Comparison of Architecture Methods

Derived from: Maier, ANSI/IEEE 1471 and System Engineering

RASDS RM-ODP DoDAF Krutchen 4+1 Zachman

Enterprise 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 Information Operational & System

Process (subset) Data

Communications Technical (not protocol stacks & EEIS)

System (partial) & Technical (standards only)

Operational Scenarios Motivation & Time

Engineering (development)

Development

FunctionalObject

Node Link

InformationObject

Performs

Owns

Connects

Generates or consumes Is exchanged

over

EnterpriseObject

Interacts over

Hosts

Operational Node

SystemFunction

System Node

System Data

Performs

Is implemented by

Hosts

Generates or consumes Is exchanged

between

Operational Activity

Owns

DoDAF (Notional) RASDS (Notional)

FunctionalObject

(System)Node

Link

InformationObject

Performs

Owns

Connects

Generates or consumes

Is exchanged over

Ent Obj /Ops Node

Interacts over

Hosts

SystemFunction

System Data

Performs

Is implemented by

Hosts

Generates or consumes

Is exchanged between


Protocols

Implemented by

“RAS-DAF”


SysML Diagram Types

Source: SysML Partners


Mapping RASDS into SysML

• No simple one for one mapping• RASDS uses Viewpoints to expose different concerns of a

single system• SysML uses specific diagrams to capture system structure,

behavior, parameters and requirements– Several SysML diagrams, focused on different object classes, may

be usefully applied to any given RASDS Viewpoint

• Extended SysML Views may be used to define the relationships between Viewpoints and Diagrams

• SysML methods & tools can support more accurate fine grained modeling of structure, relationships and behavior than was expected of RASDS

• But, SysML needs to be adapted, via a profile or some other method, to guide use of appropriate views


• 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

Mapping RASDS into SysML


Enterprise View Using SysML Use Case Diagram

<<usage>>Enterprise: Use Case

Mars ExplorationProgram Federation

Mission A

Agency ABC

GTN B

Mission Q

Instr C

Agency QRS

InstrumentIntegration

OperationsContract

<<includes>> <<includes>>

<<includes>>

<<includes>>

<<includes>>

<<includes>>

<<extends>>

Cross SupportAgreement<<extends>> <<extends>

>

Service OperationsTeam

<<Secondary>>

ScienceTeam

<<primary>> ScienceTeam

<<primary>>

InstrumentTeam

<<Secondary>>

RelayService A

<<extends>>

TT&CService B

Mission Operations

Team<<Primary>>


Connectivity View (Nodes & Links) Using SysML Components (Spacecraft)

Derived from: SysML Partners

sciInstr : scienceInstrumentCDH : CmdDataHandlingSystem

dl : DownLink

Spacecraft

s :Sensor

ic :InstrControl

ap : Aperture

ap: Mechanical

ObsFinPort

DataDonePort

dm :DataManager

ecu : ExecutionControl Unit

oc :ObsControl

InstrCmndPort

TelemPort

TakeObs

SensorData

RFAntenna

ul : UpLinkTeleCmndPort

CmndInPort


Connectivity View (Nodes & Links) Using SysML Components (MOS & TT&C

Systems)

TT&C : TrackTelemCommandMOS : MissionOpsSystem

TM :Telemetry

TC :Telecommand

Pt : PointingAnt: Mechanical

TelemDonePort

dm :DataManager

MOP : MissionOpsPlanning

SC :SendCmnd

Cmnd Port

TelemPort

PointingData

TelemDataRFAnt

TeleCmndPortObsReq

Port ul : UpLink

dl : DownLink

CmndData

ReTransPort

DLPort

ULPort


Connectivity View (Composition) Using SysML Components

Global structure inherited by each kind of Spacecraft …

… and constrained for each kind

TT&C : TrackTelemCommandMOS : MissionOpsSystem

TM :Telemetry

TC :Telecommand

Pt : Pointing Ant:

Mechanical

TelemDonePort

dm :DataManager


SC :SendCmnd

Cmnd Port

TelemPort

PointingData

TelemData

RFAnt

TeleCmndPortObsReq

Port ul : UpLink

dl : DownLink

CmndData

ReTransPort

DLPort

ULPort

sciInstr : scienceInstrumentCDH : CmdDataHandlingSystem

dl : DownLink

Spacecraft

S :Sensor

IC :InstrControl

Ap : Aperture

AP:Mechanical

ObsFinPort

DataDonePort

dm :DataManager

ecu : ExecutionControl Unit

oc :ObsControl

InstrCmndPort

TelemPort

TakeObs

SensorData

RFAntul : UpLinkTeleCmndPort

CmndinPort

RF: link [X-band]

RF: link [KaBand]


Functional View Using SysMLActivity Diagram

• Showing component allocations (optional)

Sp

ac

ec

raft

Gro

un

d S

ys

tem

Ins

tru

me

nt

S/C

Co

ntr

ol

Mis

sio

n O

ps

PrepareCmnd

AcceptData

FinishObsSeq

Take Obs

plannedObs

InstrCmnd

PlanObsSeq

TT

&C

Ne

two

rk

XmitCmnd

RecvData

TransmitDataStore

Data

ExecuteCmnd

retransReq

readyCmnd

RecvCmnd

obsComplete

retransDataReq


Informational View Using SysMLClass Diagram

• Reusable, refinable information structure:

<<info obj>>InstrCmndFile

1..* 1

describes

Global representation inherited by each kind of Information Object


<<data obj>>InstrCmndList

<<data obj>>InstrCmnd

1..*

<<metadata obj>>InstrCmndMetaData

<<metadata obj>>InstrCmndSemantics

<<metadata obj>>InstrCmndStructure

6 Nov 2008 JPL Modelling Early Adopters (MEA) PS 31Derived from: SysML Partners

Communication View (Protocol Objects)

Using SysML Component Diagram

TC :TeleCmnd

<<protocol>>LL: LinkLayer

SC : SpaceCraft

CmndData:RF

<<protocol>>PL: PhysLayer

<<protocol>>IP: InternetLayer

<<protocol>>TP: TransportLayer

CmndInPort

SC :SendCmnd

<<protocol>>LL: LinkLayer

MOS : MissionOpsSystem

<<protocol>>PL: PhysLayer

<<protocol>>IP: InternetLayer


CmndPort

ECU : ExecutionControl Unit


RF: link [Xband]

<<controls>>


Communication View Using SysMLState Machine Diagram



Idle

Waiting

SendingevSend /transmitCount=0

tm(Wait Time) [transmitCount<LIMIT]

evDoneSend /++transmitCount

evACK[isValid]

tm(Wait Time) Throw(“Unable to Send”)

Protocol specifications inherited by each instance of Protocol Objects


Developing Useful Viewpoints

• Viewpoint Specification Examples– IEEE 1471 & RASDS Approach– Stakeholders, concerns, modeling language,

consistency & completeness

• Extensions needed for Space System MBE– May need extended Physical (Connectivity) view– May need other views (Service)


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 scenarios

• 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

All five RASDS viewpoint elementsAre documented in CCSDS 311.0-M-1


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.


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


Typical Connectivity (& Physical) Views

• 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, path, orbit), including their interaction with external elements and forces that are outside of the control of the system, but that must be modeled with it to understand system behavior (planets, asteroids, solar pressure, gravity)

• Structural view – Describes the structural components in the system (s/c bus, struts, panels, articulation), their physical attributes and connectors, along with the relevant structural aspects of other components (mass, stiffness, attachment)

• Thermal view – Describes the active and passive thermal components in the system (radiators, coolers, vents) and their connectors (physical and free space radiation) and attributes, along with the 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

Connectivity Views use different subsets of the same physical objects, but areexamined from different perspectives

and use different attributes. Space System MBE may require

other views and object types.


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 )


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 missions have used RASDS successfully– An approach for adapting SysML to add useful views has been presented– This is aligned with latest JPL SE Practices, Doc 75012 (see backup)

• Even in a “document driven” process adopting a useful set of views is valuable

– Word & PowerPoint

• However, adoption of a formalized modeling environment based on SysML will aid development 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 SysML 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


BACKUP


JPL SE Practices, Doc 75012 Table 3. Architectural Viewpoints• 1 Programmatic

– a. Purpose, scope, and objectives– b. Organization, including the work breakdown structure ...

• 2 Functional– 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. 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. 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. 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 subsysteminteractions, control system elements, and elements

of system under control ...

• 6 Technical Infrastructure and Standards– 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– a. Development– b. Integration– c. Assembly, test, and launch operations (ATLO) [verification and validation (V&V)] ...


Definitions of DoDAF Views1.3.1 Definition of the Operational View The OV is a description of the tasks and activities, operational elements, and information exchanges required to accomplish DoD missions. DoD missions include both warfighting missions and business processes. The OV contains graphical and textual products that comprise an identification of the operational nodes and elements, assigned tasks and activities, and information flows required between nodes. It defines the types of information exchanged, the frequency of exchange, which tasks and activities are supported by the information exchanges, and the nature of information exchanges. 1.3.2 Definition of the Systems View The SV is a set of graphical and textual products that describes systems and interconnections providing for, or supporting, DoD functions. DoD functions include both warfighting and business functions. The SV associates systems resources to the OV. These systems resources support the operational activities and facilitate the exchange of information among operational nodes. 1.3.3 Definition of the Technical Standards View The TV is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements. Its purpose is to ensure that a system satisfies a specified set of operational requirements. The TV provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. The TV includes a collection of the technical standards, implementation conventions, standards options, rules, and criteria organized into profile(s) that govern systems and system elements for a given architecture.


DoDAF Elements and Their Relationships

(Partial and not Exact)

Operational Node

SystemFunction

System Node

System Data

Performs

Is Implemented By

Hosts

Generates or Consumes Is Exchanged

Between


Owns

Source: Takahiro Yamada, SAWG Chair


Correspondence Between RASDS and DoDAF Elements

DoDAF Elements RASDS ElementsOperational 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)



Correspondence Between RASDS and DoDAF 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 ConnectivityDescription (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) NoneSource: Takahiro Yamada, SAWG Chair


Correspondence Between RASDS and DoDAF Views (2/2)

DODAF View and Product RASDS ViewSystems 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



Object

Unified ObjectRepresentation

Core Functions What the object does

External Interfaces: How external elements are controlled

Management Interfaces: How objects are configured controlled, and reported upon

Service Interfaces: How services are requested & supplied

Concerns: Issues Resources Policies

DirectiveGeneration

CommandExecution

DirectiveExecution

CommandSchema & StructureDefinition

Operations PlanSchema & StructureDefinition

Information ObjectsRelationship to Functional View

Instantiation

ObservationPlans

InstrumentCommands

S/C Commands

S/C Event Plans

Information Objects are exchanged among

Functional Objects

AbstractData Architecture

Meta-models

Data Models

Actual DataObjects

InformationObject

DataObject

RepresentationInformation

SemanticInformation

StructureInformation

1..n

Instantiation

InformationObject

DataObject

RepresentationInformation

SemanticInformation

StructureInformation

1..n

OperationPlans Commands

Realization Realization

Information Concerns:StructureSemanticsRelationshipsPermanenceRules

modeling space data systems architectures 6 nov 2008 peter shames nasa jet propulsion laboratory,...

Documents

systems engineering

engineering space systems

ground systems

model views

control systems

system engineering activity

different views

early adopters meawhat