FR 2858436 A1 20050204 FR 0408467 A 20040730 L'invention concerne de façon générale des systèmes d'automatismes industriels, et elle concerne en particulier des procédures pour modifier un programme orienté objet en cours d'exécution, en particulier un programme pour commander une installation automatisée, ainsi que des systèmes d'exécution pour exécuter des programmes de commande dans une unité de commande d'une installation automatisée. Des systèmes de commande sont utilisés de plus en plus souvent, en particulier pour commander ou réguler des séquences de fonctionnement ou des processus industriels à grande échelle, par exemple en fabrication industrielle ou en assemblage final. De façon similaire, ils sont utilisés pour surveiller de tels processus qui sont accomplis automatiquement dans la plus grande mesure possible, ainsi que pour illustrer l'état de processus présent. De telles installations automatisées ou usines automatisées ont atteint une importance primordiale dans la fabrication industrielle, à cause du haut niveau de productivité qu'elles facilitent. Pour éviter des arrêts de production, il doit être possible de modifier le programme de commande d'une installation automatisée sans la nécessité d'arrêter l'installation automatisée ou de la placer dans un certain état. Sinon, par exemple dans le cas d'une machine d'emballage, il serait nécessaire de retirer à la fois le matériau d'emballage complet, ainsi que les marchandises qui doivent être emballées, si la relation entre le programme de commande et le contenu présent des variables intervenant dans ce programme est perdue à cause d'une modification de programme, ce qui fait que l'information relative à l'état de processus présent n'est plus disponible. Pour permettre d'adopter un programme modifié indépendamment de l'état présent respectif de l'installation automatisée, il est nécessaire de respecter certaines exigences. D'une part, le changement de programme doit avoir lieu en temps réel. Ceci signifie que les temps de réponse ou les intervalles d'exécution fixés du programme de commande ne doivent pas être dépassés. De plus, il est vital que l'état de programme présent, en particulier les données qui, par exemple, contiennent de l'information concernant l'état de processus présent de l'installation automatisée, soit maintenu et continue à être utilisé par le programme modifié. Dans le cas de systèmes de commande SPS, du fait qu'ils sont utilisés dans des automatismes industriels, une variété de différents systèmes de programmation sont déjà capables à l'heure actuelle d'accomplir des modifications de programme sans avoir à interrompre l'exécution du programme. Cette caractéristique est fréquemment appelée "programmation en ligne". Cependant, ces systèmes utilisent des processus qui exigent une coordination étroite entre le système de programmation et le système d'exécution du système de commande. En procédant ainsi, le système de programmation gère l'information concernant l'état du programme avant la modification, en obtenant ainsi à partir d'elle les mesures nécessaires pour réaliser les modifications de programme. Des systèmes de programmation actuels sont cependant fréquemment caractérisés par des contraintes en termes de fonctionnalité. Ainsi, par exemple, l'aspect de temps réel n'est généralement pris en considération que rarement. A la place, on suppose que la durée de l'interruption de l'exécution de programme n'est pas critique. Ceci est réellement le cas avec des systèmes de programmation qui permettent seulement des modifications d'ordres de programme, mais qui ne supportent cependant pas de changements d'objets variables ou de la structure d'objets (instanciation). D'autres systèmes emploient des objets de données globaux, pour lesquels l'utilisateur adresse manuellement les variables de programme. Ici, l'utilisateur a la responsabilité de garantir que les variables conservent leur ancien contenu après que les modifications de programme ont été accomplies. Le principal inconvénient de tels modèles de programmation simples est qu'ils ne sont pas orientés objet et ne permettent pas l'encapsulation de données. Les exigences imposées au système de programmation utilisé font qu'il est seulement possible d'utiliser des outils de programmation qui ont été spécialement développés pour la mise en oeuvre dans le domaine de l'ingénierie de commande industrielle. L'objectif de l'invention est donc d'identifier des moyens constructifs pour résoudre le problème consistant dans la manière d'accomplir des modifications dans un programme de commande d'une installation automatisée, pendant qu'elle fonctionne, avec une réduction importante ou même pratiquement complète des limitations imposées jusqu'à présent à la fonctionnalité d'un système de programmation déployé. En particulier, l'objectif est de modifier le programme en utilisant un outil de programmation qui n'a pas été adapté spécifiquement dans ce but. Une autre tâche de l'invention est l'indication d'une manière de respecter les exigences de temps réel d'une installation automatisée, pendant la modification d'un programme de commande en cours d'exécution. Le problème peut être résolu avec une facilité stupéfiante en utilisant un objet basé sur l'une des revendications indépendantes annexées. Des modes de réalisation utiles et des développements supplémentaires sont présentés dans les revendications dépendantes. Cependant, pour commencer, on définira ou on clarifiera certains termes qui sont applicables à la description et aux revendications, de manière globale. En programmation orientée objet, une classe décrit une entité abstraite qui reproduit un objet. Un objet constitue une instance d'une classe, c'est-à-dire une image dans la mémoire d'un système informatique qui est générée sur la base du modèle de classe. Une classe peut avoir différents membres, comme on les appelle. Ceux-ci incluent, entre autres, des méthodes et des champs de la classe. Une sous-classe peut également être un membre d'une classe. Une pile fait référence à une zone de stockage dédiée dans laquelle un programme enregistre en tampon des données d'état. Un tas est une partie de la mémoire dans laquelle des structures de données sont stockées temporairement, l'existence et la taille de ces structures ne pouvant pas être déterminées avant l'exécution du programme. Le procédé conforme à la présente invention pour modifier un programme orienté objet en cours d'exécution, et en particulier un programme pour commander une installation automatisée, qui est stocké dans une mémoire sous la forme d'un code intermédiaire et qui peut être converti en code machine exécutable au moment de l'exécution, comprend l'établissement d'un programme modifié, ou d'un module de programme modifié, également sous la forme de code intermédiaire, la comparaison du code intermédiaire du programme modifié avec le code intermédiaire du programme en cours d'exécution, pour déterminer la modification, ainsi que l'incorporation des modifications dans le programme en cours d'exécution. Le grand avantage de cette procédure réside dans le fait qu'un outil de programmation qui génère un code intermédiaire à partir d'un code source n'a pas besoin de générer une information supplémentaire quelconque concernant les modifications de programme incorporées. L'outil de programmation n'exige donc aucune fonction supplémentaire pour incorporer des modifications de programme dans un processus en cours d'exécution. Cette tâche est accomplie par le système d'exécution, et en particulier un système d'exécution eCLR ("Embedded Common Language Runtime"). Ceci permet de supporter des modifications de programme pendant que le processus est en cours d'exécution, en utilisant des outils de programmation qui n'ont pas été développés de façon spécifique pour l'utilisation dans le domaine de l'ingénierie de commande industrielle. Il est préférable ici d'utiliser un code intermédiaire CIL (Common Intermediate Language) ou MSIL (Microsoft Intermediate Language) pour le code intermédiaire. CIL et MSIL sont différents termes pour le même code intermédiaire. Le code intermédiaire CIL est un élément constitutif de la plate-forme .NET de Microsoft'-'. L'avantage d'utiliser le code intermédiaire CIL réside dans le fait qu'il contient une description complète pour la structuration de classes. Il est préférable de convertir le code intermédiaire en code machine exécutable en utilisant un compilateur JIT (Just-In-Time), qui fait également partie de la plate-forme .NET. Il est préférable que l'incorporation de modifications dans le programme en cours d'exécution comprenne la génération d'un ou plusieurs premier(s) objet(s) de programme ; copie de données contenues dans un ou plusieurs second(s) objet(s) de programme vers le ou les premier(s) objet(s) de programme précités - le ou les second(s) objet(s) de programme faisant partie du programme en cours d'exécution - ; le passage du ou des second(s) objet(s) de programme au(x) premier(s) objet(s) de programme, le(s) second(s) objet(s) de programme faisant partie du programme en cours d'exécution. Ceci a l'avantage consistant en ce que, par l'exécution de certaines étapes en arrière-plan, il est possible de préparer la modification de programme. De plus, il est généré une modification de programme qui est très utile pour incorporer les modifications. En règle générale, ceci est effectué par le système d'exécution et a pour fonction de procurer une séquence automatique organisée des étapes exigées pour incorporer la modification de programme. Dans ce but, par exemple, le système d'exécution génère un code intermédiaire, qui est converti en code machine exécutable par le compilateur JIT, et est exécuté automatiquement. De préférence, après que les modifications ont été incorporées, la mémoire allouée aux objets de programme qui ne sont plus utilisés est désallouée. On peut utiliser dans ce but la fonction dite de "collecte de déchets" d'un système d'exécution CLR. Des processus qui s'exécutent dans des installations automatisées sont généralement sujets à certaines exigences de temps réel. Sur la base des critères de temps réel, qui doivent être respectés, il est possible, sous la dépendance d'au moins un temps de réponse d'un système automatisé commandé par le programme, et/ou sous la dépendance d'au moins un intervalle d'exécution du programme, de fixer un temps maximal qui ne doit pas être dépassé au moment de l'incorporation des modifications. Dans ce but, la procédure comprend une fonction utile qui peut déterminer le temps exigé pour incorporer les modifications, au moyen d'une simulation. Un avantage particulier réside également dans le fait que les modifications sont incorporées en au moins deux sous-étages. Ici, des mesures préparatoires sont accomplies pendant le premier sous-étage, comme par exemple la génération d'objets de programme et la copie de données, et dans le second sous-étage le système est par exemple commuté vers les objets de programme nouvellement générés. Si pendant le premier sous-étage, il se produit dans la séquence de fonctionnement du programme en cours d'exécution un événement qui, par exemple, pourrait entraîner une modification de données qui ont déjà été copiées, il est possible de répéter le premier sous-étage à un instant ultérieur. Si le programme en cours d'exécution commute de façon cyclique entre un état actif et un état inactif, comme il est habituel dans le cas de programmes de commande, la procédure peut, entre autres choses, calculer commodément un ou plusieurs instants auxquels le programme commute vers son état actif. Si le temps exigé pour les modifications à incorporer est également connu, il est possible de déterminer pour un instant spécifique si les modifications peuvent être incorporées, tout en respectant simultanément les conditions de temps réel d'une installation automatisée. De plus, l'invention comprend également un système d'exécution pour exécuter des programmes de commande dans une unité de commande d'une installation automatisée, en particulier pour mettre en oeuvre la procédure décrite cidessus, incluant un moyen pour lire et écrire un contenu de mémoire, dans lequel : l'unité de commande a une mémoire adressable et un programme de commande est enregistré de manière récupérable sous la forme d'un premier code intermédiaire dans une première zone de mémoire ; moins des parties du premier code intermédiaire peuvent être converties en ordres de commande exécutables qui sont enregistrés dans une seconde zone de mémoire, pendant que le processus s'exécute dans l'installation automatisée ; système d'exécution réagit à l'existence d'un second code intermédiaire alloué dans une troisième zone de mémoire, en modifiant ainsi la séquence de processus dans l'installation automatisée. La séquence de fonctionnement dans l'installation automatisée peut être modifiée commodément en sélectionnant au moins une partition de la troisième zone de mémoire et au moins une unité de stockage de la seconde zone de mémoire, dans laquelle l'adresse de départ d'une partition de la seconde zone de mémoire est stockée ; comparant le premier code intermédiaire stocké dans la première zone de mémoire et le second code intermédiaire stocké dans la troisième zone de mémoire ; convertissant le code intermédiaire stocké dans la partition de la troisième zone de mémoire en ordres de commande exécutables, qui sont stockés à leur tour dans une quatrième zone de mémoire ; copiant des données à partir de la partition de la seconde zone de mémoire vers la partition de la troisième zone de mémoire ; et en stockant l'adresse de départ de la quatrième zone de mémoire dans l'unité de stockage de la seconde zone de mémoire. Le système d'exécution est de préférence un système d'exécution CLR, en particulier un système d'exécution eCLR, du fait que ce type de système d'exécution comporte des fonctions qui conviennent particulièrement pour produire l'effet décrit ci-dessus. Comme déjà mentionné dans la description de la procédure conforme à la présente invention, il est préférable d'utiliser un code intermédiaire CIL pour le code intermédiaire. En outre, le système d'exécution pour convertir un code intermédiaire en ordres de commande exécutables doit également inclure de préférence un compilateur JIT. Pour exécuter les modifications de programme d'une manière organisée, le système d'exécution comporte des moyens utiles pour générer, stocker et exécuter des ordres de commande. Lorsqu'on utilise le système d'exécution dans des environnements de temps réel, il est possible d'effectuer une modification dans la séquence de processus dans les limites d'une durée donnée. Dans ce but, le système d'exécution comprend des moyens utiles pour calculer la durée exigée pour effectuer une modification dans la séquence de processus d'une installation automatisée. Pour respecter les conditions de temps réel, les routines, qui sont exécutées dans le but d'effectuer une modification dans la séquence de processus d'une installation automatisée, peuvent être répétées soit intégralement, soit partiellement. Le cadre de l'invention englobe également l'identification d'un système automatisé dans lequel le système d'exécution décrit ci-dessus est intégré, et qui convient pour accomplir la procédure décrite ci-dessus. Dans ce qui suit, l'invention sera exposée de façon plus détaillée, en étant exemplifiée sur la base de modes de réalisation préférés, et en référence aux dessins annexés. Dans cet exposé, des symboles de référence identiques dans les dessins désignent des composants identiques ou similaires. La figure 1 montre une représentation schématique des méta-données et de la représentation de code d'un assemblage, la figure 2 montre la modification de champs d'une classe, et la figure 3 montre un diagramme de priorité/ temps détaillant plusieurs tâches d'un programme en cours d'exécution, ainsi qu'une tâche pour mettre en oeuvre des modifications dans ce programme. Dans le mode de réalisation suivant de la procédure conforme à la présente invention, on utilise un système d'exécution eCLR, qui a pour fonction d'exécuter des programmes sur la base du code intermédiaire CIL spécifié dans le standard ECMA (European Computer Manufacturers' Association). Un système d'exécution eCLR utilise les spécifications de l'infrastructure Common Language Infrastructure (CLI) de la plate-forme .NET de Microsoft. Le système d'exécution eCLR qu'on envisage permet d'apporter des modifications à un programme de commande d'une installation automatisée, pendant qu'elle fonctionne. Un programme de commande, ici sous la forme d'un code intermédiaire CIL, est en règle générale constitué de modules individuels (assemblages), chacun d'eux incluant à son tour un code intermédiaire CIL. Le programme de commande est donc fondamentalement modifié en adoptant et en activant un ou plusieurs assemblages modifiés. En premier lieu, les modifications sont apportées au code source du programme ou des assemblages qui doivent être modifiés. Le code source peut être programmé en une variété de langages de programmation différents, par exemple C#, ou dans un langage de programmation qui correspond à la spécification IEC61131. Un code intermédiaire CIL est généré conformément au code source modifié, en utilisant un outil de programmation. N'importe quel outil de programmation qui peut générer un code intermédiaire CIL convient dans ce but. Le code intermédiaire CIL de tous les assemblages modifiés est maintenant chargé dans le système d'exécution eCLR. A l'étape suivante, le système d'exécution eCLR analyse les modules de code intermédiaire CIL nouvellement chargés, et compare ceux-ci avec le programme qui est en cours d'exécution. En procédant ainsi, toutes les différences existantes sont détectées. Ceci est rendu possible par le fait que le code intermédiaire CIL contient une description complète pour la structure de classes, incluant non seulement les méthodes, mais également les champs d'une classe. Ensuite, l'actualisation du programme est préparée. Ici, le système d'exécution eCLR génère un code de programme qui organise les mesures individuelles à adopter. Ceci inclut en particulier, également, l'adoption de toutes les données existantes qui doivent être exécutées dans le programme modifié. De plus, de nouvelles données sont initialisées. Une partie du code de programme généré comprend ce qu'on appelle des constructeurs de copie et des constructeurs de delta. Un constructeur de copie et un constructeur de delta sont générés pour chaque classe modifiée. Pendant une étape suivante, les objets de la classe modifiée sont générés au moyen du nouvel opérateur, après quoi le constructeur de delta est exécuté. Dans cette étape, tous les nouveaux membres supplémentaires de la classe sont générés et/ou initialisés. A l'étape suivante, le constructeur de copie copie vers l'ancienne classe les valeurs présentes pour les objets. Enfin, toutes les références aux anciens objets sont transférées vers les nouveaux objets. Pour cette étape de l'exécution, le programme de commande est bloqué pendant un bref intervalle de temps. Le système d'exécution eCLR commande les références de tout programme donné, qui sont également appelées des données gérées. Une référence est stockée dans le tas. La pile contient une référence à l'adresse de mémoire dans le tas. La génération et la libération, l'allocation d'espace de mémoire et l'accès à des membres d'une classe sont organisés en utilisant des pointeurs. Chaque assemblage contient ce qu'on appelle des méta-données, auxquelles on peut accéder pendant l'exécution. La figure 1 montre l'interaction 41 entre des métadonnées (21 à 24,31 et 32) et la représentation de code, 11 à 14, d'un assemblage. Chaque assemblage contient de l'information concernant des classes, représentée par exemple sur la figure 1 par X et Y, ainsi que leurs champs 31,32 et méthodes 21 à 24. Cette information est incluse dans les méta-données d'un assemblage. Les méthodes et les champs d'une classe présentent également des dépendances 42. Chaque fois qu'un assemblage est chargé dans le système eCLR, le code intermédiaire correspondant est converti en code machine exécutable par le compilateur JIT. Chaque méthode d'une classe est représentée par un bloc de code continu 11 à 14 dans le tas de code géré de la mémoire. Toute l'information nécessaire concernant les classes et les méthodes, par exemple quelle méthode appartient à telle classe, ou les signatures des méthodes, est stockée dans une zone de données statique, l'espace de travail de métadonnées. Lorsque le bloc de code 12 représentant une méthode 22 de la classe X est exécuté, il est également possible, par exemple, d'avoir un accès 43 à une méthode 24 de la classe Y. Chaque assemblage comprend une ou plusieurs classes. S'il devient nécessaire de modifier ou d'échanger un assemblage, les différences entre les classes correspondantes de l'assemblage en cours d'exécution et de l'assemblage modifié sont évaluées en premier lieu. On prend ici en considération une variété de cas différents. Dans le premier cas, les deux classes contiennent des méthodes et des champs identiques. De façon similaire, le code intermédiaire est également identique. Ceci peut, par exemple, être vérifié à l'aide d'une vérification CRC du code. Du fait qu'il n'y a pas de discordance entre des codes intermédiaires, aucune étape supplémentaire n'est nécessaire dans ce cas. Dans le second cas, les deux classes contiennent des méthodes et des champs identiques. Cependant, en comparaison avec la classe correspondante de l'assemblage en cours d'exécution, une ou plusieurs méthodes de la classe de l'assemblage modifié révèlent un code intermédiaire modifié. Dans ce cas, une compilation pour la méthode modifiée est accomplie, et le pointeur dirigé vers le code qui est généré de cette manière est alloué au descripteur de la méthode originale. Dans ce cas, la commutation est très rapide du fait qu'un seul élément de pointeur est alloué. Dans le troisième cas, les deux classes ne contiennent plus les mêmes méthodes. Ceci peut être le cas si la classe modifiée révèle une méthode supplémentaire, si la classe originale ne contient plus une méthode qui existait précédemment, ou si les deux classes contiennent des méthodes avec des signatures différentes. Dans ce cas, il peut être nécessaire de supprimer l'une des méthodes. Si c'est le cas, une vérification est effectuée afin de déterminer si la méthode qui doit être supprimée contient une référence au code actif, une fois que toutes les modifications ont été effectuées. Ceci est illustré dans l'exemple suivant. Dans cet exemple, nous considérerons deux assemblages A et B, dans lesquels l'assemblage A contient la classe X et l'assemblage B contient la classe Y. La méthode X::process() appelle la méthode Y::process(). Si la méthode processO de la classe Y est maintenant supprimée, des modifications correspondantes supplémentaires sont accomplies dans la méthode X::process(). A cet égard, il peut également être nécessaire de modifier plus d'un assemblage en même temps. Dans le quatrième cas, au moins un champ des deux classes est différent. Dans ce cas, l'objet devra être modifié. Ici, une vérification en termes de champs supprimés est effectuée en premier, cette vérification se déroulant selon les mêmes principes que la vérification décrite dans le cas trois. Si toutes les modifications sont admissibles, un constructeur de copie est généré. On donne ci-dessous une explication de base concernant la manière selon laquelle une classe modifiée adopte les membres du type de classe d'origine. En règle générale, ceci est effectué avec l'aide de constructeurs de copie. Un constructeur de copie est une fonction spéciale qui copie tous les membres de classe contenus à la fois dans l'ancien type de classe et dans le nouveau. Pour déterminer si un membre de classe est contenu ou non dans les deux classes, il est nécessaire de distinguer entre trois cas. Si les noms et les types de données du membre de classe sont identiques, le membre de classe sera également identique. Ce premier cas décrit une relation forte entre les membres de classe. Tous les membres de classe auxquels ce cas s'applique sont copiés 1 à 1 par le constructeur de copie. Si seulement les noms des membres de classe sont identiques et le type de données est un type de données élémentaire, il y a une relation faible entre les membres de classe. Tous les membres de classe auxquels ce cas s'applique sont copiés et transférés, par exemple du type de données "byte" (octet) vers le type de données "int" (entier) . Si ni le premier cas, ni le second, ne s'applique, on juge que les membres de classe sont différents et donc sans relation. Ces membres de classe ne sont pas traités par le constructeur de copie. Ceci est décrit une fois de plus, à titre d'exemple, sur la figure 2. Des membres de classe a, b et d d'une classe initiale 51 sont identiques à des membres de classe a, b et d d'une classe modifiée 52 et sont copiés par le constructeur de copie, comme représenté sur la figure 2 par des flèches portant des symboles de référence 61 à 63. Le membre de classe c dans la classe 51 a le même nom que le membre de classe c dans la classe 52, mais est d'un type de données différent. Il y a une relation faible entre les deux membres de classe portant le nom c. Par conséquent, au moment de la copie du membre de classe c, une transformation 64 a également lieu. Les membres de classe e, f et g n'ont pas de relation et ne sont donc pas traités par le constructeur de copie. Le constructeur de copie prend en compte seulement des membres de classe non statiques, du fait que des membres de classe statiques sont représentés seulement par type de classe et non par instance. En accédant aux méta-données du type de classe original et d'un type de classe modifié, le système d'exécution eCLR est capable d'analyser des différences entre des types de classe et de générer un constructeur de copie qui correspond au type de classe respectif. Un exemple d'un constructeur de copie sous la forme de code intermédiaire est présenté ci-dessous. .method public hidebysig instance void copyctor(...) ldarg, 0 ldarg.1 ldfld int32 Application.Test2/* 02000005 */::xl/* 04000022 */ stfld int32 Application.Testl/* 02000006 */::xl/* 04000025 */ ldarg,0 ldarg.1 ldfld char Application.Test2/* 02000005*/::x2 /* 04000023 */ stfld int32 Application.Testl/* 02000006 */ ::x2/* */ ldarg.0 ldarg.1 ldfld int32 Application.Test2/* 02000005 */ ::x3/* */ stfld int32 Application.Testl/* 02000006 */::x3/* 04000027 */ ret Fondamentalement, un constructeur de copie comprend les deux ordres de code intermédiaire ldfld (load field ou "chargement de champ") et stfld (store field ou "stockage de champ"). Cette paire d'ordres est utilisée pour des champs qui ne diffèrent pas en termes de leurs types de données. On considère qu'il y a une relation faible entre les champs si les types de données diffèrent, mais appartiennent aux types de données élémentaires suivants : bool, int8, uint8, intl6, uintl6, int32, uint32, int64, uint64, real32, real64. Dans ces cas, il peut être nécessaire d'utiliser des opérateurs tels que conv.i4 (int32) ou conv.r4 (real32), afin de transformer de l'un à l'autre des membres de classe présentant une relation faible. L'exemple suivant, présenté sous la forme de code intermédiaire, convertit un champ X1 d'une classe de type de données "int" en type de données "real" : ldfld X : :X1 // int datatype conv.r4 stfld X*: :X1 // real datatype Le système d'exécution eCLR convertit le constructeur de copie en code machine exécutable au moyen du compilateur JIT. Le code assembleur basé sur Intel indiqué ci-dessous pourrait, par exemple, être le résultat de la conversion d'un constructeur de copie. mov esi dword ptr [ebp+8]; objet de source mov edi dword ptr [ebp+12]; objet de destination mov eax dword ptr [esi+4]; xl (ancienne classe) mov dword ptr [di+8], eax; xl (nouvelle classe) Dans le cas d'un champ présentant un type de données modifié qui ne peut pas être alloué à un type de données élémentaire, il est nécessaire de distinguer entre deux cas différents. Si le type de base est #system.object", l'objet est actualisé par le système d'exécution eCLR lui-même. Si le type de base est #system.valuetype", le constructeur de copie contient un code pour exécuter le constructeur de copie de cette classe modifiée. L'exemple suivant montre la structure hiérarchique d'un constructeur de copie dans le cas où des sous-classes d'une classe sont modifiées. C# structs S { int xl; int x2; } class X { int xl; S si;) } constructeur de copie en code de langage intermédiaire X::copyctor: ldfld X : :X1 // int datatype stfld X*::X1 ldflda X::sl ldflda X*::sl call S:copyctor Dans ce cas, l'ordre de code intermédiaire ldflda ("load address of field" ou "chargement d'adresse de champ") est utilisé pour charger les adresses des sousclasses afin d'appeler le constructeur de copie correspondant de ce type de classe. Après la conversion de tous les constructeurs de copie en code machine exécutable, le système d'exécution eCLR collecte toutes les références à des classes modifiées pour lesquelles les constructeurs de copie ont été générés. De telles référence peuvent par exemple être localisées pour des références statiques dans la zone de données globale, ou pour des sous-classes dans la pile d'appel locale ou dans d'autres objets. Si une liste de toutes les références d'objets a été générée, les objets modifiés sont régénérés par le système d'exécution eCLR en utilisant l'opérateur "New". Après avoir été générés et initialisés, les objets sont copiés. Le constructeur de copie alloue maintenant le contenu présent des anciens objets à tous les nouveaux objets. Jusqu'à ce moment, la collecte de références et la génération et la copie d'objets peuvent être répétées dans le cas où le système d'exécution eCLR détecte qu'un fil alloué au programme qui doit être modifié a été activé pendant le processus. Vient ensuite la phase critique, qui ne peut pas être interrompue, dans laquelle toutes les références sont modifiées. Dans cette phase, le programme qui doit être modifié est bloqué. Les allocations de pointeurs et donc le temps exigé dans ce but dépendent du nombre d'instances d'objets et de leurs références, ainsi que de l'étendue des modifications. Après que le changement a eu lieu en modifiant les références d'objets, l'exécution du programme, qui a été modifié entre temps, peut être reprise. Le blocage du fil est levé. Une autre des fonctions du système d'exécution eCLR est de désallouer des réserves de mémoire qui ne sont plus exigées. Un aspect supplémentaire de l'invention consiste en un processus qui garantit que les critères de temps réel stipulés pour le processus de commande sont respectés chaque fois que des modifications de programme sont accomplies. En règle générale, des programmes de commande sont exécutés de manière cyclique. Les critères de temps réel sont définis par les intervalles d'exécution des programmes dans lesquels les informations d'entrée sont lues, les programmes de commande sont exécutés et les informations de sortie sont écrites. Le respect des critères de temps réel est obtenu en subdivisant l'accomplissement de modifications de programme en une phase préparatoire et une phase critique, comme on l'a déjà mentionné ci-dessus. Pour accomplir la modification de programme avec succès, aucun ordre de programme du programme de commande ne peut être exécuté dans une phase ou l'autre. La phase préparatoire, qui englobe pratiquement toutes les mesures nécessaires pour accomplir une modification de programme (approximativement 99%) peut être interrompue et répétée un nombre de fois quelconque. Dans le cas où la phase préparatoire est interrompue par l'exécution d'un ordre de programme, cette phase peut être recommencée à n'importe quel moment. La phase critique comprend l'activation du nouveau programme. Pour des raisons de cohérence, l'activation doit avoir lieu simultanément pour tous les objets de programme. Ceci explique pourquoi ce processus ne peut pas être interrompu. En utilisant la présente invention, le temps exigé pour les deux phases peut être déterminé de façon précise. Le temps d'exécution pour accomplir une modification de programme doit dans tous les cas être plus court que le plus court intervalle d'exécution d'un programme d'application. Des exigences de temps réel caractéristiques demandent des temps de cycle de l'ordre d'environ 10 ms. Les temps jusqu'à l'activation suivante d'un cycle de programme peuvent être calculés à l'avance. Dans le cas de programmes qui sont exécutés de manière cyclique, il est donc possible de prédire le moment auquel l'exécution suivante aura lieu. Aucune prédiction ne peut être faite pour des programmes commandés par des événements. Ici, la durée de la phase critique affecte ce qu'on appelle la gigue. Par conséquent, si un événement se produit pendant la phase critique, il ne peut être traité, au plus tôt, par le programme correspondant qu'après l'achèvement de la phase critique. Si la tolérance de gigue maximale est inférieure au temps exigé pour exécuter la phase critique d'un programme, il n'est pas possible d'effectuer une modification de programme à un instant quelconque en respectant les critères de temps réel ainsi définis. La séquence de fonctionnement est représentée sur la figure 3 sous la forme d'un exemple de diagramme de priorité / temps, représentant l'activité de différentes tâches avec différentes priorités, en relation avec le temps. Si une tâche passe dans un état actif, toutes les autres tâches avec une priorité inférieure seront interrompues. La tâche 73 est la principale tâche du programme en cours d'exécution avec le module de programme alloué P3. Cette tâche est exécutée périodiquement avec un intervalle de temps de 15 ms. Des tâches supplémentaires du programme en cours d'exécution représenté dans cet exemple comprennent des tâches périodiques 71 avec un intervalle de temps 10 ms et un module de programme alloué P1, ainsi qu'une tâche orientée événement, 72, avec un module de programme alloué P2. Du fait d'exigences de temps réel, les tâches allouées au programme en cours d'exécution ont la priorité la plus élevée. Le système d'exécution eCLR qui est appelé le gestionnaire de modification sur la figure 3, organise les modifications de programme. Des tâches 81 et 82, qui sont allouées au gestionnaire de modification, réalisent les modifications. Dans cet exemple, la tâche 81 est commencée après que la tâche principale 73 est passée dans un état inactif. Cependant, pendant qu'elle est exécutée, la tâche 81 est interrompue par la tâche 71 au moment où elle passe dans son état actif. Après ceci, la tâche 82 pour réaliser les modifications est redémarrée, dans cet exemple, au prochain instant possible auquel la tâche principale 73 retourne à un état inactif. La tâche 82 n'est interrompue par aucune autre tâche, ce qui signifie que les modifications ont été réalisées avec succès. Dans cet exemple, le module de programme P3 a été changé. Ayant été modifié avec succès, le module de programme modifié P3* est exécuté. La tâche 74 est une autre tâche du système eCLR, utilisée par exemple pour la communication ou le débogage. Il va de soi que de nombreuses modifications peuvent être apportées au dispositif et au procédé décrits et représentés, sans sortir du cadre de l'invention. REVENDICATIONS 1. Procédé pour modifier un programme orienté objet qui est en cours d'exécution, en particulier un programme pour commander une installation automatisée, dans lequel le programme sous la forme d'un code intermédiaire, qui peut être converti en code machine exécutable au moment de l'exécution, est stocké temporairement dans une mémoire, caractérisé en ce qu'il comprend les étapes suivantes : on fournit un programme modifié ou un module de programme modifié, également sous la forme d'un code intermédiaire; on compare le code intermédiaire du programme modifié, respectivement, du module de programme modifié, et le code intermédiaire du programme en cours d'exécution, pour déterminer la modification ; on incorpore les modifications dans le programme en cours d'exécution. 2. Procédé selon la revendication 1, caractérisé en ce qu'on utilise pour le code intermédiaire un code intermédiaire CIL ou MSIL incluant ce qui est fondamentalement une description complète pour la structure de classes. 3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la conversion du code intermédiaire en code machine exécutable est effectuée au moyen d'un compilateur JIT. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la mise en oeuvre des modifications comprend les étapes suivantes : on génère un ou plusieurs premier(s) objet(s) de programme ; copie des données contenues dans le ou les second(s) objet(s) de programme vers le ou les premier (s) objet (s) de programme, le ou les second(s) objet(s) de programme faisant partie du programme en cours d'exécution ; on passe du ou des second(s) objet(s) de programme au(x) premier(s) objet(s) de programme, ce qui a pour effet de l'incorporer ou de les incorporer dans le programme en cours d'exécution. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'un programme de modification est automatiquement généré pour incorporer les modifications. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'après l'incorporation des modifications, la mémoire allouée aux objets de programme qui ne sont plus utilisés est désallouée à nouveau. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les modifications sont incorporées en une durée donnée, la durée étant fixée sous la dépendance en particulier d'au moins un temps de réaction d'un système automatisé commandé par le programme, et/ou sous la dépendance d'au moins un intervalle d'exécution. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le temps exigé pour incorporer les modifications est déterminé par simulation. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les modifications sont incorporées en au moins deux sous- étages, parmi lesquels un ou plusieurs sous-étage(s) peut / peuvent être répété(s) au moins une fois. 10. Procédé selon la revendication 9, caractérisé en ce que la répétition du ou des sous-étage(s) dépend de la survenance d'un événement prédéfini dans la séquence de programme. 11. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le programme en cours d'exécution alterne de façon cyclique entre un état actif et un état inactif et la procédure peut, entre autres, commodément calculer un ou plusieurs instants auxquels le programme passe à son état actif. 12. Système d'exécution pour exécuter des programmes de commande dans une unité de commande d'une installation automatisée, en particulier pour mettre en oeuvre le procédé selon l'une quelconque des revendications précédentes, incluant un moyen pour lire et écrire des contenus de mémoire, caractérisé en ce que : l'unité de commande a une mémoire adressable et un programme de commande est enregistré, avec possibilité de lecture, sous la forme d'un premier code intermédiaire dans une première zone de mémoire ; moins des parties du premier code intermédiaire peuvent être converties en ordres de commande exécutables qui sont enregistrés dans une seconde zone de mémoire, pendant que le processus s'exécute dans l'installation automatisée ; système d'exécution réagit à la fourniture d'un second code intermédiaire alloué dans une troisième zone de mémoire, pour modifier ainsi la séquence de processus dans l'installation automatisée. 13. Système d'exécution selon la revendication 12, caractérisé en outre par le fait que la séquence de fonctionnement dans l'installation automatisée est modifiée par les étapes suivantes : on sélectionne au moins une partition de la troisième zone de mémoire et au moins une unité de stockage de la seconde zone de mémoire, dans laquelle l'adresse de départ d'une partition de la seconde zone de mémoire est stockée, en comparant le premier code intermédiaire stocké dans la première zone de mémoire et le second code intermédiaire stocké dans la troisième zone de mémoire ; on convertit le code intermédiaire stocké dans la partition de la troisième zone de mémoire en ordres de commande exécutables, qui sont stockés à leur tour dans une quatrième zone de mémoire ; copie des données à partir de la partition de la seconde zone de mémoire vers la partition de la troisième zone de mémoire ; on stocke l'adresse de départ de la quatrième zone de mémoire dans l'unité de stockage de la seconde zone de mémoire. 14. Système d'exécution selon la revendication 12, caractérisé en ce que le système d'exécution est un système CLR et, plus précisément, un système eCLR. 15. Système d'exécution selon l'une quelconque des revendications 12 à 14, caractérisé en ce que le code intermédiaire est un code intermédiaire CIL ou MSIL qui contient une description complète pour la structure de classes. 16. Système d'exécution selon l'une quelconque des revendications 12 à 15, caractérisé en ce que le système d'exécution convertit un code intermédiaire en ordres de commande exécutables au moyen d'un compilateur JIT. 17. Système d'exécution selon l'une quelconque des revendications 12 à 16, caractérisé en ce qu'il comprend un moyen pour générer, stocker et exécuter des ordres de commande. 18. Système d'exécution selon l'une quelconque des revendications 12 à 17, caractérisé en ce qu'il effectue une modification dans la séquence de processus d'une installation automatisée en une durée donnée. 19. Système d'exécution selon l'une quelconque des revendications 12 à 18, caractérisé en ce qu'il comprend un moyen pour calculer la durée exigée pour effectuer une modification dans la séquence de processus d'une installation automatisée. 20. Système d'exécution selon l'une quelconque des revendications 12 à 19, caractérisé en ce que les routines qui sont exécutées afin d'effectuer une modification dans la séquence de processus d'une installation automatisée, peuvent être répétées entièrement ou partiellement. 21. Système automatisé caractérisé en ce qu'il comprend un système d'exécution selon l'une quelconque des revendications 12 à 20, qui convient pour exécuter l'une des procédures précédentes.