OSGi Community Event 2018 Presentation by Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega)
Abstract: The European Space Operations Centre (ESOC) is the main operations center for the European Space Agency (ESA), operating a number of earth observation and scientific missions. Monitoring and control functions needed by spacecraft operators are provided by software systems which are reused across missions, but tailored and extended for mission specific needs. The current generation of monitoring and control systems are becoming obsolete and a European wide initiative called the European Ground Systems Common Core (EGS-CC) (http://www.egscc.esa.int) has been started to develop the next generation.
This talk will explain why OSGi was chosen and how it is used in the development of next generation of monitoring and control software. It will describe how OSGi provides the necessary framework that enables the software to be extended for the different space systems it is expected to support. The overall software architecture will be discussed, some of the challenges faced and the benefits gained by using OSGi. The first target mission for the system is JUICE (http://sci.esa.int/juice) which will explore the moons of Jupiter and which is scheduled for launch in 2022.
Email Marketing Automation for Bonterra Impact Management (fka Social Solutio...
Flying to Jupiter with OSGi - Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega)
1. ESA UNCLASSIFIED - For Official Use
Flying to Jupiter with OSGi
Anthony Walsh, ESA
Hristo Indzhov, Telespazio Vega
2. ESA UNCLASSIFIED - For Official Use !2
What has OSGi to do with Juipter?
OSGi + =
3. ESA UNCLASSIFIED - For Official Use !3
Spacecraft Mission Control
ESOC Operations Centres
Mission Control System (MCS)
Telecommands
Telemetry
ESTRACK Control Centre (ECC)
4. ESA UNCLASSIFIED - For Official Use !4
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
5. ESA UNCLASSIFIED - For Official Use !5
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
6. ESA UNCLASSIFIED - For Official Use !6
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
7. ESA UNCLASSIFIED - For Official Use !7
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
8. ESA UNCLASSIFIED - For Official Use !8
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
9. ESA UNCLASSIFIED - For Official Use !9
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
10. ESA UNCLASSIFIED - For Official Use !10
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
11. ESA UNCLASSIFIED - For Official Use !11
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
12. ESA UNCLASSIFIED - For Official Use !12
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
13. ESA UNCLASSIFIED - For Official Use !13
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
14. ESA UNCLASSIFIED - For Official Use !14
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
15. ESA UNCLASSIFIED - For Official Use !15
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
17. ESA UNCLASSIFIED - For Official Use !17
Project Organisation
•The project spans
− 8 Countries,
− 17 Companies,
− 23 Teams and
− 43 Components
• 11 System Architects
• 12 Integration and Validation Engineers
18. ESA UNCLASSIFIED - For Official Use !18
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
20. ESA UNCLASSIFIED - For Official Use !20
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
21. ESA UNCLASSIFIED - For Official Use !21
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
22. ESA UNCLASSIFIED - For Official Use !22
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,…)
23. ESA UNCLASSIFIED - For Official Use !23
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
25. ESA UNCLASSIFIED - For Official Use !25
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
26. ESA UNCLASSIFIED - For Official Use !26
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
27. ESA UNCLASSIFIED - For Official Use !27
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
29. ESA UNCLASSIFIED - For Official Use !29
EGS-CC Component
Deployable Units Composition
OSGi Bundle
Blueprint
OSGi Bundle
Base Class
OSGi Bundle
Base Class
OSGi Bundle
Base Class
OSGi Bundle
Blueprint
OSGi EGS-CC
30. ESA UNCLASSIFIED - For Official Use !30
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
31. ESA UNCLASSIFIED - For Official Use !31
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
…
32. ESA UNCLASSIFIED - For Official Use !32
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
33. ESA UNCLASSIFIED - For Official Use !33
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.
34. ESA UNCLASSIFIED - For Official Use !34
EGS-CC Deployment Plan
Application A
Session A
Node A
Node B
Session B
Application B
Application C
Deployment Plan
35. ESA UNCLASSIFIED - For Official Use !35
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 Component Framework
EGS-CC Application Control
EGS-CC Distributed Services
EGS-CC Runtime Management
OSGi Framework/JVM
EGS-CC Application
OSGi Framework/JVM
EGS-CC Leader Application
EGS-CC Component Framework
EGS-CC Application Control
EGS-CC Distributed Services
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
36. ESA UNCLASSIFIED - For Official Use !36
EGS-CC Infrastructure
EGS-CC Component Framework (CF)
EGS-CC Application Control (AC)
EGS-CC Distributed Services (DS)
37. ESA UNCLASSIFIED - For Official Use !37
EGS-CC Component Framework
•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
39. ESA UNCLASSIFIED - For Official Use !39
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()
40. ESA UNCLASSIFIED - For Official Use !40
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
42. ESA UNCLASSIFIED - For Official Use !42
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
43. ESA UNCLASSIFIED - For Official Use !43
EGS-CC Application Control
•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
44. ESA UNCLASSIFIED - For Official Use !44
EGS-CC Application Control
•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
45. ESA UNCLASSIFIED - For Official Use !45
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
46. ESA UNCLASSIFIED - For Official Use !46
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.
47. ESA UNCLASSIFIED - For Official Use !47
EGS-CC Distributed Services
•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)
48. ESA UNCLASSIFIED - For Official Use !48
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)
49. ESA UNCLASSIFIED - For Official Use !49
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
51. ESA UNCLASSIFIED - For Official Use !51
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
52. ESA UNCLASSIFIED - For Official Use !52
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)
53. ESA UNCLASSIFIED - For Official Use !53
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)
54. ESA UNCLASSIFIED - For Official Use !54
THANK YOU
Contact:
Anthony.Walsh@esa.int
Hristo.Indzhov@telespazio-vega.de
60. ESA UNCLASSIFIED - For Official Use !60
EGS-CC Service Patterns
•Stateless Service Pattern
•One-Way Stereotype
•Conversational Service Pattern (± Callbacks)
61. ESA UNCLASSIFIED - For Official Use !61
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);
62. ESA UNCLASSIFIED - For Official Use !62
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();
63. ESA UNCLASSIFIED - For Official Use !63
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
64. ESA UNCLASSIFIED - For Official Use !64
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);
}
65. ESA UNCLASSIFIED - For Official Use !65
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
66. ESA UNCLASSIFIED - For Official Use !66
Conversational Service Pattern
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
67. ESA UNCLASSIFIED - For Official Use !67
Conversational Service Pattern
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
{
}