WO2017109386A1 - Procede hors ligne d'allocation d'un logiciel embarque temps reel sur une architecture multicontrôleur multicoeur, et son utilisation pour des applications embarquees dans un vehicule automobile - Google Patents

Procede hors ligne d'allocation d'un logiciel embarque temps reel sur une architecture multicontrôleur multicoeur, et son utilisation pour des applications embarquees dans un vehicule automobile Download PDF

Info

Publication number
WO2017109386A1
WO2017109386A1 PCT/FR2016/053578 FR2016053578W WO2017109386A1 WO 2017109386 A1 WO2017109386 A1 WO 2017109386A1 FR 2016053578 W FR2016053578 W FR 2016053578W WO 2017109386 A1 WO2017109386 A1 WO 2017109386A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
time
cores
architecture
multicore architecture
Prior art date
Application number
PCT/FR2016/053578
Other languages
English (en)
Inventor
Sylvain COTARD
Wenhao Wang
Benoit MIRAMOND
Fabrice CAMUT
Original Assignee
Valeo Equipements Electriques Moteur
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Valeo Equipements Electriques Moteur filed Critical Valeo Equipements Electriques Moteur
Publication of WO2017109386A1 publication Critical patent/WO2017109386A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs

Definitions

  • the present invention relates to an offline method of allocating software on a multicore architecture.
  • the invention also relates to a use of this method for embedded applications in a motor vehicle.
  • OS acronym in English Operating System
  • ECU Electronic Control Unit
  • the traditional issues of embedded operating systems are the time response capability (ie ensuring real-time determinism of applications) and scalability (ie maintaining the robustness of applications while adding more and more features).
  • multicore microcontrollers are seen as essential.
  • a multicore architecture can be seen as a set of cores operating in parallel in the same chip. Each heart can execute its own piece of code. Contrary to what happens in the use of multiple controllers, all cores share the same hardware components (power, bus, I / O, memory).
  • Such processors have appeared on the embedded market in recent years and are currently promoted by manufacturers such as Freescale (for example Cobra or McKinley types), Infineon (for example TC277 or TC279 in the AURIX family). , or Texas Instruments (eg the Tl Vision family), etc.
  • An application can be viewed as a set of software components that communicate with each other. If we take applications under AUTOSAR for example, these components are called Software Components (SWCs) and interact independently of a particular hardware platform thanks to an abstract environment called Virtual Functionnal Bus (VFB, that is to say " Virtual Functional Bus "). Each SWC contains one or more "runnables” (a word for AUTOSAR denoting a piece of code called “executable” by the skilled person). Executions of "runnables” can be programmed independently.
  • SWCs Software Components
  • VFB Virtual Functionnal Bus
  • the category of applications targeted by the present invention is that of the control / command applications (for example that relating to the engine control system, the passenger compartment, the chassis, the control modules of the advanced driver assistance systems, or ADAS in English terminology, acronym for "Advanced Driver Assistance System", etc.) for which strong real-time constraints and strict functional cooperation must be respected, even across the borders of the cores.
  • control / command applications for example that relating to the engine control system, the passenger compartment, the chassis, the control modules of the advanced driver assistance systems, or ADAS in English terminology, acronym for "Advanced Driver Assistance System", etc.
  • the inventive entity focused primarily on the first two issues.
  • the third problem can be treated in the same way by extending the constraints and cost functions used in the method of the invention.
  • Timing Architect For example, commercial tools such as Timing Architect or SymtaVision offer validation at the simulation level. From a user-provided allocation solution, these tools simulate a set of tasks deployed on the multicore architecture, and verify a set of constraints (for example real-time constraints, contention between the shared resources, etc.).
  • constraints for example real-time constraints, contention between the shared resources, etc.
  • the designer can analyze the Gantt chart of the sequencing of tasks, analyze the dependencies of the data, or even summarize the overhead of the communication load.
  • the allocation choice may still not be optimal
  • the inventive entity claims an invention based on the complete analysis of the software components and their interactions.
  • the AMALTHEA tool evaluates allocation solutions using cost functions. By applying a metaheuristic algorithm such as a genetic algorithm, the tool explores the solution space to find the best solution that satisfies the conditions of the predetermined cost functions.
  • a metaheuristic algorithm such as a genetic algorithm
  • the definition of the cost functions from the tool is mainly based on real-time criteria: the quantization metric for compliance with the system-level delay, the resource consumption and the system time for data communication ;
  • the present invention therefore aims to meet this need and concerns in particular the allocation of application components on cores.
  • the method comprises:
  • a first step of analyzing the dependencies of the application components generating an oriented graph comprising a first set of nodes formed by functional elements identifying with the application components or executables according to a level of granularity enabled by the operating system, and a second set of transitions between these functional elements;
  • a second step of distributing the functional elements on cores of the multicore architecture typically resulting from a current optimization of a cost function by the nodes and the transitions under predetermined constraints;
  • a fourth evaluation step of the current optimization calculating a distance to a predetermined objective and returning to the second step for an additional iteration of the second, third and fourth steps if this distance is greater than a predetermined threshold.
  • this current optimization is based on a metaheuristic algorithm.
  • the predetermined constraints include core load ratings, current load balancing of cores, and implementation strategies.
  • the cost function comprises criteria chosen from:
  • the estimation of the execution time of each of the functional elements is according to the invention a worst execution time, an average execution time or a probabilistic model.
  • the criteria can be determined in a Initial iteration of the second, third, and fourth steps using a single-core reference platform of multicore architecture.
  • the first step comprises:
  • a first phase in which, on the one hand, the nodes are each modeled by a first group comprising first parameters chosen from the execution time, a trigger mode, a first period, and in which, on the other hand, the transitions are each modeled by a second group comprising second parameters chosen from a weight based on a size of transmitted data, a second period of a producer;
  • a second phase of classification of the transitions according to a third group comprising predetermined classes chosen from a first class in which the transitions are periodic, a second class in which the producers or consumers are periodic, a third class without periodicity, a fourth class; in which transitions are invoked on an event;
  • the second step comprises:
  • a first phase of preparation transforming the oriented graph into an acyclic directed graph by means of a first operation of placing the nodes on a horizontal line, direct arcs being placed above this line and retrograde arcs being placed below in this same line of a second operation consisting in modifying an order of the nodes so as to form a succession of these nodes with a minimum cost of retrograde arcs, and a third operation of provisionally suppressing these retrograde arcs;
  • each arc is associated with a cost according to the classification and the data transfer rate.
  • the third step is a hardware target evaluation further comprising a measurement of execution times of the services used by communicating between the cores.
  • Input (B) are reference values of these criteria and Output (B) are current values of the criteria in the current iteration.
  • the invention also aims at using the offline method for allocating software on a multicore architecture described above for applications under a real-time operating system of the AUTOSAR type intended to be embedded in a motor vehicle.
  • FIG. 1 is a general representation of the method according to the invention
  • Figures 2a and 2b respectively illustrate a transformation of an oriented graph into an acyclic oriented graph in the method according to the invention.
  • FIGS. 3a and 3b respectively show an oriented graph of an application with modeling of the nodes by an execution time and a period, and a result of a dependency analysis for this application in the method according to the invention.
  • Figure 4 illustrates a two-core allocation obtained by the method according to the invention for the application shown in Figure 3a.
  • Figure 5 shows an oriented graph of another application showing data transfer rates between executables.
  • Figures 6 illustrates an analysis of the execution time of an executable.
  • Figures 7a and 7b show two examples of overall flow execution response times on one of the cores shown in Figure 4.
  • the software architecture 1 is compatible with the AUTOSAR standard; however, the off-line method of allocating software on a multicore architecture according to the invention is not specific to AUTOSAR.
  • a first step 2 of the method an analysis of the dependencies between the functional elements of an application is carried out.
  • a first dependency analysis tool implementing this first step 2 is based on a development environment dedicated to Java language applications (Eclipse). It makes it possible to analyze an application software by parsing the description files in .xml format (for example * .arxml files in an AUTOSAR context).
  • This first tool analyzes the characteristics of the application 1 in the following phases:
  • the software architecture 1 is modeled using a directed graph G (V,
  • V is a first set of nodes A, B, C, D, E, F, G, H formed by application components or executables (or " runnables "for AUTOSAR applications), and T is a second set of transitions between these functional elements.
  • a V node is modeled by an execution time, a trigger mode, a periodicity.
  • a transition T has a weight that depends on the size of the data exchanged, the periodicity of the executables that produce and consume these data a dimension of the graph G is optimized by the creation of buses between the nodes V.
  • - class 1 periodic T transition divided into three series S1, S2, S3 (Series 1: same second and third periods for the consumer and one producer, series 2: third generation period smaller than the second consumer period; third period of the producer greater than the second period of the consumer);
  • - class 2 producer OR consumer (exclusively) periodic divided into two series S1, S2 (Series 1: the producer is periodic, series 2: the consumer is periodic);
  • T-transitions invoked on events eg mode switching event, client / server operation.
  • AUTOSAR is the targeted operating system, two levels of granularity are allowed: analysis at the level of the SWC application components, or analysis at the runnable level. In all other cases, the analysis is done at the level of the application components, but in the case of AUTOSAR, this facility makes it possible to reduce the complexity of the analysis and consequently to reduce the time necessary to find a solution of allocation.
  • the first inputs 1 of this first tool performing the first step 2 of the method according to the invention are:
  • Real-time software (BSW or "Basic Software” in AUTOSAR) and a hardware abstraction layer of the multicore architecture (HW in AUTOSAR eg for the CAN bus, etc.) are not included in the analysis leading to an allocation solution, but only in the validation of the solution, where the impacts of the BSW basic software and the hardware abstraction layer HW are implicitly taken into account in measurements.
  • BSW Base Software
  • HW hardware abstraction layer of the multicore architecture
  • the first outputs of this first tool performing the first step 2 of the method according to the invention are:
  • the executable producer and the consumer executable the SWC application components that contain them and their associated execution environment (declination mode, their periodicity), and the transmitted data;
  • each transition T is classified in one of the classes C1 C2 C3 or C4 according to criteria of the execution environment for the executables producers and consumers;
  • the data information for each transition contains a data size, a unit of data, a data type and a data transfer rate;
  • Figure 5 shows an example of sequences with indication of classes and series of T transitions between nodes A, B, C, D, E, F, G, as well as data transfer rates in bytes per millisecond.
  • sequences identified serve to determine a global response time of execution of these sequences.
  • a second tool implementing the second step 5 of the method according to the invention performs an exploration of the design space (or DSE, acronym for the English expression "Design Space Exploration") of the oriented graph developed in the first step 2 to distribute applications in multicore systems.
  • design space or DSE, acronym for the English expression "Design Space Exploration”
  • the problem is formalized as a combinatorial optimization problem, which relies mainly on the definition of objective functions with respect to predetermined constraints.
  • the predetermined constraints 6 are static parameters which must be checked for each possible solution. These constraints 6 may take into consideration both real-time characteristics (for example the load of each core) and implementation strategies (for example, prohibiting the separation of a client and its server).
  • the cost function 7 is calculated from the following essential elements:
  • Execution time of each executable which is not constant at each execution.
  • An estimate of this execution time can be divided into three formats: a worst execution time, an average execution time or a probabilistic model;
  • the entries below correspond to feedback information of a fourth step of the method according to the invention, described below, from a previous iteration. Note also that these inputs can be determined at the time of an initial iteration, for example by using a software run analysis on a reference single core platform (on the same target). These results are then updated after iteration of the process steps.
  • the model of the application in order to calculate the overall response time of execution of sequences, the model of the application must be an acyclic oriented graph (or DAG, acronym for "Direct Acyclic Graph "in English terminology); the preparation of the oriented graph G consists in transforming the initial oriented graph into an acyclic oriented graph in the following manner:
  • optimization based on the acyclic oriented graph generated by the preceding preparation phase which involves an allocation of the nodes C, F, B, D, A, E of the graph G on the different cores of the multicore architecture; there are two degrees of optimization:
  • DSE Design Space Exploration
  • the optimization solution is evaluated by the cost function 7, and a search for the solution that minimizes the cost function can be performed by metaheuristic algorithms such as MOSA (acronym for "Multi-Objective Simulated Annealing", that is to say “Specific Analysis of Multi-Scale Objects”, or MOGA (acronym for "Multi-Objective Genetic Algorithm", c ie "Genetic Algorithm of Non-Dominated Sorting"), etc.
  • MOSA acronym for "Multi-Objective Simulated Annealing
  • MOGA acronym for "Multi-Objective Genetic Algorithm", c ie "Genetic Algorithm of Non-Dominated Sorting
  • the results of this second step 5 are integrated in the method for generating configuration files 8, 9 in the .xml format (or more precisely * .arxml in an AUTOSAR context):
  • a second configuration file 9 of the execution environment that is to say the actual configuration of the allocation determined by the method according to the invention.
  • a third step 10 of the process according to the invention the resulting solution 11 is evaluated at the end of the second step 5.
  • the input information of the validation could be constraints drawn from the specifications (already used in the second step 5 for allocation decisions of the application components 1), for example one of the inputs required in this second step 5 is the Execution time of executables, or more generally a specification file 12 in * cmm format describing imposed performances.
  • executable execution time can be calculated using real-time analysis on a single-core platform. For each executable, a T exe execution time distribution for a large number N of executions is calculated, and statistical results are provided (average execution time, minimum execution time, maximum execution time, deviation type, etc.). An example of such a distribution is given in Figure 6.
  • the execution time distribution of the executables is calculated on the multicore architecture for the solution obtained at the end of the second step at each iteration.
  • the impacts on the real-time behavior of the distribution are analyzed and taken into account for the following iterations.
  • a validation HIL (acronym for "Hardware In the Loop")
  • the results from the third step 13 are used to evaluate the performance of the solutions and update the input data of the second step 5 if additional iteration is necessary.
  • a feedback / update metric model for this assessment 16 is constructed by the following criteria (non-exhaustive list):
  • - executable execution time for each executable, the execution time can be modified; the overall load of multicore architecture needs to be optimized; the acceleration parameter is calculated for each distribution solution (how often is it possible to increase the performance with a multicore architecture compared to a single-core architecture).
  • the data access time can be modified especially for the service of the IOC channel
  • a distance 17 constructed on a set of criteria ⁇ for measuring a difference between reference values Enter (O) of these criteria and current values Output (O) of these criteria calculated from the results of the previous steps 10, 5 can be given by the expression:
  • This distance D is close to zero if the output criteria (O) calculated for the solution are close to the criteria entered (O).
  • the distance D is greater than a predetermined threshold D 0 , a return 18 is made to the second step 5, otherwise the solution is satisfactory and can be implemented 19, that is to say, embarked on a vehicle.
  • each node A, B, C, D, E, F, G, H represents an application component with an execution time C and a period T indicated by a pair (C, T) in FIG. the following figures.
  • a non-periodic component D is denoted (C, ⁇ ); for example, the node D is non-periodic,
  • the purpose of this example is to distribute the application on a two-core architecture 20, 21 shown in Figure 4, the two cores 20, 21 being identical.
  • first core 20 B ⁇ C ⁇ E ⁇ D;
  • second heart 21 A ⁇ F ⁇ H ⁇ G;
  • the nodes A and F are strongly connected because their periods (equal to 6) are identical; the nodes A and F will therefore be allocated to a first task 24.
  • the nodes B, C, and E are strongly connected because their periods are equal to 12; these nodes B, C and E are allocated to a second task 25.
  • the results of the third step can be used to evaluate the performance of the solutions and update the input data of the second distribution step.
  • the feedback / update metric such as the execution time of each node, a variable access time for transition T, or the overall response time of the sequences will be used to update the input data of the distribution for the next loop / iteration.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Le procédé comprend une première étape (2) d'analyse de dépendances entre des composantes applicatives (1) produisant un graphe orienté comportant un premier ensemble de nœuds formés par des éléments fonctionnels ou des exécutables, et un second ensemble de transitions entre les éléments fonctionnels;une deuxième étape (5) de distribution d'éléments fonctionnels sur des cœurs, résultant d'une optimisation courante; une troisième étape (10) de validation de l'optimisation courante calculant un temps d'exécution de chacun deséléments fonctionnels exécutés sur les cœurs; et une quatrième étape (16) d'évaluation de l'optimisation courante calculant une distance (D) à un objectif prédéterminé et effectuant un retour (18) à la deuxième étape pour une itération supplémentaire des deuxième, troisième et quatrième étapes si cette distance est supérieure à un seuil prédéterminé (D0).

Description

PROCEDE HORS LIGNE D'ALLOCATION D'UN LOGICIEL EMBARQUE TEMPS REEL SUR UNE ARCHITECTURE MULTICONTRÔLEUR MULTICOEUR, ET SON UTILISATION POUR DES APPLICATIONS EMBARQUEES DANS UN VEHICULE AUTOMOBILE
DOMAINE TECHNIQUE DE L'INVENTION.
La présente invention concerne un procédé hors ligne d'allocation d'un logiciel sur une architecture multicœur.
L'invention concerne également une utilisation de ce procédé pour des applications embarquées dans un véhicule automobile.
ARRIERE PLAN TECHNOLOGIQUE DE L'INVENTION.
De nos jours, des systèmes d'exploitations (ou OS, acronyme en terminologie anglaise de "Operating System") embarqués sont couramment utilisés dans les unités de calcul électroniques (ECU ou "Electronic Control Unit" en terminologie anglaise) de véhicules automobiles. En général, il revient à un système d'exploitation l'enchaînement des tâches, le traitement des interruptions, et la gestion des ressources.
Les enjeux classiques des systèmes d'exploitation embarqués sont la capacité de réponse temporelle (c'est-à-dire assurer le déterminisme temps réel des applications) et l'extensibilité (c'est-à-dire maintenir la robustesse des applications tout en ajoutant de plus en plus de fonctionnalités).
En ce qui concerne les applications dans l'automobile, les véhicules devenant autonomes et connectés, la complexité du logiciel s'accroît, et des standards tels qu'AUTOSAR (acronyme en terminologie anglaise de "AUTomotive Open System ARchitecture", c'est-à-dire "Architecture de Système Ouvert d'Automobile"), permettant de standardiser la conception des produits logiciels automobiles, conduisent également à une augmentation de la taille du code à embarquer.
De plus, avec l'arrivée de la norme ISO 26262, les systèmes d'exploitation embarqués sont de plus soumis à un nouvel ensemble d'exigences pour satisfaire aux contraintes de sûreté de fonctionnement. Le respect de ces contraintes nécessite des mécanismes logiciels de tolérance aux fautes spécifiques. Dans ce contexte, des microcontrôleurs multicœurs sont vus comme essentiels. Une architecture multicœur peut être vue comme un ensemble de cœurs fonctionnant en parallèle dans une même puce. Chaque cœur peut exécuter son propre élément de code. Contrairement à ce qui se passe dans l'utilisation de multiples contrôleurs, tous les cœurs partagent les mêmes composants matériels (alimentation, bus, E/ S, mémoires). De tels processeurs sont apparus sur le marché de l'embarqué ces dernières années et sont actuellement mis en avant par des fabricants tels que Freescale (par exemple les types Cobra ou McKinley), Infineon (par exemple le TC277 ou TC279 dans la famille AURIX), ou Texas Instruments (par exemple la famille Tl Vision), etc ..
Une application peut être vue comme un ensemble de composants logiciels qui communiquent entre eux. Si l'on prend les applications sous AUTOSAR par exemple, ces composants sont appelés Software Components (SWCs) et nteragissent indépendamment d'une plateforme matérielle particulière grâce à un environnement abstrait appelé Virtual Functionnal Bus (VFB, c'est-à-dire "Bus Fonctionnel Virtuel"). Chaque SWC contient un ou plusieurs "runnables" (vocable propre à AUTOSAR désignant un élément de code appelé "exécutable" par l'homme de métier). Les exécutions des "runnables" peuvent être programmées indépendamment.
Cette méthodologie de description permet aux développeurs et aux intégrateurs de concevoir logiquement une ECU. La catégorie d'applications visées par la présente invention est celle des applications de contrôle/ commande (par exemple celle concernant le système de contrôle moteur, l'habitacle, le châssis, les modules de pilotage des systèmes d'aide à la conduite avancés, ou ADAS en terminologie anglaise, acronyme de "Advanced Driver Assistance System", etc ..) pour lesquelles des contraintes temps-réel fortes et de strictes coopérations fonctionnelles doivent être respectées, même au travers des frontières des cœurs.
C'est la raison pour laquelle l'utilisation d'une architecture multicœur dans le domaine de l'automobile n'est pas triviale, dans la mesure où les applications cibles interagissent avec des systèmes physiques, et sont tenues par de strictes contraintes temps réel. Malgré des avantages indéniables en termes de performances, l'introduction des architectures multicœurs conduit à de nombreux problèmes:
- allocation du logiciel aux cœurs, c'est-à-dire l'allocation d'une composante logicielle à un des plusieurs cœurs;
- définition d'un ensemble des tâches dans le système d'exploitation et affectation puis séquencement des éléments fonctionnels aux tâches;
- distribution des variables dans les mémoires dans le cas d'architecture matérielle avec plusieurs niveaux de mémoires;
- synchronisation du flux de traitement entre les cœurs.
L'entité inventive a principalement porté son attention sur les deux premiers problèmes. Le troisième problème peut être traité de la même manière par extension des contraintes et des fonctions de coût utilisés dans le procédé de l'invention.
En ce qui concerne l'allocation hors ligne du logiciel, on connaît des procédés basés sur une analyse manuelle et sur une validation par simulation.
Par exemple, des outils commerciaux tels que Timing Architect ou SymtaVision proposent une validation au niveau de la simulation. A partir d'une solution d'allocation fournie par l'utilisateur, ces outils simulent un ensemble de tâches déployées sur l'architecture multicœur, et vérifient un ensemble de contraintes (par exemple les contraintes temps réel, la contention entre les ressources partagées, etc .).
Par l'utilisation d'un de ces deux outils, le concepteur peut analyser le diagramme de Gantt du séquencement des tâches, analyser les dépendances des données, ou encore faire la synthèse du temps système de la charge des communications.
Ces deux outils ont fait l'objet de demandes de brevets par leurs concepteurs, et leurs principes sont notamment décrits dans la demande internationale WO2012146406, et le brevet américain US6947868, respectivement.
La simulation est proche du modèle matériel réel et les résultats de l'analyse pourraient être une aide pour les modifications de l'allocation (proposée initialement par ces outils.
Ces outils sont des produits commerciaux, bien industrialisés, et pouvant être interfacés avec un standard logiciel tel qu'AUTOSAR, cependant:
- le choix d'allocation peut encore ne pas être optimal;
- l'aide fournie par ces outils pour l'étape d'allocation est limitée car elle nécessite de connaître par avance l'enchaînement des tâches devant assurer le respect des contraintes fonctionnelles. L'entité inventive revendique une invention basée sur l'analyse complète des composantes logicielles et de leurs interactions.
Il est également connu de l'entité inventive des procédés hors ligne d'allocation d'un logiciel basés sur des méthodes heuristiques, tels que ceux mis en œuvre dans les outils issus des programmes de recherche européens AMALTHEA et parMerasa (acronyme de "Multicore Execution Parallelized Hard Real-time Applications Supporting Analysability.").
Des méthodes heuristiques telles qu'évoquées ci-dessus sont décrites dans l'article de B. Miramond, J.-M. Delosme, « Décision guide environment for design space exploration », 10th IEEE Conférence on Emerging Technologies and Factory Automation, 2005.
L'outil AMALTHEA évalue les solutions d'allocation en utilisant des fonctions de coût. En appliquant un algorithme métaheuristique tel qu'un algorithme génétique, l'outil explore l'espace des solutions pour trouver la meilleure solution qui satisfait aux conditions des fonctions de coût prédéterminées. Cependant:
- la définition des fonctions de coût à partir de l'outil est principalement basée sur des critères temps réel: la métrique de quantification de la conformité avec le délai au niveau du système, la consommation des ressources et le temps système pour la communication des données;
- l'aspect lié aux séquences d'exécution, tel que les chaînes événementielles et les ordres d'exécution, n'est pas considéré.
L'outil du projet parMerasa prend la dépendance des composantes en compte, cependant :
- le temps système des communications entre cœurs n'est pas considéré par l'outil;
- seul les runnables d'une même tâche peuvent être exécutés en parallèle, dans le but de toujours assurer l'enchaînement des tâches dans le bon ordre. Cela ne permet pas de tirer profit du parallélisme offert par le multicoeur. Cet aspect est traité notamment dans l'article de Milos Panic, Sébastian Kehr, Eduardo Quihones, Bert Bôddeker, Jaume Abella and Francisco J. Cazorla, " RunPar: An Allocation Algorithm for Automotive Applications Exploiting Runnable Parallelism in Multicores," ACM International Conférence on Hardware/Software Codesign and System Synthesis (CODES), New Delhi, India, October 12-17, 2014.
De plus, aucun de ces outils issus des projets européens n'est encore industrialisé, et une mise en pratique dans un procédé industriel doit encore être évaluée.
Les problèmes d'allocations ont également été considérés par le domaine de la recherche académique. Dans l'article de A. Monot, N. Navet, B. Bavoux, and F. Simonot-Lion, " Multi-source software on multicore automotive ecus - combining runnable sequencing with task scheduling," IEEE Trans. Ind. Electron, vol. 59, no. 10, pp.3934-3942, October, 2012, les auteurs proposent un algorithme heuristique pour allouer des « runnables » AUTOSAR sur des cœurs. Dans les articles de H. R. Faragardi, B. Lisper, and T. Nolte, "Towards a communication-efficient mapping of Autosar runnables on multi-cores," IEEE 18th Conf. on Emerging Technologies & Factory Automation (ETFA), vol. 18, pp. 1-5, Spetember, 2013, et de S. E. Saidi, S. Cotard, K. Chaaban, and K. Marteil, "An ilp approach for mapping autosar runnables on multi-core architecutures," Proceeding of the 2015 Workshop on Rapid Simulation and Performance Evaluation: Methods and Tools, 2015, les auteurs modélisent le problème d'allocation à l'aide d'une approche ILP, acronyme en terminologie anglaise de « Integer Linear Programming », c'est-à-dire, une optimisation linéaire en nombre entier. Ces travaux, non industriels, ne considèrent que des contraintes temps réels, et ne ciblent pas les séquencements des traitements.il existe donc un besoin pour un procédé hors ligne d'allocation d'un logiciel sur les cœurs, assurant la configuration de l'ensemble des tâches et le séquencement des exécutables aux tâches et qui soit industrialisable.
DESCRIPTION GENERALE DE L'INVENTION.
La présente invention vise par conséquent à satisfaire ce besoin et concerne en particulier l'allocation des composantes applicatives sur des cœurs.
Elle a précisément pour objet un procédé hors ligne d'allocation d'un logiciel sur une architecture multicœur, ce logiciel étant compatible avec un système d'exploitation prédéfini comprend:
- des composantes applicatives;
- un environnement d'exécution;
- un logiciel de base temps réel fournissant des services aux composantes applicatives;
- une couche d'abstraction matérielle de l'architecture multicœur.
Selon l'invention, le procédé comprend:
- une première étape d'analyse des dépendances des composantes applicatives produisant un graphe orienté comportant un premier ensemble de nœuds formés par des éléments fonctionnels s'identifiant aux composantes applicatives ou bien à des exécutables selon un niveau de granularité permis par le système d'exploitation, et un second ensemble de transitions entre ces éléments fonctionnels;
et en outre dans une itération courante:
- une deuxième étape de distribution des éléments fonctionnels sur des cœurs de l'architecture multicœur, celle-ci résultant typiquement d'une optimisation courante d'une fonction de coût par les nœuds et les transitions sous des contraintes prédéterminées;
- une troisième étape de validation de cette optimisation courante calculant un temps d'exécution de chacun des éléments fonctionnels exécutés sur les cœurs au moyen du logiciel de base et de la couche d'abstraction matérielle;
- une quatrième étape d'évaluation de l'optimisation courante calculant une distance à un objectif prédéterminé et effectuant un retour à la deuxième étape pour une itération supplémentaire des deuxième, troisième et quatrième étapes si cette distance est supérieure à un seuil prédéterminé.
Dans le procédé selon l'invention, cette optimisation courante est basée sur un algorithme métaheuristique.
Selon l'invention, les contraintes prédéterminées comprennent des charges nominales des cœurs, un équilibrage de charges courantes des cœurs, et des stratégies d'implémentation.
Selon l'invention encore, la fonction de coût comprend des critères choisis parmi:
- une utilisation de l'architecture multicœur;
- un temps système de communication entre les cœurs;
- un temps de réponse global d'exécution d'enchaînements des éléments fonctionnels;
- une estimation du temps d'exécution de chacun des éléments fonctionnels;
- un temps d'accès de données;
L'estimation du temps d'exécution de chacun des éléments fonctionnels est selon l'invention un pire temps d'exécution, un temps d'exécution moyen ou un modèle probabiliste.
Selon l'invention toujours, les critères peuvent être déterminés dans une itération initiale des deuxième, troisième et quatrième étapes en utilisant une plateforme monocœur de référence de l'architecture multicœur.
Dans le procédé selon l'invention, la première étape comprend:
- une première phase dans laquelle, d'une part, les noeuds sont modélisés chacun par un premier groupe comprenant des premiers paramètres choisis parmi le temps d'exécution, un mode de déclenchement, une première période, et dans laquelle, d'autre part, les transitions sont modélisées chacune par un deuxième groupe comprenant des seconds paramètres choisis parmi un poids fonction d'une taille de données transmises, une seconde période d'un producteur;
- une deuxième phase de classification des transitions selon un troisième groupe comprenant des classes prédéterminées choisies parmi une première classe dans laquelle les transitions sont périodiques, une deuxième classe dans laquelle les producteurs ou des consommateurs sont périodiques, une troisième classe sans périodicité, une quatrième classe dans laquelle les transitions sont invoquées sur un événement;
- une troisième phase d'analyse des taux de transfertdes données, comprenant à la fois les accès en production et en consommation;
- une quatrième phase d'analyse de séquences de communications et d'extraction de flux de ces données présentant des taux de transfert identiques.
Dans le procédé selon l'invention encore, la deuxième étape comprend:
- une première phase de préparation transformant le graphe orienté en un graphe orienté acyclique au moyen d'une première opération consistant à placer les nœuds sur une ligne horizontale, des arcs directs étant placés au dessus de cette ligne et des arcs rétrogrades étant placés au dessous de cette même ligne d'une deuxième opération consistant à modifier un ordre des nœuds de manière à former une succession de ces nœuds avec un minimum de coût d'arcs rétrogrades, et d'une troisième opération consistant à supprimer provisoirement ces arcs rétrogrades;
- une deuxième phase réalisant l'optimisation courante en se basant sur le graphe orienté acyclique et la fonction de coût;
- une troisième phase de génération de fichiers de configuration du système d'exploitation et de l'environnement d'exécution.
Selon une autre caractéristique, chaque arc est associé avec un coût en fonction de la classification et du taux de transfert des données. Dans le procédé selon l'invention toujours, la troisième étape est une évaluation sur cible matérielle comprenant en outre une mesure de durées d'exécution des services utilisés en communiquant entre les cœurs.
Dans le procédé selon l'invention enfin, dans la quatrième étape la distance est donnée ar l'expression:
Figure imgf000010_0001
où Θ sont les critères de la fonction de coût, Entrée(B) sont des valeurs de référence de ces critères et Sortie(B) sont des valeurs courantes des critères dans l'itération courante.
L'invention vise également une utilisation du procédé hors ligne d'allocation d'un logiciel sur une architecture multicœur décrit ci-dessus pour des applications sous un système d'exploitation temps réel de type AUTOSAR destinées à être embarquées dans un véhicule automobile.
Ces quelques spécifications essentielles auront rendu évidents pour l'homme de métier les avantages apportés par le procédé selon l'invention par rapport à l'état de la technique antérieur.
Les spécifications détaillées de l'invention sont données dans la description qui suit en liaison avec les dessins ci-annexés. Il est à noter que ces dessins n'ont d'autre but que d'illustrer le texte de la description et ne constituent en aucune sorte une limitation de la portée de l'invention.
BREVE DESCRIPTION DES DESSINS.
La Figure 1 est une représentation générale du procédé selon l'invention
Les Figures 2a et 2b illustrent respectivement une transformation d'un graphe orienté en un graphe orienté acyclique dans le procédé selon l'invention.
Les Figures 3a et 3b montrent respectivement un graphe orienté d'une application avec une modélisation des nœuds par un temps d'exécution et une période, et un résultat d'une analyse de dépendances pour cette application dans le procédé selon l'invention.
La Figure 4 illustre une allocation sur deux cœurs obtenue par le procédé selon l'invention pour l'application montrée sur la Figure 3a.
La Figure 5 représente un graphe orienté d'une autre application montrant des taux de transfert de données entre exécutables.
La Figures 6 illustre une analyse du temps d'exécution d'un exécutable.
Les Figures 7a et 7b montrent deux exemples de temps de réponse global d'exécution d'enchaînements sur un des cœurs montrés sur la Figure 4.
DESCRIPTION DU MODE DE REALISATION PREFERE DE L'INVENTION.
Dans le mode de réalisation préféré de l'invention, montré sur la Figure 1 , l'architecture logicielle 1 est compatible avec le standard AUTOSAR; toutefois le procédé hors ligne d'allocation d'un logiciel sur une architecture multicœur selon l'invention n'est pas spécifique à AUTOSAR.
Dans une première étape 2 du procédé, on effectue une analyse des dépendances entre les éléments fonctionnels d'une application.
Etant donné la grande sensibilité des applications cibles à un ordre d'exécution de ces éléments fonctionnels et la faible proportion de parallélisme existante, la répartition d'applications du domaine de l'automobile entre de multiples cœurs nécessite une analyse des dépendances particulièrement fine.
Un premier outil d'analyse des dépendances implémentant cette première étape 2 est basé sur un environnement de développement dédié aux applications en langage Java (Eclipse). Il permet d'analyser un logiciel d'application en faisant l'analyse syntaxique des fichiers de description au format .xml (par exemple les fichiers *.arxml dans un contexte AUTOSAR).
Ce premier outil analyse les caractéristiques de l'application 1 dans les phases suivantes:
1 - Remodelage de l'architecture logicielle 3
- l'architecture logicielle 1 est modélisée en utilisant un graphe orienté G(V,
T), dont plusieurs exemples sont montrés sur les Figures 2 à 5, où V est un premier ensemble de nœuds A, B, C, D, E, F, G, H formés par des composantes applicatives ou bien des exécutables (ou "runnables" pour des applications AUTOSAR), et T est un second ensemble de transitions entre ces éléments fonctionnels. Un nœud V est modélisé par un temps d'exécution, un mode de déclenchement, une périodicité. Une transition T a un poids qui dépend de la taille des données échangées, des périodicités des exécutables qui produisent et consomme ces données - une dimension du graphe G est optimisée par la création de bus entre les nœuds V.
2 - Construction de statistiques 4 sur les transitions T entre les nœuds V Chaque transition appartient à l'une des quatre classes C1 , C2, C3, C4 suivantes:
- classe 1 : transition T périodique divisée en trois séries S1 , S2, S3 (Série 1 : mêmes deuxième et troisième périodes pour le consommateur et un producteur; série 2: troisième période du producteur plus petite que la deuxième période du consommateur; série 3: troisième période du producteur plus grande que la deuxième période du consommateur);
- classe 2: producteur OU consommateur (exclusivement) périodique divisée en deux séries S1 , S2 (Série 1 : le producteur est périodique; série 2: le consommateur est périodique);
- classe 3: aucune périodicité;
- classe 4: transitions T invoquées sur des événements (par exemple événement de commutation de mode, opération client/ serveur).
Si AUTOSAR est le système d'exploitation ciblé, deux niveaux de granularités sont permis: analyse au niveau des composantes applicatives SWC, ou analyse au niveau des "runnables". Dans tous les autres cas, l'analyse est faite au niveau des composantes applicatives, mais dans le cas d'AUTOSAR, cette facilité permet de réduire la complexité de l'analyse et par conséquent de diminuer le temps nécessaire pour trouver une solution d'allocation.
3 - Analyse des taux de transfert des données entre les exécutables.
4 - Analyse de séquences de communications (extraction des flux de données appartenant à la classification C1 S1 ).
Les premières entrées 1 de ce premier outil réalisant la première étape 2 du procédé selon l'invention sont:
- les composantes applicatives (SWCs dans AUTOSAR);
- les relations qui structurent ces composantes.
II convient de noter que, dans la mesure où l'architecture logicielle (aussi appelée architecture statique) est une donnée d'entrée, cette première étape 2 du procédé est réalisée seulement une fois, et est exclue du processus itératif.
Un logiciel de base temps réel (BSW ou "Basic Software" dans AUTOSAR) et une couche d'abstraction matérielle de l'architecture multicœur (HW dans AUTOSAR par exemple pour le bus CAN, etc ..) ne sont pas inclus dans l'analyse conduisant à une solution d'allocation, mais seulement au niveau de la validation de la solution, où les impacts du logiciel de base BSW et de la couche d'abstraction matérielle HW sont pris en compte implicitement dans des mesures.
Les premières sorties de ce premier outil réalisant la première étape 2 du procédé selon l'invention sont:
- des informations sur les transitions T: l'exécutable producteur et l'exécutable consommateur, les composantes applicatives SWC qui les contiennent et leur environnement d'exécution associé (mode de déclangement, leur périodicité), et les données transmises;
- une classification des transitions T: chaque transition T est classée dans une des classes C1 C2 C3 ou C4 selon des critères de l'environnement d'exécution pour les exécutables producteurs et consommateurs;
- des informations sur les données: l'information sur les données pour chaque transition contient une taille des données, une unité des données, un type de données et un taux de transfert des données;
- une identification des enchaînements des éléments fonctionnels, "runnables" ou SWC.
La Figure 5 montre un exemple d'enchaînements avec indication des classes et des séries des transitions T entre les nœuds A, B, C, D, E, F, G, ainsi que des taux de transfert des données en octets par milliseconde.
Les résultats de l'analyse de dépendances pilotent la deuxième étape 5 de distribution des éléments fonctionnels de l'application, par exemple:
- la classification des transitions T et les informations sur les données sont utilisées pour évaluer un temps système des communications;
- les enchaînements identifiés servent à déterminer un temps de réponse global d'exécution de ces enchaînements.
Un second outil implémentant la deuxième étape 5 du procédé selon l'invention effectue une exploration de l'espace de conception (ou DSE, acronyme de l'expression anglaise "Design Space Exploration") du graphe orienté élaboré dans la première étape 2 pour distribuer les applications dans des systèmes multicœurs.
Ainsi que cela a été indiqué dans l'analyse de l'état de la technique, le problème est formalisé sous la forme d'un problème d'optimisation combinatoire, qui repose principalement sur la définition de fonctions d'objectif par rapport à des contraintes prédéterminées.
Par conséquent, deux éléments essentiels sont pris en compte dans cette deuxième étape 5 du procédé selon l'invention comme l'indique la Figure 1 : les contraintes 6 qui doivent être respectées et une fonction de coût qui doit être optimisée 7.
Les contraintes prédéterminées 6 sont des paramètres statiques qui doivent être vérifiés pour chaque solution possible. Ces contraintes 6 peuvent prendre en considération aussi bien des caractéristiques temps réel (par exemple la charge de chaque cœur) que les stratégies d'implémentation (par exemple interdire la séparation d'un client et de son serveur).
La fonction de coût 7 est calculée à partir des éléments essentiels suivants:
- utilisation de l'architecture multicœur;
- temps système de communication inter-cœur;
- temps de réponse global d'exécution d'enchaînements ("makespan" dans le vocabulaire de l'homme du métier) qui peut aussi prendre en compte des contraintes en termes d'ordre d'exécution.
Outre les résultats de la première étape 2, d'autres types d'entrées provenant de l'exécution sur la plateforme des versions précédentes sont nécessaires pour calculer la fonction de coût 7:
- un temps d'exécution de chaque exécutable, qui n'est pas constant à chaque exécution. Une estimation de ce temps d'exécution peut se décliner en trois formats: un pire temps d'exécution, un temps d'exécution moyen ou un modèle probabiliste;
- un temps d'accès de données qui pourrait être utilisé pour évaluer un surcoût de temps système de communication pour les communications inter-cœur;
Les entrées Ci-deSSUS Correspondant à des informations de rétroaction d'une quatrième étape du procédé selon l'invention, décrite ci-dessous, provenant d'une itération précédente. On notera aussi que ces entrées peuvent être déterminées au moment d'une itération initiale, par exemple en utilisant une analyse de l'exécution du logiciel sur une plateforme monocœur de référence (sur la même cible). Ces résultats sont ensuite mis à jour après itération des étapes du procédé.
De manière détaillée, on procède comme suit pour effectuer la distribution des éléments fonctionnels de l'application:
- préparation du graphe orienté G fourni par la première étape 2: dans le but de calculer le temps de réponse global d'exécution d'enchaînements, le modèle de l'application doit être un graphe orienté acyclique (ou DAG, acronyme de "Direct Acyclic Graph" en terminologie anglaise); la préparation du graphe orienté G consiste à transformer le graphe orienté initial en un graphe orienté acyclique de la manière suivante:
1 - Placer les nœuds A, B, C, D, E, F sur une ligne horizontale comme le montre la Figure 2a, des arcs directs (traits pleins) étant placés au dessus de cette ligne et des arcs rétrogrades (traits en pointillé) étant placés au dessous de cette ligne;
2 - Modifier un ordre de ces nœuds A, B, C, D, E, F de manière à former une succession de nœuds C, F, B, D, A, E avec un minimum de coût d'arcs rétrogrades comme le montre la Figure 2b;
3 - Supprimer les arcs rétrogrades, le reste du graphe est alors un graphe orienté acyclique.
Les dépendances telles que les contraintes séquentielles sont prises en compte. Tous les nœuds qui sont fortement connectés ne seront pas répartis sur plusieurs cœurs. L'existence d'une solution dépend fortement du fait qu'il existe plus d'un groupe.
- optimisation basée sur le graphe orienté acyclique généré par la phase de préparation précédente qui implique une allocation des nœuds C, F, B, D, A, E du graphe G sur les différents cœurs de l'architecture multicœur; il y a deux degrés d'optimisation:
1 - le degré d'équilibrage des charges qui implique une optimisation des charges (c'est-à-dire équilibrage des charges d'une unité centrale de traitement ou processeur, minimisation des charges de communication inter-coeur, etc ..) quand les nœuds C, F, B, D, A, E du graphe sont répartis entre les différents cœurs;
2 - le degré de performance qui implique une optimisation du makespan pour chaque cœur, et optimise l'ordre d'exécution des nœuds dans chaque cœur.
Ces deux degrés d'optimisation peuvent être formulés dans une approche d'exploration de l'espace de conception (DSE).
La solution d'optimisation est évaluée par la fonction de coût 7, et une recherche de la solution qui minimise la fonction de coût peut être effectuée par des algorithmes métaheuristiques tels que MOSA (acronyme de "Multi-Objective Simulated Annealing", c'est-à-dire "Analyse Spécifique d'Objets Multi-échelle", ou MOGA (acronyme de "Multi-Objective Genetic Algorithm", c'est-à-dire "Algorithme Génétique de Tri Non-dominé"), etc ..
Comme le montre la Figure 1 , les résultats de cette deuxième étape 5 sont intégrés dans le procédé pour générer les fichiers de configuration 8, 9 au format .xml (ou plus précisément *.arxml dans un contexte AUTOSAR):
- un premier fichier de configuration 8 du système d'exploitation;
- un second fichier de configuration 9 de l'environnement d'exécution (RTE ou Runtime Environnement dans AUTOSAR), c'est-à-dire la configuration effective de l'allocation déterminé par le procédé selon l'invention.
Dans une troisième étape 10 du procédé selon l'invention, on évalue la solution obtenue 1 1 à l'issue de la deuxième étape 5.
Cette évaluation nécessite une vérification complète du comportement fonctionnel et temps réel de la solution 1 1 .
Les informations d'entrée de la validation pourraient être des contraintes tirées des spécifications (déjà utilisées dans la deuxième étape 5 pour les décisions d'allocation des composantes applicatives 1 ), par exemple l'une des entrées requises dans cette deuxième étape 5 est le temps d'exécution des exécutables, ou plus généralement un fichier de spécifications 12 au format *cmm décrivant des performances imposées.
A l'itération initiale, le temps d'exécution des exécutables peut être calculé en utilisant une analyse temps réel sur une plateforme monocœur. Pour chaque exécutable, une distribution du temps d'exécution Texe pour un grand nombre N d'exécutions est calculé, et des résultats statistiques sont fournis (temps moyen d'exécution, temps d'exécution minimum, temps d'exécution maximum, écart type, etc .). Un exemple d'une telle distribution est donné sur la Figure 6.
Pour les itérations ultérieures, la distribution des temps d'exécution des exécutables est calculée sur l'architecture multicœur pour la solution obtenue à l'issue de la deuxième étape à chaque itération. Les impacts sur le comportement temps réel de la distribution sont analysés et pris en compte pour les itérations suivantes.
La même chose est faite pour les services 14 utilisés pour communiquer entre les cœurs (services IOC dans AUTOSAR, acronyme de "Inter-OS application Communication", c'est-à-dire "Communicateur d'inter-Os Application").
Comme ces interfaces de programmation d'applications (ou APIs, acronyme de "Application Programming Interface") sont principalement responsables d'un accroissement de la fonction de coût 7, la charge de la communication inter-cœur est observée au moment de l'exécution.
La couche d'abstraction matérielle 15 étant introduite dans cette troisième étape 10, on obtient une validation HIL (acronyme de "Hardware In the Loop", c'est- à-dire "Matériel dans la Boucle") très proche de l'environnement réel.
Dans la quatrième étape 16 du procédé selon l'invention, les résultats provenant de la troisième étape 13 sont utilisés pour évaluer la performance des solutions et mettre à jour les données d'entrée de la deuxième étape 5 si une itération supplémentaire est nécessaire.
Un modèle de métrique de rétroaction/ mise à jour pour cette évaluation 16 est construit par les critères suivants (liste non exhaustive):
- le temps d'exécution des exécutables: pour chaque exécutable, le temps d'exécution peut être modifié; la charge globale de l'architecture multicœur doit être optimisée; le paramètre d'accélération est calculé pour chaque solution de distribution (De combien de fois est-il possible d'accroître la performance avec une architecture multicœur par comparaison à une architecture monocœur).
- le temps système de communication: le temps d'accès aux données peut être modifié particulièrement pour le service du canal IOC;
- le temps de réponse global d'exécution d'enchaînements (makespan);
- la robustesse de l'application due à l'ajout d'un temps système additionnel;
- etc ..
Une distance 17 construite sur un ensemble de critères Θ pour mesurer un écart entre des valeurs de référence Entrée(O) de ces critères et des valeurs courantes Sortie(O) de ces critères calculés à partir des résultats des étapes récédentes 10, 5 peut être donnée par l'expression:
Figure imgf000017_0001
Cette distance D est voisine de zéro si les critères Sortie(O) calculés pour la solution sont proches des critères visés Entrée(O).
Si dans la quatrième étape 16, la distance D est supérieure à un seuil prédéterminé D0, un retour 18 est effectué à la deuxième étape 5, sinon la solution est satisfaisante et peut être implémentée 19, c'est-à-dire, embarquée sur un véhicule.
Un exemple d'application dont le graphe orienté est représenté sur la Figure 3a permettra de bien comprendre le procédé hors ligne d'allocation d'un logiciel sur une architecture multicœur selon l'invention.
Dans cette application, chaque nœuds A, B, C, D, E, F, G, H représente une composante applicative avec un temps d'exécution C et une période T indiqués par un couple (C,T) sur la Figure 3a et les figures suivantes. Une composante D non périodique est notée (C, Φ); par exemple le nœud D est non périodique,
Le but de cet exemple est de distribuer l'application sur une architecture à deux cœurs 20, 21 illustrée sur la Figure 4, les deux cœurs 20, 21 étant identiques.
Selon le procédé de l'invention, dans la première étape 2, les traitements suivants sont réalisés:
1 - Synthèse du modèle: les dépendances existantes dans l'application sont analysées en termes de classifications 22, de taux de transfert de données, etc ., comme l'illustre la Figure 3b.
2- Préparation du graphe: étant donné que l'application montrée sur la Figure 3a contient un cycle B, C, D, le graphe orienté de l'application doit être transformé en un graphe orienté acyclique; le procédé identifie la transition de D à B comme un arc rétrograde 23 et l'ignore dans l'optimisation de l'étape suivante.
Dans cette deuxième étape 5, les traitements suivants sont réalisés:
3 - Optimisation: l'application est distribuée sur les deux cœurs 20, 21 en évaluant une fonction de coût 7 qui prend en compte les critères suivants:
a) équilibrage de la charge et temps système de communication: ces deux critères sont concurrents; sans contrainte d'équilibrage de charge, il n'y aurait pas de temps système de communication si tous les nœuds étaient alloués à un seul cœur.
i) l'équilibrage de charge: les charges de l'architecture multicœur pour chaque cœur 20, 21 doit être réalisé autant que possible;
ii) le temps système de communication entre les cœurs 20, 21 doit être minimisé.
Sur ces bases, l'application peut être distribuée comme le montre la Figure
4. b) performance: pour les résultats d'allocation sur le premier cœur 20, il y a deux possibilités d'enchaînement, soit A→F→G→H, soit A→F→H→G; le choix entre ces deux possibilités dépend du makespan (dans la fonction de coût 7).
En supposant que le coût d'une commutation de contexte est l'unité, pour l'ordre A→F→G→H, le makespan est 23 comme le montre la Figure 7a.
Pour l'ordre A→F→H→G, le makespan est 17 comme le montre la Figure 7b.
c) vérification des contraintes: il convient de noter que pour chaque solution, les contraintes 6 temps réel et fonctionnelles doivent être respectées. Dans cette application, la solution d'allocation est:
- premier cœur 20: B→C→E→D;
- second cœur 21 : A→F→H→G;
Les contraintes 6 suivantes doivent être respectées:
i) une charge maximum pour chaque cœur 20, 21 ne doit pas être dépassée; ii) l'exécution de chacun des nœuds doit respecter leurs délais;
iii) les transitions spécifiées comme ne passant pas par un cœur 20, 21 ne doivent pas passer par ce cœur;
iv) l'ordre des nœuds sur chaque cœur doit respecter les spécifications fonctionnelles;
v) les contraintes autres, si elles existent dans les spécifications.
4 - Configuration des tâches: l'allocation des nœuds V à plusieurs tâches est basée sur les critères de chaque nœud V.
Par exemple, dans le premier cœur 20, les nœuds A et F sont fortement connectés car leurs périodes (égales à 6) sont identiques; les nœuds A et F seront donc alloués à une première tâche 24. Pour la même raison, dans le second cœur 21 , les nœuds B, C, et E sont fortement connectés car leurs périodes sont égales à 12; ces nœuds B, C et E sont alloués à une seconde tâche 25.
Dans la troisième étape 10 du procédé selon l'invention appliqué à l'application montrée sur la Figure 3a, on effectue le traitement suivant:
5 - Test d'ordonnançabilité et de synchronisation: l'ordonnançabilité est satisfaite si chaque tâche 24, 25 satisfait à son délai (égale à sa période dans l'exemple). L'arc rétrograde 23 qui a été ignoré doit être pris en compte pour la synchronisation.
Dans la quatrième étape 16 du procédé selon l'invention appliqué à l'application montrée sur la Figure 3a, on effectue le traitement suivant:
6 - Evaluation et rétroaction: les résultats de la troisième étape peuvent être utilisés pour évaluer la performance des solutions et mettre à jour les données d'entrée de la deuxième étape 5 de distribution. La métrique de rétroaction/ mise à jour telle que le temps d'exécution de chaque nœud, un temps d'accès de variable pour transition T, ou le temps de réponse global des enchaînements sera utilisé pour mettre à jour les données d'entrée de la distribution pour la boucle/ itération suivante.
Comme il va de soi, l'invention ne se limite pas au seul mode de réalisation préférentiel décrit ci-dessus.
Notamment, le système d'exploitation AUTOSAR, et les éléments de l'architecture logicielle correspondante (SWC, BSW, IOC, RTE, VFB, HW, etc ..) cités, n'est qu'un exemple parmi d'autres de systèmes d'exploitation.
Une description analogue pourrait porter sur d'autres modes de réalisations avec d'autres systèmes d'exploitation temps réel, notamment EUROS ®, visant ou non, les applications embarquées dans un véhicule automobile.
Ces autres modes de réalisation ne sortiraient pas du cadre de la présente invention dans la mesure où ils résultent des revendications ci-après.

Claims

REVENDICATIONS
1) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ), ledit logiciel (1 , 8, 9, 15) étant compatible avec un système d'exploitation prédéfini (8) et comprenant des composantes applicatives (1 ), un environnement d'exécution (9), un logiciel de base temps réel fournissant des services auxdites composantes applicatives (1 ), et une couche d'abstraction matérielle (15) de ladite architecture multicœur (20, 21 ), caractérisé en ce qu'il comprend:
- une première étape (2) d'analyse des dépendances desdites composantes applicatives (1 ) produisant un graphe orienté comportant un premier ensemble (V) de nœuds formés par des éléments fonctionnels s'identifiant auxdites composantes applicatives (1 ) ou bien à des exécutables selon un niveau de granularité permis par ledit système d'exploitation (8), et un second ensemble (T) de transitions entre lesdits éléments fonctionnels;
et en outre dans une itération courante:
- une deuxième étape (5) de distribution desdits éléments fonctionnels sur des cœurs (20, 21 ) de ladite architecture multicœur (20, 21 ) résultant d'une optimisation courante d'une fonction de coût (7) par lesdits nœuds (V) et lesdites transitions (T) sous des contraintes prédéterminées (6);
- une troisième étape (10) de validation de ladite optimisation courante calculant un temps d'exécution (Texe) de chacun desdits éléments fonctionnels exécutés sur lesdits cœurs (20, 21 ) au moyen dudit logiciel de base et de ladite couche d'abstraction matérielle (15);
- une quatrième étape (16) d'évaluation de ladite optimisation courante calculant une distance (D) à un objectif prédéterminé et effectuant un retour (18) à ladite deuxième étape (5) pour une itération supplémentaire desdites deuxième, troisième et quatrième étapes (5, 10, 16) si ladite distance (D) est supérieure à un seuil prédéterminé (D0).
2) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ) selon la revendication 1 précédente, caractérisé en ce que ladite optimisation courante est basée sur un algorithme métaheuristique. 3) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ) selon la revendication 1 précédente, caractérisé en ce que lesdites contraintes prédéterminées (6) comprennent des charges nominales desdits cœurs (20, 21 ), un équilibrage de charges courantes desdits cœurs (20, 21 ), et des stratégies d'implémentation.
4) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ) selon la revendication 1 précédente, caractérisé en ce que ladite fonction de coût (7) comprend des critères choisis parmi:
- une utilisation de ladite architecture multicœur (20, 21 );
- un temps système de communication entre lesdits cœurs (20, 21 );
- un temps de réponse global d'exécution d'enchaînements desdits éléments fonctionnels;
- une estimation dudit temps d'exécution (Texe) de chacun desdits éléments fonctionnels;
- un temps d'accès de données.
5) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ) selon la revendication 4 précédente, caractérisé en ce que ladite estimation est un pire temps d'exécution, un temps d'exécution moyen ou un modèle probabiliste.
6) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ) selon la revendication 4 précédente, caractérisé en ce que lesdits critères sont déterminés dans une itération initiale desdites deuxième, troisième et quatrième étapes (5, 10, 16) en utilisant une plateforme monocœur de référence de ladite architecture multicœur (20, 21 ).
7) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ) selon la revendication 1 précédente, caractérisé en ce que ladite première étape (2) comprend:
- une première phase dans laquelle, d'une part, lesdits noeuds (V) sont modélisés chacun par un premier groupe comprenant des premiers paramètres choisis parmi ledit temps d'exécution (Texe), un mode de déclenchement, une première période, et dans laquelle, d'autre part, lesdites transitions (T) sont modélisées chacune par un deuxième groupe comprenant des seconds paramètres choisis parmi un poids fonction d'une taille de données transmises, une seconde période d'un producteur;
- une deuxième phase de classification desdites transitions (T) selon un troisième groupe comprenant des classes prédéterminées (C1 , C2, C3, C4) choisies parmi une première classe (C1 ) dans laquelle lesdites transitions (T) sont périodiques, une deuxième classe (C2) dans laquelle lesdits producteurs ou des consommateurs sont périodiques, une troisième classe (C3) sans périodicité, une quatrième classe (C4) dans laquelle lesdites transitions (T) sont invoquées sur un événement;
- une troisième phase d'analyse des taux de transfert desdites données;
- une quatrième phase d'analyse de séquences de communications et d'extraction de flux desdites données présentant desdits taux de transfert identiques. 8) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ) selon la revendication 1 précédente, caractérisé en ce que ladite deuxième étape (5) comprend:
- une première phase de préparation transformant ledit graphe orienté en un graphe orienté acydique au moyen d'une première opération consistant à placer lesdits nœuds (V) sur une ligne horizontale, des arcs directs étant placés au dessus de ladite ligne et des arcs rétrogrades étant placés au dessous de ladite ligne, d'une deuxième opération consistant à modifier un ordre desdits nœuds (V) de manière à former une succession desdits nœuds avec un minimum de coût desdits arcs rétrogrades, et d'une troisième opération consistant à supprimer lesdits arcs rétrogrades;
- une deuxième phase réalisant ladite optimisation courante en se basant sur ledit graphe orienté acydique et ladite fonction de coût (7);
- une troisième phase de génération de fichiers de configuration (8, 9) dudit système d'exploitation (8) et dudit environnement d'exécution (9).
9) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ) selon la revendication 1 précédente, caractérisé en ce que ladite troisième étape (10) comprend en outre un calcul de durées d'exécution desdits services utilisés en communiquant entre lesdits cœurs (20, 21 ). 10) Procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture nnulticœur (20, 21 ) selon la revendication 4 précédente, caractérisé en ce que dans ladite uatrième étape (16) ladite distance (D) est donnée par l'expression:
Figure imgf000024_0001
où Θ sont lesdits critères, Entrée(O) sont des valeurs de référence desdits critères et Sortie(O) sont des valeurs courantes desdits critères dans ladite itération courante. 11) Utilisation du procédé hors ligne d'allocation d'un logiciel (1 , 8, 9, 15) sur une architecture multicœur (20, 21 ) selon l'une quelconque des revendications 1 à 10 précédentes pour des applications sous un système d'exploitation temps réel (8) de type AUTOSAR destinées à être embarquées dans un véhicule automobile.
PCT/FR2016/053578 2015-12-21 2016-12-20 Procede hors ligne d'allocation d'un logiciel embarque temps reel sur une architecture multicontrôleur multicoeur, et son utilisation pour des applications embarquees dans un vehicule automobile WO2017109386A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1562954 2015-12-21
FR1562954A FR3045870B1 (fr) 2015-12-21 2015-12-21 Procede hors ligne d'allocation d'un logiciel embarque temps reel sur une architecture multicontroleur multicoeur, et son utilisation pour des applications embarquees dans un vehicule automobile

Publications (1)

Publication Number Publication Date
WO2017109386A1 true WO2017109386A1 (fr) 2017-06-29

Family

ID=55542873

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/053578 WO2017109386A1 (fr) 2015-12-21 2016-12-20 Procede hors ligne d'allocation d'un logiciel embarque temps reel sur une architecture multicontrôleur multicoeur, et son utilisation pour des applications embarquees dans un vehicule automobile

Country Status (2)

Country Link
FR (1) FR3045870B1 (fr)
WO (1) WO2017109386A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018205804A1 (de) * 2018-04-17 2019-10-17 Conti Temic Microelectronic Gmbh Steuergerätetesteinrichtung zum Testen, Absichern und Entwickeln von Funktionen
CN110532028A (zh) * 2019-08-30 2019-12-03 上海浦东发展银行股份有限公司信用卡中心 一种基于eclipse生成接口文档的方法
CN115826938A (zh) * 2022-01-29 2023-03-21 宁德时代新能源科技股份有限公司 实时操作系统的生成、使用方法及装置、电子设备、介质
WO2023186427A1 (fr) * 2022-04-01 2023-10-05 Robert Bosch Gmbh Procédé d'attribution de composants logiciels à une architecture de dispositif de commande

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070294696A1 (en) * 2006-06-20 2007-12-20 Papakipos Matthew N Multi-thread runtime system
US20090007127A1 (en) * 2007-06-26 2009-01-01 David Roberts System and method for optimizing data analysis
US20130312001A1 (en) * 2010-10-28 2013-11-21 Noriaki Suzuki Task allocation optimization system, task allocation optimization method, and non-transitory computer readable medium storing task allocation optimization program
AU2013266988A1 (en) * 2013-12-03 2015-06-18 Canon Kabushiki Kaisha Application specific MPSoC synthesis using optimized code partitioning

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070294696A1 (en) * 2006-06-20 2007-12-20 Papakipos Matthew N Multi-thread runtime system
US20090007127A1 (en) * 2007-06-26 2009-01-01 David Roberts System and method for optimizing data analysis
US20130312001A1 (en) * 2010-10-28 2013-11-21 Noriaki Suzuki Task allocation optimization system, task allocation optimization method, and non-transitory computer readable medium storing task allocation optimization program
AU2013266988A1 (en) * 2013-12-03 2015-06-18 Canon Kabushiki Kaisha Application specific MPSoC synthesis using optimized code partitioning

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018205804A1 (de) * 2018-04-17 2019-10-17 Conti Temic Microelectronic Gmbh Steuergerätetesteinrichtung zum Testen, Absichern und Entwickeln von Funktionen
CN110532028A (zh) * 2019-08-30 2019-12-03 上海浦东发展银行股份有限公司信用卡中心 一种基于eclipse生成接口文档的方法
CN110532028B (zh) * 2019-08-30 2023-11-21 上海浦东发展银行股份有限公司信用卡中心 一种基于eclipse生成接口文档的方法
CN115826938A (zh) * 2022-01-29 2023-03-21 宁德时代新能源科技股份有限公司 实时操作系统的生成、使用方法及装置、电子设备、介质
CN115826938B (zh) * 2022-01-29 2023-11-17 宁德时代新能源科技股份有限公司 实时操作系统的生成、使用方法及装置、电子设备、介质
WO2023186427A1 (fr) * 2022-04-01 2023-10-05 Robert Bosch Gmbh Procédé d'attribution de composants logiciels à une architecture de dispositif de commande

Also Published As

Publication number Publication date
FR3045870B1 (fr) 2018-08-31
FR3045870A1 (fr) 2017-06-23

Similar Documents

Publication Publication Date Title
Mubeen et al. Supporting timing analysis of vehicular embedded systems through the refinement of timing constraints
WO2017109386A1 (fr) Procede hors ligne d'allocation d'un logiciel embarque temps reel sur une architecture multicontrôleur multicoeur, et son utilisation pour des applications embarquees dans un vehicule automobile
WO2017076723A1 (fr) Procede de simulation parallele de niveau systeme electronique avec detection des conflits d'acces a une memoire partagee
FR2964224A1 (fr) Procede et dispositif de deploiement et d'aide au deploiement de composants formant un systeme temps reel embarque
US20230376281A1 (en) Systems and methods for generating service access points for rte services in code or other rte service information for use with the code
Mosterman et al. AdvancingModel-Based Design by Modeling Approximations of Computational Semantics.
FR2958427A1 (fr) Procede d'agencement d'un logiciel d'application sur le materiel informatique d'un equipement reel ou virtuel et architecture de commande de l'equipement comprenant un tel logiciel
EP2956874B1 (fr) Dispositif et procédé pour accélérer la phase de mise à jour d'un noyau de simulation
WO2012110445A1 (fr) Dispositif pour accélérer l'exécution d'une simulation system c
Wang et al. Generation of schedule tables on multi-core systems for AUTOSAR applications
Giusto et al. Modeling and analysis of automotive systems: Current approaches and future trends
Ali et al. Towards a framework for the analysis of multi-product lines in the automotive domain
Benveniste et al. Contracts for the design of embedded systems part i: Methodology and use cases
Panunzio Definition, realization and evaluation of a software reference architecture for use in space applications
US7536427B2 (en) Comparing process sizes
Lazreg et al. Assessing the functional feasibility of variability-intensive data flow-oriented systems
Schneider et al. Software Parallelization in Automotive Multi-Core Systems
Möstl On Timing in Technical Safety Requirements for Mixed-Critical Designs
Bushehrian et al. Cost‐aware execution of transactional web services using labelled transition systems
Ghosal et al. Metrics for Evaluating Electronic Control System Architecture Alternatives
Bauer et al. Reference Architectures for Automotive Software
Haberl et al. Seamless model-driven development put into practice
Popp et al. Towards a methodology for the quantitative evaluation of automotive architectures
Becker et al. Timing analysis of safety-critical automotive software: The AUTOSAFE tool flow
FR3069678A1 (fr) Procede d'evaluation d'un temps d'execution de taches sur des blocs materiels

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16826414

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16826414

Country of ref document: EP

Kind code of ref document: A1