J.-F Tilman

R Sezestre

A Schyn

Simulation of system architectures with AADL

Keywords: AADL, simulation, embedded systems

AADL is a language dedicated to the modeling of system architectures. Among all the possible analyses, verifications and other usages of such models, this article considers the simulation of the behavior of these systems. After an overview of the context and the illustration of the interest of such a simulation, it presents the development of ADeS, a simulator which aims at representing the whole behavior information provided by the AADL standard. The different behavioral aspects to be considered are presented, followed by the main technical choices of the development of ADeS and the difficulties which appeared. The article ends with consideration on the current status and the perspectives of the tool for the AADL community.

Introduction

The current system engineering practices are more and more based on modeling approaches and the use of architecture description languages (ADL). This evolution is driven by the need for stronger methods to handle the increasing complexity of the embedded systems. The use of ADLs is coupled with techniques and tools to help in the development: automatic generation, performing verifications, etc. One of the main ADLs currently considered by industry in system engineering for embedded systems is AADL [START_REF] Sae | Architecture analysis & design language (AADL)[END_REF]. This language provides a means to model both the software and the execution platform architectures. In parallel with its standardization process, efforts have been spent to develop tooling support, based on various approaches. We will consider in this paper the simulation of the behavior of a system described with AADL. First, let us consider the interest of the simulation of AADL models, the context of this question, and some cases which illustrate its use in existing tools. Second, we will deeper consider how such a simulation is performed in ADeS, a tool which aims at supporting the whole behavioral aspects of AADL. Last, we will deal with the integration of such a tool in the AADL environment and the perspectives it offers for the future.

Context of the study

AADL overview

AADL is now better known by the embedded system community, and the purpose of this paper is not to deeply present it once again. However, few words to introduce its main concepts are useful to understand the specificity of a simulation based on this language. An AADL model is composed of a set of components. Each component belongs to a category (e.g., processor, thread, subprogram, system...) which has a precise semantics. It is described in two parts: the type represents its interface with outside, and the implementation represents its contents. These components are hierarchically composed and connected together to form a complex architecture. Such a description may be enriched by associating valued properties to detail many aspects of the description. For instance, a thread will receive a deadline property or a compute execution time property. AADL provides operational modes to represent various configurations of a same system, and transitions between these configurations. Depending on the current mode, components may be activated or deactivated, connections may change, properties may have different values, etc. Last, AADL supports an annex mechanism to extend the description capabilities of the language by introducing a dedicated sub-language. A behavior annex is currently defined by the standardization committee.

Verifying properties of a model

Once we have a means to produce a precise model of a system, we may want to verify properties of this model. Some of these properties can be checked by applying formal techniques. For instance, the schedulability of a set of tasks can be ensured, thanks to formulas provided by the scientist literature. Provided that information is available in a model, it is possible to implement these formulas in a tool [START_REF] Guettier | Static Mapping of Hard Real-Time Applications onto Multi-Processor Architectures using Constraint Logic Programming[END_REF]. Other verification techniques are based on model checking. Several teams use these approaches to verify various kinds of properties, and develop tools implementing their solutions. An example is Cheddar, which is designed for checking task temporal constraints and buffer sizes of real time applications and systems [START_REF] Singhoff | Scheduling and Memory requirement analysis with AADL[END_REF]. Ensuring the schedulability of a reduced set of periodic tasks by formal techniques may be reasonable. When the size and the complexity of the model grow, with many interactions between tasks, or dynamic changes of the configuration, the problem becomes more difficult, sometimes impossible. In such a case, in absence of proofs, we may want to see what happens in the system by simulating its behavior. This is illustrated by Cheddar, which uses scheduling and buffer simulation when its feasibility tests can not be applied. BIP, developed by Verimag, or the Furness Toolset, proposed by Fremont Associates, also encompass simulation capabilities, even if they only consider subsets of AADL [START_REF] Verimag | BIP[END_REF][START_REF]Furness Toolset[END_REF].

Simulation from the AADL model

More generally, the designer of a system is interested by animating his model. This provides him an overview on how his system will behave when finished. This helps him, for instance, to better dimension the system, or to detect locks, missed deadlines and other problems -even if a simulation will never replace other verification techniques to ensure the absence of failures. Another approach to use simulation consists in computing the evolution of the system in batch mode and recording the results, and then analyzing these results during a second step. However, AADL is a priori designed to describe static system architectures. Thus it may seem strange to envision the simulation of such a model. In fact, compared with other modeling languages, and thanks to its precise semantics which includes the description of behavioral aspects, AADL makes possible such simulations, as we will see later.

Lack for a full support of the AADL behavior

Most of the AADL tools which use simulation techniques do it to help in the verification of particular properties. They generally not consider the whole AADL language. The restrictions may be due to an incomplete support of all the possible constructs of the language. In this case the tools only understand a subset of the language, or just ignore some possible constructs. Sometimes, the tools do not respect the exact standard behavior associated with the elements of the architecture, as specified by the AADL standard. Either they use a simpler model, or they use their own behavior model. In this context, there was no tool, at our knowledge, which was able to simulate the whole behavior of an AADL description with respect to what is specified by the standard. This is one of the main reasons of the development of ADeS, an AADL tool which aims at simulating the full behavior of an AADL system architecture.

Elaboration of the AADL standard

The development of the first prototype of ADeS started at Axlog Ingénierie, where the authors were all employed, in the context of a research project with the European Space Agency (ESA) to qualify the interest of the future AADL language for space domain. The motivation of this development was the assertion of the feasibility of tools supporting AADL, but also the need for feedbacks to the standardization committee where we were involved in the definition of the language. At this time, it was about the only AADL tool, and its development allowed the detection of many problems in the draft grammars of the language. The creation of OSATE, the open source AADL tool environment, by SEI has been the opportunity for a completely new version of the simulator [START_REF]OSATE[END_REF]. Since OSATE consists in a set of Eclipse plug-ins which may be reused to take advantage of their functions, ADeS became also an Eclipse plug-in, and gave up its own AADL parser to reuse the services provided by OSATE. More generally, the designer of a system is

Simulation of AADL in details

What has to be simulated

When considering the AADL description of a system, behavioral information comes from many locations. First, the standard of the language provides a precise description of each component category. For each of them, it explains the exact behavior. Some component categories are active, that is they represent an element of the architecture which executes something. The threads are the best example of such an active component. The specification of a thread behavior is complex by nature. Its complexity is reinforced by the fact that the AADL standards aims at not restraining too much the user, and make possible the description of all the common kinds of tasks which exist in the real time community. Thus, an AADL thread may be parameterized to match with the exact thread of the user. The global behavior of a thread is then the sum of many details which exist in actual real time threads. For instance it is possible to describe an initialization phase, an activation phase, or a recovery phase, even if this will not be used in some cases by the user. The passive AADL component categories can also introduce behavioral information which has to be taken into account by the simulation. For instance, a data component, which may represent a global variable in memory, can also be used to represent a shared data. In such a case, specific mechanisms are used to manage this sharing. When simulating the access to this variable by a thread, the simulation has to add the representation of these mechanisms. Another example: a bus, which is used to support communications, introduces some constraints on the transfer of data or events. When modes are used, they represent various runtime configurations of the system. For each of these configurations a specific behavior appears, as if we had several different systems. What has an impact on the simulation is the fact that these modes can change during the live of the system, and these changes appears during the simulation. When such a mode change happens, the simulation has to take into account all the consequences: a subcomponent may be removed, another one will appear, some connections are redefined, the values associated with properties change, threads are halted or restarted, etc. Some rules exist in the AADL standard to precisely specify when and how these mode changes happen. The pure AADL specification may be completed by the use of standard annexes. The error model annex gives details on the handling of errors, the arrival laws of errors, etc. This should be taken into account, since it has an influence on the result of the simulation. The behavior annex is, of course, the major complement to refine the behavior description of a system. With this annex it is possible to explain how a subprogram, called by a thread, will work, raise events, etc. Supporting this annex in the simulation brings many capabilities to analyze the behavior of the modeled system. The last source of information about the behavior is what the user may introduce by himself. Indeed, he can create his own new properties or annexes to represent what he wants. However, if he does so, he also has to develop the support to understand the semantics of his extensions. A simulator may provide extension points to make possible the development of plug-ins to support such user defined complements.

Simulation management

Several solutions exist to manage the execution of a simulation, and the choice of the appropriate simulation engine depends on the purpose of the simulation. An integration engine is adapted to simulations which contain only continuous variables. A step-by-step engine is adapted to simulations with no continuous variables, and where the events are implicit. In this case the engine tests at each periodic step the status of the events to detect when they are raised. An event-driven engine is adapted to simulations with no continuous variables, and where the events are explicit. Here, it is possible to directly jump from the execution of one event to the execution of the following, which is more efficient. Combined engines may also exist, to combine continuous and discrete variables, as well described in [START_REF] Sautereau | ESCADRE V5 / Simulation, Manuel du concepteur[END_REF]. The simulation of an AADL architecture is clearly largely discrete: the elements have states, their properties change instantaneously, etc. All the events are explicit. Then, the simulation engine technique used for ADeS is naturally the eventdriven approach. An AADL system will usually contain periodic tasks which will be regularly dispatched, but also aperiodic events which may happen at any time. Thus, the amount of things to be simulated may vary in the time, with long empty durations and other heavy periods. Thanks to the event-driven approach, the performances of the simulation are improved: when nothing happens, the simulated time is immediately advanced up to the next event.

Concretely, the kernel of the tool works as a scheduler for the simulation events. Each event has a date when it has to be executed, and is added into an ordered list. When two events have the same date, they can have different priority levels to order them. The execution of an event generally produces new events which will be executed later. For instance, when the task scheduler decides a switch between tasks, some events are raised to preempt the first task and start the second. However, we identify two drawbacks of this solution. First, the simulated time may advance at an irregular speed, depending on the activity of the system. If we want to present a "real time" simulation to the user, we have to synchronize this simulated time with the actual time. This is easily feasible by adding specific periodic synchronization events. The second drawback might appear if we imagine, in the future, an extension of the simulator to take into account the environment in which the studied system evolves. In such a case, continuous variables may be useful. Solutions exist, either by extending the simulation engine, or by accepting compromises in the representation of these continuous variables in the simulation.

Layered structure

Simulating the complex behavior of a full system involves several aspects. Some of them are generic, other ones dependent on the AADL specificities. To cope with this reality, the simulation tool has also to be organized into layers. A first set of layers, called "jimex" is in charge of the pure simulation aspects. It is organized as follow:

• The jimex core component implements the lowest level of the simulator, the simulation engine. It defines simulation events and manages them. It is completely independent from any specific purpose of the final simulation. At this level the simulation events are just characterized by the date when they have to be raised and their priority; • The jimex base component provides higher level simulation elements, and particularly more specialized events, as required by the simulation of elements of an embedded system; • The jimex aadl component introduces all the AADL specific semantics, as defined by the AADL standard. However, it is still independent from OSATE, and might be used to support an AADL simulation related to another modeling tool. The other layers play a role in the management of the simulation:

• The ades instantiation component implements the mechanisms to build the simulation elements from the AADL elements as described in OSATE; • The ades trace component is in charge of recording all what happens during the simulation and providing this information to the upper levels in charge of the man-machine interface; • The ades simulator component implements the man-machine interface which control the simulation and displays the results.

Exploitation of the results

Several ways exist to exploit the results of a simulation: observation during the computation, compilations and analyses of the resulting data, production of reports, etc. Most of them are based on the systematic record of all what is computed by the simulator, in order to keep a trace afterward. Such a trace mechanism is integrated into ADeS. Each element of the AADL architecture records what happens for it: emission of an event, change of a property value, transmission of a data onto a bus... All this information is stored into an XML file. The choice of this format has been done to make easier post-analyses by anybody. When coupling the trace coming from a run of the simulation with information on the structure of the simulated architecture itself, it becomes possible to rebuild the exact state of a simulation at a given date in the past. Such a snapshot of a simulation makes possible the replay of a simulation, either to refine the analysis of an interesting point, or to change parameters and compare two different runs without playing twice what is similar before the divergence. ADeS is able to store these snapshots and reload them to propose this capability. This mechanism is also used at the beginning of the simulation. Indeed, the creation of a simulation, before its first run, consists in the creation of such a snapshot at t=0 and its loading. During the execution of a simulation, the user may observe the status of all the properties of the elements composing the architecture. However, this information is presented as a table. Effort is still needed to improve the graphical rendering of the results, for instance by proposing chronograms and other high-level widgets to give a complete and intuitive view of the results. Figure 1 shows the main window of the tool, with several views to control the current values of the parameters, the events of the simulation, the trace of the results. When considering all the aspects composing the behavior of an AADL architecture, we have to deal with a high complexity. This complexity comes not only from the fact that many details have their own rules that have to be taken into account, but also from the impact they may have onto the global behavior. As usual, passing from a local level to the global level introduces complexity. The best illustration of this difficulty is the impact of the modes onto the behavior. As explained before, many elements of the architecture may have modes, which control some parameters, enable or disable subcomponents, change connections, etc. Since such an element having modes may be integrated as another subcomponent with its own modes, and so on up to the top of the hierarchy, we have to consider the system operation modes (SOM), which are the combination of all the modes of all the components. The set of possible SOMs is then the cross product of the sets of modes for each component. We have here a possible combinatorial explosion. The complexity of the simulated behavior must not be an obstacle to the openness of the simulator. Since AADL supports the introduction of userdefined extensions, represented by annexes, an AADL simulator has also to support such possible extensions. Fortunately, the modular approach adopted to build ADeS helps in this support. The semantics of an extension defined by a user will only be known by this user; thus, ADeS may offer extension points and mechanisms to connect plugins, but in any cases, the development of these plugins is of the responsibility of the user.

ADeS and the AADL environment

Integration with other AADL tools

As mentioned before, OSATE is an AADL tool which provides a textual modeler, a parser, and all what is needed by any tool to handle the data structure representing the AADL architecture. It is designed as a set of Eclipse plug-ins, and many other tools have been developed on top of it to bring their own features: analyses, verifications, etc. OSATE is now integrated into the Topcased environment, also based on Eclipse, and which provides graphical modelers. We assist at the emergence of a complete tool environment around AADL. In this context, the developer of a new AADL tool has to wonder whether it is expedient for him to integrate his tool into this environment. This integration has been done for ADeS. The first benefit is the reuse of the AADL parser and the underlying data model, which is shared with other tools. The second benefit is the capability for the user to have all its tools at the same place. He uses textual and/or graphical modelers, verifies the completeness and consistency of his model, perform various analyses, statistics and validations, and run his simulation without any translation of his models.

Project management

As a consequence of this integration, the management of simulation projects has to be done in the sense of Eclipse projects, and also in a compatible way with the projects of the other AADL tools. In ADeS, a simulation project is created in relation with a preexisting AADL project, provided by OSATE and used to model the target architecture. The simulation project may contain one or more simulations of the same system, characterized by different scenarios. Once a simulation is created, it may be executed, and at any moment a capture of its state may be done to be replayed later. This capture, also called snapshot, constitutes a new simulation in the project. A synchronization mechanism is able to detect changes in the AADL project and take them into account in the simulation project. Generally, modifications of the model make the existing simulations obsolete.

License and availability

Another consequence of the integration of ADeS into the OSATE/Topcased tool family is the need for a free open-source license. The chosen license is the Eclipse public license (EPL). Now, the ADeS source repository is hosted by Topcased and is available for downloads and contributions 1 .

Results and perspectives

ADeS has not yet been extensively used on large models. Feedbacks are still missing to get a correct overview of its results. However, experimentations on smaller models show interesting capabilities, even if the analysis of the results may be a bit painful due to the lack of high level graphical displays. Spices, a European R&D project dedicated to predictable system engineering based on AADL, provides us the opportunity to continue the development of ADeS and trial it further. The official behavior annex is currently standardized by the AADL committee. Since it was not stable enough during the development of ADeS, another minimal behavior annex has been implemented. This shown the capability to plug extensions to support user-specific annexes. However, we may expect to shortly support the future standardized behavior annex. Another standard annex exists, the error model annex. Its support is also missing for the moment. The Topcased project, which now encompasses OSATE, also deals with other modeling languages. It needs a generic simulation support, able to cover multi model formalisms. In the future, ADeS could be adapted to such a larger purpose, or its technology may be reused in with this new objective. Another important and positive result of ADeS is for the AADL standardization committee. Indeed, the development of this tool has been -and is still -the opportunity to experiment evolutions of AADL in parallel with the works of the committee and bring feedbacks on the lacks, inconsistencies and other problems in the draft versions of the standard.

Conclusion

This article has shown the interest for a simulation based on AADL models, and how this architecture description language provides a complex behavioral information, thanks to its semantics and the mechanisms it proposes. This approach is already used by several tools for verification purposes. ADeS has been designed to support all the details of this behavior, to provide an animation of the models as precise as possible. Its development, still in 1 http://gforge.enseeiht.fr/projects/ades/ progress, has accompanied the definition of the AADL standard and provided a strong feedback for this standardization. The integration of ADeS into the AADL tool suite and its open-source license may open new perspectives for its usage and development.

Acknowledgment

The works presented in this paper have been partially conducted during projects with ESA and other European project. The authors acknowledge the cooperation of some partners of these projects, and of the members of the AADL standardization committee.

Figure 1 :

 1 Figure 1: Snapshot of the ADeS main window 3.5 Complexity and openness


G Veran

G Garcia

A Component Driven Development Process From The System Design To The Final Implementation

Keywords: Component, Model, Transformation, Simulink

This paper describes a "seamless" component driven engineering process for control law or mode management software whose algorithms are designed in Simulink/Stateflow. An interface mechanism between this tool and a realtime target allows gathering the components modelling and the components implementation in a unique process flexible and adaptable. The component architecture is preserved during all the development and the closed-loop between the avionics components and the environment is never broken, enabling the developper to perform representative simulation form the first system model until the final implementation.

Introduction

Component driven engineering has been introduced to help managing the increasing complexity of information systems. A component is a block that implements a basic functionality. It is described by its interface, i.e. the services it provides and the services it uses. Recently, the component-based development process has been introduced for real time embedded systems. Real time software often implements complex control laws or mode management algorithms such as AOCS (Attitude and Orbit Control System) for spatial aircraft. Generally these algorithms are developed in two phases. First they are designed with modelling tools like Simulink/Stateflow. Once validated in these tools, the algorithms are coded manually or by automatic code generators and then validated on real hardware. This two-phase process creates a strict separation between the algorithms design and the software implementation. This paper presents a mechanism for interfacing the design tool (Simulink) with real software running on the target. It makes it possible to incrementally implement the component models without breaking the component architecture. By doing so, it improves the development process and enables a fast prototyping on the hardware target. This paper is organized as follows: In section 2, we present the process. In section 3, we introduce the Simulink/OBSW (On-Board Software) interface mechanism. In section 4, we present a full use case and the main experimentation results. Finally, in section 5, we summarize the contribution of this paper and point out the future directions of this work.

The Component Modelling Process

The modular architecture

The modular architecture used [START_REF] Moreno | Plug & Play architecture for on-board software components[END_REF] was designed to improve the reuse of software components and the dynamic modification of on-board software. It is based on a library called framework that contains the basic common functionalities (TC management, TM management, software bus services…). The services offered by this library enable the developer to easily integrate software components into a software bus. This mock-up is based as much as possible on free standard or open technologies (UDP, XML, Python, RPC…). The mock-up is running on a Linux PC host with either a processor simulator or a real target (FPGA or ASIC board)

Overview of the process

During the first phase of a project, a mission analysis is performed to define the first architecture of the avionic. The components are selected and preliminary versions of the control algorithms are modelled in Simulink. Simulink models are naturally organized in sub models, which can be interpreted as components. Generally, a Simulink model contains:

• Sensor component models

• Actuator component models

• OBSW component models which implement the control or mode management algorithms • The environment model which describes the physical laws that govern the target Closed-loop simulation is performed between the environment and the avionic architecture (sensors, actuators and OBSW models).

The incremental model transformation process proposed enables the transfer of the components one by one from the Simulink model to the software architecture. If a component model comes to maturity before the other it can be implemented in software and plugged into the modular avionic architecture while the others components remains in Simulink.

During these transformations, the closed-loop constituted by the components and the environment is never broken. As a consequence, the components code can be easily tested with representative values during all the development steps.

At the end of the process, all the components are implemented in software and only the environment model remains in Simulink. The software architecture can still being simulated, Simulink computing the input data of the OBSW and the OBSW computing the input data of Simulink.

An example of incremental transfer is described in figure 1. The component interfaces (figure 2) are described using the Interface Description Language (IDL [2]). An IDL file is written for each component, describing A set of specific IDL compilers (figure 3) is used to generate automatically the OBSW interfaces and the OBSW skeletons in order to ease the component integration into the generic mock-up. The IDL files are also processed to produce XML files used by the ground software database to encode/decode the TC/TM send or received by the ground operators. From the Java object, it is easy to send the data through a TCP/IP network to the target. Although a direct connection with the target is possible (if the target provides a TCP or UDP link) we choose to reuse an intermediary XML-RPC [START_REF]Simple cross-platform distributed computing[END_REF] server written in Python, which already handle all the communication (TC/TM) between the board and the ground in our architecture. This enables us to have a unified communication mechanism between the target and the ground. We use Java XML-RPC libraries to connect to the XML-RPC server from the Java and for each component we add to the server a specific class to handle the communication of the component. Our software architecture comes with a framework providing functions to send XML-RPC message through an UDP link. The last step of the Simulink/OBSW interface uses these functions to transfer the data between XML-RPC Server and the OBSW running on the target. Finally, the global interface mechanism architecture is the following: Once in Simulink the data can obviously be oversampled (by using a transition rate block).

Figure 6: OBSW/Simulink synchronization

Real-time representativeness

To preserve the real-time representativeness of the simulation the whole OBSW is frozen when a call to a getValues is blocked. As a consequence the task scheduling and the relative task execution time are preserved but all the data acquisitions take no time from the OBSW point of view. Simulink/OBSW interface mechanism provides a good temporal representation for systems, which use a data acquisition server running in a dedicated task. The interface mechanism creates also a big overhead mainly due to network latencies and Simulink computation time. On representative example our simulation is three times slower than the real time.

Automatic generation of the Simulink/OBSW Interface

The Simulink/OBSW interface mechanism (Simulink blocks, the Java and Python classes and the OBSW part) is only dependant of the types, the names, and the frequencies of the data exchanged between Simulink and the OBSW. As a consequence it can be automatically generated to speed-up and simplify the interfacing process. This process is mainly automatic. It does not require a lot of manual intervention and as a consequence is very fast.

Software distribution

The global architecture can be distributed on three machines:

• A Matlab station where the model part of the architecture runs

• A host machine where the ground/board server runs. This machine is linked with the real hardware target where the generic avionic and the software components run. • A Ground Station where an HMI displays the measures (TM) received from the board and also enables the user to send commands (TC)

The various machines are connected through a classical network link.

Utilization Example

The ESA ExoMars mission aims at sending a rover on mars. The process described in this paper has been used in the preliminary studies of this project.

In case of a crash of the nominal processor module during the boost phase of the ExoMars orbit insertion, the Main Engine (ME) shall be stopped at most 10 seconds. Once the ME is operational, the satellite attitude must converge again. The processor module warm redundancy concept has been developed to guarantee at any conditions a quick restart of the OBSW on the redundant processor module, to be able to resume the attitude control and the boost. Simulink/OBSW interface has been used to set-up a Fail-Op demonstration with the following goals:

• Refining and verifying the warm redundancy concept specifications, in both HW and SW fields. • Demonstration that the timing constraints are met (boost resumed before 10 seconds).

• Demonstration of the potential re-use of the AOCS source code in the frame of the ExoMars development

The architecture presented in the previous chapters has been tailored for the purpose of this demonstration:

• Use of two LEON processor boards.

• The crash of the Nominal processor module during ME firing has been achieved in the demonstration by disconnecting the board power. After the failure, the redundant processor module shall be woken up and restore the previously saved context to resume the ME firing as soon as possible.

When the nominal processor module is switched off, Simulink model is blocked because there are no available actuators data. When the redundant makes the first sensor acquisition, the nominal processor module is put in stand-by mode and some forced AOCS cycles are executed to compute the dynamics of the carrier during the crash. The demonstration has provided the expected results:

• The second processor module was reconfigured and it had taken back the control of actuators in less than 5000 ms. • The mission was not lost even if one of ΔV (targeted or accumulated) data was corrupted. • Additional measures were provided (Maximum attitude error, time to stabilize the carrier attitude) Figure 9 shown an example of result provided by the demonstration:

Figure 9: Simulation Results

Improvement of the design process

The principle presented improve the development process on the following points:

• Incremental transformation:

The possibility to incrementally implement the component in software makes it possible to parallelize the component development. A software component can be developed and tested alone without breaking this architecture.

• Early and representative tests:

Simulink/OBSW interface mechanism enables the developers to perform closed-loop simulation during all the development steps. As a consequence the components implemented in software can be tested and validated earlier on the target and with representative input values. It is not necessary to wait the development of complex hardware test bench to begin to test the component implementation.

• Early validation of the component architecture:

The overall component architecture can be validated on the real target. Performance and metric measures can be obtained earlier in the software development cycle.

• Proof of reusability: Impact of Main Engine restart after reconfiguration The Simulink/OBSW interface is a mean of proving the reusability of a component already implemented in software. This component can be quickly integrated in the architecture of the new project and it is possible to prove that the component fits in the architecture and meets the new requirements.

Conclusion

As shown by the description of the ExoMars use case, Simulink/OBSW interface can really improve the development process of component-based architecture.

By enabling parallelization of the component development, fast-prototyping of the architecture and earlier and more representative tests it simplifies the software development planning. It is also a good way to quickly prove the reusability of existing component implementation.

Reconfiguration

Even if the mechanism described here use an intermediary server, it is possible to directly connect Simulink to the target board if this one provides an UDP or TCP link. So, the mechanism is not dependent of a particular kind of operating system or API and can be used on most of the embedded target.

Although with positive impact, this process does not enable to simulate every phenomenon due to its poor real-time representativeness. For that, the future work will try to increase the real-time representativeness by lowering the network communication latency.

Acknowledgement

I would like to acknowledge J. Villa (TAS-F) for its cooperation on the ExoMars demonstration development.

Figure 1 :

 1 Figure 1: An example of incremental transfer

Figure 2 :

 2 Figure 2: Model Interface Specification

Figure 3 :

 3 Figure 3: Specific IDL Compilers

Figure 4 :

 4 Figure 4: Simulink/OBSW Interface Simulink Blocks

Figure 5 :

 5 Figure 5: Overview of the interface mechanism

  A dedicated IDL compiler has been developed and integrated in the already existing set of IDL compilers. For each component, this tool generate four files: • A Simulink model for the incoming signals (.mdl) • A Simulink model for the outgoing signals (.mdl) • A Java Class which received the signals from Simulink and transferred them to the Python server (.java) • A Python class which enables the XML-RPC server to handle the component communication (*.py) • A C file which implements the functions to get and set signals values from the OBSW (*.c) 3.5 Automatic generation of the component code The Simulink/OBSW interface mechanism can be associated an automatic code generator (ACG) to produce a fully automatic implementation process. The code of the component models are generated with the ACG and integrated into the modular software architecture with the code generated by the IDL compiler. This process is a mean of quickly prototyping a component on a representative hardware environment. If the automatic code generator used authorizes to define the prototype of the functions used to get and set the input and output signals, no extra manual code is needed to interface the generated OBSW code with the interface mechanism. The global process is the following: • Generation of the component skeleton (from IDL) • Generation of the component code (from Simulink model) • Integration of the component code in the generated skeleton • Generation of the interface mechanism • Exchange of the Simulink block by the interface blocks generated • Dispatch of the interface code (Java class in Matlab path, add of the Python class in the XML-RPC server and add of OBSW interface code in the project compilation file) • Compilation of the binary

Figure

  Figure 7: Software distribution

Figure 8 :

 8 Figure 8: Simulink model of the ExoMars demonstration

Glossary


M Prochazka

S Fowell

L Planche

DisCo Space-Oriented Middleware: Architecture of a Distributed Runtime Environment for Complex Spacecraft On-board Applications

Keywords: Spacecraft on-board software, middleware, temporal and spatial partitioning, Integrated Modular Avionics

The DisCo project funded by the European Space Agency addresses future space missions with complex payload data handling applications. The key features are hard real-time constraints for applications running in embedded environment of a medium to large size space mission, partitioning between applications having different levels or criticality, and distributed computing. This paper presents an overview of the DisCo Space-Oriented Middleware (SOM) which provides support for DisCo applications running in distributed environment and having stringent requirements for predictability, fault detection and handling. The paper identifies key motivations for building DisCo SOM, provides a brief overview of the SOM architecture, compares it with other solutions and makes suggestions for future work.

Introduction

Motivation

Current spacecraft on-board systems become increasingly complex, providing more functionality such as coordination, cooperation, interoperability, autonomy, and improved fault tolerance. The costs to develop radiation-tolerant hardware components remain high so simply developing faster CPUs does not address the requirement for more functionality. Instead distributed and decentralised architectures are being addressed, based around high-speed networks such as SpaceWire. While at the same time, there are cost saving pressures -optimisation of mission efficiency, use of system resources, software development process. Standard solutions exist for efficient use of system resources and the required improved functionality. But these are sporadically deployed on different missions with little direct re-use between them. By defining standard software architectures with common building blocks that can be reused between missions, e.g. COTS or third-party software, the software development process can be reduced while improving the functionality of the system. The key objective of DisCo was to provide a reuseable software infrastructure to address the increasing complexity of spacecraft on-board systems through the following key principles:

• Applications are distributed on a set of processing modules. They are developed independently but integrated onto the same distributed platform. Through the SpaceWire network the software running on any processing module can access any memory, telemetry, I/O or payload specific module.

• Predictability in both time and space domain is assessed as late as when applications are integrated.

• Detection of software and hardware failures and triggering of associated predefined recovery actions.

• Automatic fault recovery with low/high availability applications involving reconfigurations on multiple processing modules (PMs).

• Tailoring and runtime configuration allowing system budgets optimisation.

• High level of flexibility provided to the system integrator. These objectives were met through the development of a Space-Oriented Middleware (SOM).

Processing Module

Payload Central Data Handling Unit

Use Case Applications

The SOM has been primarily developed for complex payload applications requiring distributed processing. Within the domain of the spacecraft control and data systems, the payload part is the one exhibiting the highest complexity and variability, usually solved through ad-hoc solutions that shall be redeveloped for each new mission. Besides, a general trend is towards augmentation of this complexity, including improvements in terms of coordination or even cooperation, while the space domain constraints limit the volume of hardware and software that can be embedded. SOM targets include multi-payload systems like the ones implemented for science exploration missions as well as individual payload systems with single or multiple CPU where:

• Multiple applications sharing a single CPU are guaranteed not to exceed their execution time, memory and communication budgets.

• Distribution is completely transparent and hence applications are developed the same way no matter whether they run on the same processor or a different one.

• Location of system units (processing modules, instrument front ends or mass memory units) is fully transparent which allows applications to be developed the same way, not taking account whether they run on the same processor or a different one.

• Different levels of availability at application software level are allowed and simultaneously supported.

Middleware Survey

Before doing any decisions with respect to the SOM architecture and design, we wanted to gather information about existing technologies, standards and studies which could be used, adapted, or implemented from scratch ("adopt, adapt, innovate").

In the Middleware Technology Survey we have first of all provided a definition of middleware used throughout the study: a software layer that stands between the underlying operating system and applications and primarily facilitates the distribution of applications and services. Next, we have identified various groups of relevant technologies to look at: In the next step we have considered the requirements specification and architectural decision to come with the following proposal as to which technologies would be used:

SOM Architecture

This section provides an overview of the SOM architecture.

Services

The SOM provides a set of functional services as well as a set of non-functional services (Figure 2). Functional services are used directly by the applications (i.e. they provide a functional interface used by applications). On the other hand, nonfunctional services are used only indirectly, i.e. by the SOM itself, so that they transparently contribute to functionality provided by functional services, or they change non-functional properties or quality-ofservice parameters (i.e. they are used or configured through management interfaces). The functional services are as follows:

Remote Invocation Service (RIS): This is a key service which allows application modules to perform remote invocation of functions provided by another module (either in the same or within another application). RIS provides distribution transparency, hence application modules are written the same way, not having to take into account where other applications are deployed. RIS is based on Minimum CORBA and Real-Time CORBA [START_REF]The Common Object Request Broker Specification[END_REF][START_REF]The Object Management Group[END_REF][START_REF]Real-Time CORBA Specification (static scheduling)[END_REF].

Event Service (EVS): This service provides support for producer/consumer data exchange ("publishsubscribe") and it is based on the CORBA Lightweight Event Service [START_REF]Lightweight Services Specification[END_REF]. EVS is designed to use different types of event dispatchers for different event channels, depending on application requirements (efficiency vs. predictability). The implementation uses the CORBA Asynchronous Method Invocation (AMI) which is supported by the RIS and which makes it possible to call a method in an asynchronous fashion without modifying the servant interface or implementation. This gives EVS the ability to deliver an event asynchronously to multiple consumers without having to use extra dispatcher threads and thus adding unnecessary overhead. Mass Memory Service (MMS): Access to persistent virtual mass storage is one of the key features required by on-board applications. MMS provides a file-oriented API and location, distribution and communication transparency. MMS was reused from the MAGUS Mass Memory Study [START_REF]Data Management Software for Mass Memory Based Payload Processors: Prototype Design[END_REF]. Device Access Service (DAS): This service allows applications to perform commanding and data acquisition to simple networked devices (e.g. simple payloads), in this case over SpaceWire though extensible to others. DAS is an implementation of the SOIS Device Access Service and Device Data Pooling Service [START_REF]CCSDS Spacecraft Onboard Interface Services -Device Access Service Red Book[END_REF][START_REF]CCSDS Spacecraft Onboard Interface Services -Device Data Pooling Service Red Book[END_REF]. It provides location and communication protocol transparency.

Configuration and Deployment Service (CDS):

CDS provides distributed management of application deployment, lifecycle, configuration, and upgrade across the processing modules as a result of mission phase changes and fault recovery. A simple application framework was designed which all applications implement in order to let the SOM control their lifecycle (start, activate, deactivate, stop, checkpoint). CDS also provides a software repository to which upgrades of existing applications as well as new applications could be uploaded, and which is used to load appropriate applications during a configuration update.

Information Flow Authorisation Service (IFAS):

The SOM must ensure that application integrity is preserved while operating on shared resources. IFAS provides an extensible framework for implementing algorithms for the authorisation of information flows between applications, devices and mass memory (in conjunction with RTOS). The authorisation criteria implemented by an algorithm can vary from a simple credentials-based authorisation to more complex rules for communication between different criticality levels as used in the GUARDS project [START_REF]A Generic Fault-Tolerant Architecture for Real-Time Dependable Systems[END_REF]. Communications Service (CMS): CMS is an implementation of a proposed SpaceWire mapping of the SOIS Subnetworking Layer's Packet Service [START_REF]CCSDS Spacecraft Onboard Interface Services -Subnetwork Packet Service[END_REF]. It provides resolution of abstract location to concrete network address and both best effort and assured SOIS classes of service. In addition it provides network integrity fault detection (i.e. monitoring of bandwidth usage against allocation).

Support for Partitioning

DisCo allows different applications, potentially with different criticality levels and potentially developed by different software vendors, to be executing on the same processing module. The SOM treats the applications as fault containment regions and provides means for partitioning between them:

• Spatial partitioning: Memory pooling techniques and FDIR policies to deal with illegal memory access were designed. However, due to RTEMS not using the LEON2 memory write protection mechanisms, spatial partitioning is not supported by the SOM implementation for the DisCo demonstrator.

• Temporal partitioning: RTEMS was extended with CPU-Time timers which allow the SOM to enforce CPU budgets of individual application tasks. An associated CPU Budget Overrun FDIR policy is implemented.

• Network partitioning: CMS allows to associate applications with communication budgets defined as amount of data (packets or bytes) allowed to be sent per a time window. An associated CMS Budget Overrun FDIR policy is implemented.

• Information flow checking: IFAS makes it possible to define a data filter which prevents faulty or unexpected data to be sent from one application to another.

End-to-End Schedulability Analysis

A DisCo system is composed of two parts: the SOM and applications. To perform schedulability analysis of DisCo, we have to take into account that the SOM only gives a framework to the software system, but schedulability will differ for different DisCo deployments containing particular applications. In order to make the DisCo system analysable, a computational model has been specified which defines abstract system entities representing computations, information exchanges between computations (communication), and their temporal and concurrency properties. To consider remote invocations, communication costs must be added to the worst case execution time computed. The delays for messages being sent between processors and the overheads due to communications must be bounded. In the holistic schedulability approach, communications schedulability is integrated with the processor schedulability so that execution time of operations which use communication includes overheads due to packet handling and communications protocol [START_REF] Tindell | Holistic Schedulability Analysis for Distributed Hard Real-Time Systems[END_REF]. As a necessary prerequisite, a timing analysis of the communications layer must be performed. In particular for DisCo, this means:

• Timing analysis of a single SpaceWire packet delivery. This includes considerations with respect to the network topology, overheads due to use of SpaceWire routers and packet processing by the SpaceWire drivers.

• Timing analysis of a CMS packet delivery. CMS adds overheads due to segmentation, buffer management and acknowledgment reply messages.

• Timing analysis of a RIS remote invocation. On top of SpaceWire and CMS, the RIS adds its own protocols used to perform remote method invocation. We use the notion of an end-to-end task to denote the system where a task may execute on several processors before it completes. An end-to-end task could be viewed as a chain of subtasks. Each subtask is then a continuous execution thread of the task running on a single processor. In other words, these subtasks represent tasks as treated in the single-processor schedulability analysis presented above. In DisCo we are interested in meeting all end-to-end deadlines of end-to-end tasks, that is, deadlines which take into account all subtasks in the end-to-end task chain.

Evaluation

DisCo provides software infrastructure for distributed data processing and control in spacecraft on-board applications (Figure 3). An early evaluation shows that the SOM addresses many issues of current complex spacecraft on-board applications dealing with multiple processing, memory, I/O and payload modules, and having stringent requirements for predictability, fault detection and handling.

Benefits of DisCo

The DisCo SOM is a complex middleware which combines both well know mature technologies applied in the space domain with emerging and state-of-the-art technologies:

• Several mature and standard technologies were adapted to space systems constraints (RIS, EVS, SCS).

• Several standards from the space domain were adopted and implemented (DAS, TAS, CMS).

• In addition, some technologies were newly developed (CDS, IFAS). The SOM provides a rich set of services which meet requirements of complex on-board applications and stringent hard real-time and dependability constraints. The SOM services are tailorable so that only required functions are deployed. DisCo applications are composed of smaller components which gives more flexibility in terms of configuration, deployment, CPU and memory load. They are focussed on the provision of their functionality not on how the functionality is invoked, nor on how fault-tolerance is achieved. Greater flexibility and component reuse also provides opportunities for on-board software suppliers to invest in validated products with costs covered across multiple deployments.

Space-Oriented IMA

Integrated Modular Avionics (IMA) is a concept of aircraft systems hosting multiple software modules certified to different criticality levels. The IMA features are layered architecture using standard programming interface layers to hide hardware and applications from one another, reconfiguration of applications (statically or in flight), protection mechanisms to allow resources like memory to be shared by multiple criticality level applications, and to allow applications to be inserted/altered without impact on the rest of the system (partitioning), flexible scheduling to meet deadlines of all the applications for each permitted configuration and when system is upgraded, code re-use and portability, physical integration of networks, modules and IO devices and design for growth and change. DisCo addresses most of these IMA features by:

• Systematic building of software applications composed of well-specified building blockssoftware modules. The SOM application framework is being extended in the COrDeT study funded by ESA [START_REF]Component-Oriented Development Techniques[END_REF]. The component framework facilitates software reuse, incremental design, static and dynamic reconfiguration.

• Integration of different communication protocols, networks and devices (CCSDS SOIS).

• Static and runtime mechanisms to enable secure sharing of resources amongst applications with different criticality levels (I/O, CPU, memory). IMA has been used in Airbus A380, Boeing 777 and 787 Dreamliner, as well as in several military aircrafts. The goals of IMA for spacecraft on-board software are similar to those in avionics systems:

• Weight and energy savings: Boeing reports that its 787 Dreamliner saves 2000 pounds of weight thanks to IMA. Airbus reports that A380 saves a half of the processing units thanks to IMA [START_REF] Ramsey | Integrated Modular Avionics: Less is More[END_REF].

• Savings in software engineering: Focus could be directed on application layer, instead of hardware, communication and systems integration.

• Software reuse and portability: Standardised integration of software components made by different vendors.

• Advanced features: IMA gives opportunity to new features such as flexible scheduling and support for static and dynamic reconfiguration. The DisCo/COrDeT approach is similar to the Automotive Open System Architecture (AUTOSAR), with the Virtual Functional Bus providing functionality similar to the SOM's RIS, standardised interaction between components, standardised component implementations and well-defined functional interfaces (provided, required) [START_REF]Automotive Open System Architecture (AUTOSAR)[END_REF].

DisCo has investigated a set of technologies capable of supporting the increasing complexity of the payload systems. A key challenge was to address the software engineering issue and particularly the verification and validation process (which is also central to the IMA approach).

Future Enhancements

In this section we analyse which way the SOM could be enhanced in the future.

Functionality

There are various functionality enhancements we are considering for the future: Application framework: One of the key enhancements is to improve the SOM application framework. The control of the software module lifecycle through the use of module-specific interfaces could be refined through the adoption of a component framework. This also allows for the definition and binding of provided and required interfaces, necessary to determine that a system is consistent and complete, i.e. all the interfaces required by all the software modules/components are present in the system. Design of a component model for the SOM is already being considered by the COrDeT project. A more sophisticated model should allow to check component implementation not only based on their functional interface, but also based on their behaviour, or semantics of functions they provide, and their non-functional properties. Dynamic linking: The CDS Deployment Manager is in charge of PM bootloading, downloading an image for the processing module to execute, and also module loading. The CDS Software Repository allows for uploading and downloading applications composed of software modules, version upgrade, etc. However, this functionality has not been fully implemented due to unavailability of a dynamic linking technology which could be easily adopted on the RTEMS platform. At present all software modules must be present in the current PM image, although they might be unused or inactive in the current configuration, and being used after a configuration update. Both Software Repository and software module loading are only simulated. Both the SOM design and all the APIs support configuration updates at the granularity of software modules. Various options for dynamic linking have been already studied and safe and efficient dynamic linking could be added to CDS in the near future. Plug-and-Play: The CCSDS SOIS area is currently defining a concept for Device Plug-and-Play to allow for dynamic discovery and reconfiguration of new devices inserted (mechanically, power-up or by other activation methods) into a spacecraft on-board bus/network. The SOM is implemented assuming a system application configures the SOM with the available devices and the SpaceWire network (following the current standard practise in on-board software). If there are any discrepancies between configuration and reality, they may be detected by the FDIR Fault Detectors and reported to the registered System FDIR application. Insertion of new devices must be controlled by the system application authorised to re-configure the SOM. By implementing the SOIS Device Plug-and-Play services, the device and network configuration knowledge that must be encoded in the system application is removed, removing the risk of a discrepancy between configuration and reality. Task group CPU budgets: The CPU-Time Timers extension to RTEMS supports a CPU-Time timer associated with a single thread. This does not allow for the tracking of CPU utilisation of a group of related threads which constitute an application. To allow the assignment of a CPU budget for an application instance on a particular processing module, the RTEMS extension should be modified so as to be applied to a group of RTEMS threads. Spatial partitioning: The upgrade to RTEMS to make use of the LEON2 memory "write" windowing mechanism should be made, so as to be used to provide spatial partitioning.

Performance

When analysing the performance figures of the SOM product, a number of factors must be taken into account:

• Emulated Memory Arrays, devices and partially emulated SpaceWire network: It must first be considered that a number of elements of the DisCo Demonstrator are emulated using a Linux PC attached to the actual SpaceWire network, in particular the Memory Arrays (MAs), Devices and also a portion of the SpaceWire network (a Virtual SpaceWire Router running as an application, SpaceWire links between Virtual SpaceWire Router and Memory Array Emulation emulated using UDP/IP -this allows multiple SpaceWire nodes to be emulated, each as a Linux applications). All of these must be considered to operate at orders of magnitude slower than corresponding hardware implementations. A more reasonable emulation would run the Memory Array and Device Emulation on individual LEON2-based PMs (PM-Leons), blocking directly on the SpaceWire driver and with the PM-Leon directly connected to a SpaceWire port of the USB-SpaceWire Router, eliminating at least the overhead of the emulated part of the SpaceWire network.

• Tooling support for optimisations: Optimisations of RIS performed were based on data generated using the GNU gprof tool when running SOM tests under Linux. Unfortunately it was not possible to gather timing information, only number of invocations. Thus it was not possible to objectively determine where optimisations would be most efficient, that is to say to identify the functions which use CPU the most (number of their invocations multiplied by their average execution time). Instead analysis of the most frequently invoked functions highlighted a number of functions that were identified as being "likely" to affect performance, e.g. acquiring and releasing of a mutex. Availability of tools to obtain execution times as well as number of invocations would allow for more effective optimisations to take place.

• Limited refinement: Due to schedule and resource constraints, only limited amount of time has been spent on analysing performance issues. Only the client side of RIS remote invocations were optimised (see Tooling Support for Optimisations). Plenty of scope remains for optimisations within the rest of the SOM. During the DisCo "Refinement of the middleware to the level of a product" phase, a number of optimisations were identified and implemented for the Remote Invocation Service. Beyond those already implemented, the following list identifies further optimisations that may be performed: • Reduction of blocking operations per RIS invocation: The SOM uses a number of dynamically allocated objects. To avoid heap fragmentation, the classic technique of memory pools is used. Each memory pool is protected by an exclusive lock, so as to avoid interference between different threads allocating from and freeing objects to the memory pool. The RIS in particular has a large number of objects that are allocated and freed on a per-invocation basis, resulting in many (tens) of exclusive locks being acquired and released on each invocation. This clearly provides a significant overhead. By more detailed consideration of the scope of the objects that are acquired and released per invocation and their reuse between invocations, as well as by adopting non-blocking data structures the number of exclusive locks acquired and released can be reduced. Some of this has already taken place during the SOM refinement, however there is still scope for further improvements.

• RIS invocation request dispatching optimisation: RIS request processing could be optimised by merging some of the task involved in message dispatching. This would imply fewer threads involved in message dispatching and hence less context switches performed per a single message dispatch.

• Local RIS invocation optimisations: The SOM product refinement was focussed on optimising remote RIS invocation optimisations. Depending upon application granularity and deployment, the majority of RIS invocations may turn out to be local. Further optimisations reducing unnecessary marshalling of CORBA headers could be performed.

• CORBA message optimisations: The CORBA request message could be reduced by simplifying the message header from current 70-100 bytes to approximately 20 bytes, offering a considerable saving in network overhead. The impact of this is that the RIS would no longer implement the CORBA standard and would not be able to interoperate with any other CORBA implementation.

• Marshalling and unmarshalling: It has also been considered that the CORBA data representation encoding mechanism, the Common Data Representation (CDR), also imposes an overhead of the network. The notion of marshalling and unmarshalling data into messages is fundamental to CORBA. Each data structure is walked through marshalling or unmarshalling each field in turn, rather than directly memory copying the whole data structure into the CORBA message. Thus marshalling and unmarshalling impose an overhead. However, CDR uses a mechanism known as reader-makes-good, that is to say the RIS invocation requester marshals the operation request into the CORBA request message in its local representation together with a flag indicating whether big endian or little endian was used. If the RIS invocation receiver uses the same data representation, no translation is required, i.e. byte swapping, and the data is simply unmarshalled. On the other hand, if it is different each field must be translated. However, it can be seen that in the majority of real circumstances within an on-board system, the CPU of the requester and receiver's PM would be the same type and so no translation would be required.

Process

The SOM offers technology allowing different applications to be developed separately and integrated later in the development lifecycle. It is crucial to define a development process taking into account the applications' ability to be easily integrated, allowing for smooth transition from independent validation to integrated validation, taking. This should involve developing a process for performing separate timing and memory usage analysis of applications and the SOM platform.

In addition, modelling techniques should be either developed or adopted to model software applications, modules, functional interfaces and bindings between them.

Conclusion

The paper has presented the architecture of the DisCo Space-Oriented Middleware. An early evaluation shows that the SOM addresses many issues of current complex spacecraft on-board applications dealing with multiple processing, memory, I/O and payload modules, and having stringent requirements for predictability, fault detection and handling. The paper has also analysed possible future enhancements of the SOM, its functionality, performance and also corresponding development process.

Figure 1 :

 1 Figure 1: Distributed Scalable Data Handling and Processing Architecture

Figure 2 :

 2 Figure 2: Technology Selection for DisCo SOM

Figure 2 :

 2 Figure 2: SOM Architecture

Figure 3 :

 3 Figure 3: DisCo High-Level Physical Architecture

Acknowledgements

The authors would like to thank the DisCo SOM development team, Patricia Lopez-Cueva, Matthew McBraida, Julian Milby and Nick Clark (all SciSys), as well as Yong-Dan Shi (EADS Astrium SAS) leading development of the reference space application.

Many useful comments were provided by Jean-Charles Fabre and Yves Deswarte (LAAS-CNRS), Christophe Honvault (EADS Astrium SAS), Andy Wellings and Neil Audsley (University of York).

Last but not least, the authors would like to thank the ESA Technical Officer for DisCo, Philippe Chevalley.


Benoît Priot
email: benoit.priot@isae-supaero.fr

Arnaud Dion
email: arnaud.dion@isae-supaero.fr

Guillaume Beaugendre
email: guillaume.beaugendre@isae-supaero.fr

Raghuveer Kasaraneni
email: raghuveer.kasaraneni@isae-supaero.fr

Accurate Events Synchronization in a System-on-Chip Navigation Receiver

Keywords:

A System-On-Chip design and synchronization details of a navigation receiver are presented. The architecture of the GNSS receiver is easily modifiable and offers the capability of accurate time management, thanks to the use of a co-design approach. The purpose of such a platform is to allow real time validation of research algorithms. A secondary application is education, as this platform can be used to study signal demodulation and navigation.

The receiver is fully functional, but further developments are still undergoing. Results demonstrate accuracy, flexibility and ease of use of the system.

I. INTRODUCTION

Event and timing management in a Global Navigation Satellite Systems (GNSS) receiver is critical. Indeed, the standard position, velocity and timing (PVT) solution is based on the propagation delay estimation from the receiver to each satellite in view. Thus, GNSS receivers typically involve high sampling frequency, event synchronization and low latency closed control loops.

Designing a real embedded receiver to study algorithms is a complex task for most research laboratories. There is two usual solutions to tackle this problem : the Field-Programmable Gate Arrays (FPGA) based System-On-Chip (SOC) or pure software using SDR approach. Due to the implementation of matrix of binary operators, architectures based on FPGA allow an interesting concurrent and real-time signal processing [START_REF] Muslim | Efficient FPGA Implementation of OpenCL High-Performance Computing Applications via High-Level Synthesis[END_REF]. The latency of computations in an FPGA is completely deterministic by their very construction, downto a clock cycle. However, designing applications to be ported on FPGA is usually complex and lacks the flexibility of software application for fixed architecture processor. The typical solution is then to use the Software Defined Radio (SDR) approach where all the computations are performed by high performance/high frequency Digital Signal Processors (DSP). Software receivers are already proposed to scientific or industrial community [START_REF] Fernandez-Prades | GNSS-SDR -An open source Global Navigation Satellite Systems software-defined receiver[END_REF]. However, as the architecture is fixed, they are not suited when targeting highly integrated embedded applications or intended Funded by Occitanie region.

for performance, such as power consumption, memory usage or high computations. Whatever the performance of the DSP, it is limited by the fixed number of operators and by the bandwidth of the memory [START_REF] Rowen | Engineering the complex SOC[END_REF]. The classical approaches of hardware (HW) and software (SW) design are very different, as are their design languages : VHDL and C. We used a modern approach based on SystemC language [START_REF] Wieman | An Overview of Open SystemC Initiative Standards Development[END_REF] and High Level Synthesis (HLS) tools in a coherent and common design flow for HW and SW. Such design environment allows to emulate both HW and SW module execution before implementation. It is a great advantage for validating and debugging, as well as making it evolve rapidly according to the emulation results.

The purpose of this work is to develop a GNSS platform for research labs and academic institutions. It offers various possibilities:

• Critical management of time which is the core of a GNSS receiver, • Full access to the architecture, • Rapid and easy reconfigurations of the architecture, • Validation on HW targets of the algorithms developed on SW (Matlab or Octave) receiver. First, a review of the co-design flow and the distributed GNSS architecture will be presented. We will demonstrate the versatility of the approach, from algorithm to architecture. Then a description of the innovative time management and illustrative results will be shown. As stated previously, this is the core of a receiver, and control loop latency should be bounded as tight as possible.

II. SYSTEM DESIGN

In order to create a flexible distributed architecture for a bi-constellation (GPS/Galileo) GNSS receiver, new seamless co-design and high level synthesis tools have been used. The receiver, so-called low-level layer, supports the demodulation of signals, the acquisition and tracking of satellites in view, and leads to the generation of pseudo-ranges (and Doppler frequencies) between the receiver and the satellites. The navigator, so-called high-level layer, converts the receiver-tosatellite pseudo-ranges into PVT solutions. From this generic architecture, a standard receiver/navigator is implemented. It is designed to operate with GPS L1 C/A and Galileo E1 signals. The development, based on SystemC language [START_REF] Wieman | An Overview of Open SystemC Initiative Standards Development[END_REF], is supported by the implementation of a sequential functional simulator in Matlab or Octave (Matlab compatible GNU software). This flow is presented in fig. 1. From the codesign architecture developed on dedicated third party tools, a real-time implementation of the standard receiver/navigator is performed on a hardware platform. Such implementation is based on existing development boards, i.e., the Zedboard (based on Xilinx Zynq-7000), with a radio-frequency (RF) front-end extension board. Such generic development boards are therefore inexpensive. An earlier version of this receiver has been used to assess the performances of computational error mitigation techniques [START_REF] Hafidhi | Demo: Localisation in a faulty digital GPS receiver[END_REF] due to current leakage in components or due to low battery level. SpaceStudio is a C/C++ framework created by SpaceCodesign for developing applications to speed-up performance using CPU and FPGA without knowing the underlying hardware infrastructure of these technologies [START_REF] Filion | A SystemC Framework for Fast Exploration of Hardware/Software Systems[END_REF]. The development of applications is intuitively partitioned to target heterogeneous computing platforms (e.g., System-On-Chip). Designers explore, analyze, profile, and validate designs using the SpaceStudio solution. Using SpaceStudio co-design, we performed the partitioning HW / SW with the SystemC language that allows to generate IP with Vivado High Level Synthesis. This novel implementation technique offers more flexibility as no VHDL coding is required except for the interfaces with the front-end. Thus, except for loop filters, the tracking loops are HW-based. Fast computation capabilities (acquisition Fast Fourier Transform (FFT) and channel tracking) are supported by the HW part (PL). High level computation algorithms with less time constraints (loop filters, raw measurement, navigator) are supported by the SW part using a softcore processor (PL) as well as the ARM processor (PS).

III. EVENT AND TIME MANAGEMENT

Events refer to a given process of the receiver associated to a specific time. They can be related to a specific temporal characteristic of the GNSS signal or to a time-based functionality of the receiver. Based on the architecture of the system, events can be classified into four classes: new sample reception, acquisition and tracking channel initialization, tracking, and measurement.

A. New sample reception

Compared to the architecture presented in [START_REF] Majoral | Implementation of GNSS Receiver Hardware Accelerators in All-Programmable System-On-Chip Platforms[END_REF], the novelty of this project is the direct connection of the front-end to tracking loops. Indeed, no buffer is present at the input of the tracking channels. In addition, the tracking loops are parallel and autonomous. Due to this design, the computational load of the ARM processor is reduced as it only needs to configure the different tracking channels (for initialization and measurement process) and to retrieve the observations when available. The direct connection also implies that samples must be processed as soon as they arrive, because a single loss of sample will strongly affect the performance of the receiver.

In our architecture, the Data IQ handler block is used to manage and to dispatch the incoming samples from the GNSS receiver front-end. The Data IQ handler updates a sample counter register, referred to as N s , which is accessible for all other blocks requiring time synchronization. The receiver reference time t rx is then defined by:

t rx = t 0 rx + N s /F s (1)
where t 0 rx is the initial reference time referenced against GPS time, and F s is the sampling frequency.

The sample counter is crucial for the synchronization and timing between the different blocks because all the other events will be related to a specific sample, as described further.

B. Acquisition and tracking channel initialization

In our architecture, we use a single acquisition block for the whole tracking channels. First, the signal is stored over a fixed period of 8.192ms. The value given by the sample counter for the first recorded sample is also memorized. This value is referred to as N acqui s . Then, we compute the correlation between the signal and a local replica using a FFT-based correlation implementation. This allows to estimate the code delay τ , Doppler frequency f d and signal-to-noise ratio. In case of detection, this information is sent to the channel manager in order to compute the value of the sample counter corresponding to the beginning of a code PRN of the satellite. This value, referred to as N init s , is computed following the equation:

N init s = N acqui s + F s (kT rx c -τ ) (2)
k is an arbitrary integer chosen such as:

N init s > N s + F s T computation (3)
where N s is the current value of the sample counter, and T computation is the computation and communication delay of the channel manager. This equation takes into account the estimated duration of the received PRN code affected by the Doppler effect. This value is referred to as:

T rx c = T c /(1 + f d /f L1 ) (4)
where T c is the standard duration of a PRN code (1 ms for GPS L1 C/A code), and f L1 is the value of L1 frequency.

Then the manager initializes a tracking channel by sending the PRN ID of the satellite, the Doppler frequency and N init s to the tracking block. Satellite signal tracking automatically starts when the value of the sample counter register is equal to N init s . Using Equation ( 2) and (4) it is possible to bound the maximum time lapse for this initialization, depending on the precision of acquisition results and the dynamic of the vehicle. For example, with a Doppler frequency error of 200Hz and a time lapse of 5s, the error on the estimated starting time of the code PRN is about 0.635µs. This value is lower than the chip period, which is 0.9775µs for GPS L1 C/A and Galileo E1-B/C signals. Thus the tracking channels can be initialized. Also, the dynamic of the vehicle can also be taken into account, as an acceleration of 1m/s 2 induce a Doppler rate of 5.255Hz/s, and a maximum Doppler frequency error of 26.3Hz after 5s.

Therefore, this functional design allows us to take into account the non-deterministic delay resulting from computation process and from communications between blocks while ensuring the synchronization of tracking loops with the incoming signal.

C. Tracking

In our architecture, the tracking loops are divided into four functional blocks as shown in the diagram presented in fig. 3. The different blocks are defined by their activation time. They are executed following a cascaded chain of events, and have different working frequencies. These blocks are defined as follow:

1) the NCO Correlator, activated at each new sample coming from the Data IQ handler, 2) the Integrator Synchronizer, activated at each end of code coming from the NCO Correlator, 3) the LoopEstimator, activated at each integrator output coming from the Integrator Synchronizer, 4) the DataDecoder, activated at each end of bit coming from the Integrator Synchronizer. The NCO Correlator block is composed of three functional blocks: carrier NCO, code NCO and correlators. At each new sample, the carrier phase φ and code phase ϕ c of the respective NCO are incremented. Once the code phase reaches the end of the PRN code table (1023 chips for GPS L1 C/A signal), an End of Code event is triggered, and outputs of the correlators are sent to the Integrator Synchronizer block.

The Integrator Synchronizer block is composed of the bit synchronization and of the integrators. At each End of Code event, the value of the code counter N c is incremented and is used to trigger two events. One is the End of Integration event, which triggers the send of the outputs of the integrators to the LoopEstimator. The second is the End of Bit event, which triggers the send of the bit value to the DataDecoder block, and triggers the reset of the code counter.

The LoopEstimator block is composed of the phase and delay discriminators, and of the phase and delay loop filters. It updates the commands of the NCO, and estimates the Doppler frequency. It does not generate any event as the NCO processes the latest commands values available using dedicated registers. A delay can be observed between the End of Code from the NCO Correlator block and the update of the NCO command, which could be reduced by the optimization of computation in the tracking loop.

The DataDecoder block main task is to decode the frame of the navigation message in order to retrieve information such as ephemeris data of the satellites and time, using the bitstream from Integrator Synchronizer block. It also includes a preamble detector, a bit counter N b , and a frame counter N f . The frame counter is updated thanks to the timing information of the navigation message.

D. Measurement

The purpose of measurements is to retrieve the valuable information associated to the same reference time t rx from all the tracking channels. This information is sent to the Measurer Navigator block in order to elaborate raw measurements, in particular pseudo-range measurements. The pseudo-ranges are computed following the equation:

P R = (t rx -t sv )/c ( 5
)
where c is the speed of light, t rx is the receiver reference time associated with the measurement, and t sv is the satellite transmission time, given by:

t sv = T chip ϕ c + T c N c + T b N b + T f N f (6)
where T chip is the chip period, T c is the PRN code period, T b is the bit period, and T f is the frame period. As described previously, ϕ c comes from NCO Correlator, N c comes from Integrator Synchronizer, and N b and N f come from DataDecoder. In order to synchronize the measurements for the whole tracking channels, we use the Data IQ handler block to trigger a Measurement event when the value of the sample counter register is equal to N meas s by using a Do Measurement flag. Then the NCO correlator block of each channel, which is the only block of the tracking channel activated at each sample, is tasked to fetch the data and send them to the Measurer Navigator block.

However, due to the cascaded architecture of the tracking loops, a challenge is to wait for the Integrator Synchronizer and the DataDecoder to finish their computation, while not blocking the NCO Correlator process. The solution selected for our architecture, illustrated in fig. 5, is described as follow: First, the NCO Correlator saves the value of the carrier phase and code phase. Then, in case of End of Code, we set a Measurement Enable flag to zero, and resume NCO Correlator process. When Measurement Enable is set to one, the NCO Correlator collects remaining data and send it to the Measurer Navigator block. This process ensures the coherency and the datation of the raw measurements, even in case computation or communication delay.

IV. RESULTS AND DISCUSSION

The receiver has been completely implemented with six GPS channels and is fully functional. It can be extended to as many channels as can be fitted in the HW. For simulation and debbuging purposes we used a recorded signal. We sampled the GNSS signal with an SBX board mounted on an ETTUS USRP X310. We are working to integrate the Analog Device AD9361 RF board with the FPGA.

The test of this architecture has shown the capability to initialize the channels from the results of the acquisition, regardless of the computing delay of the acquisition. The results obtained when using tracking loops (integrators, discriminators, Doppler frequency and C/N0) are shown in fig. 6, when initialized with acquisition outputs. The acquisition process start at 0s. At approximately 1.9s, the acquisition provides its results to the manager which configures the tracking loop. We can see that the Doppler frequency is initialized. At 2.5 s, the tracking loop starts the tracking process. From that moment, the loop converges and work properly. In this test, the initialization delay and the tracking start delay have been increased intentionally, in order to validate channel initialization.

In addition to the development of the aforementioned codesign architecture, one of the expected outputs is a Vivado project (or EDK) compatible with the hardware platform, targeted and validated on such platform.

V. CONCLUSION

This work demonstrates that co-design GNSS architecture is of great interest to fix the complexity and non-flexibility issues related to the use of FPGA. It offers both the capability of a critical management of time and of an open and easily modifiable architecture. The high level modelling and simulation allows early key decisions and shortens the development process [START_REF] Dion | A Flexible Implementation of a Global Navigation Satellite System (GNSS) receiver for on-board satellite navigation[END_REF].

Fig. 1 .

 1 Fig. 1. Seamless design flow.

Fig. 2 .

 2 Fig. 2. block diagram of the architecture.

Fig. 3 .

 3 Fig. 3. block diagram of the tracking channels.

Fig. 4 .

 4 Fig. 4. Event time diagram.

Fig. 5 .

 5 Fig. 5. Measure event time diagram.

Fig. 6 .

 6 Fig. 6. Test results of the tracking loops.

ACKNOWLEDGMENT

This work has been funded by Occitanie region.

The authors would like to thank Dr Gaël Pagès for the work on the software manager, as well as Space Codesign for the technical support. The authors would also like to thank Dr Anne-Emmanuelle Priot for her help and support.