Ben Taylor

Guglielmo S Aglietti
email: g.aglietti@surrey.ac.uk

Simon Fellowes

Thierry Salmon

Alexander Hall

Thomas Chabot

Aurélien Pisseloup

Sean Ainley

Dan Tye

I Retat

Aurelien Pisseloup

Cesar Bernal

Francois Chaumette

Alexandre Pollini

Willem Steyn

RemoveDebris Preliminary Mission Results

Keywords: space debris, debris removal, ADR, commissioning, net, harpoon, vision-based navigation, dragsail 1

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

An extensive literature survey in the field of active debris removal has been presented in a recent papers [START_REF] Forshaw | The RemoveDebris ADR Mission: Launch from the ISS, Operations and Experimental Timelines[END_REF].

Mission Overview

The mission concept consists of a main mini satellite platform of approximately 100kg mass that once in orbit will release two 2U cubesats which will act as space debris simulators (more details on the mission can be found in [ 2 , 3 , 4 ]). Four key technologies, to be used at different stages of a typical Active Debris Removal (ADR) mission will be tested: Vision Based Navigation (VBN) as a tool to observe and quantify the relative dynamics between an uncooperative debris and the platform preparing for its retrieval; two technologies for debris capture, namely a net and a harpoon; and finally a de-orbit sail, to increase the satellite platform drag, thus reducing its speed and orbit altitude until it burns up in the Earth's atmosphere.

One of the cubesats, after low speed ejection from the satellite platform will be observed using the VBN to prove its hardware and algorithm, whilst the CubeSat also relays attitude data to the satellite platform for validation. The second cubesat, after ejection, will inflate a structure to increase its size to make it comparable to that of larger debris becoming a more size-representative target for the net capture experiment i.e. a net will be launched by the platform to envelope and capture the cubesat. A small panel of material analogous to that used in standard satellites construction will then be deployed using a boom that will position this panel at a 1.5 meter distance from the platform. This panel will be the target for the harpoon experiment (i.e. a tethered harpoon is going to be fired by the satellite platform to hit this panel). The last experiment to be performed will be the drag sail. During a real mission this would be the last phase, when the platform and the debris that it has captured are deorbited together, destroying through burn-up. IAC-18-A6.1.5

Page 2 of 8

Figure 1 shows the sequencing of the four experiments in the mission. The net sequence is: (N1) DS-1 CubeSat ejection, (N2) inflatable structure inflation, (N3) net firing, (N4) net capture. The VBN sequence is: (V1) DS-2 CubeSat ejection, (V2) DS-2 drifts away, (V3) VBN system collects data. The harpoon sequence is: (H1) harpoon target plate extended, (H2) target plate reaches end, (H3) harpoon firing, (H4) harpoon capture. The dragsail sequence is: (D1) inflatable mast deploys, (D2) sail starts deployment, (D3) sail finishes deployment.

The mission design has tried to ensure the payloads are representative as possible for future missions and have scalability potential to larger classes. In certain cases, the mission had to give priority to practicality, satisfying regulatory (licensing) requirements or safety requirements. For instance, sizing of the payload targets was selected to ensure the artificial debris would reenter in a timely fashion whether or not the mission was successful, similarly a low altitude orbit was selected to ensure prompt disposal of the mission.

1.2

Paper Structure This paper I structured into 5 sections. Section 1 provides the mission introduction and overview. Section 2 describes the spacecraft and hosted hosted payloads in greater detail. Section 3 presents the launch and deployment operations of the mission, with section 4 discussing the platform and payload commissioning acivities. Finally, Section 5 gives an overview of the experimental timeline as the mission moves to the payload demonstrations.

2

Spacecraft description The platform and payloads are described in the next sub sections, and more details, including test activities can be found in [START_REF] Forshaw | Final payload test results for the RemoveDebris active debris removal mission[END_REF].

Platform

The RemoveDebris satellite platform is based on the X50 satellite and utilizes internally developed avionics systems under the SSTL Fireworks programme. The X-Series platforms are being developed with some key drivers and principles in mind. These are a combination of (a) principles that SSTL have employed successfully in delivering small satellites in the last 30 years, and (b) new approaches that are enabled by SSTL's evolution as a company in the last 15 years, specifically the recently developed in house capabilities for batch/mass production and automated test.

The RemoveDebris platform has been modified to be compliant for ISS deployment including battery and activation safety features consisting of apply before flight items to be added by astronauts and additional delayed start-up system safeties. Further, certain elements of software for activation of payloads are to be uploaded once deployed from the ISS, rather than included at launch to ensure potentially dangerous commands cannot be sent be spurious commanding whilst in proximity to the ISS. The platform, in the AIT hall, can be seen in Figures 2 and3. Note that the back face of the spacecraft is covered with a solar panel for flight and that the dragsail has been reallocated to the back panel from former designs in [START_REF] Taylor | The RemoveDebris Mission, From Concept To Orbit[END_REF]. A cutout is made in the back panel for dragsail deployment.

Visual Based Navigation System

The Vision-Based Navigation is an experiment of proximity navigation between the satellite platform and a CubeSat, designated DS-2 [START_REF] Yol | Vision-based navigation in low earth orbit[END_REF]. At the beginning of the experiment DS-2 will be ejected by the platform and will drift gently away for several hours while the attitude is controlled to maintain a slow rotation. The main goal of the experiment is to evaluate navigation algorithms and a VBN sensor. The DS-2 CubeSat is a fully functional system and acts as an active target with integrated camera, GPS receiver and Inter-Satellite link (ISL). In this way, the VBN will capture navigation data of the position, orientation and relative velocity of the DS-2 CubeSat, which can be verified by the data and images captured by DS-2 and transmitted back to the mothership.

Dedicated image processing and navigation algorithms have been designed at Airbus Defence and Space and INRIA to meet the specific case of noncooperative rendezvous [START_REF] Petit | Tracking complex targets for space rendezvous and debris removal applications[END_REF]. Airbus Defence and Space is responsible for the overall VBN experiment and the navigation algorithms, while CSEM is in charge of the sensor. Figure 5 shows an image captured with the camera. The respective distance of the targets are quoted on the image. Below this, the figure presents the same scene captured with the LiDAR. The LiDAR provides 2 images: a B&W intensity image similar to any standard camera, and a distance image or depth map that is a 3D image of the scene of interest or target. Performance requirements are verified by ensuring the hardware is capable of collecting the requisite number of images. The way in which the VBN algorithms are validated with respect to the VBN experiment and the tracking performance have been investigated in a separate paper 3 .

Once integrated with the platform, the VBN experiment was verified through the system chain including transfer of images to the Payload Interface Unit (PIU) and transfer to operators. The DS-2 target CubeSat includes an inter-satellite link (ISL), with a matching module integrated on the platform to collect data from the target. DS-2 streams GPS position, attitude data, imagery and general system telemetry one way over the ISL. On the platform, the ISL data is in turn streamed to the spacecraft PIU. Prior to integration, the ISL subsystems were extensively range tested on ground up to 500m with a 99% packet transfer success. Further, once integrated in to DS-2, the system was demonstrated at representative departure velocities performing all functions and streaming imagery and GPS location as expected on orbit.

Net Experiment

The NET payload will be the first in-orbit flight demonstration for a system catching large orbital debris via a high strength net. On the RemoveDebris mission artificial orbital debris of 2kg and 1m diameter will be captured, however, the 5m net used for this demonstration is already capable to capture debris in the 1.5m range and to return up to several hundred kilograms to Earth on a destructive trajectory. This experiment will be the next big step after successful IAC-18-A6.1.5

Page 5 of 8 demonstrations of the net deployment in both drop tower and on a parabolic flight. The NET design is shown in Figure 6. The NET container has 275mm diameter and a height of 225mm. The total mass is 6kg.The high strength fiber net is deployed by concentric accommodated flight weights and a central lid, dragging the net. Motors and winches integrated within the weights are used to close the net after successful capture of the debris. The net deployment and closure will be achieved via redundant mechanisms. The NET will be released to capture the DS-1 debris target at 6m distance from the spacecraft.

Due to the complex dynamics of nets in microgravity, the NET has been tested on parabolic aircraft flights as well as a drop tower to verify correct opening and closing of the net.

As shown in Figure 1, the N2 stages involve the CubeSat, DS-1, deploying an inflatable sail system. The inflatable structure is constructed with five aluminum-polymer laminate cylindrical booms, with an average length of 45 cm. A set of four triangular polyester film segments or sails finish the structure. Initially the booms and sail are compacted into the satellite. The cutting of a burn-wire releases the booms and sail, whereby Cool Gas Generators (CGGs) activate to deploy the booms and side plates outwards and draw out the sail material. The central hub contains the undeployed z-folded booms which are a two layer aluminum-PET membrane. To prevent the membrane from detaching during pressurization the ends of the booms are clamped between two aluminum disks. The principles of the deployable inflatable for the DS-1 experiment are explained in more detail in a separate paper [START_REF] Yol | Vision-based navigation in low earth orbit[END_REF]. The DS-1 CubeSat is electrically simple compared to DS-2, with only a power system and automated payload board to perform burn wire and CGG initiation. Repeated testing of the inflatables was performed to verify performance, including activation at the cold extreme case.

2.4

Harpon and target The harpoon target assembly (HTA) is shown in Figure 7 and contains: structure, deployable boom mechanism, two frangibolts, target plate, harpoon and safety door. The full operation of the harpoon system has been detailed in other papers [START_REF] Forshaw | The RemoveDebris ADR Mission: Launch from the ISS, Operations and Experimental Timelines[END_REF][START_REF] Petit | Tracking complex targets for space rendezvous and debris removal applications[END_REF] The sequence for deployment of the target plate is as follows. Initially the target plate frangibolt is cut to release the outer plate. Then the Oxford Space Systems (OSS) deployable boom system is commanded to reel out the boom. The target plate is fixed to the end of the 1.5 meter boom and is pushed outwards. The OSS boom system consists of a carbon fiber boom rolled into a circle and unrolled outwards with a motor and guiding mechanism. Sensors are able to determine the length of the boom uncoiled and retraction is also possible, but not used on the RemoveDebris mission. Figure 7 shows the fully deployed boom system. Careful alignment is made on ground to ensure the harpoon is aligned with the centre of the target plate through use of a laser substituting for the harpoon. The plate is made of a metal honeycomb and is the same material the core of ESA's Envisat satellite is made of.

2.5

DragSail Experiment The last experiment to be deployed is the dragsail. This system consists of two parts: an inflatable mast and a sail deployment mechanism located at the tip of the mast. Details of its development can be found in [START_REF] Fernandez | Design and development of a gossamer sail system for deorbiting in low earth orbit[END_REF][START_REF] Aglietti | An overview of the mechanisms and deployables on the removedebris ADR mission[END_REF].

The system utilizes a 'jack-in-the-box' deployment method, with a cool gas generator (CGG) that inflates the folded mast, and pushes the stored sail and its deployment mechanism out of its container. The inflatable cylindrical mast (1 m long, 90 mm diameter) consists of a tough aluminium-BoPET three-ply laminate. A BoPET bladder is used inside the cylinder to improve airtightness. Once full mast deployment and rigidisation has occurred, the inflation gas is vented symmetrically. The sail is then deployed using a brushless DC motor stored in the central shaft of the sail deployment mechanism which unfurls four 1.5 meter long carbon fiber booms, drawing the sail out

3

Launch and Deployment After final system end to end and environmental testing, the RemoveDebris spacecraft was packaged for delivery and flight. The main platform is protected by a series of concentric encasements for shipping. Firstly cover panels screw into the platform structure and protect the solar panels. Secondly the panelled structure is placed within a clam shell. This clam shell is placed into a metal protective box and the box is put into the shipping container.

On arrival at Cape Caneveral, the shipping container was removed and the RemoveDebris platform the platform was unpacked down to the clam shell, loaded into a cargo transfer bag (CTB) and embarked on to the CRS-14 Dragon as cargo in the pressurized section.

CRS-14 launched on 2 nd April 2018 on a Falcon 9 launch vehicle, with the dragon capsule arriving and docking at the ISS two days on 4 th April 2018. The RemoveDebris spacecraft was unloaded from the capsule pending the scheduled deployment.

After unpacking and removing the platform handling panels, the RemoveDebris satellite was loaded in to the Japanese Experiment Module (JEM) airlock on 6 th June 2018. Launch and Early Operations Phase (LEOP) Deployment from the ISS marked the beginning of the RemoveDebris LEOP commissioning. Contact was made with RemoveDebris during the first pass after power up over the SSTL groundstation in Guildford, UK. This showed the spacecraft was performing nominally and the battery was fully charged. Initial commissioning progressed with switch on of the spacecraft OBC, followed by detumbling from the slow initial angular rate to a controlled attitude state. AOCS commissioning then progressed through higher order control modes until the platform was in a coarse Nadir pointing mode.

4.2

Platform Checkout Key healthchecks were performed on key platform modules not already checked by virtue of moving to nadir pointing mode, including prime and redundant RF receivers, low rate transmitters and low level command links.

The spacecraft then performed a series of AOCS manoeuvres to verify performance against that required for executing payload experiments.

4.3

Payload Checkout The critical data chains and experiment support systems were tested including verification of GPS, prime and redundant High Rate Transmitters (HRTs), Payload Interface Units (PIUs) and the Inter Satellite Link (ISL). This testing demonstrates full chain performance, from GPS/ISL to PIU to HRT to ground. The payloads are essentially "one-shot" systems, limiting the level of checkout that can be performed on the experiments themselves. All payload checkouts have shown good performance./

4.4

Payload Calibration and Characterisation Once data paths had been established, commissioning moved on to calibration and characterisation of the imaging systems. The Supervision cameras and VBN 2D camera were tested over a range of exposures and frame rates which are planned for use on the experimental demonstrations. Imaging targets on the Earth were selected to check the bright and dark image signal levels. Typically, polar regions are used of the bright imagery, however due to the orbital inclination not reaching high latitudes, cloud tops were used instead for this purpose. Uniform zones such as the Sahara desert were also used to characterise the intrinsic sensor noise patterns.

Rehearsal sequences have been performed that include representative lighting conditions and spacecraft slews. An image captured during the Net experiment rehearsal is shown in Figure 12 showing the Earth partially in FoV, as expected.

5

Experimental Timeline The RemoveDebris mission is now moving to the experimental demonstration phase, with the anticipated timeline given in the table below.

Conclusions

This paper has given an overview of the of RemoveDEBRIS mission, briefly describing the spacecraft and its experiments, and giving an update on the launch, deployment, and commissioning of the craft.

The RemoveDebris mission, now performing experimental payload operations, will be the first demonstration of key ADR technologies crucial to ensuring a space environment safe from space debris.

Figure 1 .

 1 Figure 1. N1 to N4: net experiment, V1 to V3: vision-based navigation experiment, H1 to H4: harpoon experiment, D1 to D3: dragsail experiment.

Figure 2 .

 2 Figure 2. Platform -Payload Face. Top: platform under integration. Credit: SSTL, 2017. Bottom: CAD model view of the same face.

Figure 3 .

 3 Figure 3. Platform -Back Face. Top: platform under integration. Credit: SSTL, 2017. Bottom: CAD model view of the same face.

Figure 4 .

 4 Figure 4. Left: Vision Based Navigation payload, Right: DS-2 target in deployed state The University of Surrey have supplied the DS-2 target CubeSat with an attitude control system supplied by the University of Stellenbosch. The VBN sensor has two main subsystems: an off-the-shelf colour camera and a flash imaging Light Detection and Ranging device (LiDAR) developed by CSEM. Its main functionality is to capture images of DS-2 with both vision-based devices according to a predefined timeline defining snapshot times and integration times.Figure5shows an image captured with the camera. The respective distance of the targets are quoted on the image. Below this, the figure presents the same scene captured with the LiDAR. The LiDAR provides 2 images: a B&W intensity image similar to any standard camera, and a distance image or depth map that is a 3D image of the scene of interest or target. Performance requirements are verified by ensuring the hardware is capable of collecting the requisite number of images. The way in which the VBN algorithms are validated with respect to the VBN experiment and the tracking

Figure 5 .

 5 Figure 5. Top: test scene for VBN system, Bottom Left: showing image intensity in number of visible photons (more yellow objects are brighter). Bottom Right: 3D depthmap scene in metres.

Figure 7 .

 7 Figure 7. Top Left: inside the Harpoon target assembly (HTA); Bottom Left: CAD model of HTA with target partially deployed. Right: HTA with CPRF boom fully deployed during fire testing (HTA at bottom, target plate at top).

Figure 6 .

 6 Figure 6. Left: NET undergoing vibration testing, Centre: NET CAD model; Right: Partially deployed system exposing flight weights.

Figure 8 .Figure 9 .of 8 Figure 10 .

 89810 Figure 8. Top: RemoveDebris fitted with mounted handling panels; Bottom: RemoveDebris in shipping container

Figure 11 .

 11 Figure 11. Left: RemoveDebris observed from the ISS shortly after deployment, Right: Close up of platform 4 Commissioning Operations 4.1Launch and Early Operations Phase (LEOP) Deployment from the ISS marked the beginning of the RemoveDebris LEOP commissioning. Contact was made with RemoveDebris during the first pass after power up over the SSTL groundstation in Guildford, UK. This showed the spacecraft was performing nominally and the battery was fully charged. Initial commissioning progressed with switch on of the spacecraft OBC, followed by detumbling from the slow initial angular rate to a controlled attitude state. AOCS commissioning then progressed through higher order control modes until the platform was in a coarse Nadir pointing mode.4.2Platform Checkout Key healthchecks were performed on key platform modules not already checked by virtue of moving to nadir pointing mode, including prime and redundant RF

Figure 12 .

 12 Figure 12. Supervision camera image captured during Net rehearsal operation

Table 1 .

 1 RemoveDebris Experimental timeline

	Event	NET Date	Description
	Net	September	Deployment and inflation of DS-1
	Experiment	2018	CubeSat
			Deployment of Net and capture of
			DS-1
	Visual Based	October	Deployment of DS-2 CubeSat,
	Navigation	2018	transmission of imagery and
	Experiment		attitude/position data
			Observation of departing DS-2 by
			VBN payload
	Harpoon	February	Deployment of Harpoon Target on
	Experiment	2019	end of boom
			Firing of harpoon into target
			Retraction of boom, target and
			harpoon
	DragSail	March	Deployment of Inflatable Boom and
	Experiment	2019	Sail
			Accelerated deorbiting of spacecraft

Acknowledgements

The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement n°607099. 'RemoveDebris -A Low Cost Active Debris Removal Demonstration Mission', a consortium partnership project consisting of: Surrey Space Centre (University of Surrey), SSTL, Airbus DS (formerly Astrium) GmbH, Airbus SAS, Airbus Ltd, ArianeGroup France, Innovative Solutions in Space (ISIS), CSEM, Inria, Stellenbosch University.

The authors would also like to acknowledge the help and support of the members of the RemoveDebris consortium and the support of launching agent NanoRacks.


Claire Pagetti

Julien Forget

Heiko Falk

Dominic Oehlert

Arno Luppold

Automated generation of time-predictable executables on multi-core

In this paper, we are interested in the implementation of control-command applications, such as the flight control system of an aircraft for instance, on multi-core hardware. Due to certification and safety issues, time-predictability -in the sense that the timing behavior must be analysable and validable off-line -is a mandatory feature. We present a complete framework, from high-level system specification in synchronous languages, to implementation on a multi-core hardware platform, which enforces time-predictability at every step of the development process. The framework is based on automated code generation tools to speed-up the development process and to eliminate error-prone human-made translation steps.

Introduction

Developing safety critical applications requires to respect standardized guidelines, concerning for instance the development process (e.g. the ARP 4754 [START_REF]Aerospace Recommended Practices ARP4754a -development of civil aircraft and systems[END_REF] for aeronautics) or the software development (e.g. the DO-178C [START_REF]DO-178 ED-12B -Software Considerations in Airborne Systems and Equipment Certification[END_REF]). In the aeronautics domain, certification authorities require the designers to show, prove and argue that the system has been developed correctly and in compliance with the standards, such as the aforementioned ones. Time-predictability is one important objective according to the DO-178C, in the sense that the timing behavior of a system must be analyzable and validable off-line. Dealing with this objective for multi-core is known to be complex or even unfeasible in the general case [START_REF] Wilhelm | The worst-case execution-time problem -overview of methods and survey of tools[END_REF][START_REF] Wilhelm | Embedded systems: Many cores -many problems[END_REF], because of intensive resource sharing, complex internal behavior and lack of documentation. In the academic literature, there has been a lot of effort to propose WCET analysis techniques and predictable programming languages; in the industry, dedicated standards have been defined. The most recent documents are the CAST-32A [START_REF]Position Paper on Multi-core Processors -CAST-32A[END_REF] and some recommendations published by the FAA [START_REF] Mutuel | Assurance of Multicore Processors in Airborne Systems[END_REF]: they provide a set of guidelines, among which the applicant should identify the interference channels (e.g interference on memory buses) and argue that they are properly mitigated by adequate means.

In this paper, we focus on the software development process, to ensure time-predictability at every step of the process. Here, the term time-predictability encompasses: eliminating bus interferences thanks to the AER (Acquisition Execution Restitution) execution model, simplifying the computation of WCET upper-bounds, enabling the schedulability analysis of a task set, and preserving the semantics of the program throughout successive code generation steps.

Applicative context

A control-command application aims at controlling and supervising a physical entity in its environment. A typical example is the flight control system of an airplane. We consider the longitudinal flight controller of the Research Open-Source Avionics and Control Engineering (or Rosace) case study [START_REF] Pagetti | The rosace case study: From simulink specification to multi/many-core execution[END_REF]. Although of modest size, this controller is representative of real avionics applications.

Figure 1 depicts the Rosace architecture. The controller is composed of 8 functions (depicted by boxes) that run at different periods and exchange data (depicted by arrows). A series of filters (named X filter ) consolidate the data measured on the aircraft and two controllers manage the airspeed (va control ) and the vertical speed (vz control and altitude hold ). Data-dependencies are causal, for instance, the function vz filter produces the variable vz f, which is consumed by functions vz control and va control. The controller receives two inputs from the cockpit, which are the orders requested by the pilot on the altitude h c and on the vertical air speed V a c . The Aircraft receives the orders δ ec and δ thc computed by the controller.

Current industrial development process

The current development process followed by air-framers [START_REF] Souyris | Formal verification of avionics software products[END_REF] for implementing such a controller on a single core architecture is the following. Each function is coded in the Scade language [START_REF]SCADE Language -Reference Manual[END_REF] (the industrial version of lustre [START_REF] Caspi | Lustre: A declarative language for programming synchronous systems[END_REF]) and the assembly (that is how functions are interconnected and scheduled) is implemented in an ad-hoc language. The proprietary qualified tool KCG of Ansys [START_REF]SCADE Suite KCG C & ADA Code Generator[END_REF] translates each Scade program into an equivalent C code. The generated C code uses no dynamic memory allocation and only bounded loops, in order to ensure low timing variability. gcc is then used to generate the executable.

The WCET of the different functions is analyzed by the aiT tool from Absint [START_REF]Worst-case execution time analyzer ait[END_REF]. Each function is analyzed in isolation using static analysis. Functions execute non-preemptively, following a schedule computed statically.

Contribution

In this work, we adapt the existing industrial process to support multi-core hardware, and also to rely on freely available software. Our framework covers the whole development process, from the high-level specification with synchronous languages, to the implementation on the target hardware platform. Thanks to automated code generation, the time-predictability of the developed system is established on its high-level specification and preserved during the subsequent steps of the development. 2 summarizes the framework and the novelties of the paper are highlighted in bold. The highlevel specification is performed combining lustre, for the functions, and Prelude [START_REF] Pagetti | Multi-task implementation of multi-periodic synchronous programs[END_REF], for the assembly.

lustre functions are compiled into C code using the open-source lustrec compiler from ONERA [START_REF] Garoche | Testing-based compiler validation for synchronous languages[END_REF] 1 . The preludec compiler produces a C code that assembles the lustre functions into a multi-task program. The C code is compiled using the wcc (WCET-aware C Compiler) compiler [START_REF] Falk | A compiler framework for the reduction of worst-case execution times[END_REF]. The back-end of wcc generates a partitioned non-preemptive schedule. The WCET of each function is analyzed separately using aiT. The application executes on an arm-based multi-core architecture, which has the particularity of combining a global flash memory with private local addressable scratchpad memory (SPM), instead of local cache memory. Time-predictability is addressed at each step of the framework. First, the synchronous approach [START_REF] Benveniste | The synchronous approach to reactive and real-time systems[END_REF], followed by lustre, simplifies the programming of real-time aspects by reasoning on logical time, focusing only on the execution order instead of the exact execution dates. Second, Prelude transposes the synchronous semantics to the assembly level and introduces specific constructs to ensure that multi-rate communications have a deterministic semantics. preludec has been extended to generate multi-phase AER tasks [START_REF] Durrieu | Predictable flight management system implementation on a multicore processor[END_REF], which separate computation phases from communication phases (as in [START_REF] Pellizzoni | A predictable execution model for COTS-based embedded systems[END_REF][START_REF] Boniol | Deterministic execution model on cots hardware[END_REF]). This effectively eliminates memory access contentions during computation phases, which simplifies the WCET analysis of these phases. Third, the schedule computed off-line ensures that real-time constraints will be respected. Furthermore, because we adopt a non-preemptive partitioned schedule, there is no interference between tasks due to preemption, which again simplifies the WCET analysis. Fourth, wcc is designed specifically to produce an internal representation that is more amenable to WCET analysis, meaning that the WCET over-estimation, performed by aiT, is reduced. Finally, relying on local addressable memory (scratchpad) instead of caches further simplifies the WCET analysis.

The main novelty of our work is to provide a complete development framework focusing on time-predictability on multi-core. Our approach extends and integrates previous ideas. The elements of the framework that are new are the following: the compilation of Prelude programs into AER tasks, the off-line scheduling of AER tasks, the integration of AER tasks and a task sequencer (off-line schedule) into wcc, and the hardware architecture choice with its dedicated execution model.

Framework overview

In this section we provide an overview of the development framework presented in Figure 2. This section focuses on the integration of the different steps of the framework. The extensions we made to the different elements of the framework will be detailed in subsequent sections.

Initial program

The system is programmed as a combination of Prelude [START_REF] Pagetti | Multi-task implementation of multi-periodic synchronous programs[END_REF] and lustre [START_REF] Caspi | Lustre: A declarative language for programming synchronous systems[END_REF], two synchronous languages [START_REF] Benveniste | The synchronous approach to reactive and real-time systems[END_REF].

Each function is first programmed separately as a lustre node. The inputs and outputs of one node are all synchronous, which means in our context that they are all consumed or produced at the same periodic rate. Each node is compiled separately by the lustrec compiler, which translates lustre code into C code.

lustre nodes are then assembled together in a Prelude program, which details the real-time constraints of the system and the semantics of the communications between the lustre nodes. This assembly is not done directly in lustre because communications relate nodes executing at different periodic rates; Prelude is better suited to the specification, analysis and efficient compilation of such systems [START_REF] Pagetti | Multi-task implementation of multi-periodic synchronous programs[END_REF]. An example of Prelude program is provided in Code 1. vz filter and vz control are imported nodes, programmed separately in lustre. The main node rosace main details the data-flows between the imported nodes. For instance vz filter produces value vz f, which is consumed by vz control. The rate of flow vz f is reduced by 2 (vz fˆ/2 ), so that vz control executes twice slower than vz filter. Periods are specified on the inputs and outputs of the main node, for instance h c has a period of 100 and an offset of 0. preludec deduces the periods of the imported node calls from the period of its inputs.

¦ ¥

preludec translates the Prelude program into a multi-task C code, where each lustre node corresponds to one task. Tasks are executed periodically, the code executed during each period is the C code generated by lustre for the corresponding node. In order to prevent memory access contentions during the execution of a task, the code of each task follows the AER model: there is a separate C function for the Acquisition phase, the Execution phase and the Restitution phase. The Acquisition phase is in charge of collecting all data required for the computation. This phase accesses to the shared memory (the flash memory), to fetch data into local memory. On the contrary, the Execution phase is pure computation, no access to shared memory occurs. The Restitution phase consists in copying all the results of the Execution phase from the local memory to the shared memory. Splitting the interference-free phases from the non interference-free phases greatly simplifies the computation of the WCET of each phase (see Section 3.2 for more details). Finally, preludec also generates a description of the task set in an xml file for wcc (see below, Section 2.2.2). The AER code generation process is a new contribution of this work, it is detailed in Section 4.

wcc

In this section, we give a brief overview of wcc, of the inputs needed in order to compile multi-task programs, and of how the off-line mapping of Section 5 was integrated in wcc.

Compiler overview

A compiler makes several transformation steps in order to transform a C code into an executable for a given target [START_REF] Aho | Compilers: Principles, Techniques, and Tools[END_REF]. The transformation steps of wcc are detailed in Figure 3. The parser translates the C code into a high level representation (denoted ICD-C in wcc). The ICD-C representation is then translated into a low level representation (LLIR -Low-Level Intermediate Representation), which already depends partially on the processor target. Finally, the assembler and linker produce the executable. Compared to a classic C compiler, the specifics of wcc are:

1. The LLIR is analyzed with static WCET analysis tools. In this work, we use aiT of Absint [START_REF]Worst-case execution time analyzer ait[END_REF]; 2. wcc includes some optimizations on the LLIR targeted for the reduction of the WCET. In classic compilers, most standard optimizations are targeted for the reduction of the average execution-time not the worst-case execution time.

wcc High level ICD-C

Low level LLIR Memory layout aiT WCET results

WCET-aware mapping

Input description: application and architecture

In order to deal with timing aspects, wcc requires more information than just the C file(s). First, it requires a file that describes some characteristics of the physical architecture such as the number of cores, the memory sizes, the maximal read and write access time to each memory. Because we rely on a TDMA bus (see Section 3.1 for details), a second file describes the TDMA features and contains the slots length and the repetition length of the TDM. In a third file, the user specifies in an xml file the function set with the real-time attributes such as the period. In our case this file is generated by preludec, as well as the C files.

Code architecture

A specific mapping aware compilation procedure has been implemented in wcc. The algorithm 1 summarizes its main steps. First, we read the hardware characteristics. We consider that each core has direct access to a private scratchpad memory (SPM), and access to a shared flash via a private bus. Next, the first for loop reads the application description (stored in the xml file and in the C code). Inside the loop, aiT is called in order to compute the WCET and the size of each function of the application and each of its AER phases. Thanks to the AER model, the aiT analysis can assume that code on each core executes in isolation from other cores. The access to the flash is possible only at pre-defined time slots (see Section 3 for more details on the hardware architecture). Once we have the WCET for each function, a constraint programming problem is generated, which describes the scheduling problem to solve with OPL IBM [START_REF]CPLEX Optimization Studio[END_REF] (see Section 5 for more details). Once the scheduling problem is solved, the second for loop reads the off-line schedule computed by the solver. Finally, the local scheduler code is generated for each core.

Algorithm 1 WCET-aware mapping

1: procedure LLIR ExecutionModel (Config appli) 2:
get SPM size, SPM stack size, flash size end for Integration code for off-line schedule 16: end procedure

Off-line schedule and mapping

The program schedule is computed off-line with OPL. An OPL problem description generally consists of two parts:

• A .dat file, containing the input data. This is the file generated by wcc, which depends on the application and on the hardware description;

• A .mod file, containing the constraints and the script that generates the results. This file is independent of the actual program to analyze. It only specifies constraints related to the execution model and to general rules related to the kind of scheduling problem we want to solve.

The mapping problem formulation in OPL is detailed in Section 5. The solver computes for each function on which core it must be executed and when each of its AER phases must start executing.

Real-time executive

In this section we detail the hardware and software platform on which the execution of the final embedded program relies.

arm-based multi-core

wcc supports two types of processors: a single core Tricore and several arm-based architectures that range from 1 to 8 cores. In this work, we rely on the arm-based architecture that has initially been implemented by Timon Kelter [START_REF] Kelter | WCET Analysis and Optimization for Multi-Core Real-Time Systems[END_REF], which is depicted in Figure 4.

Each core is cadenced at 1Ghz and is associated with a private local SPM. Such a memory is better suited for predictable implementation than traditional cache memories, which generate implicit traffic to maintain cache coherency. The main memory is a flash memory and cores access it through a bus arbitrated with a TDMA (Time Division Multiple Access) protocol. The access is managed by the hardware and no special additional code must be added by the developer. Even if this architecture does not reflect an existing platform, it is still realistic because the next generation of embedded processors for control-command application is expected to share similar features.

Execution model

The structure of the wcc code on this platform follows an execution model detailed in [START_REF] Luppold | Bus-aware Static Instruction SPM Allocation for Multicore Hard Real-Time Systems[END_REF][START_REF] Oehlert | Practical challenges of ilp-based SPM allocation optimizations[END_REF]. To summarize:

• There is a unique function per core;

• The local SPM is partitioned in two parts: one for the instructions (section .text spm) and one for the stack (section .stack ). Everything else is stored in the flash;

• Only local addressing on local SPM is supported, meaning that core i cannot access the SPM of core j when i = j.

In this work, we extend wcc to implement the AER model [START_REF] Durrieu | Predictable flight management system implementation on a multicore processor[END_REF] on this platform. This is done as follows:

Rule 1: Several functions are sequenced in a non preemptive way on each core. No migration is allowed, meaning that a function will always execute on the same core. The sequence is computed off-line; Regarding rule 3, we assume that the code and data of the three AER phases can fit in the SPM permanently. Another solution would be to fetch the code of phase E during the A phase. This was more or less our approach in previous work [START_REF] Boniol | Deterministic execution model on cots hardware[END_REF].

az f vz f q f vz f vz f q f va f δ thc δ ec

Scheduler

Since the system schedule is computed off-line, and since we consider partitioned scheduling, the scheduler consists of a simple sequencer on each core. The sequencer is implemented in C, its structure is provided in Code 2.

A local table table stores the schedule computed off-line. The function fill table fills the table with the start time and the address of each function. In this example, vz filter and altitude hold are the two functions allocated on the core. They are initialized by calling all the [function name] init. At the end of the initialization phase, a synchronization barrier ensures that all cores start executing at the same time. In the infinite while loop, each sequencer scans its table, waits for the next function activation of the sequence and executes it.

Prelude AER code generation

In this section, we detail how the inputs for wcc are generated by the preludec compiler. The main focus of Prelude is the implementation of deterministic multi-rate communications. Initially, communications were implemented based on Sofronis et al. ideas [START_REF] Sofronis | A memory-optimal buffering protocol for preservation of synchronous semantics under preemptive scheduling[END_REF], using a shared memory approach. Prelude was later extended in two steps to support hardware platforms with distributed memories:

1. Puffistch et al. in [START_REF] Puffitsch | Off-line mapping of multi-rate dependent task sets to many-core platforms[END_REF] developed Interlude, an extension of Prelude, which allowed push and pull communications on the many-core Intel Single-chip Cloud Computer (SCC). These ideas have since been introduced directly in preludec with the option -extern buffers in the distribution 1.6.0. This option is generic and it is up to the designer to implement the read and write functions for a specific target.

2. The developers of lustrec and preludec eased the integration of C code generated by lustrec in the preludec imported node infrastructure.

In this work, we rely on these extensions and we adapt them to support the AER multi-phase task model.

Task code generation

For each lustre node f , lustrec generates two C functions: an initializing function f init, and a "step" function f step corresponding to the code executed by one repetition of f . The initialization function is scheduled only once, at the beginning of the system execution, while the step function is scheduled periodically. preludec wraps the function f step with code dedicated to the implementation of communications with other functions. The option -extern buffers generates a step function that includes code for acquiring inputs, then a call to the step function and then code for the restitution of outputs. In this work, we have introduced a new AER code generation option (-aer wcc). This mode splits the "wrapping" code in three separate A (acquisition code), E (step function), R (restitution code) functions. It also separates initialization code in a dedicated I function.

Communication buffers. Communication buffers are allocated in a separate file, that goes into the flash memory. An example is provided in Code 3. The section "buffer" contains buffer declarations. For instance, variable vz filter95 Vz f vz speed control104 Vz f is the communication buffer allocated for the communication of variable Vz f from vz filter to vz speed control. Note that preludec allocates a buffer of size 2, because vz filter executes twice faster than vz speed controller. preludec groups the addresses of all communication buffers in an array (buffer addresses).

Step functions can access to communication buffers through this array, using the buffer identifier generated in section "buffers id": values of the enumeration are declared in the same order as buffers, thus, for instance, buffer addresses[vz filter95 Vz f vz speed control104 Vz f id] is the address of vz filter95 Vz f vz speed control104 Vz f. ¦ ¥ AER functions. Code 4 shows the code generated by preludec for the function vz filter. preludec allocates variables to store the inputs and outputs of the function (variables locread and locwrite). These variables are local copies, allocated in the local SPM, of the global variables allocated in the flash memory. For instance, vz filter 95 fun Vz locread is a copy of the buffer for the communication from aircraft dynamics to vz filter. The copy is performed by a call to read val, during the A phase of vz filter (i.e. vz filter 95 A). Because the communication buffer contains two cells, the index variable Vz rcell is used to read alternatively from the two cells. Note also that we use the buffer identifier in read val to denote which buffer we want to access.

Similarly, vz filter 95 fun Vz f locwrite is a copy of the buffer for the communication from vz filter to vz speed control. The copy is performed by a call to write val, during the R phase of vz filter (i.e. vz filter 95 R). The function must write determines whether the current value must be copied to the buffer or not, because vz control only reads one out of two successive values produced by vz filter. Note that the function uses the local copies discussed above.

Local/global memory copies. Copies from/to the flash memory are performed by functions read val and write val. These functions are platform specific. For our arm-based architecture, since we only manipulate double values, we implemented a monomorphic version of these functions. The code for read val is shown in code 5. The function write val is very similar. A polymorphic version that relies on memcpy is also available in the Prelude distribution.

Off-line mapping problem

In this section, we describe the mapping problem formulation in OPL [START_REF]CPLEX Optimization Studio[END_REF]. Computing off-line mapping and scheduling with constraint programming is not new. The novelties here are twofold:

• We use the Conditional Time-Intervals that have been introduced into IBM ILOG CP Optimizer since version 2.0 for AER model. This approach, as described in [START_REF] Perret | Mapping hard real-time applications on many-core processors[END_REF], has been shown very efficient to solve non preemptive off-line mapping problems;

• We propose a procedure to reduce the window size which is very efficient in average.

In scheduling theory, the elements being scheduled are called tasks and jobs. In our case, each lustre function of the application corresponds to a task. Each periodic repetition of a task corresponds to a job.

Background on conditional time-intervals

Detailed definitions and descriptions can be found in [START_REF] Laborie | Reasoning with Conditional Time-intervals[END_REF] and [START_REF] Laborie | Reasoning with Conditional Time-Intervals. Part II: An Algebraical Model for Resources[END_REF]. The Figure 6 shows the classic way to represent a non preemptive task that could execute on two different cores with a conditional time interval-based approach. The formulation of this representation is done as follows. A task t 1 is associated with:

• an interval i 1 of length t 1 .wcet (not represented on the figure);

• two conditional intervals i 1,1 and i 1,2 .

To express that only one conditional interval will be present in the result (t 1 executes only on one core) and that it will be synchronized with i 1 (to determine the start time of t 1 and to impose the execution length to be the WCET), the constraint is:

alternative(i 1 , all(x ∈ 1,2)i 1,x )
The solver then computes the values of presenceOf(i 1,1 ), presenceOf(i 1,2 ) and startOf(i 1 ). In the Figure 6, the task executes on the second core.

Let us consider a second task t 2 . t 2 is associated with i 2 , i 2,1 and i 2,2 as for t 1 . If t 2 is also mapped to the second core, the execution of the two tasks must not overlap, indeed the CPU must be accessed in mutual exclusion. To ensure this constraint, OPL provides the notion of cumulative function, named pulse, that computes the sum of access quantity made by the different intervals. The Figure 7 shows the cumulative of two intervals. This schedule does not satisfy exclusive core access condition code and thus is not correct. We must add a constraint to ensure the exclusive core access condition. For instance, to ensure this on the second core, we add the following constraint: pulse(i 1,2 , 1) + pulse(i 2,2 , 1) ≤ 1 Such a formulation is really compact compared to usual formulation and also much more efficient thanks to the algorithms implemented in OPL. For the same problem with two tasks, in the usual formalization, the

i 1,2 t 1 .wcet startOf(i 1 ) =? endOf(i 1 ) =? t 1 .release t 1 .period presenceOf(i 1,2 ) = 1 presenceOf(i 1,1 ) = 0 i 1,1 Figure 6: Conditional time intervals i 1,2 i 2,2 pulse(i x,2 , 1)
Figure 7: Cumulative function of two intervals variables would be c 1 , c 2 ∈ {0, 1} representing on which core t 1 and t 2 execute; s 1 , s 2 ∈ {0, .., L} representing at which dates t 1 and t 2 start their execution. Then to ensure the mutual exclusion, the constraint would be:

c 1 = c 2 =⇒ (s 1 + t1.wcet ≤ s 2 ) ∨ (s 2 + t2.wcet ≤ s 1 )
Using =⇒ and ∨ in constraint programming is very costly and should be avoided as much as possible. However, since most of our problem relates to mutual exclusion or bounded quantity accesses, these constraints are needed.

Problem inputs

We can now express the mapping problem for AER synchronous programs executing on the arm-based architecture. The problem inputs are the hardware specification encoded as:

• nbCores the number of cores, SPMsize the size of the local SPM, StackSPMsize the size of the local memory area dedicated to store the stack, flashsize the size of the external memory;

• MAF is the length of the TDMA cycle on the bus, StartBusSlot[nbCores] is the beginning of the bus temporal slot allocated to each core on the bus in the MAF;

and the application description encoded as:

• TaskList the name of the application functions, TaskProps [TaskList] the attributes associated to each function. In particular, TaskProps[t].period gives the period of function t; TaskProps[t].wcet x provides the WCET for each phase x ∈ {A, E, R}; TaskProps[t].size x,y details for each phase x ∈ {A, E, R} the size of the section y ∈ {.data, .stack, .others}. The term others refers to all possible sections, except the .stack.

An OPL script first unrolls the jobs on the study window, the length of which will be discussed in the very next section. After this unrolling, we obtain:

• the set of Jobs,

• JobProps[Jobs] the attributes associated to each job. More precisely, JobProps[j].function gives the name of the function j is a job of; JobProps [j].release provides the release date of j; whereas JobProps[j].deadline is its deadline.

Study window

Since the system is composed of functions with different periods, we must compute the schedule on the hyperperiod H of the tasks (where H=lcm t TaskProps[t].period)). Unfortunately, this means that the size of the schedule H can theoretically be exponential in the number of tasks in the worst-case. In order to improve the resolution time, we try to reduce the size of the problem by computing a schedule on a shorter study window, such that we can deduce the schedule on H from the schedule on the study window. We propose to define this shorter window with length SWsize as: Since we do not know a priori the value of SWsize, we have to call the solver with different values of SWsize as long as the solver does not find a solution. In the current implementation, we successively try values from gcd to lcm. From what we have observed, SWsize is in general much lower than the hyper-period, but this is just an empiric knowledge. In the case of a geometric task set -that is when for all t 1 , t .period -SWsize is equal to the period of one of the tasks. This is commonly the case in controllers we studied, which simplifies the problem. Note that reducing SWsize reduces the size of the scheduling table, which reduces the execution time and memory footprint of the embedded program.

                   SWsize ≤ H SWsize H MAF SWsize ∀t ∈

Decision variables

The variables that must be computed by the solver are:

Constraints

The first constraint is directly related to the conditional intervals approach. We must associate each phaseX interval to a unique phaseX c and their timing positions must be synchronized.

∀j ∈ Jobs, alternative(phaseX[j], all(c ∈ Cores) phaseX c[j][c]) (1)
The next constraint is related to the execution order of the different phases of a job, that is A must be before E, which must execute before R.

∀j ∈ Jobs, endBeforeStart(phaseA[j], phaseE[j]) ∧ endBeforeStart(phaseE[j], phaseR[j]) (2)
Then we must ensure that each job will execute between its release date and its deadline.

∀j ∈ Jobs, startOf(phaseA[j]) ≥ JobProps[j].release ∧ endOf(phaseR[j]) ≤ JobProps[j].deadline (3)
All jobs of the same function must execute on the same core.

∀j ∈ Jobs, c ∈ Cores, X ∈ {A, E, R} presenceOf (phaseA c[JobProps[j].function][c]) == presenceOf (phaseX c[j][c]) (4)
There is no job execution overlapping on a core.

∀c ∈ Cores, j∈Jobs pulse( X∈{A,E,R} phaseX c[j][c], 1) ≤ 1 (5)
The sections stored in a given memory area do not exceed the size of this memory.

∀c ∈ Cores, t∈TaskList presenceOf(phaseA c[t][c]) ×( x∈{A,E,R} TaskProps[t].size x,.others ) ≤ SPMsize t∈TaskList presenceOf(phaseA c[t][c]) ×( x∈{A,E,R} TaskProps[t].size x,.stack ) ≤ StackSPMsize (6)
The acquisition and restitution phases must execute within the TDMA slot allocated to the core.

∀j ∈ Jobs, c ∈ Cores, X ∈ {A, R} presenceOf(phaseX c[j][c]) =⇒ ((startOf(phaseX[j]))mod MAF == StartSlotBus[c]) (7)
6 Case study

The code developed in wcc is around 1200 lines of C++ and the code developed in preludec is around 300 lines of ocaml. We applied the framework on Rosace and on the WATERS 2017 industrial challenge. [START_REF] Hamann | Demo abstract: Demonstration of the fmtv 2016 timing verification challenge[END_REF][START_REF] Hamann | Waters industrial challenge[END_REF].

ROSACE

The application is composed of:

• 1250 runnables, where a runnable is a piece of code that reads a set of labels (variables) and writes another set of labels. A runnable may be periodic or sporadic, in the sequel we only consider periodic ones;

• 10000 labels, that serve as the communication variables between runnables. A label can be read by several runnables but can only be written by at most one, which we call the producer of that label. A label that is not consumed by any runnable is an external output of the system (i.e. data sent to an actuator) and a label that is not produced by any runnable is an external input (i.e. data originating from a sensor). We have translated the Amalthea tasks description [START_REF] Amalthea | An open platform project for embedded multicore systems[END_REF] in Prelude, where each runnable becomes a node. details on the translation and semantics can be found in [START_REF] Forget | WATERS Industrial Challenge 2017 with Prelude[END_REF]. The Prelude program has been compiled with the framework. Since we do not have the internal code of the runnables, we simply created an empty C function for each corresponding node. The size of the Prelude code is about 1Mo, while the size of the C code is about 11Mo. Due to the size of the C code, we had to increase the size of the local SPM to compute the memory mapping because of our choice to store code in each processor SPM. In future work we plan to modify A functions to pre-fetch task code at task release. The execution times of the different steps are given in the table below. The mapping is done on 4 cores. Scade suite now comes with an integration of aiT and StackAnalyzer [START_REF] Ferdinand | Combining a high-level design tool for safety-critical systems with a tool for wcet analysis on executables[END_REF]. The processor model is quite generic but it provides the designer with a means to compare the memory/time cost of different programs.

We disabled most C compilation optimizations in our framework. Indeed, optimization are often avoided in safety critical embedded systems because they can break traceability and their correctness is difficult to prove. CompCert [START_REF] Leroy | Formal certification of a compiler back-end or: programming a compiler with a proof assistant[END_REF] is the first proved compiler that offers some optimization with a sufficient confidence to possibly be introduced in the design of future airplanes. CompCert has been assessed in the aeronautics context to implement a flight control system [START_REF] Bedin França | Formally verified optimizing compilation in ACG-based flight control software[END_REF]. The system is specified in Scade and the generated C code is then compiled for a Freescale MPC755 single-core, superscalar, pipelined microprocessor. The authors compared the performances between gcc and CompCert in terms of WCET and code size, all computed with aiT. The results were quite encouraging thanks to the optimization offered by CompCert since the WCET was in general 10% less than with a compilation with gcc and no optimization. The authors also summarize the expectation on a compiler regarding optimization from the DO 178: an optimization is acceptable as long as a verification provides enough coverage. Our purpose here is different since we target predictable execution on multi-core as a first objective. However, integrating safe optimization on predictable implementation would be a challenging issue worth to be considered in some future work.

The authors of [START_REF] Raymond | Timing analysis enhancement for synchronous program[END_REF][START_REF] Raymond | Timing analysis enhancement for synchronous program[END_REF] focus on the WCET analysis and optimization of synchronous programs. In terms of tools, they rely on gcc for arm processor, the e2c lustre compiler and otawa [START_REF] Ballabriga | OTAWA: An Open Toolbox for Adaptive WCET Analysis[END_REF] as static WCET analysis tool. They first remind the characteristics of the CFG (control flow graph) associated to a synchronous program: very simple structure mainly made of sequential basic blocks and nested conditionals; the calling tree of subfunctions is statically bounded. However, the designer may call external code or library for which a priori no assurance exists. In the implementation of Rosace for instance, we called a math library provided with wcc and for which aiT is able to compute the WCET. From a lustre program, the authors compute unfeasible paths by mixing model checking and IPET approaches in order to improve the quality of the WCET estimation. This work is also orthogonal to ours since it optimizes the WCET for a single core and a single function. Their solution could be used for the E phase of our execution model.

Predictable execution

Many works tackle the implementation real-time applications on multi-core platforms. In the family of softwarebased solutions to enforce the predictability, there are two main approaches: 1) interference-aware control software that manages, in a transparent way for the embedded application, the interference by sequencing the shared resources accesses; 2) application-aware control that consists in modifying the applications.

Since we work at the compiler level, we definitely belong to the second category which has the advantage to be more efficient, if the applied modifications are well realized. We already mentioned, in the introduction, the execution models [START_REF] Boniol | Deterministic execution model on cots hardware[END_REF][START_REF] Pellizzoni | A predictable execution model for COTS-based embedded systems[END_REF][START_REF] Durrieu | Predictable flight management system implementation on a multicore processor[END_REF]. Compared to those existing rules, the one proposed here is a direct reuse of standard ideas. The off-line computation with a constraint programming approach is also classic as for instance done in [START_REF] Puffitsch | Off-line mapping of multi-rate dependent task sets to many-core platforms[END_REF][START_REF] Gorcitz | On the scalability of constraint solving for static/off-line real-time scheduling[END_REF][START_REF] Becker | Contention-Free Execution of Automotive Applications on a Clustered Many-Core Platform[END_REF][START_REF] Silviu | Combined task-and network-level scheduling for distributed time-triggered systems[END_REF]. In [START_REF] Rihani | Response time analysis of synchronous data flow programs on a many-core processor[END_REF], the authors propose an off-line mapping of Scade/lustre programs on the Kalray MPPA to improve the WCET. In the continuation of the former work, Graillat and al. [START_REF] Graillat | Parallel Code Generation of Synchronous Programs for a Many-core Architecture[END_REF] have developed a parallelization framework of lustre programs on the Kalray MPPA that follows the off-line mapping computed before. Their idea is to manage the data-flow between distant nodes as an explicit communication, similarly to the push/pull communication of [START_REF] Puffitsch | Off-line mapping of multi-rate dependent task sets to many-core platforms[END_REF]. We reused the most state of the art modeling framework of conditional time interval as we initially performed in [START_REF] Perret | Mapping hard real-time applications on many-core processors[END_REF]. The main novelty here is to integrate all the steps in an automated way by generating the wrapping code from the synchronous compilers, by interacting with aiT and the OPL solver. With this framework, further interaction between the WCET analyzer, the off-line computation and the code transformation could be imagined.

In [START_REF] Luppold | Bus-aware Static Instruction SPM Allocation for Multicore Hard Real-Time Systems[END_REF], we considered a unique function be mapped on the arm-based architecture. We implemented a wcc-optimization that computed off-line a memory mapping for the instructions, i.e. some are stored in the local SPM while the rest is in the flash; in order to reduce the WCET value.

Time-predictable implementation of multi-threaded programs has been studied in [START_REF] Andalam | Predictable multithreading of embedded applications using pret-c[END_REF], for mono-core hardware, and later in [START_REF] Yip | The forec synchronous deterministic parallel programming language for multicores[END_REF], for multi-core hardware. However, the input language does not provide means to specify real-time constraints and thus ignores the real-time schedulability analysis problem.

Time-predictability is also the main concern of Precision Timed (PRET) machines [START_REF] Stephen | The case for the precision timed (pret) machine[END_REF] and many associated works, although authors work at a different level from us, since they focus on the hardware architecture.

Conclusion

We developed a framework that allows to produce time-predictable code for an arm-based multi-core platform, starting from lustre and Prelude input programs. The approach has been applied to two case-studies. The Rosace case-study is solved very efficiently. The WATERS 2017 industrial challenge is much more complex, but our framework is still able to handle it. We will pursue our experiments to detect potential slowdown but we are optimistic on the mapping resolution since it has been shown very efficient in our previous benchmarks in a different context.

For future works, we plan to focus on the following improvements. 1) Improving the semantics and capacities of the xml file. There are many equivalent ways to express the same input, which should be avoided; and on the other hand new properties cannot be added by the user, e.g. precedence constraints between functions, as it is required in control-command applications; 2) Defining a data-flow dedicated internal representation. Due to the specifics of synchronous programs, one further step towards a really efficient and adequate compilation could be to define a fully specific representation; 3) On-line scheduling. We are currently working on an on-line scheduling policy, as an alternative for the current off-line solution.

Figure 1 :

 1 Figure 1: Rosace architecture

-

  AER-based C code -XML tasks description preludec -aer wcc Executable with partitioned non-preemptive off-line schedule wcc -wcet aware mapping

Figure 2 :

 2 Figure 2: Framework overview

Figure 3 :

 3 Figure 3: wcc internal architecture

Figure 4 :

 4 Figure 4: arm-based multi-core architecture

Rule 2 :

 2 The function sections are allocated on the local SPM where they execute, except the exchanged data which are stored in the flash. Since there is no global addressing on the local memory, the flash is the only area where all cores can access; Rule 3: A function is decomposed in 3 AER phases. Data consumed by the function is first read during an acquisition phase A from the flash and copied to local variables. Then the function executes in isolation from other cores and without accessing any shared resources during the execution phase E. Finally, data produced by this function and consumed by other functions is copied to the flash during the restitution phase R; Rule 4: The A and R phases always occur during the TDMA slots of the core hosting the function. Example 1. The implementation shown in the Figure 5 fulfills the 4 rules of the execution model. The diagram shows part of a Rosace execution on two cores. vzcx stands for vz control in mode x ∈ {A, E, R}; vffx for vf filter; vacx for va control; ahe for altitude hold in mode E. The variables that are written or read in the flash are shown on the flash line.

Figure 5 :

 5 Figure 5: Dual core execution of part of Rosace

Code 3 (

 3 C external buffers). § ¤ // buffers double v z _ f i l t e r 9 5 _ V z _ f _ v z _ s p e e d _ c o n t r o l 1 0 4 _ V z _ f [2]; ... // buffers id enum { v z _ f i l t e r 9 5 _ V z _ f _ v z _ s p e e d _ c o n t r o l 1 0 4 _ V z _ f _ i d , ...} // table to access the buffers void * buffer_a d d r e s s e s [ P L U D _ B U F F E R _ N U M B E R ] = { ( void *) v z _ f i l t e r 9 5 _ V z _ f _ v z _ s p e e d _ c o n t r o l 1 0 4 _ V z _ f , ...}

Code 4 (

 4 C code generated by preludec). § ¤ // local copy of communication buffers static double v z _ f i l t e r _ 9 5 _ f u n _ V z _ l o c r e a d ; static double v z _ f i l t e r _ 9 5 _ f u n _ V z _ f _ l o c w r i t e ; ... // information on buffer sizes and communication patterns struct write_proto_t v z _ f i l t e r 9 5 _ V z _ f _ v z _ s p e e d _ c o n t r o l 1 0 4 _ V z _ f _ w r i t e ; struct write_proto_t v z _ f i l t e r 9 5 _ V z _ f _ v a _ s p e e d _ c o n t r o l 9 2 _ V z _ f _ w r i t e ; ... int vz_filter_95_I () { int _idx_i =0; v z _ f i l t e r 9 5 _ V z _ f _ v z _ s p e e d _ c o n t r o l 1 0 4 _ V z _ f _ w r i t e . wpref_size =0; ... return 0; } int vz_filter_95_A ( void * args ) { static int Vz_rcell =0; // copy from flash to local SPM read_val ( a i r c r a f t _ d y n a m i c s 7 3 _ v z _ v z _ f i l t e r 9 5 _ V z _ i d , ... , & v z _ f i l t e r _ 9 5 _ f u n _ V z _ l o c r e a d ); Vz_rcell =( Vz_rcell +1)%2; return 0; } int vz_filter_95_E ( void * args ) { // vz_filter (...) is the step function generated by lustrec v z _ f i l t e r _ 9 5 _ f u n _ V z _ f _ l o c w r i t e = vz_filter ( v z _ f i l t e r _ 9 5 _ f u n _ V z _ l o c r e a d ); return 0; } int vz_filter_95_R ( void * args ) { static int V z _ f _ v z _ s p e e d _ c o n t r o l 1 0 4 _ V z _ f _ w c e l l =0; static int instance =0; if ( must_write ( v z _ f i l t e r 9 5 _ V z _ f _ v z _ s p e e d _ c o n t r o l 1 0 4 _ V z _ f _ w r i t e , instance )){ // copy from local SPM to flash write_val ( v z _ f i l t e r 9 5 _ V z _ f _ v z _ s p e e d _ c o n t r o l 1 0 4 _ V z _ f _ i d , ... , & v z _ f i l t e r _ 9 5 _ f u n _ V z _ f _ l o c w r i t e ); ... return 0; } ¦ ¥ Finally, the execution phase vz filter 95 E simply consists in calling the step function generated by lustrec.

Code 5 ( 4 . 2

 542 Function read val). § ¤ void read_val ( int id , int cell , int size , void * addr ){ double * p = ( double *) addr ; * p = buffer_addres s [ id ][ cell ]; } ¦ ¥ Task set description preludec computes a clock for each node call during the clock calculus analysis[19]. The activation period, offset and deadlines of each node are directly derived from its clock. The production of the task set description as an xml file, as required by wcc, is thus a mere syntactic transformation step. The xml file lists the different A/E/R/I functions, along with their associated real-time attributes.

1 .

 1 the interval phaseX[j in Jobs] of length TaskProps[JobProps[j]. task].wcet x , which represents the execution of job j during the phase X ∈ A, E, R; 2. the interval phaseX c[j in Jobs][c in Cores], which is computed only if the job j runs on core c and which does not exist otherwise. When the interval exists, it is synchronized with phaseX[j].

  The symbol | means divides, thus MAF|SWsize is satisfied if the MAF divides SWsize. We need to take into account the MAF of the TDMA bus for computing the study window size. However since we can configure this parameter, we choose it wisely -for instance, such that M AF | gcd t (TaskProps[t].period). Function periods are usually much slower than hardware capacities, thus this constraint should be easily reachable. As a consequence, the MAF does not impact the study window size, the other constraints on the other hand really matter. From the constraints, in the best case, SWsize is equal to the gcd of the periods and in the worst to the lcm. Moreover, a study window is valid if we are able to compute a schedule: all active jobs, i.e. such that JobProps[j].release ≤ SWsize, must be scheduled in the study window, i.e. end their execution before SWsize.Example 2. Let us consider two functions t 1 and t 2 where name period wcet a wcet e wcet r .a t 1 .e t 1 .r t 2 .a t 2 .e t 2 .r

					TaskList,	either TaskProps[t].period SWsize or SWsize TaskProps[t].period
				a valid schedule can be found
	t 1	20	1	2	1
	t 2	100	2	5	2
	then on a single core it is sufficient to compute an off-line schedule on a study window of size 20, such as for
	instance:
	start time 0	1	3	4	6	11
		t 1

  2 ∈ TaskList either TaskProps[t 1 ].period|TaskProps[t 2 ].period or TaskProps[t 2 ].period|TaskProps[t 1 ]

  We have implemented Rosace in lustre and Prelude, then generated the AER-based code and compiled it with wcc. The execution times of the different steps are given in the table below.

	preludec	wcc phase 1 OPL	wcc phase 2
	0m0.114s 1m45.132s	0m0.601s 0m20.481s
	WATERS 2017 Industrial Challenge The second use case was proposed by Arne Hamann, Simon Kramer,
	Martin Lukasiewycz and Dirk Ziegenbein from Robert Bosch GMBH as the WATERS 2017 challenge

Table 1 :

 1 Tasks description

	Period	0.7ms 0.9ms	1ms	1.1ms 1.5ms 1.7ms 2ms	4.9ms 5ms
	Number of runnables 4	5	41	3	8	5	27	5	26
	Period	6ms	6.66ms 9.5ms 10ms 20ms 50ms 100ms 200ms 1000ms
	Number of runnables 2	146	6	303	306	45	246	14	43

This work could easily be adapted to rely on ec2c and poc from the Verimag lab[START_REF] Raymond | Efficient Compilation of a Declarative Synchronous Language:the Lustre-V3 Code Generator[END_REF] instead.

Acknowledgments

This work has been funded by the DGA in the context of a Stage ERE N • 2016.60.0004.00.470.75.01. The authors would like to thank Eric Noulard for his precious advice.