FR3084490A1

FR3084490A1 - Banc d'observation et de test d'un logiciel embarque a base de composants et methodes d'observation et de tests employant ce banc

Info

Publication number: FR3084490A1
Application number: FR1800821A
Authority: FR
Inventors: Li Wenbin; Franck Le Gall
Original assignee: Easy Global Market
Current assignee: Easy Global Market
Priority date: 2018-07-30
Filing date: 2018-07-30
Publication date: 2020-01-31

Abstract

L'invention concerne la validation du logiciel destiné à être embarqué dans les réseaux de télécommunications mobiles de 5ième génération mais plus généralement au logiciel embarqué de tout système cible. Le logiciel considéré est un logiciel à base de composants. L'invention comprend d'une part un banc pour observer et tester, à l'aide d'un modèle (Model Based Testing), le logiciel embarqué, où le ou les contrôleurs des composants du logiciel sont eux aussi des composants, fonctionnant dans le même environnement d'exécution que le logiciel et utilisant le même canal de communication c'est-à-dire le canal de l'environnement d'exécution. Elle comprend aussi des méthodes d'observation et de validation du logiciel embarqué dans son ensemble ou de tout composant individuellement, à l'aide d'un modèle, employant ledit banc. On évite ainsi le développement d'une interface d'adaptation des environnements d'exécution entre le contrôleur et le logiciel à tester. Le banc de test permet de plus d'observer ou de tester le logiciel avec une précision accrue par rapport à l'état de la technique, au moyen de l'observation de tout composant individuellement.

Description

©) L'invention concerne la validation du logiciel destiné à individuellement, être embarqué dans les réseaux de télécommunications mobiles de 5^>ieme génération mais plus généralement au logiciel embarqué de tout système cible.

Le logiciel considéré est un logiciel à base de composants.

L'invention comprend d'une part un banc pour observer et tester, à l'aide d'un modèle (Model Based Testing), le logiciel embarqué, où le ou les contrôleurs des composants du logiciel sont eux aussi des composants, fonctionnant dans le même environnement d'exécution que le logiciel et utilisant le même canal de communication c'est-à-dire le canal de l'environnement d'exécution.

Elle comprend aussi des méthodes d'observation et de validation du logiciel embarqué dans son ensemble ou de tout composant individuellement, à l'aide d'un modèle, employant ledit banc.

On évite ainsi le développement d'une interface d'adaptation des environnements d'exécution entre le contrôleur et le logiciel à tester.

Le banc de test permet de plus d'observer ou de tester le logiciel avec une précision accrue par rapport à l'état de la technique, au moyen de l'observation de tout composant lllllllllllllllllllllllllllllllllllllllllllll

Banc d’observation et de test d’un logiciel embarqué à base de composants et méthodes d’observation et de tests employant ce banc

Domaine technique

L'invention concerne la validation du logiciel destiné à être embarqué dans les réseaux de télécommunications mobiles de 5^ième génération (réseaux 5G).

Etat de l’art et référence(s) pertinente(s)

Les réseaux 5G à venir offriront des services qui impliquent la présence d’un logiciel complexe au sein même de l’infrastructure, qualifié pour cette raison de « logiciel embarqué ».

Le logiciel considéré dans la présente invention est un logiciel à base de composants. Selon les principes de la programmation à base de composants (« programmation orientée composant »), chaque composant accomplit une fonction donnée. Il peut être utilisé par plusieurs logiciels. Il se présente par exemple sous la forme d’un fichier informatique contenant du code compilé.

Les composants fonctionnent dans un environnement d’exécution (computing environment) qui permet de les faire communiquer entre eux, en créant des flux de données et grâce à des moyens de contrôle. L’environnement d’exécution comporte, par exemple, des fonctions d’interface avec les composants mais aussi des fichiers exécutables composés d’une suite de fonctions d’interface, enchaînant les composants et construisant ainsi des logiciels qui peuvent à leur tour devenir des composants.

Le logiciel considéré dans la présente invention doit être validé (testé) préalablement à son « embarquement ». Une méthode de test du logiciel embarqué d’un système cible consiste à successivement stimuler le logiciel à partir d’une configuration de test correspondant à une situation possible du système cible, recueillir les sorties du logiciel et les comparer aux valeurs attendues.

Si les valeurs de sortie égalent les valeurs attendues, le logiciel est validé pour ce test ; sinon, il est invalidé et il convient d’analyser les différences entre les sorties et les valeurs attendues et de corriger le logiciel en conséquence.

Il est utile de se contenter d’observer le fonctionnement du logiciel lors de son exploitation sans intervenir dans sa stimulation (monitoring).

Les fonctions d’observation, de recueil des sorties d’un logiciel ou d’un composant logiciel et éventuellement les fonctions de stimulation de ce logiciel ou de ce composant sont des fonctions de contrôle qui peuvent être réunies au sein d’une même unité dite « contrôleur ».

Une campagne de test doit satisfaire à deux exigences contradictoires : d’une part, les tests doivent être suffisamment variés et nombreux pour que la campagne de test soit probante ; d’autre part, le coût de celle-ci doit être réduit autant que possible ainsi que sa durée en sorte de réduire le temps nécessaire pour aborder le marché (« time to market »).

Ces considérations ont motivé l’automatisation des méthodes de test à partir d’un modèle du système cible qu’on a représenté de manière informatique, autrement dit un modèle programmé (Model Based Testing, MBTesting). Le brevet US 7 089 534 B2 présente une architecture de test (Model Based Tester, MBTester) au moyen de configurations de test produites automatiquement. Il introduit une unité de génération de configurations de test qui permet de communiquer directement avec l’utilisateur (interface utilisateur). Le générateur transmet la suite des configurations de test à un moteur d’exécution associé à un moteur de validation. Le moteur d’exécution stimule le logiciel à tester avec les différentes configurations de test et le moteur de validation vérifie que la réaction du logiciel correspond à celle attendue. L’architecture de test proposée est adaptée à la validation d’un logiciel à base de composants fonctionnant en parallèle au sens de la présente demande dits « concurrent operations » dans l’antériorité.

Cependant il faut développer une interface entre le MBTester et le logiciel à tester pour leur permettre de communiquer. Cette interface peut mobiliser des ressources importantes dans les ordinateurs (temps de calcul, mémoire vive, connexions etc.) et son développement être coûteux.

Résumé de l’invention

La présente demande revendique un banc pour observer et tester, à l’aide d’un modèle, un logiciel embarqué à base de composants, où le ou les contrôleurs sont des composants fonctionnant dans le même environnement d’exécution que le logiciel et utilisant le même canal de communication c’est-à-dire le canal de l’environnement d’exécution.

Elle revendique aussi des méthodes d’observation et de validation dudit logiciel dans son ensemble ou de tout composant individuellement, à l’aide d’un modèle, employant ledit banc.

Le but de la présente invention est d’éviter le développement d’une interface d’adaptation des environnements d’exécution entre le contrôleur et le logiciel à tester.

Le banc de test permet de plus d’observer ou de tester le logiciel avec une précision accrue par rapport à l’état de la technique, au moyen de l’observation de tout composant individuellement.

Description des dessins

L’invention sera mieux comprise à l’aide des dessins suivants qui ne doivent pas s’interpréter comme une limitation.

La Figure 1 représente l’architecture principale d’un banc pour l’observation ou la validation d’un logiciel embarqué à base de composants.

La Figure 2 représente l’architecture principale d’un banc pour l’observation ou la validation de composants individuels d’un logiciel embarqué à base de composants et les flux de données et de contrôle lors de l’observation ou de la validation.

La Figure 3 représente l’architecture principale d’un banc pour l’observation ou la validation d’un logiciel embarqué synchrone à base de composants dans son ensemble et les flux de données et de contrôle lors de l’observation ou de la validation.

La Figure 4 représente l’architecture principale d’un banc pour la validation dynamique d’un logiciel embarqué synchrone à base de composants dans son ensemble et les flux de données et de contrôle lors de la validation.

La Figure 5 représente l’architecture principale d’un banc pour la validation dynamique de composants individuels d’un logiciel embarqué à base de composants et les flux de données et de contrôle lors de la validation.

La Figure 6 représente l’architecture d’un banc pour l’observation ou la validation d’un logiciel embarqué parallèle à base de composants dans son ensemble et les flux de données et de contrôle lors de l’observation ou de la validation.

La Figure 7 représente l’architecture d’un banc pour la validation dynamique d’un logiciel embarqué parallèle à base de composants dans son ensemble et les flux de données et de contrôle lors de la validation.

La Figure 8 représente l’architecture distribuée d’un banc pour l’observation d’un logiciel synchrone embarqué à base de composants dans son ensemble et les flux de données et de contrôle lors de l’observation.

La Figure 9 représente l’architecture distribuée d’un banc pour la validation dynamique de composants individuels d’un logiciel synchrone embarqué à base de composants et les flux de données et de contrôle lors de la validation.

Description d’un mode de réalisation détaillée de l’invention

La Figure 1 représente l’architecture principale de l’invention : un système informatique 1 caractérisé par son environnement d’excution et son canal de communication interne, un logiciel à base de composants 2 à 6 implémenté dans le système, une unité de supervision 7, le ou les contrôleurs 8, 9 et les interfaces d’accès 10 et de sortie 11 entre le système informatique et l’extérieur.

Le MBTester se compose de l’unité de supervision 7 qui permet de communiquer directement avec l’utilisateur et du ou des contrôleurs 8, 9 qui communiquent directement avec le logiciel.

L’unité de supervision fonctionne indifféremment à l’intérieur ou à l’extérieur du système informatique ; ainsi elle est représentée à la frontière entre les deux et la flèche issue de l’unité de supervision ou celle y aboutissant ne doivent pas s’interpréter comme des flux de communication directe. Elle communique avec tous les contrôleurs, de manière directe si elle est à l’intérieur du système, indirecte sinon, c’est-à-dire en passant par une interface logicielle ou matérielle.

Dans l’invention, les contrôleurs se présentent sous la forme de composants 8, 9 implémentés dans le système 1, qui partagent le canal de communication du logiciel à tester et de ses composants. On évite ainsi le développement d’une interface d’adaptation entre le ou les contrôleurs et le logiciel à tester.

Dans une réalisation préférée de l’architecture principale, les composants du logiciel et les contrôleurs sont implémentés sur le même ordinateur ou microprocesseur et utilisent le cas échéant le même système d’exploitation. Le canal de communication peut alors être, par exemple et de manière non limitative, ce qu’on appelle une Application Programming Interface (API).

Les composants du logiciel peuvent fonctionner de manière synchrone ou parallèle. Synchrone : il existe des composant initiaux (ou d’entrée) et des composants finals (ou de sortie) et les composants (sauf les composants finals) envoient leurs sorties à d’autres (ainsi certains composants ne peuvent commencer tant que d’autres n’ont pas fini et l’on retrouve l’acception commune de « logiciel synchrone »).

Parallèle : les composants fonctionnent en parallèle et partagent un espace mémoire commun. Ils se succèdent ou non dans le temps et communiquent ou non de manière directe entre eux.

Un logiciel où les composants fonctionnent de manière synchrone (respectivement parallèle) sera dit « logiciel synchrone » (respectivement « logiciel parallèle »).

Dans le cas d’une application à l’observation (Figure 2, Figure 3), les contrôleurs sont multiples. Chaque contrôleur 8 ou 9 est propre à un composant 2 ou 4 respectivement et contient une liste de valeurs attendues en sortie du composant dans les conditions opérationnelles envisagées. L’unité de supervision 7 a calculé cette liste pour chaque composant à partir d’un modèle du système cible et l’a transmise au contrôleur dudit composant. Un contrôleur a pour fonction de recueillir les sorties de son composant, de les comparer aux valeurs attendues et de signaler les différences entre les valeurs recueillies et les valeurs attendues à l’unité de supervision. La spécialisation de chaque contrôleur à un composant permet d’analyser en détail le comportement du composant. Quant à l’observation d’un logiciel synchrone dans son ensemble, si elle peut être synthétisée à partir de l’observation des composants individuels, il est aussi techniquement faisable de l’effectuer au moyen d’un unique contrôleur (Figure 3). Dans cette option, l’unité de supervision calcule la liste de valeurs de sorties attendues du logiciel dans son ensemble et la transmet au contrôleur, qui recueille les sorties du logiciel au niveau du composant de sortie, les compare aux valeurs attendues et signale les différences entre les sorties et les valeurs attendues à l’unité de supervision.

La suite d’étapes allant du calcul de la liste des valeurs attendues au signalement des valeurs fautives de sortie, qu’il s’agisse d’observer un composant individuel ou le logiciel synchrone dans son ensemble, constitue une méthode d’observation classique à laquelle on se réfère lorsqu’on parle de méthode d’observation dans la présente demande.

Dans le cas d’une application à la validation (test), l’unité de supervision a pour fonctions, outre d’être l’interface avec l’utilisateur, la génération automatique de configurations de test à partir d’un modèle du système cible, selon des méthodes connues. Elle envoie les configurations de test ainsi produites aux contrôleurs.

Il y a un ou plusieurs contrôleurs, suivant que l’on veut tester le logiciel synchrone dans son ensemble (Figure 3) ou chaque composant individuellement (Figure 2) et alors chaque contrôleur 8 ou 9 est propre au composant qu’il sert à tester 2 ou 4 respectivement. Un contrôleur destiné à la validation a pour fonctions de stimuler le logiciel synchrone ou son composant à l’aide des configurations de test reçues de l’unité de supervision, puis de recueillir les sorties du logiciel synchrone, respectivement dudit composant, puis de les comparer aux valeurs attendues et enfin de signaler à l’unité de supervision les différences entre les valeurs recueillies et les valeurs attendues.

Lorsque c’est le logiciel synchrone dans son ensemble qu’on valide, le contrôleur envoie, par le canal de communication interne, les configurations de test aux composants initiaux du logiciel directement, sans passer par l’interface reliant le logiciel à l’extérieur.

Lorsque c’est un composant individuel qu’on valide, pour un logiciel synchrone comme pour un logiciel parallèle, le contrôleur envoie, par le canal de communication interne, les configurations de test au dit composant. Il recueille ensuite les sorties du dit composant. Une telle utilisation permet de valider complètement les composants individuels ; par exemple mais non limitativement, elle permet de valider toutes les options de la fonction d’un composant ou de mesurer précisément son temps d’exécution.

La suite d’étapes allant de la génération de configurations de test au signalement des valeurs fautives de sortie du logiciel synchrone ou d’un composant quelconque constitue une méthode de test classique, à laquelle on se réfère lorsqu’on parle de méthode de test sans autre précision dans la présente demande.

La validation peut être différée (offline) ou dynamique (online).

Différée : dans l’architecture correspondante, l’unité de supervision fonctionne indifféremment à l’intérieur ou à l’extérieur du système informatique. L’unité de supervision prépare des configurations de test, au-moins une, qui suivent un certain ordre. Elle télécharge tout d’un coup la suite de configurations de test vers le contrôleur (l’unique contrôleur du banc ou bien le contrôleur du composant testé individuellement suivant la logique de test), préalablement aux tests. La durée du téléchargement n’est pas critique. Puis le contrôleur effectue tous les tests, dans l’ordre.

Dynamique (Figure 4, Figure 5) : dans l’architecture correspondante, l’unité de supervision 7 est elle-même un composant qui fonctionne à l’intérieur du système informatique et qui partage le canal de communication du ou des contrôleurs et des composants du logiciel, ce qui permet de réduire le temps de communication entre l’unité de supervision 7 et le contrôleur 8. Elle prépare une configuration de test à la fois, l’envoie au contrôleur (l’unique contrôleur du banc (Figure 5) ou bien le contrôleur du composant testé individuellement (Figure 6) suivant la logique de test), qui effectue le test et renvoie un rapport de test à l’unité de supervision, qui prépare alors la configuration de test suivante en fonction du rapport.

Les méthodes d’observation et de validation du logiciel dans son ensemble décrites cidessus peuvent être adaptées à un logiciel parallèle et à l’architecture correspondante (Figure 6, Figure 7).

Dans le cas d’une application à l’observation, l’unité de supervision 7 fonctionne indifféremment à l’intérieur ou à l’extérieur du système informatique. Le contrôleur observe le logiciel parallèle dans son ensemble par la lecture des données de sortie des différents composants dans l’espace mémoire commun, auquel il a un accès direct.

Dans le cas d’une application à la validation, le contrôleur stimule les composants par l’écriture des données d’entrées desdits composants dans l’espace mémoire commun, auquel il a un accès direct ; puis recueille les données de sortie desdits composants par la lecture en parallèle de ces données dans l’espace mémoire commun.

La méthode de test peut être différée ou dynamique. La méthode dynamique est basée sur une architecture où l’unité de supervision fonctionne à l’intérieur du système informatique et utilise le même canal de communication que les composants du logiciel (Figure 7).

Selon un mode de réalisation particulier, l’invention est adaptée à une architecture où l’environnement d’exécution est distribué c’est-à-dire que les composants fonctionnent sur des ordinateurs différents, reliés en réseau (Figure 8, Figure 9), le logiciel étant synchrone ; par exemple mais non limitativement des composants qui sont des commandes Unix sur des ordinateurs exploités par Unix et communiquant entre eux selon la pile de protocoles TCP/IP ; cependant ces commandes utilisent entre elles le canal de communication fondamental d’Unix (« piping »).

Pour une application à l’observation, lorsqu’il s’agit d’observer un logiciel synchrone dans son ensemble (Figure 8), le contrôleur est unique et implémenté sur un ordinateur quelconque du système ; lorsqu’il s’agit d’observer les composants individuellement (Figure 9), les contrôleurs sont multiples, chaque contrôleur étant propre à un composant et implémenté sur le même ordinateur que son composant afin de réduire le temps de communication entre les deux. La méthode d’observation est la même que pour l’architecture principale. L’unité de supervision fonctionne indifféremment à l’intérieur ou à l’extérieur du système informatique ; bien qu’elle soit représentée à l’extérieur sur la Figure 8, cela ne doit pas s’interpréter comme une limitation.

Pour une application à la validation, dans le cas d’une validation différée, l’unité de supervision fonctionne indifféremment à l’intérieur ou à l’extérieur du système informatique. La méthode de validation est la même que pour l’architecture principale.

S’il s’agit de valider un composant donné individuellement, le contrôleur sera avantageusement implémenté sur le même ordinateur que ledit composant afin de réduire le temps de communication entre les deux.

dans le cas d’une validation dynamique, l’unité de supervision est elle-même un composant qui fonctionne à l’intérieur du système informatique et partage le canal de communication du contrôleur et des composants du logiciel. La méthode de validation est la même que pour l’architecture principale.

S’il s’agit de valider un composant donné individuellement, l’unité de supervision et le contrôleur seront avantageusement implémentés sur le même ordinateur que ledit 10 composant afin de réduire le temps de communication entre l’unité de supervision et le contrôleur d’une part, le contrôleur et ledit composant d’autre part (Figure 9).

Applications industrielles

L’invention a été mise au point pour tester du logiciel embarqué destiné à des réseaux 15 5G mais peut être appliquée au logiciel embarqué de tout système cible.

Claims

Revendications

1. Banc d’observation et de test, à l’aide d’un modèle programmé, de tout composant (2-6) d'un logiciel embarqué à base de composants ou du logiciel dans son ensemble, qu’il soit synchrone ou parallèle, comprenant une unité de supervision (7) et un ou plusieurs contrôleurs (8,9), lesquels contrôleurs sont des composants utilisant le même canal de communication que les composants dudit logiciel.
2. Banc selon la revendication 1 caractérisé en ce que ladite unité de supervision (7) est un composant utilisant le même canal de communication que les composants dudit logiciel.
3. Banc selon la revendication 1 caractérisé en ce que :

- les composants (2-4) fonctionnent en parallèle ;

- les composants partagent un espace mémoire commun (12).
4. Banc selon la revendication 3 caractérisé en ce que ladite unité de supervision (7) est un composant utilisant le même canal de communication que les composants dudit logiciel.
5. Banc selon la revendication 1 caractérisé en ce que les composants dudit logiciel synchrone sont implémentés sur des ordinateurs différents reliés en réseau.
6. Banc selon la revendication 5 caractérisé en ce que ladite unité de supervision (7) est un composant utilisant le même canal de communication que les composants dudit logiciel.
7. Procédé d’observation de tout composant dudit logiciel, employé sur un banc selon la revendication 1 avec un contrôleur (9) par composant (4).
8. Procédé d’observation dudit logiciel parallèle dans son ensemble par lecture des données de sortie des composants dans l’espace mémoire commun (12), employé sur un banc selon la revendication 3 avec un unique contrôleur (8), lequel contrôleur a accès directement audit espace mémoire commun.
9. Procédé d’observation de tout composant dudit logiciel ou dudit logiciel dans son ensemble, employé sur un banc selon la revendication 5 avec respectivement un contrôleur (8) par composant (5), implémenté sur le même ordinateur que ce composant, ou un unique contrôleur sur le banc.
10. Procédé de test de tout composant dudit logiciel ou de test dudit logiciel synchrone dans son ensemble, employé sur un banc selon la revendication 1 avec respectivement un contrôleur (9) par composant (4) ou un unique contrôleur 8 sur le banc.
11 .Procédé de test selon la revendication 10 caractérisé en ce qu’il est différé.
12. Procédé de test selon la revendication 10 employé sur un banc selon la revendication (2), caractérisé en ce qu’il est dynamique.
13. Procédé de test dudit logiciel parallèle dans son ensemble par écriture des

5 données d’entrée des composants puis par lecture des données de sortie des composants dans l’espace mémoire commun (12), employé sur un banc selon la revendication 3 avec un unique contrôleur (8), lequel contrôleur a accès directement audit espace mémoire commun.
14. Procédé de test selon la revendication 13, caractérisé en ce qu’il est différé.

10 15. Procédé de test selon la revendication 13, employé sur un banc selon la revendication 4, caractérisé en ce qu’il est dynamique.

16. Procédé de test de tout composant dudit logiciel ou dudit logiciel dans son ensemble, employé sur un banc selon la revendication 5 avec respectivement un contrôleur (8) par composant (5), implémenté sur le même ordinateur que ce
15 composant, ou un unique contrôleur sur le banc.
17. Procédé de test selon la revendication 16 caractérisé en ce qu’il est différé.
18. Procédé de test selon la revendication 16 employé sur un banc selon la revendication 6, caractérisé en ce qu’il est dynamique.