JP2022519776A - プログラマブルロジックコントローラプログラムを分析する方法、コンピュータプログラム及び装置 - Google Patents

Abstract

プログラム（ＰＲＯＧ）が論理フレームワークのモデル（ＭＯＤ）に翻訳され（ＴＲＡＮＳ）、そこからプロパティ（Ｐｒｏｐ）が決定されるＰＬＣプログラム分析方法が開示される。ユーザ仕様（ＩｎｔＰｒｏｐ）に結合された上記プロパティが、自動化ソルバー（ＳＭＴ）によって検証される。プロパティ（Ｐｒｏｐ）の対偶が充足可能である場合、モデル入力及び内部メモリ値を表す反例（ＰＲＯＯＦ ＮＯＫ）が提供される。反例（ＰＲＯＯＦ ＮＯＫ）は、上記モデルのエラー初期構成（ＩｎｉＣｏｎｆ）に翻訳される。上記エラー初期構成（ＩｎｉＣｏｎｆ）を用いて、モデルの実行（ＥＸＥ）のモデルシミュレーションが行われ、上記モデルシミュレーションのエラー中間構成（ＡＳＴ－ＩｎｔＣｏｎｆ）が、上記プロパティ違反まで記録される。上記元のプログラム（ＰＲＯＧ）のエラー初期構成及びエラー中間構成（Ｌａｄ－ＩｎｉＣｏｎｆ、Ｌａｄ－ＩｎｔＣｏｎｆ）が、上記モデルのエラー初期構成（ＩｎｉＣｏｎｆ）及び上記モデルシミュレーションのエラー中間構成（ＡＳＴ－ＩｎｔＣｏｎｆ）から導出され、表示される。上記モデルを実行する装置が提供される。

Description

本発明は、ＩＥＣ６１１３１－３標準規格に記載されている言語で書かれたプログラムを分析する方法及び装置に関する。こうしたプログラムは、特に、工業システムの制御を実行するプログラマブルロジックコントローラ（ＰＬＣ）のために意図されている。

本発明は、より詳細には、ラダー（Ladder）プログラムにおけるエラーを分析、検出及び補正する方法及び装置に関する。

プログラマブルロジックコントローラ（ＰＬＣ）は、組立ライン又はロボットデバイス等、製造プロセスのオートメーションコントローラとして使用される、工業用デジタルコンピュータである。

ＰＬＣには、入力及び内部メモリの値から出力を計算するソフトウェアが設けられ、したがって、ＰＬＣは、配線によるリレー、タイマ及びシーケンサに取って代わった。ラダーロジックとしても知られるラダー言語は、ＰＬＣソフトウェアを開発するために用いられるプログラミング言語である。この言語は、リレーロジックハードウェアの回路の図を用いて、グラフィカルな図によりＰＬＣプログラムを表す。標準規格ＩＥＣ６１１３１－３は、ＰＬＣをプログラミングするいくつかの他の言語もあるがとりわけラダー言語について記載している。

ソフトウェア開発プロセスの一部は、デバッグに割り当てられる。デバッグは、プログラムが安全に且つ所与の仕様に従って挙動することを検査することである。工場におけるバグは、人的及び物的被害、並びにプラント操業中止時間に関して、極めてコストがかかる可能性があるため、デバッグは、製造環境での実装の前に実施する必要がある。

通常の方法は、シミュレーション法であり、それは、初期構成によって定義されるいくつかのテストを設定し、上記テストにおいてプログラムを実行して、これらの構成下でその挙動を検査することである。プログラムは、通常、工場のソフトウェアシミュレーションで実行される。

こうした方法の主な欠点は、こうした方法が、網羅的ではなく且つ時間がかかり、したがって、コストがかかるということである。この非網羅性により、選択されたテストが製造環境においてプログラムのあり得る全ての実行を１回でカバーすることを保証することが極めて困難になる。唯一の保証は、プログラムが、テストされた構成に対してバグがないということであるため、テスト段階の後にプログラムにバグが残る可能性がある。

モデル検査法は、時間及び資源を節約するために、テストするためにプログラム自体ではなくプログラムのモデルを連続的に実行することである。しかしながら、特に工業応用に対して、実行パス関連の複雑性は指数関数的であることが多い。テスト効率は、ＣＰＵ時間によって制限され、したがって、この方法は依然として網羅的ではない。

さらに、テストを生成及び実行するために、少なくともいくつかの構成は手動で定義する必要があるため、上記テストは、部分的に又は完全に手動で開発及び実行される。テスト生成及び実行の一部を自動化することができるが、こうした方法の別の欠点は、テストの出力値を依然としてプログラマーが分析しなければならず、バグに関する唯一の入手可能な情報は、バグをもたらす入力及び内部メモリの初期構成であるということである。したがって、エラーの基本的な理由と、考慮される初期構成によりプログラムのいずれかの時点でそのエラーをもたらす理由とを理解することが困難であることが多い。

本発明の１つの態様によれば、プログラマブルロジックコントローラプログラム分析方法であって、
プログラマブルロジックコントローラプログラムのタイプの元のプログラムを論理フレームワークのモデルに翻訳するステップと、
少なくとも上記モデルと、事前定義された言語形式化とから、上記元のプログラムの内部変数に関する一組のプロパティを決定するステップと、
自動化ソルバーにより、ユーザ仕様に結合された上記一組のプロパティの充足可能性を検証し、上記一組のプロパティからのプロパティの対偶が充足可能である場合、上記プロパティの対偶が充足可能であるモデル入力及び内部メモリ値を表す一組の反例を提供し、又は、上記一組のプロパティが常に充足される場合、その確認を提供するステップと、
反例を、上記モデルのエラー初期構成に翻訳するステップであって、上記エラー初期構成は入力及び内部メモリの初期値を含む、ステップと、
上記モデルのエラー初期構成（ＩｎｉＣｏｎｆ）を用いて、モデルの実行（ＥＸＥ）のモデルシミュレーションを行い、実行の開始から上記プロパティ違反まで上記モデルシミュレーションのエラー中間構成を記録するステップであって、上記エラー中間構成は内部メモリの中間値を含む、ステップと、
上記モデルのエラー初期構成及び上記モデルシミュレーションのエラー中間構成を、上記元のプログラムのエラー初期構成及び中間構成に翻訳するステップと、
上記エラー初期構成及び中間構成を表示するステップと、
を含む、プログラマブルロジックコントローラプログラム分析方法が開示される。

これらの特質の下で、プログラムに対する１つの又はいくつかのプロパティが違反されたとき、バグが発生する。プロパティは、プログラムの入力、出力及びローカルメモリの値に関連する。本発明により、シミュレーション環境又は実環境におけるプログラムの実行の前にこうした違反を検出することができる。本方法は、プログラムの実行中にエラーをもたらす入力及びローカルメモリの初期値を見つけることである。デバッグは自動化されるとともに加速される。本方法は、記載した方法でエラーシナリオが見つからない場合に実行構成がプログラムプロパティを違反しないことを保証するため、網羅的である。実際に、従来技術では、テストの実行中にプロパティ違反が検出されない場合であっても、全てのあり得る実行に対してそのプロパティが持続する保証はない。

得られる初期構成及び中間構成により、エラーシナリオに関する、プログラムの実行中にこうしたエラーが発生する場所、方法及び理由を示す有用な情報もまた、プログラムコードとともに提供される。プロパティ違反は正確に説明される。プロパティ違反をもたらす初期構成が計算され、メモリ割当等の実行情報が、初期構成からプロパティが違反されるプログラムの箇所まで、記録及び回収される。本方法は、一階述語論理においてプログラマーによって表される命令エラー又は機能仕様違反のいずれかを、インターロックプロパティ（interlocking property）として検出する。プログラムは、実行中、プロパティ違反をもたらす初期値及び中間値並びにバグを修正する方法等、メモリ値に対する追加の情報とともに、表示することができる。したがって、本方法は、実行すべきテストを決定し、それらの実行を監視し、それらの結果を分析するために、人の介入が不要であるため、自動デバッグを可能にする。

本方法はまた、工業サイズの複雑なプログラムに対して制限がある自動化シミュレーションの場合のように、シミュレートすべき複数のテスト構成下でプログラムを連続的に実行する代わりに、プロパティ検証に依存するため、より高速なデバッグも可能にする。したがって、中央処理装置上での実行時間が削減される。

これらの特質により、ファクトリーオートメーション業界においてラダープログラム展開時間を安全に削減する、効率的な、網羅的な且つ高速なツールが提供される。

モデルは、好ましくは、数学的に証明可能である一階述語論理フレームワークで表され、したがって、計算問題を表現するのに有用である。さらに、一階述語論理は、ラダーモデルから導出されるプロパティと対応する機能仕様を表すように適合され、上位の論理フレームワークと比較して、一階述語論理プロパティの生成は自動化がより容易である。

一実施の形態によれば、元のプログラムをモデルに翻訳するステップは、抽象構文木（Abstract Syntax Tree）としての上記元のプログラムの表現の第１の中間ステップと、上記抽象構文木からのモデルの生成の第２の中間ステップとを含む。

こうした中間ステップの実装は、抽象構文木を、それが含有する全ての要素に対するプロパティ及びアノテーション等の情報により強化することができるため、有利である。上記抽象構文木は、好ましくは、ＯＣＡＭＬ等の関数型言語で記述される。抽象構文木はまた、ラダープログラムにおける各要素の位置を記憶することもでき、それは、モデルのシミュレートされた実行中にエラー中間構成を回収するのに有用である。

このために、モデル実行をシミュレートするステップは、好ましくは、
上記エラー初期構成を、抽象構文木に対応するエラー初期構成に翻訳する第１の中間ステップと、
上記対応する初期構成を用いて抽象構文木を計算し、抽象構文木に対応する内部メモリの中間値を回収する第２の中間ステップと、
を含む。

抽象構文木表現は、命令を接続する論理ゲートにおける値等、ラダープログラムの単純な実行によって得ることができない中間値を生成することができるため、有利である。

一実施の形態によれば、元のプログラムをモデルに翻訳するステップは、静的単一代入変換の中間ステップを含む。静的単一代入変換は、好ましくは、抽象構文木表現に対して適用され、実行中に内部メモリ値を追跡するのに有利である。

一実施の形態によれば、一組のプロパティを決定するステップの間に、上記一組のプロパティは、ダイクストラの最弱事前条件計算法を用いて、上記一組のプロパティに対する事前条件を決定するように計算され、上記一組のプロパティの検証は、その事前条件に基づいて実施される。事前条件は、プロパティに固有である基礎をなす前提である。事前条件が満たされることは、プロパティが検証され、その実行中にエラーが発生しないことを意味する。

一実施の形態によれば、ユーザ仕様と結合された上記一組の述語の充足可能性は、充足可能性モジュロソルバー（Satisfiability Modulo Solver）を用いて検証され、これは、一階述語論理において論理式として表された決定問題である、背景理論付き充足可能性問題を解くように構成された、自動化ソルバーである。

本発明の別の態様によれば、少なくとも１つのプロセッサによって実行されると、上述したような方法を実行する命令を含むコンピュータプログラムが開示される。

好ましい実施の形態では、上記コンピュータプログラムは、演繹的プログラム検証プラットフォームにおいて実行される。

本発明は、本発明による、上記に定義したような方法のステップをコンピュータに実行させる、コンピュータプログラムを記憶する、非一時的コンピュータ可読媒体を更に目的とする。

本発明の別の態様によれば、上述したようなプログラマブルロジックコントローラプログラム分析方法を実行する装置が開示される。こうした装置は、一実施の形態では、
上述したコンピュータプログラム命令、及び場合により一時的な計算データ等の他のデータも記憶するメモリＭＥＭと、
メモリＭＥＭの内容を読み出すとともに、本発明による方法のステップを実行するプロセッサＰＲＯＣと、
場合により、プロセッサＰＲＯＣによって処理されるべき／処理されたデータを（ネットワーク又は他の任意のリンクを通して）受信／送信する入出力インタフェースＩＮＴと、
を備える（図６の例に示すような）処理回路ＰＣを備えることができる。
本発明の他の特徴及び利点は、非限定的な例として与えるその実施の形態のうちの１つの以下の詳細な説明から、且つ添付図面を参照して明らかとなる。

開示する方法に関与する例示的な一組のステップを示す図である。 ラダー図の一例を表す図である。 開示する方法に関与する中間ステップの実行結果を示す図である。 開示する方法に関与する中間ステップの実行結果を示す図である。 開示する方法に関与する中間ステップの別の実行結果を示す図である。 開示する方法の実行の結果としてエラーシナリオを示す図である。 プログラマブルロジックコントローラプログラム分析方法を実行する処理回路ＰＣの一例を示す図である。

図において、同じ参照符号は同一の又は同様の要素を示す。

図１は、参照番号１０によって示す、ラダープログラム演繹的検証に関与する例示的な一組のステップを示す。

本方法の第１のステップ（ＴＲＡＮＳ）は、ＰＬＣプログラム（ＰＲＯＧ）をモデル（ＭＯＤ）に翻訳するものである、翻訳ステップである。

上記ＰＬＣプログラムＰＲＯＧは、以降ＰＬＣと称するプログラマブルロジックコントローラで実行可能である。ＰＬＣは、産業機械及びプロセスを制御するために、順序、計時、計数、算術、データ操作及び通信等の命令を記憶及び実行することができる。フィールドデバイスへのインタフェース回路は、入力接続及び出力接続の形態で提供される。

ラダー図は、ＰＬＣプログラムのシーケンス制御ロジックをグラフィカル図で表す。ラダー言語は、ラダー図の一例を表す図２に示すようにリレー論理電気回路図を模倣するグラフィカル言語である。ラダーロジックは、実際には、ルールベース言語である。「ラング」とも称されるルールは、一組のデータにおける条件によってアクティベートされるとインスタンス化される。一組は、上記アクティベーションに従って選択され、それらのルールに属するステートメントが実行される。リレー等の電気機械デバイスで実装される場合、プログラムを構成する様々なルールは、ソフトウェアの一部として連続ループにおいて逐次実行される。１秒につき多数回ループを実行することにより、同時且つ即時の実行の効果を達成することができる。ラングは、プログラマブルコントローラの適切な動作を達成するために所与の順序で実行される。より詳細には、ラダープログラムは、連続的に、例えば１００ミリ秒毎に実行される１つのループを含むことができる。

ラング入力は、「接点」とも称される論理チェッカである。いわゆる「接点」は、一体化された又は外部の入力モジュールを介する、押しボタン及びリミットスイッチ等の物理的デバイスからプログラマブルコントローラへの物理的又はハード入力を指すことができる。接点はまた、プログラムの別の場所で生成される可能性がある内部記憶ビットのステータスも表すことができる。

ラング出力は、「コイル」によって表されるアクチュエータである。「コイル」は、プログラマブルコントローラに接続された何らかのデバイスを動作させる物理的出力を表すことができ、又は、プログラムの別の場所で使用される内部記憶ビットを表すことができる。各接点又はコイルは、プログラマブルコントローラのメモリにおける単一ビットのステータスに対応する。これらの命令は、メモリにおける特定のビットアドレスのオン／オフステータスを検査し、内部出力及び外部出力の状態を制御する能力を提供する。電気機械リレーとは異なり、ラダープログラムは、単一ビットのステータスを任意の回数参照することができ、無限に多数の接点を有するリレーと等価である。

ラダー図では、ラングは、接続された命令のネットワークとして構成される。命令の間の接続は、上記命令の間の論理関係を表す。例えば、ラダーロジックにおいてＯＲロジックは２つの接点の並列接続で実装され、ＡＮＤロジックはラダーロジックで接点の直列接続として実装される。

第１のステップで動作する翻訳（ＴＲＡＮＳ）は、翻訳アルゴリズムを実施することによって実行される。翻訳アルゴリズムは、ラダープリミティブの事前定義されたモデル化を用いて、ラダープログラム（ＰＲＯＧ）を、論理フレームワークで表されるモデル（ＭＯＤ）に翻訳する。ラダープリミティブは、接点によって表される論理チェッカ、コイルによって表されるアクチュエータ、機能ブロック、及びより一般的には任意の基本又は拡張ラダー言語命令等、ラダー論理回路を構成する論理命令要素からなる。

モデル（ＭＯＤ）は、好ましくは、一階述語論理の論理フレームワークで表される。一階述語論理は、命題論理の拡張であり、領域と称される世界の部分的な視野において命題が真であるか又は偽であるかを考慮する。一階述語論理は、アルファベット、一階述語言語、一組の公理及び一組の推論規則からなる。一階述語論理は数学的に証明可能であり得るため、計算問題を表現するのに有用である。一階述語論理は、構文論及び意味論から構成されている。一階述語論理の構文論は、概念を表すために用いられる形式言語であり、一階述語論理の意味論は、任意の一階述語論理式の値を決定する論理式である。

ラダープログラムのシーケンス構造を考慮すると、翻訳は、ループ自体に含まれる命令に対してのみ動作する。したがって、プログラムがループの連続的な実行を含まないため、時相論理でのプログラムモデルの表現は不要である。翻訳の第１のステップ中、代数的データ型を用いて、プログラムの入力、内部メモリ及び出力がモデル化される一方、多相型を用いて、モデルプリミティブの数が因数分解される。

命令のモデル化は、述語を表現するように一階述語論理式として命令を表すことである。述語は、基本的に、非二値変数の二値関数である。実行時における入力及びローカルメモリの認可された値は、こうした述語から得ることができる。命令モデル化は、実行時の入力及びローカルメモリの認可された値、すなわち、命令が実行されるときにエラーを発生させない値を表す、一階述語論理式として表現されるプロパティに関連付けることができる。これらの論理式は、命令及び論理式が参照するエラー理由のような更なる情報にリンクさせることができる。

ラダーモデルは、上記述語を含む数学的記述を用いて生成される。言い換えれば、ラダープログラムの目的は、選択された数理論理学における一組の述語を用いて表される。こうした数学的記述の検証により、プログラムの計算手法が正確であることが確実になる。こうした数学的記述の検証により、計算手法が、計算することが期待されることを実行する理由が明らかとなる。こうした検証は、証明とも称され、数学的記述に関連するプログラムの実行の安全性及び健全性を確実にする。プログラム実行中に、ランタイムエラー（メモリへの不正アクセス若しくはオーバーフロー、０によって除算しようとする試みのような不正操作、又は、ループの連続的な実行を含む他のタイプのプログラムの場合は、無限ループのような終了問題等）がないことが証明された場合に、実行の安全性が確実になる。プログラム健全性は、機能正確性とも称され、プログラムが行うように想定されることを行うことを検証することである。

形式論理では、論理システムは、システムにおいて証明することができる全ての論理式が、システムの意味論に関して論理的に妥当である場合にのみ、健全性を有する。言い換えれば、システムは、その定理の全てがトートロジーであるとき、健全である。演繹的システムの健全性は、その演繹的システムにおいて証明可能である任意の文（sentence）が、意味論的理論の、その理論が基づく言語に対する全ての解釈又は構造において真でもあるという特性である。

好ましい実施形態では、第１のステップは第１の中間ステップ（ＡＳＴ－ＴＲＡＮＳ）を含み、そこでは、ラダープログラムは最初に、ＡＳＴ表現又は構文木としても知られ、以降、頭字語ＡＳＴと称する抽象構文木として表現される。次いで、第２の中間ステップ（ＭＯＤ－ＴＲＡＮＳ）において、ラダープログラムのＡＳＴ表現からラダーモデルが生成される。

抽象構文木は、プログラミング言語で書かれるソースコードの抽象構文構造の木表現である。木の各ノードは、本実施形態ではラダープログラムである、ソースコードで発生する構成体を示す。

ＡＳＴは、それが含有する全ての要素に対するプロパティ及びアノテーション等の情報により編集及び強化することができる。こうした編集及びアノテーションは、ラダープログラムのソースコードでは、ソースコードを変更することを意味するため、不可能である。

ラダープログラムと比較すると、そのＡＳＴは、実際の構文に現れる全ての詳細は含まず、波括弧、セミコロン又は丸括弧等、構造的且つ内容に関連する詳細のみを含む。ｉｆ条件ｔｈｅｎ表現のような構文構成体は、３つの分岐とともに単一のノードを用いて示すことができる。

ＡＳＴは、通常、コンパイラによる連続的な分析段階に起因して、プログラムに関する追加の情報を含む。ラダープログラムをＡＳＴで表現することは、本方法の続くステップにおいて有用である、ラダープログラムにおける各要素の位置を記憶することを可能にするため、有利である。この中間ステップはまた、ＡＳＴの完全なトラバーサルにより概してプログラムの正確性の検証が可能であるため、興味深い。

本実施形態では、上記ＡＳＴ表現は、好ましくは、ＯＣＡＭＬ等の関数型言語で記述される。

好ましい実施形態では、翻訳アルゴリズムは第３の中間ステップを含み、そこでは、静的単一代入変換（ＳＳＡＴ）を用いて、プログラムの実行中に内部メモリ値が追跡される。ラダー言語等の命令型プログラミング言語では、代入により、変数は、それらの寿命及びスコープの間の異なる時点で異なる値を保持することができる。静的単一代入変換は、各実行段階において代入される値を追跡するために有利である。命令型言語で書かれたプログラムに対して演繹的検証を実施するために、関数型モデルへの変換が必要であり、それは、静的単一代入変換により、モデルに対して、より詳細にはＡＳＴ表現に対して実施される。静的単一代入変換は、モデル要素をラダープログラム要素に連結するために、モデル要素に、コード位置のような情報を追加するのを可能にする、連結ステップとして見ることができる。したがって、元のラダープログラム（ＰＲＯＧ）まで遡ることを、容易に実施することができる。図３ｂは、こうした静的単一代入変換の一例を提供し、そこでは、モデル実行の異なるステップにおける整数Ｄ１の値は、（ｄ１＿１，ｄ１＿２，ｄ１＿３）の値として記憶される。この変換に相当するものが、図３ａのラダー図に表現されている。

本方法の第２のステップ（ＰｒｅｄＴ）は、ラダープログラムモデル（ＭＯＤ）からプロパティ（Ｐｒｏｐ）を生成することである。第２のステップは、モデル（ＭＯＤ）を事前定義された言語形式化（ＬＦｏｒｍ）と結合して、上記モデル（ＭＯＤ）に関連するプロパティ（Ｐｒｏｐ）を得る。次いで、上記プロパティに対する条件（Ｃｏｎｄ）が得られる。

こうしたプロパティは、モデル実行において実施される動作を表し、各実行段階において検証されるように予期される。それらは、各再帰呼出し時にループ不変条件を検証することに類似している。上記プロパティに対する条件は、２つのカテゴリ、すなわち、事前条件及び事後条件に分類することができる。

事前条件（ＰｒｅＣｏｎｄ）は、プロパティ（Ｐｒｏｐ）に固有であるとともに、その実行の前に検証されるべきであり、そうでなければエラーが発生する可能性がある、基礎をなす前提を示す。より詳細には、ルーチンが呼び出されると、上記ルーチンプロパティに対応する事前条件は、上記ルーチンプロパティが検証されるように満たされると想定される。

例えば、階乗関数プログラムは、変数に対して実施される再帰的計算法を表すループを含む。こうしたループの事前条件は、階乗が計算される変数が、ループの開始時は正の整数でなければならないということである。

事後条件は、事前条件が検証されてルーチンが呼び出されたときに予測される結果を表す。したがって、ルーチンプロパティの事前条件は、プロパティ計算時にルーチンの最後に予測された結果から演繹することができる。ループの場合、事前条件及び事後条件は、特に、ループの連続的な実行を含むプログラムにおいて、密に関連するか又は更には類似し、ループ不変条件を形成する。ループの実行段階において事後条件が満たされる場合、次の段階の事前条件も同様に満たされることが確実になる。

そのために、この第２のステップ（ＰｒｅｄＴ）は、ダイクストラの最弱事前条件（weakest precondition）計算法を用いて、上記プロパティを計算するとともに、モデルプロパティ（Ｐｒｏｐ）に関連する事前条件（ＰｒｅＣｏｎｄ）を決定する。図４は、第２のステップにおいて事前条件を得るために生成及び計算されたプロパティの一例を示す。図４のプロパティは、以下のように読むことができる。すなわち、「Ｘに記憶された値が「オン」／「真」である場合、Ｄ１に記憶された値は、０よりも大きく且つ９９９９よりも小さい」である。

一階述語論理プロパティに対するダイクストラの最弱事前条件計算法の実行により、こうした計算が健全でありながら、計算されたプロパティのサイズを最小限にすることが確実になる。事前条件は、各プロパティの定義領域を提供する。このステップにより、事前条件を満たすことが、ルーチンプロパティが持続することと、その実行中にエラーが発生しないこととを意味するため、証明の健全性が確保される。したがって、プロパティが充足される場合、又は言い換えれば、上記プロパティの対偶が充足可能でない場合、対応するラダープログラムを実行するときにエラーは発生する可能性がない。

有利な実施形態では、ユーザ仕様（ＦＵＮＣ）から、他のプロパティが表される。ユーザ仕様は、機能仕様とも称され、プログラムの予測された挙動、すなわち、プログラムが、プログラムユーザによって必要とされるものを満たすように実行するべき機能とともに、入力及び出力の要求されたプロパティを記述する。例えば、工業背景において、ロボットアームは、センサが所与の範囲内の信号を受信しているときにのみ動作するように要求される場合がある。書かれているプログラムは、上記仕様に従うように想定されているが、ユーザ仕様から導出される計算プロパティは、書かれたプログラムが命令エラーを含む可能性があるため、追加の安全措置である。

これらのプロパティは、インターロックプロパティ（ＩｎｔＰｒｏｐ）であり、一階述語論理において機能仕様を表すことによって得られる。上記インターロックプロパティは、満たすべき追加の事後条件としてモデルのプロパティを用いて計算される。したがって、事前条件（ＰｒｅＣｏｎｄ）は、これらのインターロックプロパティから同様に、ダイクストラの最弱事前条件計算法を用いて導出することができる。

第１のステップ及び第２のステップにおいて、上位の論理フレームワークも用いることができるが、一階述語論理は、概して、ラダーモデルから導出されるプロパティ（Ｐｒｏｐ）と対応する機能仕様（ＩｎｔＰｒｏｐ）とを表すのに適している。上位の論理フレームワークは、最終的応用に関する不必要な複雑性を導入する可能性がある。さらに、一階述語論理プロパティの生成は、上位の論理フレームワークと比較して自動化がより容易である。

機能仕様から導出されるプロパティの計算により、モデルのプロパティが充足されるとき、実行時に、機能仕様の違反から導出されるエラーが発生しないことが確実になる。

第２のステップは、述語変換としても知られ、好ましくは、入力としてラダーモデルを受け取るとともに様々なプログラムの形式的証明を生成する適切なツールを含む、演繹的プログラム検証プラットフォーム（ＰＬＡＴ）において計算される。第１のステップもまた、好ましくは、演繹的プログラム検証プラットフォーム（ＰＬＡＴ）において計算される。命令モデル化は、外部モデル化ツールを通して実施することができ、外部モデル化ツールは、上記演繹的プログラム検証プラットフォームにおいてダウンロードされるとともに、ラダー言語の事前定義されたテンプレート及びモデルを含む、ライブラリとすることができる。有利な実施形態では、上記プラットフォーム（ＰＬＡＴ）は、ＷＨＹ３のタイプであり、ラダーモデル（ＭＯＤ）は、ＷＨＹＭＬのタイプのプログラミング言語で表現される。

本方法の第３のステップ（ＳＭＴ）は、第２のステップにおいて生成されたプロパティを形式的に証明するか、又は、これらのプロパティに対する反例を見つけるために、自動化ソルバーを用いる。上記生成されたプロパティは、それらが常に充足される場合、又は、その対偶が充足可能でない場合、形式的に証明される。上記プロパティ（Ｐｒｏｐ）又はその対偶の充足可能性は、それらの先行定義された事前条件（ＰｒｅＣｏｎｄ）に従って評価される。

好ましい実施形態では、第３のステップは、背景理論付き充足可能性（ＳＭＴ）問題に対して自動定理証明器によって実施され、この自動定理証明器を用いて、多数の組込み論理的理論及びそれらの組合せにおいて一階述語論理式の妥当性（又は、二元的に、充足可能性）を証明することができる。こうしたソルバーは、論理式として一階述語論理において表される決定問題である、背景理論付き充足可能性問題を解くように構成されている。ＳＭＴ問題は、命題変数が別の数学的理論の論理式に置き換えられるＳＡＴ問題である。より具体的には、ＳＭＴ問題は、追加の解釈を含む一階述語論理における論理式である一組のＳＭＴインスタンスとして表される。

第２のステップにおいて先行して用いられた演繹的プログラム検証プラットフォームは、概して、自動ソルバーを同様に含む。したがって、上記自動ソルバーを用いて、第３のステップを同様に計算することができる。用いることができるソルバーの一例は、好ましくは、ＣＶＣ４である。別の例は、Ｚ３及びＡｌｔ－Ｅｒｇｏとすることができる。ソルバーは、証明を実行するとともに反例を提供するように、プラットフォームと適切に相互作用するように構成されなければならない。上記相互作用は、証明又は反例が必要とされるモデル要素の指示を含む。上記プラットフォーム（ＰＬＡＴ）がＷＨＹ３である好ましい実施形態では、証明又は反例が必要とされるモデル要素は、図３ｂにおいて「model-trace」というラベルで見ることができるように、ＷＨＹＭＬ言語において特定の関数によってラベル付けすることができる。

解は、背景理論に関して発見的に実施され、ＳＭＴインスタンスが充足可能であるか否かを判断することである。第２のステップから得られるプロパティは、少なくとも整数線形算術の理論、好ましくは、レコード、線形実数算術及び文字列の理論に関して解かれる。有利な実施形態では、自動定理証明器は、多相型の一階述語論理に基づき、好ましくは、有理数及び整数の線形算術、配列、タプル、レコード、帰納的データ型、ビットベクトル、文字列、及び未解釈関数シンボルに関する等式（equality over uninterpreted function symbols）等、組込み基礎理論を含む。より好ましい実施形態では、こうした自動定理証明器は、量化記号及びモデル生成能力のためのサポートを更に含む。

第２のステップで得られたプロパティ（Ｐｒｏｐ、ＩｎｔＰｒｏｐ）が、ＳＭＴソルバーを使用することによってその計算時に充足された場合、ＳＭＴソルバーにより、プロパティが充足されているという証明を表す応答（ＰＲＯＯＦ ＯＫ）が生成される。次いで、プログラム（ＰＲＯＧ）の命令が、生成時にエラーをもたらす可能性がないこと、及び／又はユーザによって表された機能仕様（ＦＵＮＣ）が、ラダープログラム（ＰＲＯＧ）の全てのあり得る実行に対して持続することが確実になる。したがって、プログラム（ＰＲＯＧ）の健全性が論証される。

そうでなく、プロパティ（Ｐｒｏｐ、ＩｎｔＰｒｏｐ）の対偶が充足可能である場合、ソルバーによってプロパティに対する反例が提供される。ＳＭＴソルバーにより、上記反例を表す応答（ＰＲＯＯＦ ＮＯＫ）が生成され、それは、上記プロパティが充足されていない場合をもたらすモデル構成に対応する。特に、反例の内容は、形式的証明が事前条件（ＰｒｅＣｏｎｄ）に基づいて評価されるため、少なくとも初期構成を指す。

本方法の第４のステップは、得られたプロパティ反例（ＰＲＯＯＦ ＮＯＫ）をモデル構成に、より詳細には初期モデル構成に翻訳する（ＴＲＡＮＳＢ）。上記モデル構成は、モデル入力及び内部メモリ値を含む。この翻訳は、上記事前定義された言語形式化（ＬＦｏｒｍ）に基づいて実施され、第２のステップにおけるモデル（ＭＯＤ）からのプロパティ生成プロセスの逆のプロセスとして動作する。

得られたプロパティ反例は、初期モデル構成（ＩｎｉＣｏｎｆ）及び中間モデル構成（ＩｎｔＣｏｎｆ）の両方に対応するデータを含み、その理由は、モデル及び演繹的検証プロセスが関数型であるためである。上記初期モデル構成（ＩｎｉＣｏｎｆ）は、ラダーモデル（ＭＯＤ）の実行の開始時に、上記プロパティが充足されない場合をもたらすモデル入力及び内部メモリの初期値を含む。上記中間モデル構成は、ラダーモデル（ＭＯＤ）の実行の開始と、上記プロパティが充足されないモデル位置との間の内部メモリの中間値を含む。

しかしながら、上記反例は、実行中に生成される中間値の全ては含まない。例えば、ラダープログラムの実行中に、ラダープログラム変数Ｘに対して４つの値を代入することができる。したがって、４つの値は、変数Ｘを表す４つの中間変数（Ｘ１、Ｘ２、Ｘ３、Ｘ４）に代入される。得られた反例は、場合によっては、中間変数（Ｘ１、Ｘ２、Ｘ３、Ｘ４）の全てに対応する値を返さない可能性がある。

後に詳述するように、この場合を克服する好ましい方法は、得られた反例から初期構成を選択することと、反例から選択された上記初期構成（ＩｎｉＣｏｎｆ）によりモデルを実行することによって中間変数（Ｘ１、Ｘ２、Ｘ３、Ｘ４）の値を再計算することとである。

第５のステップは、第４のステップにおいて得られたモデルの初期構成から内部メモリの中間値を計算するために、ラダープログラムの実行（ＥＸＥ）をシミュレートすることである。

好ましい実施形態では、第５のステップは、第４のステップで得られたモデル初期構成（ＩｎｉＣｏｎｆ）を、好ましくはＯＣＡＭＬ言語で表されるＡＳＴ表現の対応する初期構成（ＡＳＴ－ＩｎｉＣｏｎｆ）に翻訳することである、第１の中間ステップ（ＡＳＴ－ＴＲＡＮＳＢ）を含む。こうした翻訳は、第１のステップで動作したようなＡＳＴ表現のモデルへの翻訳から導出することができる。

第５のステップは、ＡＳＴ表現内部メモリ（ＡＳＴ－ＩｎｔＣｏｎｆ）の中間値を回収及び記録するために、上記対応する初期構成（ＡＳＴ－ＩｎｉＣｏｎｆ）を用いて、シンボリック実行エンジン（Symbolic Execution Engine）によってＡＳＴ表現を計算することである。ＡＳＴ表現実行は、ラダープログラム実行のシミュレーションとして動作する、第２の中間ステップ（ＡＳＴ－ＳｙＥｘ）を含む。中間値の収集は、エラー又は仕様違反が発生する実行の箇所まで実施される。第５のステップは、上記演繹的プログラム検証プラットフォームにおいて同様に実施することができる。

結果として、ＡＳＴ表現は、ラダープログラムの実行によって得ることができない中間値の生成を可能にするため、有利である。中間値を得ることができない１つの理由は、ラダーモデルでは、命令を接続する論理ゲートが変数として表現されないということである。したがって、こうしたコード位置において発生するエラーは、返される反例において明確とはならない。第１のステップにおける翻訳時、これらのコード位置における値は失われ、第３のステップ時に提供される反例値から回収されない。しかしながら、これらのコード位置における値は、エラーをもたらしたものの適切な解釈のために必須である。第５のステップは、静的単一代入が適用されたＡＳＴ表現の実行により、これらのコード位置における値の回収も可能にする。

この第５のステップは、モデルエラーシナリオを提供し、これを通して、エラー又は仕様違反をもたらす値が収集される。モデルエラーシナリオは、ＡＳＴ表現構成（ＡＳＴ－ＩｎｉＣｏｎｆ、ＡＳＴ－ＩｎｔＣｏｎｆ）に基づく。

第６のステップは、モデルエラーシナリオをラダープログラムに戻すように翻訳する。ＡＳＴ表現構成（ＡＳＴ－ＩｎｉＣｏｎｆ、ＡＳＴ－ＩｎｔＣｏｎｆ）は、ラダープログラムの対応する構成に戻るように翻訳される。図５はエラーシナリオを示し、エラーシナリオは、二値に対する色と、上記エラーシナリオの整数値に対するラベルとを含む。ラダープログラムは、図５に示すように、グラフィカルに表示され、プログラムにおけるエラー位置、上記エラーの前の、例えば、色強調表示によって示される実行パスと、プログラム実行の開始からエラー又は仕様違反までの入力及び内部メモリの値に関する情報により、拡充されている。エラーシナリオは、第１のステップにおいてモデルに追加されたエラー位置及び理由情報とともに、見つけられたエラーとそれを修正する方法とに関する非常に充実した情報を与える。

本発明の１つの態様によれば、プログラマブルロジックコントローラプログラム分析方法であって、
ラダープログラムであるプログラマブルロジックコントローラプログラムのタイプの元のプログラムを、ラダープリミティブの事前定義されたモデル化を用いて、論理フレームワークのモデルに翻訳するステップと、
少なくとも上記モデルと、事前定義された言語形式化とから、上記元のプログラムの内部変数に関する一組のプロパティを決定するステップと、
自動化ソルバーにより、ユーザ仕様に結合された上記一組のプロパティの充足可能性を検証し、上記一組のプロパティからのプロパティの対偶が充足可能である場合、上記プロパティの対偶が充足可能であるモデル入力及び内部メモリ値を表す一組の反例を提供し、又は、上記一組のプロパティが常に充足される場合、その確認を提供するステップと、
反例を、上記モデルのエラー初期構成に翻訳するステップであって、上記エラー初期構成は入力及び内部メモリの初期値を含む、ステップと、
上記モデルのエラー初期構成（ＩｎｉＣｏｎｆ）を用いて、モデルの実行（ＥＸＥ）のモデルシミュレーションを行い、実行の開始から上記プロパティ違反まで上記モデルシミュレーションのエラー中間構成を記録するステップであって、上記エラー中間構成は内部メモリの中間値を含む、ステップと、
上記モデルのエラー初期構成及び上記モデルシミュレーションのエラー中間構成を、上記元のプログラムのエラー初期構成及び中間構成に翻訳するステップと、
上記エラー初期構成及び中間構成を表示するステップと、
を含む、プログラマブルロジックコントローラプログラム分析方法が開示される。

Claims (9)

1. プログラマブルロジックコントローラプログラム分析方法であって、
   プログラマブルロジックコントローラ（ＰＬＣ）プログラムのタイプの元のプログラム（ＰＲＯＧ）を論理フレームワークのモデル（ＭＯＤ）に翻訳するステップ（ＴＲＡＮＳ）と、
   少なくとも前記モデル（ＭＯＤ）と、事前定義された言語形式化とから、前記元のプログラムの内部変数に関する一組のプロパティ（Ｐｒｏｐ）を決定するステップと、
   自動化ソルバー（ＳＭＴ）により、ユーザ仕様（ＩｎｔＰｒｏｐ）に結合された前記一組のプロパティ（Ｐｒｏｐ）の充足可能性を検証し、前記一組のプロパティ（Ｐｒｏｐ）からのプロパティ（Ｐｒｏｐ）の対偶が充足可能である場合、前記プロパティ（Ｐｒｏｐ）の対偶が充足可能であるモデル入力及び内部メモリ値を表す一組の反例（ＰＲＯＯＦ ＮＯＫ）を提供し、又は、前記一組のプロパティ（Ｐｒｏｐ）が常に充足される場合、その確認（ＰＲＯＯＦ ＯＫ）を提供するステップと、
   反例（ＰＲＯＯＦ ＮＯＫ）を前記モデルのエラー初期構成（ＩｎｉＣｏｎｆ）に翻訳するステップであって、前記エラー初期構成（ＩｎｉＣｏｎｆ）は入力及び内部メモリの初期値を含むステップと、
   前記モデルのエラー初期構成（ＩｎｉＣｏｎｆ）を用いて、前記モデルの実行（ＥＸＥ）のモデルシミュレーションを行い、実行の開始から前記プロパティの違反まで前記モデルシミュレーションのエラー中間構成（ＡＳＴ－ＩｎｔＣｏｎｆ）を記録するステップであって、前記エラー中間構成は内部メモリの中間値を含むステップと、
   前記モデルのエラー初期構成（ＩｎｉＣｏｎｆ）及び前記モデルシミュレーションのエラー中間構成（ＡＳＴ－ＩｎｔＣｏｎｆ）を、前記元のプログラム（ＰＲＯＧ）のエラー初期構成及び中間構成（Ｌａｄ－ＩｎｉＣｏｎｆ、Ｌａｄ－ＩｎｔＣｏｎｆ）に翻訳するステップと、
   前記エラー初期構成及び中間構成（Ｌａｄ－ＩｎｉＣｏｎｆ、Ｌａｄ－ＩｎｔＣｏｎｆ）を表示するステップと
   を含む
   プログラマブルロジックコントローラプログラム分析方法。
2. 前記元のプログラム（ＰＲＯＧ）を前記モデル（ＭＯＤ）に翻訳する前記ステップ（ＴＲＡＮＳ）は、抽象構文木（ＡＳＴ）としての前記元のプログラム（ＰＲＯＧ）の表現の第１の中間ステップ（ＡＳＴ－ＴＲＡＮＳ）と、前記抽象構文木（ＡＳＴ）からの前記モデル（ＭＯＤ）の生成の第２の中間ステップ（ＭＯＤ－ＴＲＡＮＳ）とを含む
   請求項１に記載のプログラマブルロジックコントローラプログラム分析方法。
3. モデル実行をシミュレートする前記ステップは、
   前記エラー初期構成（ＩｎｉＣｏｎｆ）を、前記抽象構文木（ＡＳＴ）に対応するエラー初期構成（ＡＳＴ－ＩｎｉＣｏｎｆ）に翻訳する第１の中間ステップ（ＡＳＴ－ＴＲＡＮＳＢ）と、
   前記対応する初期構成（ＡＳＴ－ＩｎｉＣｏｎｆ）を用いて前記抽象構文木（ＡＳＴ）を計算し、前記抽象構文木（ＡＳＴ）に対応する内部メモリの中間値（ＡＳＴ－ＩｎｔＣｏｎｆ）を回収する第２の中間ステップ（ＡＳＴ－ＳｙＥｘ）と、
   を含む
   請求項２に記載のプログラマブルロジックコントローラプログラム分析方法。
4. 前記モデル（ＭＯＤ）は、一階述語論理フレームワークで表される
   請求項１から請求項３までのいずれか１項に記載のプログラマブルロジックコントローラプログラム分析方法。
5. 前記元のプログラム（ＰＲＯＧ）を前記モデル（ＭＯＤ）に翻訳する前記ステップ（ＴＲＡＮＳ）は、静的単一代入変換（ＳＳＡＴ）の中間ステップを含む
   請求項１から請求項４までのいずれか１項に記載のプログラマブルロジックコントローラプログラム分析方法。
6. 前記一組のプロパティ（Ｐｒｏｐ）を決定する前記ステップの間に、前記一組のプロパティ（Ｐｒｏｐ）は、ダイクストラの最弱事前条件計算法を用いて、前記一組のプロパティ（Ｐｒｏｐ）に対する事前条件（ＰｒｅＣｏｎｄ）を決定するように計算され、前記一組のプロパティ（Ｐｒｏｐ）の検証は、その事前条件（ＰｒｅＣｏｎｄ）に基づいて実施される
   請求項１から請求項５までのいずれか１項に記載のプログラマブルロジックコントローラプログラム分析方法。
7. ユーザ仕様と結合された前記一組のプロパティの充足可能性は、充足可能性モジュロソルバー（ＳＭＴ）を用いて検証される
   請求項１から請求項６までのいずれか１項に記載のプログラマブルロジックコントローラプログラム分析方法。
8. プロセッサによって実行されると、請求項１から請求項７までのいずれか１項に記載の方法を実行する命令を含むコンピュータプログラム。
9. 請求項１から請求項７までのいずれか１項に記載のプログラマブルロジックコントローラプログラム分析方法を実行する装置。

Images