re:Invent 2024: Goustoが実現したFactory OSによる工場効率化と生産性向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How Gousto reduces food waste and increases workforce productivity (MFG202)
この動画では、英国のMeal Kit企業Goustoが、データ駆動型のオペレーションを実現した取り組みについて紹介しています。HighByteやAWS IoTなどのサービスを活用してIndustrial Data Fabricを構築し、工場の稼働率を70%から98%まで向上させた事例を詳しく解説しています。Factory OSと呼ばれるシステムを通じて、3秒に1箱のペースで週20万箱を生産する工場の効率化を実現し、ダウンタイムによる1時間あたり£30,000のコスト損失を防いでいます。さらに、Factory TwinやFactory APIを活用したシミュレーション機能の実装により、工場の設定最適化や予知保全を可能にし、処理能力を10%以上向上させた具体的な成果も示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Goustoの事例：データ駆動型オペレーションへの挑戦
みなさん、こんにちは。本日は、Goustoの素晴らしい取り組みについてお話しさせていただきます。イベント初日を楽しくお過ごしいただけたことと思います。このGoustoの事例は、AWSのサービスとパートナーを活用して、データ駆動型のオペレーションを構築した道のりについてです。私はDimitrios Spiliopoulosと申します。これから数分間で、産業界のお客様がオペレーションのデータ駆動化を目指す際に直面する課題についてお話しし、それらの課題に対するAWSのアプローチをご紹介します。このアプローチはGoustoでも採用されており、食品廃棄物の削減や作業効率の向上など、素晴らしい成果を上げています。ぜひ、彼らがどのようにしてこれを実現したのか、参考になる実践例としてお聞きください。
全体的な傾向として、お客様は単一のユースケースを超えて、データの活用を加速・拡大したいとおっしゃっています。しかし、その取り組みの中で、お客様の声や各種レポートから分かることは、すべての組織がデータ駆動型を目指しているものの、実際に成功しているのはわずか26.5%で、データから価値を引き出せているのは32%に過ぎないという現状です。
皆様もご経験の通り、産業データは非常に断片化しており、コンテキストが欠如しているため、様々な問題が生じています。ほぼすべての製造業者が価値の高い産業データを持っていますが、このデータは日々の経験からもお分かりの通り、ほとんど活用されていません。時間の約80%がデータの所在確認、取り込み、そして分析のための準備に費やされています。そして、ようやく洞察が得られた時には、意思決定や対応を行うにはすでに手遅れというケースが多いのです。
二つ目の問題は、ソリューションの構築に非常に時間がかかることです。通常、一つのソリューションに5〜10人の人員が必要となります。 新しいソリューションを作ろうとすると、また一からやり直しになってしまい、これは非常に非効率です。そして、コストも高額になります。成功したソリューションをスケールしようとしても、コストが線形的に増加してしまうため、ビジネスケースの観点からも難しい状況です。
結局のところ、お客様が望んでいるのは、データの出所に関係なく、簡単にデータにアクセスできることなのです。 AWSのアプローチは、ITシステムとOTシステムにまたがるデータのライフサイクル全体において、データ中心のアプローチを取ることです。私たちはお客様との対話の中で、5つの能力の実現を目指しています：アクセシビリティ - エッジでデータが生成される場所やクラウドで、いかに簡単にデータにアクセスできるか、インターオペラビリティ - 既存のデータと将来のデータ投資をいかに統合し、ゼロからやり直すのではなく、既存のものを拡張できるか、拡張性 - ビジネスの進化に合わせて、いかにビジネスロジックを追加できるか、バージョニング - 適切なデータガバナンスのために、データの変更と関係性をいかに文書化するか、そしてスケーラビリティ - コスト効率が良く安全な方法で、アセットレベルのサイトやユースケースをいかにスケールできるか、という点です。
AWSのIndustrial Data Fabricアプローチとその実装
AWSのアプローチには、Industrial Data Fabricが含まれています。これは、異なるシステムからのデータを共通のAPIを通じて接続し、データフローを促進する産業用アーキテクチャです。
データとガバナンスを安全でスケーラブルな方法で管理するメカニズムがあり、Generative AIに向けた準備を整え、自社のデータとLLMを活用してデータの上にアプリケーションを構築し、ビジネス目標を達成することができます。Industrial Data Fabricについて、さらに詳しく見ていきましょう。 このアーキテクチャは、バイヤーとビルダーの両方のお客様に対応できるように設計されています。Goustoはビルダーカテゴリーに属しています。AWS IoT SiteWiseやAWS IoT Coreなど、多くのAWSサービスとパートナーが関与しています。Goustoが使用しているHighByteのようなISVパートナーがおり、多くの課題解決とデータ駆動型オペレーションの構築をサポートしています。また、このアーキテクチャをISVパートナーとAWSサービスと共に全ての製造業者向けに実装できるシステムインテグレーターもいます。
Industrial Data Fabricを通じて、私たちは製造業者がデータに投資し、データを保存し、データを文脈化することを支援しています。最終的に、エネルギーモニタリング、予知保全、あるいはGenerative AIを使用したその他のユースケースに関わらず、このデータに基づいて行動することができます。これは、GoustoがHighByteやAWS IoTなどのサービスを使用して実現したアプローチであり、素晴らしい成果を達成しています。彼らは具体的な数字と、どのようにしてそれを実現したかを共有してくれます。では、Goustoの興味深いストーリーをご紹介したいと思いますが、まず、GoustoがUKで何をしている会社なのかを紹介するビデオをご覧いただき、その後、ThomasとFabriceが登壇して、彼らの刺激的な journey についてお話しします。
Goustoは、最高の選択肢を提供するレシピボックスを提供しています。10分で作れる簡単な料理、家族で楽しめる定番メニュー、世界各国の料理など、新鮮で質の高い食材と素晴らしい味わいを 1食£2.99からお届けします。批評家たちも絶賛しており、今やあなたの近くのキッチンで調理されています。 詳しくはgousto.co.ukをご覧ください。
Goustoの概要と直面した課題
皆さん、こんな遅い時間にお集まりいただき、ありがとうございます。私はThomasで、こちらがFabriceです。私たちがどのようにアプローチしたかについてお話しさせていただきます。 数年前、私はある疑問に出会いました：もしすべての状態にアクセスでき、その上で推論できたら、どんな問題が解決できるだろうか？それはとても刺激的な考えでしたが、私たちが置かれていた状況とは異なっていました。なぜなら、現実には ダウンタイムが発生するたびに1時間あたり£30,000のコストが発生していて、その解決方法が分からなかったのです。私たちが直面していた現実は、何の状態も把握できておらず、持っていないデータに基づいて推論することもできず、したがって何の問題も解決できないという状況でした。
では、このダウンタイムをどのように対処し、防止して、この莫大な金銭的損失を避けることができるでしょうか？そのためには、データが必要でした。数年後にどこに到達したいのか、ビジョンを作ることから始めました。まず第一に、私たちの資産にデータがあり、それを何とか入手する必要があると考えました。データに接続できれば、それを別の場所に移して、より良いものに、他の機能にとって使いやすく、有用なものにする必要があります。そこまで来れば、そのデータの上で推論できるシステムにデータを移行し始め、価値を付加し始めることができます。さらに重要なのは、これを実際の意思決定に変換できることです。単なる意思決定ではなく、最適な意思決定を望むところです。そしてこの情報を工場へのコマンドに変換し、工場を制御し、状態を私たちに有利なように変更して、直面していたこれらの問題の一部を防止し始めることができます。
続ける前に、私たちについて少しお話しさせていただき、その後で課題をより具体的に分解していきたいと思います。
そして、FactoryOSと呼んでいるソリューションについてお話しします。これは私たちの製品のブランド名のようなものです。実質的には、工場というハードウェアのためのOperating Systemです。その後、次に何をするつもりなのかについてお話しします。私たちはゼロからイチまで来ましたが、今は次のステップを計画しているところです。その後、これがあなたにとってどのように役立つかについてお話しします。
私たちについてお話ししましょう。動画でご覧いただいたように、私たちはMeal Kit企業です。基本的に、新鮮な食材が詰まった箱をお届けしています。私たちは最高の選択肢を提供することにこだわっています。非常に幅広い顧客層にフォーカスしています。1人から5人家族まで、様々な世帯規模の幅広いマーケットをターゲットにしています。特に味については、できるだけ幅広いレシピのバリエーションを提供するよう心がけています。これが私たちの主要な戦略です。リーズナブルなものから高級なものまで、ほとんどの予算に対応し、主に夕食や昼食、そして近い将来には朝食も含めた複数の食事の機会に対応しています。
私たちのミッションはとてもシンプルです。夕食を楽しむ最も愛される方法になることです。これが私たちの存在理由であり、「愛される」という部分を特に重視しています。そして、これらすべてを、人々の生活を豊かにし、地球を私たちが見つけた時よりも良い状態で残しながら実現したいと考えています。これも私たちにとって非常に重要です。お客様がアプリやウェブサイトで買い物をし、注文を行う瞬間から、箱が届き、開封し、準備をして、調理する瞬間まで、そして最も重要な食事を楽しむ時間まで、最終的には通常とても良好なフィードバックをいただくところまで、もちろん私たちは常に努力を続けています。
生産効率向上への取り組み：OEEの活用
私たちにとって、選択肢の豊富さが何より大切です。毎週200種類のレシピを提供していますが、これらは単なる微調整のバリエーションではなく、できるだけ多様性を持たせた独自の特徴的なレシピばかりです。また、廃棄物を可能な限り抑え、その改善にも継続的に取り組んでいます。 では、私たちが直面していた課題とは何だったのでしょうか？それは生産量の拡大でした。 課題の規模感をお伝えすると、週に20万箱を生産しており、これは3秒に1箱のペースでピッキングと梱包を行う必要があることを意味します。しかも、各箱には約50種類の異なる食材が含まれています。つまり、週に1,000万回のピッキング作業が必要という、かなり大規模な課題だったのです。
このサイトを開設した当初、ピーク時の生産能力の3分の1程度までしか稼働できませんでした。 問題は、稼働率が70～85%の間で大きく変動していたことですが、その理由がよく分かりませんでした。現場で発生しているPLCイベントと作業員の行動との間に明確な関連性が見出せなかったのです。 発生した不具合の修復に時間がかかり、修理に関するフィードバックも得られませんでした。エンジニアリングチームは、問題が発生し修復された後でしか分析できず、リアルタイムでの対応ができませんでした。また、潜在的な問題の再発パターンについての分析も行えない状況でした。
当時は自信も低く、本当にこの工場を拡大できるのかと自問自答していました。 まず、実際の純生産量を理解する必要がありました。1週間の総稼働可能時間から、 サイトを使用していない時間を差し引き、さらに 休憩時間や計画的なメンテナンス時間といった予定外のダウンタイムも差し引きます。その後、 様々な理由で効率的に使用されていない時間も差し引きます。これらの時間を全て差し引いた後に残る時間が、実際の生産時間となります。そして、私たちはこれらすべてを測定することができました。
残された生産時間は極めて重要でした。生産時間を1時間失うごとに3万ドルのコストが発生することが分かりました。このデータにアクセスできるようになり、私たちは手の届きやすい改善点を特定できました。そのために、Overall Equipment Effectiveness（OEE）という3つの重要な要素から成る方程式を使用しました。まず設備の稼働率があり、 次に運転性能、そして製造プロセスの品質です。これらの3つの要素を個別に特定することができます。
このデータにアクセスできるようになり、稼働率が私たちのサイトの本当のボトルネックであることが分かりました。短期間でこの指標を70%から95%まで引き上げる必要がありました。そうすることで、サイトをより効率的に運営できるようになります。その後、長期的には 稼働率を98.5%まで引き上げることを目標としました。現在では一貫して98%で運営できていることをご報告できることを嬉しく思います。
私たちは、この取り組みを3つのシンプルなステップに分けました。まず最優先事項として、ダウンタイムをできるだけ早く検知できるようにすることでした。障害を検知できるようになったら、次は Mean Time To Repair (MTTR) を最小化することです。それが達成できたら、今度は障害と障害の間の時間を最大化することに注力しました。これが私たちの取り組みの進め方でした。では、私たちが構築したFactory Arrestというソリューションについて、Thomasから説明させていただきます。
Factory Arrestソリューションの構築と進化
では、どのように0から1を目指したのでしょうか？私はエンジニアリング部門の責任者に、理想的な状態とはどういうものかを尋ねました。彼はこう答えました。「障害が発生したら、エンジニアを問題が起きている場所に正確に派遣してほしい。場所と障害の内容を正確に把握し、素早く対応してほしい。そして、後で分析して学習できるようにデータを記録しておいてほしい。そうすれば、いつも同じことを繰り返して対応するような状況を避けられる」と。
それはもっともな話でしたが、現実は違いました。設備が停止すると、誰かが目視で問題に気付くかもしれません。その人はエンジニアを探して「これを修理してもらえますか？あなたが適任者ですか？」と尋ねます。Slackを使って必要な人を探し、ようやくエンジニアを見つけます。エンジニア同士で話し合い、最終的に適任者が現場に向かって問題を修理します。もし覚えていれば、システムを更新します。ほとんどの場合、障害が発生したことすら把握できていませんでした。つまり、テクノロジーが人の後追いをする状況で、MTTRへの影響を見ると、無駄な時間が多く、修理までの時間が長くなっていました。
そこで、この状況を逆転させる方法を考えました。設備が停止したときに人が何が起きたのか把握しようとするのではなく、データを取り込んで障害を検知できるものを作れば良いのではないかと。その時点では具体的な方法は分かっていませんでしたが、データを取り込んで、これは障害らしいと判断できるようにしようと考えました。すべてのシグナルが障害というわけではなく、誤検知の可能性もあります。そして保守システムに作業指示を作成し、エンジニアを派遣して問題を修理します。データはすでにシステムに入っているので、入力を依頼する必要はありません。
結果として、今では人がテクノロジーに従う形になり、MTTRが大幅に短縮されたことが分かります。さらに発見したことがあります - 以前は追跡できなかった他の要素も追跡できるようになりました。何かが故障したとき、その故障を発見し、エンジニアに伝えるだけでなく、エンジニアがどれだけ早く問題に対応したか、調査にどれだけ時間がかかったか、そして検知から修理までどれだけかかったかを測定できるようになりました。サイクル全体が細かく追跡され、MTTRがさらに短縮される中で、各ステップを最適化できるようになっています。
そこまでくれば、はるかに良い状態になっていました。しかし、最初の段階ではまだゼロの状態で、非常に基本的な問題を抱えていました。ほとんどの工場と同じように、私たちの工場にも設備があり、PLCがありました。
私たちの場合、優れた設備を持っていました。Siemens製の優れたPLCがあり、非常に良いデータとモデルを持っていました。PLCを制御するPLCサーバーがあり、Kepwareも動いていたので、非常に良いセットアップでした。問題は、データがロックされていて、そこに眠ったままで活用できていなかったことです。私たちの場合、HighByteという素晴らしいプラットフォームを使用して、データに接続し、自動化システムからデータを取り出すことができました。
しかし、それは物語の半分に過ぎませんでした。データは自動化システムから取り出せましたが、クラウドに送る必要がありました。クラウドに送ることで、約200人のクラウドエンジニアとデータサイエンティストのチームを活用できるようになります。これらの人々が実際にデータを扱い、有効活用し始めることができます。私たちにとってのパズルの2番目のピースは、このデータをAWS IoT Core（実質的にはMQTTブローカー）にルーティングすることでした。これら2つのピースが組み合わさって、業界で一般的に「Unified Namespace」と呼ばれるものを作り出しました。これが私たちにとってのグラウンドゼロ、つまり、これから起こるすべてのことの最も基本的な要素であり、基盤となったのです。
HighByteについて触れておきたいと思います。私たちにとって、これは画期的なものでした。HighByteがなければ、これらのことは何一つできなかったでしょう。実際、これらが始まる1年前に自分たちで構築しようとしましたが、完全に失敗しました。10人のチームが1年間かけて取り組みましたが、失敗に終わりました。これは解決が難しい問題で、購入できるのであれば自分たちで作る必要はありませんでした。HighByteを使えば、データにネイティブに接続でき、それはすぐそこにありました。文字通り2日以内に接続が完了し、データのモデリングができるようになりました。新しいPLCが登場するたびに、一からやり直す必要はありません。テンプレートを通じてインスタンス化し、新しい機器を素早く追加し続けることができます。
このように適切にモデル化されたデータがすべて揃ったところで、他のアプリケーションにフローさせて有効活用することができます。私たちはパブリッシュ-サブスクライブモデルを導入しました。これら2つのシステムの組み合わせにより、データを広く利用可能にすることができました。この情報を追加のサービスに送ることができるようになりました。この場合、IoT Eventsにフォルト検出器を構築しました。これは基本的に、シグナルを送信せずに3回故障した場合は不具合があるに違いないという単純なルールエンジンです。これらすべてをミドルウェア（これはAWSのグルーで、このような用途に最適です）を通して処理し、メッセージを伝播させて、保守システムのAPIをトリガーします。
実際の現場ではこのような感じです：原材料が入った青いトートが準備されているのが見えます。これがコンベアベルトを流れてきて右に曲がるはずなのですが、角で跳ね上がってしまい、スキャン不可のイベントが発生します。そこでエンジニアにモバイルアプリで通知を送ります。エンジニアはメッセージを確認し、対応を承諾して、オーダーの修正に向かいます。その結果、MTTRが劇的に改善され、これが初日の目標達成につながりました。
データ活用による生産性向上：リアルタイムルーティングの実現
障害を解決していく中で気づいたのは、単なる対応モードを超えて、他の問題も見えてくるということです。工場内のRATと呼ばれる、箱を一方向から別の方向へ直角に移動させる装置で、奇妙な不具合が発生していることに気づきました。個々の事象は理解できなかったのですが、データを分析してみると、パターンが見えてきて、これらの装置全てに機械的な不具合があることが分かりました。摩耗や劣化の問題を特定し、機械保守計画を見直すことができました。予期せぬメリットも含めて、様々な効果が積み重なり、新しいプロダクトアーキテクチャが生まれました。次に、データをData Lakeに送ることを考えました。そうすることで、さらに多くの価値を生み出せると考えたからです。
Unified Namespace（UNS）の基本アーキテクチャがあれば、既存のインフラを活用できるため、これは非常にシンプルでした。インフラはすでに存在していたので、パイプラインに接続してデータをLakeに移動させることができます。データがLakeに入れば、分析を実行し、Analyticsチームを活用し、レポートを生成し、さらにはモデルのトレーニングも行えます。
次に、すぐに実現できることは何かを考え、予知保全の実装に取り組むことにしました。問題が発生してから対応するよりも、故障を未然に防ぐ方が遥かに良いからです。つまり、先ほどお話しした30,000ポンドの出費を完全に防ぐことができます。基本的なアーキテクチャは既にあったので、機器の周りに温度変化や振動を監視するセンサーを追加することができました。これらの測定値が正常範囲を超えた場合、機器が故障する可能性があると予測し、故障が発生する前に予防措置を講じることができます。
このデータをオンラインの異常検知サービスに送信し、UNSにストリーミングで戻します。UNSに入ったデータは、作業指示を作成する同じミドルウェアインフラを活用します。エンジニアにとっては何も変わりません - 単に作業指示を受け取って機器の対応をするだけです。これが私たちの工場での実際の様子です。工場は基本的に3次元のキューブで、3つの工場が重なったラザニアのような構造になっています。ご覧いただいているのはリフトです - 製品を運ぶ高速リフトが上下に移動しているイメージです。このようなリフトが6台ほどあり、1台でも故障すると深刻な問題になります。そこで、底部にセンサーを設置してデータアラートを発信し、それを受信して保守作業を行っています。
その結果、多くの事例とともにシステムのダウンタイムを大幅に回避することができました。 自動化システムに付属のSCADAシステムがありましたが、文字通り1万個のライトが点滅するだけの非常に基本的なものでした。何か問題が発生すると、 赤いライトが点滅するだけで、故障の場所や性質を示すことはできませんでした。誰かが実際にその場所に行って、その場で原因を突き止める必要がありました。そこで、HighByteからデータを抽出し、SCADAシステムやその他のアプリケーションを構築するための産業用プラットフォームであるIgnitionにプッシュしました。
数ヶ月以内に、工場全体を網羅する包括的なSCADAシステムを実装することができました。これにより、それまでアクセスできなかったさまざまなメタデータを表示できるようになり、コントロールルームでセットアップすることができました。 大きなスクリーンが並ぶ部屋を想像してください。そこでは、インタラクティブな方法ですべての状況を完全に可視化しながら、状況認識を維持することができます。また、データ分析に優れたツールであるAWS IoT SiteWiseも導入しました。通常は30日分のデータを扱っていますが、現在ではそれ以上のデータも処理可能です。可視化機能など、多くの機能を提供しています。
SCADAの先を見据えて、 これがもっと大きなインパクトを与える可能性があると考えました。次のステップとして、先ほど言及したOEEメトリクスをこの統合システムに追加しました。 UNSとIoT Coreからこのデータを取得できるようになったことで、Ignition内で計算を行い、そのデータをリアルタイムでコントロールルームに送信できるようになりました。 これが実際のダッシュボードで、約1分ごとにデータを更新できます。右上隅には、先ほど説明した設備の可用性、性能、品質を示すバーチャートがリアルタイムで表示されています。コントロールルームのオペレーターは、これらのメトリクスが時間とともにどのように変化するかを確認し、何か問題が発生した場合に対応することができます。
Factory Twinの構築とシミュレーション機能の活用
このOEEメトリクスの計算式について多くお話ししてきました。 これを使って、企業レベルからサイト、工場内のエリア、特定のライン、さらにはステーションレベルまで、さまざまな粒度で表現することができます。
このメトリクスは、異なる時間単位でも表現・分析することができます。シフト単位、1日の生産単位、週単位、月単位などで計算することができます。これにより、オペレーションが期待通りに機能していない機会領域を特定することができます。次の戦略的投資のタイミングを検討し、どの工場に投資すべきかを決定する際には、 データを参照することができます。私たちの推奨事項は、OEEスコアが最も低いサイトを優先することです。
例えば、箱をパレットに積んで顧客に出荷する工程で、パフォーマンスの低下が確認されたとします。その場合、工程の自動化、処理能力の増強、あるいは作業員の配置の見直しなど、いくつかの投資オプションが考えられます。このような対応が可能になるのは、システムにデータを入力し、測定、追跡、改善する方法を確立しているからです。
私たちのシミュレーション機能についてお話ししましょう。これは私たちが誇りに思っている機能の1つです。 具体的なシナリオをご説明します。工場の製造現場で、ラインに沿って箱の滞留が発生し始めているとします。 この複雑なシステムで何が起きているのかはっきりとはわかりません。このような状況では、何が問題なのかを特定するためにRoot Cause分析を開始します。その滞留ポイントで、滞留が発生する直前に工場内での箱の再循環数が増加していたことに気付くかもしれません。
そこで仮説が立ちます：もし箱の再循環をより適切に管理できれば、こうした滞留は発生しないか、より早く解消できるのではないか、というものです。しかし、実際の現場でこの仮説を検証することは問題があります。コストがかかりすぎる上、設備が故障する可能性があり、顧客に届けるべき箱の出荷時間に間に合わないリスクがあるからです。そこで私たちは、これらのプロセスやイベントをモデル化してテストできるデジタルシミュレーションシステムを構築しました。
様々なパラメータでシミュレーションを実行できます。再循環レベルが10%の場合はどうなるか？モデルを実行して結果を確認すると、何も問題は起きません。次に、工場内の再循環を15%に設定したシナリオを実行します。この時点で、箱の詰まりが所々で見られ始めますが、まだ許容範囲内です。さらにパラメータを20%まで上げると、突然すべてが停滞し、何も動かなくなってしまいます。このようなシナリオを簡単かつ迅速にシミュレーションできる能力があれば、滞留の原因を特定し、適切な対策を講じることができます。
これこそが私たちのデジタル機能の本当の目的です。 この機能をどのように構築したのか、少しお時間をいただいてご説明します。私たちは非常にシンプルで反復的なアプローチを取りました。3つのシンプルなステップを使用しています。まず、重要なプロセスの1つをモデル化します。次に、そのプロセスについて実験を開始し、微調整を行います。現場で見られる実際の状況を再現できるようになったら、モデルの次のパート、次の重要なコンポーネントに移行します。
私たちは小規模なモデリングステーションから始めました。 箱が取り出されてから、その中に材料が入れられるまでの所要時間を調査しました。このプロセスをモデル化した後、箱がステーションに滞在する平均時間を測定することができました。このモデルができあがると、これらのステーションをいくつか組み合わせてレッグを作成しました。レッグができると、 複数の箱を様々なステーションに送ることになります。あるステーションには行き、別のステーションにはスキップし、また別のステーションに行くといった具合です。そして複数の注文を処理していきます。
そのレッグで複数の注文を処理することで、お客様が注文した全ての材料を集めるために、箱が訪れる必要のあるステーション数を測定できるようになりました。これがレッグのモデリングです。次に、このシミュレーションの範囲をさらに広げていきます。レッグができたら、それらを複数つなぎ合わせて、 フロア全体のプロセスをモデル化できるようにします。
フロア全体にアクセスできることの興味深い点は、私たちの工場には2つの異なる温度帯があることです。一つは冷蔵の材料だけを集めるゾーンで、これらは箱の特定のセクションに入れられます。その後、箱は工場の常温側に移動し、根菜類や低温を必要としない材料を入れていきます。フロア全体のモデルができたことで、箱がラインで過ごす時間をモデル化して測定できるようになりました。最後に、Thomasが先ほど述べたように、私たちの タワーは異なる層で構成されており、この側には3層あります。これら3つのフロアを接続することで、先ほど言及した各フロア間の再循環を測定することができるようになりました。これで、ゼロから完全な工場モデルが完成したわけです。
先ほど説明した各ステップにおいて、非常に重要な検証フレームワークを実行しています。モデルの反復作業を行うたびに、まず過去のデータを再現することから始めます。前日や前週の生産日のデータを収集し、そのデータをシミュレーションモデルで実行して、シミュレーションの出力を確認します。このダイアグラムでは、時間経過に対する箱の累積処理数を示しています。一方の線が実際の生産データで、もう一方がシミュレーションによる再現データです。これにより、その再現の精度を測定することができます。微調整を重ねることで、シミュレーションの再現精度に満足できるレベルに達します。
これが重要な理由は、デジタルシミュレーションの精度が高くなれば、このケイパビリティから得られる予測に高い信頼性を持てるようになるからです。ツールの検証が完了すれば、先ほど述べたようなシナリオを実行することができます。このシミュレーションで実行できるシナリオには3つのタイプがあります。最も明白なものは、先ほど述べた工場内の設定可能なパラメータに関するものです。一度にレッグを訪れることができる箱の数はいくつか？再循環でどれだけのループが可能か？これらは設定可能なパラメータなので、シミュレーション環境で多数のテストを実行し、これらのパラメータの最適なバランスを見つけることができます。
次のユースケースのタイプについてお話しします。製造ライン上で稼働している多くのデータプロダクトがあります。先ほど触れた、箱がどのステーションで停止するかを制御するRoutingシステムなどです。これらのモデルは継続的に改善され、開発が進められています。シミュレーション環境でこれらのモデルの新しいイテレーションをテストし、オペレーションの改善につながるかどうかを確認することができます。そして最後のユースケースのタイプは、工場に新しいパーツを追加したり、ここにConveyor beltを追加したり、あそこのステーションを削除したりした場合、どうなるかということです。これらすべてをシミュレーション環境で実行することができます。
最終的にはこのような形になります。このアニメーションでは、Towerの全体像をリアルタイムではなく、リプレイとして見ることができます。下部では、箱がTowerに入っていき、上りのランプを通って、Towerの入り口で少し列を作ります。ここには箱を一つずつ送り出すQueueingプロセスがあります。先ほど説明したように、箱は前方のレグに入り、レグの周りを回っていきます。これらの箱は、必要な材料を入れるステーションで停止します。そして、箱は1つのステーションを訪れた後、再びConveyorシステムに乗り、別のステーション、さらに別のレグに移動して、常温の食材を取りに行きます。
この工程はすべての箱で行われます。箱はそれぞれ異なるルートを通りますが、同じような工程を経ます。最後に、これらの箱はピッキングエリアを出て、エンドオブラインに向かい、先ほど説明したパレットに載せられて、お客様のもとへ発送されます。これがFactory Twinの力です - あらゆるイベントを再現し、これらのシナリオの変更をテストする能力があります。
最近、素晴らしい成功事例がありました。適切なタイミングで適切なステーションに箱をRoutingすることの重要性について先ほど触れました。特定のステーションにおける在庫の可用性を測定するために、リアルタイムデータへのアクセスは非常に重要です。在庫は減少していき、補充が必要になりますが、時にはステーションで在庫が不足することがあります。在庫がどこにあり、どれだけあるかを知ることは、Routingプロセスにとって非常に重要です。また、リアルデータにアクセスすることで、ステーションの作業負荷を予測し、ライン全体でバランスが取れていることを確認することができます。
最近、これらのデータをリアルタイムで活用し、箱のルートを更新できるようになりました。箱がどこに行くと予測していても、最適な工程となるようにそのルートを更新し、適切なタイミングで適切な材料を取れるようにすることができます。この改善は、私たちのオペレーション効率に大きな影響を与えました。最近、処理能力が10%以上向上したことを確認しています。これは私たちにとって非常に大きな成果です。
AI/MLを活用したFactory OSの未来像
これらのコンポーネントがすべて接続されると、在庫データにアクセスするために接続・クエリを実行する複数のWarehousing Systemデータベースがあります。データベースに直接クエリを実行する代わりに、UNSを通じてすべてを接続することで、統合された空間でそのデータにアクセスできるようになります。これが私たちのゼロからイチを作り上げるソリューションで、FactoryOSと名付けました。
私たちはそこで一旦止めることにしました。ゼロからイチを作るには十分だったからです。 振り返って、もし続けていったら何か問題が発生するかどうかを考えました。そして答えはイエス、いくつかの問題が起こり得ると分かりました。 まず、インフラストラクチャを見直しました。最初はすべてが単一のサーバーにありました。工場が完全にこれに依存しているため、もしこれがダウンしたら工場全体が停止してしまうことは、天才でなくても分かります。
そこで、コンテナ化の導入を決めました。パッチやサーバーリリースを進化させられるようにGitOpsも導入しました。実質的に、100%の耐障害性を持つシステムを実現しました - 決してダウンすることはありません。ちなみに、私たちはOEE計算の中で可用性も計算に入れています。技術的な可用性も含めています。98.5%を達成しようとすると、技術面では100%に近い必要があります。私たちはPortainerを使用しています。これはKubernetesのオンプレミス版のような、ローカルのオンプレミスコンテナ化サービスです。AWSも使えましたが、レイテンシーの理由で、私たちのインフラはすべてオンプレミスです。AWS Outpostを使用している場合は、異なるオプションがあります。
Factory Twinはアップグレードされる予定です。私たちがどのようにTwinを構築したかを説明しましたが、その後何ができるでしょうか？ 先ほど、過去のイベントを再生できるとお話ししましたが、工場の現場でできる限りリアルタイムにこのデータにアクセスできます。仮説をテストし、インシデントへの解決をより迅速に見つけることができます。これをSimulation 機能に接続したいと考えています。そうすることで、障害を検出して迅速な対策を導入する必要がある場合に、非常に短い時間スケールで代替シナリオをテストできるようになります。
いくつかの意味のあるシナリオを実行して、Simulationから最適な結果を見つけることができます。その時点で、障害が修正されるまでの適切な時間、適切なパラメータで工場を再構成し、進化を続けることができます。 私が説明したDigital Twinから、今度はDecision Twinに入ります。複数のリアルタイムデータソースにアクセスでき、瞬時にシナリオをテストし、必要に応じてこれらの設定を更新できます。これらすべてがコントロールルームのオペレーターの手に委ねられ、最適なタイミングで最適な決定を下すことができます。
次に、Factory APIについてお話しします。 これまで、システム間にはこのような多くの接続が存在していました。最適化を見出し、工場に指示を出して状態を改善するためには、工場に対して指示を出す必要があることを覚えておいてください。私たちが抱えていた問題は、プラットフォームにとって致命的な「絡み合い」の状態でした。ASAソリューションがJDA Warehouse Management Systemと通信し、お互いを認識しているような状況です。また、PlatformのPythonプログラムがネイティブSQLを書いて制御システムに送信するなど、まさに混沌とした状態で、このようなシステムは運用できません。
明らかな問題点は、これらのシステムの1つが使えなくなった場合、インターフェースを書き直さなければならないことです。新しい工場を建設して別のWMSを2つ導入しようとする場合、これらすべてを複製し、どのシステムと統合するかを調整しなければなりません。 明確な解決策は、APIを導入することです。工場をベンダー固有の実装から抽象化する必要があります。JDAやManhattanを使用していることを意識する必要はありません。これらのシステムには何も問題はなく、完璧に機能しています。ただ、私たちはそれを意識したくないのです。私たちは、Goustoが理解する形で、Warehouseシステムが行うことの標準的なバージョンを作成したいと考えており、これをすべてに適用したいと考えています。
Factory APIと言う場合、保守、Warehouse管理、Warehouse制御などのための多くのAPIを指します。これらすべてが合わさって工場を形成します。これは現在進行中で、まだ完全には実現していません。そして当然ながら、最終的な目標はアルゴリズムによる意思決定からAI/MLへと進化することです。 これは現在検討中の事項です - これは同じReactive Maintenanceのアーキテクチャです。これは最初のユースケースを思い出すためのものです。工場からデータを取得し、それをUNSで使いやすい形に変換し、その後シンプルなif-then-else処理を行います。例えば、3回スキャンされていない場合は、故障の可能性があるとしてMiddlewareを通じてWork Orderを発行します。
しかし、Work Orderを作成する便利なMiddlewareは残しつつ、UNS型のロジックを取り除いて、Downtime Predictorと呼べるものを導入したらどうでしょうか？推論のためにデータを取り込み、「これは以前にも見たパターンで、このパターンが出現すると数分後に工場で何か問題が発生する」と予測できます。これを工場のあらゆる場所に適用して、パフォーマンスの低下を予測することができます。20個のこのような事象が同時に発生している場合、どれに対応すべきでしょうか？深刻度は様々なので、AIを使って優先順位付けを行い、これら2つは対応が必要で、これら2つは待機可能といった判断ができます。
私たちが検討している実際の技術アーキテクチャでは、ホットスワップが可能です。機械データをルーティングし、AWS SageMakerなどとインターフェースして調整を行うレイヤーを通じて推論を実行します。その結果、潜在的なダウンタイムを予測し、それをデータベースに保存します。調査が必要だと判断した場合は、既存のMiddlewareを通じてWork Orderを発行します。エンジニアはこれらの仕組みを知る必要はなく、何も見える必要はありません。単に別のWork Orderに対応するだけです。このように、すべてに対応できる普遍的なソリューションが得られ、新しいアーキテクチャが形成されていきます。
この新しいアーキテクチャは、私たちのビジョンにより近づいています。 データを収集し、UNSを通じて活用可能にし、そのデータに基づいて推論を行ってから行動を起こします。さらに一段階上のレベルで見ると、 これらのMLプレディクターで異なるパターンが浮かび上がってきます。Factory Twinに接続して、様々なシナリオをテストすることができます。例えば、ある時点でダウンタイムが発生する場合、できるだけ早く対応するための最適な設定は何かといったことです。
さらに多くのユースケースが登場しています。先ほど話した混雑検知の例を考えてみましょう。混雑を予測できれば、それを防止または軽減するためのより良い設定は何でしょうか？生産ラインのバランスをより良く取るにはどうすればよいでしょうか？製品の一部がChill Zoneに滞留したり、Ambient Zoneに滞留したりすることがあります。このようなアンバランスを予測できれば、工場の設定を調整できます。これらの機械学習モデルは予測を提供し、Twinに接続して代替シナリオを実行し、これらの問題に対処するための最適な判断を見つけ出します。そして、Factory APIを通じて工場システムに接続し、工場をリアルタイムで再設定することができます。
この複雑なオーケストレーションが整うことで、 冒頭で示したビジョンが実現します。設備から得られる生データを、イベントを生成するUNSに接続し、そこから学習することができます。分析と予測を実行し、その予測は先ほど説明したシステムへのコマンド、つまり決定につながり、それをFactory APIを通じて接続することで、先ほど述べた設備へと制御を戻すことができます。これがスケールする工場テクノロジーなのです。
結局のところ、より速く、より遠くまで進むことができるということです。問題を解決するためにこれらすべてが必要というわけではありません - エンジニアリングの専門知識だけでも可能です。ある程度のところまでは到達できますが、十分な速さでは達成できません。事前に分析を行った結果、95%程度の可用性は達成できるものの、12ヶ月かかり、一部の問題は解決に何年もかかる可能性があることがわかりました。その12ヶ月の間にダウンタイムが発生するため、多額のコストがかかります。6ヶ月で達成できれば、それは価値があります。
また、データがあればより先に進むことができます。専門知識だけでは一定のレベルまでしか到達できません。データがない領域には限界があり、直感だけで行動することになります。しかし、このアプローチを使えば、その限界を超えてさらに先に進むことができます。通常、このような問題を解決する際は一つの領域に焦点を当てます - 一つの領域に集中し、次の領域に移っていきます。次の領域に取り組む頃には、データが蓄積されており、それが非常に役立ちます。
もう1つの利点は、インテグレーションに関してです。これが私たちが持っていた状態で、多くのメーカーが採用している典型的なオートメーションピラミッドです。これは通常、多くのポイントツーポイントの統合と複雑な絡み合いを生み出します。この見方ではなく、こんな風に見られたらどうでしょう？ 中心にハブがあり、生データに価値を付加し、情報やデータを提供する多くのスポークを追加できます。 これらのスポークは、データを生成してシステムに戻すこともできます。Fabriceが先ほど言及したOEEがその一例です。私たちはOEE Manufacturing Execution Systemという新しいスポークを作成し、品質とパフォーマンスを計算します。このデータをダッシュボードに表示することもできますし、再度システムに戻すこともできます。これにより、OEEを計算しない他のスポークもそのデータの恩恵を受けることができ、ネットワーク効果を生み出すことができます。
データ駆動型工場実現への実践的アドバイス
実装に関しては、私たちがお見せしたような大きな構想を持ちつつも、小さく始めることが大切です。 少人数のグループで始めて、何かを実現させましょう。良いユースケースを見つけて、それを基に発展させていきます。
時間を限定することも重要です。 目標を達成したら、価値を追加し続けていきます。スピードを上げて、最終的に一旦立ち止まり、 プラットフォームをスケールさせれば、月へ向かう準備が整います。大きなチームは必要ありません。最初のUNSシステムをインストールするには1人で十分です。 新しいユースケースに遭遇したら、Data ScientistやData Engineerを見つければいいのです。Software Engineerは実際、7-8ヶ月経ってから加わりました。最初から必要というわけではないのです。
大きなチームは必要ありませんが、スケールする準備が整った時には必要になります。これが私たちのチームです。 とても誇りに思っています。そして下にいるのが、いつも笑顔の Head of Engineering です。彼はとても幸せそうです。標準規格を使用することを強くお勧めします。自分で作る必要のないものは作らないでください。素晴らしいツールがたくさんあります。HighByteについても言及しましたが、とてもクールです。ツールについて考えすぎないで、とりあえず試してみてください。うまくいかなければ、POCを行い、 次に進みましょう。RFPを作成したり戦略文書を書いたりせず、素早く動くことです。これが私たちの経験上、最も効果的です。
大きなチームは必要ありません。 また、優れたツールが80%程度カバーしてくれるので、大規模なソフトウェアエンジニアリングチームも必要ありません。 工場を止める必要も絶対にありません。実験のために静かなエリアを選び、そこで学び、改善を重ねてから、より重要なエリアに移行すればいいのです。 たとえ技術を完全に理解していなくても、最善の方法はチームを混ぜ合わせることです。機械工学とソフトウェアエンジニアリング、あるいは技術全般の人材を一緒にすれば、1+1が3になるような相乗効果が生まれます。それが、お互いから学び合う方法なのです。
機器間の通信の問題について心配する必要はありません。予知保全で説明したように、検知器を簡単に取り付けることができます。状態ベースのモニタリングでさまざまなデータを測定でき、すぐに始められます。もしテックチームが自動化について理解していないなら、彼らを工場で一定期間過ごさせてください。文字通り、現場の空気を肌で感じる必要があります。他に方法はありません。数日間実際に工場で働けば、多くを学び、非常に有用な経験となります。これは必ず行う必要があります。
そして最後に、私たちが始めた地点に戻ってきました。ただし今は、可能な限りすべての状態を把握できています。そしてそのデータを基に推論を行うことができます。では、どのような問題を解決できるのでしょうか？本日説明したように、私たちは効率性の向上に取り組んできました。そして、効率的な運営を維持することで、お客様のご自宅に届くボックスの中の食材を新鮮に保ち、価格を手頃に抑えることができています。これこそが大きな成果であり、お客様にとって重要な点なのです。本日は私たちのストーリーにお付き合いいただき、ありがとうございました。最後になりますが、LinkedInでお気軽にご連絡ください。リンクを記載しております。また、セッションに関する通知が届くと思いますので、アンケートにご協力いただければ幸いです。皆様のフィードバックは私たちにとって非常に重要です。重ねて御礼申し上げます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion