Amazon Web Services ブログ
IoT@Loft #14 IoTにおけるAI/機械学習活用の取り組み
こんにちは。IoT ソリューションアーキテクトの嶺です。
9月16日に開催された IoT@Loft 第14回目のテーマは、「IoTにおけるAI/機械学習活用の取り組み」でした。
各LTのダイジェストを、参加者の皆様から寄せられた質問への回答と共にお送りします。
※ 他の IoT@Loft の開催記事はこちらからご覧いただけます。
IoT@Loft とは ?
IoT 関連ビジネスで開発を担当するデベロッパーのためのイベントです。IoT の分野は、「総合格闘技」と呼ばれるほど、必要な技術分野が非常に多岐に渡ること、ビジネスモデルが複雑なケースが多く、全体を理解することは難しいと言われています。その結果、実証実験 (Proof of Concept : PoC) から商品への導入が進まないケースや、PoC でさえ十分に実現できていないケースも多々あります。
IoT@Loft は、そういった IoT 特有の課題と向き合い、情報共有・意見交換を行う場として、参加者の事業や製品開発を成功に近づけることができれば幸いです。この勉強会では、膨大な IoT 関連の情報の見通しを良くするために、各回ごとにテーマを定め、それに沿った形で登壇者に事例や技術のご紹介を頂きます。テーマは、インダストリー、ソリューション、テクノロジー、開発フェーズなどを軸に決めていきます。
IoT@Loftについて詳しく知りたい方はこちらのブログを見て頂ければと思います。
https://aws.amazon.com/jp/builders-flash/202005/iot-loft/
Connpassのグループに入っておくと、次のイベントの通知や、登壇資料の通知が受け取れますので、ぜひご参加ください。
IoT@Loft Connpass
https://iot-loft.connpass.com/
LT セッション
LT 1 – 目視代替AIをPoCで終わらせない。目視代替AIアプリケーションプラットフォームの取り組み。- 目視業務のAI活用システム立ち上げを簡単に –
登壇資料: 目視代替AIをPoCで終わらせない。目視代替AIアプリケーションプラットフォームの取り組み。- 目視業務のAI活用システム立ち上げを簡単に –
日立製作所様からは、工場における目視検査など人間による目視で行われている検査業務を代替するAI開発がPoCから本番展開に移行する際の課題と、それを解決するために開発されたHitachi Visual Inspection Application (HVIA) についてご紹介いただきました。
目視代替AIの本番展開においては、UIの開発、IoTデバイスとの接続、学習用画像データや学習済モデルのバージョン管理、再学習の仕組みといった、AIを実運用する為のシステム開発が必要であり、その為にはAI分野以外の多岐にわたるスキルが求められることが導入に向けての課題となっています。
日立製作所様では、目視代替AIの実運用で必要とされる機能をパッケージ化したソリューションとしてHVIAを開発し、それらの課題の解決に取り組まれています。
HVIAでは、学習や推論を行うAIエンジンと接続するエンジンインタフェース、カメラやPLCといったデバイスと接続するデバイスインタフェースを定義する事で、様々なAIエンジンやデバイスと組み合わせてご利用いただく事ができます。また、学習用データの管理、学習や推論の実行と結果の確認など、目視検査工程で必要とされる業務を遂行するためのUIを提供しています。
今回は、AIエンジンとしてAmazon SageMakerを利用するための設定方法やコードを解説されると共に、ボタンの品質検査を例として、欠けたボタンが異常と判定されるまでの流れをご説明いただきました。
「PoCで目視検査のモデルは作ったけど、実運用向けシステム開発のハードルが高くて先に進めない」といった悩みをお持ちの方に向けて、HVIAではTry-itというお試し環境も提供されているとの事です。
Q&A
Q. Try-it環境というものに興味を持ったのですが、学習データや判定モデルは事前に用意する必要があるのでしょうか?
Try-it@awsでは、コンテナ形式のHVIAをお試し頂く事ができます。この環境ではHVIAを学習から推論まで一通りお試し頂けますが、基本的には学習済みモデルをお持ちのユーザー様が、モデルとHVIAとの接続をお試し頂く事を前提としております。学習済みモデルをお持ちでない場合は、サンプルの学習データやモデルを提供する事が可能ですので、その旨お伝え頂ければと思います。
Q. Try-itはコンテナとして提供されるとの事ですが、提供形態はどのようになるのでしょうか?
1つのDockerコンテナにHVIAの機能が全て入ったものを提供する形になります。具体的なコンテナイメージの提供方法につきましては、ご連絡頂ければ個別に対応させて頂きます。
Q. カメラの接続はBasler社に対応とありますが、今後、これ以外のカメラの接続の考えはあるのでしょうか?
はい、Basler社以外のカメラにも順次対応していく予定ですので、今後サポート情報を更新していきます。
また、産業用カメラの国際的規格であるGenICamにも対応しておりますので、各ベンダーのSDKを利用すれば、他のカメラに接続する事も可能です。
Q. 検査内容によって選定するAIエンジンも異なってくるかと思いますが、専門的な知識がなくても適切なAIを選定してすすめることができるのでしょうか？
ご指摘の通り、検査内容/検査対象/撮像環境によって、適切なAIエンジンの選択が必要です。また、AIエンジンを利用するには、適切な学習を行わせるという点が重要です。そういった面では、専門的な知識が必要になります。
弊社のHVIAでは、様々なAIエンジンへ対応する事で、エンジン選択の範囲を広げられ、また、パッケージ化する事により、AIシステム導入時のSIのコストや技術的課題を低減する事ができます。これらの事から、AI導入のハードルを下げる事が可能です。
また、AIの専門的な知識の支援として、弊社でAIエンジン作成サービスもご用意しておりますし、HVIA導入にあたり様々なアドバイスを差し上げる事も可能ですので、是非ご活用下さい。
ご不明点、ご不安などがございましたら、講演資料の最終ページにあるメールアドレスまで、ご一報頂ければ幸いです。
LT 2 – AWS IoTとAmazon SageMakerで業務用冷凍庫の故障予知を実装
登壇資料: AWS IoTとAmazon SageMakerで業務用冷凍庫の故障予知を実装
東北地方で数多くのクラウド開発を手掛けられているヘプタゴン様からは、青森県の大青工業様と共同開発された、業務用冷蔵庫の故障予知システムの詳細についてお話しいただきました。
業務用冷蔵庫では、気温が上昇する夏場に負荷が上がる事で、潜在的な問題が故障として同時期に集中的に顕在化しやすく、サポート人員不足を招いていました。また、生鮮食料品等の冷蔵庫では、故障が発生すると大きな損失が発生し、場合によっては損害賠償に発展するケースもあります。また、機器をリモートメンテナンスするための既存のソリューションは高価で、全ての設備に導入するのは難しいという課題がありました。
この課題を解決するため、ヘプタゴン様ではAWS IoTを使ってリモートメンテナンス、設備状態の可視化、設備データのクラウドへの蓄積、設備故障の予知といった機能を持つソリューションを開発されました。エッジ側ではRaspberry Piといった安価なデバイスを使い、低コストで冷蔵設備の品質や価値の向上、巡回メンテナンスの必要性の低減といった効果を実現されています。また、これまでは「故障」というのはお客様からクレームを頂くイベントでしたが、「故障前の事前連絡」となる事により、逆にお客様から喜ばれるイベントに変化するという効果もありました。
システムは大きく分けて「データの収集/蓄積/可視化」「推論」「学習/テスト」の3つのパイプラインで構成されています。
「データの収集/蓄積/可視化」では、AWS IoT CoreにセンサーのデータをJSON形式で送信し、Amazon Kinesis Data FirehoseでそれをS3に保存すると共に、AWS Lambdaで管理画面で可視化するためのデータに加工してAmazon RDSに保存します。
「推論」では、1時間毎にAWS Step Functionsのワークフローを起動し、ワークフローではS3上のデータを推論用に整形してAmazon SageMakerで推論を実行すると共に、管理画面で表示するためのデータをRDSに保存します。
「学習/テスト」では、管理画面で学習を開始するとStep Functionsでワークフローを起動し、ワークフローではS3上のデータを学習用に整形してSageMakerで学習を実行し、生成されたモデルでテスト用データによる推論を行い、結果を評価します。
開発で最も時間がかかったのは学習データ集めで、数ヶ月をかけ、試験用冷蔵庫から正常時のデータだけでなく、高負荷時や不具合発生時のデータを取得し、その後2〜3週間でアルゴリズムの選定を行ってSageMakerのビルトインアルゴリズム(LinearLearner & XGBoost)の採用を決められ、1ヶ月程度でAWS側のパイプラインを構築されました。
次のステップとしては、AI/IoT技術を使った業務用冷蔵庫の省エネ化のPoCを実施されており、AWS IoT GreengrassとAmazon SageMaker Neoを使ったエッジでの推論とそれに基く制御、カメラやサーマルアレイといった新しいデバイスの活用にチャレンジされているとの事です。
Q&A
Q. 故障には様々な種類があると思いますが、どのようなセンサーの情報を何種類くらい収集されたのでしょうか?
収集しているデータを全てお話しする事はできませんが、外気温や電力など10種類くらいのデータを収集しており、それらの組み合わせから、どのような種類の故障が発生し得るかを予測しています。
Q. 冷蔵庫の場所によっては通信環境が安定しない場合もあると思いますが、そういった環境へはどのように対応しているのでしょうか?
故障予知ではクラウド側で全て処理しているので、安定したネット環境の存在が前提となっておりますが、次のフェイズではエッジ側での推論や制御を考えており、AWS IoT Greengrassを使ったオフライン対応にもチャレンジできればと考えております。
Q. 管理画面はどのようなものを、どのように作られたのでしょうか？AWSのコンソールだと確認できなかったり機能的な不足がありましたでしょうか？
データの可視化以外にも設備マスタやセンサーマスタなどの管理も必要だったため、専用の管理画面(WEBアプリ)を作成した経緯となります。
Q. 外気との関係もあり実際の故障から時間が経ってから故障が顕在化することがあるとおっしゃっていましたが、推論するうえでは外気温などPLCからとれる冷蔵庫のデータ以外にも取得しているデータなどはありますでしょうか?
発表でお話ししたフェーズでは、気象情報など外部から取得するようなデータは使っておらず、PLC から取得できる情報だけを用いています。
Q. MQTTの下はUDPでしょうか? QoSは何を使用しているのでしょうか?
TCP8883ポートでQoSは0を利用しています。
(※ AWS IoT Core では TCP のみをお使い頂けます。AWS IoT Core で利用可能なプロトコルについてはこちらをご参照ください。)
LT 3 – 物流・インフラ保全業界におけるカメラと画像映像データによるAI活用提案と事例
登壇資料: 物流・インフラ保全業界におけるカメラと画像映像データによるAI活用提案と事例
AIによる社会課題の解決をミッションとされているAutomagi様からは、物流、及びインフラ点検分野で人の目による確認が行われている業務をAIによって自動化する取り組みをお話しいただきました。
最初に、物流・インフラ点検分野でのこれまでの様々な取り組みをご紹介いただきました。物流分野では、ニチレイロジ グループ本社様でご利用いただいている、倉庫の天井に設置した魚眼カメラを用いた、段ボール・パレット・かご車・フォークリフトといった物体がどのように移動・滞留しているかを追跡するシステムの他、スマートフォンのカメラによる三辺計測、段ボールの個数検知といった様々な事例についてお話しいただきました。インフラ点検分野では、東京電力パワーグリッド様でご利用いただいている、ドローンで撮影した映像から鉄塔の錆の位置の検出と劣化度の判定を行うシステムの他、鉄橋やガードレールの錆の検出、コンクリートやアスファルトのクラック(ひび割れ)の検出、アナログメーターの指針の認識といった様々な事例をお話しいただきました。
そして、これらのAIソリューション開発で得られたノウハウをいくつかご紹介いただきました。
1つは、少ないデータからでもモデルの学習に必要なデータを作り出す「学習用データの増強」です。元の画像に対して加工を施す手法として「背景合成」「画角変更」「色彩変更」「精細度変更」、新たなデータを作り出す手法として、人間がBlender等のソフトウェアを使って本物そっくりの画像を作る「3Dモデリング」、AIに特徴を捉えた偽画像を作らせる「GAN (敵対的生成ネットワーク)」といったものを活用されています。
また、深層学習が不得意とする対象には別の手法を用いて、互いの長所を活かすような工夫も採り入れられています。レジに設置したカメラで商品を特定するAIを開発したケースでは、例えばおにぎりの画像だけからメーカーや品名を特定する事は、類似商品が多い上に学習用の画像が数枚しかなく、深層学習では難しいため、深層学習ではおにぎり・お菓子・飲み物といった商品カテゴリーの特定に留めた上で、そのカテゴリーの中で特徴点マッチングを行っておにぎりの種類を特定したり、ラベルをOCRで読み取って会社名や味、内容量の違い等の細かい識別を行っています。
Q&A
Q. BlenderでのCG作成を効率化する手法はありますでしょうか?
全ての製作物を1から作るだけでなく、既に出回っているものがあればそれを加工して利用するという手法があります。ある程度製作をこなして慣れてしまえば、AIの教師データとしてのCG製作が効率的かを事前に検討した上で、効率的でない場合は別の手法を使うといった判断ができます。
Q. インフラ点検では目視以外の作業もあると思いますが、AIで錆などを検出する事で、作業全体ではどの程度の効率化を図れるのでしょうか?
二次点検や詳細点検では打音や触診などが入ってきますので、目視だけでは対応できません。一方、運用についてヒアリングさせて頂くと、一次スクリーニングを目視のみで行っているケースは結構あり、そこの部分をまずは代替して省力化する事を目指しております。その上で、打音や触診については、ドローン・自動走行車・ロボットアームといったものを手掛けている会社様と連携し、実現方法を検討していきたいと考えております。
Q. 学習用画像データの作成にCGも活用されているとの事ですが、実際の環境でも精度良く推論できるようにCGを作成するために工夫されていることはありますか?
まずCG作成による教師データが学習データとして有効なケースかどうかを判断しています。形が特徴的な機械的な構造物などは向いており、一方で劣化現象など色/質感のわずかなニュアンスが判定を左右するようなものは不向きです。
CG作成する際には、まず形状を3Dで構築したのち、テクスチャは実態のものと近しいものを貼り付けたり、光源位置を様々なパターンにしたり、背景画像を差し替えたりすることでバリエーションを増やしています。
Q. クラックや錆といったものの認識では撮影条件を揃える事が難しいと思いますが、どのように対処していますか?
特に影響が大きいのが明るさなので、逆光が強い時には対象面がもっともはっきり映るような画像補正を撮影前に行っていただくことを推奨しています。後からのデジタル補正だとうまくAI検知できなくなる傾向があるため。
画角を揃える場合は、撮影画面上にガイドを設けることもあります。それにより運用時にある程度統一された画角で撮影することが可能になります。
LT 4 – AI/機械学習に活用できるAWSのエッジソリューションのご紹介
AWSからは、IoT開発の多くのケースで必要とされるエッジコンピューティングにご利用いただけるAWS IoT Greengrassを中心としたエッジソリューションをご紹介すると共に、工場における外観検査を例に、AI/機械学習を活用したIoTソリューションの構築方法をご説明しました。
例えば工場設備の異常検知を行うケースでは、異常を検知したらすぐに設備を停止したり、パトランプを点灯する等のアクションを行う必要がありますが、異常検知を行うAIをクラウドで実行する場合、ネットワークの往復レイテンシが発生しますし、ネットワーク障害等があると工場を稼働できなくなる可能性があります。
AWSの処理機能の一部をエッジ側に拡張するAWS IoT Greengrassをお使いいただく事で、異常検知などのクリティカルな処理はエッジ側で行いつつ、データの蓄積や分析、推論モデルの再学習といった部分ではクラウドのメリットを活かすようなアーキテクチャを実現する事ができます。
iot@Loft#14-LT4-AI /機械学習に活用できる AWSのエッジソリューションのご紹介
Q&A
Q. Greengrassのオフラインキャッシュ機能は、Greengrassが標準で搭載している機能でしょうか? それともユーザーがロジックを実装する必要があるのでしょうか?
AWS IoT Greengrass では Cloud Spooler と Stream Manager という 2種類のオフラインキャッシュ機能を提供しています。Cloud Spooler は、AWS IoT Core へのメッセージ送信を自動的にキャッシュします。Stream Manager は AWS IoT Analytics、Amazon Kinesis Data Streams、AWS IoT SiteWise、Amazon S3 といったサービスにデータを送信するために Greengrass 上で動作する Lambda 関数からお使い頂けます。Cloud Spooler の詳細についてはこちら、Stream Managerの詳細についてはこちらをご参照ください。
Q. Greengrassのノンコーディングとはどういう意味ですか? confだけ書けばよいという意味ですか? NodeREDのようなGUI開発ということですか?
Connector は、AWS コンソール等で Greengrass グループの設定の一部として指定頂く形になります。Connectorの中にはMQTTでのデータの入出力を必要とするものがあり、その場合は Connector に MQTT メッセージを送受信する部分はご用意頂く必要がありますが、Connector が実装している主要ロジック部分についてはコーディングが不要、という意味となります。Connectorの詳細についてはこちらをご参照ください。
Q. オフラインキャッシュの容量はどのように設計すればいいのでしょうか?
基本的には、送信するデータのビットレートと、何秒程度のオフライン状態が想定されるかで、どの程度の容量のオフラインキャッシュが必要になるかが決まってくると思います。それに加えて、デバイスのストレージ容量に制限がある場合は、その制限も加味して決める必要があると思います。Cloud Spooler のキャッシュサイズの設定方法についてはこちら、Stream Manager のキャッシュサイズ (ストリームサイズ) の設定方法についてはこちらをご参照ください。
お知らせ
次回 IoT@Loft
第15回目のIoT@Loftは、「スマート農業を加速するための IoT の使い所」という内容で開催いたします。
イベントの詳細や申込についてはこちらのサイトからご確認ください。
IoT@Loft ウェブサイト
https://aws.amazon.com/jp/start-ups/loft/tokyo/iot-loft/
IoT@Loft Connpass
https://iot-loft.connpass.com/
著者について
嶺 行伸
AWSのIoTソリューションアーキテクトとして、様々な業界のお客様のIoT導入を支援しています。