IEC 61131-3とは？第6回 IEC 61131-3
第3版の内容とJIS B 3503

IEC 61131-3は1993年に初版が発行され、2003年に第2版に改訂、そして2013年に第3版への改訂が行われました。第3版では、異なるPLCベンダ間でのプログラム移植性を高めるためのいくつかの基本データ型、標準ファンクション、標準ファンクションブロックが追加されました。さらにオブジェクト指向拡張や名前空間の導入といったプログラミング言語機能の拡張が行われました。

原則としてこれら第3版における言語拡張は、第2版の言語仕様に対する後方互換性が保たれています。第2版の言語仕様に基づいて記述されたアプリケーション・プログラムは、第3版に対応した実行環境においてもそのまま同じ振る舞いをします。そのため、ユーザは新しい言語要素を知らなくても従来の言語仕様に沿ってプログラミングを行えるようになっています。

第2版から第3版での主な改訂点は次の通りです。

オブジェクト指向拡張として追加された主な言語要素

第3版での特徴的な拡張項目である“オブジェクト指向拡張”に関連して追加された主な言語要素は表1の通りです。

表1 オブジェクト指向拡張として追加された主な言語要素

これらの言語要素とその間の実装（IMPLEMENTS）、継承（EXTENDS）といった関連は、基本的にC++やJavaといった汎用オブジェクト指向プログラミング言語と同様のものと考えて問題ありません。オブジェクト指向設計の経験があるユーザにとっては、オブジェクト指向で行った設計をそのままIEC 61131-3言語で実装できるようになった点がこの言語拡張の利点の1つといえるでしょう。

以前からのIEC 61131-3ユーザ向けには、まずメソッドの利点について紹介したいと思います。ファンクションブロックは、データ（内部変数）と処理ロジック（ボディ）をカプセル化したものではありましたが、処理ロジックとしてボディを1つだけしか持っていないため、基本的に1つの機能しか持つことができませんでした。

これに対し、第3版で追加されたクラスおよび拡張されたファンクションブロックには、その内部変数を共有した複数の処理ロジックをメソッドとして定義することができるため「関連の深いデータとそれを取り扱う複数の機能を1つのPOUとしてカプセル化する」ことができます。そのクラスおよびファンクションブロックに定義された複数のメソッドは、外部から選択的に呼び出すことができます。

従来は「複数のファンクションブロック群を、その間での変数値を引き渡しながら呼び出すこと」で実現していた一連の機能を、メソッド を備えた1つのPOUにまとめてしまうことでアプリケーションの見通しとメンテナンス性を向上させられます。さらに、インタフェースや実装、継承、メソッドのオーバーライドといったオブジェクト指向言語機能をうまく利用することで、さらにメンテナンスや再利用性を向上させることが期待できます。

オブジェクト指向ファンクションブロック

IEC 61131-3 のオブジェクト指向拡張の特徴は、メソッド、インタフェース、実装や継承といった言語拡張が、新たに導入されたPOU種別である“クラス”のみならず、以前からある“ファンクションブロック”に対しても行われている点と言えます。すなわち、ファンクションブロックもクラスと同様に複数のメソッドを持ち、インタフェースを実装し、他のクラスやファンクションブロックを継承することができるようになっています。

このような拡張がなされたファンクションブロックを、従来のファンクションブロックと対比して便宜的に「オブジェクト指向ファンクションブロック」と呼ぶことがありますが、これは従来のファンクションブロックとは異なる種類のPOUが追加されたという意味ではありません。あくまで第2版との互換性を保ちつつクラスの特徴も併せ持つように拡張されたものです。宣言キーワードは第2版までと変わらず “FUNCTION_BLOCK”です。参考に、オブジェクト指向拡張されたファンクションブロックの宣言例を図 1に示します。

ファンクションブロックのオブジェクト指向拡張の意図は、従来スタイルのIEC 61131-3プログラミングとオブジェクト指向プログラミングを1つのアプリケーション内で共存させられるようにするところにあります。つまり、クラスやメソッドなどのオブジェクト指向拡張を利用して内部ロジックを実装したファンクションブロックであっても、従来通りに入力／出力／入出力変数とボディを持たせておけば外部からは第2版までと同じ方法で呼び出して利用できるということです。

第3版のオブジェクト指向拡張は、ユーザやアプリケーションの部分ごとにオプション的に利用できるように考慮されています。裏を返すと、アプリケーション全体を始めからオブジェクト指向で設計するユーザにとってはファンクションブロックを定義する意味は特になく、代わりにクラスだけを用いても問題ないでしょう。

名前空間

名前空間（NAMESPACE）についてもやはり基本的な考え方はC++やJavaといった汎用プログラミング言語と同様です。データ型やPOU定義など“型”の名前を区切り文字ピリオド“.”を用いて階層的に表現した名前空間毎に定義できます。名前空間の利点の1つは、名前空間を設定しておくことでライブラリ機能などを用いて外部からデータ型定義やPOU定義をアプリケーションに取り込んだ際に、それらの名称が不用意に衝突することを防ぐことです。

もう一つの利点は、一連の機能を実現するために必要なデータ型とPOU定義を特定の名前空間下に配置し、その機能を外部から利用する上で直接知る必要のない内部実装に相当するものに対しアクセス限定子 “INTERNAL”を付与して名前空間内に隠蔽することです。これにより、名前空間を“複数のPOUとデータ型定義によって実現される高度な機能を提供するソフトウェアコンポーネント”とできます。このように名前空間はライブラリに格納したソフトウェア部品の構成とメンテナンス性維持のために有効な言語機能といえます。

第3版を取り巻く状況とJIS B 3503への取り組み状況

IEC 61131-3 第3版の新しい言語機能は2014年4月現在、欧州の一部ベンダでしかサポートされておらずユーザでの使用実績はまだ非常に限定的な状況です。国際規格を定めるIECにおいても、“IEC 6113-3を用いたアプリケーション/プログラミング言語実装ガイドライン”である IEC 61131-8 の第3版改訂に着手し、IEC 61131-3 の仕様拡張の曖昧な点の確認やあるべき活用方法について議論を行い始めたばかりという状況です。

国内においては、IEC 61131-3に対応した日本工業規格であるJIS B 3503 への第3版改訂内容の取り込み作業を、PLCopen, NECA, JEMAの合同委員会により2015年中頃の発行を目指して進めています。またPLCopen の技術ワーキンググループにおいても、既存の各種PLCopen標準仕様の第3版への対応と、第3版オブジェクト指向拡張の利用ガイドの作成に向けた研究を進めています。

終わりに

最終回となる今回は、IEC 61131-3の第3版改訂の内容と、それに対するJIS B 3503改訂や標準化団体における取組状況について、ご紹介させていただきました。

第3版の特徴であるオブジェクト指向拡張の利点は、従来のPOU活用だけでは困難であった高度なソフトウェアのテンプレート化／部品化とその再利用を実現できるようになった点にあります。ただ、そういったライブラリを適切に設計するにはオブジェクト指向設計に関する高度な知識が必要になります。オブジェクト指向設計は、マシン制御アプリケーションを開発対象とするユーザの多くにとっては馴染みが薄いため、その習得は難易度が高く感じられることでしょう。

しかしながら、従来スタイルで記述されたアプリケーションの一部だけに、オブジェクト指向拡張を駆使して設計されたソフトウェア部品ライブラリを利用することも可能であり、それにはさほど高度なオブジェクト指向の知識は要求されません。そういった観点から今後、各PLCベンダやPLCopenのような標準化団体、また高度な知識を有するユーザグループなどが、オブジェクト指向拡張を活用したライブラリ群を整備して、利用しやすい形でユーザに提供していくことが期待されています。

この文章は情報ポータルMONOist（アイティメディア株式会社）に掲載された連載記事を再構成・加筆したものです。