GD.findiでデジタルツインを設計する

我々は市販のソフトウエアが開発されるまで泣き寝入りをしなければならないのであろうか？そこで注目されるのがレクサー社のGD.findiだ。何故、GD.findiが注目に値するのであろうか？

1 デジタルツインを設計するツール
- 1.1 FINDIデータモデル
- 1.2 対話型モデリング
2 プログラミングが必要ないとは何を意味するか？

前回の投稿「進化するデジタルツイン」と「テスラが誘導するデジタルエンジニアリングCPSとは」でエンジニアリングの重心が物理的空間からサイバースペースへ急速に移行していると論じられた。

そしてその原動力は「原子の組み替えには多大な時間とコストが必要であるが、ビットとバイトの組み替えは適切なソフトウエアが存在すれば、瞬時にただ同然のコストで実現する」である。さらに、ギルダーの法則は「安い資源を多用し、高価な資源を節約するビジネスモデルが勝つ」と説く。つまり、適切なソフトウエアを作成して、できる限りのプロセスをサイバースペースで実現した者が一人勝ちする。テスラの躍進がそれを雄弁に物語っている。これは大変なことである。テスラは世界最高峰のソフトウエア集団を抱えており、必要なソフトウエアを自前で次々と開発し、サイバースペース内のプロセスの比率を急速に高めている。

デジタルツインを設計するツール

GDfindiは生産シミュレータ(シミュレーションツール) と位置付けられているが、実際にはサイバースペースで生産システムのデジタルツインを設計するツールであり、シミュレーションはデジタルツインを使ったアプリケーションの一つという位置付けが正しい。ここで特に注目するべきことは、GDfindiのベースになる技術は生産システムを構造解析し、一般化したデータモデルなのである。

製造業に携わる方々には「データモデル」と言うITの概念には馴染みが少ない。生産システムは外面的には千差万別であるが、内面的には共通点が潜んでいる。共通点を抽象化すると、全ての生産システムが同じ抽象化されたルールの集合体に基づき機能している事実が浮かび上がってくる。このように抽象化された高次元のモデルは一般的にはメタモデルと呼ばれている。そして、ITの世界ではデータモデルという名称が使われる。

FINDIデータモデル

このFINDIデータモデルと呼ばれるデータモデルは画期的イノベーションを可能にする魔法の杖である。まず、FINDIデータモデルは生産システムをオブジェクト指向に基づき、複数のサブシステムに分割することに成功した。

オブジェクト指向とは90年代にソフトウエア開発を飛躍的に進化させたイノベーションで、ソフトウエアの複雑性を大幅に削減する効果がある。システムを構造化解析し、複数のサブシステムに分割することに成功すると、ソフトウエアの複雑性を大幅に削減できる。オブジェクト指向が巨大ソフトウエアの経済的開発を可能にしたと主張しても過言ではない。FINDIデータモデルはオブジェクト指向に基づき生産システムを複数の要素に分割している。代表的な要素はステーション(装置)とプロセスであり、GUI上で個別に設計することが可能になった。

GD.findiの場合、生産システムを分割することにより、複雑性を約1/100程度に削減している。その為に、設計の工数も、エラーの発生率も大幅に削減される。別の言葉を借りれば、シミュレーションのエキスパートでなくても簡単にモデルを作れる難易度が実現していると言える。

そして、GD.findiのユニークな特徴は、設計された要素(ステーションとプロセス)をリレーション(関係性)と呼ばれる概念で結合することにより、デジタルツインのフレームワークが完成されるところにある。ここで一旦、構造解析により、生産システムの複雑性を大幅に削減することに成功したことを記憶していただきたい。

対話型モデリング

そして、FINDIデータモデルはGD.findiの対話型モデリング言語を可能にした。一般的にプログラミングが必要ないことが強調されるが、対話型モデリングはもっともっと奥が深い。対話型モデリング言語の基本コンセプトはユーザーが「何をモデルリングするか」を判断し、それを「どの様に記述するか」をGD.findiが管理している。ユーザーがアクションを起こすと、GD.findiがポップアップウインドーを開き、任意のオプション、またはパラメータ値の入力を可能にする。

つまり、ユーザーはGD.findiが提供するガードレールの中で、プログラミングを必要としない設計作業を進めていく。これはプログラミングが必要な従来型シミュレーションとの決定的違いである。

プログラミングさえ出来れば、何でも表現できる従来型シミュレーションはごく一部の有能なプログラマーにとっては天国である。ところが、それはプログラムを編集しなければいけない第３者のプログラマーにとっては地獄を意味する。プログラミングを担当した本人でも、時間が経てば、自分のプログラムを理解し編集することが極めて難しくなる。編集するより、ゼロから書き直した方が手っ取り早いと言われるぐらいだ。

GD.findi ではユーザーは「何をモデル化するか」の自由を持つが、「どうモデル化するか」はGD.findi が管理している。そして、モデルを理解するためにコードを読む必要が一切無い。全てがGUI上のグラフィックスと表で表現されている。それは、探し求める情報が必ず期待した場所で見つかることを意味する。つまり情報へのアクセスタイムが極めて短いのである。コードの原始林の中を探し求めるコードが見つからず彷徨うようなことがない。FINDIデータモデルに基づき、モデルが標準化された形で構造化されているので、第3者でもモデルを理解し、容易に編集することが可能である。ここで読者に理解して頂きたい事実は、誰がデジタルツイン(シミュテーションモデル)の構築を担当してもFINDIデータモデルの秩序が守られる。これはシミュレーションの経済性を飛躍的に高める。

プログラミングが必要ないとは何を意味するか？

プログラミング言語の進化は、CPUが理解できる言語である機械言語から、人間が理解し、作業しやすい言語に刻々と進化し続けている。進化のメカニズムはバックグラウンドでソフトウエアが任意の作業を支援し、ユーザーの負担を低減することである。そして、究極の言語はプログラミングを全く必要としない言語である。

GD.findiはFINDIデータモデルから導かれた高度なGUIベースのモデリング言語を実現して、プログラミングをデジタルツインの設計から排除した。これはただの「プログラミングフリー」とは別の意味を持っている。それをここで説明しよう。

GD.findiのモデリングはGD.findiが提供するガードレールの中で、設計の自由が提供され、FINDIモデルの秩序が守られることを対話型モデリング言語が管理している。これにより：

1) モデルの再利用性が実現する
つまり、一度生産システムのモデルを作成すれば、このマザーモデルをコピーして編集することにより、子孫モデルを作成することが可能である。小孫モデルの作成費は「マザーモデル作成費/小孫モデルの総数＋編集費」と表現できる。つまり、子孫モデルが作成されればされるほど、シミュレーション経費が削減される。
米国スペースX社はロケットの再利用性を実現した。再利用性は価格破壊を実現し、人工衛星の打ち上げコストが28500ドル/kgから、10ドル/kgへ削減されようとしている。コストが約3000分の1になるのである。GD.findiでも全く同じことが実現する、使い方を工夫すれば、シミュレーションのコストが3000分の1程度のレベルまで引き下げられる。

2) 構造化されたFINDIデータモデルに基づいたデジタルツインの構造はステーション、プロセスとリレーションから構成されるフレームワークと階層化された個別に設計される要素の集合体として表現される。

生産現場の人間が長年貯蓄した知識は彼らの作業を中心に経験と勘により構成されている。そこでの問題は、経験と勘を言語化する能力が残念ながら限られていることである。ところが、GD.findiが導入され、GD.findiの構造化された生産システムの表現の仕方が身につくと、今まで言語化できなかったことが、言語化出来るようになる。すなわち、現場でのコミュニケーションが円滑になり、情報の共有が豊かになる。これは現場だけではなく、現場と他の部署とのコミュニケーションも円滑になることを意味する。アップルのスティーブ・ジョップスはイノベーションとは、関連性のなかった点と点を結ぶ(関連性を構築する)ことにより誕生すると説いた。GDfindiの構造化されたモデルは現場の人間の言語化能力を高め、コミュニケーションを円滑にし、イノベーションが生まれやすい環境を実現する。

3) シミュレーションの世界には「プロセスシミュレーション」と言う概念がある。

これはプロセス、すなわち物の流れをシミュレーションとして再現しているが、生産システムの挙動をシステムとして再現していないシミュレーションをさす。

何故プロセスシミュレーションが必要なのであろうか？プログラミングを必要とする従来型シミュレーションでは、デジタルツインをシステムとして表現するために、プロセスシミュレーションの工数の何十倍もの工数が必要となる。そこで、システムの挙動を正確に表現できなくても、プロセスさえ正確に再現できれば、目標が達成されるアプリケーションがシミュレーションの対象となっていた。

それに対して、GD.findiは構造化されたFINDIデータモデルに従い生産システムのモデルが作成されるために、生産システムが常にシステムとしてモデル化される。モデルを編集してもシステムの特性が失われることがない。プログラミングされたモデルで、モデルがシステムとして機能するか確認する作業は、モデルの規模が大きい場合は、気が遠くなるほど膨大な工数を必要とする。GD.findiではFINDIデータモデルの秩序が守られれば、システムとしての機能が確保される。そして、秩序が守られていない場合はエラー信号が発生する。

読者の皆さんはすでにお気付きではないだろうか？GD.findiとは、従来の生産シミュレーションと全く異質のものである。そして、GD.findiの多様な使い方を理解し、従来型シミュレーションの概念の束縛から解放されれば、GD.findiは従来型シミュレーションと比較にならないほど大きな利益をユーザーに提供する。

イーロン・マスクは口癖のように「既存のルール、常識に囚われてはいけない」と社員に説いている。本投稿ではGD.findiが全く新しいコンセプトに基づき構築されていることを、できる限り分かりやすく説明した。「従来のルール、常識に囚われないGD.findiの使い方」とはなんであろうか？

次回の投稿はGD.findiのアプリケーションをテーマにし、読者の生産性をGD.findiを採用して高め、業績を飛躍的に高める方法について解説する。

→ GD.findi の製品情報はこちら