A real-time middleware and component model for a fractionated spacecraft

Johnny Willemsen; Remedy IT

Gabor Karsai, Abhishek Dubey, Andy Gokhale, William R. Otte, Csanad Szabo; Vanderbilt University/ISIS

Alessandro Coglio, Eric Smith; Kestrel Institute

This work was supported by the DARPA System F6 Program under contract NNA11AC08C. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of DARPA.

Future Fast, Flexible, Fractionated, Free-Flying Spacecraft (F6)

Objective: Develop and demonstrate a satellite architecture where the functionality of a traditional monolithic spacecraft is replaced by a cluster of wirelessly connected modulesAdvantages:

Increased flexibility during design and acquisitionReduced development and launch costsIncreased adaptability and survivability of space systems on-orbitPotential to apply economies of scale to satellite design & manufacture

Key program objective is to promote the usage of open interface standards for hardware and software

F6 Program challenges

Distributed system with network addressabilityEverything and anything can be accessed and addressed

DynamismDynamically deployed applications, security configurations, and cluster architectures

Resource sharingSpecific resources can be shared across applications: CPU, communication links, memory, services

Fault toleranceFaults in components, services, communication links, computing nodes are detected, isolated, and their effects mitigated

Multi-level securityThe architecture shall address the requirements of MLS

F6MDA (Model-driven Architecture)

Layered architecture supported by a model-driven development toolchain

Model-drivenDevelopment

Software Platform

Deployment

F6OS

The ‘Operating System’ that providesRestricted OS calls for application actorsPrivileged calls for platform (‘service’) actorsAll system calls are time-bounded

Provides messaging services All component interactions are via messagesNo other interactions are possible

All component interactions are facilitated by a ‘secure transport’ that verifies security labels on messagesResource management functions

CPU time: temporal partitioning for actors, utilization cap per actor within partition Memory: space partitioning, limit capsNetwork bandwidth: bandwidth budget, differentiated routing

Middleware

The ‘middleware layer’ providesSynchronous and asynchronous point-to-point communication with call/response semantics (subset of CORBA)

Location transparencyRequest (de)multiplexingMessage (de)marshalling Error handlingSupport for QoS (client timeouts, reliable one-ways)

Anonymous publish/subscribe communications with one/many-to-many data distribution patterns (subset of DDS)

Datatype specificationStatic discoveryReduced set of QoS: reliability, time-based filtering, latency budget, etc.

F6 Component Model

The F6 Component Model is based upon existing Object Management Group (OMG) standards

CORBA Component Model (CCM)Data Distribution Service (DDS)DDS4CCMAMI4CCMDeployment and Configuration (D&C)

By using formal standards components can be used on top of various implementationsCORBA and DDS together deliver interoperability at the wire protocol layerF6 makes the mandatory CORBA part of CCM optional through the connector conceptDelivers a true Interoperable Open Architecture solution

F6 Component Model

Applications are constructed from interacting componentsComponents interact and exchange data via ports Publishers are decoupled from subscribers, publishers can send data at anytime, subscribers are triggered when data is available or they can poll for dataProvided and required interfaces are connected and support tightly and loosely coupled, synchronous interactions with call/response semanticsComponents are triggered by the middleware, by default single-threaded and non-reentrant

F6ORB

Connector concept of CCM

Connectors are like components but deliver middleware servicesComponents can't directly communicate with other components but only through a connector

User component Connector

F6COM

F6OS

F6 Technology Package

F6ORB

User componentConnector

F6COM

F6OS

F6 Technology Package

Platform Actors

The ‘platform services’ that manageOperations

Autonomous and commanded

Application deploymentActors, components, connections, resource limits, labels

DictionaryAddressing of all ‘objects’Data topics

CertificatesFaults

Application restarts, redeployment

Communication resource Wireless Inter-Module Communications, including bandwidth and routes

Fault Management

The overall layered approach to manage faults on various levels of the system:

Localized:Anomaly detection, diagnostics, mitigation:

Network HW, CPU HW, F6OS, Component/Actor

If mitigation fails, report ‘up’

Global: (Fault Manager)System-wide diagnostics and mitigationFault-tolerant, replicated, hierarchicalAutonomous recovery from faults:

Failover and reconfiguration

Node

System Partition

Fault ManagerDictionary Manager

Deployment Manager

Certificate Manager

User Partition

liveness checking and mitigation through F6OS

Miti

gate

/Re

cove

r (lo

gic

al m

ess

ag

e f

low

)

System-wide Fault

Management

Operations Manager

Actor

Actor-level Fault

Management

Actor

Actor-level Fault

Management

Actor

Actor-level Fault

Management

Platform Fault Management

CRM

Network-level Fault Management handled by Radio and CRM

Miti

gate

/Re

cove

r

Security Architecture

F6OSDistributed, dynamic/reconfigurable separation kernel

Spatial and temporal separation of actorsRuns actors, which make system calls

Provides simple inter-actor communication via system calls send/receive calls – the only calls for communication

Labeled messages, using multiple-domain labelsF6OS enforces MLS MAC on every message

ImplementationPrototype: extension of Linux Long term: micro-kernel

ActorsPlatform actors

Trusted part of platform software, along with F6OSCan make privileged system calls to F6OS (e.g. to manage partitions)

Application actorsCan only make non-privileged system calls to F6OS

Multi-label actor must be trusted/verified w.r.t. its assigned set of labelsActors contain middleware and generated glue code

Middleware and glue code realize higher-level interactions in terms of lower-level system callsMinimal set of features to ease verification

Model-based development eases verification of actors

Deployment

Components and connectors are deployed by the F6 Deployment Manager (F6DM)The F6DM is based on the OMG Deployment and Configuration standard

Describes a way to package software artifactsDelivers standard deployment interfaces

Supports reconfiguration and redeployment capabilities to adapt to a change in mission

F6 Development Environment

Model-driven developmentSoftware architecture models capture:

Component interfaces, ports, assemblies, and deployment informationAnticipated resource needs (budgets)

Middleware glue code and configuration artifacts are automatically generated from models

Model-driven system integration Integration models capture:

System-wide data type definitionsComplete system architecture (all apps)All security labels and lattices

Conventional development process can also be used

System integration requires configuration artifacts

F6 Project schedule

Currently all system parts are under developmentInitial phase 1 has been extended until June 2013

Validation and verification through 2013Ground test bed in 2014On orbit testing in 2015The 5th International Conference on Spacecraft Formation Flying Missions and Technologies which takes place May 29-31 2013 in Munich will have a F6 session

Thanks for your attention

More background information is online available at

http://www.remedy.nl

http://www.orbzone.org

http://www.omg.org

For more information regarding DARPA F6

http://www.darpa.mil/Our_Work/tto/Programs/System_F6.aspx