Modeling Space Data Systems Architectures - PowerPoint PPT Presentation

1 / 48
About This Presentation
Title:

Modeling Space Data Systems Architectures

Description:

Modeling Space Data Systems Architectures 6 Nov 2008 Peter Shames NASA Jet Propulsion Laboratory, California Institute of Technology Topics Why views of system ... – PowerPoint PPT presentation

Number of Views:219
Avg rating:3.0/5.0
Slides: 49
Provided by: cweCcsds8
Category:

less

Transcript and Presenter's Notes

Title: Modeling Space Data Systems Architectures


1
  • Modeling Space Data Systems Architectures
  • 6 Nov 2008
  • Peter Shames
  • NASA Jet Propulsion Laboratory, California
    Institute of Technology

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

3
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 dont forget the interactions among these,
    electrical, power, thermal, dynamic, etc, etc
  • Where do you stand to get a view of all this?

4
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?

5
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, IT, VV
  • Operations and sustaining
  • Cradle to grave lifecycle
  • Mission view vs infrastructure view

motion
6
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.
7
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 41,
  • 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

8
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.

9
Space Data System Several Architectural
Viewpoints
Derived from RM-ODP, ISO 10746 Largely compliant
with IEEE 1471-2000
10
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
  • 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

Reference Architecture for Space Data Systems
(RASDS) Reference Model Open Distributed
Processing (RMODP, ISO 10746 spec)
11
RASDSTop Level Object Ontology
Composed Of
Organization
  • Mission
  • Requirements
  • Objectives

FulfilledBy
  • Goals
  • Scenarios

ComposedOf
Owns/Operates
Fulfills
Function
Information
Calls
Produces
Consumes
  • Logical structure
  • Data
  • Behavior
  • Metadata

IsAllocatedTo
  • Interfaces

ComposedOf
  • Rules
  • Constraints

ContainsInstances
Node
Environment
ProvidesService
Affects
Uses
  • Type

ConnectVia
ImplementedOn
  • Attributes
  • Physical Environs

Communication
  • Ports
  • Attributes
  • Location

ConnectToPort
Link
  • Protocol stack

AssociatedWith
  • Standards
  • Type
  • Attributes

12
Space Data System Architectural Notation
Object
Object with Interface
Object Encapsulation
Management
Node Encapsulation (physical aggregation)
Node (physical location)
Service
External
Concerns
Logical Link
Physical Link
Space Link (rf or optical)
13
Instrument Integration
Cross- Support Agreements
Science PI Org
NASA/ JPL
Tracking Agreements
ICDs
Operations Agreements
ESA
Enterprise Concerns Requirements Objectives Roles
Policies Activities Configuration Contracts /
agreements Lifecycle / Phases
S/C Contractor
14
Functional ViewExample Functional Objects
Interactions
Functional Concerns Behaviors Interactions
Interfaces Constraints
15
Connectivity ViewNodes Links
SPACECRAFT
Mission Planning Computer
Internet
Space Link
Ground Tracking Station
Spacecraft Control Computer
Connectivity Concerns Distribution Communication
Physical Environment Behaviors Constraints
Configuration
16
Connectivity ViewMapping Functional Elements to
Nodes
Allocation View Implemented Functions End to End
Behavior Performance Throughput Trade studies
17
Communications Viewpoint Protocol Objects
End-To-End Command Processing
GROUND SYSTEM
SPACECRAFT
Payload
Commands
Command Generation
Command Execution
CDH
Packet
Packet
Packet (Relay)
Packet
Tracking Station
TC Space Data Link
TC Space Data Link (Relay)
TC Space Data Link
Frame
SLE CLTU
SLE CLTU
Communications Concerns Standards Interfaces Prot
ocols Technology Interoperability Suitability
TCP/IP
TCP/IP
TCP/IP
TCP/IP
RF Generation
PPP
PPP
RF Generation
Onboard Physical
Onboard Physical
18
MSL End-End Network Architecture Example
Connectivity Overview
MSL Planning and Control Center
MSL Rover

Rover Command Generation
CDH
SSR
Payload
MRO Spacecraft
File Xfer
Instr Command Execution
Rover Command Execution
Relay
Electra
Large SSR
MRO Control Center
Relay Command Execution
File Handling
Electra - lite
CDH
File Mgmt
Cmnd File Processing
Relay Command Generation
In-situ delivery
In-situ Delivery
Space Link Processing
Cmnd Integ
DSN
Proximate Link
File Prep
SDST
Space Data Link Delivery
Link Prep
XMTR
Deep Space Link
Performance Overlay Processor speed CPU
requirements Link capacities Throughput
Storage capacities
Team Overlay MSL MRO DSMS
Contractor
Data Flow Overlay Uplink Downlink
Relaying
19
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

20
Comparison of Architecture Methods
RASDS RM-ODP DoDAF Krutchen 41 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
Derived from Maier, ANSI/IEEE 1471 and System
Engineering
21
DoDAF (Notional)
RASDS (Notional)
22
SysML Diagram Types
Source SysML Partners
23
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

24
Mapping RASDS into SysML
  • 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

25
Enterprise View Using SysML Use Case Diagram
ltltusagegtgt Enterprise Use Case
Mars Exploration Program Federation
ltltincludesgtgt
ltltincludesgtgt
Agency ABC
Agency QRS
Cross Support Agreement
ltltextendsgtgt
ltltextendsgtgt
ltltincludesgtgt
ltltincludesgtgt
Science Team ltltprimarygtgt
ltltincludesgtgt
Mission Q
Science Team ltltprimarygtgt
Mission A
GTN B
ltltincludesgtgt
ltltextendsgtgt
Relay Service A
Instr C
ltltextendsgtgt
Mission Operations Team ltltPrimarygtgt
TTC Service B
Instrument Team ltltSecondarygtgt
Service Operations Team ltltSecondarygtgt
Instrument Integration
Operations Contract
26
Connectivity View (Nodes Links) Using SysML
Components (Spacecraft)
Spacecraft
sciInstr scienceInstrument
CDH CmdDataHandlingSystem
ap Mechanical
s Sensor
dm
DataManager
SensorData
DataDonePort
CmndIn Port
ecu Execution
Control Unit
ap Aperture
ObsFin Port
InstrCmnd Port
ic
oc
InstrControl
ObsControl
TakeObs
TelemPort
dl DownLink
TeleCmndPort
ul UpLink
Derived from SysML Partners
RFAntenna
27
Connectivity View (Nodes Links) Using SysML
Components (MOS TTC Systems)
TTC TrackTelemCommand
MOS MissionOpsSystem
DL Port
Telem Port
TM Telemetry
dm
DataManager
TelemData
Tele Cmnd Port
Re Trans Port
RF Ant
UL Port
TelemDonePort
ObsReq Port
TC
MOP Mission
Telecommand
OpsPlanning
CmndData
Cmnd Port
SC
SendCmnd
Pt Pointing
Ant Mechanical
PointingData
28
Connectivity View (Composition) Using SysML
Components
RF link KaBand
RF link X-band
Global structure inherited by each kind of
Spacecraft
and constrained for each kind
29
Functional View Using SysMLActivity Diagram
  • Showing component allocations (optional)

retransReq
obsComplete
Finish
Mission Ops
Prepare
Plan
Accept
ObsSeq
Cmnd
ObsSeq
Data
plannedObs
readyCmnd
Ground System
Xmit
Recv
TTC Network
Cmnd
Data
retransDataReq
S/C Control
Spacecraft
Instr Cmnd
Instrument
Take Obs
30
Informational View Using SysMLClass Diagram
  • Reusable, refinable information structure

ltltinfo objgtgt InstrCmndFile
describes
ltltmetadata objgtgt InstrCmndMetaData
ltltdata objgtgt InstrCmndList
1
1..
ltltdata objgtgt InstrCmnd
1..
ltltmetadata objgtgt InstrCmndStructure
ltltmetadata objgtgt InstrCmndSemantics
Global representation inherited by each kind of
Information Object
Derived from SysML Partners
31
Communication View (Protocol Objects)Using SysML
Component Diagram
MOS MissionOpsSystem
SC SpaceCraft
CmndIn Port
Cmnd Port
ltltcontrolsgtgt
SC SendCmnd
TC TeleCmnd
CmndDataRF
RF link Xband
Derived from SysML Partners
32
Communication View Using SysMLState Machine
Diagram
ltltprotocolgtgt TP TransportLayer
Sending
evSend / transmitCount0
Idle
evDoneSend / transmitCount
tm(Wait Time) transmitCountltLIMIT
Waiting
evACKisValid
tm(Wait Time) Throw(Unable to Send)
Protocol specifications inherited by each
instance of Protocol Objects
Derived from SysML Partners
33
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)

34
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 elements Are documented
in CCSDS 311.0-M-1
35
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.

36
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

37
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)

Connectivity Views use different subsets of the
same physical objects, but are examined from
different perspectives and use different
attributes. Space System MBE may require other
views and object types.
  • 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

38
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 )

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

40
BACKUP
41
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.

42
Definitions of DoDAF Views
43
DoDAF Elements and Their Relationships(Partial
and not Exact)
Performs
Operational Node
Operational Activity
Is Implemented By
Owns
Hosts
System Function
System Node
Generates or Consumes
Is Exchanged Between
System Data
Source Takahiro Yamada, SAWG Chair
44
Correspondence Between RASDS and DoDAF Elements
DoDAF 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
45
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) None
Source Takahiro Yamada, SAWG Chair
46
Correspondence Between RASDS and DoDAF 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
47
Unified Object Representation
Management Interfaces How objects are
configured controlled, and reported upon
Object
Service Interfaces How services are
requested supplied
External Interfaces How external elements
are controlled
Core Functions What the object does
Concerns Issues Resources Policies
48
Information ObjectsRelationship to Functional
View
S/C Event Plans
Observation Plans
Directive Generation
Command Execution
Directive Execution
Operation Plans
Actual Data Objects
Commands
S/C Commands
Realization
Realization
Command Schema Structure Definition
Operations Plan Schema Structure Definition
Instrument Commands
Data Models
Information Objects are exchanged
among Functional Objects
Instantiation
Instantiation
Information Concerns Structure Semantics Relation
ships Permanence Rules
Abstract Data Architecture Meta-models
Write a Comment
User Comments (0)
About PowerShow.com