メンテナンス エンジニアリングを実行するプロセスは、次のサブプロセスで構成されます。
このサブプロセスは、その存続期間中にシリアル構成を維持するために必要なアクティビティを処理します。このサブ プロセスには、シリアルを廃棄または削除するアクティビティも含まれます。
シリアルは、定期メンテナンスや故障など、さまざまな理由で交換されます。アプリケーション内のシリアル構成は、実際の組立で行われた変更に応じて更新する必要があります。システムには、これらの変更を支援するいくつかの機能があります。
シリアルが構成から削除された場合、シリアルをどうするかを決定する必要があります。これには、シリアルの廃棄または修理が含まれます。
シリアルは次の場合に削除できます。
アプリケーションからシリアルが削除された場合でも、シリアルの履歴データを表示できる場合があります。これは、シリアルを削除するときに選択したオプションによって異なります。
シリアルのすべての構成ルールはテンプレート構成に組み込まれており、構成の変更が報告されるとこれらのルールが検証されます。構成ルールは、構成内のどこにどの構成品目番号が許可されるか、特定の位置にインストールされるコンポーネントの数、互換性ルール、および異なる位置にある品目間の依存関係を制御します。
このサブプロセスは、構成不一致エントリーの調査と処理を行います。作業オーダーまたは製造オーダーから実行される構成変更インストール、IFS/フリート管理のシリアル構成の別の場所にすでにインストールされている構成品目のレポート、またはシリアル構成にインストールされていない構成品目の削除をレポートできます。これにより、構成不一致のログ エントリーが作成されます。何らかの処置を行う必要があるかどうかを決定する前に、まず原因を調査し、構成に必要な修正を行う必要があります。
IFS/フリート管理のシリアル構成に対して直接作業している場合、構成の不一致のログ エントリーは作成されませんが、代わりにエラーメッセージが表示されます。
このサブプロセスは、IFS/フリート管理に保存されている履歴データとデータ クエリの分析を処理します。信頼性分析は、メンテナンスの改善領域の特定、繰り返しの不具合を回避するための施設/設備器の修正の必要性、不良構成品目の特定など、多くの面で重要です。
分析は、レポート、IAL、キューブ、ポートレットなどのさまざまな機能を使用して実行されます。
このサブプロセスは要件を認定するために使用されます。
このコンテキストにおける要件としては、たとえば、製造会社からのサービス速報やサービスレター、当局からの耐空性指令、または社内の信頼性分析から生じる変更要求などが挙げられます。
すべての要件は変更要求 (CR) として登録し、要件の適用可能性の評価は CR に基づいて行う必要があります。評価プロセスは、承認プロセスとステータスの変更を利用して実行する必要があります。
要件が組織に適用できないことが判明した場合は、CR をキャンセルする必要があります。それ以外の場合は、さらに処理して変更オーダー (CO) を作成する必要があります。要件が適用される施設/設備の種類が組織で使用されていない場合、または提案された変更に財務的または機能的なメリットがない場合は、要件は適用されません。
このサブプロセスは、適用可能な CR をどのように実装するかを定義するために使用されます。
CR がアクティブ化され、承認された後、CO を使用して変更を実装するために必要な手順が定義されます。CR の要求元と変更の種類によって、必要な作業が決まります。たとえば、サービス速報や耐空性指令では必要な手順がすでに定義されている場合があり、それをアプリケーションに入力するだけで済みますが、社内エンジニアリング指示の場合は、必要な手順を定義するために完全なエンジニアリング プロセスを実行する必要がある場合があります。システム内のドキュメントやデータを更新するだけで十分な場合もありますが、物理的な作業が必要な場合もあります。
手順が定義され承認されると、通常、フリートの変更の実際の実装を管理するために、IFS/フリート管理で変更が作成されます。
このサブプロセスは、保守計画ドキュメントとメンテナンス レビュー委員会レポートを管理するために使用されます。このプロセスはほぼ手動のプロセスであり、IFS Cloud では完全にはサポートされていません。
これらのドキュメントには、当局または製造会社によって定義されたメンテナンス要件が含まれており、これらすべての要件は、適用可能性、頻度などに基づいて評価および整理され、生産で使用される前に保守部門の手順に採用される必要があります。
メンテナンス要件が必要なプロセスを経ると、フリートの保守プログラムが形成され、このプログラムがアプリケーションに読み込まれます。
アプリケーションに保守プログラムを入力すると、保留中のタスクが生成され、保守オーダーを通じて実行を計画できるようになります。