JP4587246B2 - コンピュータ化されたサプライチェーン計画の方法 - Google Patents

Description

【０００１】
発明の背景
企業内サプライチェーンのロジスティクス上の計画を含むサプライチェーン計画（「ＳＣＰ」）は、今日の多くの製造会社の成功に欠くことができない。たいていの製造会社は、顧客要求に応えて製品のタイムリーな配送を保証するために、なんらかの形式のコンピュータ化されたサプライチェーン計画を使っており、それらの生産プラントの制御はこれに依存している。一般に、サプライチェーン計画は本質的には階層的であり、それは顧客オーダーに連動する物流および生産計画から、材料と能力所要量の計画にまで拡大し、現場スケジューリング、製造施工および製品の展開に至っている。サプライチェーン計画は、生産要求を満たすためのコンポーネントの既成供給から、工場から顧客に至る完成品のタイムリーな輸送に至るまでの、生産の異なった局面において、円滑な機能を果たすことを保証する。
【０００２】
最新のサプライチェーンはしばしば巨大なデータのアレイを含んでいる。変化している要求と能力に応えて、サプライチェーンにおける計画を作り、そしてダイナミックに修正する計画アプリケーションは、サプライチェーンを通しての材料の流れに関するデータに対して迅速なアクセスを必要とする。サプライチェーンの効率的なオペレーションは変化に順応する種々の計画の能力に依存する。そして必要とされるデータが蓄積される方法は、それがアクセスされることができる容易さの程度を決定する。
【０００３】
従来の関係モデルでは、サプライチェーンデータは多数のリレーショナル・データベーステーブル内に蓄積される。もし製造オーダーのパラメータが変えられるなら、そのような変更によって影響を与えられるサプライチェーンの局面のすべてはリレーショナルテーブルを使って再度計算されなくてはならない。変化した能力に応えて計画アルゴリズムが製造オーダーの日付および／または量を変える前に、例えば日付および／または量の変更が他の生産および販売オーダーに与えるであろう影響を考慮に入れなくてはならない。このような計算は非常に複雑であって、そしてその変更によって影響を与えられるであろうすべての他のオーダー、材料およびリソースに関するデータに対してそのアルゴリズムがアクセスすることを必要とする。従来のモデルでは、リレーショナル・データベーステーブルを通してトレースすることによって、その情報が計算されているべきであった。このような計算は扱いにくく、そして遅れ計画(ディレイプランニング)は不必要な機能を果たす。
【０００４】
そのため、コンピュータ化された方法によって、サプライチェーン計画に関係するすべてのデータが最も効率的な、そして有用な方法で利用可能にされる必要がある。このようにして、計画機能のランタイムを劇的に減らすことを可能にし、こうして、改善された方法で所定のコンピュータリソースを用いて、必要とされる生産プロセスの制御を可能とする。
【０００５】
発明の要約
この必要に対処するために、本発明はオブジェクトを蓄積するための、データモデルに関する。このオブジェクトは企業全体のサプライチェーンに沿ってロジスティクスプロセスを計画するために重要である。データ構造が規定され、それによって生産工程の個別のワーキングステップがアクティビティとして規定され、そしてそのようなアクティビティの組織化されたグループがオーダーとして規定される。もしあるとしても、そのアクティビティは１つを越えるリソースに割り当てられることはなく、そしてそのアクティビティのためのスタートおよびフィニッシュ時間と、そのアクティビティが現在スケジュールされている何らかのリソースと、そして、もしあるならば代わりのリソースのリストとに関する情報を含んでいる。時間計算だけを表現しているアクティビティは、リソースに対応する必要はない。アクティビティは補助的オブジェクトを通して互いにリンクされる。そしてそのオブジェクトはアクティビティ間の最小・最大の時間に関する情報を含んでいる。オーダーは、インプットおよび／またはアウトプットインターフェースノードを含んでいることもできる。これはそのオーダーの中でアクティビティによって消費され、そして生産される材料を表している。１つのオーダーから作り出される材料の数量を表現しているアウトプットインターフェースノードは、その材料を必要とする他のオーダーから、それぞれのインプットインターフェースノード(複数)あるいはノード(単数)に補助オブジェクトを通してリンクされる。オーダーアンカーが規定され、それによって計画アルゴリズムがデータベーステーブル内のそのオーダーナンバによって、データ構造内のオーダーを容易に参照することができる。計画オブジェクトアンカーは、計画アルゴリズムが所定の材料に関するすべてのオーダーにアクセスすることを可能にし、そしてリソースアンカーはそのリソースのためにスケジュールされたすべてのアクティビティにアクセスすることを許容する。
【０００６】
さらに特に、本発明は１つのデータモデルを含むコンピュータ化されたサプライチェーン計画に関する方法を提供する。前記データモデルは、少なくとも１つのアクティビティを含む少なくとも１つのオーダーを含んでいる。ここにおいて前記少なくとも１つのアクティビティの各々は、生産計画展望からの個別の作業ステップを表し、前記少なくとも１つのアクティビティのそれぞれは前記オーダーのすべての直接的に次のアクティビティに参照されてリンクされ、そして前記少なくとも１つのアクティビティのそれぞれは前記オーダーのすべての直接的に前のアクティビティに参照されてリンクされる。
【０００７】
望ましい実施例がサブクレームに明記されている。
【０００８】
概要としては、インスタントデータモデルを使ったサプライチェーン計画の以下の特徴と達成度とが注目される。
【０００９】
本発明は製造工程データを蓄積することを可能とし、それによってそれらが必要とするデータに最も効率的なアクセス可能性をもつ計画アルゴリズムおよびアプリケーションプログラムを提供する。
【００１０】
このデータは、サプライチェーンに沿った材料およびオーダーの進捗を反映する論理的方法で蓄積される。
【００１１】
製造工程における個別の作業ステップを表現している別々のデータ要素が定義され、そして前記要素間の関係が蓄積される。
【００１２】
それぞれの作業ステップについての特定情報が、開始時間、終了時間および作業ステップがその上で実行される、または実行されるかもしれないリソースを含む、それらのデータ要素とリンクされる。
【００１３】
製造工程における作業ステップのグループが計画アルゴリズムによってアクセスされることができるオブジェクトとして組織化され、そして作業ステップの前記グループ間の関係が蓄積される。
【００１４】
データベーステーブルを提供することによって、計画アルゴリズムは、製造工程における作業ステップのどのような組織化されたグループへも効率的なアクセスを持つ。それによって作業ステップのグループのそれぞれが、データ構造におけるそのロケーションに参照される。
【００１５】
データベーステーブルを提供することによって、計画アルゴリズムもまた、特定の時刻において所定のリソースによって行われた作業ステップへの効率的なアクセスを持っている。それによってそれぞれのリソースによって行われたすべての作業ステップの日付と時刻とが、そのリソースに参照される。
【００１６】
ベーステーブルを提供することによって、計画アルゴリズムはさらに、特定の材料を作るか、あるいは消費することに関与する作業ステップの組織的化されたグループへの効率的なアクセスを持つ。それによって、材料を識別する情報が、作業ステップのこのような組織化されたグループのそれぞれのインプットあるいはアウトプットに参照される。
【００１７】
図面の簡単な説明
図１はオーダーとそのアクティビティの間の関係を表現した図である。
【００１８】
図２はオペレーションをするためのアクティビティの融合を表現した図である。
【００１９】
図３はオーダーの入出力インターフェースノードを表現した図である。
【００２０】
図４はインプットアクティビティ、アウトプットアクティビティと、そしてインプットあるいはアウトプットがないアクティビティを表示した図である。
【００２１】
図５はアクティビティ間の時間的な制約条件がどのようにモデル化されるかを表示した図である。
【００２２】
図６はオーダーの間の時間的な制約条件がどのようにモデル化されるかを表示した図である。
【００２３】
図７はペギングを持つ単純なオーダーネットワークを表わした図である。
【００２４】
図８はオーダー間のペギングがどのようにモデル化されるかを表わした図である。
【００２５】
図９はオーダーアンカーとオペレーションアンカーを表わす図である。
【００２６】
図１０は計画オブジェクトアンカーを表わす図である。
【００２７】
図１１はリソースアンカーを表わす図である。
【００２８】
発明の詳細な説明
図１に示されるように、オーダー１０はいくつかのアクティビティ１１を集めたグループ化された組織単位を表している。それぞれのオーダーは、そのアクティビティネットワークの最初のアクティビティと最後のアクティビティを指定している。このため、オーダー１０はアクティビティ１２およびアクティビティ１３を指定する。それぞれのアクティビティ１１は、そのオーダーへの参照１４を含んでいる。図２で描写されるように、オーダーにおいて実行されるべきアクティビティ１１ａ、１１ｂおよび１１ｃのチェーンのような関連したアクティビティは、「オペレーション」２０内に互いにグループ化されて、プランニングテーブルの上でそれぞれのアクティビティを個々にマップすることを避けることができる。
【００２９】
図３に示されるように、オーダー１０のようなオーダーは１つまたはそれ以上のインプットインターフェースノード３０および／または１つまたはそれ以上のアウトプットインターフェースノード３１を持つことができる。それぞれのインプットインターフェースノード３０は１つの材料を表している。インプットインターフェースノードはまた、必要とされる材料の数量と、その材料の時間要求と、そして必要とされる材料の数量と他のオーダーあるいは在庫によって配付された数量との間の差異から得られるその材料の欠乏についての情報を含む属性を持っている。それぞれのアウトプットインターフェースノード３１は、作られた材料のタイプ、材料の数量、材料の時間アベイラビリティおよび他のオーダーにまだ届けられていない生産された材料の数量から得られるその材料の余剰のような、類似の属性を持っている。それぞれのインプットインターフェースノード３０は、アクティビティ１２を参照するかもしれない。もしそうであるなら、それが表している材料は消費されている。それぞれのアウトプットインターフェースノード３１はアクティビティ１３にポイントをする。もしそうであるなら、それが表している材料が作られている。もしアクティビティ１２が材料を消費するなら、このアクティビティのすべてのインプット材料は一点鎖線矢印３２ａによって追跡されることができる。これはアクティビティ１２からインプットインターフェースノード３０までポイントしている。もしインプットアクティビティ１２が１つを越える材料を消費するなら、矢印３２b がインプットインターフェースノード３０ａを次のインプットインターフェースノード３０ｂに結び付ける。そしてそれは同じインプットアクティビティ１２上にリンクする。無限の長さを持つことができるインプットインターフェースノード３０のチェーンが、どの材料が問題のオーダーのために必要とされるかを確認することを可能とする。これはアウトプット材料のための材料表が決定されていることを意味する。同様に、アクティビティのアウトプット材料は一点鎖線矢印３４によってトレースされることができる。これはアクティビティをアクティビティ１３の第１のアウトプットインターフェースノード３１に結び付ける。もしいくつかのアウトプット材料があるなら、矢印３３はアウトプットインターフェースノード３１ａを次のアウトプットインターフェースノード３１ｂに結び付ける。これは作られた第２の材料を表している。インプットインターフェースノード３０のように、このチェーンは無限の長さを持つことができる。
【００３０】
図４は、オーダー１０がインプットあるいはアウトプット材料がないアクティビティ４１と、そしてまたアセンプリ処理４２のようなアクティビティを持っていることを示しているが、これら両方ともが材料を消費し、そして作っている。材料の在庫あるいは購入オーダーは、１つのアウトプットインターフェースノード３１を持つ、そしてインプットインターフェースノードあるいはアクティビティのない、１つのオーダーによってモデル化される。しかしながらもし、購入オーダーをモデル化する上で、ベンダーの能力が考慮に入れられるべきであるなら、購入オーダーは（可能な限り正確に）ベンダーの利用可能能力を表現している少なくとも１つのアクティビティを含んでいなくてはならない。複数の購買オーダーが「スケジュールライン」の中にまとめられる事もできる。それはその各々が異なった配送時間を有しているいくつかのアウトプットインターフェースノードを持つ購買オーダーとしてモデル化される。顧客要求が購買オーダーに反映される。それぞれのオーダーは１つのインプットインターフェースノード３０を有しているが、しかしアウトプットインターフェースノードあるいはアクティビティはない。顧客オーダーのような材料を消費するオーダーが「要素を発する」ものとしてモデル化される。他方、材料を作るオーダーが、「要素を受け取る」ものとして、モデル化される。この両方のオーダーのタイプは、ＳＣＰモデルにおける他のコンポーネントに類似のオブジェクトとしてモデル化されることが可能であり、これによってモデル上で稼働するための追加のアルゴリズムを作る必要が省かれる。インプットあるいはアウトプットインターフェースノードがないオーダーが存在することもできる。例えば、リソース上のテストあるいはメンテナンスを表わすオーダーのようなものである。
【００３１】
リンクもまた、連続したアクティビティ間に作ることができる。前記リンクは後継のアクティビティに関するものだけではなく、アクティビティ間の最小・最大時間に関する参照をも含んでいる。これらの時間的制約は、同じオーダー内のアクティビティ間（オーダー内の制約）にも、そして異なったオーダーに属しているアクティビティ間（クロスオーダー制約）にも共に存在することがある。
【００３２】
図５はアクティビティ間のオーダー内の時間的制約を説明する。図５ａに示されるように、アクティビティ１１ｄは３つの後継アクティビティ１１ｅ、１１ｆおよび１１ｇを持っている。時間的制約を表現しているエッジ５０、５１そして５２は属性を持っている。それらはアクティビティ間の最小・最大時間インターバルと、そしてスタート−スタート、スタート−フィニッシュ、フィニッシュ−フィニッシュ、あるいはフィニッシュ−スタートのような時間的制約条件のタイプである。実線の、そして破線のストレートな矢印に従うことによって、連続したアクティビティへの参照がモデル化される。図５ｂでは、アクティビティ１１ｄからスタートして、最初に矢印「succ＿edge」５１に従って、第１の後継アクティビティに達し、小さい正方形５３からエッジ「succ＿act」５２に沿って参照する。このプロセスは、続いてすべての他の後継アクティビティに達するために、第１の順調な小さい正方形から繰り返される。小さい正方形５３は補助オブジェクトの記号であり、これは後継アクティビティへの参照と、次の補助オブジェクトと、そしてアクティビティ間の時間的制約条件の属性すべてを蓄積する。同じ技術は先行の制約条件をモデル化するのにも使用され、例えばカーブした矢印「pred＿edge」５４と「pred＿act」５５に従うことによってアクティビティ１１ｈの先行条件を見いだすことができる。
【００３３】
クロスオーダーの時間的制約が図６で示される。第１のオーダー６１および第２のオーダー６２のそれぞれは、３つのアクティビティ１１を含んでいる。第１のオーダー６１のアクティビティ１１ｊと第２のオーダー６２のアクティビティ１１ｎとの間にクロスオーダーの時間的制約条件がある。この制約条件は、オーダー内の時間的制約条件のために上に説明されたのと同じ方法でマップされる。すなわちアクティビティ１１ｊが後継アクティビティ１１ｋと１１ｏとを持っていて、そしてアクティビティ１１ｏは先行アクティビティ１１ｊと１１ｎを持っていることを示している。
【００３４】
同様に、「ペギング」が２つのオーダーをリンクしている。そこではオーダーの１つが、他のオーダーによって消費された材料を供給している。ペギングは、材料のタイプと数量を追跡し、１つのオーダー（「劣位オーダー」）によってもう１つのオーダー（「優位オーダー」）に供給する。ペギングはどのような所定の時刻にでも、どのような所定のオーダーに関してでも優位、そして劣位のオーダーを確認することが可能である。もしオーダーの日付が変更されたなら、ペギングはこの変更によって影響を受ける他のすべてのオーダーが更新されるようにできる。
【００３５】
図７は、材料Ｍ１，Ｍ２および／またはＭ３を生産または消費する５つのオーダー７１、７２、７３、７４および７５からなるオーダー間のペギングの例を描いている。示されているように、例えば、Ｍ２とＭ３のそれぞれは、Ｍ１を生産するのに必要とされる。それぞれのインプットインターフェースノード３０の隣のそれぞれの属性が示されているが、それらは必要とされる量と所要日付を示している。それぞれのアウトプットインターフェース３１ノードの隣に示される属性は、作り出される数量と使用可能日付である。例えば、オーダー７１は１００個のＭ２を生産するが、これはオーダー７２と７３がＭｌを生産するという要求を満足させるのに十分である。オーダー７３の要求はオーダー７１と７５によって満たされる。
【００３６】
図８に示されるように、オーダー間の関係が、アクティビティ間の時間的制約と同じ方法でマップされている。Ｍ２オーダー７１が供給するオーダーは、Ｍ２オーダー７１のアウトプットインターフェースノード３１からスタートすることによって、そして別の言い方をすると実線のストレートな矢印（「succ＿edge」）５１と、破線のストレートな矢印（「succ＿act」）５２を追跡することによって、見いだすことができる。同様に、Ｍｌオーダー７３が供給するオーダーは、Ｍｌオーダー７３のインプットインターフェースノード３０からスタートすることによって、そしてあるいは実線のカーブした矢印（「pred＿edge」）５４と、破線の矢印（「pred＿output 」）５５を、供給オーダー７１と７５のアウトプットインターフェースノード３１まで追跡することによって、見いだすことができる。
【００３７】
ペギングがオーダーの大きいネットワークをリンクすることができるとしても、すべてのオーダーがお互いへの関係を持っているわけではない。したがって、ＳＣＰネットワークは通常、分離性のサブネットワークの集合体である。これは特定のオーダーを見つけるためにネットワーク全体をスキャンすることは難しい。したがって、図９に示されるように「オーダーアンカー」９０が、「オーダーナンバ」９１を通してＳＣＰネットワーク内のオーダー１０あるいはオーダーのグループに直接アクセスを提供することができる。この情報は、オーダーナンバのための一次インデックスとネットワーク内のオーダーへの参照のための２次インデックス、あるいはオブジェクト識別ナンバ（「OID」）９２とを用いて、ＲＡＭによってバッファされたリレーショナル・データベーステーブルに蓄積されることが望ましい。同様に、「オペレーションアンカー」９３がオーダー１０内のオペレーション２０に、あるいは融合されたアクティビティに、直接アクセスを提供することができる。オペレーションアンカー９３のキー９７はオーダー１０のためのＯＩＤ９２である。それは前もって決定されたオペレーションナンバ９４に、そのオーダー９５の中のオペレーションナンバに、そしてそれぞれのオペレーション２０の最初のアクティビティ９６に、参照される。その結果、１つのオーダー１０のあるオペレーション２０にアクセスするアプリケーションプログラムのためには、最初にオーダーアンカー９０を使って、そのオーダーのためのOID９２を決定し、次にオペレーションアンカー９３を使って、オペレーション２０の第１のアクティビティ９６を見いだす必要があり、それが探しているものである。
【００３８】
図１０で示されている計画オブジェクトアンカー１００は、アプリケーションプログラムが所定の材料のためにオーダー１０のすべてを効率的に決定することを可能にする。それぞれの材料は、その材料ナンバ１０１、プラント１０２、保管位置１０３および仕切り１０４によって、リレーショナル・データベーステーブル内で識別される。これは集合的に「計画オブジェクト」として示されている。表１０９内の計画オブジェクトアンカーは、材料Ｍ４のために第１インプットインターフェースノード１０５へ、そして材料Ｍｌのために第１アウトプットインターフェースノード１０６ｉ照合をする。 それぞれの材料のすべてのインプットインターフェースノード３０とアウトプットインターフェースノード３１とは、二重に連結されたリスト内に保持され、それは図１０に示されるように、要求事項と使用可能日付に従ってソートされている。それで、それぞれの材料あるいは「計画オブジェクト」のために、すべての受けている、そして発している要素を選ぶことは可能である。それは材料要求計画のために重要なことである。
【００３９】
それぞれのアクティビティが１つの特定のリソースに対応することが望ましいので、リソースアンカーはアプリケーションプログラムが特定のリソースのためのすべてのアクティビティを決定するが可能であるように提供される。図１１は、１つのリレーショナル・データベーステーブル１１９としてモデル化されたリソースアンカー１１０を描写している。これはそれぞれのリソースナンバ１１１をそのリソース上にスケジュールされた対応する第１のアクティビティＡ２にまで参照する。次に第１のアクティビティＡ２である１１２は、同じリソース上にスケジュールされた次のアクティビティＡ３である１１３にリンクされる。それはスケジュールされた時間に従って、時系列の順序で順番に次のアクティビティＡ５である１１５およびＡ８である１１８にリンクされる。これは特定のリソース上に新たなアクティビティをスケジューリングすることを容易にする。例えば、リソース上に新アクティビティをスケジュールするためには、アプリケーションプログラムは最初に、新アクティビティに関して提案された時間の直前のアクティビティとそして直後のアクティビティをチェックして、そのリソース上に新アクティビティを行う十分な時間があるかどうかを決定しなくてはならない。リソースアンカー１１０は、そのリソースによって時系列的に参照される特定のリソースのすべてのアクティビティを蓄積しているので、この情報はアプリケーションプログラムによって容易に、そして迅速にアクセスできる。
【図面の簡単な説明】
【図１】 図１はオーダーとそのアクティビティの間の関係を表現した図である。
【図２】 図２はオペレーションをするためのアクティビティの融合を表現した図である。
【図３】 図３はオーダーの入出力インターフェースノードを表現した図である。
【図４】 図４はインプットアクティビティ、アウトプットアクティビティと、そしてインプットあるいはアウトプットがないアクティビティを表示した図である。
【図５】 図５はアクティビティ間の時間的な制約条件がどのようにモデル化されるかを表示した図である。
【図６】 図６はオーダーの間の時間的な制約条件がどのようにモデル化されるかを表示した図である。
【図７】 図７はペギングを持つ単純なオーダーネットワークを表わした図である。
【図８】 図８はオーダー間のペギングがどのようにモデル化されるかを表わした図である。
【図９】 図９はオーダーアンカーとオペレーションアンカーを表わす図である。
【図１０】 図１０は計画オブジェクトアンカーを表わす図である。
【図１１】 図１１はリソースアンカーを表わす図である。

Claims (12)

1. サプライチェーン計画に関するデータを格納および処理するシステムであって、前記データが前記システムの処理を行うコンピュータプログラムによってアクセスされるようにコンピュータメモリに格納される形式のシステムにおいて、前記データの組織化では、
   ａ）前記データは複数の離散データ要素を定義するために分割され、ここで、前記複数の離散データ要素の各々は生産過程における個々の作業ステップを表しており、生産計画の観点からは分割できないものであり、
   ｂ）前記複数の離散データ要素の間の関係がサプライチェーンに沿った材料データ及び製造注文データの進捗を反映するように論理的にまとめられ、蓄積され、その際、同一の製造注文データ内の関連する離散データ要素が相互にリンクされて、少なくとも１つのネットワークが形成され、前記関連する離散データ要素の各々はデータ時系列において直前および直後のすべての離散データ要素を参照しており、
   ｃ）前記各製造注文データ内の最初の離散データ要素と最後の離散データ要素へのダイレクトリンクが設けられ、当該ダイレクトリンクはコンピュータメモリに格納され、
   ｄ）前記各製造注文データに少なくとも１つの入力インタフェースノードデータ要素が設けられ、ここで、当該入力インタフェースノードデータ要素は前記製造注文データが必要とする材料データを表しており、各入力インタフェースノードデータ要素は前記材料データを必要とするすべての離散データ要素にリンクされ、
   ｅ）前記各製造注文データに少なくとも１つの出力インタフェースノードデータ要素が設けられ、当該出力インタフェースノードデータ要素は前記製造注文データによって生成された材料データを表すものであり、各出力インタフェースノードデータ要素は前記材料データを生成するすべての離散データ要素にリンクされ、
   離散データ要素の前記少なくとも１つのネットワークの最初の製造注文データの各出力インタフェースノードデータ要素は、前記した最初の製造注文データの前記出力インタフェースノードデータ要素に関連付けられた材料データを必要とするようにスケジュールされた、離散データ要素の前記少なくとも１つのネットワークの後続する各製造注文データのそれぞれの入力インタフェースノードデータ要素を参照するようにリンクされており、
   サプライチェーンに関する前記データは、離散データ要素の前記少なくとも１つのネットワークのうちの所望の製造注文データの最初の離散データ要素への前記ダイレクトリンクを用いてアクセス及び処理され、その後、同一の製造注文データ内の前記関連する離散データ要素間の前記リンクを用いて、先行する離散データ要素と後続する離散データ要素がデータ時系列にスケジュールされ、
   与えられたリソースについてすべての製造注文データが決定及びスケジュールされる、ことを特徴とするサプライチェーン計画情報を格納および処理するシステム。
2. 時系列的に直前のすべての離散データ要素への前記参照と時系列的に直後のすべての離散データ要素への前記参照はそれぞれ少なくとも２つの属性を有しており、当該少なくとも２つの属性には、製造プロセス中の前記個々の作業ステップの間の最小時間インターバルおよび最大時間インターバルと、時間的制約条件のタイプとが含まれている、請求項１記載のシステム。
3. 前記複数の離散データ要素のうち少なくとも１つは、スタート時間、終了時間、現在計画されているそれぞれの離散データ要素のリソースへの参照、および、１つまたは複数の代替的なリソースへの参照の、少なくとも４つの属性を有している、請求項１記載のシステム。
4. 前記各入力インタフェースノードデータ要素は、必要な材料、必要な量、前記した必要な材料が必要とされる時間、および前記必要な材料の何らかの不足に関するデータを含んでおり、ただし、前記不足は前記した必要な量と他の注文または在庫から配布される前記した必要な材料の量との間の差として定義され、前記各出力インタフェースノードデータ要素は、生成された材料、生成された量、前記生成された材料が生成された時間、および前記生成された材料の何らかの余剰に関する情報を含んでおり、ただし、前記余剰は生成された量と他の注文にまだ配布されていない前記生成された材料の量との差として定義される、請求項１記載のシステム。
5. 同一の製造注文データを有する離散データ要素の前記ネットワークのうちの少なくとも１つは前もって割り当てられた注文番号を有しており、前記システムはさらに、オブジェクト識別子にマッチする前もって割り当てられた各注文番号に関するエントリーを持つデータベーステーブルを含んでおり、ここで、前記オブジェクト識別子は離散データ要素の前記少なくとも１つのネットワークの各注文への参照である、請求項１記載のシステム。
6. 離散データ要素の少なくとも１つのネットワークの中の前記複数の離散データ要素は少なくとも１つのオペレーションとして識別され、まとめられ、前記オペレーションの各々は前もって割り当てられたオペレーション番号を有しており、前記システムはさらに、各オブジェクトＩＤに関するエントリーと、前記各オペレーションの最も早い離散データ要素にマッチする前もって割り当てられたオペレーション番号に関するエントリーを持つデータベーステーブルを含む、請求項１記載のシステム。
7. 各材料は前もって割り当てられた材料番号を有しており、前記システムはさらに、各材料が必要とされる少なくとも１つの入力インタフェースノードデータ要素への参照にマッチする前もって割り当てられた各材料番号に関するエントリーと、各材料が生成される少なくとも１つの出力インタフェースノードデータ要素への参照にマッチする前もって割り当てられた各材料番号に関するエントリーを持つデータベーステーブルを含む、請求項１記載のシステム。
8. 前記データベーステーブルはさらに、プラント、保管場所、およびバッチのうちの少なくとも１つを含む各材料に関する識別データを含む、請求項７記載のシステム。
9. 各リソースは前もって割り当てられたリソース番号を有しており、前記システムはさらに、それぞれのリソース上でスケジュールされた離散データ要素の時系列にマッチする前もって割り当てられた各リソース番号に関するエントリーを持つデータベーステーブルを含む、請求項１記載のシステム。
10. 離散データ要素の前記少なくとも１つのネットワークは最初の製造注文データとｍ個の後続する製造注文データを含んでおり、前記ｍ個の後続する製造注文データの各入力インタフェースノードデータ要素は、前記最初の製造注文データが前記ｍ個の後続する製造注文データの材料需要に対して供給を行うように前記最初の製造注文データのそれぞれの入力インタフェースノードデータ要素にリンクされている、請求項１記載のシステム。
11. 離散データ要素の前記少なくとも１つのネットワークのうちの１つはｋ個の出力インタフェースノードデータ要素を有しており、ｋ個の異なる材料を生産するための製造注文データを表している、請求項１記載のシステム。
12. 複数の離散データ要素が１つのオペレーションを形成するようにまとめられ、該オペレーションの最初の離散データ要素が生産のセットアップを表し、前記オペレーションの後続する離散データ要素が生産ステップを表す、請求項１記載のシステム。

Images