非調整空気を用いた流動層乾燥プロセスは、投入される製品のばらつきもあって複雑で予測不可能です。その結果、最適ではない設定が頻繁に使用され、手戻りが発生し、コストの増加、余分な作業、生産スケジュールへのプレッシャーの増大など、多くの問題が生じました。乾燥パラメータの最適化を目指し、空気と温度条件の関数として乾燥時間をモデル化する試みは、部分的にしか成功しませんでした。
しかし、JMP Proの機能データエクスプローラ（FDE）を用いて、工程開始から15分以内の個々の製品の乾燥プロファイルをモデルに組み込むことで、画期的な進歩がもたらされました。オペレーターはその結果を用いて最短乾燥時間を予測し、それに応じて機械の設定を調整できるようになりました。FDEを用いて、様々なパラメータが工程内で結果にどのような影響を与えるかについての洞察を得ることは、非常に有益です。本講演では、工程情報を測定するすべての人にとって有益な情報となるでしょう。オペレーターにこの情報を提供し、工程の途中で機械の設定を調整することで成果を最大化する方法を紹介します。
こんにちは。このプレゼンテーションへようこそ。オリンピックのジェイコブです。同僚の[聞き取れず]も同席しています。本日は、機能データエクスプローラーを用いた乾燥工程のインプロセス最適化についてプレゼンテーションを行います。
まず、このプロジェクトの背景についてご説明します。その後、[聞き取れず]で、私たちが行ったことのより詳細な統計的な分析についてご説明します。ご興味を持っていただければ幸いです。
まず、ルンドベックについて少しお話します。ルンドベックは1915年から続く企業で、脳の健康に尽力しています。つまり、脳の健康を回復させるあらゆる薬を扱っているということです。
世界50カ国以上で約5,400人の従業員を擁し、その歴史は古く、API製造から卸売業者に至るまで、包括的なサプライチェーンを構築しています。さらに、CMOパートナーや、あらゆる原材料を供給する多くのサプライヤーも含まれています。当社の製品は世界100以上の市場に流通しており、非常に複雑なサプライチェーンとなっています。
本日は、年間約25億錠を生産するバルク生産において実施したプロジェクトに焦点を当てます。このプロジェクトでは、造粒プロセスを採用しています。そのプロセスについては後ほど詳しく説明します。流動床と呼ばれる装置を用いて造粒を行うプロセスです。
外から大量の空気が入ってきます。空気はフィルターで濾過されるだけです。地元の小さな気象観測所から、天候と空気の状態は24時間で大きく変化することが分かっています。
オペレーターたちは、社内仕様を満たすために、今日のプロセスや製品をどれくらいの期間試すべきかという問題を抱えています。ここにJMPの小さな数値がいくつか表示されていますが、現時点ではバッチの26%が社内基準値を下回っていることが確認されています。
少し高いですね。まずはこの問題を軽減し、優秀なオペレーターがプロセスをよりスムーズに進められるよう支援できないか検討しました。
造粒プロセス、あるいは流動床乾燥とは何でしょうか？流動床に湿った粉末を入れ、そこに大量の空気を送り込みます。空気を特定の温度まで加熱し、一定量の空気を流すことで水分を乾燥させ、その後フィルターを通して再び排出します。こうすることで、流動床乾燥の力を完全に失うことなく、乾燥を行うことができます。造粒も可能です。今回のケースはこれに限定されませんが、可能性としてはあり得ます。
新しいタイプの流動床では、吸入空気の湿度を特定の設定値に調整できる空調ユニットが備わっているはずです。しかし、現在の私たちのシステムではそれが不可能で、物理的な制約から、それを購入して追加することさえ不可能です。
設備が少し古いため、機械から十分なデータを取得するために、自分たちでセンサーを設置する必要がありました。そうしないと、結果がすべて紙に印刷されてしまうため、私たちの作業には最適ではありません。
さらに、これらすべてを行うために必要なすべてのデータを収集しています。流動床データ、左側の気象データ、そして工程内制御データもあります。私たちの目標は、これらすべてのデータをデータレイクに集めることです。
さらに、オペレータに表示させたい操作をすべて表示できる小さなアプリケーションを作成しました。これは、すべてのデータの流れを示したものです。
最初は、外の天気に基づいてどれくらいの期間予測するかという単純なモデルから始めましたが、良いモデルとは言えませんでした。そこで[inaudible]が、Functional Data Explorerを使って、どのように私たちの役に立つモデルに近づいたのかを説明します。
はい。ありがとう、ジェイコブ。システム全体の概略図が欲しいんです。ジェイコブが言ったように、気象観測所があって、毎日天気や流動床に流れる空気に関する情報を提供してもらえます。
それに基づいて、例えばオペレーターの作業時間を見積もることができます。機械をセットアップして試運転し、目標値に達するまでどれくらいの時間がかかるでしょうか？しかし、季節による気象条件の変化や、例えば夏や冬など、設備の寒さによって停止したり電源を切ったりするなど、多くの問題があります。
この流動床に流入する空気には大きな変動がありました。ここにある気象観測所から得られるデータや情報だけに基づいて乾燥時間を予測するのは非常に困難でした。
調査の最初のステップとして、流動床の直前、流動床に流入する空気のすぐ近くにIoTセンサーをいくつか設置しました。また、流動床に製品温度センサーや排気センサーも設置しました。
これにより、タンクに入り流動床から排出される空気の特性を直接測定できるようになりました。しかし、それは大量のデータを意味します。時系列データも取得しています。合計8個のセンサーがそれぞれ1秒ごとにデータをデータレイクに送信しています。
そうすれば、まず乾燥中に何が起こっているかを理解できるはずです。バッチ間で何が異なっているのか、そしてより多くの情報を収集できるはずです。最終的な目標は、このデータを活用して、このセットアップにおける乾燥をより正確に予測できるようにすることでした。
アイデアはシンプルでした。データレイクに収集した大量の履歴データから、IoTデータや気象データなど、あらゆるデータを抽出したいと考えていました。
そこで、モデルを学習させ、そのモデルを「Prod Intel」と呼んでいるプラットフォームで使用したいと考えました。最初のモデルでは、乾燥開始直前にすべての情報を収集し、それをモデルにプッシュします。そして、オペレーターは私たちが与えた推定値に基づいて作業を開始します。
話を進める前に、私たちが保有しているデータ、つまりIoTデータを見てみましょう。先ほども申し上げたように、これは過去1年間に収集した履歴データです。そして、これらすべてのセンサーから毎秒収集されるIoT情報も保有しています。
例として、あるバッチを見てみましょう。乾燥中、流動床に空気を吹き込みます。すると、空気の流れは同期して上下し、目標値付近で平均的に安定します。
次に、乾燥空気の温度も制御します。つまり、乾燥プロセス中に製品温度がどのように上昇するかを確認できるということですね。これは、乾燥開始からの経過時間に基づいています。
乾燥中に排気温度も上昇しているのが分かりますね。完璧ですね。では、このバッチを例えば別のバッチと比較してみましょう。別のバッチに移ります。
これは別のバッチです。赤で示されています。このシステムを適切に管理しようと努めているにもかかわらず、乾燥手順はバッチごとに異なる可能性があることがはっきりとわかります。
乾燥機の空気温度によって大きく左右される可能性があります。乾燥プロファイルも変動し、製品温度と排気温度の両方で確認できます。これは、過去のデータや乾燥開始直前に収集したデータを使って、目標値や必要な乾燥時間を概算できないことを明確に示しています。もちろん、過去のデータや乾燥開始直前に収集したデータを使っても、目標値や必要な乾燥時間を概算することはできません。
プロセスにばらつきがある場合、プロセスを開始してみないとその変化はわかりません。そして、その変化に基づいて、「乾燥が別の傾向を示しているので、別のプロファイルが必要だ」と判断するのです。
そのため、乾燥中のデータを活用して、製品の最終的な相対湿度の仕様を達成するための目標をどのように設定すべきかを予測するという 2 番目のアイデアを思いつきました。
アイデアはシンプルでした。プロセスを開始し、乾燥中に8つのセンサーすべてからデータを収集したいと考えていました。乾燥中は、だいたい15分間データを待機します。その後、それらのデータを分析するか、構築したモデルにプッシュします。15分後、オペレーターに予測値を提供します。その目標値は、例えば、この温度はどれくらいか、10分後に停止すべきか、といったものです。
この予測は、乾燥のパフォーマンスに直接基づいており、特定のバッチに基づいており、事前に想定された条件に基づいていません。
どうやってやるかというと…これに戻ります。JMPの良いところは、時系列データを分析するための非常に強力なツールと、関数データエクスプローラを備えていることです。
残念ながら、この機能は現時点では、私の知る限りでは開発段階から利用可能です。時系列データを分析するための非常に強力なツールです。
例えば、この乾燥プロファイルにおけるバッチ間の差異を調べたいのですが、データエクスプローラー関数を使っています。例えば、製品データを見てみたいと思います。そして、経過時間、そしてもちろん、IT関数としてバッチデータも持っています。
このアプリケーションでは、すべてのバッチを時系列で履歴的に確認し、それらすべてのプロファイルにおける一般的な傾向を見つけようとします。バッチ間の差異をどれだけ明確に把握し、すべてのプロファイルを個別に比較できるかを確認できます。
私がやりたいのは、これらの各信号の傾向やプロファイルを抽出し、それをモデルの入力として使用して、ターゲットとなるものを予測できるようにすることです。
先ほど申し上げたように、今回のケースでは50分間のデータを収集し、その傾向やプロファイルに基づいてターゲットを予測したいと考えていました。また、ここでデータを確認する時間枠も限定しておく必要があります。
この機能には、フィルターを使ってデータを切り取る便利なオプションがあります。例えば、この例では15分間のデータを見ています。また、分析前にデータがクリーンアップされすぎないように、最初から少し範囲を絞り込みたいので、180秒から900秒までのデータだけを見ます。
ここに表示されています。それでは、これらのバッチ全体における全体的な傾向を確認したいと思います。モデルと直接関数主成分分析（PCA）に進みます。ご覧の通り、JMPはこれらのバッチ全体における全体的な傾向を見つけようとし、それを主関数として表示し、5つの異なる固有値を抽出します。これを形状関数として呼び出し、これらの製品全体の平均レベルと比較した、各バッチ間の差異を特徴づけます。
それぞれのバッチについて、非常に有益な情報が得られます。各バッチが平均的な見た目からどれだけ異なるかが分かります。下のプロファイラーを使えば、抽出されたすべてのFPCコンポーネントを簡単に操作して、それぞれの変更がどのような影響を与えるかを確認できます。
例えば、これは経過時間です。FPC 1コンポーネントの値が高い場合、トレンドやプロファイルの観点から、製品の平均製品温度にどのような影響があるでしょうか？また、マイナスの値を大きくした場合、製品温度にどのような影響があるでしょうか？
単純に言えば、FPC1 が高くなると、この期間中に製品温度の平均レベルが多少低くなったことを意味し、より負の値になると、平均レベルが高くなります。
これらの各要因が、製品温度の全体的な結果、あるいは経時的な傾向やプロファイルに及ぼす影響を個別に簡単に確認できます。これらの要素を抽出してモデルの入力として使用し、そのモデルを用いて目標値を予測します。
ここで結果をサマリーとして保存するオプションがあり、そうすると、例えばここにあるすべてのFPCコンポーネントに関する非常に便利な情報が表示されます。もちろん、異なるバッチ番号に関連付けられています。
ご覧の通り、各バッチごとにFPCコンポーネントごとに1つの数値を取得しています。これはモデル構築のための入力値となります。これは、各信号のプロファイルから直接抽出した情報だからです。そして、それに基づいて、どのような状態かを把握します。新しいバッチは平均的な外観とは異なり、それに基づいて作業を進めます。
戻って、これをモデル化するかどうかを確認しましょう。どのようにするか考えてみましょう。すべての信号のFPC成分をすべて集めたので、ここから先は非常に簡単です。例えば、一般的な回帰モデルやその他のアプローチを使ってモデルを構築するだけです。
例えば、ここでの例として、最終的な信号を取得する簡単なオプションがありました。これは相対湿度を予測するためのものでした。Xとして、さまざまなFCコンポーネントの組み合わせをすべて入力として取得しました。
その後、最終的な推定値、つまり最終的なモデルを作成し、システムに組み込むことができました。これは非常に簡単です。このモデル、つまり予測はすべて、IoTセンサーから収集したすべての信号のプロファイルに基づいており、それに基づいて目標を設定するだけです。
ここからは、モデルを抽出するだけです。構築後、モデルを抽出し、最初のモデルの抽出に戻ります。では、新しいバッチ用にこのLPCコンポーネントをどのように抽出すればよいのでしょうか？
最大の問題は、その後JMPが使えなくなることです。私の環境では、AWS上で稼働する製品に全てを組み込みたいので、モデルとFPCコンポーネントの両方を抽出できる必要があります。
モデルの抽出は非常に簡単なので、実行できます。しかし、FPCコンポーネントを正確に抽出するのが非常に難しいという問題があります。残念ながら、現時点ではJMPからこれらのコンポーネントを簡単に抽出する方法はありません。新しいバッチを作成したいからです。
この新しいバッチを使って、このモデルを使ってどのコンポーネントが適切かを推定できるようにしたいのですが、これらのコンポーネントを抽出するには非常に間接的な方法があります。それは、FPCコンポーネントの計算方法の基本に立ち返るだけです。
これを見て…もしこれを見つけたら、閉じるかもしれません。はい、ここにあります。FPCコンポーネントから抽出したテーブルに戻ると、予測値や、このFPCコンポーネントを使って信号をどのように予測するかといった積を示す列があります。
これは非常に単純なものです。この関数は、全てのデータ（今回の場合は入力した全ての履歴データ）に対して平均関数を構築しようとします。次に形状関数を作成し、バッチに基づいてこの形状関数を調整することで、各バッチと平均外観の差を補正しようとします。
私たちができることは、履歴データがあり、その履歴データに基づいて時間の経過に伴う平均値を抽出したり、この履歴データに基づいて時間の経過に伴う形状関数を抽出したりできることです。
これら2つのパラメータを取得したら、それを抽出して同様のプラットフォームに入力するだけです。そして、新しいバッチが来るたびに、このモデルに当てはめてFPCコンポーネントを計算します。
どうすればそれができるのか。このケースについては後で詳しく説明します。テーブルを作成するたびに、FPCコンポーネントの概要を抽出します。実は、形状関数も取得できます。これらはここに隠れているだけです。例えば、形状関数を見れば、これら全てが分かります。また、後ろには、時間経過に伴う形状関数を計算する式があります。
やりたいのは、このデータを直接抽出することです。また、平均値と時系列プロファイルも抽出します。ここで少し整理しておきます。簡単にするためです。これで最後なので、非表示を解除しておきます。
デフォルトでは…これも余計な機能なので、削除してもいいかもしれません。デフォルトでは、抽出したテーブルは、入力した時間範囲の中心ですべての形状関数を計算します。
やりたいことは、データをトリミングした180秒から900秒までのシェイプ関数を抽出したいということです。この列を更新するだけで簡単にできます。900秒から開始したいので、経過時間を更新するだけで、時間経過に伴うシェイプ関数の数値を簡単に取得できます。
例えば、ここに表示されている最初のウィンドウと全く同じ入力ができることがわかります。これでシェイプ関数が出力されました。これをどうやって使えるでしょうか？ すべてをまとめてコンパイルしてみます。
ここにデータテーブルを用意しました。履歴データに基づいて、例えば製品温度などの形状関数を抽出し、経過時間も取得しました。今、新しいバッチが届きましたので、テーブルに追加しました。もちろん、新しいプラットフォームではAWS//でこれらの計算をすべて行います。
新しいバッチができました。100℃から900℃までの温度範囲で取得した信号の情報です。先ほど説明した式に戻って、このモデルを構築し、FPCコンポーネントを抽出したいと思います。
私がやっているのは、まず、各時点における新しいバッチに含まれるシグナルと平均値の差を求めるだけです。Episcopalから抽出した表の結果として、この最小関数の式も得られます。残差は、シグナルと過去の日付に基づいて計算した平均値との差です。これを使って、モデルの残りの部分、つまりこの部分を構築するだけです。
やってみましょう。私が構築したのは、残差です。それぞれの関数について、FPC成分を抽出します。もちろん、切片は不要です。中心多項式を非アクティブ化することで、他の関数と全く同じ抽出結果が得られるようにします。
これを実行して、それぞれの形状関数の式を見ると、FPCコンポーネントを表すパラメータが1つあります。これは、履歴データから抽出したそれぞれの形状関数に基づいて、これらのコンポーネントをそれぞれ抽出する方法です。その後、それをモデルの入力として入力します。
新しいデータセット、新しいバッチが来るたびに、それをフィッティングし、FPC成分を抽出してモデルの入力として入力します。そうすることで、それぞれのデータに基づいて必要な推定値を得ることができるはずです。
残念ながら、先ほど申し上げたように、これはFPCコンポーネントを抽出する直接的な方法ではありません。しかし、これはその一つの方法です。これは、FPCコンポーネントの機能を用いて、私たちのセットアップにおけるシステムのパフォーマンスを予測するというアプローチです。
最後のスライドは一般的な結論です。少なくとも私たちのケースでは、システムがさらされるあらゆる変動やシステム内で発生するあらゆる事象を考慮すると、デフォルトの入力に基づいてシステムの状態を予測することは非常に困難であるということは明らかだと思います。
もちろん、可能であればシステムにオンライン制御機能を導入する方がはるかに良いのですが、これも容易ではありません。2つ目の選択肢は、異なる方法でエクスプローラーを操作する機能です。これは時系列データを分析するための優れたツールですが、現時点では主に提供目的でのみ利用可能であり、JMPから一部の要素を抽出するのは容易ではありません。
産業用システムのほとんどは、JMPに直接接続できない可能性があります。そのため、JMPに搭載されているこのオプションの機能は大きく制限されます。
しかし、これは探検家の視点から、私たちのプロセスに対する素晴らしい洞察を与えてくれました。どこに問題があったのか、そして各バッチで何が起こっているのか。以前は平均値などしか見ていなかったのですが、今では実際に…
さらに詳しく。
はい。そして時系列データですね。プロセスの観点から、その分析部分を見るのは非常に興味深いです。
まさにその通りです。それでは、ご清聴ありがとうございました。皆様にお会いできるのを楽しみにしています。
