【レポート】スマートファクトリの実現における AWS IoT での検討ポイント(AWS-13) #AWSSummit

この記事は、4月26日に行われた AWS Summit Tokyo（2023）のセッション『スマートファクトリの実現における AWS IoT での検討ポイント(AWS-13) 』のセッションレポートとなります。

セッション概要

製造業では、人材の不足や育成また品質向上やコスト削減に関する課題が旧来から叫ばれています。デジタルを活用し、それらの問題を解決すべく、稼働状況の可視化、故障の予兆保全に取り組まれているお客様が多く増えています。その一つの手段として、近年注目されている視認性の高いデジタルツインを構築することにより、機器の故障に対するアクションをより迅速化・高度化させることが期待できます。本セッションでは、製造機器からのデータを収集しデジタルツインを構築するまでの一連の流れと、ビジネスにどのような効果をもたらすのかをご説明します。

スピーカー

アマゾン ウェブ サービス ジャパン合同会社
技術統括本部
ソリューションアーキテクト
戸塚 智哉 氏

セッション視聴

AWS Summit Tokyoの登録を行うことでオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。）

登録済みの場合、以下から直接遷移できます。

• https://jpsummit.awsevents.com/public/session/view/532

レポート

セッションを始める前に先に伝えたいメッセージとして「工場を生き物のように育てていく」をテーマに話されました。 本レポートもスマートファクトリの実現を「生き物のように育てる」観点で読んで頂けると幸いです。

製造業の課題

• 少子高齢化、技術継承、環境・設備・標準化・投資、安全衛生管理などがある
• 昨今は、サステナビリティを意識して構築しているケースも多くなってきた
  • これまでは品質向上をメインに考えていたが、昨今はCO2削減が非常に注目されている状況。

サステナビリティの観点における取り組み

• 例えばダッシュボードで水の使用量の監視
• 最適なタイミングでの機器のメンテナンス
• まだまだ安全ではない現場の安全性の向上

とはいえ、すぐに取り組めない状況というのはよくあります。

スマートファクトリとは

• スマートファクトリの定義は諸説あるがここでは次の定義として検討する
  • 企業ごとに「自動化」をベースとして「効率化」「プロセス改善」などを目指すもの

スマートファクトリの考慮事項

• 大きく3つある
  • 安全かつ簡単にエッジリソースを活用
  • 工場とクラウドのセキュアな接続
  • 工場とクラウドのリソースをハイブリッドに活用

スマートファクトリ実現の壁

• 業務面
  • 現場だけ、経営面だけというように片方の状況しか見えてないと取り組みが難しい
  • パッケージ製品を使う場合でもすぐに取り込めないという問題もありがち
  • またその費用対効果も見えづらいことがある
• 技術面の課題（特に技術面の課題でスマートファクトリ実現が進まないことがよくある）
  • 設備からデータをどうあげるのがいいか（プロトコルが多種多様）
  • プロトコルの違いをどうすればいいか
  • センシングできてない場合、どんなセンサーを調達してどう設置すればいいのか
  • 大規模に展開したり障害発生時の復旧をどうするか

このあたりの話は、筆者もよく聞く課題ですね。製造業の現場では様々なプロトコルが使われており「データを吸い上げる」だけでも工数と時間がかかるケースが多い印象があります。

AWSでスマートファクトリを構築するには

• ISA95という欧米で主流になりつつある規格がある
  • PLC, SCADA, MESなどのデータ頻度や設備側システムと経営側システムでやり取りがしやすくなることが規格化されている
• IA95をもとにOPC UAのような国際規格を使ってフィールドプロトコルレベルで共通化
  • 結果としてITとOTの境界がなくなる
  • データがより早くクラウドにアップロードされたり、逆により早く機器をコントロールできるように

機器間、システム間のデータ処理におけるオーバーヘッドがなくなることで処理速度の向上も見込めるようになりますね

IA95と AWS サービスのマッピング

• 下記は一例
  • センサーのセンシングはマイクロ秒単位 設備装置
  • PLCのデータ処理は秒単位の PLC
  • SCADAは分単位のモニタリング サードパーティのエッジソフトウェア、AWS IoT Greengrass,
  • MESは時間単位のオペレーション管理 AWS IoT Core, AWS IoT SiteWise, Data Lake
  • ERPは日月単位の事業計画など アプリケーション、Amazon QuickSight
• 扱うデータを意識してAWSサービスを選択するといい

実際にAWSで利用できるサービスは多岐にわたるので、あくまでも一例であり、自社の業務に合わせてビルディングブロックで考えることが重要という話でした。 これはこれまでもAWSを利用する上でよく語られてきた話です。

産業分野で利用できるIoTサービス

• ゲートウェイ装置
  • AWS IoT Greengrass
• データ可視化
  • AWS IoT SiteWise Monitor
  • Amazon OpenSearch Service
  • Amazon Managed Grafana
  • Amazon QuickSight
• 設備データの収集
  • AWS IoT SiteWise
  • AWS IoT Core
• データ分析・蓄積
  • AWS IoT Analytics
  • Amazon S3
• 予兆保全・品質検査
  • Amazon Lookout for Equipment
  • Amazon SageMaker
• 外観画像の収集
  • Amazon S3
• MLモデルの配布
  • Amazon S3
• 外観検査・画像分析
  • Amazon Lookout for Vision
  • Amazon Rekognition

特定の課題に特化したサービスも多くありますので、扱うデータ要件に応じて最適なものを選択して構築していく流れになりますね。

例えば、実際の現場で、画像や動画からインサイトを得たいという場合でも、プロトコルの違いやよくあるプロトコルについてはAWS IoT Greengrassで予め用意されたコンポーネントを使うだけでデータ取得・クラウドサービスへの利用に繋ぎこむことも用意になります。 この際、ユーザーは対象のコンポーネントをデプロイするだけでOKでコードを書かずに実現できるメリットもあります。

技術面の課題に対するAWSサービス

• AWS IoT Greengrass
  • 直接クラウドとやり取りができない設備に対して、ゲートウェイとして様々なプロトコルで設備と通信してクラウドへデータ送信できる
  • MQTT,GPIO, RTSP, Modbus RTU/TCP, SLMP, OPC-UA, OPC-DA...
  • これらをMQTTやHTTPSを用いて、AWS ioT Core,Amazon Kinesis, Amazon S3, AWS IoT Analyticsなどに連携
• AWS IoT SiteWise
  • 機器データを数分でAWSに取り込み
  • データを構造化して取り込むことができ、機器のパフォーマンスメトリックを指定できる

AWS IoT SiteWiseでは、事前に取り込むデータに対してアセットモデルというモデルを作り、どのデータをどういう単位で取り込み、指定した計算によるメトリクスを生成することができます。 また、簡単な設定だけですぐに設備からデータを取得することができるのも大きな特徴の一つになっているので、要件が合えば非常に素早くデータ収集から可視化までを実現できるサービスになっています。

センサーデバイスの調達や設置の課題

• 例えば稼働率は既に取れているが、違うデータから故障予兆したい時にデバイスやセンサーをどこから調達すればいいのか分からないという課題
  • AWS のパートナーとして接続実績のあるカタログから選択できる。
  • 直接サイトから購入も可能
  • 一方で既に使っているゲートウェイを活用したい場合、デベロッパーガイドからスペックを満たしているか確認も可能
• AWSで提供しているデバイス
  • Amazon Monitoron
  • 非常に小さなセンサー
    • 裏側に粘着テープで装置に貼り付けるだけで故障予兆が始められる
    • とても簡単に利用できるため費用対効果が高い
• AWS Panorama
  • 市販のIPカメラつないで作業員を映したり、外観検査のモデルを動かせる
  • まだ日本国内では展開されていません。
• 上記のようなデバイスがない場合
  • データがあれば Amazon Lookout for Equipmentで故障予兆をしたり Lookout for Visionで外観検査ができる

大規模な展開（複数向上への展開など）や障害発生時の復旧に関する課題

• 開発者が何か変更を書けたタイミングで何かが崩れてしまうことは回避したいということがある
  • IaCで構成
  • CDK や CFn など
    • 一度テンプレ化すれば他の工場にも展開しやすい
    • 障害発生時の復旧にも繋がらる
    • なるべく早いタイミングでテンプレ化するのがいい

デバイスの監視・監査を実現する

• 設備側の装置はいくつもあるので、AWS IoT Device managamentで管理
  • デバイスのログ収集、問題箇所を素早く特定
  • 現地に行くのは大変なので、OTAでクラウドからアップデートする
  • スケジュール設定で実行も可能
• AWS IoT Defenderで異常動作をAIで検知
• セキュアトンネリングで設備側のFWの穴を開けずにAWSからアクセス可能
  • デバイス側からトンネルを張る
• Well-Architected FrameworkののIoT版である IoT lensの利用
  • 設計時のベストプラクティスやエッジ側で検討すべきことを参考にできる

データの活用と検討

• まずは小さく始める
• 大きく始めると失敗しやすい
• エッジ側のデータを全部クラウドに上げるのではなく絞ってあげる
• 可視化は一番取り組みやすい
• データが溜まってきたらモデルをつくる
  • 精度が上がってきたらそのモデルをエッジで推論させる
• データが増えると色んなサービスで活用できる
  • AWS IoT SiteWise：ニアリアルタイム
  • Amazon QuickSight：データの粒度でバッチ的な可視化

デジタルツインの可能性

• その場での視認性の向上により問題発生をより早く解決できる
• 現地に行くことがなくなりコスト削減につながる
• 構築が難しい
  • AWS IoT TwinMaker のクッキー工場のサンプルが公開されている
  • ミキサーの回転数や温度が時系列で上がっている（AWS IoT SiteWiseなどを経由）
  • ツインメーカーで受けてGrafanaでダッシュボード化している
  • 3D表現上でどの部分が故障しているのかタグを押すことで確認できる
  • サードパーティとの連携も可能

デジタルツインに置ける4つのレベル

• LV1
  • 物理システムの視覚的な表現
• LV2
  • 現在や過去データの可視化
  • しきい値レベルでの監視
  • 過去データにもとづいた予測は行わない
• LV3
  • 過去データを用いた機械学習モデルで将来予測を行う
• Lv４
  • LV3におけるモデルとの差異が大きくなると自動的に再更新して精度の高い予測を提供

この４つのレベルについては、下記の記事でも分かりやすく解説されていますので、参考にして頂ければと思います。

最後に

スマートファクトリーを実現するにあたり、現状の課題とそれらを解決するAWSサービスやその組み合わせに関する解説から始まり、デバイスの選定方法やクラウドへの取り組み方、デジタルツインといった最近話題となっている分野の紹介など、多角的な視点で幅広いテーマを扱う内容で、スマートファクトリを目指すためのアウトラインを理解できる濃いセッションだったように感じます。

また、セッションで紹介された課題については、私も経験あるものが多かったのですが、逆に見ると多くのケースで同じ課題に突き当たり悩んでいるユーザーの方がまだまだ多いという裏付けでもあると思いました。

このセッションでは具体的なサービスについても紹介され、その中には明日からすぐに取り組めそうなものもありましたので、できる所からスモールスタートで始めてみてはいかがでしょうか？

以上です。