JP2004326787A

JP2004326787A - 故障復旧システムおよび方法のためのプラニングおよびスケジューリング

Info

Publication number: JP2004326787A
Application number: JP2004125575A
Authority: JP
Inventors: Markus P J Fromherz; ピージェイフロムハーツマルカス; G Boburo Daniel; ジーボブロウダニエル
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 2003-04-28
Filing date: 2004-04-21
Publication date: 2004-11-18
Anticipated expiration: 2024-04-21
Also published as: US7139629B2; JP4786139B2; US20040216002A1; EP1480144A1

Abstract

【課題】システム・コントローラ内の、スケジューリングされた生産ファンクションの状態を追跡して、モニタする。
【解決手段】システム・コントローラ、一つ以上の作業ユニットを持つジョブの生産における、選択されたモジュール機能のプラニング利用のための、少なくとも一つのプラニング・ファンクション、一つ以上の作業ユニットを持つジョブの生産における選択されたモジュール機能の利用をスケジューリングするための、少なくとも一つのスケジューリング・ファンクション、および、一つ以上の作業ユニットを有するジョブの生産における、一つ以上の選択されたモジュール機能のパフォーマンス故障を識別するための、少なくとも一つのファンクション、を備えるシステム。
【選択図】図１

Description

本発明は全体として、自動化された製造システムの制御および管理に関し、より詳細には、再構成可能な生産システムの故障復旧および状態遷移化のためのシステムおよび方法に関する。

生産システムでの、モデル・ベースのプラニングおよびスケジューリング(システム制御ソフトウェア)はしばしば、通常のビヘイビヤのためのスケジュールの生成だけのために使用されるが、これらのスケジュールの実行における、故障からの復旧、および、システムの不整合な状態から整合的な状態への遷移化(transitioning)には関連させられない。従来のシステム場合には一般的に、そのモジュールの一つがオフラインとなった時、または、故障を宣言した時には、「全体の」システムが停止させられる。更に、もし、オペレータの介入無しに故障から復旧することが可能ならば、単純な復旧手続(例えば、現在工程パス中にあり、まだ配送されて(delivered)いない全ての作業ユニットをパージすること)が呼び出され、システムは次に、再起動されて、現在のジョブの非完了の部分を生成する。単純なデフォルト復旧手順(default recovery procedures)を選択する理由は、作業ユニットの再ルーティング、再動作オペレーション、および、選択されたジョブの部分の再動作、を要求し得る故障復旧の一般的な問題が、特に、再構成可能なシステムにとって、しばしば、オリジナルのプラニングおよびスケジューリングの問題と同じくらい複雑であることである。

このアプローチは、並行モジュールまたは工程中の潜在的に大きな数の作業ユニットを持つシステムにとって不満足である。異なったジョブの部分が、複数のモジュールに亘って分散されることを前提にすると、工程中の全ての作業ユニットのパージングのような単純な手順は、最も良いケースでもかなりの浪費に繋がり、大きな、ワーストケースでは生産時間の損失に繋がる。多くのモジュールを持つシステムにおける復旧の複雑さに起因して、単純な復旧は、実際に、システム状態における不整合、または、少なくとも予期されないモジュール相互作用(module interactions)、に繋がり得る。

簡潔に述べると、そして、本発明の一つの特徴に従って、コンピュータ制御されたシステムが、作業ユニット(work unit)を処理するための複数の選択的な(alternative)機能を伴う複数のモジュールを有する再構成可能な生産システムにおける、構成に特有なオペレーションの復旧を提供する。本システムは、プラニング、スケジューリング、および、パフォーマンス故障(failure)識別ファンクション、を有するシステム・コントローラを含む。プラニング・ファンクションは、１つ以上の作業ユニットを持つジョブの生産での、選択されたモジュール機能(capabilities)の利用を計画し、スケジューリング・ファンンクションは、ジョブの生産(production)での、選択されたモジュール機能の利用をスケジューリングする。故障識別ファンクションは、スケジューリングされたジョブについて作業ユニットを実行する(perform)ために、モジュール機能の故障を識別する。

本発明の他の特徴に従って、作業ユニットを処理するための複数の選択的な(alternative)機能を伴う、複数のモジュールを有する、再構成可能なコンピュータ制御された生産システムにおけるオペレーションの、構成に特有の(configuration-specific)復旧のための方法が開示される。本方法は、一つ以上の作業ユニットを有するジョブの生産における、選択されたモジュール機能の利用のプラニングおよびスケジューリングを含む。製造システム内のモジュールに、パフォーマンス・コマンドが提供され、ジョブの生産における何らかのモジュール機能のパフォーマンス故障(failure)が、識別される。

ここにおいて、システム・コントローラ内の、スケジューリングされた生産ファンクションの状態を追跡して、モニタする方法およびシステムが開示される。このシステム・コントローラ内では、コントローラが、全ての利用可能なシステム機能(capabilities）の連続的な使用を提供し、各々の機能が実行された後に必要なものとして、システム状態および更新されたモジュール・モデルをレポートする。これを実現するために、システム・モジュールによってレポートされた現在のスケジュールおよび事象(events)は、ジョブが実行されるに際して整合的なやり方で、インクリメンタリに統合され(integrated in)、プラン実行のログが形成され得る。これらの情報の形式(forms)は、システム制御ソフトウェアに、オペレータに、システム状態をより旨くレポートする能力を与え、これらは、故障復旧および状態遷移化(transitioning)のためのプラニングのための基盤を与える。詳述され、制約を基礎とするフォーマットで提供されるシステム状態に対して、本システムおよび方法は、システムの機能およびオリジナルのジョブ制約(job constraints)を用いて、非終了ジョブ要素(unfinished job elements)を生産するための、新規のプラニングおよびスケジューリングを生成する。スケジューリングのための現存するアプローチとは対照的に、ここに明白に説明される本システムおよび方法は、パージングおよび再生成を、ジョブを生成するために実行され得る機能の一つとして考慮する。本システムおよび方法は、人間の介入を含むジョブ要素(element)の、パージングのための複数のメカニズムをも考慮する。

本システムおよび方法は、製造、印刷、または組立(assembly)のような複数のステップの生産工程のために用いられるソフトウェアを制御するために適応され、柔軟なルーティング、最適な生産性、および、最適な負荷バランシング、を提供するための、複雑なパスに亘る複雑なオペレーションの取扱いを提供する。以下の説明において、本発明の完全な理解を提供するために、膨大な特定の詳細な説明が行われる。しかし、当業者にとって、そのような特定の詳細部分(details)無しに、本発明が実施できることは明白であろう。他の場合には、本発明を不必要に不明瞭化しないために、特定の実施の詳細部は細かく示されない。

ここで図面の説明に進む。図面の目的は、システムおよび方法の実施例を示すことであり、システムおよび方法を限定することではない。図１は、本発明の一つの実施例と適合する通常の、および故障復旧オペレーションのプラニングおよびスケジューリングのためのコントローラを示す。システム100において、システム・コントローラ110は、何らかの既知のタイプのジョブ入力ソースから生成されるべき作業ユニットの記述(descriptions)を受け取る。これらの記述は、所望の出力生成物(output products)または達成されるべき他のゴール(goal)の記述に対応する。それらは一般的に、いかにして生成物が生成されるかを指定すること無しに、生産物の属性(または特性)、これらの属性に対する値または範囲または一般的な制約、および、生産のタイミングについての、あり得る制約(例えば締め切り)、を指定し得る。

システム・コントローラ110はまた、パス130に沿って、システム内の各モジュール120から、機能モデル(capability models)およびパフォーマンス・ログ情報を受け取る。機能モデルは、いかにしてモジュールが移動し、作業ユニットを変換するかの記述であり、通常、作業ユニットの属性およびタイミングについての情報を伴う。モデルは、生産システムが起動される(started up)時に一回だけシステム・コントローラに送られ得るか、または、モデルは、定期的に、または変化が発生したときに更新され得る。モジュール内の(そしてそれ故にモデル内の)そのような変化は、例えば、モジュールの再構成、タイミング値での変化、および、リソースの利用不可能性(および、それ故、いくらかの機能(capabilities))、であり得る。機能モデルには、例えば、タイミング制約(constraints)(例えば、機能の実行の期間、リソースが占有される時間、または、リソースの予約)、機能制約(feature constraints)(例えば、処理されている作業ユニットのサイズについての限界、一部分のオリエンテーションの変更、または２つの部分を一緒に付加するような作業ユニットの変換についての限界)、および、コマンド(例えば、時間および、恐らく他の情報を伴う、機能に対応するオペレーションの名称またはＩＤ(identifications))、が含まれる。タイミングおよび機能(feature)制約は、いつ、および、いかにして、機能(capability)が、作業ユニットに提供されるかを記述する。コマンドは、対応するオペレーションを開始するためにモジュールに送られるコマンドである。

モジュール120は、例えば、フィーダ・モジュール、マーキング・エンジン・モジュール、仕上げ器(finisher)モジュール、または、輸送モジュールのような、印刷エンジンの機械モジュールのような、多くの種類のタイプの生産システムを包含し得る。或いは、モジュール120は、準備モジュール、加熱モジュール、混合モジュール、分析モジュール、または、輸送ロボットを備え得る、バイオ技術のスクリーニング・システムの分析モジュールを含み得る。製造ライン・モジュールは、機械モジュール、組立モジュール、試験モジュール、輸送ロボット、または、梱包モジュールを含み得る。梱包ラインは、ボトル充填モジュール、または、ラベル付けモジュールを含み得る。システム・コントローラ110は、所望の作業ユニットのためのスケジュールをサーチする時に、全ての可能なシステム機能(capabilities）を考慮する。

一つ或いはそれ以上のジョブの所望の作業ユニット(work unit)のいくらか、または全てをプラニングおよびスケジューリングすることは、選択され、スケジューリングされた機能の組をもたらす。これらが利用可能なことを前提として、システム・コントローラ110は、スケジューリングされた機能に対応する命令コマンドを、パス140を経由して、モジュール120に送る。モジュールの各々は次に、指定されたジョブの完了のために、そのタスク・シーケンスを実行する。処理されている作業ユニットのパスを示すパス150に見られるように、作業(work)は、次のモジュールに引き続いて移動する前に、特定のモジュール120内を周期的に反復し得るか、または、作業は、第３のモジュールに通過する前に、複数のモジュールの中を周期的に反復し得る。３つのモジュール120だけが、ここでの目的のために説明されるが、ジョブ要求の複雑さに依存して、システムは、膨大なモジュールを含み得ることが理解されるであろう。モジュールは、再構成可能なシステム内に種々の構成を持ち得る。更に、いかなる時点においても、モジュール上でスケジューリングされている作業、および、システムの状態、に関してのオペレータ・フィードバックのための機能もまた存在する。

システム制御ソフトウェアは、機能を選択することによって、これらの機能のタイミング変数(timing variables)を決定することによって、および、故障を識別して、故障から復旧することによって、スケジューリングされた機能を実行するために、ジョブをプラニングし、スケジューリングする。図２は、プラニング、スケジューリング、モニタリング、レポーティング、および、システム・コントローラによる故障の識別およびそこからの復旧へのアプローチを示す。この図面では、受信され、工程内の各々の後続のステップに提供されたデータに関して方法ステップが説明される。この工程のステップ220、230、および240の各々は、順番に(一つずつ)、または一度に(concurrently)、実行され得る。いずれの場合でも、各ステップは、データ225、235、または、前のステップまたはシステム内の他のアクションによって提供されたスケジュールおよび実行の間の偏移を消費し、データ235、245、および究極的に、後続のステップまたは他のシステム・オペレーションのために270を生成する。このデータを消費し、生成することは一般的に、インクリメンタリに行われる。つまり、実時間ソフトウェアの当業者にとって明白なように、ステップは、一つのデータ・アイテムを次から次に処理するが、バッチでも処理され得る。最初は、作業ユニット225、または実行されるべきジョブ、の記述(description)は、コントローラに提供される。もし、診断的(diagnostic)ジョブが実行されねばならないならば、対応する作業ユニットが同時に、ジョブ・キューに挿入される。

コントローラはまた、スケジュールおよび実行の間の偏移に関するシステムおよび情報の現在の状態260とともに、利用可能なシステム・モジュールのモデルを持つ。このモデルのオペレーションは、例えば、モジュール、および、それが以前にプラニングし、スケジューリングしたかもしれない、何らかの機能によって現在実行される。選択された作業ユニットに加えて(plus)何らかのオプションの診断的作業ユニット225が次に、ステップ220に送られる。ここでは、各モジュールに対する機能モデルを考慮して、選択された作業ユニットのための機能がプラニングされ、スケジューリングされる。このステップは、前のステップで選択された、各作業ユニットおよび診断的作業ユニットに対して反復され、スケジューリングされた機能の組235が、生成される。230において、故障は識別され、260からのスケジュールおよび実行偏移データ(schedule and execution discrepancy data)に基づいて復旧モードが識別される。具体的に、スケジュールと実行ポイントの間の、何らかの(大きな)偏移(discrepancy)は、潜在的な故障に繋がる。(故障は、介入(intervention)を必要とする現在の故障か、未だ回避できる差し迫った故障か、のいずれか、得る。)従って、ソフトウェアは、レポートされた実行が、依然として、ジョブおよびモデルによって与えられた制約を満足させるか否かを識別する必要がある。例えば、もし作業ユニットが、モジュールに、予想された時間より長く存在(stays)するならば、それは、他のスケジューリングされた作業ユニットとオーバラップ(衝突)するであろうか？もし、作業ユニットが遅延されたならば、それは、依然として、他の作業ユニットに関して先行制約(precedence constraints)を満足させるであろうか？もし、作業ユニットの変換(transformation)(例えば、オリエンテーション(orientation)での変化)が、実行されなかったならば、それは補償され得るであろうか？この推論は、モジュール・レポートに基づいてスケジュールを修正し、次に、制約に対してそれを再びチェックすることによって為され得る。

もし、制約(constraints)が、引き続き満足されるならば、更なるアクションは不必要である。(これははまた、モジュールに、ローカルな問題を解決することに際しての、いくらかの自律性を持たせることも可能とし、これによって、更にロバストネスを改善する。)
もし、実行の差異のために、生産が不整合になってきているならば、モジュール・レポートに従ってスケジュールを更新すること、または、それを試みることによって、正しいスケジュールを生成するスケジューラのファシリティ(例えば、制約解決器(constraint solver))が、それを検知するために使用され得る。例えば、もし、作業ユニットについてのオペレーションが、遅延されるならば、同じジョブの作業ユニットが、不適切な状態で生成され得る(そして、それ故、先行制約が違反されることになる)か、或いは、作業ユニットは、衝突し得る(そして、それ故リソース制約が違反されることになる)。そのような実行差を比較して、そのスケジュールに統合することによって、スケジューラは、即座にそのような不整合を検知できる。

もし制約が、もはや満足されないならば、詳細なシステム状態は、システムが故障から復旧できるか否か、および、いかにして、システムが故障から復旧できるかを決定するための基盤を提供する。例えば、故障の一般的な結果は、ジョブのその部分が、それらの先行制約(precedence constraints)に違反すること(即ち、いくつかの作業ユニットの遅延のために、所望されるものとは異なったオーダー(order)となってしまうこと)、または、(それらを生産するためにスケジューリングされたモジュールが、オフラインとなったために)全く生産されないことである。この状態は、恐らく、これらのジョブの再プラニングまたは再ルーティングによって、システム制御ソフトウェアが、復旧出来るように、それらの部分を識別することを促進する。ダイナミックなシステム・スケジュールに取り込むための、ステップ220のプラニングおよびスケジューリングのために、システム故障識別および故障復旧モードが提供される。

スケジューリングされた機能235は次に、ステップ240に提供される。ここで、コントローラは、スケジューリングされた機能に対応するコマンド245を、個々のモジュールに送る。このステップは、各スケジューリングされた機能に対して反復される。モジュールは、それらのモデルで定義されたのと同じ詳細なレベルで、機能の実行をインクリメンタリにレポートする。例えば、輸送モジュール(transport module)は、入力時間、出力時間、入力作業ユニット(および、その属性)、出力作業ユニット(および、その属性)、および、それらの間のいくつかの制約(例えば、時間変数(variables) の間の時間制約、作業ユニット変数の間の属性変換、等)、を伴って、「移動」機能を定義し得る。もしシステム制御ソフトウェアが、その機能を選択し、スケジューリングする(時間および属性変数のための値を決定する)ならば、所定の時間で、この機能を実行するために、コマンドがモジュールに送られ、モジュールは、モデル変数(時間、属性、リソース)に対する実際の値(または、予想された値への差異)を折り返しレポートする。これらのモジュール・レポート255は、250でロギングされ、詳細化された、そのスケジュールの実行のログを構築するために統合される。ログは、明示的に、或いは黙示的に、システムのビヘイビヤのヒストリを含み得る。例えば、タイミング値に対する単一の値の替わりに、ログは、発生の頻度および見込みを含む、値の分散(distribution)を維持し得る。この情報は次に、システム状態260を更新し、システム・レポート270を生成するために利用される。

或いは、モジュールのビヘイビヤが、予想されたビヘイビヤから(大きく)偏移した場合にだけ、モジュールは、それらのビヘイビヤをレポートし得る。これによって、レポーティングのオーバーヘッドが削減できる。モジュールは、それら自身のモデルへのアクセスを持つので、システムコントローラとの、特別の通信は不必要である。あるモジュールが故障寸前か否かを決定するために、現在の観察されたビヘイビヤ値、および、それらの値についての限界を知ることが必要である。しかし、故障へ接近していることもまた、制御可能性に依存する。即ち、「限界の５％以内」は、きつい制御を持つモジュールに対して受け入れられ得るが、貧弱なセンシング機能を持つモジュールに対しては、殆どカタストロフィックである。

終了していないジョブ要素(element)を作成するための新しいプランおよびスケジュールを生成するに際して、本方法は、モジュールを伴う製造システムの機能、および、オリジナルのジョブ制約を用いる。スケジューリングのための現存するアプローチとは対照的に、本方法は明示的に、パージングおよび再生成を、ジョブ生成(job production)のためのオプションの一つとして考慮する。更に、進行中の(in-process)ジョブ要素の復旧および再生成の双方が、既にプラニングされ、スケジューリングされた他のジョブ要素の文脈で検討される必要がある。一つの例として、２つの要素からなるジョブを考慮する。要素2の生成が、最初に開始し得る(例えばそれが、生成するために、要素１より長い時間を費やすため)。プラナ／スケジューラは、双方の要素のためのスケジュールを持つが、それが故障に遭遇した時には、システムは、第２のものを生産するだけであった。その結果、正しい生産を保証するために、プラナ／スケジューラは、双方を一緒にスケジューリングしなければならなかった。一つのシナリオにおいては、要素２の生産を十分に、遅延すること、または、それを再ルーティングすることによって、要素１が、その間に生産され得、２の前に届けられ(delivered)得るようにすることが可能かもしれない。他のシナリオにおいては、要素１はもはや、２の前に移動され得ず、それ故、要素２はパージされねばならず、双方のジョブ要素が、始めから生産されねばならない。

図３に進む。ここで、フローチャートは、本発明による、作業ユニットの復旧、および、新しい作業ユニットのプラニングのためのプラニングで利用されるオペレーションの模範的実施例を示す。これから分かるように、新しい作業ユニットをプラニングし、スケジューリングする前に、復旧をプラニングし、スケジューリングする出力ループが存在する。310において、プランは公式化されて、現在の、または、将来の生産目的のために、進行中の作業ユニットを復旧させる。本方法は、追加の作業ユニットが復旧されるべきか否かを識別するために、320においてシステムに質問する。もし追加の作業ユニットが復旧されるべきならば、プランは、310において調整され、全ての復旧ユニットが識別されるまで質問(query)が反復される。330において新しい作業ユニットが次にプラニングされる。

このアプローチでの主要な利点は、故障の面における、浪費および生産時間の削減である。本方法は、もしシステムの現在の状態からの再起動が、生産の始めからの再起動に較べてより効率的ならば、システムの現在の状態からの再起動によって復旧を試みる。(反対に、もし、進行中の作業ユニットのパージングおよび再生成が、より効率的ならば、それが好ましい。)複雑な、再構成可能なシステムに対しては、本方法は、復旧を最適化するための、種々の利用可能な機能を利用することを試みる。分離、ヒューリスティック・ベースの復旧アルゴリズムの必要は無い。このアプローチは、構成から独立の(configuration-independent)であり、従って、このフレームワークでモデル化され得る、任意の再構成生産システムに対して容易に再使用される。

通常のまたは新規の作業ユニットのプラニングを実現するためのオペレーションの順序付け(ordering)の説明的な実施例が、図４に示される。プラニングされるべき作業ユニットまたはジョブは、入力ジョブ記述に基づいてステップ410で選択される。コントローラは次に、ステップ420で、オフラインのリソースを利用せずに、作業ユニットを生産するために必要とされる機能を決定する。オフライン・リソースは、例えば、それがパワー・ダウンされている、または壊れているために、現在利用不可能な、何らかのモジュールまたは部分モジュール(partial module)である。ステップ420でこの決定を為すに際して、コントローラは、一つまたは複数のオフライン・リソースの機能を除いて、(そこから、選択的機能が選択される)全ての有り得るシステム機能を考慮する。ステップ430で、コントローラは、作業ユニットを生産するために機能が利用可能か否かを判断する。もし十分な機能が利用不可能なら、ステップ440で、後続の同じジョブの作業ユニットは、一時的に考慮から除去され、プラニングされるべき他の作業ユニットを選択するために、コントローラは、ステップ410に戻る。もし、所望の作業ユニットに対しての機能が利用可能でなければ、適切でない出力の引渡しを避けるために、全ての後続の、同じジョブの作業ユニットが(たとえ、それらが生産され得る場合でも)遅延させられる。

もし、作業ユニットを生産するための十分な機能が利用不可能ならば、ステップ450で、ジョブ内で各タスクのために要求される時間の総量のようなタイミング制約(例えば、輸送オペレーションまたは処理ステップの期間)、その間にリソースが占有されるインターバルについての制約、および、そのようなインターバル中のリソースの予約、が、選択変数(selection variables)によって修正され、コントローラに提出される(posed to)。選択変数は、各機能に対して一つのブーレアン(Boolean)変数であり、真(機能が選択されている)か、偽(機能は選択されていない)かのいずれかになる。選択変数は、プラニング・ステップによって、各機能に対して生成される。

選択変数についての制約は、例えば、同じ出力に対する複数の選択的な(alternative)機能の一つだけが、選択され得る(即ち、その選択変数だけが真で有り得る)ことを決定する。制約の修正は、制約のタイプに従属する(constraint-type-dependent)。例えば、リソース割り当てでの割り当てインターバルは、選択変数によって乗算される。これらの制約修正(constraint modifications)の効果は、もし対応する機能が選択されるならば、リソース割り当てのようないくつかの制約だけが、有効になってくるということである。ステップ460において、コントローラは次に、選択変数および共通モジュール上のメモリ制約を、制約記憶(constraint store)に通知(posts)する。ステップ470において、実時間制約およびオーダ制約(order constraints)は、コントローラに渡される。

次の作業ユニットの機能の間の順位制約(precedence constraints)において、正しい出力時間が使用されねばならないので、全ての選択的機能の出力変数は、一つの時間変数に接続される。この時間変数は次に、順位制約で使用される。ジョブ制約は、ジョブに対するリソース、および、全ての有り得る、ジョブ内の作業ユニットに対して考慮されている機能の出口ポート、をリザーブする。もし、このポイントで、ジョブの一部分だけがスケジュールされていれば、選択されたリソースが、オープン・エンドの(open-ended)将来のためにリザーブされるし、さもなければ、ジョブの期間のためにリザーブされる。これは、オフラインのリソースに起因して、ジョブの、いくつかの部分が未だ生成されていない場合でさえ、ジョブが正しく送られることをも保証する。提示された(presented)ステップのシーケンスは、ここに開示された方法に対する、ただ一つの例示された実施例である。当業者にとって、膨大な代替的なステップ手順が、類似の結果を産むことは明白であろう。

選択変数(selection variables)の使用は、スケジューラが、全ての可能な、代替的なプランを同時に考慮し、その選択変数をインスタンス生成する(instantiating)ことによってプランを選択することを可能とする。この方法に対する代替的な方法は、サーチを使用して、次から次へと、ベストのスケジュールを持つものを維持しながら、代替的プランを検討することである。この最初のケースでは、全ての機能のプラニングは、スケジューリング(時間値の発見)に先立つ。第２のケースでは、プラニングはおよびスケジューリングは、インターリーブされる。いずれの場合でも、最終結果は、各作業ユニットに対する、一つのプランおよびスケジュールである。

図５は、作業中の(in-process)作業ユニットの復旧のためのプラニングを実現するための、オペレーションのオーダリング(ordering)を詳述する模範的実施例を示す。510において、コントローラは、作業中の作業ユニットの中から、プラニングされるべき作業ユニットを選択する。始めから、作業ユニットを生産する機能は、520において識別される。作業中の作業ユニットの各々に対して、復旧中に、２つの機能の組が考慮される。それらは、現在の位置および作業ユニットの状態から、所望の出力製品を生産する機能(「復旧機能」。以下において、例示の擬似コードにおいて添字「ｒ」で示す。)；および、所望の出力製品をパージングし、再生成する機能である(「パージ機能」および「生成機能」。以下において、添字「ｐ」および「ｃ」で示す。)。復旧およびパージ機能は、現在の位置から開始する一方、「生成」機能は、始めから製品を生成する、通常のシステム機能である。

530において、コントローラは、作業中の作業ユニットを、その現在の位置からパージ出来る機能を判断する。「現在の位置」の定義は、実行ごとに特有(implementation-specific)である。例えば、故障の際に実行されることがスケジュールされた機能が、完了され得ることが想定され得る。従って、復旧およびパージ機能は、対応するモジュールの出口ポートから開始し得る。代替的に、即座に、代替案の一つとして、パージングおよび再生成を考慮するよりはむしろ、プラナ／スケジューラは、現在の状態から、通常のスケジュールを生成することを最初に試み得る。もしこれが失敗したら、それは、制約(例えば、タイミング、または、順位(precedence)制約)および第１のプランに違反した、それらの部分(parts)を識別し、それらのパージングをスケジューリングすることになる。コントローラは次に、ジョブを再び、プラニングし、スケジューリングすることになろう。これは、複数回の反復(multiple iterations)によっても為され得る。

コントローラは、作業中の作業ユニットを、現在の位置から修復出来る機能を540で識別し、十分な機能が利用可能か否かを、550で判断する。560において、もし十分な機能が利用不可能ならば、コントローラは、後続の、同じジョブの作業ユニットをキャンセルし、それらを、考慮の対象から一時的に除去する。510において、新しい作業ユニットが次に選択され、機能の識別が、新しい作業ユニットに対して反復される。或いは、もし現在の機能が、完了され得ないならば、全体のモジュールが、オフラインであると宣言されねばならない (そして、再生成が、唯一のオプションとなる) か、または、現在の機能が、実行されていないが、作業ユニットの状態が既知である(そして、復旧と再生成の双方がオプションである)か、または、作業ユニットの状態が、未知である(即ち、作業ユニットは、パージされ、再生成されねばならないことが、やはり、唯一のオプションである)。

もし、十分な機能が利用可能ならば、570において、コントローラは、全ての機能に対して、選択変数(selection variables)によって修正されたタイミング制約を通知する(posts)。選択変数および共通モジュールについての制約は、580で通知されて、システムが、故障を修復するか、作業ユニットをパージしてそれを再生産するか、のいずれかを行うことが可能とされる。選択変数についての制約は、例えば、同じ出力に対するいくつかの代替的機能の一つだけが、選択され得る(即ち、その選択変数だけが、「真」であり得る)ことを決定する。ステップ580において、制約は、各作業ユニットに対して、修復機能だけか、または、パージ機能と再生産(即ち生成)機能が一緒に選択されるように定義される。制約の修正は、制約タイプに依存する(constraint-type-dependent)。例えば、リソース割り当てでの割り当てインターバルは、選択変数によって乗算される(multiplied)。これらの制約修正の効果は、もし対応する機能が選択されているならば、リソース割り当てのようないくつかの制約のみが有効となる、ということである。590において、プラニングされるべき他の作業ユニットを選択するために510に戻る前に、スケジューラによる使用のために、コントローラは、実時間制約およびオーダー制約を通知する。

ここに提示される、作業中の作業ユニットの復旧をプラニングするための、擬似コードの一つの例は、全体の(分離性の(disjunctive))問題を、制約記憶(constraint store)に通知し、ブーレアン(Boolean)変数を使用して、同時にプラニングし、スケジューリングするために、複数の機能の中から選択する。当業者が理解し得るように、例えば、サーチ手順が必要に応じて代替の機能の選択および通知(posting)に亘ってバックトラック（backtrack）した状態で、異なった代替機能が次から次に通知され得る、というような、他のアプローチが利用され得る。そのような代替的アプローチが、本出願の明細書および特許請求の範囲によって完全に考慮される。

initialize scedules S and constraint store C;
repeat forever do
given the current schedule S, determine set U_p of in-process work units u and
set U_f of all other (future) work units in S;
for all work units u in U_p do
determine set S_u,C of "create" capabilities s such that u = output work unit of s
and exit port of s is in P_u
and s does not use off-line resources;
determine the exit port p_u, of the module currently containing u;
determine set S_u,_p of "purge" capabilities s such that the entry port of s = p_u
and exit port of s is a purge module
and s does not use off-line resources;
determine set S_u,_r of "repair" capabilities s such that u = output work unit of s
and exit port of s is in P_u
and s does not use off-1ine resources;
let S_u = union of S_u,C, S_u,p, and S_u,r ;
add S_u to S;
post to C : timing constraints of _si in S_u,c, with selection variables b_i added;
post to C : timing constraints of s_i,p in S_u,p, with selection variables b_i,p added;
post to C : timing constraints of s_i,r in S_u,r, with selection variables b_i,r added;
post to C : b_c = sum (s_i in S_u,c) b_i;
post to C : b_p = sum (s_i in S_u,p) b_i,p;
post to C : b_r = sum (s_i in S_u,r) b_i,r,
post to C : b = b_p;
post to C : 1 = b_p + b_r,
post to C : real-time constraints for s_i in S_u ;
for all s_i in S_u,c and S_u,r, post to C: exit port of s_i = exit port of job of u; end for
post to C : to = sum (s_i in S_u,c and S_u,r) bi times output time of s_i;
post to C : order constraint for t_o,
end if
end for
for all work units u in U_f do
(determine capabilities and post constraints as in regular scheduling;)
end for
for all jobs j and all possibly capabilities s_i,j in S_u,c and S_u,r scheduled above do
r_i,j = resource for exit port of s_i,j;
if all work units in j are being scheduled then
post to C: reserve r_i,j for the duration of job j;
else
post to C: reserve r_i,j for open-ended future for job j;
end if
end for
solve for the undetermined time variables and selection variables in C;
send commands to modules based on selected capabilities (b_i = 1) in S and
determined time variables in C;
clean up completed parts of S and C;
end repeat

図６を参照する。ここで、フローチャートは、コントローラのスケジューリング・ファンクションを示す。最初は、ステップ610において、コントローラは、スケジューリングされるべきそれらの機能(これらは、プラニング・ステップによって提供された機能の全てまたはサブセットであり得る)を選択する。コントローラは次に、ステップ620において、同じジョブ内のプラニングされた機能に対する出口リソースをリザーブする。同じジョブの全ての作業ユニットは、同じ最終出口ポートに配送されるように制約されるので、その同じ最終出口ポート(例えば、印刷エンジンの仕上げ器のスタックに対応するもの)に接続されたリソースは、ジョブが終了するまでは、他のジョブによって使用され得ない。ステップ630において、コントローラは次に、プラニングされた機能の、タイミングおよび選択変数を解決する。これは、いくつかの制約解決(constraint solving)または、制約された最適化技術(constrained optimization technique)(これらは、当業者に知られている)を用いて実現できる。

以前のスケジュールに存在した全ての作業ユニットに対する復旧のスケジューリングの代替物として、プラナー(planner)は、現在作業中のものまでの、または、それを含む、全ての作業ユニットを(ジョブ記述によって要求されたオーダー(order)を用いて)識別し得る。これは、復旧に含まれるべき作業ユニットの最小セット(minimal set)である。更に、プラナー／スケジューラは、そのプランに、人間の機能(human capabilities)を考慮し得る。例えばもし、一定の作業ユニットが、自動的にパージされ得ない、またはクリアされ得ないならば、どのジョブ要素がオペレータによって取り扱われる必要があるか、および、それが、どれを自動的に処理出来るか、を決定するために、プラナが最初に使用され得る。オペレータは次に、システムが進行する前に、いかにして、自動的にパージされ得ない、または、クリアされ得ないそれらの作業ユニットを取り扱うかを決定するかを尋ねられ得る。

他の代替案は、現在のシステム状態を反映するためにスケジューリングするための、ローカルな修復(repair)を試みることである。もし、いかなる制約にも違反すること無しに修復が為され得るならば、実行は、修復されたスケジュールから進行し得る。もし、スケジュールの修復が失敗するならば、プラナ(planner)／スケジューラ(scheduler)は再び、制約に違反するそれらの部分(parts)を識別し、これらのパージングをプラニング、およびスケジューリングでき、次に、通常のスケジューリングを再スタート出来る。スケジュールの修復、例えば、全く新しいプランおよびスケジュールを生成すること無しに、スケジュールにおける、タイミングまたはアクションを変更することは、いくつかの制約解決(constraint solving)、または、制約された最適化技術（これらは、当業者に知られている）を用いて実現され得る。

本発明は、特定の実施例を参照して説明され記述されてきた一方、更なる修正および改善が、当業者によって想起されるであろう。例えば、復旧プラナおよびスケジューラは、ここにおいて、故障復旧の遷移期間中に通常のスケジューラの替わりに用いられ、その後に、ソフトウェアが再び通常のスケジューラにスイッチングできる、別個の手続として提示された。その替わりに、２つの方法が統合され得る。即ち、故障復旧は、通常のスケジューリング方法の一部分であり得る。更に、ここで用いられる「コード」または「プログラム」は、コンピュータまたはタスクを実行(perform)する実行(execution)装置によって使用され得る、何らかの複数のバイナリ値、または、何らかの実行可能で、解釈され(interpreted)またはコンパイルされたコード、でありうる。このコードまたはプログラムは、いかなる、複数の既知のコンピュータ言語の一つでも書かれ得る。ここで使用される「コンピュータ」は、記憶し、処理し、ルーティングし、操作し、または、このようなオペレーションに類似するデータについてのオペレーションを実行する、いかなる装置をも意味し得る。

本発明の一つの実施例による、故障復旧のためにプラニングし、スケジューリングするためのシステムを説明する。本発明の一つの実施例による、故障復旧のための、プラニングおよびスケジューリングを実現するための、オーダリング(ordering)オペレーションを詳説するフローチャートを提供する。本発明の実施例による、作業ユニットの復旧のためのプラニング、および、新規の作業ユニットのプラニングを実現するための、オーダリング・オペレーションを詳説するフローチャートを提供する。本発明の実施例による、通常の、または新規の作業ユニットのプラニングを実現するための、オペレーションのオーダリングを詳述するフローチャートを提供する。本発明の実施例による、工程実行中の(in-process)作業ユニットの復旧のためのプラニングを実現するための、オペレーションのオーダリングを詳説するフローチャートを提供する。本発明の一つの実施例による、故障復旧が存在する状態での、スケジューリングを実現するための、オペレーションのオーダリングを詳説するフローチャートを提供する。

Claims

作業ユニットを処理するための複数の選択的な機能(alternative capabilities)を伴う複数のモジュールを有する、再構成可能な生産システム（production system）での、コンフィギュレーション特有の(configuration-specific)オペレーションのリカバリ、のためのコンピュータ制御されたシステムであって、
システム・コントローラ、
一つ以上の作業ユニット（work unit）を持つジョブの生産における、選択されたモジュール機能の利用をプラニングするための、少なくとも一つのプラニング・ファンクション（planning function）、
一つ以上の作業ユニットを持つ前記ジョブの生産における前記選択されたモジュール機能の利用をスケジューリングするための、少なくとも一つのスケジューリング・ファンクション、および、
一つ以上の作業ユニットを有する前記ジョブの生産（production）における、一つ以上の前記選択されたモジュール機能のパフォーマンス故障(failure)を識別する（identifying）ための、少なくとも一つのファンクション、
を備えるシステム。
請求項１に記載の再構成可能な製造システム（production system）での、コンフィギュレーション特有のオペレーションのリカバリのためのシステムであって、
一つ以上の作業ユニットを有する前記ジョブの生産における、一つ以上の前記選択されたモジュール機能のパフォーマンス故障（failure）から復旧するための、少なくとも一つのファンクション、
を更に備えるシステム。
請求項１に記載の再構成可能な生産システムでの、コンフィギュレーション特有の、オペレーションのリカバリのためのシステムであって、一つ以上の前記選択されたモジュール機能のパフォーマンス故障（failure）を識別するための前記ファンクションが、
前記選択されたモジュール機能のパフォーマンス故障を有する、一つ以上のモジュールを識別するための手段、および、
パフォーマンス故障を有する前記モジュールを、オフライン・リソースとして指定するための手段、
を備えるシステム。
作業ユニットを処理するための複数の選択的機能（alternative capabilities）を伴った複数のモジュールを有する、再構成可能なコンピュータ制御された生産システムにおけるコンフィギュレーション特有の、オペレーションのリカバリのための方法であって、
一つ以上の作業ユニットを持つジョブの生産での、選択されたモジュール機能の利用を計画(planning)し、
一つ以上の作業ユニットを持つ前記ジョブの生産での、前記選択されたモジュール機能の利用をスケジューリングし、
パフォーマンス・コマンドを、前記少なくとも一つの生産システム内の複数のモジュールに提供し、そして、
一つ以上の作業ユニットを有する前記ジョブの生産での、一つ以上の前記選択されたモジュール機能のパフォーマンス故障を識別する、
ステップを有する方法。
請求項４記載の、複数のモジュールを有する、再構成可能なコンピュータ制御された生産システム(production system)における、コンフィギュレーション特有の、オペレーションのリカバリのための方法であって、
一つ以上の作業ユニットを有する前記ジョブの生産での、一つ以上の前記選択されたモジュール機能のパフォーマンス故障から復旧するステップを更に含む方法。
請求項５記載の、複数のモジュールを有する、再構成可能なコンピュータ制御された生産システムにおける、コンフィギュレーション特有の、オペレーションのリカバリのための方法であって、パフォーマンス故障から復旧するステップが、
進行中の(in-process)作業ユニットの現在の位置からの前記パフォーマンス故障によって影響を受けた、当該進行中の作業ユニットをパージするための機能(capability)を決定し、
前記進行中の作業ユニットの現在の位置からの、前記パフォーマンス故障によって影響を受けた、前記進行中の作業ユニットを修復するための機能を決定し、
前記パフォーマンス故障によって影響を受けた、作業ユニットを包含する前記ジョブの完了のために、十分な機能が利用可能か否かを判断し、そして、
実行されるべきジョブのキューからの前記パフォーマンス故障によって影響を受けた、作業ユニットを包含するジョブを除去する、
ステップを含む方法。