Flying to Jupiter with OSGi - Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega)

ESA UNCLASSIFIED - For Official Use
Flying to Jupiter with OSGi
Anthony Walsh, ESA
Hristo Indzhov, Telespazio Vega

ESA UNCLASSIFIED - For Official Use !2
What has OSGi to do with Juipter?
OSGi + =

Spacecraft Mission Control
ESOC Operations Centres
Mission Control System (MCS)
Telecommands
Telemetry
ESTRACK Control Centre (ECC)

JUICE - JUpiter ICy moons Explorer
• Mission to visit the Jovian system focused on
studying three of Jupiter's Galilean moons:
Ganymede, Callisto, and Europa
• Prime Contractor is Airbus Defence and Space
• Launch in 2022 with arrival in 2029 after a
sequence of five gravity assist manoeuvres with
Earth, Venus, Earth, Mars, and again Earth
• In 2033, after completing various manoeuvres
around Jupiter and the other moons will enter
orbit around Ganymede
• Instruments include cameras, spectrometers,
magnetometers, and an ice-penetrating radar

JUICE - Scientific Objectives
• Mission will perform detailed investigations of Jupiter
and its system of moons
• Give better insight into how gas giant planets and their
satellites form and evolve
• Three of the moon are believed to harbour internal
oceans; Ganymede, Europa & Callisto
• Emphasis on Ganymede as a planetary body as a
potential habitat of life
• Characterisation of the ocean layers
• Topographical, geological and compositional mapping of
the surface
• Characterisation of icy crusts and internal mass
distribution, dynamics and evolution of the interiors
• Study Ganymede's intrinsic magnetic field

JUICE - Making it happen
• Returns are great, but space is expensive! – cost of
the JUICE mission is approx. 850 million Euros
• The costs of scientific missions like JUICE are very
great for any one nation – can be difficult to justify
• Sharing costs and expertise amount nations
therefore makes a lot of sense
• Much better return for each member state per Euro
spent
• The European Space Agency was created to
coordinate space activities between European
nations

European Space Agency (ESA)
Over 50 years of experience
22 Member States
Eight sites/facilities in Europe,
about 2300 staff
5.75 billion Euro budget
(2017)
Over 80 satellites designed,
tested and operated in flight

ESA Activities
space
science
telecommunications
human
spaceflight
earth
observation
space
transportation
navigation
operations technology
exploration
* Space science is a Mandatory programme, all
Member States contribute to it according to
GNP. All other programmes are Optional,
funded ‘a la carte’ by Participating States.
ESA combines responsibility in nearly
all areas of space activity.
Operations - ESOC

European Space Operations Centre (ESOC)
• Mission Control Centre of ESA
• Operating since 1967
• Mission and Launch Operations
• Operation of ESA’s world wide network of
Ground Stations (ESTRACK)
• Centre for space debris studies and
services, space security, ground system
engineering, the design and development of
tracking stations and satellite navigation
• Focus on Earth Observation, Astronomy and
Solar System Exploration Missions

ESOC – Selection of Missions (81 and counting)
Herschel GaiaPlanck
Mars Express LISA PathfinderExoMarsMars Express Rosetta
BepiColombo Cheops Solar Orbiter James Webb Space Telescope
BepiColombo Goce Swarm Sentinels
Galileo

Earth Observation Missions - Cyrosat
• Monitors variations in the extent and thickness of
polar ice
• Monitors the changes in thickness of marine ice,
and variations in the thickness of the ice sheets
that overlie Greenland and Antarctica
• Tracks changes in the thickness of the ice with a
resolution of about 1.3 centimetres
• Important in monitoring impact of climate
change, expected to be amplified at the poles
• Main payload is a radar altimeter called SIRAL
• Launched 2010 - initial programmatic lifetime
was 3.5 years, but still going strong

Astronomy Missions - Planck
• Mapping of the cosmic wave background
• Afterglow from the big bang – @ 380,000
years universe cooled enough (3000K) for
protons and electrons to combine to form
neutral hydrogen atoms and allow photons to
travel freely
• Fundamental to Cosmology
• Liquid Helium used to maintained an
instrument temperature of −273.05 °C (0.1
°C above absolute zero) - coldest known
object in space
• Operated 2009-2012 when helium exhausted

Solar System Exploration Missions - Rosetta
• Performed detailed study of comet
67P/Churyumov–Gerasimenko
• Rosetta spacecraft placed in orbit
during active phase around the sin
• Released Lander module Philae for
first successful landing on a comet
until battery power ran after 2 days
• Showed that water from comet 67P
is substantially different from that
found on Earth
• Launched in 2004, arrived 2014 and
mission ended in 2016

Renewal of Monitoring Control Systems – ESC-CC
• Many different systems for monitoring and
control used for space system operations and
Assembly Integration and Testing (AIT)
• Many are reaching the end of life
• Agreement within Europe to develop common
infrastructure to support space systems
monitoring and control
• Share and reduce system development costs
and maximise synergy and interoperability
• Modernization of AIT and MCS systems
• Ambitious collaboration between ESA,
national agencies, prime industry and SMEs

EGS-CC technology requirements and OSGi Selection
• Development of EGS-CC started with requirements specification and technology
evaluation and selection activities
• A number of criteria were taken into consideration, including;
o Modular and extensible for different mission needs;
o Performance, reliability, scalability, etc
o Compatibility with EGS-CC licensing needs;
o Longevity of technology and future outlook;
o Knowledge within and outside of Space domain (community strength).
• A number of technologies were considered for the EGS-CC component framework
(EJB, SCA, CCM, OSGi, etc) – OSGi was selected as most appropriate
• Selected technologies was input into the contract with the Industry Consortium for
the implementation phase of EGS-CC

EGS-CC Development Consortium

Project Organisation
•The project spans
− 8 Countries,
− 17 Companies,
− 23 Teams and
− 43 Components
• 11 System Architects
• 12 Integration and Validation Engineers

Software Development Environment
•Technology Baseline
− Java 1.8.0.x (openJDK - openSUSE,
Oracle JDK - SLES)
− Apache Maven 3.2.3
− Apache ServiceMix 5.4.0 (Karaf 2.4.1)
− Eclipse SDK 4.4.1 (Luna SR1)
− Linux openSUSE 13.2, SLES 12
•SDE Continuous SDE Development
Linux OpenSUSE 13.2 or SLES 12
Open JDK or Oracle JDK
Eclipse IDE
Maven Git Groovy
•SDE Continuous SDE Continuous Integration
SonarQube Nexus Jenkins
Open JDK or Oracle JDK
Maven Git Groovy
Postgre
SQL
Linux OpenSUSE 13.2 or SLES 12

What is EGS-CC?
•EGS-CC is a software infrastructure designed to support distributed space M&C
systems
•It is layered (kernel, reference implementations, reference test facilities) and each
layer contains EGS-CC components
•EGS-CC components can be combined in various ways to form EGS-CC applications
•The applications are used as building blocks for EGS-CC systems
EGS-CC Kernel
(Core M&C Functionality, Data Handling, Application Support
Reference Implementations
(Mission Adaptation, UI, Preparations, Evaluation
Rereference Test Facilities

Conceptual Overview
Component A
Impl.
Component
Impl.
Component
Component B
Impl.
Component
Impl.
Component
Impl.
Component
Deployable
Unit A
Deployable
Unit D
Deployable
Unit C
Deployable
Unit B
Deployable
Unit E
Application A
Application B
Application C
Application D
System A
System B
Session C
Application C
Application D
Session D
Application D
Session A
Application A
Application B
Session B
Application A
Application C

EGS-CC Components
•The EGS-CC System is composed of layers. Each layer is decomposed into so called
“Level 0” (L0) Components and their provided and consumed services
•L0 components are EGS-CC software packages that cover a functional scope
specified by software requirements and interact with other L0 components only via
well-defined services and interfaces
•L0 components are composites that are further decomposed into lower level
components called Ln Components (n=1,2,…)

Component Decomposition
• The definition of separate Ln components can be governed by deployment
considerations, separation of concerns, etc
•The result of the decomposition process is a set of implementation components
(Ln), which may or may not be deployed together
•A “deployable unit” is defined as a composite that includes implementation
components from a single L0 component that need to be deployed together
Component A
Impl.
Component
Impl.
Component
Deployable
Unit
Impl.
Component
Deployable
Unit
Impl.
Component

Component Decomposition

Implementation Components
•Implementation components are assembled from units implemented in a specific
programming language (Java)
•The development of implementation components is supported by the EGS-CC
Component framework
•The EGS-CC Component framework is based on OSGi and defines the programming
entry point and controls the life cycle of an EGS-CC component

Impl. Component Wiring & Deployable Units
• Grouping of impl. components into functional units (Deployable Units) is done in
the model
• It is a process opposite of component decomposition
• A deployable unit (DU) is a collection of impl. components of a given EGS-CC
component and their internal wiring

Deployable Units Composition
• Every deployable unit has a boundary with ports (consumed and provided
services); this is the “face” of the deployable unit that the application “sees”
• Deployable units are wired automatically; the model supports properties and
filters if the user needs to modify the default wiring
• A deployable unit is realized as a maven project with custom packaging
“deployable-unit” and is generated from the model
− a karaf feature file that lists all needed bundles (implementation components and
apis)
− an optional wiring xml that represents internal service wirings and external ports
expressed in the model

EGS-CC Component
OSGi Bundle
Blueprint
OSGi Bundle
Base Class
OSGi Bundle
Base Class
OSGi Bundle
Base Class
OSGi Bundle
Blueprint
OSGi EGS-CC

EGS-CC Application
•An EGS-CC application is a collection of deployable units (maven project with
dependencies of type deployable-unit)
•For every deployable unit referenced in the application a blueprint wiring is
generated from the model wiring or directly from the base classes contained in that
DU
•An application feature repository is generated to group all required bundles

Wiring -> Blueprint
Deployable Unit Wiring
Boundary Ports
Consumer Ports
Provider Ports
Composition
Internal Ports
Consumed Services
Provided Services
Base Classes
Custom Wiring
Deployable Unit Blueprint
Component
References
Services
Base Class Bean
Component
References
Services
Base Class Bean
…

EGS-CC Application Generation
Deployable Unit
Impl.
Component
Impl.
Component
Wiring
Karaf
Feature
Application
DU
DU
DU
Blueprint
Blueprint
Blueprint
Karaf
Feature
Karaf
Feature
Application
Karaf
Feature
Deployable Unit
Impl.
Component
Impl.
Component
Wiring
Karaf
Feature

EGS-CC System
•An EGS-CC System is a set of system sessions (or sessions) composed of
applications. The application run on physical or virtual nodes
•A session can span multiple nodes
•The relationship between applications, sessions and systems is captured in a
deployment plan
•The deployment plan specifies a schema for each session. The session schema
specifies the relationship between applications and nodes
•EGS-CC deployments are defined by the user at deployment time and cannot be
changed at runtime.

EGS-CC Deployment Plan
Application A
Session A
Node A
Node B
Session B
Application B
Application C
Deployment Plan

Zookeeper
Node
Master Node
EGS-CC System Deployment
OSGi Framework/JVM
EGS-CC Application
EGS-CC Component Framework
EGS-CC Application Control
EGS-CC Distributed Services
OSGi Framework/JVM
EGS-CC Master Application
EGS-CC Runtime Management
OSGi Framework/JVM
EGS-CC Application
OSGi Framework/JVM
EGS-CC Leader Application
OSGi Framework/JVM
EGS-CC Application
OSGi Framework/JVM
EGS-CC Application
Node
OSGi Framework/JVM
EGS-CC Leader Application
OSGi Framework/JVM
EGS-CC Application
OSGi Framework/JVM
EGS-CC Application
Service Registry
System State
Active MQ

EGS-CC Infrastructure
EGS-CC Component Framework (CF)
EGS-CC Application Control (AC)
EGS-CC Distributed Services (DS)

•EGS-CC CF provides the “low level” facilities to implement EGS-CC Components
and also to control their life cycle
•It defines an EgsccActivator interface which is used as an entry point to an EGS-CC
implementation components
− Every EGS-CC implementation component has an EGS-CC base class (implements
EgsccActivator) which defines the consumed and provided services. The stubs of
the base classes are generated from the model
− Specific hooks in the base class control the life cycle of the component. The hooks
are implemented to suit component needs

EGS-CC Base Class

Impl. Component Life Cycle
•The life cycle of an EGS-CC component (e.g. its impl. components) starts with the Init() phase
which corresponds with the activation of an OSGi bundle. This is a single phase where services
are provided and consumed
•It is assumed that after the Init() the component is ready to do work and startProcessing() is
called
•To initiate shutdown stopProcessing() is called. The impl. component can subscribe to different
shutdown levels
Init() startProcessing() stopProcessing()

Service Life Cycle
•For EGS-CC CF a service is any service marked with the EGS-CC annotations
@Service (a stateless service) or @ConversationalFactoryInterface (a statefull
service with or without callback)
•EGS-CF listens for EGS-CC service registrations and unregistrations, using a
standard OSGi ServiceListener
•Every time a new EGS-CC service is registered in the container, CF inspects it and
adds EGS-CC specific properties to it (registers it again with new properties)
− At any given moment two registrations of the same service exist in the container
− CF hides the original service registration by utilizing an EventListenerHook and a
FindHook
− CF makes sure that all other components see only the modified service registration

Service Life Cycle

EGS-CC Service Properties
• egscc-service-status=READY – marker for processed services
• service.pid – sets this standard OSGi property to a random UUID
• system-session-id – sets this property to the current system session ID
provided by the system resources
• service.exported.interfaces=* - only if the service is not marked with
@LocalInterface
• esa.egscc.service.nature – sets this property to the value
esa.egscc.service.nature.local only if the service is marked with @LocalInterface
and the property is not already set. This property can take one of two values:
− esa.egscc.service.nature.local – this means that the service should not be exported, but can be
in certain circumstances;
− esa.egscc.service.nature.internal – this means that the service must never be exported

•EGS-CC Application Control (EGS-CC AC) is the component responsible for
starting and stopping nodes in an EGS-CC system, as well as creating, starting,
stopping, and removing application instances on those nodes
•It also monitors the state and health of every node and every application instance,
and notifies subscribers for all changes

•An EGS-CC node is a single Karaf distribution with a
root instance and zero or more child instances
•All root Karaf instances are called Leaders. A
Leader is a special application which can create,
start, stop, and remove other application instances
on the same node
•There is a special Leader, called the Master, which
operates on the Master node. There is a single
Master per EGS-CC system instance. The Master can
start and stop other EGS-CC nodes

Provided Services
•SystemControlService – A stateless service which provides capabilities to start and
stop nodes, and also create, start, stop, and remove application instances
•SystemStatusService – A stateless service which provides capabilities to inspect
the running system instance
•SystemMonitoringService – A conversational service which is responsible for
subscribing to any state or health changes in the system instance

EGS-CC AC & OSGi Cluster Information
Q: Is EGS-AC an implementation of the OSGi Cluster Information specification?
A: It does not implement NodeStatusService, but provides the
SystemStatusService, which can:
- return a collection of all nodes in the system (cluster) and
- provide status and health information for each node where every node is
responsible to publish its own status.

•EGS-CC Distributed services (EGS-CC DS) handles remote service discovery and
remote procedure call (RPC)
•It hides the fact that an application instance may be using services which actually
reside in another application instance (on the same or on another EGSCC node)

Service Discovery
•Publishes started applications in the service registry
(For every service in the local OSGi container that can be exported, EGS-CC DS publishes the service’s type
and properties in the registry, under the record of the application instance)
•Actively watches the registry for any changes. If it finds exported services from
other application instances, it will import those services
(Registers proxies for remote services, in the OSGi container, with the same type and properties)
•Watches the registry for removed services and application instances
(unregisters proxies from the OSGi Container)

RPC
•Acts as both client and server because it has to be able to call methods on remote
services and also translate remote calls to local service invocations
•An object can be passed as argument by value or by reference
− Any object can be used as a remote reference if it its class is not marked final (or
has an interface)
− If a class of an object is not known in the receiving container it will be resolved by
a network class loader
•Monitors the life cycle of remote instances and ensures that they are properly
garbage collected in the containers
•It is completely transparent for impl. components

RPC

EGS-CC DS & OSGi Remote Services
Q: Is EGS-CC DS an implementation of the OSGi Remote Services specification?
A: It supports directly the concepts of the Distribution Provider and End Point. It also makes
use of the service properties as defined in the OSGi Remote Services specification.
It does not have a direct counterpart for Topology Manager, Remote Service Admin and
Discovery.
For EGS-CC DS the remote service registry:
− notifies other frameworks that a local service has been exported
− keeps track of the remote frameworks and exported services,
− receives events about exported services (registration/unregistration) triggering
import or unregistration of a remote service,
− exposes remote services selectively based on Sessions

EGS-CC Infrastructure & OSGi Specification
•Application Control and Distributed Services are standalone projects and EGS-CC
specific requirements were layered on top of them.
•Application Control and Distributed Services already implement a significant portion
of functionality defined by OSGi Specification
•A layer complient with OSGi Specification can be realized on top of Application
Control and Distributed Services
•The result could be made available to the community (if ESA decides to do so)

The good, the bad and the ugly
“Our prime job is to fly spacecraft not develop software”
•Big projects and consortium syndrome
•Learning OSGi a we go (difficult to backtrack)
•Best practices for service dependency management not applied
•Endless levels of decomposition = bad code
•Technical discussions steered by stakeholders can result in poor design decisions
(as the saying goes: too many cooks spoil the broth)

THANK YOU
Contact:
Anthony.Walsh@esa.int
Hristo.Indzhov@telespazio-vega.de

BONUS SLIDES

Deployable Unit Wiring

EGS-CC Service Patterns
•Stateless Service Pattern
•One-Way Stereotype
•Conversational Service Pattern (± Callbacks)

Stateless Service Pattern
Code usage – Server Side – Service Provider
The server implements the interfaces of the services, according the
needed functionalities. In our example
ConfigurationTrackingServiceImpl class
The server registers the services into the OSGi registry, by using the
Component Framework
Details about the CF are explained later
// Get the EGS-CC Bundle context, provided by the Kernel Infrastructure (CF)
EgsccBundleContext egsccBc = EgsccFrameworkUtil.getEgsccBundleContext();
// The stateless service implementation
ConfigurationTrackingService myService = new ConfigurationTrackingServiceImpl();
// Register the service to the OSGi context
egsccBc.registerService(ConfigurationTrackingService.class, myService);

Stateless Service Pattern
Code usage – Client Side – Service Consumer
The client resolves the service via the OSGi bundle context
Service resolution done by using the Infrastructure utilities, or
by Blueprint, OSGi Service Trackers, etc…
OSGi services are unique in the OSGi Context Stack
Multiple instances are supported by specifying properties
// Get the EGS-CC Bundle context, provided by the Infrastructure
EgsccBundleContext egsccBc = EgsccFrameworkUtil.getEgsccBundleContext();
// Retrieve the service from OSGi
ConfigurationTrackingService myService = egsccBc.getService(ConfigurationTrackingService.class);
// Consume the service via the service object, by calling its methods
ConfigurationItemContainer confItemContainer = myService.getConfigurationItems();

OneWay Stereotype
In EGS-CC the presence of the stereotype <<OneWay>> in methods, can be
placed in both Stateless and Conversational interface methods.
The method must return void and must not declare any exception

OneWay Stereotype
The interface IMcmDefinitionListener in this case will have Java annotations to identify the
One-Way methods
The @OneWay annotation is read by the Component Framework at runtime, and it will
choose the right way to handle it, during the remoting of the service
Details about remoting are explained later
public interface IMcmDefinitionListener
{
@OneWay
void onSubscriptionClosed();
@OneWay
void onUpdate(McmDefinitionSnapshot mcmDefinitionUpdate);
}

Conversational Service Pattern
The Conversational Service pattern in EGS-CC can be defined using the
<<Conversation>> stereotype
Stateful service where the service provider maintains the conversation state
A dedicated instance of the service provider serves one and only one
conversation

The code generation in this case requires a factory interface (Abstract Factory
design pattern), which can be used by the service consumer to initialize the
conversation 
The Java annotation @ConversationalInterface accepts a parameter which
identifies the type of Conversation

The generated code
@ConversationalInterface(type = ConversationType.BASIC)
public interface IMcmDefinitionSupplier
{
@StartConversation
void subscribe(McmDefinitionFilter filter);
@EndConversation
void unsubscribe();
void updateSubscription(McmDefinitionFilter filter);
}
@Service
public interface McmDefinitionMonitoringService extends IMcmDefinitionSupplier
{
}

Flying to Jupiter with OSGi - Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Flying to Jupiter with OSGi - Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega)

Similar a Flying to Jupiter with OSGi - Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega) (20)

Más de mfrancis

Más de mfrancis (20)

Último

Último (20)

Flying to Jupiter with OSGi - Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega)