切屑堂 kirikuzudo

昨日、クラウドPLCという文字列を目にしていろいろ考えてたので、それを書いておきます。 まず、クラウドPLCの成立形態としては2つ考えられるのではないかと思っています。 ひとつはPLCの実体がAWSやAzureみたいなところのRT拡張Linuxインスタンスにある形態です。本記事ではこちらをリアルクラウドPLCと呼びたいと思います。 もうひとつはPLCの実体は制御対象と同じサイトにありながらもエンジニアリングツールと密結合したコンフィギュレーションコンテナがAWSやAzureみたいなところにあり、実体とコンフィグコンテナがある程度の遅延で同期する形態です。本記事ではこちらはコンフィグベースクラウドPLCと呼びたいと思います。 前者のリアルクラウドPLCは制御対象の時定数が大きい空調や非反応系プラントなどの制御では有望ではないかと思います。 配管機器やプラント向け伝送器はIPノード化するのが比較的容易ですし、無線化はここ5年のトレンドでもあったりします。 そのため、サイト内にIPネットワークを整備してAWSやAzureとセキュアに接続することができれば、PLCの実体がAWSやAzureにあるRT拡張Linuxインスタンスであっても十分に成立すると考えます。 後者のコンフィグベースクラウドPLCは高速な制御周期を要求されるPLCに適用することを考えた形態です。 三菱電機のMELSEC iQ-R や キーエンスのKV-7000 などは単体でのスキャンタイムが 0.1～0.5[msec]程度で動作しますが、IPsecやTLSでの暗号化を施しインターネット回線でのルーティングを経てAWSやAzureにあるLinuxインスタンスと行う通信では、このスキャンタイムと同等のRTTを「常に保証」することは今後も困難だと考えます。 AWSやAzureと直接回線を用意するAWS Direct ConnectやAzure ExpressRouteを利用すれば低遅延を実現することは可能ですが、サイト内のEthernetにおけるスイッチング遅延にも気をつかわなければいけませんし、PLCをクラウド化することによるメリットに対して足まわりであるネットワークにかける投資はかなりのものになると考えられます。 ここでクラウドにPLCがあるメリットに立ち返ってみたいと思います。 まず考えられるのは形態管理が容易になることです。現場では最新の設定をUSBフラッシュメモリに保存して制御盤に図面といっしょに保管したりすることがありますが、そもそも実体がクラウド上にあればそういったことを考える必要はありません。 これに付随して制御盤から信号配線をなくすことができるかもしれません。スイッチやセンサや伝送器自体がIPv6ノードとなっていて直接クラウド上のLinuxインスタンスとやりとりできれば信号配線を制御盤にまわす必要はなくなります。かわりにサイト内のEthernetにぶらさがったスイッチングハブ（M12コネクタのIP67なやつ）につないだりする必要はあるかもしれませんが。 アクチュエータやモーターでは、電力の配線や油空圧の配管がなくなることはないかもしれませんが、動作のための信号をIP化することは可能でしょう。保護協調をクラウドから管理できれば電力配線のバス化なども夢ではないかもしれません。（現状ではちょっと費用を考えるときついかもしれませんが、遮断器や接触器をIP化するメリットは主にメンテナンス面から十分あると考えています） こういったことが実現すれば、制御盤や制御配線などの自由度が飛躍的に高まりますので、設備に固有で必要なハードウェアというのはほぼメカニカルな部分だけになるのではないかと思います。素晴らしいですね。 そして、これらのメリットと高速な制御周期を満たすための投資とのトレードオフをしたときに考えられるのがコンフィグベースクラウドPLCです。 形態管理が容易なままで自由度が得られる、というのがクラウドPLCのメリットであるのなら、「制御の生情報をクラウド上に送ることはクラウドPLCのメリットに通じる本質ではない」と考えます。 制御の生情報をクラウドに送らないのであれば高価なクラウドとの直接回線やその接続点までの低遅延なサイト内Ethernetなどは不要となります。 現状でもEthernetベースのモーションコントローラ＝サーボアンプ接続などはありますので、サイト内でも限られた範囲であれば、制御の生情報をIPノード化したセンサ・伝送器・アクチュエータ・モーターの間のみでやりとりすることはコスト面からも制御周期からも十分に現実的です。 この形態のデメリットは低遅延を保証できる範囲のEthernetにRT拡張Linuxインスタンスがいないといけない、ということでしょうか。ここだけはどうしてもオンプレミスになり自由度が減ります。 とはいえ、この現場インスタンスがコンテナベースでクラウド上にある休止インスタンスとミラーされていれば形態管理上の問題もなくなりますし、Ethernet上の遅延が許される限りで現場から離して設置することも可能です。 例としては不適切かもしれませんが、VoIPにおけるSIPとRTPの役割分担をイメージしてもらうのもいいかもしれません。呼制御はSIPを用いてサーバで行い、実音声情報は端末間を直接RTPでやりとりするというのはコンフィグと実制御情報の関係に似ている気がします。 というわけで、ここまでクラウドPLCというものの形態を考えてきたわけですが、コンフィグベースクラウドPLCにしろリアルクラウドPLCにしろ、これらのエンジニアリングツールはクラウド上にありますので、制御プログラムを作成するにはこのクラウド上のエンジニアリングツールにアクセスする必要があります。 そして、クラウド上のエンジニアリングツールはおそらくサブスクリプション契約でPLCインスタンスに付属するものとなるため、設備そしてPLCインスタンスを保有する企業がこのエンジニアリングツールに対するロールを適切に企業外の作業者に割り当てる必要があります。 これはエンジニアリングツールを保有してPLCプログラムを提供することを付加価値として制御盤を製造していた制御盤業に対してけっこうなインパクトを持つ変化なのではないかと思います。そう簡単にはコモディティ化しないと思われているパッケージ提供能力の、そのパッケージ自体が失われるのですから。 （筆者もそういった立場に片足をつっこんでいるので、記事を書きながらけっこうな危機感があります。） この先生きのこるには、こういった変化を想定しつつ、現状で求められるものとこの先求められるもののバランスを取っていかないといけないのでしょう。 あるいはいまのうちに自らがプラットフォーマーにいっちょ噛みするというのも手かもしれません。他所の国はともかく、本邦でクラウドPLCはまだ端緒についたばかりの概念ですので。