Brevet FR2835936A1 — publié le 20030815

proprié est stoppé. Procédé et système d' analyse d' événements de blocage logiciel La présente invention concerne de manière générale la pro tection interne des logiciels et plus particulièrement, la détermination de la fréquence des interruptions logicielles. Un "plantage" ou un "arrêt imprévu" est un type de panne de système, défini comme une indisponibilité ou une absence de rapidité de réaction inopince due à une panne logicielle. La mesure de la fré quence des "plantages" (appelés "blocages" dans ce qui suit) ou "arrêts imprévus" dans un système est difficile sans instruments extérieurs. Ceci est dû au fait que le flux normal des opérations logicielles est interrompu quand les événements susmentionnés se produisent. Quand le flux normal des opérations logicielles est inter rompu, les parties du système conçues pour détecter et rapporter ces événements (comme les structures de "temporisateur chien de garde") ont une probabilité de fonctionnement correct réduite parce qu'elles nocessitent des parties du système pour fonctionner normalement après que l'interruption s 'est produite. Le s systèmes complexes composés de plusieurs plateformes logicielles/matérielles aggravent ces difficultés. Le manque de donnces quantitatives sur le taux d' incidents a un effet défavorable sur la capacité à gérer le développement de ces systèmes. En d'autres termes, sans savoir pleinement avec quelle fré quence ces incidents tendent à se produire en fonction de l'utilisation, il est difficile de savoir ou de prédire quand un système va atteindre une fiabilité acceptable via des itérations de cycles de test et de main tenance. n est également difficile d'évaluer l'impact des incidents sur la fiabilité générale du système. Les inconvénients associés aux techniques actuelles d'analyse de blocages logiciels ont mis en évidence le fait qu'une technique nou velle de mesure et d'interprétation des blocages logiciels est noces saire. Etant donné un programme ou une série de programmes, cette nouvelle technique doit permettre aux fabricants de trouver rapidement et efficacement les erreurs de système. Cette nouvelle technique doit aussi permettre le calcul et l'analyse de donnces de fiabilité du logi ciel. La présente invention est destince à répondre à ces besoins. Un procédé d'analyse interne d'événements de blocage dans un logiciel comprend le fait d'envoyer un premier signal de fonction nement depuis un premier point de contrôle logiciel à un journal d'évé nements. Le procédé comprend en outre le fait d'envoyer un deuxième signal de fonctionnement depuis un deuxième point de contrôle logi ciel, qui suit séquentiellement le premier point de contrôle logiciel, au journal d'événements. Le procédé comprend de plus le fait de calculer la fiabilité du logiciel à partir des donnces contenues dans le journal d'événements. Un avantage de la présente invention est qu'elle fournit un procédé de mesure d'événements de blocage logiciel. Un autre avan tage est qu'elle calcule une statistique de fiabilité de logiciel à partir de mesures d'événements de blocage. D'autres avantages et caractéristiques de la présente inven tion apparaîtront à la lecture de la description détaillée qui suit et peu vent être réalisés par les instrumentalités et combinaisons particulière ment désignces dans les revendications annexces, prises en conjonc tion avec les dessins d'accompagnement. Pour une compréhension plus complète de l'invention, cer tains modes de réalisation de celle-ci vont maintenant être décrits, à titre d'exemple, en faisant référence aux dessins d'accompagnement, dans lesquels: la figure 1 est un schéma fonctionnel d'un système d'analyse interne des événements de blocage dans un logiciel, selon un mode de réalisation préféré de la présente invention; et la figure 2 est un organigramme d'un procédé d'analyse interne des événements de blocage dans un logiciel, selon un mode de réalisation préféré de la présente invention. La présente invention est illustrce relativement à un système d'analyse interne des événements de blocage dans un logiciel, particu lièrement adapté au domaine de la conception de logiciels. La présente invention, cependant, est applicable à diverses autres utilisations qui peuvent nocessiter l'analyse interne d'événements de blocage, comme le comprendront bien les personnes du métier. En se référant à la figure 1, est représenté un schéma fonc tionnel d'un mode de réalisation d'un système 10 d'analyse interne d'événements de blocage dans un logiciel. Le système 10 comprend une série de points de contrôle idéalement incorporés dans un pro gramme logiciel (mis en _uvre ici en tant qu'opérations logicielles 12), un système d'exploitation ou une partie de matériel informatique. Les opérations logicielles 12 mises en _uvre comprennent un disposi tif de commande adapté pour recevoir les signaux de points de contrôle et les inscrire dans le journal d'événements 14. Les points de contrôle sont soit des points de contrôle logi ciels non fonctionnels, soit des points de contrôle fonctionnels, comme dans le présent mode de réalisation. Chaque point de contrôle est prévu pour envoyer un signal de fonctionnement à un journal d'événe ments 14, o le signal est enregistré puis envoyé à un postprocesseur 18 via un filtre 16. Le postprocesseur 18 mémorise les signaux dans une base de donnces de fiabilité 20 et analyse les signaux dans des rapports de fia bilité 22 contenant une routine logique d'analyse. Ensuite, les rapports de fi abilité 22 s ont an aly s é s p our améliorer le s op ération s lo g icie lle s et éliminer les blocages ou arrêts imprévus inutiles dans le système 10. Typiquement, un programmeur 24 analyse les donnces de la base de donnces de fiabilité 20 et les rapports de fiabilité 22 après que le logiciel respectif a passé un processus d'évaluation. Le processus d'évaluation est mis en _uvre sous forme d'un système d'exploitation indépendant 26 à partir du programmeur 24; toutefois, le système du progrmmeur et le système d'exploitation indépendant 26 peuvent, en variante, se réunir en un seul processeur avec lequel l'évaluation externe "sur place" n'est pas nocessaire. Dans le présent mode de réalisation, les donnces de signaux de point de contrôle sont envoyées à travers un filtre 16 pour réduire les signaux d'événements non logiciels. Ce filtre 16 facilite l'analyse des donnces logicielles en réduisant l'impact sur la statistique de fiabi lité provoqué par des donnces d'événement provenant de défauts maté riels ou d'événements extérieurs 28, comme le comprendront les per sonnes du métier. La routine logique actuellement mise en _uvre incorpore des statistiques de fiabilité typiques provenant des points de contrôle et lO leurs dates et heures associces. Les statistiques de fiabilité sont par exemple la "probabilité de succès d'amorce", qui divise le nombre d'amorces ratées par le nombre total de tentatives d'amorce, et le "Temps Moyen Entre Pannes", qui est égal au nombre de pannes pen dant le fonctionnement divisé par le temps de fonctionnement total. I1 lS est bien entendu que diverses statistiques de probabilité supplémentai res peuvent être utilisces, comme le comprendront les personnes du métier. La routine logique du présent mode de réalisation est exécu tée par un postprocesseur 18. Le postprocesseur 18 analyse les signaux de points de contrôle, facilite la création des rapports de fiabilité 22, et mémorise de manière permanente les donnces analysces et enregis trées dans une base de donnces de fiabilité 20 en vue d'un accès et d'une analyse ultérieurs. Les points de contrôle non fonctionnels sont ajoutés à la structure d'un logiciel dans le but délibéré de mesurer les pannes ou les événements logiciels. Par exemple, la partie "point de contrôle" du programme peut être ajoutée en tant que routine de service d'interrup tion qui est déclenchée par une horloge. Dans cette variante de mode de réalisation, le logiciel de point de contrôle exécute et détermine 3 0 p ério diquement l ' état du logic iel en ex amin ant le c ompteur d ' in struc tion de l'Unité Centrale (UC), ou bien en examinant les emplacements de donnces qui marquent l'état du logiciel. La présente invention inclut une programmation interne au logiciel qui enregistre le comportement du logiciel aux points de contrôle fonctionnels. Le système d'analyse interne des événements de s blocage dans le logiciel 10 nocessite au moins deux points de contrôle, cependant l' augmentation du nombre de points de contrôle augmente la précision du diagnostic et de l'analyse de donnces subséquents. Le pré sent mode de réalisation comprend quatre points de contrôle: un point de contrôle de mise sous tension, un point de contrôle de mise sous tension accomplie, un point de contrôle d'arrêt (ou extinction), et un point de contrôle d'arrêt accompli. Ces points de contrôle spécifiques ont été choisis parce qu'ils sont des points courants dans un nombre sensiblement grand de systèmes logiciels, comme le comprendront les personnes du métier. La combinaison idéale de points de contrôle com prend un deuxième point de contrôle qui suit séquentiellement un pre mier point de contrôle, o une inférence est faite à partir de donnces manquantes de l'un ou l'autre des points de contrôle, comme cela sera décrit plus loin. L'ordre dans lequel les points de contrôle sont enregistrés dans le journal d'événements 14 simplifie substantiellement l'interpré tation des donnces de panne. Par exemple, un point de contrôle de mise sous tension suivi d'un point de contrôle de mise sous tension accomplie indique une amorce réussie. Un point de contrôle de mise sous tension suivi d'un point de contrôle ou d'un signal autre que le point de contrôle de mise sous tension accomplie indique un défaut d'amorce. Un point de contrôle d'arrêt suivi d'un point de contrôle d'arrêt accompli indique un arrêt réussi. Un point de contrôle d'arrêt suivi d'un point de contrôle ou d'un signal autre que le point de contrôle d'arrêt accompli indique une panne pendant l'arrêt. Un avantage supplémentaire de l'incorporation de points de contrôle dans le système 10 élimine le besoin qui existait auparavant pour un équipement de surveillance externe ou des observateurs exté rieurs et réduit donc les coûts de la phase de développement. En référence à la figure 2, est représenté un organigramme d'un mode de réalis ation d'un procédé d' analy se interne d'événements de bloc age dans un logiciel. La logique démarre à la cas e d' opération 32 o l'on lance la mise sous tension pour le programme logiciel. Ensuite, dans la case d'opération 34, le logiciel envoie le signal de point de contrôle de mise sous tension au journal d'événements. La case d'opération 36 s'active ensuite, le logiciel achève la mise sous tension, et envoie le signal de point de contrôle de mise sous tension accomplie au journal d'événements dans la case d'opéra tion 38. La case d'opération 40 s'active ensuite, et le programme logi ciel entre dans le fonctionnement normal, qui dépend des fonctions spécifiques pour lesquelles le logiciel a été conçu. La case d'opération 42 s'active ensuite, et le logiciel com mence l'arrêt et envoie le signal de point de contrôle d'arrêt au journal d' événements dans la case d' opération 44. La case d'opération 46 s'active ensuite, et le logiciel achève l'arrêt et envoie le signal de point de contrôle d'arrêt accompli au jour nal d'événements dans la case d'opération 48. A ce stade, les donnces contenues dans le journal d'événements sont post-traitées en vue de leur stockage et analyse ultérieurs. Des étapes utiles supplémentaires 1S ont été incluses dans la figure 2 (cases SO, 52 et 53) pour donner un exemple illustratif d'un mode de réalisation de la présente invention. Après au moins un cycle complet du programme logiciel, de 11 mise sous tension à l' accomplis sèment de l' arrêt, la case 5 0 s 'active, et une interrogation est faite pour savoir si les opérations attendues se sont produites. En cas de réponse positive, le postprocesseur enregis tre les donnces de point de contrôle dans la base de donnces de fiabi lité dans la case d'opération 52 en vue d'une modification de pro gramme et d'une analyse ultérieures. Sinon, la case d'opération 53 s'active, et les donnces de point de contrôle sont enregistrces dans la base de donnces de fiabilité du postprocesseur puis analysoes dans les rapports de fiabilité du postpro cesseur. Par cette analyse, on peut générer des statistiques prédictives sur la fiabilité du système sur le terrain, comme le comprendront les personnes du métier. Du fait que le journal d'événements est préservé en stockage permanent, des donnces historiques peuvent être recucillies dans des ordinateurs ou des logiciels sur le terrain pour fournir une analyse plus complète de la performance rcelle en terme de fiabilité sur les sites des clients. I1 est important de noter que les points de contrôle sont conçus pour mesurer la fiabilité d'une applica tion logicielle qui tourne de concert avec un système d'exploitation, cdt ce proceeds points de corÈle pout ssi 6e as en Louvre en tag qua melody d'alyse de blocages de systems dxploition. D'rs ce Hi precede, on pat voir Me l'on a Spoof 1' un system amuse me dents de blocage dons an logiciel 10. It est bien entendre Me la description Hi precede mode de rda- Uson pram en purement illusive de cedes des norx modes de On specifies Hi reseat as Cons des pampas la present invasion. REVENDICATIONS 1. Procédé d'analyse interne d'un événement de blocage dans un logiciel, caractérisé en ce qu'il comprend les étapes consistant à: envoyer un premier signal de fonctionnement depuis un pre mier point de contrôle logiciel à un journal d'événements (14); envoyer un deuxième signal de fonctionnement depuis un deuxième point de contrôle logiciel, qui suit séquentiellement ladit premier point de contrôle logiciel, audit journal d'événements (14); et calculer la fiabilité du logiciel à partir des donnces contenues dans ledit journal d'événements (14). 2. Procédé selon la revendication 1, dans lequel l'envoi d'un premier signal de fonctionnement comprend le fait d'envoyer un pre mier signal de fonctionnement depuis un point de contrôle de mise sous tension. 3. Procédé selon la revendication 1, dans lequel l'envoi d'un deuxième signal de fonctionnement comprend le fait d'envoyer un deuxième signal de fonctionnement depuis un point de contrôle de mise sous tension accomplie. 4. Procédé selon la revendication 1, dans lequel l'envoi d'un premier signal de fonctionnement comprend le fait d'envoyer un pre mier signal de fonctionnement depuis un point de contrôle d'arrêt. 5. Procédé selon la revendication 1, dans lequel l'envoi d'un deuxième signal de fonctionnement comprend le fait d'envoyer un deuxième signal de fonctionnement depuis un point de contrôle d'arrêt accompli. 6. Procédé selon la revendication 1, dans lequel le calcul comprend en outre le fait de filtrer lesdites donnces dans ledit journal d'événements (14). 7. Procédé selon la revendication 1, comprenant en outre le fait de déclencher ledit premier point de contrôle interne d'ordinateur et ledit deuxième point de contrôle interne d'ordinateur au moyen d'une horloge sous forme d'interruptions de routine de service. 8. Système (10) pour analyser des événements de blocage dans le fonctionnement d'un ordinateur, caractérisé en ce qu'il comprend: un journal d'événements (14); un dispositif de commande (12) adapté pour recevoir un pre mier signal de fonctionnement provenant d'un premier point de contrôle interne d'ordinateur et envoyer ledit premier signal de fonc tionnement à un journal d'événements (14), ladit dispositif de com mande (12) étant adapté en outre pour recevoir un deuxième signal de fonctionnement provenant d'un deuxième point de contrôle interne d'ordinateur qui suit séquentiellement ledit premier point de contrôle interne d'ordinateur, et envoie ledit deuxième signal de fonctionne ment audit journal d'événements (14); et un postprocesseur (18) adapté pour recevoir lesdits premier et deuxième signaux de fonctionnement provenant dudit journal d'événe ments (14), ledit postprocesseur (18) étant en outre adapté pour déter miner une indication de fiabilité du fonctionnement de l'ordinateur en fonction desdits premier et deuxième signaux de fonctionnement dudit journal d'événements (14). 9. Systéme selon la revendication 8, dans lequel ledit premier point de contrôle interne d'ordinateur comprend en outre un point de contrôle de mise sous tension. 1O. Procédé d'analyse interne d'un événement de blocage dans un logiciel, caractérisé en ce qu'il comprend les étapes consistant à: envoyer un premier signal de fonctionnement depuis un point de contrôle de mise sous tension à un journal d'événements (14); 2 5 envoy er un deuxième sign al de fon ctionnement depui s un point de contrôle de mise sous tension accomplie, qui suit séquentiel lement ledit point de contrôle de mise sous tension, audit journal d'événements (14); envoyer un troisième signal de fonctionnement depuis un point de contrôle d'arrêt audit journal d'événements (14); envoyer un quatrième signal de fonctionnement depuis un point de contrôle d'arrêt accompli, qui suit séquentiellement ladit point de contrôle d'arrêt, audit journal d'événements (14); et calculer la fiabilité du logiciel à partir des donnces contenues