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

2. 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 modules
Advantages:
Increased flexibility during design and acquisition
Reduced development and launch costs
Increased adaptability and survivability of space systems on-orbit
Potential 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

3. F6 Program challenges
Distributed system with network addressability
Everything and anything can be accessed and addressed
Dynamism
Dynamically deployed applications, security configurations, and
cluster architectures
Resource sharing
Specific resources can be shared across applications: CPU,
communication links, memory, services
Fault tolerance
Faults in components, services, communication links, computing
nodes are detected, isolated, and their effects mitigated
Multi-level security
The architecture shall address the requirements of MLS

4. F6MDA (Model-driven Architecture)
Layered architecture supported by a model-driven development
toolchain
Model-driven
Development
Software
Platform
Deployment

5. F6OS
The ‘Operating System’ that provides
Restricted OS calls for application actors
Privileged calls for platform (‘service’) actors
All system calls are time-bounded
Provides messaging services
All component interactions are via messages
No other interactions are possible
All component interactions are facilitated by a ‘secure transport’
that verifies security labels on messages
Resource management functions
CPU time: temporal partitioning for actors, utilization cap per actor
within partition
Memory: space partitioning, limit caps
Network bandwidth: bandwidth budget, differentiated routing

6. Middleware
The ‘middleware layer’ provides
Synchronous and asynchronous point-to-
point communication with call/response
semantics (subset of CORBA)
Location transparency
Request (de)multiplexing
Message (de)marshalling
Error handling
Support for QoS (client timeouts, reliable one-
ways)
Anonymous publish/subscribe
communications with one/many-to-many
data distribution patterns (subset of DDS)
Datatype specification
Static discovery
Reduced set of QoS: reliability, time-based
filtering, latency budget, etc.

7. F6 Component Model
The F6 Component Model is based upon existing Object
Management Group (OMG) standards
CORBA Component Model (CCM)
Data Distribution Service (DDS)
DDS4CCM
AMI4CCM
Deployment and Configuration (D&C)
By using formal standards components can be used on top of
various implementations
CORBA and DDS together deliver interoperability at the wire
protocol layer
F6 makes the mandatory CORBA part of CCM optional through
the connector concept
Delivers a true Interoperable Open Architecture solution

8. F6 Component Model
Applications are constructed from
interacting components
Components 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 data
Provided and required interfaces are
connected and support tightly and
loosely coupled, synchronous
interactions with call/response
semantics
Components are triggered by the
middleware, by default single-threaded
and non-reentrant

9. F6ORB
Connector concept of CCM
Connectors are like components but deliver middleware services
Components can't directly communicate with other components
but only through a connector
User
component
Connector
F6COM
F6OS
F6 Technology Package
F6ORB
User
component
Connector
F6COM
F6OS
F6 Technology Package

10. Platform Actors
The ‘platform services’ that manage
Operations
Autonomous and commanded
Application deployment
Actors, components, connections,
resource limits, labels
Dictionary
Addressing of all ‘objects’
Data topics
Certificates
Faults
Application restarts, redeployment
Communication resource
Wireless Inter-Module Communications,
including bandwidth and routes

11. 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
mitigation
Fault-tolerant, replicated,
hierarchical
Autonomous recovery from
faults:
Failover and reconfiguration
Node
System Partition
Fault Manager
Dictionary
Manager
Deployment
Manager
Certificate
Manager
User Partition
liveness checking and mitigation
through F6OS
Mitigate/Recover(logicalmessageflow)
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
Mitigate/Recover

12. Security Architecture
F6OS
Distributed,
dynamic/reconfigurable
separation kernel
Spatial and temporal separation
of actors
Runs 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 labels
F6OS enforces MLS MAC on
every message
Implementation
Prototype: extension of Linux
Long term: micro-kernel
Actors
Platform actors
Trusted part of platform software, along
with F6OS
Can make privileged system calls to
F6OS (e.g. to manage partitions)
Application actors
Can only make non-privileged system
calls to F6OS
Multi-label actor must be
trusted/verified w.r.t. its assigned set
of labels
Actors contain middleware and
generated glue code
Middleware and glue code realize higher-
level interactions in terms of lower-level
system calls
Minimal set of features to ease verification
Model-based development eases
verification of actors

13. 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 artifacts
Delivers standard deployment interfaces
Supports reconfiguration and redeployment capabilities to
adapt to a change in mission

14. F6 Development Environment
Model-driven development
Software architecture models capture:
Component interfaces, ports, assemblies, and
deployment information
Anticipated 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 definitions
Complete system architecture (all apps)
All security labels and lattices
Conventional development process can
also be used
System integration requires configuration
artifacts

15. F6 Project schedule
Currently all system parts are under development
Initial phase 1 has been extended until June 2013
Validation and verification through 2013
Ground test bed in 2014
On orbit testing in 2015
The 5th International Conference on Spacecraft Formation
Flying Missions and Technologies which takes place May 29-31
2013 in Munich will have a F6 session

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

17. Contact
Remedy IT
Melkrijder 11
3861 SG Nijkerk (Gld)
The Netherlands
tel.: +31(0)88 053 0000
e-mail: sales@remedy.nl
website: www.remedy.nl
Twitter: @RemedyIT
Slideshare: RemedyIT
Subscribe to our mailing list