JP4836419B2 - 産業オートメーション用のｃｉｌコード・プログラムのオンライン修正 - Google Patents

Description

一般的に言って、本発明は、産業オートメーション・システムに関し、具体的には、動作中のオブジェクト指向プログラム、特にオートメーション設備を制御するプログラムの修正ならびにオートメーション設備の制御ユニット内の実行中の制御プログラムのランタイム・システムに関する。

制御システムは、ますます頻繁に、たとえば産業製造アセンブリまたは最終アセンブリなど、特に大規模な産業プロセスまたは動作シーケンスの制御または調整に使用されている。同様に、制御システムは、可能な最大の範囲まで自動的に操作されるプロセスを監視し、現在のプロセス状況を示すのに使用される。

そのようなオートメーション設備または自動化プラントは、それによって容易にされる高い度合の生産性のゆえに、産業製造で著しい重要性を達成してきた。

生産性の目減りを避けるために、オートメーション設備を停止させるかある状態にする必要なしに、オートメーション設備の制御プログラムを修正することが可能でなければならない。

それ以外に、たとえば荷作り機の場合に、制御プログラムと、それに含まれる変数の現在の内容の間の関係が、プログラム修正の結果として失われ、したがって、現在のプロセス状態に関する情報がもはや入手可能でない場合に、包装材料ならびに包装される商品の両方を除去する必要がある。

オートメーション設備のめいめいの最新の状態に関わりなく、修正されたプログラムを採用できるようにするために、ある必要条件を満たさなければならない。その一方で、プログラム切り替えは、リアル・タイムで行われなければならない。これは、制御プログラムのセット応答時間または実行インターバルを超えてはならないことを意味する。さらに、現在のプログラム状態、特にデータ、たとえばオートメーション設備の現在のプロセス状態に関する情報を含むデータを、修正されたプログラムによって維持し、使用し続けることが非常に重要である。

ＳＰＳ制御システムの場合に、これらは産業オートメーションで使用されるので、さまざまな異なるプログラミング・システムが、現在、すでに、プログラム実行を中断する必要なしに、プログラム修正を実施することができる。この特徴を、頻繁に、「オンライン・プログラミング」と称する。しかし、これらのシステムでは、プログラミング・システムと制御システムのランタイム・システムの間の緊密な調整を必要とするプロセスが使用される。それを行う際に、プログラミング・システムは、修正の前にプログラムの状態に関する情報を管理し、したがって、その情報から、プログラム修正を実施するのに必要な、必要な処置を導出する。

しかし、今日のプログラミング・システムは、頻繁に、機能性に関する制約を特徴とする。したがって、たとえば、リアルタイム態様は、一般に、極まれに考慮に入れられる。それよりも、プログラム実行の中断の持続時間がクリティカルでないと仮定される。これは、プログラム・コマンドの修正だけを許容し、変数オブジェクトまたはオブジェクト構造に対する変更（インスタンス化）をサポートしないプログラミング・システムに関してそうである。他のシステムでは、グローバル・データ・オブジェクトが使用されるが、この場合には、ユーザが手作業でプログラム変数に対処する。しかし、ユーザは、プログラム修正が実施された後に変数が古い内容を保っていることを保証する責任を負う。そのような単純なプログラミング・モデルの主な短所は、オブジェクト指向ではなく、データ・カプセル化を許容しないことである。

使用されるプログラミング・システムに対する要求によって、産業制御エンジニアリングの分野での展開のために特に開発されたプログラミング・ツールを使用することだけが可能になる。

したがって、本発明の目的は、展開されたプログラミング・システムの機能性に今まで課せられていた制限の広範囲のまたは本質的に完全な除去を与える、オートメーション設備の動作中にその制御プログラムに対する修正を実行する方法という問題を解く、建設的な形を識別することである。具体的に言うと、目的は、特にこの目的のために適合されたことがないプログラミング・ツールを使用してプログラムを修正することである。

本発明のもう１つの課題は、動作中の制御プログラムを修正する時に、オートメーション設備のリアルタイム要件を厳守する形を示すことである。

この課題は、独立請求項の１つに基づくオブジェクトを使用することによって、驚くほど簡単に解決することができる。有用な実施形態およびさらなる開発が、サブクレームで概要を示されている。

しかし、まず、この説明および請求項全体に適用可能ないくつかの用語を、定義するか明瞭にする。

オブジェクト指向プログラミングでは、クラスによって、オブジェクトを再生する抽象エンティティが記述される。オブジェクトは、クラスのインスタンスすなわち、クラス・テンプレート基づいて生成される、コンピュータ・システムのメモリ内のイメージを構成する。

クラスは、異なるいわゆるメンバを有することができる。とりわけ、これには、クラスのメソッドおよびフィールドが含まれる。サブクラスも、クラスのメンバとすることができる。

スタックは、プログラムが状況データをバッファリングする、専用のストレージ・エリアを指す。ヒープは、データ構造が一時的に保管されるメモリの部分であり、そのデータ構造の存在およびサイズは、プログラムを実行する前に判定することができない。

本発明による、動作中のオブジェクト指向プログラム、具体的には、中間コードの形でメモリに保管され、ラン・タイムに実行可能機械コードに変換できる、オートメーション設備を制御するプログラムを修正する方法に、やはり中間コードの形での、修正されたプログラムまたは修正されたプログラム・モジュールの提供、修正を判定するための修正されたプログラムの中間コードと実行中のプログラムの中間コードの比較、ならびに実行中のプログラムでの修正の実施が含まれる。

この手順の大きな利益は、ソース・コードから中間コードを生成するプログラミング・ツールが、実施されるプログラム修正に関する追加情報を生成する必要がないという事実にある。したがって、プログラミング・ツールは、実行中のプロセスでプログラム修正を実施するための追加機能を一切必要としない。この課題は、ランタイム・システム、具体的にはｅＣＬＲランタイム・システム（Ｅｍｂｅｄｄｅｄ Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ）によって引き受けられる。用語“ｅＣＬＲ”は、埋め込みされた共通の言語ランタイム（Ｅｍｂｅｄｄｅｄ Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ）」の略語である。ｅＣＬＲシステムは、典型的には極めて資源の制約されたデバイスである埋め込み化デバイスに特に適合するランタイム環境を指す。ｅＣＬＲシステムは、例えばＮＥＴマイクロフレームワークにより提供される。これによって、プロセスの動作中にプログラミング・ツールを使用してプログラム修正をサポートできるようになり、このプログラミング・ツールは、産業制御エンジニアリングの分野での使用のために特に開発されたものではない。

ここでは、中間コードとしてＣＩＬ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｌａｎｇｕａｇｅ）またはＭＳＩＬ（Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｌａｎｇｕａｇｅ）を使用することが好ましい。ＣＩＬおよびＭＳＩＬは、同一の中間コードの異なる用語である。ＣＩＬ中間コードは、Ｍｉｃｒｏｓｏｆｔ（登録商標）社の．ＮＥＴプラットフォームの構成部分である。ＣＬＩ中間コードを使用することの長所は、クラスの構成に関する完全な記述が含まれるという事実である。

中間コードを、やはり．ＮＥＴプラットフォームの一部であるＪＩＴ（ジャストインタイム）コンパイラを使用して、実行可能機械コードに変換することが好ましい。
動作中のプログラムに対する修正の実施に、１つまたは複数の第１プログラム・オブジェクトの生成と、１つまたは複数の第２プログラム・オブジェクトに含まれるデータの、前述の１つまたは複数の第１プログラム・オブジェクトへのコピー（第２プログラム・オブジェクトは、動作中のプログラムの一部である）と、１つまたは複数の第２プログラム・オブジェクトから１つまたは複数の第１プログラム・オブジェクトへの切り替えが含まれ、第２プログラム・オブジェクトが、動作中のプログラムの一部であることが好ましい。

これには、バックグラウンドであるステップを実行することによって、プログラム修正を準備することが可能であるという利点がある。
さらに、修正プログラムが生成され、これは、修正の実施に非常に有用である。規則として、これは、ランタイム・システムによって行われ、プログラム修正を実施するのに必要なステップの編成された自動的シーケンスを提供するように働く。このために、たとえば、ランタイム・システムは、中間コードを生成し、この中間コードは、ＪＩＴコンパイラによって実行可能機械コードに変換され、自動的に実行される。

修正が実施された後に、もはや使用されないプログラム・オブジェクトに割り振られたメモリが、割振り解除される。ＣＬＲランタイム・システムのいわゆる「ガーベジ・コレクション」機能を、この目的に使用することができる。

オートメーション設備で動作するプロセスは、一般に、あるリアルタイム要件の対象である。厳守されなければならないリアルタイム判断基準に基づいて、プログラムによって制御されるオートメーション・システムの少なくとも１つの応答時間および／またはプログラムの少なくとも１つの実行インターバルを条件として、修正を実施する時に超えてはならない最大時間をセットすることが、可能である。

このために、手順に、シミュレーションによって、修正を実施するのに必要な時間を判定できる有用な機能が含まれる。

やはり特に有利なのが、修正が、少なくとも２つのサブステージで実施されるという事実である。ここで、準備処置、たとえばプログラム・オブジェクトの生成およびデータのコピーが、第１サブステージ中に実施され、第２サブステージ中に、システムが、たとえば、新たに生成されたプログラム・オブジェクトに切り替えられる。第１サブステージ中に、動作中のプログラムの動作シーケンスで、たとえば既にコピーされたデータの修正をもたらす可能性があるイベントが発生する場合に、後の時点で第１サブステージを繰り返すことが可能である。

制御プログラムで通常そうであるように、動作中のプログラムが、アクティブ状態とアイドル状態の間で周期的に切り替えられる場合に、この手順では、とりわけ、プログラムがアクティブ状態に切り替えられる１つまたは複数の時点を便利に計算することができる。

修正の実施に必要な時間も既知である場合には、オートメーション設備のリアルタイム条件を厳守すると同時に修正を実施できる特定の時点を判定することが可能である。

さらに、本発明には、メモリ内容を読み取り、書き込む手段を含む、特に上で説明した手順を実施する、オートメーション設備の制御ユニットで制御プログラムを実行するランタイム・システムであって、制御ユニットが、アドレス可能メモリを有し、制御プログラムが、第１メモリ・エリア内の第１中間コードの形で検索可能にファイリングされ、第１中間コードの少なくとも一部を、実行可能制御コマンドに変換することができ、この実行可能制御コマンドが、プロセスがオートメーション設備で動作中である間に第２メモリ・エリアにファイリングされ、ランタイム・システムが、第３メモリ・エリア内で割り振られる第２中間コードの提供に応答し、これによって、オートメーション設備のプロセス・シーケンスが修正される、ランタイム・システムも含まれる。

オートメーション設備の動作シーケンスは、第３メモリ・エリアの少なくとも１区画と、第２メモリ・エリアの区画の開始アドレスが保管される第２メモリ・エリアの少なくとも１つのストレージ・ユニットとを選択することと、第１メモリ・エリアに保管された第１中間コードと第３メモリ・エリアに保管された第２中間コードを比較することと、第３メモリ・エリアの区画に保管された中間コードを、第４メモリ・エリアに保管される実行可能制御コマンドに変換することと、第２メモリ・エリアの区画から第３メモリ・エリアの区画にデータをコピーすることと、第４メモリ・エリアの開始アドレスを第２メモリ・エリアのストレージ・ユニットに保管することとによって、便利に修正することができる。

ランタイム・システムは、ＣＬＲランタイム・システム、特にｅＣＬＲランタイム・システムであることが好ましい。というのは、このタイプのランタイム・システムが、上で説明した効果を達成するのに特に適する機能を特徴とするからである。

本発明による手順の説明で既に述べたように、中間コードとしてＣＩＬ中間コードを使用することが好ましい。さらに、中間コードを実行可能制御コマンドに変換するランタイム・システムに、ＪＩＴコンパイラも好ましく含まれなければならない。

編成された形でプログラム修正を実行するために、ランタイム・システムは、制御コマンドの生成、保管、および実行の有用な手段を特徴とする。

リアルタイム環境でランタイム・システムを使用する時には、時間の所与の期間内でプロセス・シーケンスの修正をもたらすことが可能である。このために、ランタイム・システムに、オートメーション設備のプロセス・シーケンスの修正をもたらすのに必要な期間を計算する有用な手段が含まれる。

リアルタイム条件を厳守するために、オートメーション設備のプロセス・シーケンスで修正をも当たらすために実行されるルーチンを、全体的にまたは部分的にのいずれかで繰り返すことができる。

本発明の範囲には、上で説明したランタイム・システムが統合され、上で説明した手順の実行に適するオートメーション・システムの識別も含まれる。

以下では、添付図面を参照し、好ましい実施形態に基づいて詳細に例示される本発明の概要を示す。それを行う際に、図面の同一の符号は、同一のまたは類似する構成要素を指す。

本発明による手順の以下の実施形態では、ｅＣＬＲランタイム・システムが使用され、このシステムは、ＥＣＭＡ標準規格（Ｅｕｒｏｐｅａｎ Ｃｏｍｐｕｔｅｒ Ｍａｎｕｆａｃｔｕｒｅｒｓ’ Ａｓｓｏｃｉａｔｉｏｎ）で指定されたＣＩＬ中間コードに基づいてプログラムを実行するように働く。ｅＣＬＲランタイム・システムでは、Ｍｉｃｒｏｓｏｆｔ（登録商標）の．ＮＥＴプラットフォームのＣｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ（ＣＬＩ）の仕様が使用される。

検討されるｅＣＬＲランタイム・システムを用いると、動作中にオートメーション設備の制御プログラムに対する変更を行えるようになる。この実施形態ではＣＩＬ中間コードの形の制御プログラムが、規則として、個々のモジュール（アセンブリ）からなり、モジュールのそれぞれに、ＣＩＬ中間コードが含まれる。したがって、制御プログラムは、本質的に、１つまたは複数の修正されたアセンブリを採用し、アクティブ化することによって修正される。

まず、修正を、修正されるプログラムまたはアセンブリのソース・コードに対して行う。ソース・コードは、たとえば、Ｃ＃またはＩＥＣ６１１３１仕様に対応するプログラミング言語など、さまざまな異なるプログラミング言語でプログラムすることができる。ＣＩＬ中間コードを、プログラミング・ツールを使用して、修正されたソースから生成する。ＣＩＬ中間コードを生成できるすべてのプログラミング・ツールが、この目的に適する。

すべての修正されるアセンブリのＣＩＬ中間コードを、ｅＣＬＲランタイム・システムにロードする。

次のステップで、ｅＣＬＲランタイム・システムによって、新たにロードされたＣＩＬ中間コード・モジュールが分析され、現在動作しているプログラムと比較される。それを行う際に、存在するすべての相違が検出される。これは、ＣＩＬ中間コードに、メソッドだけではなくクラスのフィールドも含めて、クラスの構造の完全な記述が含まれるという事実によって可能にされるものである。

次に、プログラム更新を準備する。ここで、ｅＣＬＲランタイム・システムが、プログラム・コードを生成し、そのプログラム・コードによって、採用される個々の処置が編成される。これには、特に、修正されたプログラムでも使用される、すべての存在するデータの採用が含まれる。さらに、新しいデータを初期化する。生成されるプログラム・コードの一部に、いわゆるコピー・コンストラクタおよびデルタ・コンストラクタが含まれる。

コピー・コンストラクタおよびデルタ・コンストラクタは、修正されるクラスごとに生成される。次のステップ中に、修正されるクラスのオブジェクトが、Ｎｅｗ演算子によって生成され、それに続いて、デルタ・コンストラクタが実行される。

このステップでは、クラスのすべての追加の新しいメンバが、生成され、かつ／または初期化される。次のステップで、コピー・コンストラクタによって、オブジェクトの現在の値が古いクラスにコピーされる。最後に、古いオブジェクトのすべての参照を、新しいオブジェクトに切り替える。実行のこのステップについて、制御プログラムが、短い時間期間の間ブロックされる。

ｅＣＬＲランタイム・システムは、所与のプログラムの参照を制御するが、これを、マネージ・データ（ｍａｎａｇｅｄ ｄａｔａ）とも称する。参照は、ヒープに保管される。スタックには、ヒープ内のメモリ・アドレスへの参照が含まれる。生成および解放、メモリ空間の割振り、ならびにクラスのメンバへのアクセスは、ポインタを使用して編成される。

各アセンブリに、いわゆるメタ・データが含まれ、メタ・データには、ラン・タイム中にアクセスすることができる。

図１に、メタ・データ（２１から２４、３１、および３２）とアセンブリのコード表現１１から１４の相互作用４１を示す。各アセンブリに、図１に示されているように、たとえばＸおよびＹなど、クラスに関する情報、ならびにそのフィールド３１および３２、メソッド２１から２４が含まれる。この情報は、アセンブリのメタ・データに含まれる。クラスのメソッドおよびフィールドには、依存性４２も示されている。アセンブリがｅＣＬＲシステムにロードされる時には、必ず、対応する中間コードが、ＪＩＴコンパイラによって実行可能機械コードに変換される。クラスの各メソッドは、メモリの管理されるコード・ヒープ内の連続するコード・ブロック１１から１４によって表される。クラスおよびメソッドに関するすべての必要な情報、たとえばどのメソッドがどのクラスまたはメソッド・シグニチャに属するかが、静的データ・エリアであるメタ・データ・ワークスペースに保管される。クラスＸのメソッド２２を表すコード・ブロック１２が実行される時に、たとえば、クラスＹのメソッド２４へのアクセス４３を有することも可能である。各アセンブリに、１つまたは複数のクラスが含まれる。アセンブリの修正または交換が必要になった場合に、実行中のアセンブリと修正されたアセンブリの対応するクラスの間の相違が、まず評価される。この時に、さまざまな異なるケースを考慮に入れる。

第１のケースでは、両方のクラスに、同一のメソッドおよびフィールドが含まれる。同様に、中間コードも同一である。これは、たとえば、コードのＣＲＣ検証の助けによって検証することができる。中間コードの間に相違がないので、このケースでは、さらなるステップは不要である。

第２のケースでは、両方のクラスに、同一のメソッドおよびフィールドが含まれる。しかし、動作中のアセンブリの対応するクラスと比較して、修正されたアセンブリの１つまたは複数のメソッドが、修正された中間コードを有することが明らかになる。このケースでは、修正されたメソッドのコンパイルが実行され、この形で生成されたコードへのポインタが、元のメソッドの記述子に割り振られる。このケースでは、１つのポインタ要素だけが割り振られるので、切り替えは非常にすばやい。

第３のケースでは、両方のクラスに、もはや同一のメソッドが含まれない。これは、修正されたクラスに追加のメソッドがある場合、元のクラスに前に存在したメソッドがもはや含まれない場合、または両方のクラスに異なるシグネチャを有するメソッドが含まれる場合のいずれかに、そうなる可能性がある。このケースでは、メソッドの１つを削除する必要が生じる場合がある。そうである場合には、削除されるメソッドに、すべての修正が実行された後のアクティブ・コードへの参照が含まれるかどうかを確認するために、検証を実行する。これを、下の例によって示す。この例では、２つのアセンブリＡおよびＢを検討し、アセンブリＡには、クラスＸが含まれ、アセンブリＢには、クラスＹが含まれる。メソッドＸ：：ｐｒｏｃｅｓｓ（）が、メソッドＹ：：ｐｒｏｃｅｓｓ（）を呼び出す。クラスＹのメソッドｐｒｏｃｅｓｓ（）が削除される場合に、追加の対応する修正が、メソッドＸ：：ｐｒｏｃｅｓｓ（）で実装される。これに関して、同時に複数のアセンブリを修正する必要がある場合もある。

第４のケースでは、２つのクラスの少なくとも１つのフィールドが異なる。このケースでは、オブジェクトを修正しなければならない。削除されるフィールドに関する検証を最初に実行するが、これは、第３のケースで説明した検証と同一の形で行われる。すべての修正が許容可能である場合に、コピー・コンストラクタを生成する。

修正されたクラスが元のクラス型のメンバを採用する形の基本的な説明を、下で示す。規則として、これは、コピー・コンストラクタの助けを得て行われる。コピー・コンストラクタは、古いクラス型並びに新しいクラス型の両方に含まれるすべてのクラス・メンバをコピーする、特殊な関数である。

クラス・メンバが両方のクラスに含まれるか否かを判定するために、３つのケースを区別する必要がある。

クラス・メンバの名前とデータ型が同一である場合に、そのクラス・メンバは、同一である。この第１のケースでは、クラス・メンバの間の強い関係が記述される。このケースが適用されるすべてのクラス・メンバが、コピー・コンストラクタによって、１対１でコピーされる。

クラス・メンバの名前だけが同一で、データ型が要素データ型である場合に、クラス・メンバの間に弱い関係がある。このケースが適用されるすべてのクラス・メンバが、コピーされ、たとえば「ｂｙｔｅ」データ型から「ｉｎｔ」データ型に、変換される。

第１のケースおよび第２のケースの両方があてはまらない場合に、クラス・メンバは、異なり、したがって関連しないと考えられる。これらのクラス・メンバは、コピー・コンストラクタによって処理されない。

これを、図２の例によってもう一度説明する。図２で符号６１から６３の矢印によって表されるように、最初のクラス５１のクラス・メンバａ、ｂ、およびｄは、修正されたクラス５２のクラス・メンバａ、ｂ、およびｄと同一であり、コピー・コンストラクタによってコピーされる。クラス５１のクラス・メンバｃは、クラス５２のクラス・メンバｃと同一の名前であるが、データ型が異なる。名前ｃを有するこの２つのクラス・メンバの間に、弱い関係がある。したがって、クラス・メンバｃをコピーする時に、変換６４も行われる。クラスｅ、ｆ、およびｇは、関係せず、したがって、コピー・コンストラクタによって処理されない。

スタティック・クラス・メンバは、インスタンスごとではなく、クラス型ごとに表されるだけなので、コピー・コンストラクタは、非スタティック・クラス・メンバだけを考慮に入れる。

元のクラス型および修正されたクラス型のメタ・データにアクセスすることによって、ｅＣＬＲランタイム・システムは、クラス型の間の差を分析でき、めいめいのクラス型に対応するコピー・コンストラクタを生成することができる。

中間コードの形のコピー・コンストラクタの例を、下に示す。
.method public hidebysig instance void copyctor(...)
ldarg,0
ldarg.1
ldfld int32 Application.Test2/* 02000005 */::x1/* 04000022 */
stfld int32 Application.Test1/* 02000006 */::x1/* 04000025 */
ldarg,0
ldarg.1
ldfld char Application.Test2/* 02000005 */::x2 /* 04000023 */
stfld int32 Application.Test1/* 02000006 */::x2/* 04000026 */
ldarg.0
ldarg.1
ldfld int32 Application.Test2/* 02000005 */::x3/* 04000024 */
stfld int32 Application.Test1/* 02000006 */::x3/* 04000027 */
ret

本質的に、コピー・コンストラクタには、２つの中間コード・コマンドｌｄｆｌｄ（ｌｏａｄ ｆｉｅｌｄ）およびｓｔｆｌｄ（ｓｔｏｒｅ ｆｉｅｌｄ）が含まれる。このコマンドの対は、データ型に関して異ならないフィールドに使用される。フィールドの間の弱い関係は、データ型が異なるが、基本データ型すなわち、ｂｏｏｌ、ｉｎｔ８、ｕｉｎｔ８、ｉｎｔ１６、ｕｉｎｔ１６、ｉｎｔ３２、ｕｉｎｔ３２、ｉｎｔ６４、ｕｉｎｔ６４、ｒｅａｌ３２、およびｒｅａｌ６４に属する場合に仮定される。この場合に、弱い関係を示すクラス・メンバを互いに変換するために、ｃｏｎｖ．ｉ４（ｉｎｔ３２）またはｃｏｎｖ．ｒ４（ｒｅａｌ３２）などの演算子を使用する必要が生じる場合がある。

中間コードの形で引用される次の例では、データ型ｉｎｔのあるクラスのフィールドＸ１が、データ型ｒｅａｌに変換される。
ldfld X: :X1 // int データ型
conv.r4
stfld X*: :X1 // real データ型

ｅＣＬＲランタイム・システムは、ＪＩＴコンパイラによって、コピー・コンストラクタを実行可能機械コードに変換する。たとえば、下に示すＩｎｔｅｌベースのアセンブラ・コードを、コピー・コンストラクタの変換の結果とすることができる。
mov esi dword ptr [ebp+8] ; ソース・オブジェクト
mov edi dword ptr [ebp+12] ; 宛先オブジェクト
mov eax dword ptr [esi+4]; x1 (古いクラス)
mov dword ptr [di+8], eax ; x1 (新しいクラス)

基本データ型に割り振ることができない修正されたデータ型を示すフィールドの場合には、２つの異なるケースを区別する必要がある。

基底型が「システム．オブジェクト」である場合には、オブジェクトが、ｅＣＬＲランタイム・システム自体によって更新される。基底型が「システム．値型」である場合には、コピー・コンストラクタに、この修正されたクラスのコピー・コンストラクタを実行するコードが含まれる。

次の例で、修正されるクラスのサブクラスの場合のコピー・コンストラクタの階層構造を示す。

C#
----
structs S { int x1; int x2; }
class X {
int x1;
S s1;}
}
ILコード・コピー・コンストラクタX::copyctor:
-------------------------------------
ldfld X: :X1 // int データ型
stfld X*::X1
ldflda X::s1
ldflda X*::s1
call S::copyctor

この場合に、このクラス型の対応するコピー・コンストラクタを呼び出すために、中間コード・コマンドｌｄｆｌｄａ（ｌｏａｄ ａｄｄｒｅｓｓ ｏｆ ｆｉｅｌｄ）が、サブクラスのアドレスをロードするのに使用される。

すべてのコピー・コンストラクタを実行可能機械コードに変換した後に、ｅＣＬＲランタイム・システムは、コピー・コンストラクタが生成された修正されたクラスへのすべての参照を収集する。そのような参照は、たとえば、グローバル・データ・エリア内の静的参照、あるいはローカル・コール・スタック内または他のオブジェクト内のサブクラスについて、局所化することができる。すべてのオブジェクト参照のリストを生成した場合に、修正されたオブジェクトが、Ｎｅｗ演算子を使用して、ｅＣＬＲランタイム・システムによって再生成される。生成され、初期化された後に、オブジェクトがコピーされる。この時に、コピー・コンストラクタによって、古いオブジェクトの現在の内容が、すべての新しいオブジェクトに割り振られる。

この時点までに、修正されるプログラムに割り振られたスレッドが、この処理中にアクティブ化されたことをｅＣＬＲシステムが検出した場合に、参照の収集ならびにオブジェクトの生成およびコピーを、繰り返すことができる。

次に来るのが、クリティカル・フェーズであり、これは、中断できず、このフェーズで、すべての参照が修正される。このフェーズでは、修正されるプログラムが、ブロックされる。ポインタ割振り、したがってこの目的に必要な時間は、オブジェクト・インスタンスおよびその参照の数ならびに修正のスコープに依存する。

オブジェクト参照を修正することによって切り替えが行われた後に、その間に修正されたプログラムの実行を、再開することができる。スレッドのブロックが、解除される。ｅＣＬＲランタイム・システムのもう１つの機能が、もはや不要な、予約されたメモリの割振り解除である。

本発明のもう１つの態様が、制御プロセスに関して明記されたリアルタイム判断基準が、プログラム修正が実行されている時に常に厳守されることを保証するプロセスである。規則として、制御プログラムは、周期的に実行される。リアルタイム判断基準は、プログラムの実行インターバルによって定義され、このインターバルに、入力が読み取られ、制御プログラムが実行され、出力が書き込まれる。

リアルタイム判断基準の厳守は、上で既に述べたように、プログラム修正の実施形態を、準備フェーズおよびクリティカル・フェーズに副分割することによって達成される。プログラム修正を成功裡に実施するために、制御プログラムのプログラム・コマンドを、このどちらのフェーズでも実行してはならない。

準備フェーズは、プログラム修正を実施するすべての必要な処置の事実上すべて（約９９％）を含むが、準備フェーズに、何回でも割り込み、繰り返すことができる

準備フェーズがプログラム・コマンドの実行によって割り込まれるイベントにおいて、この準備フェーズをいつでももう一度開始することができる。

クリティカル・フェーズには、新しいプログラムのアクティブ化が含まれる。一貫性のために、アクティブ化は、すべてのプログラム・オブジェクトについて同時に行わなければならない。これが、このプロセスに割り込めない理由である。

本発明を使用すると、両方のフェーズに必要な時間を、正確に判定することができる。プログラム修正を実施する実行時間は、どの場合でも、アプリケーション・プログラムの最短の実行インターバルより短くしなければならない。通常のリアルタイム要件では、約１０ｍｓの領域のサイクル・タイムが要求される。

プログラム・サイクルの次のアクティブ化までの時間を、前もって計算することができる。したがって、周期的に実行されるプログラムの場合に、次の実行が行われる時を予測することも可能である。

イベント制御式プログラムについては、予測を行うことができない。しかし、クリティカル・フェーズの持続時間は、いわゆるジッタに影響する。したがって、クリティカル・フェーズ中にイベントが発生する場合に、速くてもそのクリティカル・フェーズが完了した後でなければ、そのイベントを対応するプログラムによって処理することができない。最大ジッタ許容範囲が、プログラムのクリティカル・フェーズを実行するのに必要な時間より短い場合には、このように定義されたリアルタイム判断基準を厳守することによって、プログラム修正を実行することがいつでも不可能になる。

動作シーケンスを、時間に関する異なる優先順位の異なるタスクのアクティビティを示す、例示的な優先順位／時間図によって、図３に示す。あるタスクがアクティブ状態に切り替えられる場合に、より低い優先順位を有する他のすべてのタスクが、割り込まれる。

タスク７３は、割り振られたプログラム・モジュールＰ３を有する、動作中のプログラムのメイン・タスクである。このタスクは、１５ｍｓの時間インターバルで周期的に実行される。この例に示された実行中のプログラムのさらなるタスクに、１０ｍｓの時間インターバルの、割り振られたプログラム・モジュールＰ１を有する周期的タスク７１、ならびに割り振られたプログラム・モジュールＰ２を有するイベント指向タスク７２が含まれる。リアルタイム要件に起因して、動作中のプログラムに割り振られるタスクは、最高の優先順位を有する。

図３で修正マネージャと称するｅＣＬＲランタイム・システムによって、プログラム修正が編成される。修正マネージャに割り振られたタスク８１および８２によって、修正が実施される。この例では、タスク８１は、メイン・タスク７３がアイドル状態に切り替えられた後に開始される。しかし、実行中に、タスク７１がアクティブ状態に切り替えられるので、タスク８１はタスク７１によって割り込まれる。その後、この例ではメイン・タスク７３がアイドル状態に切り替えられる次の可能な時点の間に、修正を実施するタスク８２が再開始される。タスク８２は、他のタスクによって割り込まれず、これは、修正が成功裡に実施されることを意味する。この例では、プログラム・モジュールＰ３が変更された。成功裡に修正されたので、修正されたプログラム・モジュールＰ３＊を実行する。タスク７４は、たとえば通信またはデバッグに使用される、ｅＣＬＲシステムのもう１つのタスクである。

アセンブリのメタデータおよびコード表現を示す概略図である。 クラスのフィールドの修正を示す図である。 動作中のプログラムの複数のタスクならびにこのプログラムの修正を実施するタスクの詳細を示す優先順位／時間図である。

Claims (4)

1. 現在実行されつつあるオブジェクト指向プログラムを修正する方法であって、該方法は、メモリ内容を読み取り、書き込む手段を含み、オートメーション設備の制御ユニット内で制御プログラムを実行するランタイム・システムによって実行され、
   該制御ユニットは、アドレス可能メモリを有し、該制御プログラムは、第１メモリ・エリア内に第１中間コードの形で検索可能にファイリングされ、該第１中間コードの少なくとも一部が、実行可能制御コマンドに変換され、該実行可能制御コマンドが、プロセスがオートメーション設備で動作中である間に第２メモリ・エリアにファイリングされ、ランタイム・システムが、第３メモリ・エリア内で割り振られる第２中間コードの提供に応答し、それによって該オートメーション設備内で該プロセスのシーケンスを修正し、該第１の中間コードは、メソッド及びそれぞれのクラスのフィールドを含む、実行中のプログラムのクラスの構造の完全な記述を含んでおり、該第２の中間コードは、メソッド及びそれぞれのクラスを含む、修正されたプログラムのクラスの構造の完全な記述を含んでおり、
   該オートメーション設備の動作シーケンスは、バックグラウンドで自動的に修正することができ、該修正の実行は、
   該第１の中間コートと該第２の中間コードとを比較して修正されたクラスを決定するステップと、
   準備フェーズにおいて、
   該第２の中間コードに基づいて、決定された１つの修正されたクラスの少なくとも１つの第１のプログラム・オブジェクトを生成し、
   該実行中のプログラムの一部である少なくとも１つの第２のプログラム・オブジェクト内に含まれるデータを、少なくとも１つの第１のプログラム・オブジェクト内にコピーするステップと、
   クリティカル・フェーズにおいて、
   該少なくとも１つの第２のプログラム・オブジェクトから該少なくとも１つの第１のプログラム・オブジェクトに切り換え、該実行中のプログラムの一部である該少なくとも１つの第１のプログラム・オブジェクトを形成するステップとを含み、
   該修正は、該制御プログラムのタスクに割り当てられた優先順位よりも低い優先順位を該ランタイム・システムのタスクに割り当てることで、該制御プログラムが実行されている該制御プログラムの実行インターバルによって定義される、該制御プログラムに関して明記されたリアルタイム判断基準が、該制御プログラムの修正が実行されているときはいつでも常に遵守されることを保証するように、実行され、該準備フェーズがプログラム・コマンドの実行によって中断される場合には、該準備フェーズはもう一度開始され、該クリティカル・フェーズの実行のために、該制御プログラムは、割り当てられた優先順位に関わりなくブロックされ、該制御プログラムの最大ジッタ許容範囲が、該クリティカル・フェーズを実行するのに要求される時間よりも長い方法。
   
2. 該中間コードの実行可能機械コードへの該変換が、ＪＩＴコンパイラによって行われる、請求項１に記載の方法。
   
3. 該修正を実施した後に、もはや使用されないプログラム・オブジェクトに割り振られたメモリが、もう一度割振り解除される、請求項１又は２の何れか１項に記載の方法。
   
4. 該修正を実施するのに必要な時間が、シミュレーションによって判定される、請求項１乃至３の何れか１項に記載の方法。

Images