FR 2598001 A1 19871030 FR 8605883 A 19860423 Dispositif pour le contrôle de logiciels industriels, en particulier de logiciels opérant en temps réel, et procédé correspondant. L'invention concerne le contrôle des logiciels industriels, dont on attend une haute fiabilité, et qui, dans la plupart des cas, doivent fonctionner en temps réel. Ce contrôle est la dernière phase de l'élaboration du logiciel, qui aura été, au préalable, d'abord défini (spécification), puis conçu, et ensuite réalisé. Le contrôle d'un logiciel doit se faire dans ses conditions de fonctionnement normal, et en temps réel, si c'est le cas. Il comprend des tests, dont chacun consiste à exécuter tout ou partie du logiciel, et à comparer son comportement à un comportement de référence. Tout cela doit s'effectuer en perturbant le moins possible le sys tème matériel et logiciel, que l'on observe. Les tests dits statiques consistent à vérifier le séquen cernent de différents segments du logiciel, que l'on exécute individuellement, hors temps réel. Ces tests ne révèlent en général que des erreurs assez grossières comme des branchements mal positionnés, qui sont aussi les plus fréquentes et les plus simples à mettre en évidence. Des tests dynamiques consisteraient au contraire à vérifier, en temps réel et dans un contexte représentatif du fonctionnement opérationnel,le bon fonctionnement d'un ensemble intégré de programmes élémentaires. De tels tests permettraient d'assurer que le logiciel est "valide", c'est-à-dire qu'il présente un comportement conforme à celui défini au départ, par la définition ou "spécifica tionw initiale. Malheureusement, jusqu'à présent, il n'a pas été possible d'effectuer d'une manière générale des tests dynamiques des logiciels industriels. Les moyens de test connus ont les inconvénients suivants - les tests dits manuels consistant notamment à relire le logiciel pour en corriger les erreurs, sont lents; - l'introduction de points de test, dans le logiciel à contrôler, est source de perturbations, dès lors qu'on atteint un nombre de points de test qui rend le logiciel sous test non commercialisable; - l'exécution de contrôles de bas niveau, c'est-à-dire portant sur un langage de programmation peu évolué, est également lente et délicate, même si elle est pour partie automatisée; - enfin, les outils de test existants sont spécifiques, c'est-à-dire qu'ils ne conviennent qu'à un ordinateur-hôte donné, et qu'à un langage de programmation donné, accepté par cet ordinateur-hôte. La présente invention vient apporter un perfectionnement important dans le contrôle et le test des logiciels, en particulier des logiciels en temps réel. Un premier but de la présente invention est de permettre le contrôle et le test de logiciels, en temps réel, sans perturber le programme sous test, c'est-à-dire sans y incorporer des points de contrôle inacceptables dans la version ultérieurement commercialisée. L'invention a aussi les autres buts suivants - permettre le contrôle et le test d'un logiciel indépendamment du matériel concerné, du langage de programmation choisi, et même des techniques utilisées pour l'élaboration du logiciel; permettre la réalisation de contrôles de haut niveau dans le logiciel à tester, c'est-à-dire de partir d'un langage évolué; - permettre la réalisation de tests automatiques d'un logiciel; - fournir des moyens de test propres à suivre, sans difficulté, l'évolution future du logiciel. L'invention concerne essentiellement un dispositif pour le contrôle de logiciels industriels, en particulier de logiciels destinés à opérer en temps réel, sur une machine informatique dite machine sous test. De façon générale, ce dispositif comprend - une machine informatique dite machine de test, implantée sur un ordinateur-hôte, - des moyens d'interface propres à permettre l'espionnage du bus interne de la machine sous test, et sa recopie selon un format standardisé, ainsi que la synchronisation avec cette machine en fonction de conditions choisie portant sur des données, adresses ou commandes existant dans la machine sous test, et - des moyens de test reliés aux moyens d'interface, et propres à permettre l'exécution de séquences d'opérations de test sur la machine sous test, indépendamment de la nature de celle-ci. Selon un autre aspect de l'invention, les moyens d'interface comportent - une sonde, propre à une communication totale avec le bus interne du processeur de la machine sous test; - des moyens d'interface spécifique, reliés à cette sonde, pour recevoir ledit bus interne, et le recopier sous la forme d'un bus d'interface, selon un format standardisé, - des moyens de détection de coincidence, propres à effectuer des comparaisons en temps réel portant sur des données, adresses ou commandes existant sur le bus d'interface, afin d'établir des indications de synchronisation pour le contrôle du logiciel industriel, et - de préférence, des moyens de mémoire de trace, reliés au bus d'interface, et propres à enregistrer séquentiellement les indications de synchronisation relevées par l'unité de coincidence. Selon un autre aspect de l'invention, la sonde comprend le processeur déporté de la machine sous test. Des moyens de commutation permettent deux modes de fonctionnement - un état normal de fonctionnement où le processeur est connecté à la machine sous test, le bus interne étant recopié dans le bus interface pour en permettre l'espionnage, - un état de déroutement où le processeur est connecté à un moniteur situé dans une mémoire a double accès, per mettant ainsi à l'interface spécifique soit d'accéder à la mémoire sous test, soit d'accéder à la mémoire double accès, dans laquelle les registres du processeur ont été sauve gardés. Plus particulièrement, le dispositif est propre à contrôler l'état de mise sous tension de la machine sous test, à lancer le logiciel à tester à partir de toute adresse particulière, à l'arrêter, à lire ou modifier les contenus des registres internes du processeur (déporté), ainsi qu'à surveiller les paramètres du processeur (déporté) et en modifier la valeur. Selon un autre aspect de l'invention, la machine de test, possède un processeur, des périphériques d'entrée/sortie, une mémoire de travail, une mémoire de programme, et un bus principal également relié aux moyens matériels d'interface; cette machine de test peut ainsi contrôler, à travers les moyens matériels d'interface, l'exécution de tout ou partie du logiciel industriel à tester, dans ses conditions normales de fonctionnement dans la machine sous test. Dans la pratique, la machine de test reçoit aussi une carte de symboles-mémoire du logiciel industriel à tester, tel qu'exécuté dans la machine sous test.Cette carte peut être élaborée automatiquement par un post-processeur de la chaine de production du logiciel à tester. La machine de test reçoit, en principe, un modèle du comportement du logiciel à tester, pour comparer le second au premier. Selon encore un autre aspect de l'invention, la machine de test est dotée d'un langage de test qui est un langage structuré de programmation de haut niveau, muni en outre d'instructions spéciales comprenant, au moins - le chargement et ltexécution du logiciel industriel par la machine sous test, ainsi que - la définition de variables sous test, et d'au moins un type de points de contrôle, et la validation d'un tel point de contrôle dans le logiciel à tester, en ayant recours à l'unité de coincidence. La machine de test est également munie d'un traducteur, comprenant au moins un interpréteur, ce qui permet l1exé- cution contrôlée de tout ou partie du logiciel à tester. De préférence, le langage de test comprend aussi des instructions permettant des simulations de toutes autres instructions, pour exécution temporaire dans le logiciel sous test. Mieux encore, le langage de test comprend encore une instruction permettant la vérification de toute condition booléenne voulue, en tout point de l'exécution du logiciel sous test. Ainsi, l'interpréteur permet l'analyse et l'exécution des programmes de tests écrits à l'aide du langage de test, et ceci de façon interactive. Ceci permet la comparaison, en temps réel, du comportement du logiciel sous test, à un comportement de référence, défini par programmation dans le langage de test. Dans la version la plus élaborée, la machine de test est également munie d'un compilateur, propre à élaborer un code-objet, à partir d'un code source élaboré interactivement par l'interpréteur. La rapidité d'exécution du programme de test est alors considérablement augmentée. Selon un mode de réalisation particulier de l'invention, les éléments logiciels de la machine de test sont écrits en Pascal ISO niveau 0, l'interpréteur et le compilateur étant développés à l'aide du métacompilateur LILA. L'invention offre également un procédé pour le contrôle de logiciels industriels, en particulier de logiciels destinés à opérer un temps réel, sur une machine informatique dite machine sous test. Ce procédé comprend, généralement, les opérations suivantes a) espionner le bus interne de la machine sous test, et le recopier sous un format standardisé, b) établir un jeu de conditions choisies portant sur des données, adresses ou commandes existant dans la machine sous test, et surveiller la coincidence de l'état de la machine sous test avec l'une de ces conditions, et c) exécuter une séquence d'opérations de test utilisant lesdites conditions choisies, ce qui permet de définir la séquence d'opérations de test indépendamment de la nature de la machine sous test. Avantageusement, la séquence d'opérations de test comprend l'une au moins des opérations consistant à controler l'état de mise sous tension de la machine sous test, à lancer le logiciel à tester à partir de toute adresse particu lière, à l'arrêter, à lire ou modifier les contenus des registres internes du processeur de la machine sous test, ainsi qu'à surveiller les paramètres de ce processeur et en modifier la valeur. Selon un autre aspect de ce procédé, l'opération c) comprend la préparation du logiciel à tester par 1) écriture de son coe-source; 2) passage à son code-objet, avec compilation; 3) établissement d'une liste complète des symboles utilisés par ledit code objet, comprenant leur carte d'implantation en mémoire dans la machine sous test; 4) écriture d'un programme de test en code source, dans un langage de test, tel que défini plus haut, ce programme de test comprenant, au moins, un modèle de comportement du logiciel à tester; et 5) traduction du programme de test en code exécutable par in machine de test. De préférence, le programme de test comprend également l'établissement de points de contrôle dans le logiciel à tester. En pratique, l'étape est réalisée automatiquement par le post-processeur. D'autres caractéristiques et avantages de l'invention apparaitront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels - la figure 1 est un schéma de principe très général, d'un dispositif selon l'invention; - la figure 1A est un schéma plus détaillé des constituants matériels de la machine de test; - la figure 2 est un schéma encore plus détaillé de la sonde 6 des figures 1 et 1A, et de ses connexions externes; - les figures 2A et 2B sont deux schémas semblables à la figure 2, mais illustrant respectivement deux états différents du dispositif; - la figure 3 est un schéma détaillé de la carte 3 de la figure lA; - la figure 4 est un schéma détaillé de la carte 4 de la figure 1A; - la figure 5 est un schéma détaillé de la carte 5 de la figure 1A;; - la figure 6 est un schéma semblable aux figures 1 et 1A, mais illustrant aussi des composants logiciels du dispositif; - la figure 7 est un schéma d'ensemble, principalement logiciel, du dispositif; - la figure 8 est un schéma du post-processeur; - la figure 9 est un schéma de l'interpréteur; - la figure 10 est un schéma de la gestion d'une table des symboles; et - la figure 11 est un schéma du compilateur. Les dessins annexés comportent, pour l'essentiel, des informations de caractère certain. Ils pourront donc non seulement éclairer la description détaillée ci-après, mais aussi, le cas échéant, contribuer à la définition de l'invention. Sur la figure 1, la référence 1 désigne un coffret contenant une machine de test et des interfaces matériels, selon l'invention. Le coffret 1 est relié à un terminal clavier-écran 11, ainsi qu'à une imprimante 12. Il est encore relié par une liaison multifilaire à une sonde 6, laquelle est à son tour reliée à la machine sous test 9, en un connecteur 60A de celle-ci. La figure 1A montre que le coffret 1 comprend une carte processeur 13, le processeur pouvant être le modèle 8086 d'INTEL CORPORATION, relié à un bus principal 20 satisfaisant la norme IEEE 796, ou MULTIBUS (marque déposée). La carte processeur 13 est directement reliée aux organes 11 et 12 déjà cités. Elle peut être équipée d'un module mathématique pour les calculs en virgule flottante, vendus sous la référence ISBC 8605 par la société INTEL. Le système d'exploitation peut être iRMX 86 d'INTEL. Par le bus principal 20, la carte processeur est reliée à une mémoire vive dynamique 16 de capacité 1 mega octet. Elle est reliée de même à un coupleur 17 vers une unité à disque dur 18 (disque Winchester 5,25 pouces ou 13 cm; 25 Megaoctets non formatés) et une unité à disquette 19 (disquette 8 pouces ou 20 cm; 1 Megaoctet). Une carte d'interface 14 (Intel 544, au standard RS232) permet la liaison du bus principal 20 avec un système de développement 15, sur lequel on reviendra plus loin. Le coffret 1 comprend d'autres éléments plus spécifiques de la présente invention, regroupés dans le cadre 2. Il s'agit d'une unité d'interface spécifique 3, d'une unité de coincidence 4, et d'une unité de mémoire de trace 5, reliées individuellement au bus principal 20. Ces unités sont également interconnectées par un bus d'interface 25 ou BLIC. L'unité d'interface spécifique 3 est reliée à la sonde 6 déjà citée, qui à son tour est reliée à la machine sous test 9. On supposera à titre d'exemple que le processeur de cette machine sous test 9 est le modèle 68000 de MOTO ROLA, ou un modèle de la même famille. La figure 1 montre que la machine sous test possède, à l'emplacement du microprocesseur, un connecteur 60A muni de 64 broches dans le cas considéré. Les figures 1, 1A et 2 montrent que le microprocesseur 68000 est implanté dans la sonde 6 elle-même, où il porte la référence numérique 60. Les bus sont décomposés en leur parties données (D) et adresses (A) sur la figure 2; ces deux parties sont regroupées sur les figures 2A et 2B. Un premier tampon d'entrée-sortie 61 assure la liaison entre le bus 64 (bus privé) du microprocesseur 60 et le bus interne de sonde 63, relié à la machine sous test 9. Ce bus interne 63 arrive sur un deuxième tampon 61-1, après lequel il est noté 63-2, et rejoint la carte d'interface 3. Un troisième tampon d'entrée-sortie 62 permet aussi la liaison du bus 64 au bus 64-2 d'une mémoire 65 à double accès. Ce bus 64-2 arrive aussi sur un registre de validation 67, et est relié au bus 63-2 par un quatrième tampon 62-1. Un registre de fonctions 68 est placé sous le contrôle de la carte d'interface spécifique 3, et d'une logique 69 pour la gestion de l'interruption arrivant de la carte 3 sur la ligne 66. La logique 69 est elle même contrôlée par le registre de validation 67. Le registre de fonctions 68 pilote les tampons 61 et 61-1 et de même 62 et 62-1, par leurs entrées /OC (Outpout Control). Il pilote aussi des tampons 68-1 et 68-3, qui recoivent en entrées des commandes 60C provenant du microprocesseur 60, et des commandes 63-2C (ou "fonctions" SAEL) provenant de la carte 3. Ces commandes sont appliquées soit à la machine sous test 9, par le bus 68-2, soit à la mémoire à double accès 65, par le bus 68-4. Les signaux /AS, /LDS, /UDS, /W et /DTACK sont respectivement - AS - Phase de validation des adresses MP ou SAEL - LDS - Validation d'un octet d'adresse paire - UDS - Validation d'un octet d'adresse impaire - W - Validation lecture/écriture - DTACK- Acquittement caractéristique de l'échange asyn chrone. Les signaux A, B, S1, S2, /val A, /Val B, /val S2,/val cible, /DIRS et /HMP sont respectivement A - Connexion du MP (60) avec la mémoire double ac cès (65) B - Connexion du MP (60) avec la machine sous test (9) S1 - Connexion de la carte interface (3) avec la ma chine sous test (9) S2 - Connexion de la carte interface (3) avec la mémoi re double accès (65) val A val B ) signaux dynamiques, issus des signaux val S1 ) A, B, S1, S2 et AS val S2 HMP - Horloge micro processeur DIRS - Signal issu de la carte interface (3) validant le sens de transfert des informations. Un système matériel (non représenté) gère la priorité d'accès dans le cas de demandes simultanées d'accès à la mémoire 65. Un sémaphore, implanté dans cette mémoire 65, gère de façon logicielle les enchainements de tâches. Le microprocesseur 60 est relié, à travers le tampon 62 (bus et adresse) au registre de validation 67 de la logique 69, qui gère l'interruption à destination du registre de fonctions 68. Ainsi, le microprocesseur 60 est maître des conditions dans lesquelles le registre de fonctions 68 peut changer d'état. Ceci lui permet de gérer les sauvegardes nécessaires, lors de chaque transition (compteur ordinal et état du calculateur, sauvegardés dans la machine sous test 9; autres registres sauvegardés dans la mémoire 65). Le dispositif de la figure 2 peut fonctionner de deux manières, que l'on décrira maintenant en référence aux figures 2A et 2B. Sur la figure 2A, c'est le logiciel industriel à tester qui se déroule, et le microprocesseur déporté 60 est maitre. La mémoire à double accès 65 est, dans ce cas, inutilisée. On se trouve donc dans une situation où le microprocesseur 60 travaille exactement comme s'il était seul avec la machine sous test 9. La carte d'interface 3 "espionne" le bus mémoire du microprocesseur 60. Elle en reçoit les différents signaux caractéristiques, à savoir adresse, données et commande. Ces échanges mémoires ainsi espionnés peuvent être transmis, par le bus d'interface BLIC 25, aux cartes de coîncidence 4 et de trace 5 (figure 1A). On verra plus loin que la carte de coincidence 4 permet notamment la reconnaissance d'une configuration programmée par l'utilisateur. Dans ce cas, le microprocesseur 60 peut recevoir une interruption (liaison 66), qui va le dérouter. L'ensemble du dispositif est alors commuté sur son second mode de fonctionnement. Celui-ci est illustré sur la figure 2B, où l'on voit que le bus 63 de la machine sous test 9 est maintenant contrôlé par la carte d'interface spécifique 3. Le bus 64 du microprocesseur déporté 60 communique avec la mémoire à double accès 65, de même que le bus 63. Dans ces conditions c'est le processeur 13 de la machine de test qui est maître. Il peut - soit accéder à la mémoire à double accès 65 afin de positionner un sémaphore permettant la relance du microprocesseur 60 sur la mémoire sous test (retour la configuration de la figure 2A, lire ou modifier la table des registres que le processeur 60 a sauvegardés dans la mémoire double accès 65. Cette table sera rechargée par le proces seur 60 lors de l'opération de relance. - soit accéder à la mémoire de la machine sous test 9 afin de charger un programme, . lire ou modifier des instructions ou des données, visualiser une zone mémoire, lire ou modifier les registres sauvegardés lors du déroutement (compteur ordinal, état du calcula teur). Le registre de fonctions 68, accessible uniquement par la machine de test, permet de connecter le BUS 63 soit sur la machine sous test, soit vers la mémoire double accès. Pendant ces opérations, le microprocesseur déporté 60 tourne sur un programme d'attente contenu dans la mémoire à double accès 65. Dans la configuration de la figure 2B, le microprocesseur 13 de la machine de test peut donc effectuer des tâches de différentes natures comme - contrôle l'état de mise sous tension de la machine sous test 9; - lecture ou modification des registres internes du microprocesseur 60; - lancement du logiciel industriel à tester à partir d'une adresse particulière; - espionnage de l'évolution des paramètres, ou modification de la valeur de ceux-ci; - arrêt du logiciel industriel temps réel. Un schéma partiellement détaillé de la carte 3 d'interface spécifique est donné sur la figure 3. Le bus 20 (Multibus) est relié à une logique de contrôle/ commande 30, par l'intermédiaire d'un circuit (habituel) de gestion de l'interface Multibus, noté 31. Le bus 20 est également relié à une logique de gestion 32 (contrôlée par la logique 30) d'une pile 33, dont la capacité est ici 4K x 16 bits. La logique 30 contrôle aussi trois logiques d'émission/réception, 34A, 34C et 34D, propres à interconnecter respectivement les parties d'adresse, de fonctions (commandes) et de données du bus interne de sonde 63-2 et du bus 25 dit BLIC. En outre, la logique 34A permet de faire passer les adresses du Multibus 20 sur la voie d'adresse 63-2A du bus 63-2. De son côté, la logique 34D permet d'échanger des données du Multibus 20 ou du bus 63-2D (parties données) avec la pile 33, ou avec le bus BLIC, en sa partie donnée 25D (pour la recopie du bus 63 dans le bus 25). Enfin, la logique 30 pilote encore un circuit de génération des interruptions 35, en fonction du contenu des lignes LSC et LSE que l'on décrira plus loin. Les interruptions sont engendrées vers le microprocesseur 60 (ligne 66) ou vers le microprocesseur 13 (ligne 36). La carte d'interface spécifique 3 a donc deux fonctions essentielles : - élaboration du bus d'interface BLIC 25, à destination des cartes de coincidence 4 et de mémoire de trace 5; - élaboration d'ordres à destination du microprocesseur déporté 60 de la machine sous test, sous le contrôle du processeur 13. Le bus interface 25 est une recopie du bus mémoire du microprocesseur 60. Dans le cas d'un modèle 68000, il comporte, notamment : - 24 signaux d'adresse (A10 à A123); - 16 signaux de données (D10 à D1F); - 8 signaux de contrôle (C10 à C17); - 4 signaux de synchronisation primaires LPC0 à LPC3; - 8 signaux de synchronisation secondaire LSC0 à LSC7; - 2 signaux de synchronisation externe LSE0, LSE1; - 2 signaux d'horloge HI et HC. En référence à la figure 4, on décrira maintenant un mode de réalisation particulier de la carte de coincidence 4. On note maintenant par 25 les seules 48 lignes correspondant aux signaux d'adresses, aux signaux de données et aux signaux de contrôle énumérés plus haut à propos du bus d'interface. Le symbole 250 rappelle que les signaux d'horloge sont appliqués aux circuits de la figure 4. Les 48 lignes notées 25 sont appliquées comme suit - 16 lignes consécutives à un premier comparateur primaire 40-1; - 16 lignes à une première mémoire de coïncidence 41-1, de capacité 4 K fois 16 bits, associée au comparateur primaire 40-1; - 16 lignes consécutives à un second comparateur primaire 40-2; et - 16 lignes à une seconde mémoire de coïncidence 41-2, également de 4K 16 bits, associée au comparateur 40-2. La détection de coïncidence instantanée sur un comparateur primaire 40 s'effectue sur un mot de 32 bits. Ce mot se décompose en - 16 bits d'information dont la coïncidence est obtenue par la détection à 1 d'un bit dans une mémoire 41 de 4 K 16 bits. La génération du contenu de cette mémoire est obtenue au moyen d'une relation image bit - valeur d'expression sur 16 bits. - 8 bits de complément d'adresse permettant de situer le bloc mémoire de 4 K 16 bits dans l'espace mémoire adressable (notion d'adresse de base par page de 64 K bits pour un espace défini sur 24 bits). Ces 8 bits sont à masquer lors d'une synchronisation sur une valeur de donnée. - 8 bits de procédure permettant de caractériser la synchronisation. Chacun de ces bits est masquable individuellement. On trouve par exemple les signaux suivants * Ecriture ou lecture * Instruction ou donnée * Superviseur ou utilisateur * Immédiat ou différé * Mémoire ou entrée-sortie * etc.. pour les bits restant disponibles. Seul le comparateur primaire 40-1 permet une comparaison du type > , Les fonctions servent uniquement au test sur le complément d'adresse de 8 bits. Pour affiner le point de seuil de synchronisation, il est alors nécessaire d'utiliser le second comparateur 40-2. Si, par exemple, on veut se synchroniser dès que l'on accède à une adresse supérieure à 81 200 hexadécimal, il faut - initialiser la base du comparateur 40-1 à 90 000 hexadécimal, - initialiser le comparateur 40-1 à la fonction > , - initialiser la base du comparateur 40-2 à 80 000 hexadécimal, - initialiser à 1 la mémoire 41-2 du comparateur 40-2 pour les adresses 1201 à FFFF en hexadécimal. La relation OU entre les synchronisations primaires est obtenue par la définition du câblage sur un bus 25-1 (bus de comparateur primaire à quatre fils LPCO-3), au moyen d'un configurateur logiciel primaire. (On peut recevoir,sur un même fil, plusieurs sorties de comparateurs primaires). Cette définition, générée par le logiciel, agit sur les émetteurs de bus 42-1 et 42-2. La relation ET entre les huit types possibles de synchronisations primaires est obtenue par comparaison instantanée, au niveau des comparateurs secondaires, d'une configuration de ces huit synchronisations à une configuration prédéfinie (par logiciel). On notera que sont prévus deux comparateurs secondaires 44-1 et 44-2, accompagnés d'un comparateur auxiliaire 44-3, de redémarrage (RESTART). Tous trois reçoivent les sorties respectives LPI 0 et LPI 1 des comparateurs primaires 40-1 et 40-2, le bus 25-1 ou bus LPC, et, à travers un récepteur de bus 48-2, les deux fils LSE O et 1 d'un bus 25-3 de synchronisation externe. La relation PUIS est obtenue uniquement au niveau du comparateur secondaire 44-1. Son principe est de définir une séquence de configurations instantanées du bus de synchronisation primaire et de les stocker dans une mémoire 45 (256 postes maximum de 8 bits chacun). A chaque comparaison instantanée réussie, on passe à l'attente de la suivante par incrémentation d'un compteur 46. La séquence complète est obtenue lorsque le compteur arrive en débordement. La relation RESTART sur une séquence permet de réinitialiser le compteur 46 d'adresse mémoire sur le début de la séquence, lorsqu'une configuration particulière du bus de synchronisation primaire 25-1 a été détectée par le comparateur 44-3. En résumé, les sorties des deux comparaisons primaires correspondent à des Liaisons Primaires Internes (LPI) qui peuvent être connectées soit directement à un comparateur secondaire de la même carte de coïncidence, soit aux Liaisons Primaires Communes (LPC) au travers d'un configurateur logiciel primaire. Ce dernier type de connexion a pour but soit la réalisation de fonctions de type OU, soit d'utiliser les synchronisations LPI sur d'autres cartes coïncidences au travers des liaisons LPC. De leur côté, les liaisons LSE (bus 25-3) peuvent comme les lignes LPI soit transiter par le configurateur logiciel primaire, soit être connectées directement aux comparateurs secondaires, comme représenté. Les signaux LSE sont engendrés, - soit à partir d'un bus 25-2 en LSC 0-7, décrit ci-après, à travers l'émetteur de bus 48-1, - soit à partir de signaux extérieurs calibrés, venant d'un éventuel autre dispositif analogue (ensemble 2, figure 1A), ou bien d'origine indépendante. L'ensemble des entrées des comparateurs secondaires 44-1 à 44-3 forme un bus de synchronisation primaire (BSP). Les sorties des trois comparateurs secondaires (on peut utiliser indépendamment les comparaisons n0 1 et n0 2 si on n'exploite pas leur fonction privilégiée de fonction PUIS ou RESTART) associées à la sortie du compteur, forment quatre liaisons secondaires internes (LSI). Elles sont connectées aux liaisons secondaires communes (bus 25-2 ou LSC 0-7) au travers d'un configuration logiciel secondaire défini par les émetteurs de bus 47-1 à 47-4. Ce type de connexion a pour but la réalisation de fonctions OU (seule fonction logique disponible au niveau secondaire) et l'utilisation de ces synchronisations (LSI) sur d'autres cartes de coïncidence au travers des liaisons LSC- (sur un même ensemble 2) ou LSE (vers un autre ensemble 2). L'entrée du circuit de sélection des actions (50, figure 5) est constituée par - les huit liaisons secondaires communes (LSC), - les deux lignes de synchronisations externes qui transitent soit directement, soit au travers du configurateur logiciel secondaire. Leur origine est celle qui est décrite lors de la définition du bus primaire (BSP). L'ensemble des entrées du circuit de sélection des actions forme un bus de synchronisation secondaire (BSS). Ce circuit 50 est contrôlé depuis le bus principal 20, à travers un registre de commande 53. Il permet la validation, l'écriture, et l'arrêt de la mémoire de trace (proprement dite) 56. Celle-ci reçoit les 48 fils du bus BLIC 25 à travers un registre d'écriture 55-1. Les mêmes entrées de la mémoire 56 peuvent être alimentées depuis le bus principal 20, à travers un registre de profil 55-2. La mémoire de trace 56 est organisée en mots de 80 éléments binaires, correspondant à une information enregistrée sur une profondeur de 4 K mots. Cette information se décompose en - 24 bits d'adresse, - 16 bits de donnée, - 8 bits de procédures (les mêmes que ceux décrits au niveau de la carte coïncidence), - 24 bits d'horloge (horloge à pas variable de 0,1 microseconde à 25,6 microseconde réglable par logiciel par incrément de 0,1 microseconde. Ceci permet des temps de 1,68 s max à 429 s max). L'horloge est définie par un compteur 55-3 sous le contrôle d'un circuit 54 de sélection du pas piloté par le bus 20. - 7 bits d'origine (caractéristique de la liaison LSC ou LSE qui a déclenché l'enregistrement), - 1 bit significatif de l'arrivée de la synchronisation. Le format de l'information enregistrée est fixe. Les huit derniers bits forment le complément, défini par le circuit 55-4. La mémoire 56 est également munie d'un registre de lecture (entrée 80 bits; sortie 16 bits) connecté au bus principal 20. Sont encore prévus un compteur d'écriture 56-1, et un compteur de lecture 56-2, tous deux à sortie sur 12 bits, pour correspondre à l'adressage de 4 K mots dans la mémoire 56. La figure 5 montre de plus - un compteur d'arrêt 51-1, recevant le signal d'écriture dans la mémoire 56, et dont la sortie va sur le circuit 50 de séquencement, ou "sélection des actions"; - un compteur de débordement 51-2, dont l'entrée est le signal écriture/lecture (mémoire 56) et dont la sortie, sur 12 bits, est incorporée au bus principal 20. Enfin, une interface 52 utilise la sortie débordement du compteur 51-2, ou la sortie arrêt du compteur 51-1, pour engendrer une interruption générale (carte processeur 13) sur le bus principal 20. La mémoire de trace de la figure 5 peut enregistrer les informations (garder la "trace") de deux manières : - mode continu, c'est-à-dire à chaque pas "programme" après la validation à enregistrer, - mode sélectif, c'est-à-dire à chaque synchronisation enregistrement" après la validation "enregistrer". Les actions possibles au niveau de la carte 5 sont - arrêt du calculateur de test, - génération d'une interruption au calculateur contrôlé, - génération d'une interruption pour l'ensemble 2 (figure lA), - validation d'enregistrement de trace, - enregistrement d'une information en mémoire de trace, - invalidation d'enregistrement de trace. Le circuit de sélection des actions 50 privilégie certaines actions en réponse à des liaisons LSC précises, ce qui permet une simplification du matériel. Les actions associées à chacune des lignes LSC ou LSE présentes à l'entrée du circuit 50 peuvent être définies à l'avance, par exemple comme indiqué dans le tableau de l'Annexe I. L'enregistrement de trace par la mémoire 56 peut être permanent ou limité. L'enregistrement permanent est un enregistrement circulaire (bouclé en continu) sur toute la profondeur de la mémoire de trace. L'enregistrement limité intéresse un nombre limité d'informations, par exemple selon les possibilités suivantes * début : - 256 avant la synchronisation + (4K - 256) après la synchronisation * fin : -(4K-256) avant la synchronisation + 256 après la synchronisation * centré : - 2K avant la synchronisation +2K après la synchronisation * partiel : enregistrement par page de 256 informations (maximum) après une synchronisation de validation. L'exploitation de la mémoire 56 peut s'effectuer simultanément à l'enregistrement. Un compteur 56-1 donne le nombre d'informations disponibles. L'acquisition des informations s'effectue par un processus de pile, à l'aide du compteur 56-2. Le compteur de temps est exprime en binaire (compteur 55-3). Le bit d'arrivée de synchronisation a pour but de se repérer en trace limitée (sauf partiel). Le débordement mémoire de trace (compteur 51-2) ou la fin d'un enregistrement limité (compteur 51-1) peut engendrer les actions suivantes arrêt calculateur, ou interruption vers le système d'exploitation. Le contrôle d'une trace qui ne se produit jamais ou qui ne se termine pas, s'effectue à l'aide d'un décomptage de temps par logiciel. Un bit Autorisation valide ou non le fonctionnement de la carte trace 5 de la figure 5. Des fonctions diverses sont également prévues, à savoir - remise à zéro des comparateurs primaires 40, - remise à zéro de la ou des mémoires de trace 56; - arrêt du fonctionnement des cartes 4 et 5. Dans le mode de réalisation décrit, il est souhaitable, pour un fonctionnement correct, que le cycle de la mémoire du calculateur sous test ne soit pas inférieur à 250 ns. On remarquera que le dispositif 2 espionne le bus mémoire du microprocesseur. De ce fait, il ne supporte pas l'adresse physique dans le cas d'un circuit d'aménagement mémoire (memory management unit). De ce qui précède, il résulte que la carte processeur 13 est en mesure, à travers le bus principal 20, et les différentes sections (figure 4) du bus 25, de connaître de près le fonctionnement de la machine sous test, à savoir l'ensemble 9, animé par le microprocesseur déporté 60. Pour que cette connaissance puisse devenir un contrôle de la machine sous test 9, il est encore nécessaire que la machine de test 1 connaisse la "carte" des symboles en mémoire du logiciel à tester, tel qu'exécuté dans la machine sous test 9. Une telle carte pourrait être établie manuellement, c'està-dire par un programmeur expérimenté connaissant la machine sous test et le logiciel à tester. De préférence, cette carte est établie automatiquement, à l'aide d'un outil dit post-processeur, précisément prévu pour pareille fonction. A l'heure actuelle, on peut en effet concevoir de tels post-processeurs pour des matériels du commerce, et des langages de programmation de base qu'ils supportent, comme, par exemple, le langage MODULA 2 et des processeurs MOTOROLA 68000. La machine de test 1 est maintenant en mesure de contrôler entièrement le fonctionnement de la machine sous test 9 (figure 1). Pour que ce contrôle soit efficace, il faut aussi qu'elle puisse comparer le fonctionnement de la machine 9, munie du logiciel à tester, à un comportement de référence. Cela est rendu possible par l'usage d'un langage spécialisé (dénommé IDAS par la Demanderesse) dans la machine de test 1 pour l'écriture des programmes de test. Un tel langage de programmation, spécialisé de test peut être réalisé à partir de tout langage structuré de programmation, comme PASCAL, ADA, notamment. La Demanderesse a développé son langage de test IDAS en s'inspirant de tels langages. On ne décrira pas les éléments d'IDAS tirés de ces langages, mais seulement les instructions spécifiques d'IDAS. Ce sont des instructions spécifiques déclaratives et exécutables permettant - la manipulation d'objets appartenant à un autre programme intitulé "programme sous-test", - la description d'évènements de ce programme sous-test, - l'observation du comportement du programme sous-test, - le contrôle du programme sous-test, - la simulation, par une séquence d'instructions écrites en langage IDAS, du comportement d'une instruction ou d'une procédure du programme sous-test. On trouvera en Annexe Il à la présente description l'exposé des instructions déclaratives d'IDAS, et en Annexe 111 celui des instructions exécutables, spécifiques des tests. Il apparaîtra au spécialiste que le langage de test doit impérativement contenir - les déclarations de type variable, et de type point de contrôle (déclaré ou anonyme); - la validation d'un point de contrôle anonyme; - le chargement et le lancement d'un programme sous-test. Ce sont là en effet les éléments essentiels pour contrôler le programme ou logiciel sous test, depuis la machine de test. Il est fort utile d'y ajouter la déclaration de type simulation, ainsi que la validation et l'invalidation associées. On accède ainsi à la possibilité d'intervenir dans le logiciel sous test à partir du langage de test. Pour sa part, l'instruction exécutable VERIFY permet de surveiller la satisfaction de toute condition booléenne voulue, lors de l'exécution du logiciel sous test. Si la condition n'est pas satisfaite, on peut, au choix, arrêter le logiciel sous test, ou bien garder en mémoire et imprimer les informations utiles, relatives à cette "vérification". Les instructions classiques (affectations, instructions conditionnelles, boucles...) sont utilisables dans le langage IDAS, comme dans tout autre langage de programmation structuré. Les instructions spécifiques d'IDAS sont manifestement réalisables, à l'aide des moyens matériels décrits en référence aux figures 1 à 6, car ceux-ci permettent - l'accès à toute adresse, donnée, etc, de l'ensemble matériel et logiciel sous test; - l'exécution normale, notamment en temps réel, du logiciel sous test; - l'accès et l'intervention de la machine de test d'une part dans la machine sous test (hormis son processeur), d'autre part dans ce processeur. On dispose ainsi - de moyens de contrôler la machine sous test; et - de moyens d'automatiser complètement ce contrôle, en temps réel, par le langage de test. La figure 6 fait maintenant apparaître la structure logiciel du dispositif selon l'invention. Dans la machine de test 1 est prévu le système d'exploitation 100, qui est par exemple le système iRMX 86 de INTEL. A travers une interface logiciel 101, le système d'exploitation supporte un traducteur 120 qui, comme on le verra plus loin, comporte de préférence un interpréteur et un compilateur. Le traducteur 120 communique par une interface logiciel de dialogue 103 avec le dispositif écran-clavier 11, ainsi qu'avec l'imprimante (non représentée ici). 'Il communique avec une autre interface logiciel 104 avec l'interface matériel 2 constituée comme on l'a vu des cartes 3, 4 et 5 déjà décrites, qui aboutissent à la machine sous test 9. L'interface logiciel 104 supporte également la gestion d'une table de symboles 105, sur laquelle on reviendra plus loin. Le traducteur 120 est en outre en mesure de supporter un programme de test 110, qui est précisément le programme écrit dans le langage IDAS et qui permet de comparer le comportement du logiciel sous test à un comportement de référence. Pour l'élaboration du programme de test, il est nécessaire de connaître, par un post-processeur 190, la carte des implantations mémoire de la machine sous test, munie du logiciel à tester, comme déjà relevé plus haut. Ainsi, les principaux éléments logiciels du système sont les suivants - le traducteur, mot utilisé ici pour désigner, indifféremment un interpréteur et/ou un compilateur. - la gestion de la table des symboles, - les interfaces traducteur/table des symboles, machine de test/machine sous test, . traducteur/machine de test (dialogue et système d'exploitation), le post-processeur. Ces différents éléments peuvent être développés en utilisant comme langage le PASCAL ISO niveau 0. Le traducteur est de préférence réalisé de telle sorte qu'une fois chargées, toutes les instructions du langage de test et tous les outils sont accessibles par l'utilisateur sans changement de mode. Un tel traducteur a pu être réalisé à partir du métacompilateur dit LILA (a language implementation laboratory) développé par l'Université Catholique de Louvain. En effet, après avoir codé selon le format LILA la syntaxe du langage de test et des outils IDAS, le métacompilateur LILA fournit un programme PASCAL réalisant l'analyse lexicale et syntaxique du langage. Le développement proprement dit du traducteur consiste donc à écrire les procédures sémantiques et à les insérer dans la syntaxe d'entrée LILA; on observera que la modularité de celles ci facilite la maintenance du traducteur. Le traducteur est ainsi obtenu sous la forme d'un programme codé en PASCAL ISO niveau 0, développé sur matériel IBM, et transporté ensuite sur le système INTEL 8086. La figure 7 montre que le traducteur du langage de test comprend une partie interpréteur 130 et une partie compilateur 140. L'interpréteur, par son exécution interactive, permet aussi la récupération interactive des erreurs. En effet, un message est émis immédiatement en cas d'erreur dans le programme de test; l'utilisateur peut aussitôt effectuer sa correction. L'interprétation reprend alors à partir de cette "instruction" erronée.Cette interactivité n'exclut pas le fait que l'interprétation d'un programme de test puisse se dérouler selon différentes manières - soit en exécutant interactivement, ligne par ligne, un programme qui peut être mémorisé ou non, - soit en lançant l'interprétation d'un programme existant avec ou sans point d'arrêt; - soit en combinant les deux procédés ci-dessus, c'est-àdire en exécutant un programme de test existant dans lequel on a inséré de nouvelles instructions L'utilisateur dispose ainsi d'un outil lui permettant l'élaboration interactive et progressive de ses programmes de test, qu'une unique commande permet d'appeler depuis le système d'exploitation de la machine de test. De même, une seule commande provoque l'arrêt de l'interpréteur. Par le compilateur 140, l'utilisateur dispose d'une par tie compilation du traducteur de langage de test qui correspond à une version "batch" de la partie interprétation. La mise en oeuvre et l'arrêt de ce compilateur seront semblables à ceux de l'interpréteur. Sur la figure 7, on voit également en 200 l'expression sous forme de code source du programme ou logiciel sous test. Le losange 210 représente la chaîne de production, c'est-à-dire le travail consistant à transformer ce code source en un code objet 220, qui est à proprement parler le logiciel sous test, c'est-à-dire le code exécuté par la machine sous test 9. Dans l'environnement de développement, on trouve aussi le post-processeur 190, qui reçoit le programme-source 200, et de la chaîne de production 210, des informations schématisées en 215 et comprenant un listing de compilation, des informations d'assemblage, et de lien ou "link" (cross reference). Le post-processeur 190 est en connexion avec un bloc 199 de l'environnement de test, qui permet des déclarations sous le langage de test IDAS des objets sous test. En d'autres termes, ce bloc 199 a pour fonction de permettre à 1'interpréteur 130 du traducteur 120 d'utiliser des instructions à partir desquelles la machine de test 1 saura, à travers les interfaces 3, 4 et 5, retrouver exactement ce dont il s'agit dans les emplacements mémoire ou autres de la machine sous test 9. Le programme de test lui-même est d'abord élaboré en code source IDAS comme indiqué en 110. L'interpréteur 130 travaille directement avec ce code source, de la manière déjà décrite. On notera cependant que des outils de test 180, comprenant au moins les fonctions de simulation déjà décrites, permettent la déclaration de points de contrôle IDAS 131, à l'usage du programme de test en code source 110. Les blocs 199 et 110 sont également reliés au compilateur 140, qui peut aussi établir un listing de compilation du programme de test comme indiqué en 113, et bien entendu le programme de test dans sa version en code objet comme indiqué en 115, qui donne les meilleures performances pour le test en temps réel. La figure 8 illustre le schéma de principe du postprocesseur, dont le but est de créer un lien, par une description des symboles, entre un programme IDAS et un programme à tester. Ceci permet au programme de test IDAS de manipuler symboliquement les objets du programme sous test, sans que ces symboles soient à déclarer par l'utilise sateur dans ce programme de test. Le spécialiste comprendra que le post-processeur dépend - du langage utilisé pour l'écriture du programme sous test, - des informations fournies par la chaîne de production, - de la machine cible du programme sous test. Le post-processeur effectue un travail assez proche de celui d'un compilateur, mais il doit en plus utiliser des informations d'adresses pour déterminer l'allocation des symboles. Pour cela, il est nécessaire de réaliser une analyse du code source du programme testé, extrait du listing de compilation. Les informations concernant les adresses des symboles seront celles extraites de la table d'im plantation des symboles engendrées par l'éditeur de liens. Cela est illustré sur la figure 8 où l'on voit - en 191 l'analyse du code source du programme à tester, - en 193 l'analyse de la table d'implantation de l'édi- tion de liens. Un bloc 194 réalise la synthèse et la mémorisation des informations sur les symboles, après quoi le bloc 195 est en mesure d'engendrer les déclarations de ces symboles en langage IDAS, ce qui fournit un fichier de déclaration utilisable en 199 (figure 7). L'interpréteur 130 (figure 9) a trois fonctions : - la fonction interprétation proprement dite, - la fonction gestion de la table des symboles de l'interpréteur, - la fonction interface avec l'environnement sous test. Le schéma synoptique de la fonction d'interprétation est donné sur la figure 9. Une interface homme-machine 103 répartit pour toutes les autres sous-fonctions les commandes de l'opérateur, et en retour, présente à celui-ci les résultats de ses commandes ou les messages d'erreurs qui en sont issus. Le bloc d'analyse lexicale 132 vérifie que tout mot qui lui est transmis appartient bien au vocabulaire de référence admis par le langage IDAS; si oui, elle fournit une représentation du mot reconnu à l'analyse syntaxique 131. Sinon, elle adresse un message d'erreur à l'inter face homme-machine 103. L'analyse syntaxique 131 vérifie que la phrase IDAS qui lui est fournie est correcte à l'égard de la syntaxe du langage, et réagit soit par un message d'erreur, soit au contraire par une transmission des informations vers le bloc 133 d'analyse sémantique. Ce bloc 133 procède à des vérifications statiques (contrôle de cohérence de type entre deux objets) et dynamique (non dépassement de borne en cours d'exécution), puis exécute l'instruction, en cas de demande d'exécution par l'utilisateur. Pour la vérification, elle fait appel à la gestion de la table des symboles 105, qui lui fournit tous les attributs des symboles dont elle a besoin. Pour l'exécution, elle assure certains traitements, qui peuvent faire appel à la gestion de la table des symboles 105, à l'interface avec l'environnement sous test 104, ou à la sôus-fonction de manipulation de fichier 135, (en liaison avec le système d'exploitation 101) dans le cas d'instructions IDAS relatives à des fichiers. Cette instruction 135, qui effectue les différentes opérations relatives aux instructions d'entrée-sortie, peut aussi être appelée par l'interface homme-machine, par exemple pour éditer un programme de test, ou encore par l'analyse sémantique lorsque celle-ci a traité des instructions d'entrée/sortie ou des outils spécifiques IDAS qui nécessitent la lecture d'un fichier. La figure 10 illustre la gestion de la table des symboles, qui est la structure centrale dans laquelle sont archi vées toutes les informations manipulées dans l'environnement de l'interpréteur. En 105-1 sont schématisés trois outils disponibles, qui permettent - la création de la table, par initialisation de la table ou définition d'un symbole dans celle-ci, - la consultation de la table, par lecture d'un symbole qui peut être complète ou partielle (type, valeur, adresse), - la modification de la table qui peut être l'écriture de la valeur d'un objet ou la suppression d'un symbole. L'accès à ces différents outils se fait par une interface standardisée illustrée en 104 et comprenant en 104-1 le décodage des mnémoniques de commande, en 104-2 la mise en forme des paramètres, et en 104-3 la constitution de la liste des résultats et du message de retour. L'interface 104 avec l'environnement sous test (figures 7 et 9) comporte une partie logicielle, à laquelle s'ajoutent les cartes d'interface 3, 4 et 5 déjà décrites. L'ensemble 104 comprendra tout d'abord une interface avec la machine sous test, qui a pour rôle d'adapter les différentes commandes demandées par la fonction interprétation ou compilation à la machine sous test, et notamment - conversion pour les lectures/écritures des variables sous test, par exemple si le mode flottant est différent entre la machine de test et la machine sous test), - mise en forme des paramètres pour l'appel aux fonctions de l'interface standardisé (pour les lectures et écritures en mémoire ou registre et également pour le chargement et l'exécution de programmes sous test par exemple). L'ensemble 104 comprend aussi une interface standardisée qui a pour but d'élaborer, à partir des commandes qui lui sont transmises par l'interface de la machine sous test, une succession d'appels aux fonctions "physiques" assurées par l'interface spécifique Enfin, l'ensemble 104 comprend aussi une interface spécifique, constituée de toutes les procédures physiques de plus bas niveau qui permettent d'exploiter l'interface matériel - lecture d'un mot mémoire d'un registre écriture, - mise en place d'un point de synchronisation, - mise en place du mode de fonctionnement du calculateur (pas à pas par exemple), - exploitation de la mémoire de trace. Cette partie logicielle est pratiquement la seule qui dépend de l'interface matériel et de la machine sous test 9. La figure 11 est un schéma synoptique du fonctionnement du compilateur 140. L'analyse syntaxique 141 vérifie que le programme de test en entrée du compilateur est conforme à la syntaxe du langage IDAS. Elle utilise pour cela une interface 149 de lecture du code source IDAS, qui délivre les lignes IDAS une à une, ainsi qu'une unité 142 d'analyse lexicale délivrant des unités lexicales une à une. Des contrôles sémantiques sont effectués par un bloc 143 qui vérifie notamment l'existence ou la non-existence de noms, la compatiblité de type, les contrôles sur les paramètres de procédure. Les éventuelles erreurs sont traitées en 144 par la production d'un message d'erreur convenable après quoi il est possible en 145 d'engendrer le listing IDAS. A partir de chaque instruction IDAS, on engendre en 150 une suite d'instructions PASCAL réalisant la même fonc tion. L'unité 131 peut alors engendrer le fichier PASCAL, sous forme de code source, qui après compilation PASCAL en 152 et liaison en 153 devient le module de code source qui peut être chargé dans la machine de test. En 105 est prévue une table ou catalogue dynamique des symboles (de test ou sous test) manipulés dans le programme de test IDAS. Cette table est constituée à la déclaration des symboles et peut être explorée à tout moment de l'analyse du programme de test. Elle est exploitée au moyen d'un module de procédure d'accès 104, qui constitue une interface standard avec toutes les fonctions du compilateur. Cette table est différente de celle de l'interpréteur car les informations qu'elle contient et l'exploitation que l'on en fait sont distinctes. En 160 est prévue une table de texte élémentaire PASCAL pour l'usage du traducteur 150, qui utilise aussi les bibliothèques 161 des noms de fonctions PASCAL précompilées, à l'usage du langage IDAS. L'édition de liens 153 fait aussi référence à des fonctions précompilées schématisées en 152, et comprenant - des fonctions de conversion, - l'interface avec l'environnement sous test qui est identique à celle de la fonction interprétation, - des routines d'erreur d'exécution, - des procédures internes générales. Comme déjà indiqué, c'est après cette compilation que l'on obtient les meilleures performances du programme de test, qui va définir le comportement de référence auquel on va comparer le comportement du logiciel en code objet à tester. Dans ce qui précède, la machine de test et la machine sous test sont deux machines physiquement séparées. Mais il est possible d'adopter une architecture matérielle différente. Par exemple, la machine sous test peut être simplement simulée (ou "émulée") dans un ordinateur hôte, qui joue le rôle de machine de test, et prend alors en charge, en outre, les fonctions d'interface selon l'invention. Bien enténdu, d'autres variantes de l'invention sont envisageables. ANNEXE I Actions Arrêt CP IT vers IT vers Validation Invalida- Enregistre calculateur Intel trace tion trace ment trace Lignes LSC LSC0 X X X X LSC1 X X X X LSC2 X X X X LSC3 X X LSC4 X X LSC5 X X X X LSC6 X X X LSC7 X X X LSEX X X X X X X ANNEXE II INSTRUCTIONS SPECIFIQUES DECLARATIVES DU LANGAGE DE TEST IDAS II. 1 DECLARATION DE TYPE VARIABLE DE PROGRAMME SOUS-TEST En règle générale, les variables sous-test peuvent répondre àux critères suivants 1) leur représentation est la même que celle des types suivants du langage de test : entier, fixe, flottant, booléen, chaîne de caractères, chaîne de bits. 2) leur type ou leur méthode d'accès sont spécifiques à la machine ou au langage sous-test. La prise en compte de ces critères amène à prédéfinir des types TESTED. Ces types établissent une correspondance entre les divers types de base et adressage du langage sous-test et les types IDAS. TYPE SOUS TEST TYPE TESTED IDAS Integer $ & NT32 Short integer $ & NT16 Real $ & LOT Boolean $ & OOL Logical $ & IT32 Short logical $ & IT16 Fixed xxx $ & IXxxx Short fixed xxx $ & FIXxxx String xxx $ & ARxxx Un autre type, associé à une variable assembleur est ajouté à cette liste : $ & ARASS. Le mode d'adressage est indiqué par la deuxième lettre du nom du type sous-test ; $ qui peut prendre les valeurs A, R ou P pour respectivement un adressage . Absolu, Relatif ou Pointé relatif. Ces déclarations de types prédéfinis sous-test sont produites par le post-processeur du langage sous-test, par exemple comme suit TYPE $AFIX~3 is TESTED FIXED (-3) TYPE $RFIX~3 is TESTED FIXED (-3) TYPE $AFIXO is tested FIXED (0) TYPE $PENT32 is TESTED INTEGER (32) Les autres types sous-test sont des types composés de types sous-test prédéfinis - structure dont les champs sont de type sous-test préddfini ou énumératif, - tableau dont les éléments sont d'un type sous-test prêdé- fini, - tableau de structure sous-test. ex TYPE STRUCTAR IS TESTED ARRAY (1..10) OF RECORD CH1 : SAPENT16 AT OF WORD; CH2 : SABIT16 AT 1*WORD; CH3 : $ACAR8 AT 2*WORD; END RECORD II.2. DECLARATION DE TYPE POINT DE CONTROLE Deux types point de contrôle peuvent être définis, le type anonyme point de contrôle et le type déclaré point de contrôle Il.2.1 Type déclaré point de contrôle Type point de contrôle : CHECKPOINT. Ce type point de contrôle ne peut être défini que pour des objets du programme sous-test. Un objet point de contrôle déclaré est - soit un point d'entrée : entête de procédure sous-test, label sous-test ou numéro de ligne, - soit un point d'arrêt : label sous-test ou numéro de ligne. Ils correspondent donc à une adresse instruction sous-test II.2.2 Type point de contrôle anonyme Le type point de contrôle anonyme n'a pas d'utilité en tant que type déclaré. Un objet de type point de contrôle déclaré correspond à une adresse instruction dans la machine sous-test; alors qu'un objet de type point de contrôle anonyme n'a aucune réalité dans la machine sous-test. Il n'est matérialisé que dans le système d'observation de la machine sous-test. Syntaxe déclaration~d' objetbe typepcint~decontrale ::= identificateur : "CHECKPOINT" Action~matériel (Action~logiciel ] Action matériel ::= DETECTION IS Ccondition de synchronisationl fonction~matériel Fonction~matériel ::= TRACE ((liste d 'identifications) I STOP Action~logiciel ::= ACTION IS bloc Sémantique La condition de synchronisation est une condition composée portant sur des variables sous-test ou sur des valeurs du compteur ordinal identifié par $PP. Les opérateurs de synchronisation sont "OU" et "PUIS". Ce dernier permet de décrire des conditions ordonnées dans le temps. L'opérateur "OU" est prioritaire. Ces opérateurs permettent de lier des conditions~simples. Condition simple ::= (identificateurlSPPIopérateur de comparaison expression IIN(liste d 'intervalle expression)) ) Ex : ( $PP IN (PROC!1 .. PROC!3, PROC!6, PROC!10)) L'action matériel 2 types d'action~matériel sont disponibles - enregistrer en mémoire de trace par la fonction TRACE. si la fonction TRACE n'est pas paramétrée, la condi tion~de~ synchronisation est obligatoire. On enregis tre alors l'état du bus, à chaque fois que cette condition est réalisée. Ex à chaque fois que le programme sous-test affecte 1 à X. si la fonction TRACE est paramétrée, la liste d 'identificateurs représente l'ensemble des variables sous-test à surveiller. Celles-ci doivent être définies sur 16 bits. La surveillance de ces variables peut être validée par une condition~ de synchronisation (l'invalidation n'est pas prise en compte). La surveillance provoque l'enregistrement en mémoire de trace de l'état du bus, lorsque l'une des variables est modifiée. Cet enregistrement permet de connaître la nouvelle valeur de cette variable. Ex (SPP = PROC!100) TRACE Dès que l'instruction 100 du programme sous-test est exécutée, le système espionne les variables EX et EY jusqu'à la fin. - arrêter le calculateur sous-test par la fonction STOP. La condition de synchronisation est obligatoire. Lorsque cette condition est détectée, l'exécution du programme sous-test est arrêtée. L'action logiciel Pour chaque enregistrement en mémoire de trace, la machine de test exécute l'action~logiciel décrite dans le point de contrôle qui a provoqué cet enregistrement. Cette action se déroule alors que le programme sous-test poursuit son exécution, elle ne doit donc pas faire référence à la machine sous-test. Les opérations suivantes sont donc interdites ancement/chargement d'un programme sous-test, - accès en lecture/écriture à la machine sous-test, - validation de points de contrôle. L'enregistrement courant en mémoire de trace est référencé par la variable prédéfinie : TRACE~MEMORY. L'utilisateur a alors accès à 2 informations - TRACE~MEMORY.ADDRESS contenant l'adresse de la variable ou la valeur du compteur ordinal. - TRACE~MEMORY.VALUE contenant la valeur sous la forme BIT~SLICE (16) de la variable ou le code opération pour le compteur ordinal. L'arrêt du programme sous-test se fait - soit par un point de contrôle ayant STOP comme fonction~ matériel, - soit lorsque la mémoire de trace est pleine. Exemple CHECK : CHECKPOINT DETECTION IS TRACE (fX, Ỳ) ACTION IS BEGIN IF TRACE MEMORY.ADDRESS= X'ADDRESS THEN PUT "fX =", TRACE~MEMORY.VALUE ELSE PUT "Ỳ =", TRACE~MEMORY.VALUE END IF END II.3 DECLARATION DE TYPE SIMULATION Syntaxe Déclaration de simulation ::= identificateur :SIMULATION OF instruction~à~simuler WITH identificateur BETWEEN zone de simulation ; instruction~à~simuler ::= liste de constante CMASKED BY liste de constante3 liste de constante ::= constante { , constante ) zone de simulation ::= identificateurl C , identifica teur2 ] Sémantique Ce type de déclaration permet de définir les objets de l'entité simulation. Par la suite, on emploiera le terme instruction pour une séquence de mots (16 bits) débutant par un code opération et d'une longueur maximale de 12 mots. - Les constantes qui apparaissent dans la liste~de~constante sont de type BIT~SLICE Elles définissent . soit une instruction à simuler si l'option MASKED~BY est absente, . soit une famille d'instructions si l'option MASKED~BY est présente. Les bits à 1 du masque sélectionnent les bits significatifs de la définition de l'instruction. - L'identificateur qui suit le mot réservé WITH doit être l'identificateur d'une procédure préalablement déclarée dans le programme de test. Cette procédure est utilisée comme procédure de simulation. - Les identificateurs qui apparaissent dans zone~de~simula tion sont de type CHECKPOINT sous test (label, numéro de ligne, ...). La zone de simulation est . soit l'instruction désignée par identificateurl, si identificateurl apparaît seul, . soit la séquence d'instructions localisées entre identificateurl et identificateur2, si identificateur2 est présent. Exemple de déclaration Simulation d'un branchement à une procédure particulière dont l'adresse hexadécimale est 3FCAFE. Procédure de simulation PROCEDURE PROCSIMU BODY IS BEGIN PUT "APPEL DE PROC"; END PROCSIMU; Déclaration de la simulation CALLPROC : SIMULATION OF 20100111010111001,'3FCAFE WITH PROCSIMU BETWEEN DEBPROG, FINPROG 2#0100111010111001# correspond au code de l'instruction de branchement à simuler et '3FCAFE à l'adresse de la procédure particulière. ANNEXE III INSTRUCTIONS SPECIFIQUES EXECUTABLES DU LANGAGE DE TEST IDAS ICI.1 VALIDATION D'UN POINT DE CONTROLE ANONYME Syntaxe posede~pointsde contrôle ::= SET~CHECKPOINT (Liste d'identificateurs); Sémantique Cette instruction indique les points de contrôle à valider. Une validation annule la précédente. Lorsque la prise en compte des points de contrôle est impossible, le système d'observation de la machine sous-test étant insuffisant, un message d'erreur est affiché. Exemple SET~CHECKPOINT (CHECK1, CHECK2) ICI.2 VALIDATION D'UNE OU PLUSIEURS SIMULATIONS Syntaxe Validation de simulation ::= SET SIMULATION identificateur , identificateur i Sémantique Cette validation permet de mettre en service des simulations préalablement déclarées. Les identificateurs doivent être des identificateurs de simulation. La recherche dans le programme sous test des instructions à simuler et la modification du code sous test sont effectuées lors de la validation de la simulation. Lorsque cette recherche est infructueuse, une erreur est signalée. ICI.3 INVALIDATION D'UNE OU PLUSIEURS SIMULATIONS Syntaxe Invalidation de simulation ::= RESET~SIMULATION C identificateur (, identifi cateur i ] Sémantique Cette invalidation permet de mettre hors service des simulations préalablement validées. Les identificateurs doivent être des identificateurs de simulation. Si aucun identificateur n'est présent, toutes les simulations préalablement validées sont invalidées. III.4. CHARGEMENT D'UN PROGRAMME SOUS-TEST Syntaxe chargementd~ 'un~programme sous~test ::= LOAD Nom~de~fichier Sémantique Cette instruction effectue, dans la mémoire de la machine sous-test, le chargement d'un fichier caractérisé par son nom et de format auto-chargeable. Exemple LOAD - PROGTEST; Chargement du programme contenu dans le fichier PROGTEST. ICI.5 LANCEMENT D'EXECUTION Deux instructions permettent le lancement d'un programme sous-test; l'une adaptée au test en temps réel : START qui est à utiliser avec l'instruction SET CHECKPOINT, l'autre d'utilisation plus simple pour le test statique EXEC. III.5.1. L'ntruction EXEC Syntaxe Lancement~d~'unprogramme sous test~par~EXEC ::= EXERCE point~de~lancement ] (TO liste~de~point~d'~arrêt ] point de lancement : : = point de contrôle déclaré liste~des~paramètres~actuels liste~depointsd'~arrêt ::= pointbe contrôlebéclaré Sémantique Cette instruction effectue l'exécution d'un programme sous-test à partir d'un point de lancement jusqu'à un point de contrôle s'il en existe un défini, sinon jusqu là une sortie normale de la procédure sous-test. Lorsque l'exécution s'arrête sur un point de contrôle, celui-ci sera considéré à 1'EXEC suivant comme point de lancement Si ce dernier n'est pas indiqué. Lors d'un EXEC, il y a invalidation des points de contrôle précédemment posés. Un point de lancement est un point de contrôle particulier. Il est possible d'utiliser des variables de test ou des variables sous-test comme paramètres réels à une pièce sous-test quel que soit le mode de passage de ces paramètres (par adresse ou par valeur). Exemple EXEC PROGTEST (ESSAI) TO PCl Exécution de la procédure PROGTEST dont ESSAI est le paramètre jusqu'au point d'arrêt PC1. III.5.2. L'instruction START Syntaxe lancement~d'unprogrammesous~testparSTART START tpoint~de~lancement ] Sémantique L'instruction START, comme l'instruction EXEC, permet de lancer le programme sous-test à partir de l'adresse correspondant au point de lancement indiqué. Le système conserve les points de contrôle précédemment validés. L'arrêt de l'exécution du programme sous-test ne pourra se faire que sur un point de contrôle correspondant à un point d'arrêt (fonction coupleur STOP) ou un débordement de la mémoire de Trace. Après lancement du programme sous-test, le système MCP se met en observation sur la machine sous-test. Les actions associées aux différents points de contrôle validés sont considérés comme des tâches en attente. Une tâche est activée lorsque la condition de synchronisation lui correspondant est vérifiée. Exemple SET CHECKPOINT (ENTREE, SORTIE); START PROGTEST; Ces instructions ont pour effet de positionner les points de contrôle CHECKl et CHECK2 et de lancer le programme sous-test à partir de l'adresse PROGTEST. ICI.6 L'instruction VERIFY Syntaxe Vérification (label ] VERIFY CON fichier); message ::= constante chalne~de caractères Sémantique Cette instruction permet de vérifier si une expression booléenne est vraie. Si c'est le cas, aucune action n'est entreprise. Par contre, si l'expression booléenne n'est pas vérifiée, deux actions ont lieu - si le mot clé STOP est présent, il y a arrêt de l'exécution du programme de test et donc sortie du système IDAS. Si le mot clé STOP est absent, il y a continuation en séquence, - il y a impression du numéro de ligne de l'instruction VERIFY, suivi . soit du "message" si celui-ci est présent, soit (option par défaut) de "UNVERIFIED VERIFY". Lorsque le fichier n'est pas précisé, TO est pris par défaut. Exemple Soit à la ligne 200, l'utilisation de l'instruction VERIFY VERIFY (INTEGER ( VAR) Tant que VAR reste inférieure à 100, il ne se passe rien. Dès que VAR devient supérieure ou égale à 100, et que l'on exécute cette instruction VERIFY, il y a arrêt du programme de test et édition du message 200 : ARRET DEBORDEMENT VAR Revendications. 1. Dispositif pour le contrôle de logiciels industriels, en particulier de logiciels destinés à opérer en temps réel dans une machine informatique dite machine sous test (9), caractérisé en ce qu'il comprend - une machine informatique dite machine de test (1), implantée sur un ordinateur-hôte, - des moyens d'interface (2) propres à permettre l'espionnage du bus interne (63) de la machine sous test (9) et sa recopie selon un format standardisé, ainsi que la synchronisation avec cette machine (9) en fonction de conditions choisies portant sur des données, adresses ou commandes existant dans la machine sous test (9), et - des moyens de test (13, 16, 17, 18, 19, 100 - 195) reliés aux moyens d'interface (2), et propres à permettre l'exécution de séquences d'opérations de test sur la machine sous test (9), indépendamment de la nature de celleci. 2. Dispositif selon la revendication 1, caractérisé en ce que les moyens d'interface (2) comportent - une sonde (6), propre à une communication totale avec le bus interne du processeur (60) de la machine sous test (9); - des moyens d'interface spécifique (3), reliés à cette sonde, pour recevoir ledit bus interne, et le recopier sous la forme d'un bus d'interface (25), selon un format standardisé, et - des moyens de détection de coïncidence (4), propres à effectuer des comparaisons en temps réel portant sur des données, adresses ou commandes existant sur le bus d'interface, afin d'établir des indications de synchronisation pour le contrôle du logiciel industriel. 3. Dispositif selon la revendication 2, caractérisé en ce que les moyens d'interface (2) comprennent aussi des moyens de mémoire de trace (5), reliés au bus d'interface (25), et propres à enregistrer séquentiellement les indi- cations de synchronisation relevées par les moyens de coïncidence (4). 4. Dispositif selon l'une des revendications 2 et 3, caractérisé en ce que la sonde (6) comprend le processeur (60), déporté, de la machine sous test, ainsi que des moyens de commutation (61, 62) permettant la liaison de l1empla- cement de ce processeur dans la machine sous test soit à ce processeur lui-même dans un état normal, les moyens d'interface spécifique (3) recopiant alors le bus interne dans le bus d'interface (25), soit aux moyens d'interface spécifique (3), dans un état de pilotage direct de la machine sous test (9) à travers cette interface spécifique, et en ce que la sonde (6) comprend aussi une mémoire à double accès (65), avec gestion matérielle de priorité d'accès, reliée, dans l'état de pilotage,d'une part au processeur déporté, d'autre part au bus interne allant vers l'unité d'interface spécifique, la mémoire à double accès contenant un programme moniteur propre à faire tourner le processeur déporté sur une boucle d'attente. 5. Dispositif selon l'une des revendications précédentes, caractérisé en ce que les moyens de test sont propres à contrôler l'état de mise sous tension de la machine sous test, à lancer le logiciel à tester à partir de toute adresse particulière, à l'arrêter, à lire ou modifier les contenus des registres internes du processeur de la machine sous test, ainsi qu'à surveiller les paramètres de ce processeur et en modifier la valeur. 6. Dispositif selon l'une des revendications précédentes, caractérisé en ce que la machine de test (1) possède un processeur (13), des périphériques d'entrée/sortie (11,12), des mémoires de travail et de programme (16,17), et un bus principal (20) également relié aux moyens matériels d'interface (2), cette machine de test pouvant ainsi contrôler, à travers les moyens matériels d'interface (2), l'exécution de tout ou partie du logiciel industriel à tester, dans ses conditions normales de fonctionnement dans la machine sous test. 7. Dispositif selon la revendication 6, caractérisé en ce que la machine de test (1) reçoit aussi une carte ou table de symboles-mémoire du logiciel industriel à tester 8. Dispositif selon la revendication 7, caractérisé en ce que ladite carte (105) est élaborée automatiquement par un post-processeur du programme source du logiciel tester. 9. Dispositif selon l'une des revendications 6 à 8, caractérisé en ce que la machine de test reçoit en outre un modèle de comportement du logiciel à tester, pour comparer le second au premier. 10. Dispositif selon l'une des revendications 6 à 9, caractérisé en ce que la machine de test (1) est dotée d'un langage de test qui est un langage structuré de programmation de haut niveau muni en outre d'instructions spéciales comprenant, au moins . le chargement et l'exécution du logiciel industriel par la machine sous test, ainsi que . la définition de variables sous test, et d'au moins un type de points de contrôle, et la validation d'un tel point de contrôle dans le logiciel à tester, en ayant recours à l'unité de coïncidence, et en ce que la machine de test (1) possède également un traducteur, comprenant au moins un interpréteur (130) ce qui permet l'exécution contrôlée de tout ou partie du logiciel à tester. 11. Dispositif selon la revendication 10, caractérisé en ce que le langage de test comprend aussi des instructions permettant des simulations de toutes autres instructions, pour exécution temporaire dans le logiciel sous test. 12. Dispositif selon l'une des revendications 10 et 11, caractérisé en ce que le langage de test comprend encore une instruction permettant la vérification de toute condition booléenne voulue, en tout point de l'exécution du logiciel sous test. 13. Dispositif selon l'une des revendications 10 à 12, caractérisé en ce que la machine de test est également munie d'un compilateur (140), propre à élaborer un codeobjet, à partir d'un code source élaboré interactivement à l'aide de l'interpréteur. 14. Dispositif selon l'une des revendications 10 à 13, caractérisé en ce que les éléments logiciels (120) de la machine de test sont écrits en PASCAL ISO niveau 0, l'interpréteur et le compilateur étant développés à l'aide du métacompilateur LILA. 15. Dispositif selon l'une des revendications précédentes, caractérisé en ce que la machine de test (1) et la machine sous test (9) sont implantées dans un même ordinateurhôte. 16. Procédé pour le contrôle de logiciels industriels, en particulier de logiciels destinés à opérer en temps réel, sur une machine informatique dite machine sous test (9), caractérisé par les opérations suivantes a) espionner le bus interne (63) de la machine sous test (9), et le recopier (25) sous un format standardisé, b) établir un jeu de conditions choisies (5) portant sur des données, adresses ou commandes existant dans la machine sous test (9), et surveiller (4) la coïncidence de l'état de la machine sous test (9) avec l'une de ces conditions, et c) exécuter une séquence d'opérations de test utilisant lesdites conditions choisies, ce qui permet de définir la séquence d'opérations de test indépendamment de la nature de la machine sous test 19). 17. Procédé selon la revendication 16, caractérisé en ce que la séquence d'opération de test comprend l'une au moins des opérations consistant à contrôler l'état de mise sous tension de la machine sous test, à lancer le logiciel à tester à partir de toute adresse particulière, à I'arrêter, à lire ou modifier les contenus des registres internes du processeur de la machine sous test, ainsi qu'à surveiller les paramètres de ce processeur et en modifier la valeur. 18. Procédé selon l'une des revendications 16 et 17, caractérisé en ce que l'opération c) comprend la préparation du logiciel à tester par (1) écriture de son code-source (200) ; (2) passage à son code-objet (220), avec compilation (210) (3) établissement (215, 190, 199) d'une liste complète des symboles utilisés par ledit code-objet (220), comprenant leur carte d'implantation en mémoire dans la machine sous test (9) ; (4) écriture d'un programme de test (110), en code sour ce, dans un langage de test, tel que défini dans l'une des revendications 10 à 12, ce programme de test comprenant, au moins, un modèle de comportement du logiciel à tester ; et (5) traduction (120) du programme de test en code exécutable par la machine de test. 19. Procédé selon la revendication 18, caractérisé en ce que le programme de test (110) comprend également l1éta- blissement de points de contrôle (131) dans le logiciel à tester. 20. Procédé selon l'une des revendications 18 et 19, caractérisé en ce que l'étape (3) est réalisée automatiquement par un post-processeur (190).