産業オートメーションの分野では、ラダー ロジックは依然として最も一般的に使用されるプログラミング言語の 1 つです。ただし、より複雑なコントロール オブジェクトの場合、オブジェクト指向プログラミングは確かに非常に効率的なアプローチです。{0}まずオブジェクト-指向プログラミングについて説明しましょう。
オブジェクト指向プログラミングは、高レベルのコンピュータ言語における高度なプログラミング パラダイムです。-この設計哲学は、産業用制御システムの PLC プログラムにも適用できます。 「継承」などのオブジェクト-指向プログラミング-の優れた機能の多くは実装できません-し、PLC 言語はオブジェクト-指向プログラミング言語の特性さえ持たない可能性がありますが、オブジェクト-指向プログラミングの基本概念はクラスとクラス インスタンス（つまり、オブジェクト）です。これらの概念を活用するだけで済みます。コンピューター プログラミングでは、クラスを定義するために特定のエンティティを抽象化および一般化する必要があります。しかし、産業用制御システムでは、モーターやバルブなどの制御対象は明確に定義された制御カテゴリです。抽象化を必要とせずに、それらのクラスを直接定義できます。次のセクションでは、Siemens の Step7 プログラミング言語と Schneider の Unity プログラミング言語を使用して、PLC のオブジェクト指向プログラミングについて説明します。-
I. 実装方法
ステップ 7 のオブジェクト指向プログラミングは、ファンクション ブロック (FB) を使用して実装されます。-この話題になると、シーメンスが提案したモジュール型プログラミング アプローチを思い浮かべることがよくあります。実際、これは同じ概念ですが、シーメンスが導入した「モジュール化」、「バックグラウンド データ ブロック」、「複数のバックグラウンド」などの用語は、ユーザーがこの優れた設計哲学を明確に理解して適用できるとは限りません。
ただし、オブジェクト指向プログラミングの観点からアプローチすると、この設計パターンをより深く理解できるようになります。{0} 「FB ブロック」は「クラス」とみなされます。これは、同様のコントロール オブジェクトのコードのグループとして見ることができます。たとえば、MM440 可変周波数ドライブの場合、「MtrMM440」という名前の FB ブロックを作成できます。-オブジェクト-指向プログラミングでは、これを「クラス」と呼びます。特定のモーターの制御をプログラムする必要がある場合は、オブジェクト指向プログラミングでバックグラウンド DB ブロックをそのモーターに割り当てることができます。-これはクラスの実装と呼ばれます (つまり、クラスのインスタンス、つまりオブジェクトの作成)。複数のモーターを制御する必要がある場合は、この FB ブロックに異なるバックグラウンド DB を割り当てることができます。これは、クラスの複数のインスタンスを作成するのと同じです。
Step7 は、別のタイプのプログラム ブロック、FC ブロックを特徴としています。主に FC ブロックを使用するプログラミングは、シーメンス システムでは構造化プログラミングと呼ばれます。これは、コンピュータ プログラミングにおける手続き型プログラミング-、つまり純粋に関数ベースのプログラミングに類似しています。-。
Schneider の Unity ソフトウェアを使用してプログラミングすると、オブジェクト指向プログラミングをより深く理解できます。-その DFB 定義には、入出力パラメータ、プライベート/パブリック変数、コード実装が含まれます。-これらはまさにコンピュータ オブジェクト指向プログラミングにおける「クラス」の基本要素です-。クラスのインスタンス (オブジェクト) の作成は、通常の「ブール」変数を作成するのと同じくらい簡単です。 「ファンクションブロック」でこの「クラス」の変数を定義するだけです。
Step7 と Unity はどちらも、手続き型プログラミング アプローチとオブジェクト指向プログラミング アプローチの両方をサポートしています。-これら 2 つのアプローチの違いは、C でのプログラミングと高級コンピューター言語の C++ の違いに似ています。-。
以下の説明では、Step7 の FB と Unity の DFB を「クラス」と呼び、Step7 の FB とバックグラウンド DB の組み合わせ、および Unity の DFB のインスタンスを「オブジェクト」と呼びます。
II.オブジェクト-指向プログラミング アーキテクチャ
上記の説明では実装の詳細について説明していますが、プログラミングの哲学はプログラム アーキテクチャに基づいて構築されています。コードの特定の部分でオブジェクト指向メソッドを使用するだけでは、プログラム全体がオブジェクト指向であることを意味しません-。このタイプのプログラミングには、次の側面に基づいたアプローチが必要です。
1. 構造化された回路設計。
このセクションでは主に自動化された生産ラインに焦点を当てます。スタンドアロン工作機械の場合は、簡素化された構造を使用できます。
<1>自動生産ライン層: これは最高レベルであり、その下のさまざまなゾーンを制御するメイン PLC を備えています。
<2>プロジェクト層: この層には独立した配電システムがありますが、PLC はありません。自動化された生産ラインによって制御される分散モジュールのみで構成されます。名前が示すように、高い独立性を備えており、別のプロジェクトとして設計および製造できます。自動化された生産ラインが比較的小規模な場合、この層は省略される場合があります。
<3>,機能グループレベル: プロセス部門に基づいて、特定のプロセス機能を実行する装置セグメントが機能グループにグループ化されます。このグループはエンジニアリング レベルに属します。エンジニアリングレベルを省略した場合は、自動生産ラインレベルに属します。オブジェクト指向プログラミングでは、必ずしも上記の構造を使用する必要はありませんが、適切に設計された電気的構造はオブジェクト指向プログラミングに適しています。-
2. コントロール オブジェクトのすべてのロジックは「クラス」内に実装されます。
そのためには、制御対象に関する情報を解析する必要があります。たとえば、モーターの場合、次の関連情報を考慮する必要があります。
入力情報:
<1>,モーターのサーキットブレーカーやサーマルリレーなどの回路保護情報。
<2>,モーションモーターのリミットスイッチ、ファンの圧力スイッチ、オイルポンプのオイルレベルスイッチなどの機能保護情報。
<3>開始条件と停止条件: 前述の回路保護と機能保護によりモーターの動作が停止し、リセットによって再起動がトリガーされる場合がありますが、ここで言及する条件は、シーケンシャル制御プロセスのステップなどの通常動作中の開始と停止に関するものです。-
<4>制御モード: 手動および自動など。
<5>フォルト リセット: リセット信号によるシステムの再起動。
出力情報:
<1>モーターを制御するメインコンタクターなどの制御出力。
<2>ステータス情報出力
<3>障害出力
ステータスストレージ情報:
コードの実装に使用される中間変数と、HMI で読み取ることができるステータス変数。上記の情報をすべて 1 つのクラスに統合し、クラス パラメーターを可能な限り標準化します。ただし、高レベルのプログラミング言語と比較すると、まだいくつかの違いがあります。-ステップ 7 では、従うべき標準は次のとおりです。次の構造フレームワークで示されているように、プログラム構造は FC を使用して実装され、オブジェクト制御は FB を使用して実装されます (その電気的構造は上記の紹介に基づいています)。これは単なる大まかな PLC プログラム アーキテクチャです。優れたアーキテクチャは、より包括的で科学的でなければなりません。
3. データ構造を慎重に計画する
データ構造の定義は非常に重要であり、ストレージ容量を気にせずに、これらの構造を可能な限り統一するよう努める必要があります。最新の PLC メモリは、大量のデータを収容するのに十分です。ステップ 7 では、可能な限りクラス外でユーザー定義型 (UDT) を定義しないようにする必要があることに注意してください。-代わりに、クラス内で定義してください。これにより、異なるクラス間で同じ構造の定義が重複する可能性がありますが、クラスの独立性が強化されます。
次のセクションでは、これら 2 つのプログラミング アプローチを比較します。
オブジェクト-指向プログラミングの利点 ラダー ロジックと比較して、オブジェクト-指向プログラミングには次の利点があります。
• コードは移植可能で再利用が簡単です。
• 数学関数、ループ、その他の構造を簡単に使用できます。
• オブジェクト指向プログラミングは、ほぼすべてのコンピュータ プログラミング コースで教えられます。-
• コードはさまざまなハードウェア プラットフォームで実行できます。
オブジェクト指向プログラミングをマスターするには、まずオブジェクトの概念とその使用方法を理解する必要があります。-オブジェクトまたはクラスを作成すると、複数の呼び出しを通じて簡単に再利用できます。たとえば、すべての入力、出力、および障害を処理するモーターを制御するオブジェクトを作成します。必要に応じて、この単一の制御オブジェクトを複数回インスタンス化することで、複数のモーターを制御できます。これはオンデマンドのインスタンス化として知られています。-複数のモーターを制御する必要がある場合、この 1 つのオブジェクトを繰り返し使用できます。必要に応じて呼び出され、使用時にインスタンスが作成されます。
各モーターの各インスタンスには、モーターの停止、モーターの実行、モーターの速度、モーターの過負荷などの独自の特性があります。プログラミング作業のほとんどは、オブジェクトが最初に作成されたときに完了します。これはラダー ロジックとは異なる考え方であり、オブジェクトを一度構築すると、使用および再利用が簡単になるため、より強力です。オブジェクト-指向プログラミングを使用すると、複雑な数学関数、ループ計算、配列、ネストされたサブルーチンを簡単に実行できます。高校、大学、オンライン チュートリアルなど、ほぼすべてのコンピュータ プログラミング コース-でこの概念が教えられています。{6}}作成されたコードは移植性があり、さまざまなハードウェア プラットフォームで実行できます。
「ラダー ロジックは、リレー制御システムで使用される電気ラダー図の形式に従っており、ほとんどの人がすぐに学習して習得できます。」
ただし、ラダー ロジックと比較すると、オブジェクト指向プログラミングには次のような欠点があります。-
• コストが高くなる。
• 急峻な学習曲線。
• 保守担当者にとってトラブルシューティングは特に簡単ではありません。
• 通常、ソース コードをプロセッサにアップロードする前にコンパイルが必要です。
ラダー ロジックと比較して、オブジェクト指向プログラミングでは多くの場合、より多くのメモリとより大きな処理能力が必要となるため、コストが高くなります。{0}}オブジェクト指向プログラミング言語の学習にはさらに時間がかかる場合があります。-おそらく教室での指導が必要であり、中心となる概念を習得するには、かなりの時間、練習、テスト、応用が必要です。プログラマは、トレーサを使用してコードを追跡したり、デバッガを使用してロジックをデバッグしたりするために、オブジェクト指向プログラミングを頻繁に学習する必要があります。-この種の高レベルのプログラミングでは、リアルタイムのオンライン モニタリング機能を実装することが困難になる場合があります。-
ソース コードをコントローラにダウンロードする前に、コンパイルする必要があります。通常、ソース コードはプロセッサのメモリには保存されません。これは、コンパイルされたコードは通常編集できないため、ソース コードのバックアップには注意する必要があることを意味します。オブジェクト-指向プログラミングでは、ライブラリ ファイルをコンパイル プロセス中に使用される他のリソースにリンクする必要があります。リンクとリソースについて理解していなければ、プログラムを実行するのは困難です。
ラダーロジックの利点:
ラダー ロジックはシンプルで自己文書化されたコーディング手法-です-。これがプログラミング言語として適格であるかどうか疑問視する人もいます。これはリレー制御システムで使用されるラダー図の形式に従っており、ほとんどの人がすぐに学習して習得できます。これは、数十年にわたってマシン オートメーションの分野で広く使用されている唯一のプログラミング言語であり、近い将来もオートメーション業界の主要なプログラミング言語の 1 つであり続けるでしょう。
時間が経つにつれて、さまざまな背景や分野の人々が業界に参入するにつれて、さまざまなプログラミング言語が産業オートメーション ツールキットに導入されてきました。これらには、ファンクション ブロック プログラミング、構造化テキスト、状態プログラミング、およびシーケンシャル ファンクション チャートが含まれます。これら 4 つのプログラミング言語は、ラダー ロジックとともに、国際電気標準会議 (IEC) 規格 IEC 61131-3 によって定義された標準プログラミング言語を構成します。
IEC 61131 の背後にあるロジックは、すべてのベンダーがこの規格に準拠していれば、-少なくともある程度は-これら 5 つのプログラミング言語を学習するだけで、さまざまなベンダーが提供するプラットフォームを簡単に切り替えることができるというものです。しかし、そうではありません。
同じことが、基本的なラダー ロジック (リレー接点やコイルの使用など) にも当てはまります。ただし、プログラミングするときは、各ベンダーの構文とユーザー エクスペリエンス、およびプログラミング プラットフォームの使用方法の詳細を学ぶ必要があります。標準化がされていないにもかかわらず、ラダー ロジックにはオブジェクト指向プログラミングに比べて次のような利点があります。-:
• 機械およびプロセスの制御に適しています。-
• 本質的に自己文書化されているため、理解しやすくなります。-
• 制御対象システムのトラブルシューティングが容易になります。
• デバッグが簡単です。
• ソース コードは通常、プロセッサに保存できます。
ラダー ロジックは、機械やプロセスの制御、特に多数の個別の入出力（I/O）を備えた自動化システムに適しています。{0}長年にわたり、ラダー ロジックもアナログ I/O を処理できるように継続的に改良されており、幅広いプロセス制御アプリケーションにより適したものになっています。
マシン制御アプリケーションと比較して、プロセス アプリケーションは通常、アナログ I/O の割合が高くなります。
ラダー ロジックはオブジェクト指向プログラミングよりも使いやすいため、多くの熟練した技術者やエンジニアがすぐに習得できます。{0}ロジックは非常に体系的かつ組織化されており、自己文書化されているため、理解と習得が容易になります。-デバイスがアクティブ化される前に、コードのすべての行が true と評価される必要があります。制御するモーターが 5 つある場合、少なくとも 5 行のコードが必要となり、プロセスが大幅に簡素化されます。
「ラダー ロジックのソース コードと記述子は通常、コントローラー内に保存されるため、ソース コードにアクセスする必要がなくなり、コンパイルされたプログラムを理解しようとするときにプログラマーがよく経験するイライラが解消されます。」
電気エンジニアやメンテナンス担当者にとって、ラダー ロジックは非常に直感的です。ラダー ロジックはオブジェクト指向プログラミングとは異なる考え方を必要としますが、勉強すればすぐに習得でき、他の人が書いたコードを理解するのにそれほど時間はかかりません。-ロジックがいつ真であるか、いつ偽であるかは明らかです。プログラミング経験が限られている人でも、オン/オフ状態、コイル通電、比較変数、一般的な数学関数などの概念を簡単に理解できます。
シンプルで使いやすく、トラブルシューティングとデバッグが合理化されます。ロジックをモニタリングすると、現在の動作状況が容易に把握できます。ソフトウェアの学位や高度なプログラミング スキルは必要ありません。ラダー ロジックを使用すると、メンテナンスおよびエンジニアリング担当者はプロセスを簡単に追跡し、何が起こっているかを理解できます。ラダー ロジックは真理値表として考えることができます。左側のロジックが真の場合、右側のロジックがアクティブになります。
通常、ラダー ロジックのソース コードと記述子はコントローラーに保存されます。これにより、プログラマーがソース コードにアクセスせずにコンパイルされたコードを理解しようとするときによく経験するフラストレーションが解消されます。-これはオブジェクト指向プログラミングでも一般的な問題です-。
ただし、オブジェクト-指向プログラミングと比較すると、ラダー ロジックには次のような欠点もあります。
• コンピュータ プログラマや IT 専門家はラダー ロジックに馴染みがありません。
• 数学関数、テキスト処理、データ処理を実行するのが難しい。
• スキャン時間に依存します。
• 実行にはプログラマブル ロジック コントローラー (PLC) などの特殊なハードウェアが必要です。
ラダー ロジックは、学校で習わないため、コンピューター プログラマーや IT プロフェッショナルにとって馴染みのない記号言語です。ラダー ロジックで数学関数、テキスト文字列、データを処理することは、主にラダー ロジックが元々これらの関数を処理するように設計されていないため、困難になる場合があります。
ラダーロジックはスキャン時間にも依存します。プログラムが大規模になると、ロジックのスキャンと処理により多くの時間が必要になります。ラダー ロジックを実行する場合、システムは入力を読み取り、ロジックをスキャンし、データ テーブルと出力を更新し、通信を実行して、このサイクルを繰り返します。割り込みやその他のプログラミング手法などの機能を実装して、特定のロジックをより高速に実行できます。
ラダー ロジックで構成されたソフトウェア ベースの PLC は PC 上で実行できますが、通常、ハードウェア（PLC など）はプログラミング ソフトウェアと互換性がある必要があり、両方を同じベンダーから購入するのが最善です。{0}}これにより互換性が保証されますが、ベンダーを切り替えたい場合には特に便利ではありません。
ユーザーは、ラダー ロジックとオブジェクト指向プログラミングの長所と短所を比較するだけでなく、これらのプログラミング言語がデプロイされる環境でどのように使用されるかを評価する必要もあります。{0}}工場や施設がすでにラダー ロジックで標準化している場合、たとえ後者の方がアプリケーションに適しているとしても、それをオブジェクト指向プログラミングに置き換えることは推奨されません。-オブジェクト-の使用が拡大し続けるにつれて、今後数十年間はラダー ロジックと共存することが予想されます。先進的な-自動化の専門家は、両方の言語をマスターすることをお勧めします。-