OPALE: Reducing complexity of EGS-CC Automation Procedures

Transcription

1 SpaceOps Conferences 28 May - 1 June 2018, 2018, Marseille, France 2018 SpaceOps Conference / OPALE: Reducing complexity of EGS-CC Automation Procedures Salor Moral, Nieves 1 RHEA Group, Madrid, Spain Dionisi, Simone 2 SCISYS Deutschland GmbH, Darmstadt, 64293, Germany Trifin, Francois 3 ESA-ESOC, Darmstadt, 64293, Germany With the ongoing development of the European Ground System-Common Core project; different stakeholders are analysis the possibility to maintain their automation procedure languages within the new framework. This paper presents the OPALE demonstrator developed in collaboration with the European Space Operations Centre. This demonstrator analyses the capability of translating existing languages into the EGS-CC Language and integrating the components so execution of such procedures can take place. Nomenclature APPG = Automation Procedure Preparation Guide AIT = Assembly, Integration and Testing CDM = Conceptual Data Model DSL = Domain Specific Language EAPL = EGS-CC Automation Procedural Language EGS-CC = The European Ground Systems Common Core ESA = European Space Agency ESL = A prototype DSL language for EGS-CC at ESOC ESOC = European Space Operations Centre IR = Integration Release MCM = Monitoring Control Model OPALE = Operations Automation Language Environment OPEN = Operations Preparation Environment POJO = Plain Old Java Object RCP = Rich Client Platform SCOS = Satellite Control and Operation System Test Double = Generic term for any case where you replace a production object for testing purposes UI = User Interface I. Overview he current Mission Control Systems in ESOC are based on SCOS (S2K) and used by nearly all spacecrafts for Tall monitoring and control activities. It is a generic system, tailored for the specific needs of each mission. The core of the system provides comprehensive telemetry processing, manual and automatic commanding, on-board software management, mission archive and data distribution. 1 Architect and Senior Software Engineer, Ground Segment System Department, n.salor@rheagroup.com 2 Project Manager, Ground Segment Department, simone.dionisi@scisys.de 3 Technical Officer, Ground Data System Infrastructure Division, Francois.Trifin@esa.int 1 Copyright 2018 by the, Inc. All rights reserved.

2 In the context of trying to support space systems monitoring and control in pre- and post-launch phases for all mission types a new European initiative to develop a common infrastructure has been undertaken: The European Ground Systems Common Core (EGS-CC). The essence of EGS-CC is to support space systems monitoring and control in pre- and postlaunch phases for all mission types. This is expected to bring a number of benefits, such as the seamless transition from spacecraft Assembly, Integration and Testing (AIT) to mission operations, reduce cost and risk, support the modernisation of legacy systems and promote the exchange of ancillary implementations across organizations. The initiative is being performed as collaboration between ESA, European National Agencies and European Industry. Within the EGS-CC design group, lengthy discussions were carried out in order to formalize a procedure language that would be applicable across all phases and missions. The final result of those discussions was the agreement to use a Javabased programming language as procedural language for ground automation to execute deterministically, so they can be exchanged and/or reused between missions and phases. Therefore, a set of pre-defined supporting libraries were needed to be defined in order to expose the most common functionalities any user could request. This language, commonly known as EGS-CC Automation Programming Language (i.e. EAPL), is defined in an standard document named APPG 2. However, Java 3 is not applied in its basic, most-commonly used shape; as the application of annotations and lambda expressions is deeply required. These new aspects of the language are not trivial even for an experienced programmer; thus, the target stakeholder set of the EGS-CC is deeply reduced. In general, the use of any software programming language for procedure definition assumes final users have experience Figure 1. OPALE Deployment within EGS-CC programming in such language. This is not the case in most situations and deployments, as operators or final users do not have to know Java and furthermore, some users, such as scientific, may not have any programming skill at all. In order to improve the user experience and allow reusing the knowledge of already existing procedures written in other languages, a layer on top of the EGS-CC (i.e. a Reference Implementation, in EGS-CC terms) was developed. This layer is the focus of the OPALE project that is presented in this paper. OPALE allows the creation and edition of procedures in the grammar most suitable to the final users, while the real execution would be delegated to the EGS-CC Automation Component. II. OPALE Workflow Considering the high number of possible stakeholders for the preparation, visualization and execution of automation procedures, OPALE needs to offer multiple and scalable ways of preparing a procedure that shall always be executed and/or debugged by EGS-CC. This approach enforces that all inputs need to be translated into EAPL prior being compiled and executed inside EGS-CC. Following this workflow, the execution and/or debugging of a procedure must be traced back to the format in which the user defined the procedure and not to the Java one. Therefore, a connection between OPALE preparation environment and the execution one of the EGS-CC is needed for showing the executing/debugging information to the client within the DSL editors. 2 American Figure Institute 2. OPALE of Aeronautics General Purpose and Astronautics Overview

3 In order to demonstrate the viability of such approach, the OPALE project offers a preparation environment to create and edit procedures with a DSL adapted to needs and knowledge of the final users. As base grammar has been selected the one implemented for the MATIS project, compliant to the ESA standard ECSS-E-ST-70-32C 4 procedure standard (commonly known as PLUTO). Using one of the functionality provided by the technology selected (i.e. XText) it was possible to extend the grammar to mix its rule declarations to reuse or specialize them In this way any grammar element can be replaced by new syntax, new validation can be added and so on. The customized grammar is the so-called ESL language 5, a language created ad hoc during the project to try to remove all the difficulties that the ESOC users had with the PLUTO language and adding new statements that can match the new functionalities provided by the EAPL. III. System Architecture In the OPALE architecture some requirements have weighted heavily in the final design. The project has followed an Agile approach. This approach supports the development of a no monolithic architecture in which requirements and capabilities of the used technologies have been changing during the development and were not known completely at the beginning. Because of the uncertainty of the requirements and of the legacy system that OPALE has to interface with, the final architecture is modular and technology independent (in case some technology did not satisfy the needs or in the future a new one was more adapt to the task). Considering modular architectures, the design of the OPALE project could have followed a layered approach or a service-based one. However, taking into account that OPALE is understood within the EGS-CC Framework, it is only sensible to extend its architecture approach to the one of EGS-CC. Hence, the OPALE architecture has been designed to conform to the EGS-CC standards to provide a smooth integration and escalation of the solution in future years. Taking these requirements in consideration, OPALE has been developed as an OSGI service-oriented architecture using RCP for the UI part. During the exploratory phase of the project, which dealt with the viability of the language generation and transformation, the prototyped DSL editors and language generators were handled as stand-alone applications. Likewise, the debugging capabilities were also prototyped to demonstrate the viability of debugging procedures in a DSL format but taking place in the AP language within EGS-CC. In order to produce these prototypes and since the EGS-CC system was not available at start-up of the project, test doubles were first developed to fake the EGSCC behaviour. As such, integration issues were discovered for the communication between editor technologies (i.e. Xtext 6, GEF4 7, EMF 8 ) and EGSCC requirements (e.g. OSGI, KARAF, etc.). Figure 3: OPALE Architecture Diagram 3

4 In the process of architecting the overall system, those prototyped components had to be re-designed to make them work integrated with the OPALE and EGSCC services. This was done through the wrapping of most of the communication by a bridge-alike component called OPALE-Middleware which hides the complexity of dealing with OSGI services and more specifically with EGS-CC ones, becoming the OPALE Execution Environment. Therefore, in case the system wants to work only in an offline manner, this bridge could be substituted by a simulator. As such, the resulting diagram of the OPALE Architecture is represented in the Figure above. Nevertheless, even with the developed architecture, applying the EGS-CC standards and wrapping the relevant technologies needs through a middleware layer; communication between OPALE and EGS-CC has been ensured. This task, done through RCP applications for the User Interfaces, is proving to be challenging even within the EGS- CC framework. Therefore, the system has been architected to contain two main components: One preparation environment and one communication middleware. A. Preparation Environment The preparation environment is an RCP application containing textual editors which allow the creation of ESL procedures in textual format with all traditional editing capabilities (e.g. syntax highlighting, context assist, template, outline view, validation etc.) The system includes a graphical editor for some of the ESL main structures. The transformation from graphical into textual and vice versa is also supported. The module responsible of the transformation from ESL code into EAPL format is also part of the preparation environment. In the final integrated design of the system, the foreseen available views of the client, as a minimum, are: The MCM Browser: Tree view displaying the information contained in the MCM model from EGS-CC. This view is not part of the OPALE development, as it is already part of other tools with which OPALE is integrated (e.g. EGS-CC UIF, OPEN 9, etc.). The Procedure DSLs Textual Editors: Textual Editors created with Xtext/Xtend according to the DSL grammars for defining procedures. The Procedure Graphical Editors: they are visual representations of the DSL that help the user viewing the current state of the procedure implementation. The Procedure Executor View: Display of the execution status of the executed activities. The Debug Views: Reuse of the Eclipse JDT 10 views and linked with the textual DSL editors. It includes the Execution Stack View, the Breakpoints View and the Variables View, plus the functionality that if a procedure execution stops at a breakpoint or if the user steps through a DSL file, the corresponding line is highlighted in the DSL editor. In summary, with this client component, the user shall be able to create, edit and visualise procedures in their target language and also the corresponding EAPL code. B. Execution Environment As specified before, the EGS-CC Middleware component is the responsible of wrapping up the communication OPALE components need with the backend system (i.e. EGS-CC). Most of the components can provide offline responses to the queries from the preparation environment. Therefore, this layer is execution-safe against backend unavailability. However, and although the specified robustness is needed, this layer should always be present to provide the required information to the preparation environment. The OPALE components interact with the backend system through OSGI interfaces in the same manner as the architecture of EGS-CC does. Following this mechanism, the backend system can be substituted by any other while the interface contract remains unchanged. IV. Development tasks Due to OPALE being one of the first attempt from the agency side to develop a system on top of the common core and to have it running against a non-stable backend system, the required work had to be decomposed in two phases. The first phase was basically prototyping to analyse the viability of the technologies to be used in the project whilst 4

5 the second phase was a re-engineering for reaching the full capability of the system with an integration in the EGS- CC system. A. Creation of the procedure editors For satisfying different stakeholders and even proving support to legacy systems, input languages needed to be defined. By requirements, the OPALE project had to focus on textual input ways. However, an analysis of the possibilities for a graphical representation of procedures was also required. Textual editors are based on formal language grammars (usually in EBNF format). Lexical and syntactic analysers, together with dedicated user interfaces exposing common editing capabilities such as syntax highlighting, content assist, syntactic and semantic validation support, outlining, reference scoping or template support, are generated from those grammars. Within OPALE, besides the normal editing capabilities, there is also the need for the translation of the input languages into the output EAPL one. In compiler theory, the translation module (i.e. responsible of converting the input language in its corresponding output one), comes after the semantic analyser. Hence, as OPALE has to be prepared for transforming multiple input languages sharing the same semantics into the same output one, there is a need for avoiding the duplication in the translation mappings. The translation impact can be reduced by the creation of a multi-level hierarchical conceptual model containing the common semantics. Exchanging information is possible and correct due to the inherited semantic compatibility Figure 4: Multi-level semantic model between languages. Sharing semantics ensures exchanged concepts and their relationships are the same, because they must comply with the same rules and constraints. Adding or modifying semantic-structures in a language potentially creates minor divergences that should only be added to the specific implementation without disabling the requirements of the parent model. For the translation into EAPL, this multi-level hierarchical model means that translations will be done only at the level in which the model objects are defined and automatically inherited in the child ones. For changes in EAPL code, the transformation shall affect only the top-level language translator in which that structure first appeared. While when there is a new language, only those structures that are not existing in a parent model shall be mapped to EAPL. Applying this concept, the ESL grammar was done by creating a common conceptual model in Ecore format including common statements, expressions and bodies of a procedure. Once the common semantic model was generated, for each of the supported languages, the EBNF grammar was written in Xtext format pointing to the Ecore objects to be populated by each statement. 5

6 As monitoring and control activities, procedures provide a way to interact with and verify other activities, parameters, events or monitoring elements. Therefore, allowing cross-references to the monitoring and control elements used within a procedure is a mandatory and high priority requirement. These elements are contained inside the Ecore model known as CDM of the backend system (i.e. EGS-CC). However, the executed procedures do not reference directly to this model, but to their corresponding POJOs, generated from the Automation component, which are contained within of a JAR set file known as the MCM Jar set. As a result, a reference scope had to be created and populated with those objects for the correct edition, validation and consistency checking of the input texts. Figure 5 - OPALE Editor capabilities Once defined the grammars pointing to the Ecore models, the compilers, analysers and the default textual editors have been automatically generated using the Xtext libraries. Some extra work was required for customising the views (e.g. outline, error, content assist, etc.) and adding extra semantic checks (e.g. warning and info messages) so procedures could be written/edited, as shown in the figure, within the RCP application, known as the OPALE preparation environment. In parallel with the textual grammar development a research activity looking into the current state of the art of visual programming, with the aim of selecting a graphical paradigm that is the best manner to represent procedures through a graphical form, was carried out for OPALE. Visual programming is not currently used for general-purpose programming languages, but has found its use in niches (e.g. educational environments, multimedia, modelling and simulation, testing and instrumentation, workflow automation, etc.) where the users of a software system are expected to perform a programming activity without being professional programmers themselves. This is due to the advantages and disadvantages of visual programming languages compared to textual programming languages. The advantages are: The editor ensures there are no syntactic errors, which are a major cause of confusion and frustration for the unexperienced users. The editor provides a toolbox showing visually to the users all the possible constructs and components that can be used, aiding in the learning and discovery of the language features. The shapes of the language constructs can help the user remember its functionality. Some of the analysed aspects were: the paradigm to be displayed (e.g. execution sequences, functions, logic flows, structures, data), the target environment in which the system is going to be used (i.e. AIT, operations, post-processing); constraints to be considered (e.g. synchronisation, parallelism); representation manners (e.g. block-based tools, flowcharts, hierarchical representations) and the possibility of offering reverse synchronisation between textual and graphical forms. 6

7 Finally, a block-based approach similar to Scratch 11 was prototyped as can be seen in the figure below. First, because it allows showing both flow control and linear structures; second, as ordering constraints could be enforced to ensure validation; third because palletes could be created and improve the user experience and fourth and foremost, because EMF libraries could be used to create the graphical representations of the language structures and to point to the Monitoring and Control referenced objects and integrate those easily into the OPALE preparation environment. Figure 6 - Procedure Graphical Editor Demonstrator However, and even if an operational procedure could be prepared graphically, the task is time consuming for a normal mission procedure and the benefits of such task are not even clear to the stakeholders. Nevertheless, the development of such editor and the effort associated provides a good starting point from a deeper analysis into what are exactly the needs for a graphical procedure editor and the importance of developing a graphical representation standard. B. Translation from ESL into EAPL The strong dependency of OPALE with the EGS-CC for the execution of the procedures creates the need to translate the input language into EAPL. Furthermore, the capabilities of ESL need to be supported by EGSCC either explicitly (i.e. through a one to one mapping) or implicitly (i.e. through multiple sequential mappings). The rules for the translations were made in an incremental manner, prior to any code development, for two reasons: on one side, the target language (i.e. EAPL) was still suffering major changes in existing constructions during the project development time and on the other, some constructions were being analysed for inclusion in EAPL. Figure 7 - Procedure Generation Code 7

8 One example of these changes focuses in the manner on accessing arguments and parameters within a procedure. As it changed drastically between sequential Integration Releases of EGS-CC, the translator of OPALE was upgraded to the version of IR2 instead of keeping up the IR1 one. The reason for such modification was that in operational status the EAPLs would be closer to the IR2 than to IR1 as parameters in EAPL were no longer generated and arguments would be defined as methods instead of as passing values. These changes, if not done, would render OPALE impractical at the end of its development time. For each ESL grammar structure, a dedicated issue was created defining how the corresponding EAPL should look like. The transformation from one format to the other was performed using the library Xtend in the generator package predefined of the Xtext. It is important to remark that not all the grammar structures of ESL have been transformed into EAPL for the moment (e.g. parameter declarations, save context statement, operation request statement ). Consequently, it is possible that some ESL code is validated correctly while the EAPL does not compile because of lack of transformation of some structure. This does not mean that it is impossible, but just that more work should be continued to give full support to ESL inside the EGSCC. C. Providing debugging information to EAPL OPALE needs debugging capabilities at ESL level instead of an EAPL one. As the procedures are executed in JAVA, EGSCC is deployed in Eclipse environment and uses the Eclipse compiler, OPALE needs to use the same technologies for linking the ESL code with the EAPL code executed by EGSCC. The technology allows doing that is through the SMAP traces provided by the JSR-045 standard and used by the Xtend technology 12. These traces are short bytecode strings that are added to the generated class files with the only scope to link the ESL lines of code with the EAPL compiled bytecode. The way of adding these traces to the generated code is through notation in the Xtend code. Once the EGS-CC AUT component has compiled the generated EAPL procedure, OPALE attaches the traces bytecode at the end of the generated class. In this way, when there is a request for debugging an ESL procedure, normal Debugging capabilities will be available and breakpoints established in the ESL code will be associated to the line of the correspondent EAPL code. As the default debugging variable view was not user friendly, as it was showing the information of the EAPL variables, a custom variable view was created to show the variables at ESL level by overriding the information coming from the JDT library. D. Requesting the execution of an ESL procedure The OPALE framework is basically a middleware layer that performs the calls and transformation between the ESL code requests and the EGSCC needs. It creates a tunnel to exchange the information and receive feedback performing in the correct order the required actions as expected by EGSCC. The flow implemented by the OPALE server side, since the moment the request for execution is done till the execution is completed, can be described as: 1. Through the preparation environment UI, the user shall request the execution of a procedure to start the process 2. The OPALE framework requests the compilation of the selected procedure to the backend system (i.e. EGS-CC). Prior to the compilation, and in order to be able to compile, OPALE has to store, in parallel, the textual content of the EAPL procedure: a. inside a pre-defined definition object of the monitoring and control model. b. in the predefined filespace for the Automation component of the backend system (by using the file manager component of the EGS-CC, i.e. FIM) 3. After a successful compilation of the EAPL procedure by the backend system, OPALE retrieves the generated Class file, attaches the SMAP traces at the end of the file and stores it back in FIM. 4. When the storage has been successful, OPALE framework invokes the backend automation service for the execution of a Procedure by name and registers a listener for receiving the notifications of the execution statuses which is forwarded towards the dedicated execution view. 8

9 Figure 8- Procedure Execution View E. Integrating the OPALE System with the backend EGSCC As OPALE has been developed as a satellite project of EGS-CC and is understood within its influence, it was fundamental to demonstrate the communication between both systems not only at interface and architecture level, but also at execution time. Therefore, during the development, and as the EGS-CC was still in development, test double bundles of the real EGS-components were used to simulate the expected behaviours within a dedicated Karaf container. However, the main idea of integrating OPALE with EGS-CC was to replace those test doubles from OPALE with the real remote EGS-CC services, once that the official release is available. One important aspect of this task was to ensure that the replacement of test doubles with the real remote EGS-CC services did not have any impact on the normal behaviour of OPALE functionality. While performing such changes, two types of issues appeared. On one side, there are problems already discovered within the frame of EGS-CC but not solved for the release version against which OPALE has been developed and tested. On the other, unknown issues were discovered with the deployment of EGS-CC and/or functionality the real component implementations do not contemplate. For the former type of issues, a work-around has been implemented to allow the deployment and execution; for the later an issue in the frame of EGS-CC project has been raised to provide a harmonized solution in the required implementation component for all stakeholders. F. Integrating the OPALE System with the OPEN Framework This task represents the perfect demonstration of the great flexibility and adaptability that an Agile development process can bring to a project. The OPEN project started more than one year after the official start of the OPALE project. Anyway during the OPALE development it looked quite evident that an integration between the two ESOC tools was a quite mandatory requirement that will open the possibility to have a unique and integrated tool for data and procedure preparation. In fact, OPEN is a light framework supporting generic services and features which can be expanded via specific extensions to cover specific preparation application needs. The aim is to use the framework to develop applications covering the full scope of mission operations data preparation. The framework is meant to be light, data type agnostic and extendable by specific extensions covering specific data types or services. While the implementation of the framework started in 2017, by the time the OPALE project ended, it was already possible to perform a light integration of an ESL Editor. However, seeing as OPALE requires EGS-CC to be deployed together for the full editor to work (i.e. due to the MCM linked references inside the procedures), the complete integration could not be performed. This was a limitation on the current EGS-CC architecture and a change request has been raised to the project in order to solve the design problem, allowing the EGS-CC exposing the MCM references so that they can be used in an off-line manner. As a trade-off, and as this exercise was an initial proof of concept of the OPEN integration, it was decided to simplify the ESL language removing the checks of any MCM references. Therefore, a simplification of the ESL grammar editor was performed. With which, the OPALE editor (containing the same validation, templates, formatting, etc. capabilities than the full grammar one) was added as a dependency plugin to the OPEN framework 9

10 V. Conclusion The feasibility study has demonstrated that the approach of producing automation procedures using a DSL is possible while adapting to the new execution environment of EGS-CC. This work has been done within the budget constraints and the dependability of the EGSCC updates and delivery times. It is important to remark that OPALE constitutes one of the first systems built on top of the EGSCC and using as it is expected instead of creating bridges or substituting parts. Furthermore, the work has been done using an intermediate release version of EGSCC. As such, multiple bugs have arisen and solutions been found to improve future releases of EGSCC and also clues on how to develop other Reference implementations. During the project, multiple issues have been found in DSL transformation, debugging approach, representation of the procedures and integration with EGSCC. Although overcome for this study project, those remaining open points are worth investigating further. Therefore, after demonstrating the viability of the OPALE project, multiple branches appear for future work on the same path. On one side, if the approach studied with this project will be selected for operational the current prototyped transformation of the ESL language into EAPL code and related language would need to be completed. On top of the pure transformation development work, a tighter relation with the CDM is required. Currently OPALE makes use of the MCM Jar Set generated by the Automation component; however, this is not user friendly in a pure integrated environment where users do not need to know there is code generation within EGSCC and the only information they see is the pure CDM displayed in OPEN. As such, a modification on the ESL grammar and the transformation engine would be required to link the CDM directly at ESL level and transparently to the user discover which generated code is required to be used. References 1 European Space Agency, SCOS-2000, Database Import ICD, EGS-CC System Engineering Team, Automation Procedure Programmer's Guide, ESA (unpublished) 3 JAVA, by Oracle; tested by 25th April ECSS-E-70-32C - Ground systems and operations-procedure definition language; issue 2.0,July Francois Trifin; Issue 1.0; OPALE Automation Procedure ESL 1.0 Specification 6 Xtext Library, Open-source framework under Eclipse ; tested by 25 th April GEF Library; Open-source framework under Eclipse ; tested by 25 th April EMF Framework; Open-source framework under Eclipse ; tested by 25 th April Francois Trifin, Anthony Walsh; The Next Generation Mission Operations Preparation Environment at ESOC; Workshop on Simulation and EGSE for Space Programmes (SESP) March Eclipse JDT; Open source project under Eclipse; tested by 25 th April ISBN Marji, Majed (2014). Learn to Program with Scratch. San Francisco, California: No Starch Press. pp. xvii, 1 9, Sven Efftinge, Sebastian Zarnekow, Extending Java, Pragmatic Programmer Magazine, Dec