従来型のオートメーションとITの邂逅: パート 2

パート1では、従来のオートメーションとITの目的及びシステムアーキテクチャの主な違いについて説明した。オートメーションには非常に安定した高速予測システムが必要である一方、ITの世界にはより「ソーシャル」、つまり汎用的で適応力の高い通信能力が求められる。パート2では、通信における主な違いについて説明する。

パート 2

フィールドバス vs インターネットプロトコル

PLC (詳細はパート1を参照)は入力をサンプリングして内部状態と組み合わせ、「プロセスイメージ」というスナップショットを生成する。このスナップショットは計算や判断に使用され、全出力の同時状態更新(変更)が行われる。入出力信号は通常、24Vデジタル信号か、0～10V電圧又は4～20 mAの電流ループのようなアナログ信号である。ところが、数百ものセンサ入力がある場合、物理的に1つに1本ずつケーブルをつなぐことは不可能だ。
「バス」は、こうした課題を解決するのに有効だ。わずか数本の配線のみを使用するバスは、PLCと多数のセンサやアクチュエータとの間で情報を順番に伝送する(図1に示すように、これは「パラレル」ではなく「シリアル」の動作である)。センサとアクチュエータは、コントローラと値を交換するための統合通信プロセッサを備えている必要がある。

図1: 従来の配線(上)とフィールドバス配線(下)

いわゆる「フィールドバス」において、予測可能なタイミングでデータ転送を行なうことができることは重要だ。通信における予測性とは、呼び出しから応答までの最大反応時間を正確に把握することだ。この反応時間がどのような値であれ、定格値からの偏差は「ジッター」と呼ばれ、システムの予測性を低下させる。最大ジッターは小さく既知であることが望ましい。
ここに、割り込みを使用して反応時間を短縮することが良くないとされる理由がある。つまり、割り込み処理は不確定要素が生じさせるので、システム全体の確定的特性が失われるのだ。このため、フィールドバスが接続先のコントローラ(PLC)と同じように周期的かつ確定的に動作することが多いのも当然と言える。周期的に動作するシステムは規定のジッターを生成する。複数の非同期周期的システム(PLCとフィールドバスなど)があればジッターが加算されていくことが想像できるだろう。バスサイクルをPLCサイクルと同期させることで、この問題は簡単に解消できる。

図2: オートメーションの反応時間とジッター

「プロトコル」は、デバイスやコンピュータが互いに通信するために制定された通信手順であり、通信の層や動作を決定する。ひとつ大きな問題として、オートメーション業界では長年の間にプロトコルがあまりにも多様化してしまった。機械によって異なる「言語」を使用しているため、その翻訳を担う業界が丸ごとひとつ存在するほどだ。
一例として、従来型のフィールドバスを見てみよう。IEC 61784/EN 50170規格では「分散型周辺機器用プロセスフィールドバス」(Profibus DP)が定義されている。これは、RS485規格だが非常に高速のビットレート(最大12Mbit/秒)の2本の信号線上の差動デジタル信号を使用する。これは厳格なマスタスレーブ群で動作し、プロトコル部DP V0は周期データ伝送を使用する(図3参照)。コントローラ(PLC)をマスタとし、周辺I/O機器はスレーブ機器としてマスタから周期的に届く要求に答えることだけが許可されている。
エンジニアは、接続するI/O機器数とI/O機器の種類をコントローラに伝える必要がある。スタートアップシーケンス(「パラメータ化」と「設定」)ですべてのスレーブ機器がネットワークに「参加」した後で、PLCはすべてのI/O機器を規定のポーリングレート(「要求フレーム」)で周期的にポーリングする。スレーブ(周辺I/O機器)はデータ受信を認識し、各自のI/O状態を即時応答する(「応答フレーム」)。

図3: Profibusでの周期的データ交換

この短い紹介記事を複雑な内容にしたくないので簡単に説明すると、1つのProfibusで複数のマスタを許可するトークンリング通信が可能だ(トークンのあるマスタのみがポーリングを許可され、サイクルを完了したマスタはトークンを次のマスタに渡す)。内蔵安全装置も多数ある。例えば、スレーブが事前定義された時間内にポーリングされなかった場合、スレーブは出力を事前定義された「安全状態」に変更する。スレーブが不具合を検出した場合、アラーム(「診断」)ビットをPLCへの応答内に設定することができ、PLCはその返答としてマスタに次のポーリングで診断データを要求することを許可する。

シリアルバスの「一貫性問題」に対処するための内蔵メソッドもある。パート1では「プロセスイメージ」を紹介した。オートメーションでは入力状態の一貫した凍結スナップショットを取得すること(又は出力を同時に切り替えること)がいかに重要かを説明したが、複数のセンサの入力情報が順番に送信される時に、どうすればこのようなスナップショットを取得できるだろうか？2番目のセンサ値がポーリング要求に応答した時には、最初のセンサ値がすでに変化している可能性がある。Profibusには「フリーズ」コマンドがある。PLCはこのコマンドを同報して、すべてのスレーブは自らがポーリングされるまで入力値をフリーズする。この方法ではPLCが「フリーズフレーム」(テレグラム)を送信した瞬間のスナップショットを取得できる。

バスのビットレートはポーリングレートを制限し、送信エラーの場合には実際のIO状態を反映しないポーリングサイクルが発生する可能性がある。それでも最終的には、このタイプの通信は極めて信頼性が高く確定的だ。Profibusは90年代に導入され、4000万台を超える認証機器が使用されているため、今もオートメーション業界で最も広く使用されている通信プロトコルの1つである。その信頼性は安全技術に最適だ(このトピックについては本シリーズのパート3で取り上げる)。

この周期的マスタスレーブの概念はITエンジニアにとってはやや奇異に映るかもしれない。なぜスイッチポジションを何度も尋ね、なぜスイッチはコントローラに状態が「オン」であることを伝え続けなければならないのか？状態が「オフ」から「オン」に変化した時に1回だけメッセージを送信すればすむのではないか？
これは、イベントベースの通信を使用する場合、確定的システムを構築することは容易ではないからである。

アプリケーションプログラムがデータベースと通信し、それぞれが異なるハードウェアで稼働している場合、多くはクライアント/サーバアーキテクチャとなり、1台のサーバーが多数のクライアントのためにデータを処理する必要がある。根本的な違いがお分かりいただけただろうか？多くのクライアントは通信を開始できなければならず(通信マスタ)、中央サーバーはそのスレーブシステムとして反応する。このような環境では、メッセージにトリガされたダイアログを使用することのほうがはるかに自然である。もちろん、メッセージ・ベースの確定的ネットワーク(トークンリングなど)も検討できるが、全体としての統計学的データスループットは極めて高いため、イーサネットのような確率的ネットワークのほうが有利である。このようなネットワークでは、どの参加者でも通信をいつでも必要な時に開始してメッセージを送信できる。この自由度によって、2つのクライアントが同時に開始した場合に「衝突(コリジョン)」する可能性も生まれるが、高速コリジョン検出・反応戦略があるため、スループットは良好なまま保たれる。最新のネットワークトポロジ(バス型やマッシュ型ではなくスター型)では、同時メッセージをタイムシフトして「デイジーチェーン型」にする強力な「スイッチ」によってコリジョンを防止する。

ITネットワークとそのプロトコルは、Profibusのようなメガビットではなく毎秒ギガビットのデータを伝送できるだけでなく、トポロジーも柔軟だ。このネットワークをインターネットのように世界中に広げることは、技術的には可能である。この柔軟性は、プロトコルを抽象化して「レイヤ」とし、これで「スタック」を構築することで実現されている。OSI参照モデルは7層のレイヤを定義する(図4参照)。例えばProfibusはそのうち3つ(レイヤ1、2、7)のみを定義する。独自のTCP/IPプロトコルのあるインターネットは7層すべてを使用する。

図4: OSIプロトコルレイヤ。例はHTTP

2つのコンピュータ、サーバーとクライアントが同じレイヤを使用して通信する際、そのレイヤより下の層のプロトコル（＝通信手段）は問われない。そのため各階層の通信機能は同じ階層の相手とだけやり取りしているように見えるが、実際はサーバーの第7層から第6層へ、第6層から第5層へ…と下のレイヤを呼び出していき、インターネットなどで送られたパケットがクライアントの第1層で受信され、また第2層、第3層…と経由して第7層と送られている(図5)。これは同レイヤ間の「仮想化通信」とも考えることができる。

図5: プロトコルスタックを使用したレイヤ間通信

ネットワーク層によって、相互接続したパケット交換ネットワークが実現されている。ネットワークノードは各自の判断で、受信したパケットをどのノードに転送して目的の受信者アドレス(IP)に届けるのかを決定することができる。これはインターネットの基礎であり、パケットが送信者IPから受信者IPへ送られる方法を知ることはない、ということを単に表している。

この柔軟性の弱点は「時刻同期性」の喪失だ。通信相手の最大応答時間を正確に予測することができなくなる。TCP/IPベースのネットワークを使用してパケット交換の状態変化について通信しようとすると、コントローラがメッセージを受信するのに数マイクロ秒あるいは数十ミリ秒かかる可能性がある。「TSN」(time sensitive networks)はこの弱点に取り組み、時刻同期性をITネットワークプロトコルに実装することを目指している。

嬉しいことに、産業向けIoT（以下IIoT）には時刻同期性が必要ではない。レイテンシは主要な条件ではないのだ。一方で、産業用機械をインターネットに接続しようとする時には他の制限がある。イベント駆動型の通信プロトコルスタックでは、常にスレッディング又はマルチタスクのオペレーティングシステムが必要である。従来のPLCは一般にこのようなOSを搭載していない。
最新のいわゆる「ソフトPLC」は、LinuxベースのIPC (「インダストリアルPC」 – DINレールに搭載され、キーボード・マウス・モニタを使用しないコンピュータ)上で実行されるアプリケーションだ。このようなシステムは効率的にTCP/IPプロトコルスタックを管理できる。しかしIIoT通信のネットワークと制御ソフトウェアは明確に区別するほうが賢明といえる。
その点で、ゲートウェイはネットワークとソフトウェアの分離に最適な手段である。ゲートウェイはPLCに対する周辺I/O機器のように動作(独自のフィールドバスプロトコルを使用)し、相手側のインターネットに接続するためのネットワークノードである。ゲートウェイでは安全性とセキュリティの両立が問題となるが、これについてはパート3で取り上げる。

次のパート Part 3 Part 4