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

IIoT(産業用IoT)活用を上手に行うためには何が課題となり、どういうことが必要になるのか。今回は、個別のIIoTツールを組み合わせるのではなく、IIoT統合ソフトウェアが実現する価値について説明する。

統合して初めて価値が生まれるIIoT

IIoTに先進的に取り組んでいる国内企業の実態を見ていると、異なる分野の専用ツールを要所で採用し、それらを統合して最終目標を達成しようとするケースが見られる。ただ、こうした場合、本当に必要とされる部分、いわば「かゆいところ」に手が届かずに苦しんでいる印象を受ける。

例えば「収集したデータを解析するならBIツール(Business Intelligence)だろう」、「タブレット表示であれば、HTML5をベースとしたHMIの専業メーカーだろう」といった発想があり、こうした個々のシステムをベースにして検討を進めるケースとなる。もちろん、それらは要所においては最高性能を備えているかもしれないが、IIoTを実現するためには、必要以上に高性能であったり、最終的なスループット向上などに貢献しなかったりするケースが多く、「導入したものの使いこなしていない」という状態をよく見かける。

IIoTはさまざまなシステムの集合で価値を実現するため、複数のシステムを統合したソリューションという形になって初めて価値を生む。その価値をどれだけ効率的に生み出すのかという観点で考えた場合、個別のソリューションを組み合わせるよりも、IIoTソフトウェアプラットフォームの特徴である統合ソフトウェアで最初からトータルの枠組みを決めてしまった方が良い場合も存在する。

前提として、IIoTは膨大なサイズのアプリケーションであり、膨大なデータに対して、収集、演算、表示、解析、検索といった、負荷の高い処理が多く求められる。つまり、処理速度は非常に重要なキーワードであり、複数のツールが混在するということは、その度にツール間でのインタフェースが発生するため、演算時間のオーバーヘッドが発生する。ツールに階層を持たせると、演算時間が加算されるのである。

統合ソフトウェアでは、必要な機能が網羅的に提供され、それらが密接に統合されているため、総合的に見た場合の性能は、結果として高くなる(余分なオーバーヘッドなし)。そのため、現場に浸透する(IIoTに特化した機能群のため複雑すぎない)といったケースもよく見られる。今回はこれらの点を、IIoTソフトウェアプラットフォームの1つであるzenonの例を用いて説明する。

データベースとBIツール

IIoTを実現するには、さまざまなデバイス(PLC、DCS、センサーなど)から、さまざまなデータ(製造パラメータ、製造データ、アラームなど)を集めることになる。それらは各デバイス独自のタイムスタンプと共に吸い上げ、全体のデータを時間軸上で整列させることが求められる。さらには、そのデータを高速にデータベースに保存しながら、必要であれば瞬時に複雑な演算をして異常状態を検知し、アラームなどを発行しなければならない。地味に見えるこの部分には、非常に多くのノウハウが求められるのである。

個別のシステムの組み合わせであれば、これらのデータを吸い上げて標準化するために、毎回、個々で調整が必要になる。統合ソフトウェアであれば、ある程度はこれらの調整部分などを吸収し、簡略化できるという点が特徴だ。

例えばzenonの場合は、各TAG(データ)情報が「外部タイムスタンプ」「内部タイムスタンプ」「データ」「フラグ」の4つの要素から構成(構造体化)されている。このようなデータ構造を持っていない場合、それぞれの関係性がない状態でデータベースにデータが格納されるため、それぞれを関連付ける作業が必要になる。IIoTでは単なるデータではなく、時系列データが重要となるため、時系列データの高速なデータベースへの格納、検索にはこういった仕掛けが必要なのである。

zenonの4つのデータ要素の例

データ検索での例も紹介する。zenonの場合、膨大に蓄えられた時系列データを分散させて一定量のデータベースにアーカイブし、それらのアーカイブを特定のルールで関係性を持って管理する手法を取る。アーカイブされたデータベースから「特定の製造データ(温度など)を、特定期間(アラーム発生時から前後1時間など)だけ表示したい」といった要求があると、複数のアーカイブデータから特定の時系列情報が含まれているものだけをメモリに展開し、必要とされるデータを高速に検索、取得する。

生データから1分間、1時間、1日などの粒度でアーカイブデータを自動生成することで、用途に合わせ、最適な粒度のデータから検索することを可能とする。世の中にはさまざまな優秀なデータベースが存在するが、IIoTシステムでは、データを蓄積するだけでなく、利用することも視野に入れて設計されたシステムが必要である。この利用という面では、SCADA(Supervisory Control and Data Acquisition)に内蔵されたデータベースが重要な役割を果たす。

高速な時系列データ検索を実現するSCADAデータベース

タブレット端末への表示とHTML5

最近は、生産ラインでのタブレット端末の利用が急速に進んでいるが、その活用方法としては「生産ライン全体の情報を表示する」「異常発生時はその場で復旧マニュアルを表示させる」「必要なら異常発生箇所の担当開発部署の内線番号を表示させる」などが挙げられる。タブレット端末で表示させる場合はHTML5が用いられるケースが多く見られるが、ツール面で考えた場合、Visual StudioとHTML5では、全く異なる2つの環境(Visual StudioとHTML5)を準備しなければならない。

集中管理室での集中管理パネルにおいては、Visual Studioベースで構築された計器を用いるのが性能(表示速度)としては優れている。しかし、その一部の表示を製造ラインで使うタブレット端末に表示したい場合は、ユーザーがまた新たに別のツールでパネルを作成する必要がある。さらに、導入後も2種類を継続して保守する必要がある。zenonなどの統合ソフトウェアでは、Visual StudioとHTML5の両方の環境で、ユーザーが気にすることなく表示することなども可能になる。

集中管理パネルでの表示
HTML5によるタブレット端末での表示

データ解析における統合ソフトウェアの使い方

データ解析での例について、あるデータを用いて稼働率の統計をとりたい場合があるとする。もしPLCとの接続が切れていたり、特定工程だけメンテナンス状態であるといった場合には、その期間のデータを排除して稼働率の統計演算をしなければならない。そうしなければ、想定以上に稼働率が悪い(製造ラインが止まっていた)という、意図しない結果を導いてしまうためである。

zenonの場合、「PLCとの接続無し」「メンテナンスモード」といったフラグ情報を各TAG(データ)に持たせているので、統計演算の際にはこれらの情報を外して自動演算してくれる。もちろん複雑な設定をすれば実現できないことはないが、どれだけ優秀なBIツールを用いたとしても、必要な解析結果を得るまでに、大きな手戻りまで発生する可能性がある。一般的な市販のデータベースを用いて、時系列(タイムスタンプ)やStatus Flag(フラグ)といった情報を高速に格納し、蓄積された時系列データを効率よく分散してアーカイブし、時系列情報をベースに高速に各アーカイブからデータを検索、抽出するといった作業には、多くの工数とテクニックが求められるということである。

先述した通り、優れたBIツールは世の中にたくさん存在する。本当に深い解析をしようとすると、確かにBI専用ツールが優れていることは間違いない。しかし、それらのBIツールは製造業向けに開発されたものではない。IIoT向け統合ソフトウェアは、製造業で一般的に求められるデータ解析に限定されるが、それらを簡単に利用できるように機能開発が行われている。

zenonの場合は、「一定期間におけるアラーム発生頻度がもっとも多い順に並べる」「生産停止が発生した回数が多い順に並べる」「生産停止が長く継続した順に並べる」といったソーティングがツール上で簡単に行え、それらを統計演算するためのデータベースへのアクセスは非常に効率的である。また、頻発アラームをダブルクリックすれば、該当するアラーム一覧が表示され、それが全体のガントチャートでどの位置に該当するかを視覚化できる。

ガントチャートによって過去の装置稼働状況をさかのぼって確認

さらには、特定のアラームを詳しく解析する際に、過去のアラームの時系列位置に全ての製造データを戻し、そのデータをHMIパネル上に表示させることで、「アラームが発生した直後に右側のバルブが高速に開閉していないか」「アラームが発生する直前に横のスイッチがオフになっていないか」といった、視覚的な解析もできる。もちろんローデータでの解析もできるが、視覚情報も用いて解析できる点に価値がある。

プロセス画面のリプレイ画面

IIoTプラットフォームで重要性を増すSCADA

今回挙げた例はあくまでも全体のごく一部である。強調したかったことは「IIoTを実現する上で、要素のツールを自ら統合して作り上げる」という考え方は以下の2つの点でリスクがある。

  1. ツール間の親和性の部分で性能が落ちる可能性がある
  2. ツールを介するごとに演算時間のオーバーヘッドが発生して性能が落ちる場合がある

SCADAがIIoTソフトウェアプラットフォームに大きく舵を切ったのは、これらの構成要素を高度な親和性と演算時間で構築できるからである。

また、最近は「Edgecross」や「Field System」などの日本発の規格が注目を浴びているが、これは「IIoTをパートナーと共に作りましょう」と言っているだけのように個人的には考えている。

「これらのプラットフォームを全面的に採用してさえいれば良い」という考え方は、求めるパフォーマンスに対してリスクがある。データを収集して整列するところまでは「Edgecross」や「Field System」で行うが、集中管理表示、タブレット表示、データ処理や解析いった部分は、パートナーの各社が別々に準備することになるため、構成要素間の親和性や処理速度といった面で苦しくなると感じているからだ。

できる限り自分たちの業務に最適な機能がまとまったツールを採用することが有利になるということは変わらないが、それらの中身がどうなっているのかという点では精査が必要である。