FR2858436A1 - Procede et systeme pour modifier un programme oriente objet en cours d'execution - Google Patents
Procede et systeme pour modifier un programme oriente objet en cours d'execution Download PDFInfo
- Publication number
- FR2858436A1 FR2858436A1 FR0408467A FR0408467A FR2858436A1 FR 2858436 A1 FR2858436 A1 FR 2858436A1 FR 0408467 A FR0408467 A FR 0408467A FR 0408467 A FR0408467 A FR 0408467A FR 2858436 A1 FR2858436 A1 FR 2858436A1
- Authority
- FR
- France
- Prior art keywords
- program
- intermediate code
- code
- memory area
- execution system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
- G05B19/0426—Programming the control sequence
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/656—Updates while running
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/658—Incremental updates; Differential updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
- G06F9/45516—Runtime code conversion or optimisation
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/23—Pc programming
- G05B2219/23255—Object oriented programming, OOP
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/23—Pc programming
- G05B2219/23327—Modification of program in real time
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Automation & Control Theory (AREA)
- Stored Programmes (AREA)
- Programmable Controllers (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
Pour incorporer des modifications dans un programme orienté objet en cours d'exécution, en particulier un programme pour commander une installation automatisée, l'invention procure une procédure dans laquelle le programme est stocké temporairement dans une mémoire sous la forme d'un code intermédiaire qui peut être converti en code machine au moment de l'exécution, comprenant : la fourniture d'un programme modifié, également sous la forme d'un code intermédiaire; la comparaison du code intermédiaire du programme modifié et du code intermédiaire du programme en cours d'exécution, pour déterminer les modifications; et l'incorporation de modifications dans le programme en cours d'exécution.
Description
<Desc/Clms Page number 1>
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
<Desc/Clms Page number 2>
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
<Desc/Clms Page number 3>
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.
<Desc/Clms Page number 4>
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
<Desc/Clms Page number 5>
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.
<Desc/Clms Page number 6>
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
<Desc/Clms Page number 7>
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
<Desc/Clms Page number 8>
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.
<Desc/Clms Page number 9>
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
<Desc/Clms Page number 10>
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.
<Desc/Clms Page number 11>
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.
<Desc/Clms Page number 12>
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
<Desc/Clms Page number 13>
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
<Desc/Clms Page number 14>
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.
<Desc/Clms Page number 15>
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.
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
<Desc/Clms Page number 16>
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.
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
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
<Desc/Clms Page number 17>
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.
<Desc/Clms Page number 18>
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.
<Desc/Clms Page number 19>
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
<Desc/Clms Page number 20>
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.
Claims (21)
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
<Desc/Clms Page number 22>
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
<Desc/Clms Page number 23>
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.
<Desc/Clms Page number 24>
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.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10335989.3A DE10335989B4 (de) | 2003-08-01 | 2003-08-01 | Online-Änderungen von CIL-Code-Programmen für die Industrieautomatisierung |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2858436A1 true FR2858436A1 (fr) | 2005-02-04 |
| FR2858436B1 FR2858436B1 (fr) | 2007-09-28 |
Family
ID=34042155
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0408467A Active FR2858436B1 (fr) | 2003-08-01 | 2004-07-30 | Procede et systeme pour modifier un programme oriente objet en cours d'execution |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US8108852B2 (fr) |
| JP (2) | JP4836419B2 (fr) |
| CN (1) | CN100388193C (fr) |
| DE (1) | DE10335989B4 (fr) |
| FR (1) | FR2858436B1 (fr) |
| IT (1) | ITMI20041557A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100146481A1 (en) * | 2008-12-09 | 2010-06-10 | Microsoft Corporation | Developing applications at runtime |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7027880B2 (en) * | 2003-09-30 | 2006-04-11 | Rockwell Automation Technologies, Inc. | Safety controller providing rapid recovery of safety program data |
| US8942834B2 (en) | 2005-06-27 | 2015-01-27 | Rockwell Automation Technologies, Inc. | Method and apparatus for communicating transactions between an industrial controller and a programming interface |
| TWI263908B (en) * | 2005-07-12 | 2006-10-11 | Inventec Corp | Update system and method |
| US7743363B2 (en) * | 2005-10-13 | 2010-06-22 | Microsoft Corporation | Extensible meta-data |
| EP1916583A1 (fr) * | 2006-10-26 | 2008-04-30 | Siemens Aktiengesellschaft | Procédé destiné à l'exécution de modifications de programmes en ligne dans un système d'automatisation |
| US20080127142A1 (en) * | 2006-11-28 | 2008-05-29 | Microsoft Corporation | Compiling executable code into a less-trusted address space |
| US20090193392A1 (en) * | 2008-01-29 | 2009-07-30 | Michael David Downen | Dynamic intermediate language modification and replacement |
| EP2214101A1 (fr) | 2009-01-29 | 2010-08-04 | Siemens Aktiengesellschaft | Modification d'objets sur une application |
| EP2249217B1 (fr) * | 2009-05-08 | 2013-04-24 | Siemens Aktiengesellschaft | Appareil d'automatisation et système d'automatisation |
| US20110047687A1 (en) * | 2009-09-02 | 2011-03-03 | Lee Jeong-Hee | Apparatus and Method for Providing a Hygienic Toilet Seat |
| DE102010027906A1 (de) * | 2010-04-19 | 2011-10-20 | Beckhoff Automation Gmbh | Datenverwaltungsverfahren und speicherprogrammierbare Steuerung |
| CN103198240B (zh) * | 2012-09-29 | 2016-03-16 | 网易（杭州）网络有限公司 | 一种用于保护代码安全的方法和装置 |
| US9523969B2 (en) | 2013-02-20 | 2016-12-20 | General Electric Company | Systems and methods for tracking the quality and efficiency of machine instructions for operating an associated controller |
| DE102013005542A1 (de) * | 2013-04-03 | 2014-10-09 | Phoenix Contact Gmbh & Co. Kg | Verfahren und Steuerungsvorrichtung zur Ausgabe von Daten auf einen Lokalbus |
| EP2869145B1 (fr) * | 2013-10-29 | 2016-04-27 | dSPACE digital signal processing and control engineering GmbH | Procédé destiné à influencer un programme de commande d'un appareil de commande |
| US9958848B2 (en) | 2015-02-19 | 2018-05-01 | Rockwell Automation Technologies, Inc. | Techniques for improving industrial control systems |
| CN105005486B (zh) * | 2015-06-25 | 2018-11-09 | 许继集团有限公司 | 一种智能变电站设备程序在线升级方法 |
| JP6927089B2 (ja) * | 2018-03-05 | 2021-08-25 | オムロン株式会社 | 制御装置、システムプログラム、制御方法 |
| IT201800005542A1 (it) * | 2018-05-21 | 2019-11-21 | Sistema per la progettazione e/o l’aggiornamento di programmi per l’interfaccia operatore e la gestione di macchinari e/o impianti di automazione | |
| JP6954256B2 (ja) * | 2018-11-02 | 2021-10-27 | 横河電機株式会社 | エンジニアリング装置、エンジニアリング装置の制御方法及びプログラム |
| JP6950665B2 (ja) | 2018-11-02 | 2021-10-13 | 横河電機株式会社 | エンジニアリング装置、エンジニアリング装置の制御方法及びプログラム |
| CN113009873A (zh) * | 2021-02-03 | 2021-06-22 | 深圳市显控科技股份有限公司 | Plc梯形图在线编译和下载的方法、plc及存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6092079A (en) * | 1998-01-29 | 2000-07-18 | International Business Machines Corporation | Apparatus and method for updating an object without affecting the unique identity of the object |
| US6260187B1 (en) * | 1998-08-20 | 2001-07-10 | Wily Technology, Inc. | System for modifying object oriented code |
| US6298353B1 (en) * | 1998-11-19 | 2001-10-02 | International Business Machines Corporation | Checking serialization compatibility between versions of java classes |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07200279A (ja) | 1993-12-28 | 1995-08-04 | Toshiba Corp | オブジェクト管理システム及びネットワーク管理システム |
| JPH0895807A (ja) | 1994-09-21 | 1996-04-12 | Toyota Motor Corp | タスク実行制御方法 |
| US5970243A (en) * | 1996-08-27 | 1999-10-19 | Steeplechase Software, Inc. | Online programming changes for industrial logic controllers |
| US6282698B1 (en) * | 1998-02-09 | 2001-08-28 | Lucent Technologies Inc. | Detecting similarities in Java sources from bytecodes |
| US6092076A (en) * | 1998-03-24 | 2000-07-18 | Navigation Technologies Corporation | Method and system for map display in a navigation application |
| JPH11306008A (ja) | 1998-04-20 | 1999-11-05 | Mitsubishi Electric Corp | プログラム制御装置及びプログラム制御方法 |
| US6272677B1 (en) | 1998-08-28 | 2001-08-07 | International Business Machines Corporation | Method and system for automatic detection and distribution of code version updates |
| GB2341462B (en) | 1998-09-12 | 2003-06-11 | Ibm | Method for deployment of incremental versions of applications |
| US6202208B1 (en) | 1998-09-29 | 2001-03-13 | Nortel Networks Limited | Patching environment for modifying a Java virtual machine and method |
| JP2000276381A (ja) | 1999-03-23 | 2000-10-06 | Toshiba Corp | タスク実行時間の見積もり方法 |
| JP3751466B2 (ja) * | 1999-03-26 | 2006-03-01 | 沖電気工業株式会社 | プログラム応答時間予測装置 |
| GB2357168A (en) * | 1999-12-10 | 2001-06-13 | Inventec Corp | Dynamically maintaining the functional module of an application program |
| JP3986721B2 (ja) * | 2000-01-20 | 2007-10-03 | 三菱電機株式会社 | ソフトウェア・モジュール動的交換方法及びソフトウェア・モジュール動的交換プログラム記録媒体 |
| US6973646B1 (en) * | 2000-07-21 | 2005-12-06 | International Business Machines Corporation | Method for compiling program components in a mixed static and dynamic environment |
| US20030182414A1 (en) * | 2003-05-13 | 2003-09-25 | O'neill Patrick J. | System and method for updating and distributing information |
| JP2002318703A (ja) | 2001-04-20 | 2002-10-31 | Seiko Epson Corp | 制御システム |
| US8205193B2 (en) * | 2001-06-11 | 2012-06-19 | Hewlett-Packard Development Company, L.P. | Runtime updating of virtual machine class files |
| JP2003122409A (ja) * | 2001-10-11 | 2003-04-25 | Fuji Electric Co Ltd | プログラムチェック方法、シーケンスプログラム編集装置、記録媒体、及びプログラム |
| US7603662B2 (en) * | 2002-10-09 | 2009-10-13 | Microsoft Corporation | System and method for sensing types of local variables |
| US7784044B2 (en) | 2002-12-02 | 2010-08-24 | Microsoft Corporation | Patching of in-use functions on a running computer system |
| US7461373B2 (en) * | 2002-12-05 | 2008-12-02 | Samsung Electronics Co., Ltd. | Apparatus and method for upgrading software of a wireless mobile station |
| US7536678B2 (en) * | 2003-12-04 | 2009-05-19 | International Business Machines Corporation | System and method for determining the possibility of adverse effect arising from a code change in a computer program |
| US20050257205A1 (en) * | 2004-05-13 | 2005-11-17 | Microsoft Corporation | Method and system for dynamic software updates |
| JP4870915B2 (ja) * | 2004-07-15 | 2012-02-08 | 株式会社日立製作所 | ストレージ装置 |
| CN100552629C (zh) * | 2005-04-18 | 2009-10-21 | 捷讯研究有限公司 | 实现基于数据兼容性的版本计划 |
-
2003
- 2003-08-01 DE DE10335989.3A patent/DE10335989B4/de not_active Expired - Lifetime
-
2004
- 2004-07-30 IT IT001557A patent/ITMI20041557A1/it unknown
- 2004-07-30 FR FR0408467A patent/FR2858436B1/fr active Active
- 2004-07-30 US US10/903,863 patent/US8108852B2/en active Active
- 2004-07-30 CN CNB2004100588255A patent/CN100388193C/zh active Active
- 2004-07-30 JP JP2004222850A patent/JP4836419B2/ja active Active
-
2007
- 2007-12-27 JP JP2007336097A patent/JP2008135049A/ja active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6092079A (en) * | 1998-01-29 | 2000-07-18 | International Business Machines Corporation | Apparatus and method for updating an object without affecting the unique identity of the object |
| US6260187B1 (en) * | 1998-08-20 | 2001-07-10 | Wily Technology, Inc. | System for modifying object oriented code |
| US6298353B1 (en) * | 1998-11-19 | 2001-10-02 | International Business Machines Corporation | Checking serialization compatibility between versions of java classes |
Non-Patent Citations (2)
| Title |
|---|
| ADL-TABATABAI A-R ET AL: "FAST, EFFECTIVE CODE GENERATION IN A JUST-IN-TIME JAVA COMPILER", ACM SIGPLAN NOTICES, ACM, ASSOCIATION FOR COMPUTING MACHINERY, NEW YORK, NY, US, vol. 33, no. 5, May 1998 (1998-05-01), pages 280 - 290, XP000766277, ISSN: 0362-1340 * |
| SEGAL M: "ON-THE-FLY PROGRAM MODIFICATION: SYSTEMS FOR DYNAMIC UPDATING", IEEE SOFTWARE, IEEE SERVICE CENTER, LOS ALAMITOS, CA, US, vol. 10, no. 2, March 1993 (1993-03-01), pages 53 - 65, XP000913803, ISSN: 0740-7459 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100146481A1 (en) * | 2008-12-09 | 2010-06-10 | Microsoft Corporation | Developing applications at runtime |
Also Published As
| Publication number | Publication date |
|---|---|
| CN100388193C (zh) | 2008-05-14 |
| DE10335989A1 (de) | 2005-03-17 |
| JP4836419B2 (ja) | 2011-12-14 |
| JP2005056415A (ja) | 2005-03-03 |
| US8108852B2 (en) | 2012-01-31 |
| FR2858436B1 (fr) | 2007-09-28 |
| US20050066320A1 (en) | 2005-03-24 |
| CN1580994A (zh) | 2005-02-16 |
| ITMI20041557A1 (it) | 2004-10-30 |
| DE10335989B4 (de) | 2019-07-11 |
| JP2008135049A (ja) | 2008-06-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2858436A1 (fr) | Procede et systeme pour modifier un programme oriente objet en cours d'execution | |
| EP2169547B1 (fr) | Modèle de compilation pour un contrôleur programmable. | |
| US8275680B2 (en) | Enabling transactional mechanisms in an automated controller system | |
| US7660638B2 (en) | Business process execution engine | |
| CN107391104B (zh) | 一种客户端与react native代码的更新依赖管理方法、装置及系统 | |
| US11667033B2 (en) | Systems and methods for robotic process automation | |
| EP1929399A2 (fr) | Systeme et procede de creation et d'utilisation d'instances d'objet graphique dans un environnement de charte d'etat | |
| CN109189374B (zh) | 基于对象引用链的对象构造代码生成方法及系统 | |
| JP2009532754A (ja) | 継続ベースのメタランタイムのための抽象実行モデル | |
| EP3208712B1 (fr) | Système informatique et procédé d'optimisation et de déploiement de code de programme parallèle | |
| WO2007044170A1 (fr) | Mecanisme extensible destine a une composition d'objet | |
| CN103197927B (zh) | 一种柔性工作流的实现方法及其系统 | |
| Khan et al. | A study: selection of model metamodel and SPL tools for the verification of software product lines | |
| US20220222106A1 (en) | Automatic run suspension management | |
| US20140189636A1 (en) | Migration between model elements of different types in a modeling environment | |
| EP3881515B1 (fr) | Système de supervision formelle de communications | |
| CN116560801B (zh) | 一种跨容器的柜面系统信创迁移方法及设备 | |
| CN111913720A (zh) | 一种程序部署方法及装置 | |
| Anthony et al. | A middleware approach to dynamically configurable automotive embedded systems | |
| US20230297346A1 (en) | Intelligent data processing system with metadata generation from iterative data analysis | |
| Costa et al. | Using runtime models to unify and structure the handling of meta-information in reflective middleware | |
| CN117950684A (zh) | 一种巡检任务执行处理方法及装置 | |
| CN117280319A (zh) | 用于适应在自动化系统中使用的能重新配置的运行时系统的系统和方法 | |
| CN115145599A (zh) | 一种增量升级包的构建方法、系统及存储介质 | |
| CN111381856A (zh) | 一种Java软件热更新的方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |