Concept & Technology
Innovation from LEXER

Concept & Technology Innovation from LEXER
テクノロジ編

GD.findiで「工程設計」業務をイノベーションする

~従来のシミュレーションの課題と
新コンセプトのシミュレーション技術「GD.findi」のアプローチ~

皆様もご存じのとおり、生産ラインや工場内物流などの生産システムは、カイゼンなどの現場活動では対策が難しいものです。そのため、生産準備段階で、これらの計画をより良いものに作り上げておくことは重要であり、かつ、極めて有効です。実務的には、「工程設計」や「工場レイアウト基本設計」などの活動が焦点です。このため、古くから、工程設計や工場内物流を評価するために様々な生産シミュレータが開発され、生産システムの計画をシミュレーションする試みが続けられてきました。ところが、今までのシミュレータ技術には、様々な問題がありました。

  • 操作が難しい
  • 時間がかかる
  • 価格が高い

シミュレータの専門家を要する大手企業であっても、工程設計業務において、生産ラインを計画段階でシミュレーションしている間に、(シミュレーションの時間がかかりすぎて)、量産が先に立ち上がってしまった、などという、笑うに笑えない事例は多くありました。
それゆえ、生産シミュレーションの重要性や有効性は知られていながらも、生産シミュレーションは普及しないどころか、導入した企業でさえ、だんだん、使われなくなっているのが現状です。この点を、もう少し詳しくご説明しましょう。

従来のシミュレーション技術の問題をすでに列挙しましたが、本質的な問題は、プログラミング等の高度な操作を要するために、シミュレーション技術の専門家が必要であるという点です。

残念ながらシミュレーション技術の専門家はIT領域の専門家であり、生産領域の専門家ではありません。生産現場を知らないIT専門家が造り込んだシミュレーションは、生産現場でのカイゼン的な視線が的確ではありません。言い換えれば、シミュレーション技術の専門家全てがモノづくりのツボを得ているとは言えません。起案されたプランの評価は定量的な評価はなされるものの、的確な問題対策の提案が進みません。生産現場での問題対策が分っている業務担当者の指示を受けながら修正対応する必要があります。

ここでの本質的な問題は、あるプランを修正し、シミュレーションをやり直すためには、相応の時間が必要であったことです。シミュレーションのためのパラメータ設定を変えるなどの処理だけでは多くの場合、対応できず、シミュレーションを実行させるためのプログラムを修正するなどの、大きな修正変更を行う必要があります。そのため、生産現場の担当者の修正指示を受けたとしても、その対応に相応の期間(数時間ではない、数日、場合によっては数週間)を要してしまい、量産立ち上げの早期化が叫ばれているなか、とても従来のシミュレーションを使っている時間的な余裕がなくなってきました。

また、生産シミュレーションを実施するためにはシミュレーションの専門家が必要であるため、一般的にシミュレーションを一括して請け負う社内組織を準備し、そこでシミュレーションを社内委託として実施するケースがほとんどでした。このため、生産技術や製造などの現業部門から見ると、社内発注するための費用がかかり、大きなコスト負担となっています。

しかし、コンセプト編で述べたように、今、モノづくりが置かれている環境では、生産シミュレーションの可能性を活かして生産革新を進めていかなければならない状況にあります。このため、レクサーは、これまでの生産シミュレーションの問題を解決する、新たなシミュレーション技術を開発いたしました。
レクサーの志向するシミュレーションは、専門家のためのシミュレーションではなく、現場の、業務担当者の、実務を行う方々にとってのシミュレーションでなければならない、と考えています。

そもそも、経験、知恵、アイデアは、実際に実務を行う技術者、担当者が自ら持っているものです。その知見を最大限に活用し、さらに、そこから新たな気づきを与え、そして更なる知見を生み出す活動こそことが、重要です。業務効率を高めるなどの、直接的な効果だけでなく、モノづくり現場における潜在的な価値を顕在化し、組織展開していくとともに、今まさに叫ばれている生産系の人材育成にも繋がっていきます。
実務担当者に力をつける、すなわち、「Powering 工程設計」ということです。

イノベーションする

工程設計業務をパワー・アップする!

~GD.findi によるハイレゾ工程設計により、生産準備業務の日常作業を強化する~

前節では、GD.findi を活用することで、どのように工程設計業務が革新されるかをご紹介しました。ここでは、具体的にどのように日常業務で活用するのかをご紹介しましょう。

GD.findi の優れた特徴のひとつは、シミュレーションの専門家ではなく、生産系業務の担当者が自ら、利用できることです。これにより、生産シミュレーションの力を活かすことができ、業務プロセスが大きく変わります。
GD.findi は、例えて言えば、工程設計業務のための「関数電卓のようなもの」と言えば、よいでしょう。「関数電卓」があることにより、今までの工程設計の方法が大きく変わります。

従来の工程設計は、工程設計にかかわるエキスパートが長年の勘と経験で手作り設計してきました。しかし、多品種混流や自動化等が進み、より複雑になった現代のモノづくりでは、その経験も十分に発揮できない状況です。何より、製品ライフが短くなり、量産後のカイゼンを行なっている余裕が激減している現状、いわゆる「垂直立ち上げ」を強く求められています。このため、工程設計の短期化、早期化が要求されます。ですから、今までのような「摺り合わせ型の生産準備」では勝負ができなくなりつつあります。また、量産におけるカイゼンを行う余裕がなくなってくることから、生産準備段階での工程設計は高い完成度が求められます。

ここで有効になるのが、工程設計のための「関数電卓」です。工程設計では、四則演算だけでは不十分です。足し算、引き算、積算、除算の線形演算だけでは、山積みはできても、所要量計算や物流、段取り替え、要員編成などの様々な事象を予測する非線形演算はできません。つまり、勘所を押さえた精度の高い工程設計を求めようとすると、EXCELだけでは限界があるということです。 別の言い方をすれば、「ハイレゾ(ハイ=レゾリューション)工程設計」と言ってもいいでしょう。GD.findi により、従来の経験値による「読み」を圧倒的に凌駕する分解能を提供します。パワー・ツールを活用することにより、工程設計の方法を大きく変えていくことが可能です。

concept_hires1

ここで、GD.findi が追及しようとしている工程設計業務でのパワー・ツールの力とは何かをご説明します。まず、基本的に以下のような計画作業を行うことを目的とします。

1)
工程設計で要素作業工数の山積み・山崩しを行う
2)
使用設備、工場レイアウト等のフロアプランを策定する
3)
段取り作業、工程間搬送等の付随・付帯時間を加えて、山積み・山崩しを行う
4)
製品切り替え、段取り替え等の動的要素を加えて物量要件を明らかにする
5)
工程間在庫に対応するストック場等の確保を行う
6)
工程間搬送、工場内の物流経路を策定する
7)
作業者編成、要員計画を立案する

(ここでの「要素作業工数」は、生産プロセスにおける要素作業時間を言います。工程間搬送の時間や段取り時間等の時間は含まれません。)

ここでは、工程設計のご専門の皆様にご説明する必要はないとは思いますので詳細しませんが、1)、2)で工程設計の基本的なポイントを押さえたうえで、変動要素が大きい3)、4)、5)のようなポイントを精査・検証していくことになります。
GD.findi では、これらの作業を行うために、設計(計画・編集)機能と評価機能を準備しています。GD.findi を用いて工程設計を行う業務の流れと、そこで活用する機能をご紹介します。
GD.findi では、以下の図に示すような流れで、作業を進めていきます。これを簡単にご説明しましょう。

concept_change1

① 生産プロセスの定義 まず、生産プロセスを定義します。生産プロセスは、要素作業が生産の流れとして対らなったものです。要素作業は工数(サイクルタイム)を与えたうえで、要素作業工数グラフを表示して、生産プロセス全体の要素作業工数を確認します。

生産プロセスの定義

尚、生産プロセスは多くの要素作業を持つのが一般的であるため、既存のデータを読み込む機能を準備しています。EXCELやテキスト系エディタから、要素作業名、要素作業時間、要素作業の流れ(連結情報)などを、一括して入力することができます。

エクセルからの一括コピペ

➁ フロアプランの定義 次に、フロアプランや設備計画、また、物流通路などのフロアプランを定義します。工場図面を下絵に取り込み、それをなぞるようにして、フロアプランに設置するステーションの位置と大きさや、物流通路を定義します。

レイアウト定義の図

ここでのポイントは、生産プロセスとフロアプランを別々に(独立に)定義できることです。生産プロセスは製品に依存しますから、製品構造を得たうえで生産プロセスを定義します。また、フロアプランは既存であるとともに、多くの製品を同時に、また、時代を追って生産しなければなりませんから、ある製品だけに対応するものではありません。ですから、製品の生産プロセスとフロアプランを別々に(独立に)定義できることは重要な意味があります。
ちなみに、これまでの生産シミュレータはこのような考え方はなく、フロアプランにおける設備に対して、製品が流れる条件を割り付けることでシミュレーションを行います。これでは、製品が変わるたびに、設備に対する条件を個別に造り込んでいかなければならず、とても手間のかかる仕事でした(次節も参照ください)。

③ 要素作業とステーションの関係付け(山積み) GD.findi では、別々に(独立に)定義した製品の生産プロセスとフロアプランの関係づけを行います。要素作業をフロアプラン上のステーションに、ドラッグ&ドロップで割り付けることにより山積みを行い、ライン・バランスを整えると共に、製品を生産するラインを確定します。

concept_change2

ここまでの操作により、各プロセスがどのステーションで実行されるかが決まりましたから、ステーション毎のフロアプラン山積みを見て、ライン・バランスを確認することができます。これにより、おおよその生産ライン毎のバランスを見て取れますが、この時点ではライン・バランスは静的な要素作業工数の積み上げによる評価のみですから、搬送時間や段取り替え等が影響する付随時間、付帯時間はまだ、含まれていません。
一方、この段階でライン・バランスの問題があれば、ステーション毎に積み上げられた要素作業を他のステーションへ山崩しを行い、ライン・バランスを整えることができます。

要素作業工数の山積みによるライン・バランスの確認

尚、ここまでの作業は静的な評価ですから、EXCEL等のツールでも決してできないわけではありません。しかしながら、生産プロセスや工程設計をデータベースに体系立てて管理することができるため、GD.findiを利用いただければ、業務管理という面でとても有効です。さらに、山積みに加えて、段取り替え、物流、工程間在庫、要員編成などの評価を行おうとすると、EXCEL等ではとても困難な作業になります(まず、不可能です)。このような動的な評価は工程設計ではとても重要であり、これらをGD.findiで行っていく方法をご紹介します。

④ 生産計画を与えてシミュレーションを実行いよいよ、GD.findiの生産シミュレーション機能を利用して、動的な評価を行っていきます。
生産シミュレーションを行うためには、何らかの生産計画を与える必要があります。生産計画を与えなければ、何を何個作るのかがわかりませんから。ただし、ここでの生産計画とは、実際に生産する生産計画というより、仮にこの製品を何個作るとしたらという、仮説としての生産計画です。生産準備の段階では、生産能力目標自体は定まっているものの、生産ロットや投入順などの量産における詳細な計画は決まっていないのが普通です。
生産計画設定パネルにより生産計画を与えることで、生産シミュレーションの準備は完了です。生産シミュレーションのクラウド・サービスを起動すれば、「生産レンダリング」ボタンを押していただくだけで高速な生産シミュレーションが実行されます。
尚、「生産レンダリング」とは、これまでに設定された情報を元にシミュレーション演算を行うことにより、生産工場における一連のモノの流れ、人の流れを求めて、可視化することです。

⑤生産シミュレーション結果の表示と分析生産レンダリングが終了すると、生産工場におけるモノの流れ、人の流れを可視化することができます。図に示す生産ダッシュボードを操作することにより、どの時刻にどれだけの物量が在庫しているのか、また、人の流れがどのように動いているのかなどを、アニメーション表示として確認することができます。

また、生産シミュレーションを行うことで搬送時間や段取り替え等の付随時間、付帯時間を求めることができるため、これらの動的な要素を加えた山積みを表示して、精度の高いライン・バランスを確認することができます。
勿論、この段階でもライン・バランスの問題が見出されたのであれば、生産プロセスの要素作業を他のステーションへ山崩しを行うことができます。
さらに、GD.findi が出力する流動数線図を使えば、様々な工程要素が影響するモノの流れを一瞥することができます。まさしく、シミュレーションならではのハイレゾ工程設計です。図に示すのは、上から下に工程の流れ、左から右に時間の流れ、この2つの軸の中で、各生産ロットがどのように流れていくかを表しています。
生産プロセスの時間遷移を表しますから、それぞれの流れの傾きがきついほど、生産性が高いことを表します。そして、初めの工程から最終工程までの時間がリードタイムとなるわけです。また、傾きが緩くなっている工程は、その工程で生産速度が遅くなっている、すなわち、ボトルネックとなっていることを意味します。

このように、GD.findi は、生産シミュレーションではありますが、工程設計の一連の流れをサポートいたします。言い換えると、GD.findi は生産シミュレーションが連動した工程設計ツールなのです。従来にない高い分解能(ハイレゾ)で様々なプランを高速に評価できることで、従来、勘と経験を有する専門家でも検証が難しいプランを的確に判断することができます。

concept_hires

独立性を有するデータ・アーキテクチャ

~フロアプランと生産プロセスが独立したデータ・アーキテクチャによる
プランニングの柔軟性~

GD.findi の大きな特徴のひとつに、フロアプラン定義と生産プロセス定義が独立している、という技術があります。「独立」とは、お互いの関係を意識することなく、無関係に設定されている、ということです。フロアプランと生産プロセスは、生産においては勿論、密接な関係がありますが、生産準備の段階では確定的に関係が決まっているわけではありません。製品設計の段階で、製品構成や生産方法、工法が決まり、作業標準書が作成されて、工程設計の作業が始まります。
そもそも、生産プロセスは、フロアプランというよりも、製品設計に密接に関係するものです。そののち、工程設計として、生産性や稼働率等を配慮しながら、どの作業をどのステーションで実施するのかという検討を行います。ここでは、様々な割り付けパターンが考えられますから、多くのケースを検証しながら、設計を進めていきます。そして、この活動の中で、フロアプランと生産プロセスの関係が決められていきます。ですから、フロアプラン定義と生産プロセス定義は独立であることが必要であるとともに、生産シミュレーションを利用して生産準備活動を実務的に行う上で、データ・アーキテクチャとしての重要なポイントとなります(当社の特許技術)。

concept_change3

ちなみに、従来の生産シミュレータには、このような技術概念はありませんでした。多くは離散的シミュレーションという技術が基本となっており、各ステーションに製品の流し方の条件を与えることで、シミュレーションを動かしています(図を参照)。つまり、各ステーションの定義と、そのステーションに対してモノを流す条件の定義で成り立っています。

ここでの問題は、流すモノや流すステーション(ライン)を変更したいとき、各ステーションの条件が記述されたプログラム(スクリプト)を一つ一つ変えながら、修正を加えなければなりません。このため、修正に専門家が必要であるとともに、大きな手間がかかってしまいます。
もう一点、各ステーションに製品の流し方の条件を与えることの本質的な問題は、シミュレーションの進め方に影響を及ぼすことです。「モノの流れを定義」するのではなく、「モノを流す条件を定義し、結果的にモノの流れ方を検証する」、ということになってしまいます。

本来、工程設計はどのようにモノを流すかという「意図」があり、そのうえで工程設計やステーションへの工程割り当てがあることが自然です。一方、従来の生産シミュレータでは、その「意図」を定義することはできず、結果が意図に合っているかどうかを確認する流れになってしまいます。これでは、工程設計というより、工程設計された結果を後追いで検証する、という役割になってしまいます。このような本質的な問題を解決するために、GD.findi は開発されました。

concept_change4

ここで重要なことは、独立に定義されたフロアプラン定義と生産プロセス定義を、どのように連携させていくかという技術です。GD.findi では、生産プロセスを選び、ドラッグ&ドロップすることでフロアプラン中のステーションに割り当てることができます。このような直観的な操作だけで、フロアプラン(ステーション)と生産プロセス(要素作業)が連携していきます。尚、ここでは1対1対応だけではなく、複数の要素作業をひとつのステーションに割り当てること(1対多対応)も可能です。この作業により、連携した情報はGD.findi データベースに格納され、目的とする製品を生産するステーションが決定されます。そのあとは、生産計画を設定して生産シミュレーションを実行するだけで、モノの流れを検証することができるわけです。

concept_change2

要員、物流等アクティビティのインテリジェントな制御

~ノンプログラミングで動的な生産アクティビティをシミュレーション~

ここまで、GD.findi の持つ工程設計に対するコンセプトやアプローチ、そしてデータ・アーキテクチャをご紹介しましたが、GD.findi には、工程設計に関わる技術者が共通に持っていらっしゃる神経質で分析が難しい課題を支援する機能を持っています。

工程設計では、山積み、山崩しなどの静的な分析は、EXCELなどを利用しても対応できるものの、要員編成、物流、工程間在庫の所要量など、変化する状況が影響を与える要素については動的な分析が必要で、これはEXCEL等では対応することができません。一方、このようなポイントが工程設計では極めて重要になります。生産シミュレーションを使わなければ、勘と経験で決め打ちするしかありませんでした。なぜ、そのような設計になったかを、社内DR(デザイン・レビュー)等で問われても、合理的に説明することはできませんでした。

コンセプト5-1

GD.findi は、このような問題に対応するため、スマートな生産アクティビティ・コントロール技術を持っています。ここで「生産アクティビティ」とは、作業者や物流機器、ツール等の、動的な配置、移動要素を持つ生産工場での要因のことを言います。生産アクティビティは設備の稼働率、リードタイム、生産能力、工程間在庫などの様々な要素に密接に関係しており、これらを的確に設計することが重要です。一方、従来の生産シミュレータにおけるこれらの制御は個別にプログラム(スクリプト)を記述して条件設定を行わなければならないために専門家が必要で、かつ、非常に手間と時間のかかるものでした。生産シミュレータの本質的な問題です。

GD.findi は、この問題を抜本的に解決しています。GD.findi では、従来の生産シミュレータが必要としていたような、プログラム(スクリプト)記述による条件設定は必要ありません。プログラムで条件を記述しないで生産シミュレーションでの生産アクティビティ・コントロールを行えることは、GD.findi の優れた特徴のひとつです。

それでは、GD.findi の、生産アクティビティのインテリジェント・コントロール機能をご紹介しましょう。
作業者や物流、ツールなどの生産アクティビティの要素は動的(状況に応じて変わっていく)なものであり、最も生産シミュレーションの本領を発揮するところです。今まで、その行動特性を定義することが難しい課題でしたが、GD.findi では、生産アクティビティの行動特性を組み込んだオブジェクト群を開発し、この問題を大幅に解決しました。
GD.findi の生産アクティビティとして、以下の3つを準備しています。

  • 作業者アクティビティ
  • 搬送アクティビティ
  • ツーリング・アクティビティ

concept_change9

これらは生産工場で欠くことはできない要素で、なおかつ、これらは工程設計に大きな影響を与えます。GD.findi では、これらの生産アクティビティを極めてシンプルな操作で設定し、生産シミュレーションすることができます。 具体的な操作としては、これらの生産アクティビティを、すでに定義された「フロアプランと生産プロセスの関係」に割り付けていくことで実現します。ご承知の通り、生産アクティビティは生産プロセスだけに対応するものではなく、ステーションだけに対応するものではなく、要素作業がステーションに割り付けられた状態に対応するものです。ですから、生産アクティビティの設定の方法は、「ステーションが持っている(割り付けられた)要素作業への関係」対して、設定することとなります。

<要員編成への適用>まずは、作業者の要員編成へ適用する例をご紹介しましょう。例えば、作業者は以下のようなミッションを持つはずです。

  • ステーションAで、製品Pのプロセス3を作業する
  • ステーションAで、製品Qのプロセス2を作業する
  • ステーションAとステーションBの両方を担当し、製品Pのプロセス3と製品Qのプロセス2を作業する

決して、作業者はステーションに固定されて定義されるものではなく、また、製品に固定されて定義されるものではありません。ステーションに割り付けられた生産プロセスに対して、作業者が対応することを指示されています。GD.findi では、作業者が割り付けらえたステーションに対して、その製品毎に作業者を生産アクティビティとして割り付けることができます。
具体的な操作画面をご紹介しましょう。図に示すのは、作業者を多工程持ちさせる場合のGD.findi の操作画面に説明を加えたものです。

コンセプト5-4

作業者に多工程持ちさせる設定は、ステーション・アクティビティに対して作業者を設定するだけのシンプルなものです。生産アクティビティ設定パネルを開けると、各プロセスがどのステーションに割り当てられているかを、一覧することができます。この各プロセスに対して、要員リストから要員を選び、割り当てるだけで終了です。尚、要員はチーム構成設定パネルで、複数のチーム、それに所属する作業員を定義することができます。ここでは、各作業者の名前と共に、能力や技能を設定することも可能です。 このようなシンプルな操作だけで、多工程持ちの生産ラインをいとも簡単に設定し、生産シミュレーションすることができます。

<工程間搬送への適用> 次に、工程間搬送において、状況に応じた挙動をする生産アクティビティの例をご紹介しましょう。工程間搬送は、一般的に同じ搬送作業を繰り返すわけではなく、状況に応じて搬送先や搬送タイミングが変わってくるものです。例えば、後工程の稼働を見ながら、前工程から後工程への搬送するタイミングや量を調整するような場合は多くあります。

GD.findi では、複数のステーションで同じ要素作業を持たせることができます。図に示すように、要素作業を複数のステーションに割り当てるだけです。この場合の検討事項は、複数、割り付けられた後工程のステーションは、同じ稼働をするとは限らないことです。いわゆる「チョコ停」も起きる、また、後工程へ搬送する際には搬送時間がかかりますから、ステーション間の距離に応じて搬送時間が変わる、また、ステーションの能力そのものも、個別の機械能力によって変わってくるものです。このように、後工程は均一に動作しないものですから、これに対応して、前工程から後工程への搬送も、状況を見ながら適切な搬送を行わなければなりません。例えば、以下のような優先度が考えられます。

  • 工程前バッファ在庫量が少ないステーションから搬送する
  • リードタイムが短い(生産能力が高い)ステーションから搬送する
  • 前工程から距離的に近いステーションから搬送する
  • 動かしたいステーション(品質が良い、チョコ停が少ない等)の稼働が止まらないように搬送する
  • 優先的に償却したいステーションから搬送する
  • とりあえず、並んでいる順番に搬送する

concept_change8

このような優先度を従来の生産シミュレータで設定するためには複雑なプログラミング(スクリプト)を開発する必要がありましたが、GD.findi では生産アクティビティの各要素に対して、挙動特性に対応する「ビヘイビア」を設定するだけで対応できます。 生産アクティビティの設定パネルで、搬送担当の作業者に対して、その振る舞いを指定する「ビヘイビア」を設定しておくだけで挙動を変えることができます。ここでの「ビヘイビア」は、例えば、以下のようなものが準備されています。

FI /First In
バッファに存在する部品の先着順
NE /Near
後工程の距離が近いステーションを優先
LO /Long Cycletime
サイクルタイムの長いステーションを優先
SH /Short Cycletime
サイクルタイムが短いステーションを優先
FT /Fixed Time
スケジュール・テーブルの設定により搬送

「ビヘイビア」には、パラメータを付加して、その振る舞いを詳細に設定することもできます。
尚、これだけで、工場内で発生するすべての挙動を記述できるわけではありませんが、工程設計段階において、押さえておかなければならない搬送挙動は検証することはできるでしょう。重要なことは、搬送の微細な挙動制御ではなく(AGVの動作制御プログラムを開発するわけではありませんから)、工場全体の生産性や稼働に及ぼす搬送の問題をマクロにかつ、機敏に求めることです。生産システム全体の概念設計を実施し、コンセプトを明確に位置づけることが肝要です。
そして、ここでご紹介した「ビヘイビア」は、今後、拡張的に開発されて、より幅広い挙動を設定できるように成長してまいります。

<工場内物流への適用>前節では工程間搬送についてご紹介しましたが、工場内の物流は、皆様にはご関心のあるところと思います。GD.findi では、工場内物流を記述し、シミュレーションする仕組みを有しており、シンプルな操作で、工場内物流を設計し、評価することができます。 まず、GD.findi における工場内物流の考え方をご説明します。GD.findi では、工場内物流を取り扱うために、「通路」と「経路」の概念を持ちます。「通路」とは、工場内で搬送するために準備された線分集合の情報です。そして「経路」とは、「通路」として定義された線分群を使って、当該工場内搬送の起点から終点まで移動させる経由情報です。以下に「通路」と「経路」の概念を図示します。「経路」は、「通路」の一部を使って定義されることになります。

pickup_arch_2

実際に、GD.findi で定義された「通路」と「経路」をご紹介しましょう。フロアプランペインで、マウス・ドラッグなどのオペレーションで、容易に通路を設定しておきます。次に、「経路」の設定ですが、これは、ユーザが記述するのではなく、搬送元と搬送先の情報から、GD.findi が自動的に設定します。まずは最短距離をリコメンドしますが、ユーザの判断により、遠回りのルートでも必要とあれば、GD.findi が生成するルート・リストから、必要なルートを選択することだけで、容易に設定が可能です。

pickup_arch_1

GD.findi では、フロアプランデザインにおいて、搬送元、搬送先のステーションが配置された位置、各ステーションからステーション外部へ搬送、搬入する位置(「ポート」と言う)、そして「通路」の情報を利用して、自動的に最適な「経路」をリコメンドする機能を持っています。そのため、ステーションの位置や、「ポート」の位置、そして「通路」をマウス・ドラッグなどで自由に変更しても、最適な「経路」が自動的に選択されるのです。煩わしい経路設定の定義を必要とせず、作りたいフロアプランを想いのままに描けば、それに対する経路が自動的に対応し、工場内物流の評価が機敏に行えます。

クラウド・サービスに最適化した離散系シミュレーション・エンジン

~3階層アーキテクチャによる高速シミュレーションの実現~

ここまで GD.findi の基盤とする技術をご紹介しましたが、これらの背景にはシミュレーション・エンジンの基盤があります。シミュレーション演算としては離散系をベースとする内部演算を行い、シミュレーション結果を算出します。ここで、データ・モデルが複雑になればなるほどシミュレーション演算の負荷が大きくなり、演算時間に時間を要します。そのため、GD.findi では、独自のアーキテクチャにより、シミュレーション演算を最適化する機構を開発し、工場内の大規模な生産シミュレーションでも高速演算を可能としました。

具体的には、ユーザ定義モデル/中間コード・モデル/実行モデルの3階層アーキテクチャにより構成される機構を持ち、これにより高速演算を実現しています。図に示すように、ユーザが定義したモデルは GD.findi の中間コード・モデルに一旦、コンパイル(変換)されます。中間コード・モデルは GD.findi のシミュレーション・エンジンの実行に最適化された形式であり、シミュレーション演算実行時に実行モデルにローディングされ、最適化された状態でシミュレーション演算が実行されます。

concept_arch1

このように、独自の3階層アーキテクチャを元に最適化された実行モデルへの動的コンパイルを行うことで、高速演算を実現いたしました。

スクイズ(絞り込み)シミュレーションによるチャンピオン・プランの造り込み

さて、GD.findi の大きな特徴は「絞り込んでいくことが得意」という点です。従来の生産シミュレータを使った検証は、作り上げられたプランを確認のために評価するだけでした。つまり、シミュレーションを一回、行って終わりということです。これは、生産シミュレーションを行うための準備に多大な工数や時間がかかってしまうため、色々なプランにチャレンジできないという技術的問題があったからです。

GD.findi では、はじめは緩い制約条件で検証しながら、徐々に制約条件を追加して、プラニングをブラッシュアップしていくことができます。 具体的には、初期プランに対して、設備制約や金型などのツーリング制約、さらには搬送の制約や作業者の制約を加えていきます。

一方、製造コストや工程間在庫の状況、またリードタイムや稼働率等の評価指標を確認しながら、プランを修正して絞り込んでいくことができます。 これは、従来にない新しいアプローチ、運用で、多くの初期プラン候補群から、チャンピオン・プランを導出していきます。これを、我々は、スクイズ・シミュレーション(Squeeze Simulation)、つまり、絞込みシミュレーションと言っています。

スクイズ

SIMコンセプトについては
下記をご覧ください。
生産システムシミュレータ
GD.findi は下記をご覧ください。
gd.findi
gd.findi


コンセプト&テクノロジ

関連ページ


Informationimage

生産システム設計WEB講座

生産システム設計WEB講座

第4回 ものづくり日本大賞経済産業大臣賞受賞

第4回 ものづくり日本大賞経済産業大臣賞受賞

Tech Magazine
Practice of GD.findi

gdfindi_katsuyou

Concept & Technology
Innovation from LEXER

コンセプト&テクノロジー

Seminar
Innovative technologie

セミナー

Dialogue
Talk with men of wisdom

対談

Column
Message from the Intellectuals

コラム

鳥取県知事ビデオレター

Youtubeが御覧いただけない方はこちらから動画ファイルをダウンロードしてご覧ください。

Books

  • book4
  • book1
  • book2
  • book3
PAGETOP