*本原稿は、4月2日の「MONOist」で 掲載された記事「IIoTの課題解決ワンツースリー(2)」を一部加工し、転載しています。

IIoT(産業用IoT)活用を上手に行うためには何が課題となり、どういうことが必要になるのか。今回は、IIoTソフトウェアプラットフォームの役割を果たすSCADAの特徴について紹介する。

SCADA導入に後れを取る日本

以前の「IIoT特集」でも紹介した通り、日本の製造業ではSCADA(Supervisory Control and Data Acquisition)システムの導入が極端に少ないという課題がある。SCADAシステムを全く導入していないか、MES(Manufacturing Execution System)とPLC(Programmable Logic Controller)を直接接続する製造ラインを国内ではよく目にする。

国内の生産技術部の方々と話していても、SCADAに対する認識が極めて低いことに驚く。SCADAという言葉を聞いたことのない人もいれば、いまだに「SCADA=表示系」と認識している人も多い。実はSCADAは8年ほど前から「SCADA=IIoTソフトウェアプラットフォーム」へと位置付けを大きく変えようとしているのだが、そういう認識は日本ではほぼないといえるだろう。

SCADAの機能の変化

SCADAの歴史は長く、30年以上前から工場内の全体を見渡す「表示器」として製造ラインのさまざまなデータを集約して表示してきた。その頃のSCADAは、異なるメーカーのPLCを接続し、データスループットを向上させ、表示器の見栄えの洗練さと表示速度を向上させ、データの前処理(クレンジング)を行い、レポート生成を容易にするといった範囲の役割を担っていた。

しかし、8年ほど前からSCADAはIIoTソフトウェアプラットフォームとしての明確な役割を担うようになってきている。これらの表示機のような機能に加えて、タブレット表示(HTML5対応)、アラーム解析、レシピ管理、バッチプロセス制御、監査証跡(履歴管理)、データインテグリティといった機能が追加されてきている。

これらのIIoTソフトウェアプラットフォームとして求められるSCADAの新たな機能群を、具体的な事例を含めて紹介する。

タブレット表示(HTML5)

欧州の工場では自動車の1つの製造ラインに50以上のタブレット端末が設置されているケースも珍しくはない。エラーが発生した瞬間に「どんなエラーが発生しているか」「誰がそこに向かって復旧すべきか」「復旧のためにどんなツールを持参すべきか」「復旧方法のマニュアル表示」「製造ラインの開発担当者に直接問い合わせるための内線番号の表示」などが一斉に表示される。工場内に設置されていたり、各作業員が保有しているタブレット端末を通じて表示されたりして、 例えば 50人の作業員全員に必要な情報が同時に知らせることができるようになる。

復旧した際にも、単に復旧させるのではなく「誰がいつどのように復旧させたのか」といった情報が自動的にログとして記録される。この情報は後に同じエラーが発生した際には 根本的な解決に向けて改善するための判断材料に用いられたり、原因の解析に利用されたりすることになる。


内線番号を表示する画面イメージ(出典:リンクス )

アラーム解析

まずアラームとはどんなことを意味するのだろうか。例えば、治具に部品を設置して蓋を閉じてスタートボタンを押す工程があるとする。その際に、納品される部品の寸法が変動したために蓋がなかなか閉まらず、スタートボタンを押しても動作しない場合がある。現場の作業員は何とか製造ノルマを果たすために、蓋を強引に押し込んでスタートさせるのだが、その度にそれは異常行動であるためにアラームが発生することになる。

こういったアラームは、大小含めて多くのところで発生しており、これが積もり積もって製造の生産性を落としている可能性がある。その場合には「このXX週間の発生頻度の最も高いアラームをYY件表示」といった形で統計を取り、改善部門としてどこにリソースを割いて改善投資をするか判断することになる。その統計結果を示しているのが以下の図である

トップアラーム表示(出典:リンクス)

また、タイミングがクリティカルなアラーム解析においては、アラーム発生のタイミングを実時間のタイムスタンプと共に取得する必要がある。シーメンス製のPLCなどでは標準でアラーム情報にタイムスタンプを組み合わせてSCADAに渡してくれるものもある。もし備わっていない場合は、PLCに工夫をすることでタイムスタンプと共にアラーム情報を取得することができるようになる。タイムスタンプ付きでアラーム情報が上がってくると、センサーやアクチュエータの状態データとアラームを時間軸上で整列させることができる。

PLCから値と併せてタイムスタンプ情報を収集(出典:リンクス)

センサー、アクチュエータ、アラームといったデータ全てが時間軸上で整列されるとさまざまな「見えるもの」が生まれてくる。これらのログを解析していくことになるが、その解析においても、視覚的に解析を行うツールも準備されている。

アラームが発生した履歴を選び時間軸を動かすことで、その瞬間のセンサーやアクチュエータの状態を表示し、バルブが開閉されている様子が見られる。そうすると、「アラームが発生した直前に、バルブ1番が変な動きをしている」といった様子を見つけ出すことができるようになる。

レシピ管理

エッジコンピューティングなどの傾向が強まる一方で、PLC内部に全ての製造パラメータを保存したくないという考え方なども広がってきている。当然工場ごとや企業ごと、業界ごとによって異なるが、製薬や飲料の分野では製造情報を保護したい考えである。例えば「タンクの温度をどこまで上げる」といった情報は機密にあたるもので「製造ラインの設備メーカーに知られたくない」と考える企業もいる。また勝手に誰かに改変されないように権限設定ができ、正しく履歴が残るIIoTソフトウェアプラットフォームで保管するという考えもある。

IIoTソフトウェアプラットフォームには監査証跡の機能が備わっているので、そもそも製造パラメータを変更するには一定の権限が必要である。また、変更した場合には、全ての変更履歴が改ざん不可能な形で残る仕組みになっている。

バッチプロセス制御

先述したレシピ管理とコンセプトは同じだが、製造プロセスまでIIoTソフトウェアプラットフォームで管理するという考えが「バッチプロセス制御」である。主に製薬や飲料メーカーなどが活用する。これにより、設備メーカーに重要な製造プロセスを公開することなく、製造プロセスを変更できる他、これらの変更は全て履歴管理される。

製造プロセスとは、つまり条件分岐を意味するが「温度がXX度になったらYY時間かき混ぜ、その後にバルブを開けてZZリットル液体を追加する」といったシナリオで考えてみよう。XXやYYやZZだけを変更するのは製造パラメータの変更であり、製造プロセス(条件分岐)の変更ではない。これに対して「温度がXX度になるまでYY時間かき混ぜ、TT時間後に排水バルブを開けてタンクを空にする」といった製造プロセス(条件分岐)までもPLCのプログラムを変更せずに、IIoTソフトウェアプラットフォームから行うというものがバッチプロセス制御と呼ばれる機能である。

バッチプロセス制御を用いるとPLCはロジック(条件分岐)を持たなくなるので、アクチュエータを駆動するためだけのドライブのような位置付けになる。条件分岐の演算はエッジではなく、イーサネットで接続された上位システムで行われるため、タイミングがクリティカルなアプリケーションには適応できない。しかし、飲料や製薬といった制御周期が比較的遅いアプリケーションにおいては、IIoTソフトウェアプラットフォームから行うバッチプロセス制御の方が圧倒的に管理しやすく、変更履歴も残るため安全性が増す。

さらには、最近ではより厳密に製造プロセスの履歴を残したいという要求がある。たとえ「3時間かきまぜた後に、劇薬を2杯タンクに入れた」という履歴が手書きで残されていたとしても、本当にそれが行われたかは完全に信用できるものではない。そこで、人の作業をシステムに一体化させるという観点で、劇薬を2杯確実にタンクに入れないと、つまりタンクに入れたところで作業員が確認ボタンを押さないと、次の作業に移行できないという仕組みを作ることができる。システムが人間の作業エラーを見守る仕組みを構築することができる。

監査証跡

製薬や飲料の世界では米国FDA(食品医薬品局)をはじめとする規制が厳しさを増しており、これまで工場で働く優秀な作業員によって信頼性を担保させていた日本は岐路に立たされている。

これまでは、優秀な作業員が 紙に手書きで履歴を残すことが安全で確かであるという考え方だったが、電子データで履歴を管理する方が安全で確かであるという考え方にシフトした。ミスや改ざんが発生しうる手書きや手入力(人依存)よりも、システムでデータを自動的に記録し、保存していく(人手を介さない)方が、安全で確かである。

さらには、製造品の品質を確保するために一番理想とされているのは全数検査を行うことだが、タクト時間を考慮するとそれは不可能である。そこで考えられる手段として、パラメトリックリリース(製造工程の重要パラメータが設定された基準範値にあることで、安全性を保証するという考え方)が注目を集めている。

製造物の全数検査をするのではなく、製造プロセスの重要なパラメータを全て連続的に監視、記録することで、製造物の品質を証明するという発想である。例えば、温度を条件とすると、全ての製造物が各工程でどの温度で製造されたかを履歴に残し、それが既定の±5℃以内ということを証明するといった考え方である。この管理にもIIoTソフトウェアプラットフォームが適しているのである。

SCADAの役割は大きく拡大している

ここまで述べてきた通り、欧州では「SCADA=表示器」から「SCADA=IIoTソフトウェアプラットフォーム」へのシフトが既に進んでおり、生産性向上に既に貢献していることが見て取れる。

国内ではSCADAの浸透が遅れているだけでなく、IIoTでいかに生産性を向上させるかという議論が始まったばかりではないだろうか。また、国内では「IIoT=AI」といった考え方も強調されすぎているように感じる。確かに、AIが得意な分野は存在するが、それが全てではない。今回、述べたような着実な方法で生産性を向上させることがまずは取り組むべき内容であると考える。


今後、最近注目を浴びている日本発の規格であるEdgecross(エッジクロス)やField SystemなどのIoTプラットフォームと、IIoTソフトウェアプラットフォームとなったSCADAの関連性と位置付けについて検証したい。そして、派手な機能差としては見えてこないが、スマート工場を実現する際には必ず求められる根本的な基礎機能を紹介する。

※本記事は掲載時点の情報であり、最新のものとは異なる場合があります。予めご了承ください。