re:Invent 2024: AWSが提案する製造業のIndustrial Data Fabric戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Drive innovation by implementing an industrial data strategy (MFG316)
この動画では、AWSのWorldwide Tech Leader Manufacturingを務めるSteve Blackwell氏が、製造業における産業データ戦略について解説しています。製造業者が抱える複数の基幹システム（CRM、PLM、ERP、MES）からのデータ統合の課題に対し、Industrial Data Fabricフレームワークを用いた解決策を提示しています。データをHot、Warm、Cold（Bronze、Silver、Gold）の3種類に分類し、AWS IoT SiteWise、Amazon Timestream、Amazon RDS、Amazon SageMakerなどの具体的なAWSサービスを活用した実装方法を説明。予知保全や予測品質などの実践的なユースケースを交えながら、製造業におけるデータ活用の全体像を分かりやすく示しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Industrial Data Fabricフレームワーク：製造業のデータ活用への道筋
ご来場ありがとうございます。私はSteve Blackwellと申します。AWSのWorldwide Tech Leader Manufacturingを務めております。Amazonに入社して7年余りになりますが、これまでのキャリアを通じて製造業に携わってきました。まず最初にお詫びしなければならないのですが、2日目にして既に声が枯れかけていまして、少しかすれ声でお聞き苦しいかもしれません。水を用意していますので、少なくとも20分間はお話できると思います。この講演は、明日11時30分にMGMで行われるチョークトーク（MFG 301）の前置きとなるもので、そちらでは産業データの背後にあるアーキテクチャパターンと、それをGenerative AIにどう活用できるかについて、より詳しくお話しする予定です。今回のセッションでは、産業データの捉え方と、その実装戦略について概要をお話ししたいと思います。
製造業を見渡すと、製造業者は複数の基幹システムから膨大なデータを抱えています。営業・顧客の観点からはCRMシステム、製品エンジニアリング設計の観点からはPLM、財務・サプライヤー・購買管理の観点からはERP、そして生産の観点からはMESまたはMOMシステムがあります。さらに、工場のPLCやSCADAシステムから産業IoTデータが生成され、現場で保存されているほか、接続されたデバイスからもIoTデータが入ってきます。これが製造業者が効果的に管理しなければならないデータカオスを生み出しているのです。
私がよく引用するユースケースは、製造業者が品質問題に直面した時のものです。必要なのは単一のデータセットを調べることではなく、複数の異なるデータソースを組み合わせて意味のあるものにすることです。例えば、MESから工場での不適合が特定された場合、産業IoTデータが正確に何が起こったかを教えてくれます。溶接ロボットの不適合であれば、電流や速度のデータが産業IoTデータとして入ってきます。また、その作業を行っていたオペレーターは誰か、使用された材料は何か、部品番号は何かといった情報も必要かもしれません。ここで必要となるのが、これらのシステムオブレコードからのデータを全て管理し、統合して意味のあるものにする産業データ戦略なのです。
意味のあるユースケースについて話すとき、私たちは工場における予知保全、予測品質、状態基準保全に注目しています。製造バリューチェーン全体にわたる産業データの観点から見ると、より多くの製造業者がそのチェーン全体でデータを活用したいと考えていることがわかります。その良い例が、製造業者がConnected Productを持っている場合です。顧客による製品の使用方法や、異常やアラートに関するIoTデータを受け取ります。このConnected Productデータとそれらのデータをエンジニアリング部門に送ることができ、エンジニアが次世代製品の改良に実際のシナリオからの実データを活用できるようになります。同様に、製造業者が新製品を作成し、それを生産に展開したい場合、量産前のMPIサイクルを短縮し、混乱を最小限に抑えたいと考えるため、エンジニアリングから製造へのデータ共有が重要になります。
では、これをどのように実現するのかを見ていきましょう。お客様とお話しする中で、私はAWSのサービス（データベースサービス、ストレージサービス、分析サービス、機械学習サービス）について理解していますが、産業データに関して、お客様が知りたいのは、これらすべてがどのように組み合わさり、これらのユースケースを推進するためにデータをどのように活用できるかということです。そこで私たちは、Industrial Data Fabricフレームワークを開発しました。これは、製造業者がPLC、ERPシステム、PLMなどのシステムオブレコードからデータを取得し、コンテキスト化された形で利用可能にする方法を簡素化するためのアーキテクチャフレームワークであり、ベストプラクティスとアーキテクチャパターンを提供します。場合によってはデータの生産者が消費者にもなり得ますが、このフレームワークにより、製造企業全体でデータをスケールさせることが可能になります。
IDFの4層構造とAWSサービスによる実装：Hot、Warm、Coldデータの管理
IDF frameworkには4つのレイヤーがあります。一番下のレイヤーはIngestで、これは様々なデータソースからデータを取り込む部分です。次のスライドで、異なるタイプのデータについて詳しく説明します。次にStoreがあり、これは取り込んだデータを実際に保存する場所です。データはそのライフサイクルの中で、複数の異なる形式で保存される必要があります。
そして、そのデータをContextualizeする必要があります。冒頭でナレッジグラフと様々なタイプのデータについて話した例に戻りますが、ここでContextualizationが行われます。ここで非性能データとIoTデータ、部品データを関連付けます。そして、そのデータに基づいて行動（Act）する必要があります。例として予知保全を挙げましょう。Amazon SageMakerを使用してモーターやポンプの予知保全のモデルを構築すると、そのモーターが故障することを知らせるJSONファイルがS3 bucketに作成されます。
例えば、保守責任者がS3 bucketに入ってJSONファイルを探すことはありません。彼らは実際に使用できる形式、例えばダッシュボードでその情報を必要としています。しかし、ほとんどの場合、彼らはMROシステムを持っています。そのため、機械学習モデルからの情報が、次の計画停止時に保守エンジニアが保守作業を実行するための作業指示書を保守システムに作成するワークフローをトリガーすることが望ましいのです。このレイヤーは、ビジネスの観点からデータの活用を可能にすることが本当に重要なのです。
より技術的な詳細に入っていきましょう。 IDFの背後には、このIndustrial Data Architectureがあります。産業データについて話す時、私たちには3つのタイプがあります：PLCやデータヒストリアンから来るTime Seriesデータ、MES、PLM、ERP、品質管理システムから来るStructuredデータ、そして動画、画像、Excelファイル、CSVファイル、工場環境から来るその他すべてを含むUnstructuredデータです。これらすべてをAWS cloudに取り込みますが、ユースケースによって、そのデータは異なる方法で使用される可能性があります。
Hot data、Warm data、Cold dataという異なるタイプのデータについて見ていきます。Hot dataは作成時点から、おそらく5分以内のデータです。ユースケースを考えてみてください - 工場のAndonボードや、ロボットや生産ラインから来るアラートを表示する画面があり、オペレーター、ライン管理者、または営業管理者に何かアクションが必要だということを伝えています。その5分が過ぎると、そのデータはもはやHotユースケースには有効ではなくなり、ここでWarm dataになります。これはリアルタイムデータで、製造エンジニアやデータ分析担当者により焦点を当てています。
実際のところ、データの作成から5分後以降、シフト終了時や週末までのデータを見たいというニーズがあります。このデータは依然としてオンラインで利用可能である必要がありますが、SQLクエリを通じてインタラクティブなDashboardからアクセスすることができます。場合によっては、そのTime Seriesデータにどのバッチや生産指示が関連しているかを追加して、データを充実させることもあります。
最後に、データ分析やMachine Learning、BIレポート用のCold dataについてお話しします。Cold dataには、Bronze、Silver、Goldの3種類があります。Bronzeデータは生データで、システム記録やデータソースからAWS Cloud内のData Lakeに取り込んだものですが、変換は一切行っていません。生のフォーマットのまま保存されています。Time SeriesデータやIndustrial IoTデータの場合は、Time Series Databaseに保存します。構造化データの場合は、Relational Databaseに保存します。次にSilverデータですが、これは特定のユースケースや課題に対応するために整理されたデータです。ここで、Low-codeアプリケーションを使用するビジネス部門の担当者や、Data ScientistやData Engineerが予知保全や予測品質の分析を行います。
Machine Learningモデルのトレーニングや分析を行うために、複数の生データボリュームにまたがるデータセットを作成する必要があります。これがSilverデータです。そして最後にGoldデータがあります。予知保全の例に戻ると、保全部門の責任者はS3 Bucketを直接見ることはありません。Machine Learningモデルのトレーニングに使用されたデータセットや推論に使用されたデータにはあまり関心がありません。彼らが欲しいのは、その結果、つまり推論や分析の出力結果です。これがGoldデータです。
Goldデータは、ETLの一部として直接Bronzeデータから来るか、あるいはSilverデータからの出力として得られる、十分に整理されたデータです。Cold data全体の基盤には、Data Catalogがあります。ここで全てのメタデータのカタログを作成し、Bronze、Silver、Goldデータの変換やETLを実行するためのツールを持っています。最初のスライドに戻りますが、ここにKnowledge Graphも存在します。
AWSのサービスの観点からは、これはどのように見えるでしょうか？括弧付きで例示していますが、AWSには200以上のサービスがあり、これを実現する方法は多数存在します。これが唯一の方法というわけではありません。また、これは純粋なAWSの視点であることも指摘しておきたいと思います。私たちにはPartnerも多数います。多くの場合、IDFやこのIndustrial Data Architectureを構築する方法として、私たちのPartnerはここに容易に組み込むことができます。
Hot データについて見てみると、産業用IoTのリアルタイムユースケースに対応するAWS IoT SiteWiseがあります。次にWarmデータについては、AWS IoT SiteWiseに加えて、時系列データ向けのAmazon TimestreamとInfluxを使用したAmazon Timestreamがあります。構造化データにはAmazon RDSがあります。HotデータとWarmデータの領域では、High Bitをはじめとするパートナーがいます。LitmusやSiemensもあります。非構造化データについては、AWS Storage Gatewayがあります。NetAppのようなパートナーがここに加わり、工場現場のデータをColdデータストアにレプリケートする機能を提供しています。
次にColdデータですが、ここではS3の価値が見えてきます。ほとんどの場合、Bronzeデータは S3バケットに保存されます。Silverデータに関しては、データサイエンティストやデータエンジニアが、Amazon SageMakerやAWS Glueなどのツールを使用してS3バケット内でデータセットを作成することが多く、下部に示されているように、多くの場合グラフデータベースを作成します。ここでAmazon Neptuneが活躍します。最後にレポーティング用のGoldデータですが、ここではAmazon Redshiftがあります。ただし、ここでもパートナーがいます。多くのお客様は、GoldデータやSilverデータで、SnowflakeやDatabricksを使用しているかもしれません。
最後に、ありがとうございます。冒頭で申し上げたように、これは明日のセッションの概要説明でした。MGMで11時30分から行われるMFG 301というChalk Talkで、今日お話しした内容についてより詳しく説明させていただきます。さらに詳細なアーキテクチャをお見せし、実際のデモを行って、データソースからデータがHot、Warm、Coldを通じてどのように流れ、最終的にダッシュボードやビジュアライゼーションを通じてどのように消費されるかをお見せします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion