JP2003072695A - 航空機の整備文書を検索するための方法及びシステム - Google Patents

Abstract

(57)【要約】 【課題】 航空機(3)の構成部品に関して整備を実施す
るとき、一般的に紙の文書(21, 24, 27)を完成させる際
の、文書を検索するためのシステムに関する。 【解決手段】 完成した文書(21, 24, 27)はデジタル化
され、他の３つのフィールド(43, 46, 49)、即ち、
（１）様式の識別、（２）航空機の識別、及び（３）日
付を含む、データベースレコード(50)のフィールド(40)
に格納される。また、整備、日付、及び整備を受ける部
品に関する記述が、データベースレコード(50)とは別個
の航空機(3)の構成ログ(6)に入力される。所定の部品に
ついての文書は、例えば部品の構成ログを検索して整備
の日付を見つけることによって容易に検索される。整備
の日付は、関心のあるデジタル化文書(40)を含むデータ
ベースレコードの検索を可能にする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、同様な文書の多量
のライブラリから所定の文書を検索するためのシステム
に関する。

【０００２】

【発明の背景】図１は、商用航空機３を示す。構成ログ
は、航空機３のオペレータによって保持され、ログブッ
ク６によって表される。実際には、構成ログは、（１）
コンピュータ・サーバ１２内に格納され、（２）テキス
ト検索可能な、コンピュータ・ファイル即ちデータベー
ス９の形態を取る。しかしながら、構成ログは、恒久的
な記録保持の概念を強調するため、ブック６として表さ
れる。

【０００３】サーバ１２は、航空機３の機内には置かれ
ず、一般的には、航空機３の所有者が運用する地上設置
施設（図示せず）内に置かれる。

【０００４】構成ログ６は、航空機３に含まれる構成部
品のうち、全てとは限らないが、その大部分のリストを
含む。例えば、エンジン（図示せず）は、ナセル１５内
に収容される。構成ログ６は、各エンジンについての記
述の他に、該エンジン内の構成部品又は部品の、全てと
は限らないが、それらの多くに関する記述を含む。

【０００５】構成部品が整備を受けるたびに、整備イベ
ントが、構成ログ６に記録される。例えば、エンジンの
ファンディスク（図示せず）が交換される場合には、交
換の事実並びに交換ディスクを識別するデータが、構成
ログ６に記録される。用語「整備」には、交換、修理、
継続的な使用に対する適合性の試験、及び構成部品に関
して行われる他の作業が含まれる。

【０００６】各構成部品が構成ログ６内で識別される精
度と特性は、構成部品毎に変動し得る。しかしながら、
一般的には、各構成部品は、構成部品の交換を行うこと
ができるように、例えば部品番号と製造メーカによっ
て、十分に識別される。

【０００７】構成ログ６においてなされる記入に加え
て、全てとは限らないが、大部分の整備イベントは、付
加的な文書の発生を必要とする。図２は、３つの整備イ
ベント、即ち１月のイベント１６、２月のイベント１
７、３月のイベント１８のタイミングを概略的に示す。
各整備イベントは、図示されるように、構成ログ６の変
更を生じさせる。

【０００８】さらに、各整備イベントは、それぞれの付
加的な文書２１、２４、２７の発生を必要とする。これ
らの文書には、米国の連邦航空局（ＦＡＡ）のような政
府機関によって必要とされる特別な印刷書類の様式が含
まれる。

【０００９】これらの文書及び様式２１、２４、２７
は、構成ログ６と比較して、各整備イベントに関するよ
り詳細な記述を含む。すなわち、構成ログ内における記
入は、文書２１、２４、２７においてより詳細に記述さ
れる整備イベントの要約として見ることができる。

【００１０】１機の航空機３の整備に関連して、毎年、
何万とは言わないが、何千の紙の文書が発生するので、
問題が生ずる。政府の取締官は、整備が正しく行われた
ことを検証するため、要請があり次第、任意の所定の整
備イベントに対応する特定の文書を検査に利用すること
を要求する。要請があり次第検索するこの要求は、各々
の紙の文書を、その場所について検索できることを必要
とする。

【００１１】索引は、例えば、所定の整備作業に含まれ
る全ての構成部品のリストを含み、整備された各構成部
品に対応する紙の文書の組の格納場所を指し示す。所定
の構成部品に関する文書を捜す人は、構成部品を索引に
おいて特定し、そこから紙の文書に導かれることにな
る。

【００１２】年毎、航空機毎に何万の索引を生成するの
は、費用がかかる。

【００１３】さらに、整備イベントが世界中の任意の場
所で発生し、従って、紙の文書が世界中のどこでも発生
し得るので、問題は悪化する。遠隔場所で作り出される
文書の索引の生成は、一層の支出を招く。

【００１４】

【発明の概要】本発明の１つの形態では、紙の文書２
１、２４、２７が生成されるとき、索引は生成されな
い。むしろ、構成ログが索引として使用され、構成ログ
が文書に案内する。

【００１５】例えば、構成部品Ａが日付Ｄに修理された
場合には、その事実は、構成ログに格納される。さら
に、（１）構成部品Ａを識別するフィールド、（２）日
付Ｄを識別するフィールド、（３）紙の文書のビットマ
ップを含むフィールド、及び（４）その他のフィールド
を含むデータベースレコードが、生成される。

【００１６】或る人が構成部品Ａに関する紙の文書を捜
す場合には、その人は、構成ログのコンピュータ検索を
行って、構成部品Ａの全ての事例を捜す。見つけられた
各事例は、日付に関連している。各日付についてのデー
タベースレコードの検索は、紙の文書のビットマップと
共に、構成部品Ａに関連する全てのレコードを特定す
る。

【００１７】別の実施の形態では、構成ログは、コンピ
ュータ検索可能な文書、即ちデータベースとして格納さ
れる。強調すべきことは、一般的に、航空機の一群にお
ける異なる航空機の各々について、多数の構成ログがま
とめておかれることである。整備イベントは、各構成ロ
グの修正を生じる。したがって、整備が行われると、構
成ログの新しいバージョンが生ずる。全てのバージョン
は、コンピュータ検索可能な形態に保存される。

【００１８】さらに、整備イベントに関する詳細な記
述、即ち紙の文書は、ビットマップにデジタル化され
る。各ビットマップは、データベース用語として使用さ
れる用語「レコード」としてのレコードに格納される。
３つの他の項目が、各レコード内に格納される。１つ
は、整備イベントの日付である。

【００１９】第２の項目は、関連する航空機の構成部品
の連続番号、又は組立体がある場合には構成部品の組立
体の連続番号である。第３の項目は、デジタル化される
紙の様式の番号である。普通は、この番号は、当該様式
に割り当てられる政府指定項目になるが、この番号は、
航空機のオペレータが指定することもできる。

【００２０】この構成では、（１）整備された構成部品
の連続番号、（２）整備イベントの日付、又は（３）政
府の様式番号から始めて、あらゆるデジタル化した文書
を特定することができる。（１）整備が行われたとき、
紙の文書についても、対応するビットマップについて
も、索引が生成されず、かつ、（２）構成ログとデータ
ベースレコードが多数の航空機に関係しているという事
実にもかかわらず、文書を特定することができる。

【００２１】要するに、本発明は、紙の文書について自
動検索システムを提供する。

【００２２】

【発明の実施の形態】構成ログ６が修正される度に、構
成ログ６の新しいバージョンが生ずる。図３は、その状
況を概略的に示す。時間が経過すると、構成ログ６の多
数のバージョン３０、３３、３６、３９が生ずる。これ
らのバージョンの全てが存在したままで、テキスト検索
可能なデータの集積、即ちデータベースとして格納され
る。

【００２３】単一の整備イベントは、新しいバージョン
を作り出すのに十分である。また、多数の整備イベント
が同時に行われる場合には、多数の整備イベントは、新
しいバージョンを作り出す。

【００２４】構成部品に関して発生する各整備イベント
について、図２において文書２１、２４、２７によって
表されるように、紙の文書が発生する。実際には今日、
これらの文書は、整備技術者が空欄に書き込む紙の形態
として存在する。これらの文書はまた、コンピュータに
よって生成されることもあり、そのような文書では、整
備技術者がキーボードで必要な情報を入力する。コンピ
ュータは、紙の文書を印刷する。

【００２５】技術が進展するにつれて、他の手法、及び
紙以外の他の有形媒体が生まれることが期待される。し
かしながら、紙の文書は、有形で物理的に実体があり、
内容を伝えることができるが、それ自体はデータとして
伝えることができないという特性を有する。

【００２６】本発明の下では、紙の文書は、例えば光学
的にデジタル化するスキャナによって、ビットマップに
デジタル化される。ビットマップは圧縮することがで
き、１つの圧縮型式の結果、いわゆるベクトルマップに
なる。ビットマップは、圧縮したか否かにかかわらず、
ここではビットマップと呼ぶこととする。ファイル即ち
データの集積である各ビットマップは、データベース用
語「レコード」としてのレコード内に格納される。図４
は、幾つかの例を示す。

【００２７】単一の構成部品が整備され、この構成部品
が参照符号３０を付したバージョン１の発生の原因であ
るものと仮定する。紙の文書（図示しないが、図２の文
書２１、２４又は２７に対応する）をデジタル化し、ビ
ットマップ４０として格納する。

【００２８】ビットマップ４０は、内部に含まれるあら
ゆるテキストがビットマップとして格納されるので、普
通はテキスト検索できず、従って、ＡＳＣＩＩ又はＥＢ
ＣＤＩＣのような標準的なフォーマットにコーディング
されない。しかしながら、ビットマップをＡＳＣＩＩフ
ォーマット又は別のテキスト検索可能なフォーマットに
変換することができる文字認識システムがある。好まし
くは、ビットマップは、格納された状態では、テキスト
検索できないフォーマットであるが、本発明は、テキス
ト検索可能なフォーマットの使用も意図している。

【００２９】さらに、他の３つの項目が格納される。第
１の項目は、整備作業が発生した時点を表すデータ４３
である。当該時点は、カレンダの日付、日時、又は航空
会社のフライト番号のような別の指標によって表示する
ことができる。

【００３０】第２の項目は、整備を行う構成部品又は構
成部品組立体の連続番号である。

【００３１】若しくは、商用航空機の製造メーカの全体
数がかなり少ないので、別の手法を使用することができ
る。製造メーカの名称、航空機の型式、及び航空機の連
続番号を使用して、航空機の或る部品を独自に識別する
ことができる。

【００３２】したがって、構成部品の連続番号のフィー
ルド４６は、構成部品又は構成部品組立体を独自に識別
するデータを含み、そのデータは幾つかの異なる形式の
ものとすることができる。

【００３３】第３の項目４９は、ビットマップとして格
納される文書の工業標準呼称である。例えば、特定の種
類の整備作業は、特定の政府様式ＡＢＣを完成させるこ
とが必要となることがある。ビットマップフィールド４
０は、完成した様式ＡＢＣを完全に含み、文書型式のフ
ィールド４９は、様式即ちＡＢＣの番号又は呼称を含
む。

【００３４】この構成では、データベース用語「レコー
ド」としてのレコード５０が生成される。レコード５０
は、フィールド４０、４３、４６、４９を含む。ビット
マップフィールド４０は、テキスト検索可能である必要
はない。ビットマップフィールド４０に格納されるバイ
トは、一般的に、英数文字を表さない。しかしながら、
他のフィールド、即ちデータフィールド４３、構成部品
又は構成部品組立体の番号フィールド４６、及び文書型
式フィールド４９は、テキスト検索可能である。これら
に含まれるバイトは、英数文字を表す。

【００３５】ビットマップ４０を得た元の紙の文書の位
置を特定する任意的なフィールド５３を設けることがで
きる。

【００３６】レコード５０に関する３つの実施形態につ
いて具体的に説明する。第１の実施形態では、レコード
５０は、他のものを除外して、フィールド４０、４３、
４６、４９を含む。第２の実施形態では、レコード５０
は、上記したフィールド、即ちフィールド４０、４３、
４６、４９に加えて、フィールド５３を含む。第３の実
施形態では、レコード５０は、フィールド４０、４３、
４６、４９、５３の任意の組合せに加えて、考えられる
他のフィールドを含む。

【００３７】図４では、レコード５０は、単一の整備イ
ベントを表し、参照符号３０を付したバージョン１に対
応する。他のレコード６０、６３、６６、６９、７２、
７５は、他の整備イベント、従って他のバージョンに対
応する。例えば、レコード６０、６３は、一緒に発生す
る２つの整備イベントに対応し、参照符号３３を付した
バージョン２で要約される。同様に、レコード６６、６
９、７２は、一緒に発生する３つの整備イベントに対応
し、参照符号３６を付したバージョン３で要約される。
レコード７５は、参照符号３９を付したバージョン４で
要約される整備イベントに対応する。

【００３８】明らかに、幾つかの整備イベントは、他の
ものより長くかかる可能性がある。例えば、レコード６
０によって表されるイベントは、バージョン２が作り出
される時点で開始することができるが、バージョン４が
作り出されるときに完了してもよい。この整備イベント
を割り当てるべきバージョンに関する問題が生ずる。取
り決めによって、レコード６０を後のバージョン４に割
り当てることができる。別の手法では、整備イベントの
開始に関するものと、整備イベントの完了に関するもの
との２つのレコード６０を作り出すことができる。

【００３９】しかしながら、構成ログ６に含まれる整備
イベントの要約の日付が整備イベントのレコード５０の
日付に対応しているので、整備イベントに関する時間の
この重複は、重要な問題ではない。この対応は、一方を
他方に導き或いはリンクすることを可能にする。構成ロ
グ６内の重複は、このリンクを阻止しない。

【００４０】３０、３３、３６、３９のような全てのバ
ージョンの集積を、累積構成ログと呼ぶこととする。

【００４１】各バージョンには、日付が割り当てられ
る。日付は、期間として取り扱うことができ、その期間
の間において、バージョンは、有効な構成ログとなる。
すなわち、新しいバージョンが生ずるとき、新しいバー
ジョンが立ち上がるまで、それ以前のバージョンが有効
な構成ログとして作用したものである。以前のバージョ
ンは、或る期間では有効であったが、時間とともにある
時点で有効ではなくなったものである。しかしながら、
期間を表す２つの日付を使用することができるが、各バ
ージョンに、生成の日付のような単一の日付を割り当て
るのが好都合である。

【００４２】この構成が得られると、任意の所望の紙の
文書のビットマップ４０を特定する検索を実行すること
ができる。幾つかの例は、検索が如何に実行されるかを
示す。

【００４３】例１ 遠く離れた国の特定の航空機において圧力センサの型式
Ｘが破損したことを新聞が報じたものと仮定する。異な
る航空機を所有する航空会社は、この圧力センサＸがそ
の航空機のいずれかに搭載されているかどうかを問い合
わせることができる。

【００４４】航空会社は、圧力センサを識別する検索文
字列を使用して、蓄積構成ログの検索を実行する。検索
は、検索文字列の事例を見つけるか或いは見つけないこ
とになる。

【００４５】前者の場合では、検索文字列の１又はそれ
以上の事例が発見される。これらの発見は、データベー
ス用語では、ヒットと呼ばれる。この場合には、航空会
社は、センサＸが現在取り付けられているか否かを確か
めるために、これらのヒットを調査する。例えば、時間
的に最後のヒットは、センサＸが或る時点では取り付け
られていたが、取り外されてしまったことを表すことが
ある。

【００４６】他の可能性として、ヒットしないことがあ
り、これは、センサＸがログに対応する航空機に取り付
けられていなかったことを表す。

【００４７】この検索は、センサＸを含む整備イベント
の要約を捜し当てて、例えば、センサが現在その航空機
に取り付けられているか否かを示すことができる。

【００４８】例２ 例１の続きとして、航空会社が、圧力センサＸの詳細な
整備履歴を知ることを望んでいるものと仮定する。例１
における各ヒットは、或るバージョンで発見される。そ
のバージョンは日付を持つ。

【００４９】ここでは、バージョンの概念を調査するの
が好都合である。別の実施形態では、バージョンは、実
際には使用されない。その代わり、整備が発生する度
に、整備イベントの日付と共に、各整備イベントの要約
が構成ログに加えられる。構成ログから何も取り除かれ
ない。したがって、各整備イベントを日付と関連させた
状態で、連続的に拡大する蓄積ログが生成される。この
例では、各ヒットは、これらの日付の１つに関連するこ
とになる。

【００５０】したがって、バージョンの概念の下では、
整備イベントの要約を含むバージョンの日付によって、
整備イベントに日付が割り当てられる。直接入力の概念
の下では、日付は、要約に直接関連する。いずれの場合
においても、要約には、日付が付けられる。

【００５１】全てのレコード５０に関する第２の検索
が、図４におけるデータフィールド４３に対して実行さ
れ、第１の検索で発見された日付を探す。これらのヒッ
トは、関連するビットマップを含むレコードを識別す
る。

【００５２】上述の事項、換言すると、第１検索で発見
されたヒットは、センサＸに関係する要約を識別する。
例えば、図５における２つのヒット５５、５８が生ずる
ことがある。いま、これらのヒットに対応する整備イベ
ントの詳細な記述が望まれる。これらの記述は、レコー
ドの集積の中に同じデータを見つけることによって発見
される。

【００５３】すなわち、各ヒット５５、５８は、蓄積構
成ログが如何にして系統立てられるかに応じて、日付、
即ちバージョンの日付又は整備の日付のいずれかを発見
する。その日付はまた、ヒット５５、５８に対応する整
備イベントを記述するレコード５０の日付フィールド４
３にも出現することになる。

【００５４】検索は、レコード５０の集積６１に対して
実行され、データフィールド４３においてこれらの２つ
の日付を探す。レコード５０が発見されると、これらの
レコードのビットマップフィールド４０は、整備イベン
トを記述する。問題のトランスデューサＸが含まれる場
合には、それらについて言及される。

【００５５】例３ 例１の別の続きとして、様式ＸＹＺの完了を必要とする
特定の整備手順をトランスデューサのいずれかで実施し
たか否かを、航空会社が知ることを望んでいるものと仮
定する。

【００５６】例２におけるように、ヒット５５、５８に
対応するレコード５０を特定する。その際、２つのレコ
ードに関する図４の文書型式のフィールド４９を、ＸＹ
Ｚについて検索する。いずれかのレコード５０が様式Ｘ
ＹＺのビットマップを含む場合には、検索は、そのこと
を表すことになる。

【００５７】例４ ガスタービンエンジンのファンディスクのような、特定
の部品の整備履歴が必要である。当該部品の全ての事例
を見るために、蓄積構成ログに対してテキスト検索を実
行する。そのヒットは、当該部品の一切の整備イベント
の要約、従って当該部品の整備履歴の要約を提供する。

【００５８】次に、レコード５０の日付フィールド４３
を、各ヒットで識別された日付について検索する。その
結果、ヒットを含む各バージョンに対応するレコード５
０が探索される。

【００５９】この検索の結果、部品に係わる種々の整備
作業を記述する文書のビットマップを含む全てのレコー
ドが識別される。

【００６０】部品が１つの航空機から別の航空機に移さ
れた場合には、疑わしい全ての航空機の蓄積構成ログの
テキスト検索を行わなければならない。

【００６１】例５ 政府の検査官が、部品ＡＢＣの整備が様式ＸＹＺで何度
報告されているかを知ることを望んでいるものとする。
その回答を得るために、図５のレコード６０の集積に対
して検索を行い、文書型式フィールド４９においてＸＹ
Ｚを探す。この検索の結果、様式ＸＹＺの整備の事例に
関する全てのレコードが識別される。

【００６２】次に、蓄積構成ログに対して検索を実行
し、（１）上記で識別したレコードの日付と（２）部品
ＡＢＣを探す。

【００６３】すなわち、第１の検索は、様式ＸＹＺを含
む全てのレコード５０を識別する。単一のバージョンが
多数のレコード５０に対応することもできるが、各レコ
ード５０は、構成ログのバージョンに対応する。これら
のバージョンは、部品ＡＢＣの整備を吟味するため、特
定され検索される。

【００６４】別の手法では、ビットマップ４０に様式Ｘ
ＹＺを含むレコード５０が識別されると、部品ＡＢＣを
吟味するため、ビットマップ４０を手作業で検索するこ
とができる。

【００６５】一般化した例 新しい航空機が、その製造メーカによって納入される。
図６において参照符号３０を付したバージョン１は、そ
の構成部品を記述する。今のところ、整備は行われてい
ない。

【００６６】整備イベントが部品番号２で発生する。上
述のように、レコード１０５が生成される。さらに、レ
コードの３つのフィールド内のデータが、参照符号３３
を付したバージョン２に挿入される。これらのフィール
ドは、日付フィールド４３、構成部品又は構成部品組立
体の連続番号フィールド４６、及び文書型式フィールド
４９である。これらの３つのフィールド４３、４６、４
９は、ブロック１１０によって表され、矢印１１５で示
されるように、整備された部品、即ち部品番号２の入力
と関連する。これは、単純化することができる冗長性を
作り出すものであることが分かるであろう。

【００６７】同様に、後の時点において、部品番号４で
整備が発生する。参照符号３６を付したバージョン３で
は、対応するレコード１１６の３つのフィールド４３、
４６、４９が挿入され、部品４の入力と関連する。これ
らの３つのフィールドは、レコード１１６のサブレコー
ド又はサブセットと呼ぶことができる。

【００６８】この構成の下では、各レコードのサブセッ
ト、即ち、日付フィールド４３、登録番号４６、及び文
書型式４９は、構成ログ６内の問題となる部品の対応す
る入力と関連する。この構成の下では、構成ログ６内の
部品の各入力は、レコード１１６のような、対応するレ
コード、従って、紙の文書のビットマップ４０と直接リ
ンクする。このリンクは、１１６のようなレコードがデ
ータベース・レコードであり、フィールド４３、４６、
４９のような、それらのフィールドのコンテンツを検索
して、特定のフィールド・コンテンツを有するレコード
を特定することができるという事実によって生ずる。

【００６９】例えば、部品２のような番号に基づいて、
構成ログ内の部品をまず見つけることによって、整備し
た部品の番号は、レコード、従ってビットマップに到達
することになる。すると、ブロック１１０のような関連
するレコードサブセットは、実際にレコード１１１に到
達する。

【００７０】別の例として、例えば部品２についてブロ
ック１１０内で日付を特定することによって、日付は、
１又はそれ以上のレコードに到達することになる。する
と、例えば同じ日付、又はブロック１１０内の他のフィ
ールド内の他の日付を使用することによって、レコード
１１１は特定される。

【００７１】しかしながら、１１０のようなブロックの
幾つかのフィールドには、冗長性がある。登録番号は、
構成ログ６の特徴であり、各整備イベント時に挿入する
必要はない。また、整備した部品について要約を作成す
ると、日付も、自動的に挿入される。したがって、この
例では、構成ログ６に挿入する必要がある項目のみが文
書型式フィールド４９となる。

【００７２】幾つかの例では単一のサーバを使用するこ
とができるが、この例では、蓄積構成ログ６は、サーバ
１３０に格納され、レコード９０は、別のサーバ１３５
に格納される。別の手法では、多数のサーバにわたる分
散型格納を使用することができる。データベースメンテ
ナンス用ソフトウェア１４０は、ユーザが上述の検索を
行うことを可能にする。

【００７３】レコード５０が、関心のあるビットマップ
４０を含むものとして識別されると、例えばインターネ
ットで送ることによって、該ビットマップを捜している
人に、該ビットマップのコピーを送ることができる。

【００７４】図７は、本発明の１つの形態によって行わ
れる手順を示すフロー図である。ブロック２００は、航
空機の部品について整備を行うことを表す。ブロック２
０５は、具体的な様式が整備技術者によって生成される
ことを表す。

【００７５】ブロック２１０は、様式を走査してビット
マップを生成することを表す。ブロック２１５は、
（１）ビットマップと、（２）日付と、（３）航空機の
登録番号と、（４）具体的な様式の番号、即ち政府指定
の項目とを含むフィールドを含むデータベースレコード
が生成されることを表す。

【００７６】ブロック２２０は、整備の日付のような関
連する日付と共に、整備に関する記述が構成ログに挿入
されることを表す。構成ログ内の当該記述は、整備され
た部品の記述と関連する。ブロック２２５は、紙の様式
の索引が生成されないことを表す。

【００７７】以上述べた手順は、他の整備イベントにつ
いても、繰り返される。

【００７８】次に、ブロック２３０が表示するように、
ユーザは、関心のあるレコードを特定する。データベー
スレコードは、ブロック２１５の手順によって生成され
るものであり、データベースレコードは、例えばここに
記述する検索手順の１つによって、特定される。ブロッ
ク２３５は、データベースレコード又はレコード全体に
含まれるビットマップが、インターネットのようなネッ
トワークを介して、ユーザに送られることを表す。この
伝達により、ビットマップはユーザの所有物となり、こ
のユーザは、今では、ブロック２０５で生成された紙の
文書のコピーを特定することができる。

【００７９】本発明の顕著な特徴は、整備が行われる
と、整備技術者によって紙の様式に書き込まれることで
ある。図４のビットマップ４０が、これらの様式から生
成される。しかしながら、図４のレコード５０の生成以
外には、これらの様式について索引の生成は行われな
い。

【００８０】これに対して、従来技術では、整備が行わ
れる構成部品の索引、即ち内容に関するテーブルが生成
される。この索引は、整備された各構成部品のリスト
と、各々に対応する紙の文書の位置とを含むものであ
る。クロス索引を生成することもある。大規模な整備手
順については、このような索引の生成は、非常に時間の
かかることとなる。本発明は、このような索引の生成を
取り除く。

【００８１】本明細書における説明は、幾つかの技術用
語を含む。これらの用語の適当な定義を以下に述べる。
他の定義も可能である。

【００８２】構成ログは、航空機を構成する部品又は構
成部品に関する記述を含む。しかしながら、アルミニウ
ム板を翼桁に接合するリベットのような、一般的な代替
可能な部品は含まれない。原則として、構成ログ内に含
まれるあらゆる品目を購入することができ、航空機全体
を製造することができる。

【００８３】さらに、政府規則は、構成ログの所要の内
容を規定する。政府が異なれば、内容に関する要件が異
なる。

【００８４】データベースレコードは、データベースの
基礎単位である。電話帳は、データベースの一例であ
る。このデータベース内のデータベースレコードは、各
加入者にとって個別的な記入事項である。例えば、１つ
のレコードは、ジャック・ジョーンズ、オハイオ州シン
シナチ、ウィロウテラス４３４３、電話（５１３）４４
４−６０６０となる。

【００８５】レコードは、フィールドに分割される。こ
の特別のレコードは、次のフィールド、即ち、（１）姓
（ジョーンズ）、（２）名（ジャック）、（３）通りの
番号（４３４３）、（４）通りの名称（ウィロウテラ
ス）、（５）市の名称（シンシナチ）、（６）州の名称
（オハイオ）、（７）市外局番（５１３）、（８）局番
（４４４）、及び（９）電話番号（６０６０）を含む。

【００８６】したがって、レコードは、フィールドを含
む。図６のブロック１４０で表されるもののような、公
知のデータベース管理ソフトウェアは、所定のフィール
ドを識別し、全てのレコードにおいて当該フィールドを
検索するのを可能にする。例えば、電話帳において、全
てのレコードにおいて通りの名称に関する検索を実行し
て、文字列「ウィロウテラス」を見つけ出すことができ
る。検索の結果、通りの名称フィールドにおいて語句
「ウィロウテラス」を含む全てのレコードを識別する。

【００８７】さらに、データベース管理ソフトウェア
は、ブール変数のような、フィールドの検索を結合する
のを可能にする。例えば、検索は、（１）通りの名称フ
ィールドにおいて「ウィロウテラス」及び（２）姓のフ
ィールドにおいて姓「ウィルソン」を有する全てのレコ
ードを捜すことができる。別の例として、検索は、
（１）通りの名称フィールドにおいて「ウィロウテラ
ス」を有するが（２）市の名称フィールドにおいて「シ
ンシナチ」を有しない全てのレコードを捜すことができ
る。

【００８８】レコードにおけるフィールドのコンテンツ
は、英数文字である必要はない。例えば文書が光学的に
走査され、得られたビットマップがフィールドに格納さ
れる場合、所定のフィールドは、ビットマップデータを
含むことができる。このようなビットマップは、直接テ
キスト検索をすることはできない。しかしながら、ビッ
トマップについて文字認識を行って、ビットマップ内の
任意の英数文字をＡＳＣＩＩコード又は同等のものに変
換した場合には、当該コードに関してテキスト検索を行
うことができる。

【００８９】ビットマップがデータベースレコードのフ
ィールド内に含まれることは、厳密には必要とされな
い。フィールドは検索可能であるが、ビットマップは検
索することはできず、より正確には、任意の検索の実行
は、無意味なものを生成することがある。その代わり、
ビットマップをデータベースレコードにリンクさせるこ
とができ、データベースレコードが特定されると、これ
によりビットマップも特定される。

【００９０】「維持する」は技術用語であり、単に現状
を保つことを意味しない。それは、設備において時間の
経過による有害な影響を克服するのに必要とされる行動
を指す。それは、設備を作動状態に保つのに必要とされ
る行動を指す。ある意味では、用語「維持する」は、
「良好な作動状態を維持する」という語句の簡略表記で
ある。

【００９１】本発明の技術思想と技術的範囲から逸脱す
ることなしに、多くの置換及び修正を行うことができ
る。本特許権によって保護されるのを望むものは、特許
請求の範囲に定められる発明である。なお、特許請求の
範囲に記載された符号は、理解容易のためであってなん
ら発明の技術的範囲を実施例に限縮するものではない。

【図面の簡単な説明】

【図１】 航空機３及びその関連する構成ログ６を示す
図。

【図２】 構成ログ６に生ずる一連の変更を示す図。

【図３】 異なるバージョンの構成ログ６が時間の経過
につれて生ずる概念を概略的に示す図。

【図４】 データベースレコードが各バージョンと関連
する概念を概略的に示す図。

【図５】 如何にしてバージョンを使用して紙の文書の
ビットマップ４０を特定することができるかを示す図。

【図６】 本発明の１つの形態を示す図。

【図７】 本発明の１つの形態によって行われる手順を
示すフロー図。

【符号の説明】

６ 構成ログ ２１、２４、２７ 紙の文書 ３０、３３、３６ 構成ログの連続するバージョン ４０ ビットマップ（デジタル化文書） ４３ 日付のフィールド ４６ 構成部品の連続番号のフィールド ４９ 文書型式のフィールド ９０ データベースレコード １１１、１１６ 個々のレコード １１０ ブロック １３０、１３５ サーバ １４０ データベース管理ソフトウェア

───────────────────────────────────────────────────── フロントページの続き (72)発明者 マイケル・ロバート・ラ・ブラン アメリカ合衆国、ニューヨーク州、ウィル トン、ダンデリオン・ドライブ、14番 Ｆターム(参考） 5B075 ND20

Claims (13)

【特許請求の範囲】
1. 【請求項１】 （ａ）航空機（３）の整備を実施する段
   階と、 （ｂ）ｉ）前記整備に関する記述と、ii）前記整備の日
   付とを含むコンピュータ検索可能なデータベースレコー
   ド（５０）を生成する段階と、を含むことを特徴とする
   方法。
2. 【請求項２】 ｉ）前記記述が、政府の指定項目を持つ
   政府発行様式のビットマップ（４０）コピーに含まれ
   る、ことを特徴とする請求項１に記載の方法。
3. 【請求項３】 前記記述がテキスト検索不能なフィール
   ド（４０）に含まれ、前記日付が検索可能なフィールド
   （４３）に含まれる、ことを特徴とする請求項１に記載
   の方法。
4. 【請求項４】 （ａ）航空機（３）の整備を実施する段
   階と、 （ｂ）ｉ）テキスト検索不能なフォーマットにおける前
   記整備に関する記述（４０）と、ii）テキスト検索可能
   なフォーマットにおける前記整備の日付（４３）とを含
   むデータベースレコード（５０）を生成する段階と、 （ｃ）前記整備に従って前記航空機（３）のテキスト検
   索可能な構成ログ（６）を修正する段階と、を含むこと
   を特徴とする方法。
5. 【請求項５】 （ｄ）前記段階（ａ）、（ｂ）及び
   （ｃ）の手順を繰り返して、ｉ）多数のデータベースレ
   コード（５０）と、ii）それぞれの期間に各々対応する
   前記構成ログ（６）の多数のバージョン（３０、３３、
   ３６、３９）とを生成する段階を更に含むことを特徴と
   する請求項４に記載の方法。
6. 【請求項６】 （ｅ）特定の構成部品を表すテキストに
   ついての前記ログ（６）の前記多数のバージョン（３
   ０、３３、３６、３９）を検索する段階と、 （ｆ）あるバージョン内にテキストが見つけられたと
   き、前記バージョンの期間を識別し、前記期間に合致す
   るレコード（５０）を検索して、前記レコード（５０）
   における前記整備の記述を特定する段階と、 を更に含むことを特徴とする請求項５に記載の方法。
7. 【請求項７】 （ａ）ｉ）１機の航空機（３）に各々対
   応し、ii）それぞれの期間中における前記航空機（３）
   の構成を各々が記述する多数のバージョン（３０、３
   ３、３６、３９）を各々が備える、複数の構成ログ
   （６）と、 （ｂ）それぞれの整備イベントに各々が対応し、ｉ）前
   記整備イベントを記述する文書のビットマップ（４０）
   と、ii）整備された前記航空機の登録番号を含む検索可
   能なフィールド（４６）と、iii）前記整備イベントの
   日付を含む検索可能なフィールド（４３）とを各々が備
   える、複数のデータベースレコード（５０）と、を含む
   ことを特徴とするシステム。
8. 【請求項８】 前記各データベースレコード（５０）が
   更に、前記ビットマップに含まれる文書の型式を識別す
   る番号を含む検索可能なフィールド（４９）を含むこと
   を特徴とする請求項７に記載のシステム。
9. 【請求項９】 前記各データベースレコード（５０）
   が、付加的な検索可能なフィールドを含まないことを特
   徴とする請求項７に記載のシステム。
10. 【請求項１０】 （ａ）航空機（３）の構成部品に関す
    る作業を実施する段階と、 （ｂ）様式番号を持つ様式（２１、２４、２７）上に、
    前記作業の記述を行う段階と、 （ｃ）前記記述のデジタルバージョン（４０）を生成す
    る段階と、 （ｄ）次の項目、即ち、ｉ）前記デジタルバージョン
    （４０）、ii）前記構成部品の連続番号（４６）、ii
    i）前記作業の日付（４３）、及び、iv）前記様式番号
    （４９）のうち、２又はそれ以上を含むデータベースレ
    コード（５０）を生成する段階と、を含むことを特徴と
    する方法。
11. 【請求項１１】 前記デジタルバージョンが、ｉ）コン
    ピュータ画面上に表示可能であり、ii）コンピュータネ
    ットワーク上で伝達可能である、ことを特徴とする請求
    項１０に記載の方法。
12. 【請求項１２】 前記航空機（３）のほぼ全ての構成部
    品に関する記述を含む、前記航空機（３）の構成ログを
    維持する段階を更に含むことを特徴とする請求項１０に
    記載の方法。
13. 【請求項１３】 前記航空機（３）で整備イベントが発
    生するのに伴って、前記構成ログ（６）の連続するバー
    ジョン（３０、３３、３６、３９）を生成する段階を更
    に含むことを特徴とする請求項１０に記載の方法。