Vérification de la latence dans les traces d'exécution de modèle de partitionnement logiciel / matériel

Latency verification in execution traces of HW/SW partitioning model

• Auteur / Autrice : Maysam Zoor
• Direction : Ludovic Apvrille, Renaud Pacalet
• Type : Thèse de doctorat
• Discipline(s) : Informatique
• Date : Soutenance le 08/12/2021
• Etablissement(s) : Institut polytechnique de Paris
• Ecole(s) doctorale(s) : École doctorale de l'Institut polytechnique de Paris
• Partenaire(s) de recherche : Etablissement opérateur d'inscription : Télécom Paris (Palaiseau, Essonne ; 1878-....)
• Partenaire(s) de recherche : Laboratoire : Laboratoire Traitement et communication de l'information (Paris ; 2003-....)
• Jury : Président / Présidente : Camille Salinesi
• Jury : Examinateurs / Examinatrices : Ludovic Apvrille, Renaud Pacalet, Iulian Ober, Jean-Philippe Babau, Emmanuelle Encrenaz
• Jury : Rapporteurs / Rapporteuses : Iulian Ober, Jean-Philippe Babau

Mots clés

Mots clés libres

Systèmes embarqués

Analyse de la trace d'exécution

Analyse temporelle

Simulation

Graphes de dépendance

SysML

Embedded systems

Execution trace analysis

Timing analysis

Simulation

Dependency graph

SysML

Résumé

Alors que de nombreux travaux de recherche visent à définir de nouvelles techniques de vérification (formelle) pour vérifier les exigences dans un modèle, la compréhension de la cause profonde de la violation d'une exigence reste un problème ouvert pour les plateformes complexes construites autour de composants logiciels et matériels. Par exemple, la violation d'une exigence de latence est-elle due à un ordonnancement temps réel défavorable, à des conflits sur les bus, aux caractéristiques des algorithmes fonctionnels ou des composants matériels ? Cette thèse introduit une approche d'analyse précise de la latence appelée PLAN. PLAN prend en entrée une instance d'un modèle de partitionnement HW/SW, une trace d'exécution, et une contrainte de temps exprimée sous la forme suivante : la latence entre l'opérateur A et l'opérateur B doit être inférieure à une valeur de latence maximale. PLAN vérifie d'abord si la condition de latence est satisfaite. Si ce n'est pas le cas, l'intérêt principal de PLAN est de fournir la cause première de la non satisfaction en classant les transactions d'exécution en fonction de leur impact sur la latence : transaction obligatoire, transaction induisant une contention, transaction n'ayant aucun impact, etc. Une première version de PLAN suppose une exécution pour laquelle il existe une exécution unique de l'opérateur A et une exécution unique de l'opérateur B. Une seconde version de PLAN peut calculer, pour chaque opérateur A exécuté, l'opérateur B correspondant. Pour cela, notre approche s'appuie sur des techniques de tainting. La thèse formalise les deux versions de PLAN et les illustre par des exemples ludiques. Ensuite, nous montrons comment PLAN a été intégré dans un Framework Dirigé par le Modèle (TTool). Les deux versions de PLAN sont illustrées par deux études de cas tirées du projet H2020 AQUAS. En particulier, nous montrons comment l'altération peut traiter efficacement les multiples et occurrences concurrentes du même opérateur.

While many research works aim at defining new (formal) verification techniques to check for requirements in a model, understanding the root cause of a requirement violation is still an open issue for complex platforms built around software and hardware components. For instance, is the violation of a latency requirement due to unfavorable real-time scheduling, to contentions on buses, to the characteristics of functional algorithms or hardware components?This thesis introduces a Precise Latency ANalysis approach called PLAN. PLAN takes as input an instance of a HW/SW partitioning model, an execution trace, and a time constraint expressed in the following format: the latency between operator A and operator B should be less than a maximum latency value. First PLAN checks if the latency requirement is satisfied. If not, the main interest of PLAN is to provide the root cause of the non satisfaction by classifying execution transactions according to their impact on latency: obligatory transaction, transaction inducing a contention, transaction having no impact, etc.A first version of PLAN assumes an execution for which there is a unique execution of operator A and a unique execution of operator B. A second version of PLAN can compute, for each executed operator A, the corresponding operator B. For this, our approach relies on tainting techniques.The thesis formalizes the two versions of PLAN and illustrates them with toy examples. Then, we show how PLAN was integrated into a Model-Driven Framework (TTool). The two versions of PLAN are illustrated with two case studies taken from the H2020 AQUAS project. In particular, we show how tainting can efficiently handle the multiple and concurrent occurrences of the same operator.