dataesr/scientific-paragraphs-categorization huggingface dataset:
fits" files) and split each HST observation into 5 sub-exposures of equal exposure time. From each subexposure image, he extracted the stellar spectra using a slanted rectangular extraction box with an aperture of 40 pixels and the background employing an identical extraction box, but shifted upwards by 130 pixels. He then removed the relative background from the stellar spectra, phased each sub-exposure with HST's orbit, and tried to correct for the breathing effect. To do this, he excluded the observations obtained during the first HST orbit of each visit, because the first HST orbit is notoriously affected by additional systematics. He modelled the breathing effect separately for each HST visit as a polynomial of varying order, selecting the one that minimizes the Bayesian Information Criterion: BIC = χ 2 + k log N , where k is the number of free parameters and N is the number of data points.
ACKNOWLEDGMENTS This study was based on observations with the  NASA/ESA Hubble Space Telescope , obtained from the data archive at the  Space Telescope Science Institute. STScI is operated by the  Association of Universities for Research in Astronomy, Inc. , under  NASA  contract  NAS5-26555. Support for this work was provided by  NASA  through grant number  GO-16319  from  STScI. This study also utilized data obtained at the  W. M. Keck Observatory , which is operated as a scientific partnership among the  California Institute of Technology , the  University of California  and the  National Aeronautics and Space Administration. The Observatory was made possible by the generous financial support of the  W. M. Keck Foundation. L. dos Santos and  D. Ehrenreich  acknowledge that this project received funding from the  European Research Council (ERC)  under the European Union's  Horizon 2020 research and innovation programme  (project  Four Aces  grant agreement No  724427 ), and it has been carried out in the frame of the  National Centre for Competence in Research Plan-etS  supported by the  Swiss National Science Foundation  (SNSF).
Unlike conventional software, robotic software suffers from a lack of methods and processes that could systematize and facilitate development. Thus, the application of software engineering techniques is at the heart of current issues in robotics. The work presented in this paper aims to facilitate the development of robotic software and to facilitate communication between experts in the field through the use of software engineering techniques and methods. It proposes RsaML (Robotic Software Architecture Modeling Language), a Domain Specific Modeling Language (DSML) dedicated to robotics, which takes into account the different categories of robotic software architectures and makes it possible to describe the latter independently from the implementation platform. The conceptual model defining the terminology and the hierarchy of concepts used for the description and representation of robotic software architectures in RsaML are presented in this article.
RsaML is defined through a meta-model which represents the abstract syntax of the language. The real-time properties of robotic software architectures are identified and included in the meta-model. The use of RsaML is illustrated through several experimental scenarios of the language: the definition of a robotic system and the description of its software architecture, the verification of the semantics of a robotic software architecture, and the modeling of a robotic system whose software architecture does not belong to the usual categories. The support tool used for implementations and experimentation is Eclipse Modeling Framework (EMF). The results of experimentation showed good working of the proposed solution and made it possible to validate the main concepts of the RsaML language.
Nevertheless, such application requires investigating and proposing solutions adapted to the robotic domain at the different levels (expression of need, detailed design, etc. ). This paper, therefore, aims at proposing answers to the above questions of roboticists, by proposing software engineering solutions adapted to the robotic field and following the software engineering process. It focuses on the design step of the software engineering process and, more precisely, on the investigation and proposal of RsaML, a DSML for the robotic domain that makes it possible to facilitate the design of robotic software architectures satisfying software engineering principles (modularity, reusability, scalability, portability, maintainability, etc. ). The remainder of the paper is organized as follows.
Overview of Eclipse Modeling Framework (EMF) The choice of a meta-modeling technology depends primarily on the availability of tools to support the development of a complete solution. The Eclipse Modeling Framework (EMF)  [26]  is the leading open-source tool in this area. It provides enhanced support for graphical and textual notations modeling languages and for validating model constraints, the model to model and the model to text transformations. The various tools of this framework follow the standards of the Object Management Group (OMG)  [46] [47] [48]. EMF provides code generation capabilities, allowing us to define a model either in UML, XML, or Java form, and to generate the other forms from this latter as well as the corresponding implementations classes. Regardless of the technology used to define a model, EMF is the common high-level representation that "gathers" them all together  [49].
In  [58] , authors present the contributions of model driven approach compared to code driven approach in the development of robotic software systems. In  [18] , the authors propose an overview of Model Driven Engineering approaches in robotics. They point out the complexity of robots development due to the variety of hardware and software components and the lack of common standards. The PuRSUE (Planner for RobotS in Uncontrollable Environments) approach defined in  [59]  aims to support developers in the rigorous and systematic design of high-level execution control strategies for robotic applications. In  [60] , the authors provide a catalog of 22 mission specification models for mobile robots, as well as tools to instantiate them to create robotic mission specifications. The work carried out in  [61]  provides an end-to-end overview of how robotic software systems can be formally specified from requirements modeling to architecture modeling, and from the latter to executable code generation.
The above works are related to a general application of MDE to robotics. Other works, such as those presented in  [62] , targeted more specifically the development of DSML for robotics. Hereafter, we briefly present SmartSoft  [63]  and RobotML  [64] , that are among the most recent. SmartSoft is a component-based framework for robotic software that focuses on the communication model between components. It offers a predefined set of generic communication patterns based on standard communication services (client/server, master/slave, request/response, etc. ) that the user can compose to build components. It allows the implementation of systems based on standardized components, whose interaction can be adjusted according to the context and current requirements. It builds on a meta-model called SmartMars  [55]  implemented as a UML profile, and was used as a basis for building an integrated Eclipse tool called SmartMDSD  [65].
The diagram in Figure  2  shows the hierarchy of the different concepts identified. This hierarchy can be described as follows. A robotic system consists of a robot, the environment in which it operates, and the software that controls it. A robot has a central part which we call the "body of the robot" and a set of hardware components. The software allows the robot to evolve in its environment (set of physical and logical resources). The hardware components can be either sensors, actuators, or any other device for communicating and evolving (observation, perception, and reaction) in its environment. The software consists of a set of decision-making components (layer, activity, database, knowledge, etc. ) and behavioral components (action, function, module, modifier, goal, etc. ). There are two types (small empty triangle in the figure) of ports: input ports and output ports.
In some architectures, such as subsumption, the port data can be modified by those of another. Thus, an input port can carry multiple suppressors and an output port several inhibitors. The multiplicity  [1. *] on the relationship between the elements Software and Software Component for example, means that a software is composed (small black diamond) of one or more software components. After this presentation of the main concepts used in robotics software architectures, the next subsection deals with the use of these concepts to define an abstract syntax for the Domain Specific Modeling Language RsaML.
Abstract Syntax of RsaML: The Proposed Meta-Model The abstract syntax of RsaML is defined through a meta-model, which shows the way in which the concepts identified in robotic software architectures are put in relationships to define an architecture. This meta-model was built using Ecore meta-meta-model. It is shown in Figure  3. The diagram in Figure  3  can be described as follows: a robotic control software can be composed of a database containing a set of knowledge and several layers, and must have one or more goals to achieve. The goal can be broken down into sub goals reached by performing a set of activities. These activities follow a given strategy. The activities are carried out by execution of processes that are implemented in modules. The modules that are on the layers may have several functions that implement processing.
Defining OCL Constraints to Check Semantic Rules In order to integrate the semantic rules of RsaML in the meta-model (abstract syntax) of RsaML, these rules are translated into OCL constraints. These last serve as rules of good formation of models. Some of the OCL constraints are presented in Listing 1. Each time, the constraint in natural language is given in the form of a comment, followed by the OCL code (context and invariant) corresponding to its definition. Listing 1. Some OCL constraints imposed on the domain's meta-model. --1. Each system has a name and at least one layer context Software inv : name<>'''' and layer->size()>0 --2. The number of a layer is always less than the number of layers of the system, we assume that the first layer is always 0 context Layer inv : number<Software.
Implementation: Meta-Modeling in Eclipse This subsection deals with the implementation of the abstract syntax of the RsaML language (its meta-model) and the integration of its semantic rules (as OCL constraints) in the meta-model, in order to verify their good working. The Framework EMF and the OCL project of Eclipse were, respectively, used for the implementation of the meta-model and the integration of OCL constraints in the meta-model. Once the meta-model is built, it was checked to verify that all the syntactic rules of construction were satisfied (for example, to ensure that the type of each attribute was specified). The next step was, therefore, the integration of OCL constraints in the metamodel under Eclipse. Before integrating the OCL constraints to the meta-model, each of them was first checked to ensure that it was syntactically correct, and provided the expected result.
For this, the interactive console of the Eclipse OCL project was used. Figure  4  shows an example of verification with the result in the red rectangle. The result is False in this case, because two modules (m12,m12) have the same name. In Figure  4 , we have three blocks: The first contains the RsaML meta-model, which is presented in Figure  3 ; the second contains an instance of the meta-model, which represents an architecture in which two modules have the same name (m12 highlighted in yellow); the third is the interactive console that allows us to evaluate the constraints before their insertion in the meta-model. It presents a constraint and the result (red rectangle) that it produces when it is applied to the example model of block 2. To add OCL constraints in the meta-model, its textual version is edited and constraints' invariants are added, as shown in the red boxes in Figure  5.
Definition of a Concrete Syntax: The Tree Editor of RsaML The concrete syntax defines the interface and the notations that will be used by the users to represent the different concepts of the language, and thus to build their models (architectures). This syntax can take many forms. For this first version of RsaML, we propose a tree editor, which will be enriched later to evolve towards a graphic editor. Eclipse EMF offers the possibility of producing the tree editor from the abstract syntax (meta-model) of a language. This requires associating an editor generator with the metamodel. An EMF project was therefore created, and the meta-model was integrated in this project by importing the RsaML Ecore file. This led to the creation of a. genmodel file that is the template generator. Subsequently, the.
genmodel project was used to generate code for a set of projects, including an. emf. editor project. The execution of the latter produced the RsaML tree editor presented in Figure  6. 1. An explorer of already created models. These models have a language-specific extension (. rsaml); 2. The space reserved for the construction of the models; 3. A menu allowing, among other things, to validate the model being built. With this editor, RsaML models can now be built, just by choosing the type of model in the proposed list, as shown in the diagram of Figure  7. After this presentation of the RsaML language, the next section deals with its validation through experimentions.
• A functional layer containing two modules that offer services via queries to start/stop/ parameterize them, and making it possible to manage physical and logical resources (sensors and others). These modules have functions containing the actions that are necessary for the control of these resources. Figure  8  shows the block diagram of the architecture of this system. The tree editor of RsaML presented in Section 3. 7 has been used to build the architecture of the robotic system presented in the previous subsection. The diagram in Figure  9  shows the constructed model. For a better understanding, Table  3  gives the correspondence between some elements of the robotic software architecture presented in Figure  8  and the corresponding RsaML concepts. This first experimentation shows that the syntax of the RsaML language is operational.
The type of data that the e0_prodExec input port can receive is "alphanumeric" (link 2a), but it is connected to the output port (its Outputport property) s0_ressourceCheck, which sends it data of type "numeric" (link 2b); 3. The proceduralExec module deletes the entry e0_m01 (link 3a) of module m01, which is at the functional layer (link 3b) at level n-2, whereas the decisional layer is at level n; 4. The execution duration of the resourceChecker module is 2. 5 (link 4b), while the maximum time of execution of the layer where it is located is 2. 0 (link 4a); 5. The function f0_m01 is real-time (link 5a), but it contains an action which is not real-time (action a0_f0_m01). This experimentation shows that the integration of OCL constraints in the language works fine, that these constraints are well and truly verified when the language is used, and therefore that the static semantics of RsaML is potentially well defined.
The objective of this last experiment is to verify that the language RsaML can be used to model robotic systems whose architecture belongs to none of the classical categories of architectures. For this, we consider a robotic system taken from the literature and describe its software architecture with RsaML. The robotic system considered is described in  [54]. It is a system with a real-time executive that is represented by a single processor. The latter is connected to the sensors and actuators via two acquisition cards. Figure  12  shows the structure of the robotic system. To build the software architecture of this system using the RsaML language, we proceed as follows: The sensors and actuators (visible in the diagram of Figure  12 ) can be represented by the concepts of sensors and actuators defined in the language, an action (the parallelogram with the expression Ci = 1 ms, for example) by the concept of action, a task (the parallelogram named Mvt Ctrl, for example) by the concept of function, the execution system on which the real-time controller will be executed by the concept of processor, other software components (acquisition of sensor data, processing of these data, etc.
) by the concept of module, the connections between the components by links between their respective ports, and the memory by a database and the whole system by the concept of Software. Thus, the architecture of this system is structured in a layer having two modules: • A task interpreter: it has a function to provide this service; • A motion controller: it has a function containing six actions named Instructions. These actions are periodic, and each has a period of 20 ms and an execution time of 1 ms. We built this architecture using the RsaML tree editor. The obtained model is shown in Figure  13. After these experimentations of RsaML, the next section discusses its advantages and limits.
The proposition made by  [56]  is specific to the subsumption architecture. The study conducted by  [53]  concerns the specific case of the Aibo system, and the proposed metamodel is therefore restricted to this system. Likewise, the proposal made by  [54]  focuses on the development of the system for the control of a given prototype. Almost all of these works do not take into account the real-time aspects of robotic systems. Unlike the previous solutions, RsaML provides a solution taking into account all categories of robotic software architectures and all types of robotic systems. It makes it possible to take into account functional and non-functional properties of robotic systems that cannot be included graphically in the meta-model. RsaML also offers the ability to include and verify real-time properties for robotic systems that have time constraints.
As mentioned in Section 2. 2, SmartSoft  [63]  brings a significant advance in the definition of DSML for robotics. We can recall, among other things, the interoperability provided by the possibility of generating code to CORBA and ACE (Adaptive Communication Environment). However, SmartSoft's meta-model does not distinguish hardware components from software components of robotic systems. This has the consequence of reducing the level of abstraction and therefore the possibility of abstracting the material that must support the developed system. RsaML provides the ability to model software architectures independently of the underlying hardware by decoupling the hardware and software components of a system. The components of smartSoft are kinds of "black boxes" offered to manage the robot. Consequently, the possibilities to specify/modify the desired behaviors of these components are almost nil.
Furthermore, the tasks do not explicitly describe the actions that carry them out. RsaML takes this level of granularity into account by making it possible to specify at the level of the architectural model, the components, and the tasks that constitute them as well as the actions of the latter. This way of doing things promotes the modularity of the architectures defined, increases the maintainability of the systems built, and facilitates the reusability of the components of the latter. The SmartMars meta-model on which SmartSoft is built does not integrate semantic rules for the management of non-functional properties. The authors made new works  [69]  dedicated to the modeling of non-functional constraints for robotic software systems. RobotML  [64]  has also paved the way for the application of software engineering in the field of robotics.
However, unlike RsaML, RobotML does not allow checking the non-functional properties of built models. Moreover, although RobotML defines a property allowing to specify the type of a task in the constructed model (periodic, aperiodic, etc. ), it does not offer elements for the specification of the real-time properties of the systems, which are essential elements to specify, for example, the policy and parameters for scheduling tasks. Table  4  summarizes the comparison of RsaML with some of the proposed solutions, namely RobotML, GenoM3, SmartSoft, and BRIDE. The following criteria have been used for the comparison: As shown in Table  4 , unlike the other approaches, RsaML satisfies all the criteria defined above. The limit of the work presented in this paper is that it does not cover the whole software engineering process for the construction of robotic systems shown in Figure  1.
Conclusions and Future Work Robotic systems which are special cases of embedded real-time systems suffer from the lack of development methods and processes that could systematize and facilitate their development, such as those found in the development of classical software. One of the key and topical issues is the application of software engineering techniques to robotics. One area of software engineering that opens new opportunities is model-driven engineering (MDE) that makes it possible to define Domain Specific Modeling Languages (DSML). In this article, we have addressed the issue of formalization of the description of robotic software architectures. A DSML called RsaML has been proposed for the design of the latter. It takes into account the different categories of robotic software architectures, with the possibility to specify real-time properties when necessary.
In order to define this DSML, an analysis of the robotic domain was done and the different categories of software architectures were investigated. This analysis ended with the identification and description of concepts useful for the representation of these architectures. Useful attributes to take into account real-time properties were identified, defined, and integrated into the relevant concepts. A metamodel was proposed to describe robotic software architectures. This meta-model defines the abstract syntax of RsaML. The static semantics of the language were defined and integrated in the meta-model using OCL constraints. These OCL constraints make it possible to verify semantic rules specific to the field of robotics as well as real-time properties. The Eclipse EMF Framework was used to implement the RsaML language and experiments were performed to validate the proposed solution.
The comparison with related works shows that RsaML provides several advantages. Unlike solutions proposed in most of the related works, RsaML takes into account the different categories of architectures and the functional and non-functional properties of robotic software systems. By decoupling the representation of software components from that of hardware components, it is possible to define architectures independently of the underlying hardware. This offers the possibility of detailing the actions carrying out the behavior of a software component. This level of granularity increases the maintainability and reusability of the architectures built, and makes communication between experts of the robotic domain easier. RsaML also makes it possible to specify real-time properties of robotic systems, including policy and parameters for tasks' scheduling.