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