見出し画像

PLCでのOOP(オブジェクト指向プログラミング)について

ソフトウェア開発では当たり前のように用いられるOOP(オブジェクト指向プログラミング)。しかし、自動化設備の制御プログラムでは、ほとんど浸透していません。この記事では、PLCプログラムでのOOPについて考察します。


■ OOPについて

まずOOPについて簡単に触れます。

OOPは「Object-Oriented Programming」の略であり、日本語では「オブジェクト指向プログラミング」と呼ばれています。

OOPとは、「オブジェクト(物)」 を中心にしてプログラムを構築する考え方です。プログラムを複雑な手続きの集まりとしてではなく、現実世界のように「データ」と「そのデータを操作する機能」をひとまとめにしたオブジェクトとして設計します。

また、OOPの基本概念として、
 1.カプセル化
 2.継承
 3.ポリモーフィズム
がありますが、ここでは説明を割愛します。

OOP自体の歴史は非常に古いのですが、実際のアプリケーションに多く使われるようになったのは、Javaが流行った1990年代です。この頃にOOPは一般的なプログラミング手法として定着しました。そして2000年以降、C#やPythonにも取り入られるようになり、今では当たり前のようにOOPでアプリケーションが実装されています。

■ PLCプログラムの状況

では、自動化設備を制御するPLCプログラムはどうでしょうか。

PLCプログラムは古くから現在に至るまで、ラダー言語が多く使われています。よって、PLCプログラムはOOPと縁の遠いものでした。
因みにラダー言語で実装できる手法は構造化プログラミングまでです。たまに「ラダー言語でもOOPのようなことはできる」と言う人を見かけますが、ラダー言語でOOPはできません。おそらく構造化プログラミングとOOPがごっちゃになっているのだと思います。
あらためて言いますが、「ラダー言語でOOP」は、言語仕様的に不可能です。

しかしここ最近、ソフトウェアPLCが少しずつ注目を集めています。ソフトウェアPLCではCODESYSが有名ですね。こちらは IEC61131-3 の第三版 に完全に準拠しており、ST言語を選択することでPLCでもOOPの実装が可能になっています。
因みに、従来のレガシーなハードウェアPLC(三菱電機やオムロン、キーエンスのPLC)でもST言語の使用は可能ですが、クラスベースの実装は無理だったと記憶しています。OOPによる実装はできません。

下図は、IEC61131-3の第三版に完全準拠したST言語と、OOPに対応した他の言語との仕様比較です。これを見ると、ソフトウェアPLCでST言語を選択すると、OOPによる実装が可能だということが分かります。

各言語のOOP対応


■ PLCプログラムにOOPは効果的か

では次に、「PLCプログラムをOOPで実装するのは効果的か」について考えてみます。

OOPの特長として、
 1.モジュール化と再利用性
 2.スケーラブルな設計
 3.可読性と保守性の向上
 4.エラー対策とデバッグ作業の効率性アップ
などがあげられます。

これを見るとPLCプログラムでもOOPは有効そうです。しかし、実際にはOOPでの実装が難しい面もあります。具体的には、以下について注意する必要があります。

  • リアルタイム性の低下
    OOPは柔軟性と再利用性を重視しますが、オブジェクト間の依存関係が増えるとそのトレードオフとして、制御システムのリアルタイム性が損なわれる可能性があります。

  • スキャンプログラムでの実装の難しさ
    PLCはスキャンプログラムです。このスキャンプログラムを考慮するが故に、独特の実装になってしまい、逆に読みづらくなってしまう恐れがあります。実装するには一工夫要りそうです。

これら以外にも、そもそもOOPを適用しづらい場面があります。
それは、一品一様の装置です。

一品一様の装置の場合、OOPを使える箇所はせいぜい「モーターやアクチュエータ、バルブの制御」程度になることが多く、適用箇所が少ないがゆえにOOPのメリットを感じづらくなります。
まぁそれでも「クラス化することで再利用性が高まり、同じような機構が追加された場合であってもコードの修正が最小限で済む」というメリットはありますが。

しかし、上記メリットよりも以下のようなデメリットのほうが大きくなる可能性があります。
 ↓
「一品一様の装置の場合、装置毎に異なるプログラムが求められるため、OOPのような抽象化アプローチは過剰設計になってしまう」


■ OOPが本領発揮する場面

私の経験上、自動化設備のプログラムで、OOPによる実装のメリットを1番強く感じたのは シリーズ物の標準機モジュール化設計された装置 です。

モジュール毎のフレームワークをオブジェクト化すると、現物の機械(モジュールAやモジュールB)にリンクする形で、プログラムも綺麗に分離できるようになります。以前作った装置で、機械・電装・ソフトがモジュール毎に綺麗に分離できるように設計したことがありますが、プログラムの改造の容易さや可読性、メンテ性において非常に優れたものになりました。

このような設計思想を実現できるのが、自動化設備におけるOOPのメリットだと思います。


■ OOPの習得

最後に、OOPの習得について記述します。

OOPの最大の難関は「上手に実装する」ことだと私は思います。

いくら座学で学んだとしても、いざ実装となると上手く実装できないケースがほとんどです。初心者の場合、どの機能をどう切り取ってオブジェクトとして見立てれば良いかの判断が不慣れであり、いざ実装してみると、
「何故こんなところでオブジェクト化するんだ!?」
とか、
「いやいや、この部分はオブジェクト化しろよ」
という実装になりがちです。

過剰なオブジェクト化設計になったり、クラスのインターフェース仕様がむちゃくちゃで、OOPの汎用性やスケーラビリティを失ったプログラムになりがちです。

過去の私もそうでした。(今も大したことはありませんが…)

OOPを上手く使いこなせるようになるには、経験を積むしかないと思います。実装する毎に「今回の実装は使いづらかったな。次回はこの部分をこう改善しよう」という試行錯誤を繰り返していくしかないと思います。

OOPの勘所を経験で掴み取ることが大事だと思います。


いいなと思ったら応援しよう!