ページ先頭

本文

オムロンの取り組み

ビッグデータ化する装置データ

生産現場から見たビッグデータとその活用ソリューションについてご紹介します。装置側や生産ラインでは、従来から見える化の必要性がうたわれていますが、見える化のレベルはFAを取り巻く外部環境や現場改善により変わってきています。

進歩する生産情報の見える化

従来、見える化は「生産継続に必要な情報の見える化」として、装置にシグナルタワーをつけたり、表示灯をつけたり、装置の状況を近くで見せるようにしたりすることから始まりました。そこから一歩進んで、「生産性向上に必要な情報の見える化」では、装置のアラームデータを付けたり、あんどんを付けてラインの状態を見えるように進化してきました。

マシンデータ活用を進化させ、迅速な経営判断へ

現在はそこからさらに進歩、改善が進み、生産以外の情報、例えば品質データやトレーサビリティのデータを一緒に取り込む、もしくは環境やエネルギーのデータを取り込むことで、生産ラインの状況をより細かく把握するようになりました。これが生産現場に必要不可欠な「見える化」です。

実はさらにそのデータを使って、生産ラインをより効率的に動かす、もしくはこの生産ラインはこのロケーションに合っているのか、違う生産工場に移動すべきではないのかといったデー タを紐付けて経営情報として活用しようとする動きが、「市場情報との連携」と言われています。

ここまでいくと、装置データだけでなく、 ERPシステムなどとの連携が非常に複雑になってくるので、今回は3番目のところまでを詳しくご説明します。

品質管理の環境変化

品質データを例に挙げます。なぜ品質データが必要かというと、法規制と使う人の意識が大きく変わってきていることがポイントです。品質に関する規定は業界によっても様々ですが、年々基準が厳しくなり、そのためにデータを準備しなければならなくなってきました。

もう1つが消費者のPL意識の変化がより激しくなってきていることです。例えば、テレビなどでリコールや不具合のニュースが流れると、消費者にとってそのメーカの信頼はかなり落ちることになります。

最近もかなりニュースを賑わせていますが、それを裏付けるかのように市場リコールの件数が2003年から2010年の間に5倍になっています。インターネットで検索すると山のように情報が出てきますが、毎週どこかでリコールが発生している状況です。

想像に容易いですが、これが起こるとブランドのイメージダウンやその市場における競争力ダウンといった、会社そのものへのダメージにつながります。

そこで、リコールを起こさないためには、個体管理が大変重要になってきます。従来のロット管理では見えなかった品質データをシリアル管理により、部品1個1個やその画像データがどのように作られたかをしっかり管理する必要があり、品質管理システムを強化したいという声は多くなっています。

見える化レベルとデータ量

ところで、生産現場のビッグデータとはどのようなデータか、どれくらいのデータがあるのか、規模感を知るために計算してみましょう。

装置の状態だけを見るアラーム情報のデータは普段は瞬間的なデータですが、これを取り続けると、1秒間に100B(バイト)で1年間では3GB(ギガバイト)ほどのデータになります。また、生産ラインに関するデータだと、アラーム情報と生産情報を取り続けると、9GBほどになります。これはミニマムサイズなので、これ以上のデータを取ろうとするとパソコンがパンクするという状況になってきます。

品質データだけをとってみても、ロット管理をする 場合だと、1年間で1.2TBになり、これが10 個単位のロット管理だとすると、個体管理では10倍なので12TBになってくるわけです。

さらに、これに画像データをつけると、3EB(エクサバイト)という単位になります。通常のパソコンではGBですが、その上がTB(テラバイト)、PB(ペタバイト)、EB(エクサバイト)、ZB(ゼタバイト)、YB(ヤタバイト)という位になります。

見える化レベルとデータ量の関係

そこまでいくとローカルサーバで管理し切れないデータになってくるので、実はこれまではこうしたビッグデータは捨てられていたというのが正直なところでした。

近年、IT技術の進化に伴ってクラウドサーバという技術が出てきました。クラウドサーバにデータを置くことにより、ローカルサーバのデータの容量を管理する必要がなく、容量無制限のサーバを活用することができるようになったのです。

大量データを収集、保存するために従来では課題となっていたハード設計や管理が解決され、しかもデータのセキュリティも確保されるといったIT基盤が構築されてきたのです。

品質データ収集の現状と課題

しかし、実際は装置側ではそう簡単にはできないという声がかなり多いのも事実です。今回のソリューションのきっかけとなったお客様のお話ですが、もともとこうしたデータをとっておられましたが、生産のタクトを上げるためによくよく調べてみたそうです。

すると、データをデータベースに上げるのにもともと2秒くらいかかるのを0.5秒に縮めるために、通信部分だけのタクトタイムを上げることで、装置そのもののタクトが数段上がってきます。ただし、装置の制御性能を落とさずに実行しようとすると、どちらかを犠牲にしなければならず、諦められていたのです。

ではそのような経緯がある中で、お客様がどのようなデータ収集を行っているかをマーケティングすると、実は大きく分けて4つのパターンがあります。

1つ目は人がデータをとってデータベースに手入力するオフライン系の作業者入力パターンです。

2つ目はPLCのユニットで、データをとって上位のデータベースやサーバにファイルを飛ばすというパターン。

3つ目はパソコンが装置とPLCとの通信手段になって途中で中継しているというパターンです。通信プロコトルを使って、データを収集してパソコンの中でファイル化し、そのファイルを上位に転送するものです。

そして、4つ目は少し特殊ですが、タッチパネルでデータをとってFTPで上位に飛ばすという機能を使われているパターン。大きくはデータのやりとりにこの4パターンが多くみられました。

すべてマーケティングした結果、手入力のパターンが3割で、一番多かったのは間にパソコンを入れているケースでした。このケースでもお客様の課題があって、2番目と3番目に多い課題というのは、コストアップやパソコンの管理で、ゲートウェイ機器が入ることによって人手がかかるという問題です。

そして、最大の課題は通信を速くすることで制御性能が落ちてしまい、制御性能を保持しようとすると通信のデータを間引いたり、データのスピードを遅くしたりしなければならないということでした。

品質データ収集の課題

装置データ収集ソリューション

そこで、私どもではゲートウェイやコントローラをなくし、直接データベースに飛ばすというアプリケーションを実現することで、収集スピードアップと中間に入る手間をなくすご提案をしています。

これを今までのコントローラはなぜできなかったのでしょうか?下図の左側にあるのが、従来の私どものコントローラで使っていたアーキテクチャです。新しいユニットや新しいものにしようとすると、特別なCPUのユニットを作っていました。

今回のコントローラ NJシリーズでは、PCのアーキテクチャを使っているため、従来のように新たなハードウェアを開発することなく、CPUの中でソフトウェアモジュールを作ることができます。ハードウェアを起こさずにCPUの中にエンジンを作るわけです。今回のデータベースではここにエンジンを1つ搭載しています。

これにより、余計なハードを作ることなく、CPUの中で直接データベースと接続することができるのです。これはNJだからこそ実現できたことです。

マシンとデータベースを直結し、高速性、確実性を担保し生産物の個体管理を実現!

データベースの3つの安心

今回、データベースソリューションのエンジンを作るときに3つのコンセプトを決めました。1つは「確実」、2つに「高速」、3つに「簡単」ということです。

まず「確実」というところでは、データはもともと抜け漏れをなくすというところで考えています。これまで、送りたかったけども送れなかったデータというものがあったので、それを上位に確実に飛ばします。

次に「高速」という点では、最速20msecを実現しており、データベースの接続機能を20msec程度にしても、制御の性能というのは基本的に保持、保証されます。
高速制御をしながら20msecのデータベースのエンジンを走らせられるのが今回のアーキテクチャの中で実現できるのです。

もう1つ「簡単」というキーワードでは、従来からのパターンはエクセルファイルやCSVのため、データベースといわれると一段高く、難しいと思われがちかもしれません。今回は特殊なユニットがあるわけではく、データベースやC言語、特殊なSQLというプロトコルを知らなくても、NJの中でラダーのプログラムの中からデータベースに書くことができます。

例えば、NJからDBというファンクションブロックでこのデータを送りたいという変数をセットするだけで、指定されたデータベースにデータを飛ばせます。そのため、プロトコルレベルでは何を行なっているかというのは一切知る必要がありません。あとは集めたデータを先ほどのSQLサーバを使って、データ分析し、上位のアプリケーションを組むことができます。

msecオーダでの高精度な見える化

msecオーダでの高精度な見える化事例をご紹介します。ロット管理で行われている検査画像のデータと数値データは関連づけが一切ありません。データだけが取られていき、そのうちデータベースの容量がパンクするとデータを捨てる、というように大変もったいない使い方がされていました。

これをロット管理から個体管理とし、プラス画像データを紐付けることにより、先ほどの画像データから、製品がどのように作られるかをmsecオーダで分析することができます。従来は秒オーダもしくは3秒といったオーダで取っていたデータをmsecオーダで取ることによって、より細かい品質データを取ることが可能になるのです。

もう1つ、msecオーダでデータを取ることによって、予防保全に使えるという例をご紹介します。

実は温度やトルクなどのアナログデータを細かく分析すると、異常の発生を知る前に異常の予兆を管理する、もしくは予防することが可能になります。例えばモーション系である位置までこのスピードで動けとプログラムをした場合、コントローラ側が自動的に移動量に変化させてその位置まで動かそうとします。装置からすると、その位置まで指定のスピードで動くと何の異常もありません。

一方、モータ側は、たとえばオイル切れを何らかの負荷と判断して自分でトルクを上げてスピードを上げようとします。そして、結局モータ自身に負担がかかり、モータは壊れてしまいます。

そういった予兆をこのmsecオーダのデータを取ることによって見つけることが可能であり、装置が異常を起こしたり、止まったりする前に警報値としてこのデータを活用することができます。

搬送機メーカの場合、ものが壊れそうになると振動のデータが変わってきます。例えば振動が激しくなるというのは、モータを変えるサインになります。

私どもは装置を設計しているわけではないので、データの何を見ればいいかということはお客様に教えていただかなければならないことが多々ありますが、これらのデータを収集することはできるので、お客様に合わせた確実な予兆管理を実現することができるようになると考えています。