Highlights of the European Ground Systems - Common Core Initiative

This paper describes an analysis of the formalization of contracts between components in component-based frameworks. The long term objective is to describe each component of the framework in an accurate and selfstanding manner so that the description can be used a) to design and code them in isolation and b) to enable the derivation of test cases to validate them against the formalized description. As part of this analysis several existing approaches (such as the Gherkin language and the concordion framework) were investigated. Based on the results of this investigation, a custom-made toolset was designed and prototyped. The prototype relies on two different approaches to describe the formalized contract: a) The Unified Modelling Language (UML) used together with the tool Magicdraw and b) a purpose-build Domain Specific Language (DSL) defined on top of the Eclipse framework. A small proof of concept was designed to illustrate the approach and the specifications created using those two approaches were automatically converted into tests and executed.

Section: Introductionmentioning

confidence: 90%

“…Furthermore, the code generation technology was 1 Head of Software Technology Section, Software Solutions Department. 2 Consultant, Space Division.…”

Section: Introductionmentioning

confidence: 99%

Automated derivation of tests from specifications

Stoitsev¹,

Straw²,

Legat³

et al. 2018

“…In accordance with this mindset, ESA is building a new generic EMCS infrastructure, with the willingness to reduce costs and to harmonize control centers: the EGS-CC (European Ground Systems -Common Core) [2,3]. Activities aiming at migrating the control centers at ESOC (EGOS-CC) and the EGSE Reference Facility (ERF-CC) to an EGS-CC based solution have started.…”

Section: The New Generation Of Control Centers a Emergence Of The Egs-ccmentioning

confidence: 99%

Challenges to evolve a S2K-based PROBA GS towards EGS-CC

Denis¹,

Verheyden²,

Baudoux³

2018

With the emergence of the EGS-CC (European Ground Systems -Common Core) and the evolution of the technologies, a new generation of control centers is needed. This is the context in which the PROBA-Next Ground Segment Evolution study was conducted. The objective is to evolve the PROBA ground segment, which is based on the SCOS-2000, toward the EGS-CC whilst preserving the characteristics which have made the success of the PROBA missions. The new architecture also includes new functionalities which aim at stepping the PROBA GS into the digitalized era. This paper presents the challenges to evolve a S2K-based ground segment toward EGS-CC as well as the resulting new architecture. I. Introduction to PROBA A. PROBA MissionsPROBA is a low-cost mission microsatellites family that has been initiated with PROBA-1 acting as on-board autonomy demonstrator. This initial small satellite weighting less than one hundred kilograms embarks two Earth Observation instruments taking 20-m resolution hyperspectral images and 8-m resolution gray scale images.It has been followed by PROBA-2, launched in 2009, dedicated to the sun observation and PROBA-V, launched in 2013, continuing the Vegetation monitoring started with the Vegetation instruments on board the French SPOT-4 and SPOT-5 earth observation mission.PROBA-3 with a launch date scheduled at end of 2020 will assure the continuity of the program by demonstrating the formation flying of multiple spacecraft.Although its specification of operational life was limited to 2 years, PROBA-1 has celebrated its 16 th year of operations becoming the longest operated earth observation mission of all time. B. PROBA Ground SegmentSince its first mission, PROBA has put ahead autonomy as a key driver on the mission architecture and concept. This autonomy is implemented on board through a high level commanding as well as a safe by design system architecture requiring no time critical operations.Another major characteristic of PROBA is to address mission targeted to small satellite with a low cost budget. This budget objective is reached through a maximum automation in flight and within the ground segment. This limits the cost of the operations during the satellite operational life.The development cost is also optimized by using at the early stage of the AIV the future control center as EGSE testing tool. This approach alleviates the validation of the operational environment as it is an evolution of the spacecraft testing environment. This approach has several impacts on the control center architecture forcing the architecture to be modular as well as adaptable from an AIT environment up to an operational environment.The spacecraft is operated according to the PUS standard [1]. The full automation of the operations is obtained through a set of Flight and Ground Control Procedures that have been gradually developed and tested during the satellite AIV activities.

“…Based on this common set of components, various monitoring and control systems for missions in their pre-and post-launch phases and even for ground stations can be composed all throughout Europe. [1] To compose such systems, new components can be added either on top of the existing system, or can replace components of the reference implementation to add new functionality. Several stakeholders have already started this process of creating their own M&C systems for both spacecraft and ground stations, which is referred to as the integration process.…”

Section: Introductionmentioning

confidence: 99%

EKSE: A Command Line Interface for EGS-CC based Systems

Schiller¹

2018

Until recently, the interaction with systems based on EGS-CC (the European Ground Systems Common Core) was limited to the graphical user interface developed as part of its reference implementation. However, the need has been identified for an interactive console to interface the system. Several approaches for such an interactive console have been considered and will be introduced in this paper. The approach finally chosen is referred to as EKSE (EGS-CC Karaf Shell Extension), which enables users to define commands based on scripts which can even be created at runtime, enabling fast prototyping for interactions with the backend. Particular challenges will be highlighted and approaches for meeting them will be proposed.