A Reusable Ground System Architecture Provides...

| 1Ground Systems Architecture Workshop 2014| | 1harris.com

Howard D. Gans

A Reusable Ground System Architecture Provides Lessons in the Use of DoDAF and UPDM

Eric A. Barnhart

Systems Engineer

Systems Engineer

© 2014 by Harris Corporation. Published by The Aerospace Corporation with permission

| 2Ground Systems Architecture Workshop 2014| | 2Reusable Ground System Architecture Provides Lessons In the Use of DoDAF and UPDM

Background

• Affordable Ground Architecture (AGA)– A Harris initiative to develop reusable ground systems architectures

applicable to multiple problem domains– Identifies problem-unique and common aspects for each domain– DoDAF 2.0– Unified Profile for DoDAF / MoDAF (UPDM) in Rational Rhapsody

• Based on experience in multiple ground systems– NOAA Geostationary Operational Environmental Satellite - R Series

(GOES-R)– NASA Space Network Ground Segment Sustainment (SGSS)– U.S. Army's Modernization of Enterprise Terminals (MET)– 40 years operational experience at USAF/AFWA

• AGA Goals– reduce cost and execution risk through reuse


Timeline of the Harris Initiatives

3/5/2014

Ground System Reference

Framework;2008

•Single Architecture;•Reuse of documents and concepts;•Printed Materials (Visio / Powerpoint);•GSAW presentation

Continuing Efforts;Ground System

Knowledge-base;2014+

Affordable Ground Architecture;

2012-2013

• Migration to a Unified; Architecture in Rhapsody;

•Parameterized Cost;•Performance Options;•Reusable Component Library•Governance

•Transition to Enterprise Arch;• DoDAF UPDM;

•Reusable Partitions

•EA to Model Based System Engineering Processes;

•1st Mission Specific Models Instantiated from Architecture

•Experimental Component Library

•Parameterized Costing Research


AGA Model

AGA Overview

The AGA enterprise ground system model includes multiple DoDAF views

Capability Views Data Views

System ViewsOperational Views

DOORS


Issues in Architecture Reusability

3/5/2014

EA C

ompl

exity

Non-reusable

Reusable

• Partitioning• Naming

conventions• MBSE Transition

Strategies

Multiple DecisionsMultiple Enterprises

• Addresses Common & Unique Capabilities

• Multiple arch. parts• Inheritance and

classification

• Capability Selection• Component Libraries• ParameterizationCostPerformance

• Simplified partitions

• No transitioning strategy needed

• No parameterization needed

• No libraries needed

Single DecisionSingle Enterprise• Simplified Capability

Model

Reusability across multiple domains and decisions increases complexity


Architecting For Reusability

• First, model the ground system in terms of the DoDAF Metamodel (DM2)– Start with missions and capabilities (CV)– Defer the other views (OVs, SVs)– The other views fall out naturally after

the meta model data are defined• Define entities in a data view

– Reusable entities need defined types– Use no implicit entities– DIV is equivalent to a Block Definition

Diagram (BDD) in SysML• Partition the architecture for reuse• Use generic terminology to describe

the EA entities

3/5/2014

«(U) DIV-2 Logical Data Model»Object Model Diagram [«(U) Data and Information View» Package] DataInformationViewPkg [div-2 Proc3 Systems]

sysGroundStationFull«(U) Sy stem»

1

1

sysLinkPerformanceMonitoring«(U) Sy stem»

1

1

1

1

sysSignalReception«(U) Sy stem»

1

1

1

1

1

1

sysTelemetryDisplay«(U) Sy stem»

sysTelemetryRecordAndPlayback«(U) Sy stem»

1

1

1

1

sysProductGeneration«(U) Sy stem»

1

1

1

1

sysL1DataGeneration«(U) Sy stem»

1

1

sysL2PlusProductGeneration«(U) Sy stem»

1

1

1

1

sysProductEvaluation«(U) Sy stem»

1

1

«(U) DIV-2 Logical Data Model»Object Model Diagram [«(U) Data and Information View» Package] DataInformationViewPkg [div-2 Downlink Data Model]

PlatformDownlinkSignal«(U) Entity Item»

Attr ibutes

frequency:intmodulation:int

Modulated downlink signal, assumed to be in the RF domain

downConvertedTo

IFsignal«(U) Entity Item»

Attributes

Intermediate frequency signal, downconverted from RFsignal; digitized and distributed for processing

downConvertedTo encodes

Level0DataPacket«(U) Entity I tem»

Attributes

L0 data extracted from the IF signal, in a standard format packet (e.g. CCSDS)

encodes

InstrumentScienceDataPacket«(U) Entity Item»

A ibData packet containing instrument observations, or the main mission data, in arbitrary units (not observation units, such as radiances)

InstrumentEngineeringDataPacket«(U) Entity Item»

AttributesData packet containing instrument status not related to sensor observations (eg. temperature, power status)

PlatformHousekeepingDataPacket«(U) Entity Item»

Attributes

Data packet containing platform status, not related to the instruments (eg. bus power, propellant status, temperature)

APID1 «(U) Entity A ttribute»

Attributes

Application ID, identifies the type of data in the packet

readInAs

Level0Data«(U) Entity Item»

Attributes

Internal representation / data structure for the L0 DataPacket. For example, the data packet may be read in as a structured type, like anobject or struct in C++ or Java.

readInAs

PlatformHousekeepingData«(U) Entity I tem»

InstrumentEngineeringData«(U) Entity Item»

InstrumentScienceData«(U) Entity Item»

Capture and Define Entities

Model Missions

DM2

CV-2, DIV-2

av-1 Sample Earth Observing Architecture Packages

EarthObservingGroundSystemPkg«ArchitecturalDescription»

GroundSystemApplicationsPkg«ArchitecturalDescription»

CommunicationsServicesPkg«ArchitecturalDescription»

EnterpriseCommunicationsPkg«ArchitecturalDescription»

DataProcessingServicesPkg«ArchitecturalDescription»

MissionManagementPkg«ArchitecturalDescription»

GroundStationPkg«ArchitecturalDescription»

ProductGenerationPkg«ArchitecturalDescription»

Partition Modelav-1 Earth Observing Structural Parts



«DefinesArchitecture»

SinglePhasePGDev«EnterprisePhase»


AlgorithmExecServices1 «StructuralPart»

Level1Capabilities1 «StructuralPart»



SinglePhaseGndStationDev«EnterprisePhase»


Downlink1 «StructuralPart»

GroundTerminal1 «StructuralPart»

Uplink1 «StructuralPart»

Itera

te

AV-2

Experience suggests a modified approach to EA for reusability


DoDAF MetaModel (DM2) Simplified

3/5/2014

Activity

Capability

Resource

Performer Info

Guidance

Condition

constrains

limits requires ability to perform

performed by

consumes / produces

realizes* achieves a desired effect upon

Everything has Measures

Measure PersonSystem

1+

1+

1+1+

1+

1+

1

1+

Leveraging the DM2 is key to the approach

*relationship is inverted from the DM2


Activity

Capability

Resource

Performer Info

Guidance

Condition

constrains


performed by

consumes / produces

realizes* achieves a desired effect upon

Everything has Measures

Measure PersonSystem

1+

1+

1+1+

1+

1+

1

1+

DM2 for Systems Engineers

3/5/2014

requires ability to perform

performed by

realizes

1+

1+

1

1+

Analysis

Design

Validationconsumes /

produces1+

achieves a desired effect upon

Given a capability, what do I need to do

to achieve it?

Understanding what I need to do, how do

I perform it?

Does my system successfully

implement the capability?

Capability

Resource

Info

Activity

The DM2 impacts the way systems engineers approach their processes

Performer

PersonSystem


Capability Models

3/5/2014

Reusable capabilities impact multiple systems engineering models

Activity

Resource

constrains


achieves a desired effect upon

1+

1+

Capability

requires1+

• Capabilities tie together other models• In general…

• 80% of capabilities can be reused• 20% are unique to the mission

• Capabilities are added to the model under a governance process

Requirements / Behavioral Model

Use Case Model

Mission

System and Data Model

Guidance

Condition


cv -2 Capabil ity Taxonomy - New

To Do: Review di fferent means toaddress failures and provide subclas ses of thi s capabili ty at various cost levels

Hierarchy in ManageMiss ion not matched by DOORS capability statements.

130307: W e have store and arc hive capabil ities in several plac es. Need to resolve (H DG ) .

20130318 EAB; w e can identify the s ensor types now; imaging, sounding lightning mapping, space weather insi tu; space weather sola r imaging; spaceweather particle detec tion

20130325 EAB; Archiving should be a single capabil ity that is accessed by other capabilities; res ourc e = archive, desiredeffect = add to archive; since the arc hive is probably alw ays going to be in a ground sy stem one way or another, it might be

6.7

6.8

6.9 6.1 6.6 6.2 6.3 6.4 6.5 6.10 6.11

Note: 94 capabilities as of 01/07/2014

Capability Taxonomy

3/5/2014

Hierarchical capabilities are useful for less complex, non-reusable architectures


Partitions Facilitate Modular Reuse

• Reuse is enhanced by an architecture partitioned into meaningful cohesive packages of capabilities

3/5/2014

av-1 Sample Earth Observing Architecture Packages

EarthObservingGroundSystemPkg«ArchitecturalDescription»

GroundSystemApplicationsPkg«ArchitecturalDescription»

CommunicationsServicesPkg«ArchitecturalDescription»

EnterpriseCommunicationsPkg«ArchitecturalDescription»

DataProcessingServicesPkg«ArchitecturalDescription»

MissionManagementPkg«ArchitecturalDescription»



Enabling reuse at various layers

Enabling reuse across applications within a layer

Architectural descriptions are imported into SysML models for reuse

Next Slide


Lower Level Partitioning

• UPDM provides a schema for grouping capabilities into temporal and/or structural parts within the architectural descriptions

3/5/2014

av-1 Earth Observing Structural Parts 1 of N




SinglePhasePGDev«EnterprisePhase»

«DefinesArchitecture» AlgorithmExecServices1 «StructuralPart»




SinglePhaseGndStationDev«EnterprisePhase»


DownlinkCapabilities1..* «StructuralPart»

GroundTerminal1 «StructuralPart»

UplinkCapabilities1 «StructuralPart»


Enhanced Capability Taxonomy

3/5/2014

Architectural descriptions facilitate reuse by grouping capabilities and their subtypes

cv-2 Space Segment to Ground «CV-2 Capability Taxonomy»

cpAcquireandTrackSensorPlatform«Capability»

cpAcquireAndTrackGeostat ionaryOrbits«C apab ility»

cpAcquireAndTrackGeosyncronousOrbits«C apability»

similarsimilar

cpAcquireAndTrackPolarOrbits«C apab ility»

cpRecoverGRB«C apab ility»

cpRecoverLevel0Data«C apab ility»

cpExtractDataFromDownlink«Capability»

cpExtractCCSDSPackets«C apab ility»

cpExtractOtherPackets«C apab ility»

cpProcessDataPackets«Capability»

DownlinkCapabilities1..* «StructuralPart»


SinglePhaseGndStat ionDev«EnterprisePhase»


Transition to MBSE / SysML

• Architectural Descriptions in UPDM are packages in SysML

• Transition to MBSE as follows– Import and reference these packages in

a separate SysML project (readonly)– Do NOT load the UPDM profile!

• Lacking the UPDM definitions, architectural entities now take on their equivalent SysML characteristics

– Create mission specific SysML entities • Inherit the characteristics of the

architectural entities• Inheritance does not require modify access

– Customize the SysML model for the specific ground station mission

3/5/2014

Architecture models transition easily to MBSE / SysML development

Do NOT Load


Generic Naming Conventions

• At the enterprise level, keep your taxonomy generic for reuse– Any facility where a weather product ground system is controlled can

be called a “weatherCommandCenter” operational node– An orbiting sensor and satellite bus can be called an

“orbitingObservatory” operational node• At the system solution level, create specific instances

– NOAA_WCDAS_Facility is a type of weatherCommandCenter– GOES-R_East is a type of orbitingObservatory

• For transitioning to SysML…– In order to map SysML system elements to EA elements, the EA

elements must have a defined type– Implicit entities created directly on an SV-1 cannot be reused or

mapped to SysML entities• First add them to a data view (DIV) as a defined entity

3/5/2014

Generic enterprise taxonomies allow adaptation for unique missions


Example SysML UC Model

3/5/2014

SysML behavioral models have

corresponding EA entities

Underlying UPDM to SysML relationships enable this reuse process


Inheritance Of Architecture Characteristics

3/5/2014

bdd [Package] Local_SysML_Model_pkg [bdd Proc3]

sysProductGeneration«(U) System»

:sysL1DataGeneration1 «(U) SystemPart»

:sysL2PlusProductGeneration1 «(U) SystemPart»

:sysProductEvaluation1 «(U) SystemPart»

FutureWeatherSys_ProductGeneration«block»

FW_ProdGen:sysL2PlusProductGeneration1

FW_DataRecovery:sysL1DataGeneration1

FW_ProdEval:sysProductEvaluation1

EA Model From UPDM

Desired SysML Model

Parts are typed as the corresponding

UPDM entities

SysML blocks inherit from the corresponding UPDM system

Structural models also have corresponding EA entities


Summary

• Benefits– Enterprise Architecture can transition to Model Based Systems

Engineering while maintaining traceability• Inherit the 80% common capabilities / systems• SysML can be used to engineer the 20% unique capabilities

– SysML model is unique to the specific mission• Naming conventions and concepts are in mission terms• EA model is unmodified• EA model can be overridden where necessary

• Challenges– Manual process to make the links and unique configurations– Tools don’t yet directly support this concept with built-in functions

• Need to follow SysML relationships to identify inherited information• Opportunity for some scripting

3/5/2014


Conclusions

• Modeling a Ground System Architecture for reuse has unique difficulties• Implementing a ground system solution from a reusable architecture

using SysML requires extensive knowledge of both UPDM and SysML• Up front investment is not trivial• The effort is worth the benefits

– Consistent knowledge-base of ground system architectures– Reusability at several levels

• Architectural components• System products

– Rapid decision making capability– Lower Costs in up front processes

• Future benefits– Parametrically defined cost and performance– Reusable process artifacts– Reusable components

3/5/2014

A Reusable Ground System Architecture Provides...

Documents

Transcript of A Reusable Ground System Architecture Provides...