Maxime Perrotin

Konrad Grochowski

Marcel Verhoef

Damien Galano

Michal Mosdorf

Michal Kurowski

François Denis

Estelle Graas

Michał Mosdorf

Michał Kurowski

la diffusion de documents scientifiques

Keywords: SDL, ASN.1, AADL, MSC, VDM, Spark/Ada

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

When creating software in the context of critical embedded systems, one of the first tasks is to set up a development plan with a clear strategy focusing on the priorities set by the customer and/or the end user of the system.

Priorities have to take a number of elements into account, for example requirements related to:

• Development schedule • System safety • System dependability • Quality assurance and documentation • Quality of the software code for performance, optimization • Quality of the software code for readability, maintainability • Reuse and automation • etc.

In practice it is well known that all these requirements can not be covered at the same level of quality. Thus imposing a tight development schedule or low costs typically implies sacrificing some other aspects such as system analysis, robustness, testing or documentation. The question is then to know if it is possible to overcome this sacrifice and at what price. Is there any technology, tool, science that can support a software development process in such a way that perhaps by putting more effort in some places, it could improve significantly the overall software lifecycle as a side effect? TASTE is a platform that was created with this goal in mind, and is used to explore and disseminate advanced software technologies in order to be ready for future space missions.

What are the systems that we target?

Today's processes for the development of classical Earthorbiting spacecrafts are well mastered by our few European large system integrators: development is vastly done manually, but based on years of experience and reuse. The feedback we get is that each new satellite inherits from a lot of existing material and most of the time there is no need to change the approach while yet meeting most of the requirements seen above. It is therefore not these kind of wellestablished processes that are under focus: Europeanmade classical satellites have simple, qualified software which need no major upgrade according to industry.

On the other hand, new upcoming space missions such as formationflying systems, deepspace probes, robotic systems and next generation launchers usually are much more challenging. For example, do we know how to deal with distributed systems in space? Can we specify with lists of textual requirements all the complex scenarios to handle fault management? The companies that are involved in these new missions, now that the European Space Agency is open to many new countries, are more diverse today than in the past, and some have little background in the space domain and little software items to reuse. There are many areas where projects could benefit from dedicated tools and languages to approach new problems areas. For example, automatic code generation, which seemed underperforming and cumbersome a few years ago, is now mature and efficient enough to deal with software production. We need to characterize properly our expectations and find places where we could save time by automating repetitive tasks in order to put effort on more creative work.

TASTE provides means to achieve this goal. By looking at the needs first, the idea is to find and easily adopt a good combination of technologies to make concrete and quantifiable progress in a software development lifecycle. By relying on solid, well matured technologies such as ASN.1, SDL and AADL, and by keeping the eyes open on various programming paradigms, with a longterm and opensource support in mind, TASTE is making the synthesis of the past 20 years of work in the field of modelbased development, together with the recent trends in software programming using safer languages (VDM, Ada2012, Rust, F# and others). Of course, the results are not limited to space applications. Indeed, a safe and modern software development approach should in principle benefit all areas where the cost of a system malfunction is high and cannot be compensated by quick fixes after the deployment phase.

What have we done so far?

The development of TASTE started in 2008, and has been cofunded by ESA, industry, and universities. Many partners have participated and brought a lot of knowledge and material in the toolset. The overall strategy, vision and work plan is established by ESA.

In that context, a lot of work has already been achieved, and as a technology demonstrator, TASTE is already a fullfeatured set of tools, that goes very far in several areas of software development and deployment. The tool contains:

• a userfriendly entry point, containing a graphical editor for capturing a system architecture using the AADL language, and a state machine editor implementing partly the SDL language [START_REF] Opengeode | [END_REF] Fig. 1

TASTE userfriendly GUIs

• a full, commercialquality ASN.1 compiler dedicated to safetycritical systems, generating optimized Ada and C code, but also customizable documentation using template files • technology to glue heterogeneous languages: user code can be written in C, Ada, Simulink, SDL, VHDL • A custom integration of the Cheddar and Marzhin tools providing scheduling analysis of realtime systems • a lot of other tools that ensure a correctbyconstruction approach, allows to run simulations, perform regression testing and monitoring, create links to system databases, and much more.

Technical insight

Any complex system development requires the combination of many different disciplines to cover wide ranges of requirements. In terms of software, it is common to make use of a large number of technologies to address various aspects of the same problem:

• When coding manually, C and Ada are used to cover onboard software functionalities • Assembly language is sometimes used for lowlevel code and boot software The TASTE philosophy is to let application domain specialists spend most of their effort on their area of expertise and let tools automate the tedious parts which are of little interest to the system engineers. This means taking the wide variety of technology needed in practice, and putting everything together using tools, in order to ensure a system development that is correct by construction. It is not yet possible everywhere of course, but this is the goal we try to achieve. Correctness by construction covers different facets including this one: the provision of languages that are domainspecific allows to have one and only one way of addressing a problem and rely on the research done in the area to prevent at the source the risk of a bad software implementation. To illustrate this facet, consider the following examples:

• Embedded systems are fundamentally based on state machines. Systems react on their environment and behave depending on their current mode of operation. Using a language such as SDL [4] in TASTE gives the right syntax and the corresponding checkers to ensure by construction that the application focuses on the state machine and nothing else. • Data types: rather than reasoning in terms of physical encoding (size of integers, endianness), think about the range of values that are needed by the applications.

Even if it will need to be quantified, we expect that the generalized use of dedicated languages combined with tools automating software production, on the long term, will save a lot of time that is today spent on developing manually recurrent software functionalities.

User feedback

TASTE as a whole is only used by few companies. As shown in the case study presented in the next chapter, some of the TASTE components have already reached a high level of quality and usability and have proven excellent applicability to reallife projects ; but in this chapter we will discuss the braking factors and way forward to make sure that in the future, TASTE will be better known and used by many.

Taking the decision to adopt "unusual" technologies for a new project such as those present in TASTE (modelling tools, code generators, etc.) is always raising a number of questions: did anyone try them before in a similar context? is the technology really mature? what are the risks versus the benefits? is there a community of users? is there a commercial support available? is the underlying technology going to be supported on the long run? will someone be able to maintain the generated code in a satellite in 15 years? and by the way do we really want to automate the repetitive tasks that we have been doing manually for 30 years?

Even if some languages used in TASTE seem widely known in other domains of applications (e.g. ASN.1 or SDL are standard languages for telecommunication systems), they still represent small communities of users, and experience in computer science shows that technology is fragile and so pillars can collapse quickly. For example, UML that was called by many a "de facto standard" for modern software development is today declining fast and is abandoned by several tool vendors and users. From the point of view of nontechnical decision makers, it can be difficult to see the difference between fashionable technologies which are designed for marketing purposes and technologies with solid grounds that can really help if used properly.

When the decision is taken, there is of course a price to pay. One part of this price is related to the effort needed to make an efficient use of the selected technology. Assimilation of knowledge requires effort and time. The techniques we are considering (state machines, abstract data types, model checking, etc.) are scientifically sound and mature, but at the same time they are often not widely known or understood by industrial developers. As a consequence there are limited useful resources and user feedback available so it is often perceived that the investment is risky due to little immediately visible benefits.

It is relevant to note that in the past few years, a significant interest has raised in software communities towards the functional programming style (declarative style, immutability, recursion, monads, etc.) These techniques are quite ancient but were never considered seriously for inclusion in mainstream, imperative programming languages. And yet they got a sudden and apparently unexpected second life, and many of these techniques are now included as firstclass citizens in many languages (e.g. lambda functions). This simple example shows how software is a living and surprising area that is capable of evolving when technology proves an added value on real use cases.

One of the reasons ESA is investing a lot in software development is because exploration is part of its core mission. Exploration of space requires as a first step, as well as a side effect, exploration of new technology that is also useful on Earth. As a nonprofit technical organization, ESA is not tight to any single tool, language or technology. ESA therefore has the freedom and the possibility to progress with a consistent and long term vision, taking the time to assess tools, make the right choices, and deliver results that do not depend on an immediate hit in market places.

ESA is looking at many possible ways of improving software development and in addition to TASTE has created projects named: SAVOIR and OSRA (trying to establish "reference architectures" of systems) COMPASS (exploring the fault detection mechanisms) EDS (modelling device driver interfaces) and a few others

In order to help these technologies get a chance to be used in operational projects and fly on future missions, ESA is working together with the European space industry to harmonize research and development initiatives and make communities talk together. Many technologies are driven by experts who get stuck in their area due to difficulty to have a global picture of the end user needs, to the lack of networks, connections with other research areas, or simply resources. For example, scientists who create formal methods usually have little time or interest in implementing end user interfaces that yet would be a key to make their results visible and usable by nonexperts. ESA is capable of creating these missing links, animate working groups, experiment and disseminate tools, and that is the chosen direction, now that the level of trust in what tools like TASTE can do allows to go a step further.

Case Study PROBA3 Coronagraph Instrument Software

PROBA3 is a mission devoted to the inorbit demonstration of precise formation flying techniques and technologies for future ESA missions. It will fly an instrument named ASPIICS (Association of Spacecraft for Polarimetric and Imaging Investigation of the Corona of the Sun) as primary payload, making use of the formation flying technique to form a giant coronagraph capable of producing a nearly perfect eclipse, and allowing to observe the sun corona closer to the rim than ever before. The coronagraph system is distributed over two satellites flying in formation (approx. 150 meters apart). The so called Coronagraph Spacecraft(CSC) carries the camera and the so called Occulter Spacecraft(OSC) carries the sun occulter disc.

Fig.4 PROBA3 formation flying overview and orbit.

The proposed PROBA3 Coronagraph System (ASPIICS) will be the first space coronagraph to cover the range of radial distances between 1.08 and 3 solar radii where the magnetic field plays a crucial role in the coronal dynamics, thus providing continuous observational conditions very close to those during a total solar eclipse, but without the effects of the Earth's atmosphere. ASPIICS will combine observations of the corona in white light and polarization brightness with images of prominences in the He I 5876 Å line.

ASPIICS will provide novel solar observations to achieve the two major solar physics science objectives: to understand physical processes that govern the quiescent solar corona, and to understand physical processes that lead to coronal mass ejections and determine space weather ( [START_REF]Design status of ASPIICS, an externally occulted coronagraph for PROBA3[END_REF]).

The PROBA3 coronagraph optical design follows the general principles of a classical externally occulted Lyot coronagraph. The external occulter, hosted by the Occulter Spacecraft, blocks the light from the solar disc while the coronal light passes through the circular entrance aperture of the Coronagraph Optical Box (COB), accommodated on the Coronagraph Spacecraft (CSC).

COB, its control devices, and some other mechanisms form the Coronagraph Instrument. Following case study describes usage of some TASTE tools in development of Coronagraph Instrument Software (CISW).

CISW main responsibility is to integrate and control other instrument's subassemblies in order to achieve some level of autonomy from spacecraft, including automatic execution of all observation related operations.

It is common that one of the most important part of software design is its interface, but in this situation (combining multiple subsystems into one single interface visible from main platform system) it is even more crucial to ensure proper integration of CISW with satellite, by enforcing consistency of data definitions between requirements, documentation and final implementation.

TASTE addresses those issues using language for modelling of data called ASN.1. This language was designed to ensure endtoend data consistency: from a single description of data structures, tools can guarantee by constructions that semantically equivalent representations exist at any point in time in:

• software code,

• software documentation,

• system databases, • test scripts.

It is also a well known standard, used for years in telecommunications, with various other tools available. Using this language it was possible to easily translate communication data related CISW requirements, like ones visible on Fig. 5 into ASN.1 model (Fig. 6). Such model is readable even by nonprogrammers and provides short step between textual requirements and verifiable model.

Fig.6 ASN.1 description of some of the TC sent to CISW by the satellite platform

Although this model provides information only on logical components of data, it can easily be extended to describe physical representation. ASN.1 itself contains some standard encoding rules, like GSER, PER etc. It makes creation of data representation model very easy just information about used encoding standards for already provided ASN.1 data models is needed. Yet in some situations, like with CISW, when some enforced encoding rules are outside of ASN.1 scope, standard solutions are not enough. Fortunately TASTE provides another language, ACN, which was designed for ESA with purpose of describing encoding rules for ASN.1 defined structures [START_REF]ASN.1 and ACN[END_REF].

Fig. 7 ACN encoding rules for TC described in ASN.1.

Figure 7 shows, how previous ASN.1 model can be enhanced into complete data representation model by including of ACN encoding rules. With that addition, model contains enough information to be a source for generated detailed documentation, or encoding and decoding procedures for production code.

In CISW development the ASN.1 compiler named asn1scc [START_REF]ASN.1 and ACN[END_REF] was used, which started as part of TASTE (and it is still included in it) but now it is a standalone tool. It is being used to ensure consistency between ASN.1 model (based on requirements), flight and testing code (some C functions generated from model), and required software interface documentation (partially generated from model). Consistency is achieved by treating ASN.1 and ACN model files as source code with asn1scc calls being included in build process. Same files are also used to generate documentation (Fig. 8), which will become part of Interface Control Document (ICD) required document, which shall allow other components' providers to interface with CISW. ASN.1 and ACN files will be included in that document as attachments (together with generated C header files), allowing their reuse by document receivers. DMT allows to create Python and SQL (among many others) bindings for structures described in ASN.1. In CISW testing SQL bindings are mostly used to log and later analyze telemetry reported by working software. Each received message can be stored in database, in decoded form, allowing execution of complex queries for example to calculate statistic of reported housekeeping parameters. Work needed to enable SQL bindings was minimal, assuming Python bindings already existed. With them many additional tools (including analytical) can be used by developers. At this moment they're used for manual tests, but probably, together with code development, some automatic integration tests will be created and connected to internal verification test suite.

Python bindings turned out to be an essential help in development process. Basic bindings come at zero costs, but embedding them in build process, providing some utility functions and glue code for additional modules required some moderate amount of work, but at this moment it seems it was a justifiable invest.

Fig. 9 Example of testing capabilities available via Python bindings.

Figure 9 shows how simple testing complex capabilities of CISW becomes with tests written in Python. All encoding and decoding is done by bindings generated by TASTE. Only connection methods were implemented by hand. Additional gain is that this test can be used with many different real connections starting from unit tests, where whole CISW is embedded inside tests executable (no real connection is used), through connecting to simulator and ending with real serial connection to development board with uploaded CISW. This way the same test can be used by developer on his/her machine and for integration tests with real hardware. Such capabilities greatly enhance both development speed and code quality, which is a rare combination, worth additional work.

Working with TASTE proved that one of its biggest advantages is that it is a completely open source project. For example, at some point it turned out, that C code generated by asn1scc produces some warnings in older versions of C compiler. Those warnings were superfluous and not present in newer versions of compiler, but old version was required by CISW target platform toolset. As CISW team aims at warning free code, this could become an issue, yet it was easily fixed by making a simple change in asn1scc (renaming some generated variables names). Not only it was possible ad hoc due to open source nature of TASTE, it was also easy to provide that change back to community and current version has this issue already fixed.

CISW is still being developed, so it is hard to predict how much impact TASTE will finally have on this project, but at this moment it proved to contain useful engineering tools, which can greatly help in assuring quality, safety and maintainability of code. Those tools are more than just technology demonstrator. Without them development process could not be at the same level of advancement at this point in time and they became its crucial parts. There are other efforts in industry to cover some of these areas. Tools for system engineering, user requirement notation, use case maps etc., are all of interest for the future of the TASTE approach.

Conclusion and future

Fig. 10 Overture showing coverage information after a validation experiment TASTE was created with the objective to develop software with a more scientific mindset than the classical editcompiledebug approach. To go further in that direction, some work is being done for example with formal methods, in particular the suite of VDM languages [START_REF]VDM and the Overture project[END_REF][START_REF] Fitzgerald | Collaborative Design for Embedded Systems Comodelling and Cosimulation[END_REF]. It offers a very powerful approach to specification and implementation of software; it is used in several industrial areas but is mostly unknown to the space community. In the spirit of functional languages, but not limited to that paradigm, it provides a rich and compact syntax to express complex requirements. It forms the basis for formal analysis as well as pragmatic support for testing and validation. On the other hand it offers interactive prototyping and testing, proof support and model checking, which is well suited to the verification of properties when using domainspecific languages. Combining all these technologies in a consistent way might help making a real step forward in the quality of software. This approach to modelbased systems engineering tries to build upon the results from the domain of cyberphysical systems of systems, as promoted by the DESTECS INTOCPS project [START_REF]The DESTECS project[END_REF][START_REF]The INTOCPS project[END_REF]. In this project, we couple abstract continuous time models of the environment, specified in Bond graphs, with discrete event models of the controller (spacecraft) using VDM, which allows validation of system properties very early in the lifecycle, for example by means of 3D visualisation, as is shown in Figure 11. Currently, an early prototype is available where SDL models in TASTE, specifying the reactive systems behavior in terms of state machines, are enriched with VDM models in Overture [START_REF]VDM and the Overture project[END_REF] to express the algorithmic parts of the system behavior, whereby ASN.1 is used as the vehicle to exchange data types between these formal techniques.

Fig. 11 Multidomain cosimulation of a Mars rover using Overture, developed in DESTECS [START_REF]The DESTECS project[END_REF]

Fig. 5

 5 Fig. 5 Example of requirements for CISW TC.

Fig. 8

 8 Fig. 8 Documentation (in HTML format) generated from ASN.1.This functionality alone proves usefulness of ASN.1 modelling with TASTE tools, but, as usual, it turns out that once model is prepared a lot of new possibilities of its usage appear. CISW developers decided to use asn1scc and other TASTE Data Modelling Tools (DMT) in their internal software verification process, to ensure higher code quality. At first asn1scc was used to generate encoder and decoder unit tests based on data model. Those tests help achieve high code and functionality coverage with close to zero additional development costs. Still, highly regarding code (product) quality, development team decided to invest some time to create own test framework based on possibilities provided by TASTE.


Soukayna M'sirdi

Wenceslas Godard

Marc Pantel

A Multi-Core Interference-Aware Schedulability Test for IMA Systems, as a Guide for SW/HW Integration

Keywords:

 to propose a sufficient schedulability test that is adapted both to IMA systems and heterogeneous multi-core platforms. We then exploit this test to guide the design space exploration during the SW/HW integration phase, to select a partition-to-core allocation so that all deadlines are met despite the existence of hardware interference.

I. INTRODUCTION

A. IMA Applications

Modern avionic software systems are designed according to the Integrated Modular Avionics (IMA) architecture model, where (i) applications are defined as one or several software partitions; (ii) several partitions can share the same hardware resources, provided that constraints on time and space isolation are respected between each partition. Such isolation requirements are imposed for safety reasons, to prevent the propagation of a fault that happened inside a specific partition, to all other partitions in the software embedded in a system.

IMA software is organized in two layers: at the top level, a schedule is set in advance to plan the executions of the partitions in a TDMA-like fashion. To do so, activation offsets and time windows are allocated to each partition. We refer to this top level schedule as the global schedule of the system. Within the boundaries of the time window of a given partition, a local scheduler dynamically executes the software tasks inside each partition, usually according to fixed priority preemptive policy. The local scheduler operates with no knowledge about the global schedule. In the other hand, the global schedule has to suit the tasks needs, in the sense that the sizes of the partitions time windows must adapt to the tasks running during these time interval. In this paper, we compute the size of a partition's time window such that the task with the lowest priority level only executes once per window. How we compute the activation offsets of the time windows is out of the scope of this paper though.

During the integration phase of a system design, the allocation of the software platform onto the hardware platform is done, as well as the generation of a valid static global schedule. Setting in advance the global schedule enables to enforce an execution plan that has been verified and validated first. In particular, the global schedule must fit the needs of the local schedule inside the time window of each partition, and always ensure the respect of every deadline defined in the entire system. To verify and validate the global schedule, a formal proof of correctness, such as with static timing analysis, is the preferred choice for certification authorities.

B. Multi-Cores and Inter-Task Interference

In multi-core processors, all cores have simultaneous access to shared resources, through shared interconnections. All the requests made to one resource cannot be processed at the same time, which results in waiting delays at runtime. Such interference between tasks of different partitions, simultaneously executing on different cores, significantly extend the execution times of the tasks, and thus, the sizes of the time windows of the partitions. Since these interference delays may lead to deadline violations, they must be bounded during timing analysis.

However, the sharing level implied by multi-core environments leads to an explosion of the number of possible situations to consider to find the Worst Case Execution Times (WCET) of the tasks, so that static timing analysis at code level on multi-core is quite difficult and not solved today. On the other hand, the electronic market is evolving so fast that single-core processors will soon become obsolete, and will not be produced anymore. Avionic system designers will then have no choice but to move to multi/many-core designs. This represents a major challenge for IMA systems, since no consolidated approach to guide the transition of IMA applications from single-to multi-core platforms has been put forward so far.

C. Contributions

In this paper, we propose a framework for automated integration and timing analysis, of legacy IMA software on multi-core processors. To do so, we first present a sufficient schedulability test that is interferenceaware, and compatible both with IMA applications and heterogeneous multi-core processors. The test is based on an extension of the response time analysis presented in [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF], and computes safe bounds on inter-task memory interference.

As a second contribution, we exploit the resulting IMA, multi-core interference-aware response time analysis, in an optimization framework to automate the SW/HW allocation and scheduling analysis during the system integration phase. The schedulability test is used as a guide to perform design space exploration, and to find an optimized partition-to-core mapping. The optimization criteria we rely on is the minimization of the total workload of the system. By exploiting such an interference-aware schedulability test inside the allocation search, the solution is guaranteed to preserve the feasibility of the final system, despite the additional delays that might appear due to resource sharing.

Finally, our framework enables to produce bounds for the tasks Worst-Case Response Times (WCRT), as well as for the inter-task memory interference. Such bounds are crucial to formally prove the feasibility of the system, but also to determine the minimum requirements for the time window of each partition, which is mandatory in order to set in advance a valid scheduling plan of the global system.

D. Paper Outline

The paper is organized as follows: section I introduces IMA systems, our problem statement and contributions. Section II gives some insight on the integration process and avionic requirements. Section III gives an overview of the state of the art related to our work. Section IV presents our system model. Section V then presents our extension of the interferenceaware response time analysis to IMA and multi-core contexts. Section VI presents the allocation process implemented in our framework. Section VII presents the implementation and results of our work, and section VIII finally concludes our paper.

II. AVIONICS SYSTEMS

A. IMA Systems Integration

During the integration phase of a system design, the software platform is allocated to the hardware platform. The person in charge of this task is called the system integrator. Software functions are usually designed by one or several different suppliers, and are delivered to the system integrator before the beginning of the integration phase. As tasks are scheduled dynamically, their schedule is not set in advance, but each supplier must have verified and validated the schedulability of the tasks of each delivered partition. The job of the system integrator is then to take care of the global schedule, by computing the size and activation offset of the time windows of each partition. We consider legacy code, which means the schedulability analysis performed by each supplier has been verified for singlecore environments. Thanks to the sufficient test we present in this paper, the tasks schedulability is verified again during the integration phase, to take into account the fact that partitions will be running in parallel, by including additional inter-task and inter-partition interference delays due to sharing the main memory.

One schedulability test that may be used is the response time analysis, which leads to the computation of a bound on the WCRT of each task.

After the production of WCRT bounds, the integrator is able to assess the minimum size required for the time window of each partition: the window must be large enough for the tasks inside the considered partition to complete their execution, even in the worst-case. Once all sizes have been set, the integrator decides of activation dates for the beginning of each time window, starting from the instant when the system is switched on. IMA partitions are periodic, i.e. a time window must be reserved for each partition at a periodic rate. We consider this information as implying not only a period, but also an implicit deadline per partition, equal to the period, since each partition must be assigned a window before its next periodic activation. As a consequence, one important step of the integration process is to verify that, for each partition, time window sizes and activation dates match the periodicity of the partition. If it is not the case, the integrator must consider another SW/HW allocation, for instance by increasing the number of embedded processors for instance. The integrator is likely to have to try different SW/HW allocations before finding a configuration that complies to the requirements of all the described steps.

Eventually, the chronograph resulting from the global schedule consists in the pattern that will be repeated cyclically on the system, for as long as it is switched on. This pattern is also called the major frame. In this paper, we do not address the schedule generation activity of the integration phase.

B. Avionics Requirements

Final validation of avionic systems is done through a thorough certification process, shepherded by various regulations and recommended practices (like [START_REF]Aerospace Recommended Practice ARP4754 -Guidelines For Development Of Civil Aircraft and Systems[END_REF], [START_REF]Software Considerations in Airborne Systems and Equipment Certification[END_REF] for instance). In 2014, the Certification Authorities Software Team (CAST) submitted a first position paper regarding multi-core processors [START_REF]Multi-core Processors[END_REF]; static, assymetric scheduling is recommended, as it enables to reuse existing code without modification, and since global scheduling would require further proofs and analyses when looking for certification. CAST encourages the privatization of shared resources as much as possible. This goes in the sense of IMA needs, where the more private to each partition are the resources, the better it is. As a consequence, we assume the main memory and shared caches are partitioned into areas private to each core. This reduces the number of inter-core interference to consider: dividing shared cache levels into areas private to each core suppresses inter-core cache interference, as tasks on different cores are unable to evict each other's data. However, partitioning the main memory into core-private areas does not suppress inter-core interference, as long as the memory controller is still shared by the cores. Because all requests cannot be handled simultaneously by the controller, it results in waiting delays at runtime, and thus, intercore interference, even in the case of a main memory privatized at core level. In this paper, whenever we mention main memory interference, we actually refer to the inter-core interference due to sharing the memory controller.

To be in line with CAST multi-core study: (i) we consider static partitioned scheduling for partitions: each partition is statically assigned to a core, where it will be activated from the beginning till the end of the life cycle of the system; (ii) main memory and shared caches are partitioned at core level. However, some avionic functions might implement inter-partition communications. In such cases, we assume memory banks are exceptionally shared, between the two partitions concerned; these banks store the shared data.

III. STATE OF THE ART

In the literature, no consolidated approach to guide the transition of IMA applications from single-core to multi-core platforms has been put forward so far, so the problem is still open. To our knowledge, our work is the first to combine, inside one approach for the allocation search: (i) an interference-aware multi-core schedulability test; (ii) the computation of a maximum bound for memory interference per task; (iii) the computation of a maximum bound for the WCRTs of the tasks taking interference into account. In addition, our approach is also the first to consider, at the same time: (i) IMA architectures: tasks are defined inside partitions, which implies additional activities and verifications to be handled during software integration, like the computation of the sizes of the time windows of the partitions; (ii) the possible heterogeneity of the platform: in heterogeneous multi-cores, the execution duration of a piece of code depends on the core it is executed on: as a consequence, each task has one execution time in isolation per core.

Table I summarizes the characteristics of related work. The main characteristic of our contribution is the joint management of the allocation and scheduling analysis, with interference considerations. To our knowledge, only [START_REF] Paolieri | IAˆ3: An interference aware allocation algorithm for multicore hard real-time systems[END_REF] and [START_REF] Giannopoulou | Mapping mixed-criticality applications on multi-core architectures[END_REF] handle these two activities at the same time. However, the interference-aware schedule generated in [START_REF] Paolieri | IAˆ3: An interference aware allocation algorithm for multicore hard real-time systems[END_REF] relies only on a selection of measured execution times of the tasks when running simultaneously with each other, thus no safe bound on interference per task is produced. In [START_REF] Giannopoulou | Mapping mixed-criticality applications on multi-core architectures[END_REF], model checking is performed to obtain a reliable schedule, and thus safe bounds on tasks worst-case interference. However the author makes strong assumptions on the hardware architecture, which are currently verified only in the Kalray MPPA multi-core COTS [2], and neither the heterogeneity nor the IMA environment are taken into account. In [START_REF] Bradford | Exploring the design space of ima system architectures[END_REF] the interference-aware schedule is produced after data path analysis thanks to a detailed hardware model of the platform, which implicitly leads to interference bounds. The work presented in [START_REF] Kritikakou | Distributed run-time WCET controller for concurrent critical tasks in mixed-critical systems[END_REF] relies on runtime monitoring to dynamically adapt a scheduling plan, thanks to regular comparisons of the remaining time available for each task before its deadline, and its theoretical remaining execution time required to finish, computed in isolation at observation points. Thus no bound on task interference is given, and the correctness of the final schedule is more difficult to prove. In [START_REF] Sebastian | A generic and compositional framework for multicore response time analysis[END_REF], the authors propose an interference-aware multi-core response time analysis that takes into account inter-task interference due to sharing access to the DRAM, cache and bus resources. The framework does not implement any automatic allocation search process though, and is applicable neither to heterogeneous platforms, nor to IMA software architectures. Eventually, the IMA architecture is only considered in scheduling analyses, and except for the work in [START_REF] Bradford | Exploring the design space of ima system architectures[END_REF], the heterogeneity is considered only for the allocation search without interference issues.

IV. MODEL OF THE SYSTEM

Let N p and N t respectively denote the total number of partitions and tasks of the software platform, and N c the number of cores of the multi-core processor of the hardware platform. Tasks are denoted as τ i , and are ordered by their unique priority levels i: τ i has a higher priority than τ j if i is smaller than j. We model tasks as

a vector τ i pC i , D i , T i , H i q with C i pC 1 i ... C Nc i q and H i pH 1 i ... H Nc i q.
In the vector C i , each C k i is the worst-case execution duration of τ i when running in isolation on the core k. The C k i parameters can be deduced from static WCET analysis of the code, with tools like OTAWA [START_REF] Ballabriga | OTAWA: an open toolbox for adaptive WCET analysis[END_REF] for example. Similarly, H i gives the maximum number of data requests to the memory that τ i can issue depending on its core assignment; a bound on each element of H i can be extracted after static code analysis. T i is the period of τ i , and D i its deadline.

We model partitions as a vector π i pE i , P i q, where E i is the size of the time window to be reserved for π i , and P i is the period of π i . As explained in the introduction, we compute E i such that the task with the lowest priority level only executes once per window. To ensure an accurate time window size, E i is computed after the response time analysis, to guarantee a window large enough for the tasks to complete their execution in the worst-case:

di, E i max τj partpiq pR j q (1)
where partpiq contains the tasks belonging to the partition π i . Indeed, by definition, the WCRTs correspond to the situation where every task is preempted as many times as possible during its execution. In our case, we consider all tasks of a partition to be released simultaneously at the beginning of each time window. Priority levels are unique, i.e. two different tasks cannot have the same priority level. As such, for a given partition, the task with the lowest priority level has been preempted as many times as possible by all other tasks of the same partition. As a consequence, if τ j is the task with the lowest priority level of π i , then R j accounts not only for the execution time of τ j , but also for the execution times of all other tasks of the partition. τ j is then the task with the biggest WCRT, and can be used to compute the required size of the time window of its partition as described in equation ( 1).

The task-to-partition mapping is defined by the matrix P ART as follows:

P ART ji 4 1 if τ i π j , 0 otherwise (2)
Inter-partition communications are modeled by the matrix M as follows:

M ij 4 1 if π i and π j exchange data, 0 otherwise (3)
Except for E i , all these parameters are given as inputs to our framework. Additional parameters are computed though. perform the scheduling analysis, the following variables are defined, for each task τ i : B i is a maximum bound on inter-task interference due to sharing the main memory; R i is the WCRT of the task; isopiq is the element C k i of the vector C i where k corresponds to the index of the core to which τ i has been allocated. These three sets of variables are computed automatically by our framework during schedulability analysis, as will be explained later in this paper.

To perform the allocation search, we implement in our framework the matrix a, defined as follows:

a ij 4 1 if π j is allocated to core i, 0 otherwise. (4)
Eventually, to ease the explanations of the interference mathematical model, we also introduce the following sets: partpiq contains the tasks belonging to the partition π i : partpiq tτ j , P ART ij 1u coreppq contains the tasks belonging to the core p: coreppq tτ i , a pj 1, τ i partpjqu

V. IMA RESPONSE TIME ANALYSIS

A. Definition

The response time analysis first computes the WCRTs R i of the tasks τ i , and then, compares the results with the corresponding deadlines: tasks are schedulable if and only if R i is smaller than D i . In non-IMA, singlecore systems, R i is computed as the fixed-point solution of the following iterative equation, defined by M. Joseph and P. Pandya [START_REF] Joseph | Finding response times in a real-time system[END_REF]:

R k 1 i C 1 i @j, τj hppτiq R k i T j C 1 j ( 5
)
where k is the iteration number and C 1 i is the execution duration of τ i in isolation. For the first iteration, R 0 i is set to C 1 i . The second term in (5) refers to the maximum waiting delay due to the preemption of τ i by tasks with a higher priority. The set containing such tasks is denoted

hppτ i q.
B. Transposition to IMA, Multi-Core Environments 1) Multi-Core: In equation ( 5), all tasks of the system are on the same single-core processor. In multi-core environments, the tasks are rather dispatched among the cores of the processor. In theory if interferences are ignored, the situation is equivalent to considering N c independent single-core processors, so that equation [START_REF]Aerospace Recommended Practice ARP4754 -Guidelines For Development Of Civil Aircraft and Systems[END_REF] can be easily reused: the set hppτ i q will then refer to the tasks of higher priorities that are mapped on the same core than τ i , since only the tasks on the same core as τ i could be able to preempt it. As a consequence, if τ i is mapped to core p: R k 1 i iso i @j,τ j Phppτ i q and τj coreppq

R k i T j iso j (6)
with iso i being equal to C p i by definition. To compute iso i during the WCRT analysis, the core on which τ i is allocated must be retrieved. However, in IMA architectures, tasks belong to partitions, and it is the partitions -not the tasks -that are assigned to a core. Thus, to compute isopiq: (i) the partition to which τ i belongs is identified first, (ii) the core to which the corresponding partition has been assigned is identified, and then (iii) isopiq is deduced as equal to the element of the vector C i corresponding to the core identified in the second step. The mathematical equation corresponding to the computation of isopiq is the following:

di, isopiq Np p1 P ART pi ¢ £ Nc ķ1 a kp .C k i (7)
Indeed, P ART pi will be non null only if π p is the partition to which τ i belongs; then, the term a kp will be non null only if π p is allocated to core k, which leads to the identification of the index k of the core on which π p , and thus τ i , is mapped, and then to the duration C k i . 2) IMA partitions: In IMA architectures, further refinement of equation ( 6) can be given, according to the two-level schedule. A task can be executed only within the time window of its partition. This implies that the only tasks susceptible to preempt τ i must belong to the same partition as τ i . As a consequence, equation ( 6) becomes: R k 1 i isopiq @j,τ j Phppτ i q and τj partpiq

R k i T j isopjq (8)

C. Main Memory Interference Model

As mentioned in section I-B, the response time analysis ( 5) is often compositionally augmented to consider additional latencies likely to appear in practice. In our case, we add to the response time analysis in equation ( 6), a bound B i of the maximum interference delay each task can suffer due to sharing the main memory:

R k 1 i isopiq @j,τ j Phppτ i q and τj partpiq R k i T j isopjq B i (9)
As shown in figure 1, the memory is divided into banks, and each bank is divided into columns and rows. When a request is treated by the memory controller, the bank to access is identified first, then the row. When a task issues a memory request, the waiting delay suffered before the request is satisfied depends on the order in which the pending requests are treated by the memory controller. We implemented the DRAM memory model presented in [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF], where a detailed model of intra-and inter-bank access delays is given, based on a realistic memory model implementing FR-FCFS (First Ready-First Come First Serve) protocol.

The approach in [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF] presents two computation methods, and chooses the minimum value of the two produced bounds for each task. The maximum bounds produced thanks to the two methods will be referred to as B i,method1 and B i,method2 respectively.

We present here the mathematical model of memory interference of [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF], as well as our modifications leading to our final response time analysis formulation. Due to lack of space, we will only give a brief description of the model, and for a more detailed explanation, interested readers are invited to read [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF].

1) Method 1: Request Driven Approach: In the request driven approach, the maximum delay suffered by a request on one core is assessed. To do so, two types of interference are considered: inter-and intrabank interference.

For a request req issued by one core p, the worst case situation happens when: (i) every other core issued a request just before req; (ii) none of these requests targets the same memory bank as req; (iii) the treatment of each of these requests take the longest latency Fig. 1: Model of Memory Banks possible, l max -which happens when neither the previous bank, nor the previous row were accessed just before, and the type of the request is always different than the preceding one. The computation of l max is explained in detail in [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF], and depends on standard DRAM timing parameters that can be found in the DRAM datasheet (see table 1 of [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF] for instance). As a consequence, the inter-bank interference delay for a request issued by the core p is:

RD inter p @q,qpand sharedpp,qq∅ l max (10)
where sharedpp, qq is the set of memory banks shared by the cores p and q. In our model, the sets sharedpp, qq can be deduced from matrices a and M . In particular, sharedpp, qq is empty only if no partition on core q is sharing a memory area with any partition on core p. This translates into the terms a pi , a qj and M ij being equal to zero for all partition π i belonging to p and all partition π j belonging to q. As a consequence, the emptiness of sharedpp, qq can be assessed in our model as follows:

psharedpp, qq ∅q

£ Np i1 Np j1 a pi ¢ a qj ¢ M ij 0 (11)
Equation ( 10) is the inter-bank interference delays, in the case where no request to the same bank as req was produced. In the case where requests to the same bank as req are issued, the longest interference delay for req to be serviced happens when: (i) all the other cores q that share access to the same bank as core p emitted a request before req; (ii) all these requests concern access to a different row; (iii) a memory reordering is happening. If L is the row-conflict service time, to open a row before accessing a column, then the worst-case delay per such request is L RD inter q . The intra-bank interference delay suffered by req issued by the core p is thus:

RD intra p reorderppq
@q,qpand sharedpp,qq$∅ pL RD inter q q (12) As for l max , L depends on standard DRAM parameters that can be found in the memory's datasheet (see [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF] for a detailed description). Reorderppq computes the delay of req due to the reordering effect (see [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF] for a detailed description). Following the same reasoning than in the previous paragraphs, sharedpp, qq is non empty only if there exists a partition on core q that is sharing a memory area with a partition on core p. This translates into the terms a pi , a qj and M ij being both equal to one for at least one partition π i belonging to p and one partition π j belonging to q. As a consequence, the emptiness of sharedpp, qq can be assessed as follows:

psharedpp, qq $ ∅q £ Np i1 Np j1 a pi ¢ a qj ¢ M ij $ 0 (13
) Finally, the total maximum interference delay a request originating from the core p can experience is equal to:

RD p RD inter p RD intra p (14)
Each task τ i of core p having H p i requests to issue, the total maximum interference delay directly caused by the issuing of these requests is bound by

H p i ¢RD p .
Tasks being preemptible though, the cost of memory requests of tasks with higher priorities has also to be accounted for. Therefore, the bound on τ i 's memory interference is defined as follows:

B i,method1 H p i ¢RD p @j,τ j Phppτ i q τj partpiq R k i T j H p j ¢RD p (15
) 2) Method 2: Job Driven Approach: In the second method, the author of [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF] focuses on how many interfering memory requests are generated during the execution of a task. The maximum number of requests generated by a core p during a time interval t, A p ptq, depends on the number of generated requests by its tasks that are executed during that same time interval:

A p ptq ḑτicoreppq t T i H p i ( 16
)
As an IMA environment, during the execution of τ i , only the tasks of the same partition as τ i are eligible to emit requests for a given core. Thus the maximum number of requests that core p can generate during the execution of τ i is:

A p pt i q ḑτjpartpiq t i T j H p j ( 17
)
where t i is the time interval during which τ i is executed.

Once the maximum number of memory requests generated during a given time interval has been expressed thanks to the definition of A p , one can express interand intra-bank interference delay imposed on a core p during a time interval t, respectively:

JD inter p ptq @q,qpand sharedpp,qq∅
A q ptq ¢ l max (18)

JD intra p ptq @q,qpand sharedpp,qq$∅ pA q ptq ¢ L JD inter q q (19) Finally, to consider the maximum memory interference delay τ i can suffer, equations ( 18) and ( 19) compute the elapsed time between the beginning and the end of the execution of τ i . To produce a bound that is safe in the worst-case situation, the time interval to consider is R i . As a consequence, if τ i is allocated on the core p, then the maximum bound for the memory interference it can experience during its execution is given by: B i,method2 JD inter p pR i q JD intra p pR i q (20) D. Final Definition of R i and B i Methods 1 and 2 being about the computation of maximum bounds, B i is set to the less pessimistic of the two:

B i min pB i,method1 , B i,method2 q (21)
Eventually, the final formula to compute safe bounds on the WCRTs to perform the analysis is given in equation [START_REF] Bradford | Exploring the design space of ima system architectures[END_REF], where B i is computed according to equation (21).

VI. ALLOCATION PROCESS

During the allocation process, the system integrator decides on which processor each partition will be executed. In the case of assymetric scheduling on a multi-core processor, the integrator should decide on which core each partition will be allocated. An allocation then refers to a partition-to-core mapping, each partition being supposed to run on the same core from the beginning till the end of life of the system.

After an allocation has been chosen, the system integrator then sets a global schedule for each core of the multi-core. To do so, the integrator first computes the size of each partition time window, and then sets an offset for the activation of each window inside the major frame of each core. The size of a time window depends on the tasks supposed to run within its boundaries: the window should be large enough for all these tasks to complete their executions. The offset of a window should be chosen so that the end of the window is before the beginning of the next period of the partition.

If these conditions are verified, the resulting global schedule on each core are considered to be valid, as well as the partition-to-core allocation that led to such schedules. If on the contrary, it is not possible to find a valid schedule for at least one core of the multi-core, another allocation must be selected. The allocation phase is thus important, since the validity of the computed global schedules depends on it.

We propose to automate the SW/HW allocation process of the design phase of a system. To do so, we perform an exhaustive search for a valid allocation using constraint programming. The constraints represent the scheduling requirements of the system. To be able to do so, we rely on equation [START_REF] Bradford | Exploring the design space of ima system architectures[END_REF] to guide the search. Figure 2 summarizes our exploration process: a)

Step 1: the first step consists in choosing an allocation, in order to evaluate if it is a potential solution for the SW/HW integration. The allocation is chosen automatically by the framework, among all the possible combinations. Eventually, all allocations will be evaluated during the exploration process. Step 2: The second step represents an early verification that each partition window can end before the next period. This cannot be verified with certainty before knowing the activation offsets in the global schedule, nor before computing the tasks WCRT with equation ( 9). However, if one window happens to be larger than the period of the corresponding partition, then the selected allocation could never lead to a valid global schedule. As a consequence, we add the following constraints, to help the early rejection of such invalid allocations:

di, E i ¤ P i (22)
where E i is computed according to equation (1), and each R i with equation [START_REF] Sanjoy | Partitioning real-time tasks among heterogeneous multiprocessors[END_REF]. If this condition is not respected, the search process goes back to step 1 and a new allocation is chosen. c) Step 3: If step 2 is successful, R i and B i are computed for all tasks thanks to equations ( 9) and (21).

d) Step 4: The schedulability of the tasks in the multi-core allocation currently under evaluation is assessed. Tasks are schedulable if and only if:

di, R i ¤ D i (23) e)
Step 5: If step 4 is successful, we update the sizes E i of the time windows of the partitions: now that the interference-aware WCRTs of the tasks are available, we have to check that the time windows are still large enough in the worst-case, i.e. when the durations of the tasks are equal to their R i . If it is not the case, the window size of the corresponding partitions are increased accordingly thanks to equation [START_REF]Multi-core Processors[END_REF].

f) Step 6: The sixth step is based on the same principle as the second step, evaluated with the new E i values. If a window E i is larger than the corresponding period P i , it means that the currently assessed allocation may lead to deadline violations due to memory interference. The search process then rejects the currently evaluated allocation as invalid, and goes back to the first step to choose a new allocation. g) Step 7: If the sixth step is successful though, the current allocation is stored as a valid solution.

h) Step 8: The last step of the process is the selection of a solution among the valid allocations that were stored at step 7. We propose to do so according to an optimization criteria. Our framework selects the solution that minimizes the total workload of the system. We justify our choice by the fact that this parameter is a performance characteristic, but also because it is proportional to inter-task interference delays, which add up to the tasks executions. Because of these delays, (i) the extra time available before tasks deadlines are reached at runtime is drastically shortened, and (ii) the integrator is given less flexibility for the setting of a valid global schedule for each core in the considered allocation. The objective function we defined in our framework is the following:

minimize Nt i1 R i T i (24)
VII. IMPLEMENTATION

We implemented the optimization problem proposed in this paper, to assess the benefits that can be drawn from its use. To do so, we compared several qualities of the solution returned by our approach, to the solutions that would have been returned by "classic" approaches, meaning approaches without interference consideration. As explained before, no such classic approach exists, so we modified a copy of our optimization problem into a classic allocation problem: we remove the interference bound in equation ( 9), but we still compute it thanks to equation (21), to get the corresponding interference. The resulting process is referred to as "classic approach" or "interference-oblivious solving" in the rest of the paper. We implemented the optimization problem in CPLEX [START_REF]Cplex CP Optimizer[END_REF], that has been running on a computer with an Intel Core i7 2.20 GHz processor with 16Gb of RAM.

A. Presentation of the Case Study

We derived a case study from the report [START_REF] Locke | Generic avionics software specification[END_REF], which presents a specification of an avionics Mission Control Computer (MCC) system. No mention is made about an IMA architecture, nor about maximum numbers of requests to the main memory by the tasks, but for the sake of the analysis, (i) we consider each function to correspond to a partition, as if each one had been designed by a different supplier; (ii) we randomly generate H k i values for each task, ranging from low to intensive usage of the main memory, respectively 1 and 40 requests per microsecond [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF]. We also built the C i vectors by deriving the execution time in isolation given for each task in the report. The data corresponding to our case study is summarized in table II.

B. Tests Performed

As we will explain in detail in the next paragraphs, we performed two different experimentations. In both cases, our goal is to compare the solution returned by our framework with the solution that would have been provided by interference-oblivious processes. The comparison is made on the basis of the workload reduction achieved thanks to our framework, but also on the interference percentage, and the slowdown suffered by the tasks, in the selected solution.

1) Test 1: In the first test, the number of cores N c of the multi-core platform is the only variable parameter. We ask, both our framework and a classic allocation search, to find an allocation of the eight partitions described in table II on N c cores. The H i vectors used in the first test are described in table IIb. The maximum possible number of cores is eight, corresponding to the situation where each partition is allocated alone on a core. The result of the allocation search is either a valid SW/HW allocation, or the answer that there exists no valid solution for the number of cores considered. As we will explain in detail in subsection VII-C "Results", no solution was found for N c greater than or equal to five; that is the reason why the C i and H i vectors in table II only contain four elements each, and not eight.

2) Test 2: Since memory interference depends on the H i values, the comparison results and the realized performance gains are very data-dependent. To get a general appreciation of the optimization gain achievable thanks to our framework, we test different intensities of memory utilization by the tasks. Such a second test also enables to see the evolution of inter-partition interference with the intensity of the memory usage by the tasks. As mentioned earlier, memory utilization intensity varies approximately between 1 and 40 requests per microsecond per task. As a consequence in this second test, there are two variable parameters: N c and the vectors H i . We use data from table IIa but not from table IIb, and we build the vectors H i as follows instead, for all tasks τ i and all cores k:

H k i C k i pin µsq ¢ x, x t1, 10, 20, 30, 40u (25)

C. Results

For both tests, our framework was unable to find solutions for N c greater than 4. On the contrary, in the classic approach, the search always finds a solution, but after analysis of the output memory interference bounds B i , the solution appears not to be valid in reality: some bounds lead to actual WCRTs being bigger than the deadline of the corresponding tasks, which invalidates the feasibility of the selected solution. The difference between our framework and the classic approach being the interference consideration, we can draw the conclusion that our framework prevents from choosing allocations that, later on during the schedule planning phase, appear to be infeasible. This also implies that our work enables to reduce the time spent during the last phases of a system design. In terms of computation time, solutions were always found in less than 10 seconds with two cores, 62 seconds with three cores and 7 minutes with four cores.

1) Test1: Figure 3 shows the results of the first test. According to the figure, our framework always returns a better solution than the classic approach, the difference between the two solutions being more noticeable for three cores. We were able to show some significant performance enhancement, with up to 36.9% of workload reduction, 46.6% of interference reduction and 50.4% slowdown reduction.

2) Test 2: Figure 7 displays the results of the second test. The graphs on the left show the results corresponding to our framework, whereas the graphs on the right correspond to the solution with classic approaches for the allocation search. The same legend is used in all graphs, to ease results interpretation. In all runs performed, the solution found with our framework is better than with classic approaches, by allowing up to 39.6% workload reduction, 54.5% interference reduction and 44.4% slowdown reduction.

Eventually, for a given value of N c , one can see the evolution of workload, interference and slowdown depending on the intensity of memory usage by the tasks. All three parameters increase with the usage intensity. The only exception is for four cores in figures 4b and 5b: workload and interference obtained with x equal to 40 in equation ( 25) are respectively lower than with x equal to 30, and is quite close to the solution found by our framework. Memory interference can only increase with the number of memory requests, since tasks using intensively the main memory are more likely to suffer more from interference than the tasks that only perform a small number of requests to the memory per execution. This implies that the classic approach managed by chance to find an optimized solution for x equal to 40, but failed to do so for x smaller than 40. This can be considered as an expected observation, since the objective function (24) in classic approaches ignores the B i terms in the computation of the WCRTs.

Another remark for a given number N c can be made when we compare our framework to interferenceoblivious search. The speed of the increase of workload, interference and slowdown respectively is slower figures 4a, 5a and 6a than in figures 4b, 5b and 6b, which is an interesting quality for a system integrator. The difference of speed is more visible in the graphs of figures 4a and 5a than in figure 6a though. This is due to the fact that our optimization criteria is the workload reduction. In the future, it might be interesting to experiment multi-objective cost functions, to have multiple parameters guiding the search and solution selection.

VIII. CONCLUSIONS AND FUTURE WORK

In this paper we have presented a derivation of the response time analysis in [START_REF] Kim | Bounding memory interference delay in cots-based multi-core systems[END_REF] to adapt it to IMA systems and heterogeneous multi-core platforms. The resulting response time analysis gives a sufficient schedulability test for IMA applications in heterogeneous multi-core environments. We then proposed to reuse this schedulability test to guide the design space exploration during the SW/HW integration design phase of IMA systems. To do so, we formulated an optimization problem to perform a timing-aware SW/HW allocation search. On the two implemented tests, our results showed that our approach enabled a real performance gain, by achieving up to 54.5% workload reduction, 54.9% memory interference reduction, and 50.4% slowdown reduction at runtime. In the future, we plan on refining the interference model, in order to take more than just main memory interference into account.

Fig. 2

 2 Fig. 2: exploration process

Fig. 3 :

 3 Fig. 3: Results of the first test

Fig. 4 :Fig. 7 :

 47 Fig. 4: average workload per core (%)

TABLE I :

 I Summary of related work contributions

TABLE II :

 II Case Study Data