re:Invent 2024: AWSが製造業のデータ活用課題解決策を提示 - IoT SiteWise活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Closing the machine-to-cloud gap to jump-start digital transformation (MFG206)
この動画では、製造業のDigital Transformationにおけるデータ活用の課題と解決策について解説しています。AWS IoT SiteWiseのシニアプロダクトマネージャーであるPradeep Kaushikが、データの収集・整理・分析の重要性を説き、Rehrig Pacific CompanyのBrian Roweが実際の導入事例を共有しています。IDCの調査によると現在1時間で生成されるデータ量は20年前の1年分に匹敵する一方で、68%のデータが未使用のまま破棄されている現状も明らかにされています。さらに、EdgeとCloudの連携、セキュリティ対策、スケーラビリティの確保など、具体的な実装上の課題とその解決策が示され、最新機能としてGenerative AI搭載のアシスタント機能の追加も発表されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Digital Transformationの課題と重要性
みなさん、こんにちは。MFG 206へようこそ。Digital Transformationは必ずしも容易ではなく、データへのアクセスは成功の鍵を握る重要な要素の一つです。このセッションでは、クラウドとエッジの間のデータをどのように橋渡しし、トランスフォーメーションの旅をスムーズに進められるかについてお話しします。多くのお客様やパートナー企業との協業から得た知見を共有させていただきます。私はAmazon Web Servicesのインダストリアルイオットチームでシニアプロダクトマネージャーを務めるPradeep Kaushikです。本日は、Rehrig Pacific CompanyのBrian Roweにもご参加いただき、彼らがこの課題にどのように取り組み、プロセスをよりシームレスにしたかについてお話しいただきます。
Digital Transformationは製造業の業務プロセスを大きく変革しています。私たちが目にしている包括的なトレンドは、データがあらゆる進化するプロセスの一部となっており、生成されるデータの量と規模が非常に大きいということです。これは、エンジニアリングや設計機能、Smart Factory、スマートプロダクト・サービスのいずれにおいても同様です。それぞれのプロセスには、そこに含まれる情報やデータによって達成できる独自の価値創造の道筋があります。Smart Factoryを例に取ると、生成されるデータ量は膨大ですが、価値創造の取り組みが始まらなければ、そのほとんどが適切に活用されません。Smart Factoryの良い例として、設備の稼働状況やダウンタイムなどの機械情報を見ることで、プロセスの最適化につながるより深い洞察を得ることができます。
スマートプロダクトやサービスの場合も同様の課題があります。販売した機械のライフサイクル管理を改善し、エンドユーザーに提供できるSLAを向上させる必要があります。エンジニアリングと設計においては、お客様が扱う製品バリエーションの数が膨大です。現在の運用状況、機械の状態、制約条件を考慮した反復的な設計プロセスを実現する必要があります。これらはすべてDigital Transformationの重要な要素となっています。
データ駆動型戦略の構築と価値創造の加速
様々なお客様との協業経験から学んだ重要なポイントの一つは、この旅がデータという基盤レベルから始まるということです。収集したデータと異なるワークフローを連携させ始めると、価値が加速度的に高まっていきます。Smart Factoryを例に挙げると、設備をパフォーマンスと可用性を監視できるアプリケーションに接続することで、設備の可用性を理解することができます。異常検知や予測機能などの機能を統合することで、OEEという指標を超えて、実際にそれを改善するチャンスが生まれます。これらの機能の改善に取り組むことで、品質と歩留まりを向上させる機会が生まれ、Smart Factoryのユースケースにおける価値のフライホイールが回り始めます。
同様に、先ほど議論したスマートプロダクトにおいても、データが利用可能になると価値創造の旅が加速します。これには、販売済み機械のライフサイクル管理の改善やセキュリティと脆弱性評価の強化が含まれます。動的な条件が変化し続ける中で、全体的な改善を行うことができ、それが顧客満足度とロイヤリティの向上につながります。価値創造の旅は進化し、より大きな成果を得ることができます。これはエンジニアリングと設計フェーズにも当てはまります。
興味深いのは、これらの特定の機能に限定されないということです。価値の旅は、これらの機能を統合的に見始めたときに大きく広がります。これこそがデジタルトランスフォーメーションの真の基盤なのです。Smart Factoryにおける資産の最適化と品質向上のための努力と投資は、実際には製品戦略においてより大きな価値をもたらします。例えば、機械メーカーであれば、実際に販売された機械から得られた改善点やデータに基づいて、機械製造プロセスを最適化できます。これらの情報はすべて設計改善プロセスにも役立ちます。多数のSKUを扱い、新しいバリエーションを作る必要がある場合は、製造施設の制約を考慮して設計を最適化し、さらなる価値の創出を加速させることができます。これこそが、デジタルトランスフォーメーションが実現できるフライホイールなのです。
では、なぜこれが重要なのでしょうか？今日の運用システムにおけるあらゆるやり取り、PLCが機械や設備と通信する場合でも、人間がシステムと対話する場合でも、大量のデータが生成されています。IDCの調査によると、現在では1時間で生成されるデータ量は、20年前の1年分に匹敵するほどです。これは膨大な量です。残念ながら、データの大部分は未使用で、68%のデータは収集されても破棄されているのが現状です。残りのデータについても、統合された運用プロセスがなければ、そのすべてを活用することは非常に困難で、その情報から得られる価値を失ってしまいます。
これがなぜ重要かというと、トランスフォーメーションを加速し、運用とプロセスにより大きな価値を生み出すことができるからです。Forresterの調査によると、データから得られたインサイトを活用して業務を行っている企業は、収益予測を改善する可能性が8.5倍も高くなります。これは大きな機会であり、多くの顧客が段階的に取り組もうとしている分野です。
モダンなIndustrial Data Strategyの必要性
データ駆動型戦略を構築する最初のステップは、 実際には資産の可視化とデータの収集・整理です。一見シンプルに思えますが、実際にはそうではありません。 過去5-6年間の多くの顧客とのやり取りを通じて、私たちは繰り返し発生するいくつかの課題を見出してきました。これらの課題は、特定のユースケースだけに限らず発生します。1つの資産を監視するだけなら統合は簡単に見えるかもしれませんが、複数の資産に拡張すると、より困難になってきます。
最終的な状態から逆算して考えると、データ変革の過程には5つの重要な課題があります。その最初の摩擦ポイントがデータ統合です。最初の障壁は、施設内のデバイスやハードウェアを統合する際に発生します。過去数十年存在してきた自動化システムは今では「Legacy」と呼ばれていますが、技術の進化により、最新のテクノロジースタックでの取り込みが非常に困難になっています。多くのプロトコルや様々な種類のセカンダリーセンサーが存在し、さらにデータも異なるフォーマットで存在し、マシンがまだファイルでデータを保持している状況では、データ統合は困難を極めます。
単一のアセットクラスだけでなく、様々なアセットを扱う場合はさらに課題が増えます。異なるプロトコルや異なる種類のセカンダリーセンサーを必要とする、様々なアセットクラスをサポートできるシステムが必要になります。また、データを情報に変換してユーザーにフィードバックし、即座にアクションを取れるようにするリアルタイムの意思決定も重要です。これにはEdgeとCloudの両方でインテリジェンスが必要で、ライフサイクル全体を完結させる必要があります。
データコンテキストは過小評価されがちですが、最終的には大きな問題領域となります。適切なコンテキストがなければ、データは情報になりません。情報とは、アセット階層や工場内での位置だけでなく、関係性についても重要です。このアセットが故障したらどうなるのか？どのようなボトルネックが生じるのか？フィードフォワードやフィードバックのシナリオはどうなるのか？これらのことは時としてモデル化が難しく、特別な種類のデータコンテキスト化が必要です。多くのユースケースでは、EdgeでのOperationsが重要であり、多くの場合EdgeとCloudの機能の組み合わせが必要となります。
最後に、スケーリングが大きな問題となります。多くのパイロットプロジェクトが永遠にパイロット段階にとどまってしまう原因となっています。1つのアセットやアセットクラスではうまく機能しても、別のアセットクラスやバリエーションに拡張しようとすると、大規模な再作業が必要になるためです。これにより、展開されるはずだったものが中断し、「Pilot Purgatory」に陥ってしまいます。 これらすべての課題に対して、モダンなIndustrial Data Strategyを定義する必要があります。これを考える際、単にデータをどのように収集し整理するかだけでなく、データを有用なものにするという観点からモダンなIndustrial Data Strategyを考える必要があります。
モダンなIndustrial Data Strategyは、収集・整理できたデータや情報を、異なるアプリケーションやユースケースで相互運用可能にします。今日アセット監視のユースケースがあり、明日予知保全のユースケースを構築したい場合でも、これまでの取り組みを再利用できるようにすべきです。これこそがモダンなIndustrial Data Strategyが目指す方向性であり、データの収集と整理に費やした労力が、そのデータを必要とするアプリケーションにとって透過的になります。アプリケーションはデータがどのプロトコルから来たのか、どのような形状や形式だったのかを気にする必要がなく、一対一の多点統合シナリオに対処するのではなく、価値を創造することに集中できます。
AWS レベルでのお客様のトランスフォーメーションにおけるこれらの課題を見ると、私たちは特に最初のステージ、つまりデータの収集、整理、分析をより簡単にする方法に焦点を当てました。ここで AWS IoT SiteWise は、パートナーエコシステムを通じて様々なプロトコルからデータを簡単に収集することに重点を置いた、私たちのプレミアム産業向けサービスの1つとなっています。数百のプロトコルと何千もの二次センサーをサポートしており、簡単に統合することができます。データを取り込んだ後は、階層的な関係性で整理するメカニズムがあります。より硬直的なI95モデルや構造を超えて、文脈に応じた関係性を作ることができます。その後、システム内で直接、あるいは他の手段を通じて、お好みの方法でユーザーにその情報を提示することを容易にし、また他の分析機能との統合も簡単に行えるようにしています。これらの機能がすべて単一のプラットフォームで実現されるとは考えていませんが、適切なデータ戦略として、これらの機能すべてを実現できる適切なデータ基盤を確保したいと考えています。
AWS IoT SiteWiseによるデータ収集と整理の簡素化
すべては資産の接続から始まり、先ほど議論したように、これがプロセスの最初の障壁となります。私たちはこのプロセスを簡単にすることに特に注意を払ってきました。これは、クラウドとエンタープライズの間のギャップを埋める最初のステップであり、エンタープライズアプリケーションやビジネスプロセスレベルのインテリジェントアプリケーションが、エッジで収集されているものの現在は使用できていないすべてのデータを真に活用できるようにするものです。この場合、機械の接続性について話していますが、これは多数のPLC、プロトコル、Modbus、OPC UAに依存しています。ここで私たちは、Belden、LITMUS、Easy Edgeのようなパートナーと協力して、一方でプロトコルのサポートを、もう一方で二次センサーのサポートを提供しています。今日PCでさえない IoTセンサーであっても、データオーケストレーションに取り込んで作業することができ、スマートマシンも含まれます。マシンがすでにスマートでクラウド接続用に設計されている場合は、MQTT ベースの情報もクラウドにすぐに取り込むことができます。
このように、私たちはこれらすべてのモデルをサポートしており、ここでBrianを紹介したいと思います。Brianは、同じデータ戦略を使用して、いかにシンプルでスケーラブルにするかという課題に取り組んできた、私たちのライフパートナーであり顧客の一人です。Brian、ありがとう Pradeep。私はBrian Roweで、Rehrig Pacific Companyの IT Vice Presidentを務めています。IT全般に責任を持ち、サイバーセキュリティも監督し、組織のDigital Transformationを導く責任も担っています。消費者向けブランドではない企業の従業員として慣れていることですが、初めて誰かに自分の勤務先を告げると、「えっ、何？誰？どう発音するの？」と聞かれます。そこで、Rehrig Pacificとは何か、何をする会社なのかを理解していただくために、マーケティングチームの友人たちが作成したビデオをご覧いただきたいと思います。
Rehrig Pacificは、世界がどうあるべきかを想像し、そこに到達するためのものを作る革新者たちの会社です。私と私のクルーにとって、私たちを止められるものは何もありません。私たちは自分たちのすることを100%やり遂げます。 私たちのロジスティクスソリューション事業は、パートナーが循環型システムを構築するのを支援する持続可能なイノベーションを提供することで、サプライチェーンと廃棄物産業を強化しています。 私たちのデリバリーソリューション事業は、画期的な物流処理と技術的ソリューションを通じて、倉庫から店舗の棚に至るまでの直接店舗配送を革新しています。 私たちは、リサイクルが困難なプラスチックの新しい使用方法を見出すことに専念する北米全域の8つの工場を持つ、環境に配慮した製造業者です。 私たちは、システムが互いにどのように連携するかを再考し、統合された製品エコシステムを創造するデザイナーとエンジニアです。
これらの統合された製品エコシステムは、将来それらが活用される産業に実質的な価値を付加します。私たちは、パートナーのチームの価値ある一員として、 顧客体験の向上に焦点を当てた最高水準のサービスプロバイダーです。より多様な視点がより良い結果をもたらすという信念のもと、より強固で包括的な企業を構築するため、常に内部を見つめ直しています。なぜなら、最終的に内側から優れたビジネスを構築することは、私たち互いのためのより良い生活様式を構築することを意味するからです。
Rehrig Pacificは、社員を大切にし、物資やリソース、アイデアを効果的かつ責任を持って動かすための革新的なソリューションを生み出す力を与える、家族のような企業です。私たちRehrig Pacificは、創業111年の歴史を持つ家族経営の製造会社であり、その歴史全体を通じてサプライチェーンの効率化を推進するためのコンテナを生産してきました。過去15〜20年の間に、私たちはテクノロジープロバイダーとしても成長してきました。SaaSアプリケーションを構築し、お客様のサプライチェーンでプラスチックコンテナを移動させるためのマテリアルハンドリングソリューションを提供しています。
Rehrig Pacific CompanyのBrian Roweが語るデジタル変革の実例
その一環として、私たちは信頼できるアドバイザーとしてお客様と多くの時間を共に過ごし、課題がどこにあるのか、そしてプロセスのどの要素が先進技術とデータ駆動型の意思決定によって最適化できる可能性があるのかを特定するお手伝いをしています。数年前、私たちは一歩下がって、自社の事業運営に対しても同じレベルの批判的な視点と信頼できるアドバイザーとしての姿勢を持ち込んでいるかどうか、正直に自己反省する機会を持ちました。これは、Rehrigが自らデジタル時代に確実に踏み出すために何が必要かを問うことから始まりました。
製造業者である私たちに対する多くのお客様の期待は変化しています。私たちはこれを検討し、お客様に提供できることは品質の向上と製造の柔軟性の向上であり、それによってより機敏で俊敏になり、お客様のニーズにより迅速に対応できるようになると考えました。そのためには、製造オペレーションについて非常に異なる考え方をする必要がありました。ご覧いただいたように、私たちが生産するコンテナの種類は多岐にわたり、収益ポートフォリオの中核となる最大のコンポーネントはプラスチック製品の生産です。
私たちはIT部門の私と、先進製造を監督する変革組織の同僚との間でコアチームを結成しました。そして、運営部門の主要なステークホルダーを招き入れ、AWSと私たちのパートナーの一つであるSlalomとともに、私たちの現状と検討すべき事項について詳しく分析を始めました。興味深いことに、私は私たちのことを見つけられる限り最もブラウンフィールドな環境と呼ぶようになりました。そこから3つの大きな発見が浮かび上がってきました。振り返ってみると、これらはすべて比較的明白なことでしたが、私たちはそれらを文書化し、対処すべき課題として認識する時間を取っていませんでした。
最初の発見は、製造現場に多くのスマートデバイスが存在していたということです。2018年以降の労働力不足の時期を通じて、現場スタッフを見つけることができない作業を行うためにCobotへの投資を余儀なくされました。多くの先進的なテクノロジーを持っていましたが、それらはすべて独立して動作していました。企業のセキュリティ責任者として、私はそのことに実は感謝していました - それらの多くはパッチが当てられておらず、非常に脆弱で、製造現場に置かれていましたが、少なくともそれぞれが独立していたからです。しかし、これは実際には大きな問題を表していました。つまり、何か変更を加える際には、すべて手作業で行う必要があり、ワークセンターでの変更を実施するために環境内の多くのものに触れなければならなかったのです。
2番目の課題は、レガシーな技術が数多く存在していたことです。古い企業であることを考えれば、一見当然のことかもしれません。しかし、最も古い製造施設が52年間継続して稼働している一方で、最新の施設はわずか3ヶ月前に稼働を開始したばかりだということに気づきました。この問題を深く掘り下げていく中で、これは設備や機械の世代間における能力の違いという意味で、どれほど大きな課題であるかお分かりいただけるでしょう。最後の点として、私たちは製造業として、単位あたりの利益率が比較的高い自動車やマイクロチップを生産しているわけではないという事実について、真剣に考える必要がありました。
そこで、工場内の設備を大規模に入れ替えることなく（実際のところ、そのような余裕はありませんでした）、価値に基づいたユースケースに応じて拡張可能で、柔軟性のある解決策を考え始めました。その結果、76のワークセンターを対象とする明確な範囲を設定しました。私たちにとってワークセンターとは、少なくとも1台の射出成形機と、製品の装飾、組立、パレタイズに必要な付帯設備で構成されています。また、主に2社から供給された5世代にわたる射出成形機があることも特定しました。
Rehrig Pacific Companyのデジタル変革：課題と成果
7つの主要施設全体で、環境内に125台のロボットが存在していました。実際に数え始めてみると、この数字は驚くべきものでした。誰かが「どうして100台以上になったのか」と尋ねましたが、これは時間とともに1台ずつ増えていき、気づいたら大規模なロボット群となっていたのです。また、7台のホットプレート溶接機がありました。射出成形に馴染みのない方にはなじみがないかもしれませんが、私たちは多くのプラスチックパレットを生産しており、構造的な完全性を確保するために、実際には上部とベースの2つのパーツで成形し、それらをホットプレート溶接機で溶接して、パレットの寿命に必要な構造的剛性を得ています。
10種類の異なる材料ブレンドシステムがあることも分かりました。つまり、射出成形機に原材料を供給するツールが、実際の稼働施設の数を上回っていたのです。また、約300台のPLCがあることも判明し、ブランドの簡単な調査では、少なくとも7つのロゴが確認され、その中には既に廃業している企業もありました。これらのPLCの中には、工場で実に20年近く稼働し続けているものもありました。この問題の範囲を明確にし、対応すべきプロトコルの数や、触れる必要のある機器の数を考え始めた時、すべてを完全にやり直すことなく、工場をデータ駆動型の製造オペレーションへと意味のある形で接続するために、どのような柔軟性を持った解決策が必要かを決定しなければなりませんでした。
慎重な検討の末、私たちは3つの原則に基づく前提に立ち返りました。1つ目は、包括的なフレームワークが必要だということです。私たちの目標は、エッジに配置するコンポーネントの数を最小限に抑えながら、工場内の最大限の機器と通信し、そのデータをネイティブなクラウド接続を通じてコンテキスト化、デジタル化し、データレイクに保存することでした。2つ目の原則として、組織のセキュリティ担当者として、データとネットワークのセキュリティを導入するあらゆるソリューションの中核に据える必要がありました。
これらのデバイスに対処する必要がありました。中にはメーカーの設計上、非常に脆弱性の高いものもありました。多くのOTベンダーではあまりサポートされていないマイクロセグメンテーションにも対応する必要がありました。また、これらの技術には、ロールベースのアクセス制御やマルチファクター認証といった基本的な機能が備わっていないことも考慮しなければなりませんでした。それでも、組織の他の部分にリスクを及ぼすことなく、これらのデバイスに安全に接続し、製造プロセスの機密情報が組織外に漏れないように保護しながら、エッジからクラウドまでのデータを確実に保護する必要がありました。
最後に、そして恐らく最も重要なことですが、データの自由度を高く保ちたいと考えていました。OTベンダーの方々には申し訳ありませんが、私たちが使用している25～30のサプライヤーを調査すると、間違いなく全てのベンダーが、自社ロゴの付いた製品だけで工場を構成した場合に最適に動作する接続ソリューションを持っています。しかし、それではサイロ化を助長するだけで、単に工場の現場からクラウドにサイロを移動させるだけになってしまいます。私たちの目標は、そうしたサイロを作り直すことを避け、代わりにブランドやプロトコルに依存しないエッジソリューションを用意し、データを収集、コンテキスト化して1つの場所にプッシュすることでした。
その1つの場所が、ERPやMESなどのエンタープライズシステムへの北向きのデータや、それらのエンタープライズシステムでまだカバーされていないユースケースを素早く解決できるAmazon Managed Service for Grafanaなどの他のAWSサービスのためのクリアリングハウスとなります。 この図の技術的なバージョンは持ってきていませんが、後ほど詳細についてお話しできます。左側から見ていくと、これらは工場の現場にある実際の物理的なものです。まず射出成形機から始めることにしましたが、これは様々なバリエーションが存在するため、複雑な決断でした。綿密な調査の結果、EuroMap63という古いバージョンのプロトコルを活用することで最適なポイントを見つけることができました。このプロトコルは、他のどのプロトコルよりも多くの機器をカバーできたのです。
そこから、1セットのタグテンプレートと1つの技術で、私たちの機器の大部分を接続することができました。次にPLCとロボットに移り、OPC UAや場合によってはMQTTを介してデータを取得しました。これらは、Belden Horizon Data Operationsプラットフォームを通じて接続された、ネイティブなインテリジェンスまたはネイティブな接続性を持つデバイス層を表しています。
Belden Horizon Data Operationsプラットフォームは異なる層で動作します。下位層のカテゴリーでは、ネイティブなインテリジェンスを持たないデバイスやシステムを補強する必要があります。メーカーとして異なるプロトコルを使用するため分けられた、2つの主要なユースケースを実装しています。ご存知の方も多いと思いますが、私たちは常にサステナビリティ目標の達成と効率性の向上を追求しています。Modbus TCPでCloudRAILに接続するセンサーを使用して、電力使用量をモニタリングするプログラムを開始しました。
私たちのセカンダリーセンシング構造の残りの部分は、OPC UA/MQTTをベースにしています。これは、以前はスタッフが施設内を歩き回って、アナログの圧力・温度センサーを手動でチェックしていた領域を、完全に置き換えた部分です。これらのセンサーをCloudRAILに接続可能なデジタル版に置き換えました。これらのツールはどちらもAWS IoT SiteWiseとのネイティブ統合を備えており、すべてのデータが一箇所に集約され、OTエンジニアが特定のデータ要素を簡単に見つけられるよう、人が読みやすい名前空間と階層構造の中で整理されています。
先ほど触れたように、まず私たちはAmazon Managed Service for Grafanaのネイティブ統合を活用し、エンジニア向けのリアルタイムに近い可視化の構築を始めました。ある程度の労力は必要でしたが、システムを稼働させ、エンジニアがデータを可視化に接続して自立的に作業できるようになるまでは比較的スムーズでした。これにより、アラートの設定やアセットのリアルタイム監視が可能になりました。その後、別個のヒストリアンを持つのではなく、その情報をMESに転送し始めました。私たちが取り組んでいた課題の一つは、高可用性サポートを必要としながらも、エッジコンポーネントを最小限に抑えることでした。
エッジ処理のソリューションを検討し始めた時、OpenShift上でのコンテナでのデプロイメントとポータビリティの確保に関して課題に直面しました。幸いなことに、パートナーであるBeldenが既にこの目的のためのコンテナバージョンを設計していました。また、より深い分析のためにサンプリングされたデータをAmazon Redshiftに取り込むデータインフラも構築しました。すべてのデータを保持しているわけではありませんが、必要に応じてデータ保持とメトリクスを調整できる柔軟性があります。現在、完全に稼働している工場はまだ数か所のみで、人材育成計画を通じて、価値のある意味のあるデータを見極める専門知識をまだ開発している段階です。
このシステムは複数の施設で稼働しており、Kansas工場が私たちのフラッグシップ施設として、関連機器の100%がオンラインになっています。 これは、ITやパートナーではなく、オペレーションチーム自身が作成したダッシュボードの一例です。信頼性担当者、保守担当者、生産スーパーバイザーが協力して、意味のあるプロセスパラメータとその表示方法を決定しました。ITリーダーとして、私は頻繁にスタッフと、過去20年間にITが製造業から学んだことについて話し合います。特に「The Phoenix Project」からの概念、つまり工場のように仕事を考え、ボトルネックを特定し、プロセスに効率性を組み込むことについてです。
私たちは、ITがリアルタイムに近い可視化の専門知識をもたらしていることについて、オペレーションの同僚たちと話し合ってきました。展示会場には、ハードディスクが満杯になりそうな時期を予測し、自動的にメンテナンスチケットを生成するなど、この機能に特化したベンダーが多数います。製造チームは以前このような機能を持っていませんでしたが、今では持っており、その価値をすぐに理解しました。アラートのしきい値は現在、作業指示パラメータ、サイクルタイム、材料ミックス情報に基づいて動的に設定されています。
製造現場の監督者は、作業指示のパラメータ、サイクルタイム、材料の配合を確認するために個々のHMIを物理的にチェックする必要がなくなりました。アラートが来なければ正しく実行されたということであり、アラートが来た場合は何に対処する必要があるのかを正確に把握でき、素早く対応できます。Rehrig の今後について考え、これまでの成果について話すと、先ほど述べたプロセスパラメータ制御は、すでに製品品質全体に大きな影響を与えています。
7年前にこの役職に就いてから、プラスチック製造について奇妙なことを学びました。95ガロンのロールアウトカートの金型でサイクルタイムを延長すると、96ガロンのロールアウトカートができるのです。私にとっては金型は何をしても同じサイズのはずだと思っていましたが、実際にはそうではありませんでした。サイクルタイムの仕組みを理解することは非常に重要です。なぜなら、それによって製品が規格外になる可能性があり、お客様の中にはプラスチック容器を自社の自動化システムで使用する高い要求を持つところもあるため、規格外の製品が届くと深刻な問題を引き起こす可能性があるからです。
次の3つは、現在ラボで実験中か、開発計画を立て始めているものです。私たちはData Lakeを構築しており、ライン比較に関する基本的な検討を始めています。異なる施設で同じ製品を製造しているワークセンターがある場合、それらを並べて比較し、どこが異なるのか、プロセスパラメータがどう違うのか、アウトプットやスループットがどう違うのか、場合によっては電力使用量がどう違うのかを理解するのに十分なデータが得られるようになりました。以前はデータが不足していて、エンジニアたちは逸話的な議論しかできませんでしたが、今ではData Lakeのデータに基づいて議論を進めています。
また、予知保全と信頼性向上の機会も評価しています。これらの射出成形機には大規模な油圧システムがあり、セミトラックほどの大きさの機械全体に油圧作動油が循環している状態で、インペラーが破損するような致命的なポンプの故障が起きると、真鍮の破片を取り除くために数日かけて全ての作動油をろ過し直す必要があります。現在は、同じデータインフラストラクチャを活用して振動データを取得し、POCを通じて高度な振動分析を行うことで、致命的な故障を防げないか検証しています。部品さえあれば、事前に把握できれば2時間の予防保全で済むものが、致命的な故障を起こすと4日かかってしまいます。
さらに、デジタルワークセルオーケストレーションのプロトタイプも作成しています。このデータの分析を始めたことで、これまでエンタープライズデータソースにアクセスできないアナログシステムに制約されていた工場のエンジニアたちの発想が広がりました。私たちのチームがAWSで作成したマイクロサービスは、すでにERPシステムから作業指示データを抽出していました。現在、ラボではそのデータをMQTTにプッシュして、PLCプログラムがその情報にアクセスできるようにしています。例えば、私たちは作業指示ごとに色やブランディングが異なる多くのロールアウトカートを製造していますが、これによりPLCが自動的に実行中の作業指示と使用すべき色をチェックし、レーザーカラーセンサーで正しい色であり規格内であることを確認できるようになります。
デジタルトランスフォーメーションの段階的アプローチと成功事例
私たちが期待していた重要な要素の1つは、必ずしも予想していなかったものですが、工場の各要素を接続し、プラントエンジニアリングチームにデジタルの視点で考えることを促すことで、彼らが製造現場のプロセスを標準化し、再構築する新しい革新的な方法を見出していることです。本日はお時間をいただき、ありがとうございました。ここでPradeepに戻して、会話を締めくくりたいと思います。Brian、あなたの経験を共有していただき、ありがとうございます。新しいアセットクラスに対応する際も、将来を見据えたアーキテクチャを最初から考えて構築されたというのは、とても興味深い点でした。
市場調査と顧客からのフィードバックを見ると、私たちが対話や交流を持った顧客の約70%が、すでにデジタルトランスフォーメーションに向けた取り組みを開始しているか、1年以内に開始を予定していることがわかりました。これは、デジタルトランスフォーメーションの重要性が広く認識されている良い兆候です。すでにこの journey を開始している顧客の中で、当初の目標に対する進捗に満足していると感じているのは約30%にとどまっています。また、これらの顧客の約40%が、開始はしたものの適切な価値を得られず、明確な方向性のないまま次のフェーズに移行している状態で行き詰まっていると感じていることもわかりました。
考えてみると、デジタルトランスフォーメーションはデータの収集と保存だけにとどまりません。トランスフォーメーションのプロセスにリスクをもたらし、目標達成の妨げとなる要素は他にもたくさんあります。システム全体を再設計する際には、重要な疑問が生じます。この journey を始めるにあたって答えなければならない根本的な問いは、「デジタルとは何か？」ということです。 デジタルとは、単にすべてのデータを持っていたり、それを計算、変換、分析できることだけを指すのではありません。本来の意味でのデジタルは、価値を高めるための enabler なのです。先ほど説明したフライホイールは、データが適切な形状、形式、サイズで、データ駆動の意思決定とグローバルな可用性を実現できるような相互運用性を持っている場合に機能します。
ある拠点から別の拠点に移動する際には、それらの成果を迅速に実装できるようにする必要があります。グローバルな接続性が必要で、後付けではなく、最初からサイバーセキュリティのニーズと進化する脅威を考慮に入れる必要があります。また、スケールアップのたびにアーキテクチャ全体を再構築する必要がなく、各工場が独自のスタックを持つ新規デプロイメントになることを避けられるような持続可能性も確保する必要があります。さらに、ユーザーがデータと対話し、恩恵を受け、スキル向上に活用できるような形でデータを提供する、人間中心のアプローチも維持する必要があります。顧客とデジタルトランスフォーメーションについて議論する際、私たちは短期、中期、長期的に望ましい価値を達成するために不可欠なこれらの機能すべてをサポートできるファブリックを思い描いています。
デジタル成熟度の観点から見ると、 今日多くの顧客は、まだ従来型の製造段階にいると考えています。この段階では、設備やプロセス、サブアセンブリライン、機械がサイロ化しており、個々にはスマートでHMI接続を持っているものの、相乗的な価値創造を加速するために相互に接続することができません。これらの要素をワークフローでつなぎ、施設全体でのアセットの可視化や、そのレベルでの最適化といった、より統合的なユースケースを構築し始めると、Connected Manufacturing に近づいていきます。製造の様々な側面や機能が、それぞれが生成する情報をリアルタイムで活用し、それに応じて対応できるようになるのです。
プロセスにボトルネックが発生するリスクがあることに気付いた場合、後続のプロセスがそれを認識し、対策プロセスを開始できるため、ライフサイクル全体が手動ではなく、クローズドループとなります。これは Connected Manufacturing の一例ですが、本格的なソフトウェア駆動の自動化というビジョンに高めると、ほとんどのプロセスがデータファブリックレイヤーで相互接続され、大部分のワークフローが自動化されます。人間はまだ機能的な役割を果たしていますが、すべてのステップで介入する必要はありません。究極的な目標である Lights-out Automation では、人間の介入が不要になります。ただし、これを最初の目標にする必要はありません。もし始めたばかりであれば、まずは従来型の製造からスタートし、異なるアセットや機器が相互に連携できる Connected Manufacturing を目指すことが良い第一歩となります。 先ほど議論したように、成功するデジタルトランスフォーメーションはデータだけの問題ではありません。また、私たちのプラットフォームである AWS IoT SiteWise が、産業データの収集を容易にし、さまざまなプロトコルをサポートし、情報の整理を支援する方法についても説明しました。
デジタルジャーニーを実現するためには、サイバーセキュリティなど、他の側面もカバーする必要があります。分析をデータポイントやユーザーにとって簡単でアクセスしやすいものにする方法にも取り組む必要があります。また、ERPやMESなど、お客様が持つさまざまなパートナーシステムが同じデータファブリックの一部となれるようにしたいと考えています。
AWSレベルでは、さまざまなコンポーネントとサービスが利用可能な、より広範なアーキテクチャビジョンとして考えています。すべてを一度に始める必要はありませんが、必要なときに利用できる状態にあります。これこそが Pilot Purgatory から脱却するという考え方の本質です。より広範なアーキテクチャの中で、非常にシンプルに始められるからです。アセット監視のユースケースであれば、AWS IoT SiteWise を使って、さまざまなアセットからデータを収集し、整理し、可視化するだけでシンプルに始められます。一部のアセットに予知保全を追加したい場合や、機械学習モデルを構築する専門チームがある場合、すべての取り組みを再利用可能にできます。SageMaker サービスを使用してそのMLモデルを接続し、SiteWise がアセット監視を行っていた同じアプリケーションダッシュボードに統合できるワークフローの一部にすることができます。
先ほどのスライドで示した大きなアーキテクチャについて話すと、「これら全部が必要で、これは大変だ」と考えてしまうかもしれません。私はいつも、特定のユースケースに戦略の軸を置くことをお勧めしています。そして、非常にシンプルなところから始めることができます。重要なのは何を完了するかではなく、どのように完了し、提供するかです。アセット監視は、アセットの接続を中心とした単純なユースケースです。最初は1台の機械をOPC UAで接続し、データを整理し、階層と知識を作成し、ダッシュボードで可視化することから始めるかもしれません。OPC UAをサポートしていない、または異なるレイテンシー要件を持つ別の機械を追加したい場合や、より多くのセカンダリセンサーを追加したい場合でも、アーキテクチャは最初のワークフローを変更することなく、それらすべてを統合できるようにする必要があります。
予知保全は別の重要なユースケースであり、多くのお客様が単なる監視を超えてアセットを最適化するためにバリューチェーンを見つめているのを目にします。同じアセット監視インフラを使用し、分析ワークフローに接続できることが重要です。SiteWise のようなプラットフォーム内にある機能もありますが、トランスフォーメーションの目標を達成するために、意思決定モデルやパートナーモデルを導入することでさらなる可能性が広がります。グローバルな地域にまたがる施設の企業レベルの可視性も同様に重要で、同じインフラを使用しながら比較することができます。企業の可視性から始める場合は、将来的に予知保全にスケールできるアーキテクチャを考えることが重要です。
Predictive Qualityも重要なユースケースの1つです。多くのお客様が、数日から数週間かかるバッチプロセスの最適化に注目しています。プロセスの変更に基づいて品質を予測したいというニーズがあり、そこではシミュレーションと基本的なMachine Learningの分析の両方が関係してきます。目標は、これらのワークフローを同じアーキテクチャに統合し、現在の状態に基づいたWhat-if分析を可能にすることです。これらのユースケースのどれから始めても構いませんが、次のステップへと進化できるように構築することが、スケーラブルなデータプラットフォームビジョンの基礎となります。これは単なる理論ではありません - お客様のニーズに応じてデータプラットフォームアーキテクチャにこれらのコンポーネントを段階的に追加してきた経験から得られた知見であり、今では最初の段階で話し合うべき重要なポイントとなっています。ここで、当社のプレミアムカスタマーの事例をご紹介させていただきます。
AWS IoT SiteWiseの新機能と今後のデジタルトランスフォーメーションの展望
このお客様は、アセットを最適化してダウンタイムを削減するというビジョンからスタートしました。スケーラブルなアーキテクチャを構築するという慎重なアプローチを取り、最初の成功したデプロイメントでは、異常の検出と故障リスクの予測に焦点を当てました。初期テストでは16件のインシデントを追跡し、テスト検証期間中だけでも20時間のダウンタイムを削減し、8万ドルのコスト削減を実現しました。この成果は、このような基盤を構築することで、迅速にテストし、効果的にスケールできることを示しています。
現在、彼らは同じワークフローを非常に短期間で100以上のアセットにスケールアップしています。アセットは完全に同じではなく、異なる種類のデータやプロトコルが必要ですが、同じアーキテクチャパターンを使用することで、これらのアセットクラス全体に予知保全機能を素早く展開することができました。FRONTMATECは、機械に焦点を当てている別のお客様です。彼らはスマートプロダクト戦略の観点からアプローチし、1つの顧客から複数のユーザーへと機械をスケールする際に、デプロイメントをより迅速かつ高機能にする方法を検討しました。同じアーキテクチャパターンを使用することで、デプロイメント時間を数時間から15分に短縮することができました。
この効率性は、レイヤー化されたアプローチによって実現されています。プロトコル変換が1つのレイヤー、データ編成が別のレイヤー、データ変換がさらに別のレイヤーというように構成されています。このテンプレート化されたアプローチにより、新しいアセットを導入する際のプロセスが容易になります。既に実装済みの部分との共通点が70-80%あり、わずかな変更だけで済むのです。これにより、アセットが変更された際のスケーリング方法が大きく変わります。Yaraは、作物栄養素と化学プロセスの分野における素晴らしい事例のもう1つです。彼らは慎重なアプローチを取り、実証実験から始めて、デジタルプロダクションプラットフォーム戦略として考えることを決定しました。この戦略が1つのユースケースに限定されず、同じプラットフォーム上で複数のユースケースをサポートできることを確認したかったのです。このアーキテクチャを基盤とした共通基盤を使用して、100以上のプラントで13万のインダストリアルアセットをデプロイしています。
最後に、現在協業している欧州の特殊鋼メーカーであるEfasteelについてお話ししたいと思います。彼らは炉の監視、最適化、そして炉のプロセスが進化する中で作業員にガイダンスを提供したいという思いから始まりました。彼らの目標は、作業員の仕事を楽にし、アセットのパフォーマンスを向上させ、そこからスケールすることでした。また、日々の業務をサポートするためにAI技術のメリットを作業員にもたらすことにも関心がありました。私たちは彼らと協力し、AWS IoT SiteWiseに新機能として、Generative AI搭載のアシスタントをSiteWiseにネイティブに組み込むことを発表できることを嬉しく思います。
これは、AWS IoT SiteWiseが現在、生成AIを活用したアシスタントを搭載していることを意味します。このアシスタントは、Asset Modelを理解し、アセット内の現在および過去のデータを把握し、確立された関係性を理解し、さらにSOPや製品マニュアル、ベンダーマニュアル、Eメール、重要なナレッジベースなどの追加知識ベースにアクセスすることができます。これらのリソースは私たちのアカウントに複製されることはなく、ユーザーからの質問に応じて必要な時にアクセスされます。これにより、アラームの簡単な要約が可能になります - アラームを見て、ボタンをクリックするだけで、アラームの意味、発生理由、次に取るべき行動を一度に理解できます。また、複数のプロパティを確認し、それらがどのように相関し、現在の状況を引き起こしているかを理解するような状況分析も可能です。さらに、自然言語での対話が可能で、フォローアップの質問を通じて焦点を絞り込むこともできます。データ戦略が一貫している限り、このシステムはネイティブに機能します。
モデルのトレーニングやGuard Rateの構築に労力を費やす必要はありません。これはすぐに使用可能で、Efasteelは私たちのローンチカスタマーの一つです。
ここでを振り返り、デジタルトランスフォーメーションの旅は、本質的にモダンなデータ戦略に根ざしていることを強調したいと思います。小さな一歩から始めることはできますが、次に何が必要になるかを含めた思考プロセスとビジョンを持つことが重要です。適切なモダンデータ戦略を最初に設定することは、やり直しが必要になるような他のプロジェクトになるリスクが高いか低いかを決定する重要な差別化要因となります。私たちは、ある程度の時間を経て私たちに切り替えた多くのパートナーやお客様とともに、これを検証してきました。
二つ目に申し上げたいのは、このトランスフォーメーション全体がチームスポーツだということです。単一のプラットフォームはありません - AWS IoT SiteWiseだけで、あるいはAWSだけですべてができるとは申しません。これらは確かに強力な基盤であり、良いスタートを切ることができますが、成功に導くためには常にパートナーが必要です。私たちにはSIEMENSのようなパートナーがおり、Beldenについても話しましたし、他にも多くのパートナーがいます。真の成功は、パートナーシップが整合するときに訪れると私たちは考えています - 私たちが持つパートナーシップ、お客様が持つパートナーシップ - 私たち全員が集まって適切な基盤を構築し、それらすべての機能と統合することで、デジタルトランスフォーメーションがより大きな価値創造を可能にします。参加して接続すればするほど、フライホイールのように、より多くの価値が生み出されていきます。
皆様、本日はご参加いただき、誠にありがとうございます。午後4時という遅い時間にもかかわらず、ご参加いただき感謝申し上げます。Brian、素晴らしい経験を共有していただき、課題に直面し、それに正面から取り組み、解決していただき、ありがとうございました。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion