デジタルツインとシミュレーションツールの違い:工場に合う選び方
Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.
By Mirko Peters ·
デジタルツインとシミュレーションツールの違い。両者を分けるポイント、それぞれが答える問い、そして工場長が余計な投資をせずに選ぶ方法を解説します。
Automatically translated with AI from the original post. Read the English original
シミュレーションとは、何かを変えたときに何が起こるかを確認するために実行するモデルです。デジタルツインは、実際の工場と接続された状態を保ち、ライブデータで更新され続けるモデルです。これがデジタルツインとシミュレーションツールの問題の核心であり、何を購入するか、どのようなデータが必要か、導入後に誰が保守するかを決めます。本記事は、ベンダーの提案で両方の用語を耳にし、選び方の指針を必要としている工場長のための記事です。
重要なポイント
- シミュレーションは「もし〜だったら」という問いに答えるために実行するモデルであり、デジタルツインはライブデータを通じて実際の工場と接続され続けるモデルです。
- NISTは、ツインの本質的な要素として3つを挙げています。高頻度のセンシング、信頼性の高い産業用IoT接続、そして予測のためのシミュレーションモデルです。
- シミュレーションは多くのツインの中核をなす要素です。そのため、実際に検討すべき選択は、その問いにライブ接続が必要か、それとも優れたモデルだけで足りるかという点にあります。
- まだ存在しない変更についての意思決定にはシミュレーションを選び、現在稼働中のものを監視し、制御するにはツインを選んでください。
- どのツールも、まず一つの限定された問いで試してください。そのうえで、データをどのように取得するか、どのように検証するか、結果を誰が参照できるかを確認します。
デジタルツインとシミュレーションの違いは何ですか?
まず定義から確認しましょう。ベンダーは両方の言葉を都合よく使うことがあるためです。
米国の標準化機関であるNISTは、デジタルツインを、物理的な対象を忠実に再現し、それと同期し続けなければならない、動的でデータ駆動型の仮想表現と説明しています。NISTは、成功したツインは静的なモデルではないとも述べています。そして、その本質的な要素として、高頻度のセンシング、信頼性の高い産業用IoT接続、予測分析のためのシミュレーションモデルの3つを挙げています。
3つ目の要素に注目してください。シミュレーションはツインの内部に位置しています。NISTのシミュレーションとデジタルツインに関する論文は、専門家がこの関係をどのように捉えているかを記録しています。あるパネリストは、シミュレーションを製造オペレーションのモデルとして説明しました。それは多くの場合単独で使われ、実際のシステムとは接続されていないものです。一方でツインは物理側とも同期し、ライフサイクル全体をカバーできます。別のパネリストは本質的な違いはないと考え、「デジタルツイン」は、シミュレーションの専門家が何十年も行ってきたことに対する新しい呼び名にすぎないと述べました。論文は、この議論が今もなお続いていると結論付けています。
そこで、実務的な捉え方を示します。ツールが、人が選んだ入力値を使って起動されたときにだけ動くのであれば、それはシミュレーションとみなしてください。工場からデータを受け取り続け、その変化に追従するのであれば、それはツインとみなしてください。多くの製品は両者の中間に位置しており、パンフレットの表示だけでは、どちらに当たるかは分からないものです。
例えが役立つでしょう。シミュレーションは紙の地図を使って旅行を計画するようなものです。ルートを選び、距離を確認しますが、運転中に地図が変わることはありません。ツインは、交通状況をリアルタイムで把握するカーナビゲーションのようなものです。
それぞれが答える問いは何ですか?
問いに合わせてツールを選んでください。ツールに合わせて問いを決めるのではありません。
工場シミュレーションは、まだ存在しないもの、または生産ラインで試すことのできないものに関する問いに答えます。
- 組立セルに2つ目の交代制を導入すれば、作業の滞留は解消されるのでしょうか。それとも、ボトルネックが単に別の場所へ移るだけでしょうか。
- 製品構成が複雑なバリアントの方向に移ると、リードタイムはどう変わるでしょうか。
- 2つの工程間に計画しているバッファは十分な大きさでしょうか。
- 新しいラインのレイアウトで、2年後に想定している需要に対応できるでしょうか。
デジタルツインは、今まさに稼働している工場について次のような質問に答えます。
- 作業が実際にどこまで進んでいるかを踏まえると、どの受注が遅れそうでしょうか。
- どの設備が間もなく停止しそうな兆候を示しているでしょうか。
- 今朝から、計画と現場の実態はどれくらいずれてきたでしょうか。
- ラインごとの現在のエネルギー使用量はどうなっているでしょうか。
要するに、シミュレーションは変更に関する意思決定のためのものであり、ツインは日々の稼働を操縦するためのものです。多くの工場では両方が必要で、その順序が重要です。ある変更に価値があるかどうかがまだわからない段階では、リアルタイムのデータフィードは必要ありません。また、何を監視したいかがすでにわかっていても、モデルだけでは監視してくれません。
それぞれに必要なデータは何でしょうか。
多くのプロジェクトはデータの段階で行き詰まります。そのため、デモを見る前にこの点を確認してください。
シミュレーションには、工程の明確で合意されたモデルが必要です。具体的には、工程順序(ルーティング)、サイクルタイムと段取り時間、リソース、シフトカレンダー、ロットサイズ、需要などです。多くの場合、これらはERPシステムといくつかのスプレッドシートから取得できます。作業はモデルごとに一度行えばよく、工程が変わったときに更新するだけです。手間がかかるのは、数値をラインを実際に動かしている人たちと検証する部分です。
ツインには同じ工程モデルに加えて、データフィードが必要です。NISTの一覧では、センシングと接続性が必須要素として挙げられています。つまり、誰かがこれらのデータ経路を設置し、保守し、セキュリティを確保しなければなりません。古い設備が多い工場では、これがプロジェクトの中で最も大きな部分になることもあります。ツインの品質は、その背後にある更新経路の品質によって決まります。フィードが止まると、ツインは古い状態を表示したまま、確信に満ちた様子を見せ続けてしまいます。
多くの営業の場面で本質を突く質問は次の2つです。
- 意思決定に実際に必要な更新頻度はどれくらいでしょうか。数秒ごとでしょうか、シフトごとでしょうか、それとも週次でしょうか。
- 現在すでに収集していて、信頼しているデータはどれでしょうか。
意思決定が計画会議で週に1回行われるのであれば、データを日次で更新すれば通常は十分です。ストリーミングアーキテクチャを導入すると、高価な飾りになってしまうだけでしょう。
Microsoftのツールはどこに位置づけられるのでしょうか。
Microsoftには、ライブツインの領域に向けたプラットフォームサービスがあります。Microsoft Learnによると、Azure Digital Twinsは、建物、工場、エネルギーネットワークといった環境のデジタルモデルであるツイングラフを作成するためのプラットフォームサービスです。ツインの型はDTDLと呼ばれるJSON風の言語で定義します。プロパティは、デバイスであればAzure IoT Hub経由で、業務システムであればREST APIなどを通じてライブデータから最新の状態に保たれます。グラフに対するクエリをサポートし、データを他のAzureサービスに転送することもできます。
その性質を明確にしておきましょう。これは開発者向けの構成要素であり、既製の工場シミュレーションではありません。ツインモデルとそのデータを格納し、接続するものです。キュー、段取り、シフトカレンダーを含む生産シミュレーションのwhat-if(もしも)ロジックは、別のソフトウェアが担うものです。また、Microsoftも、Azure Digital Twinsは Microsoft Fabric のデジタルツインビルダー(プレビュー)やIoT Hubのデバイスツインとは同じものではないと注意を促しています。そのため、計画を立てる前に、同僚やベンダーが指しているのがどれなのかを必ず確認してください。
レポートについては、結果をデータセットに格納し、Power BIで表示するというパターンが一般的です。これにより、管理者は傾向を把握しやすくなります。ただし、それによってモデル自体の品質が向上するわけではありません。そのため、モデルの品質を最優先事項として維持してください。
ツインとシミュレーションツールのどちらを選ぶべきでしょうか。
次の順序で質問を進めてください。ワークショップ1回で十分です。
- 意思決定の内容を書き出してください。「私たちは日付Yまでに事項Xを決定しなければならない」という1文で十分です。これがないと、どのツールも便利に見えてしまいます。
- 回答を使う人を明確にしてください。計画担当者か、工場長か、シフトリーダーか。その人のスキルによって、結果の見せ方を決める必要があります。
- 意思決定が変更に関するものか、今日の稼働に関するものかを確認してください。変更であればシミュレーションが適しています。今日の稼働であれば、ツインまたはスケジューリングや監視のツインツールが対象になります。
- 手元にあるデータとその品質を一覧にしてください。欠けている部分は正直に書き出してください。
- 更新の頻度を決めてください。リアルタイム、日次、またはオンデマンドのいずれかです。
- 最も範囲の狭いパイロットを選びます。 1行、1つの製品ファミリー、1つの問いに絞ってください。
ステップ1を完了できない場合は、そこで止めてください。何を問うべきかを知るためにプラットフォームを購入するのは、最も高くつく学び方です。
ベンダーに何を確認すべきでしょうか。
ラベルが何であれ、次の質問が当てはまります。
- モデルはどのようにデータを取得し、その更新頻度はどのくらいですか。
- 実際の結果とモデルをどのように照合し、誰が行いますか。
- ベンダーが同席しなくても、プランナーが結果を読み取れますか。
- 工程が変わったらどうなりますか。誰がモデルを更新し、どれくらいの時間がかかりますか。
- ライセンス費用以外に、今後3年間の運用にどれくらいのコストがかかりますか。
- モデルのデータをエクスポートできますか。それともロックインされますか。
自社のデータでのパイロットを依頼してください。ベンダーのサンプル工場でのデモからわかることは、自社の状況についてはほとんどありません。
長所と短所を平易に言うと何でしょうか。
シミュレーションは、特に実データが少ない場合に、安全に選択肢を検証するのに適しています。単独の問いに答えるだけであれば、設定も比較的早く済みます。その限界は、スナップショットであることです。状況が変わったら、更新して再実行しなければならず、その回答は組み込んだ前提の質に左右されます。
デジタルツインは現在の状況を把握でき、予測にも役立ちます。その代わりにコストがかかるのは、統合作業、データ管理、そしてそれを継続的に運用する人材です。また、どのツインも工場を単純化した見方にすぎないため、前提も含みます。NISTの論文も批判的な立場から同じ点を指摘しています。ツインは検証が必要で、常に単純化されたものであり、人々の意思決定を完全に捉えることはできない、という指摘です。
この2つは組み合わせて使えますか。
はい、多くの工場が最終的にたどり着く方向はそれです。シミュレーションモデルに現在のデータを入力し、工場の実際の状態に対して選択肢を検証できます。また、デジタルツインがシミュレーションモデルを呼び出し、現場の現在地点から先を予測することもできます。NISTのパネルの説明も同じパターンを示しています。生産データがシミュレーションに流れ込み、シミュレーションがオンラインでの意思決定を支える、クローズドループのアプローチです。
難しいのはアイデアそのものではありません。部品が一つの供給元から提供されることはほとんどないという点です。機械データ、ERPデータ、シミュレーションモデルには、それぞれ固有の形式と管理者があります。データマッピングと、どの部分を誰が管理するかの合意のために時間を計画してください。製造業向けのデジタルツインの枠組みであるISO 23247のような標準は、共通の用語とガイドラインを提供するために策定されました。ISOはこれを、概要と一般原則を第1部とする複数部構成のシリーズとして示しています。これを読んでもツインが構築されるわけではありませんが、チームとベンダーが共有できる語彙が得られます。
よくある間違い
- 一度きりの問いにツインを購入すること。 シフトモデルを決めるだけであれば、シミュレーションで十分です。
- ラベルを証拠と見なすこと。 3D画像のあるダッシュボードも、ライブデータが動かしていなければデジタルツインではありません。
- 検証を省くこと。 まず、先月の結果に対してモデルを実行してください。過去を再現できないモデルに、未来を任せてはいけません。
- 工場全体から始めること。 1つのラインと1つの問いを選んでください。
- 管理者を決めないこと。 誰も更新しないモデルは、数か月で時代遅れになります。
- データの経路を無視すること。 センサーや接続は、プロジェクトチームが去った後も、運用に費用がかかり続けます。
Polarisの位置づけ
問いが「もし〜だったら」から始まる場合、iFAKT Polarisも検討の候補の一つです。iFAKTは、Polarisを製造向けのAIとデジタルツインの組み合わせとして説明しており、ERPデータと製造デジタルツインを統合します。Polaris Designerモジュールは、ERPデータ、工程時間、リソース構成、制約などの入力データを、製品・工程・リソースのナレッジグラフに変換します。Polaris Simulatorモジュールは、これを基に、実際の意思決定の前に能力、人員配置、バッファのシナリオを仮想的に検証します。適合するかどうかは、データと問いによって異なるため、まずは範囲の狭いケースで試してください。
関連して調べるとよいトピック
- ツインをどこから始めるか。 プラットフォームを選ぶ前に、1つの設備またはラインと、それに必要なデータ、そして支援する意思決定を定義してください。
- シミュレーションモデルにデータを入力する方法。 ルーティング、サイクルタイム、シフトカレンダーには、最初の実行前に管理者と品質確認が必要です。
- モデルを検証する方法。 モデルの出力を、過去の期間の実際の結果と比較し、差異を書き留めます。
- 機械データとERPデータの接続。 データのマッピング、形式、インターフェースは早い段階で計画します。ハイブリッドプロジェクトが停滞しやすいのは、まさにこの統合の部分だからです。
- モデルの保守担当者。 工程が変更されるたびに誰がモデルを更新するか、また更新の頻度をどのくらいにするかを決めておきます。
次のステップ
デジタルツインとシミュレーションツールのどちらを選ぶかは、一つの文書化された決定によって最も簡単に決められます。工場で次に下す決定を書き出し、それが変更に関するものか、現在の稼働に関するものかを明記してください。その一文を次回のベンダーとの打ち合わせに持ち込んでください。