Disconnected Operations

In defense operations, air vehicle and inventory assets are deployed from main operating bases (MOBs) to forward operating bases (FOBs) and back again, or assets can be transferred between forward bases. For periods of time, bases might operate without internet connectivity to the central maintenance management system and the central technical records repository.

When assets are deployed, their baseline and technical records are required at the destination base to ensure the base can maintain assets independently and in compliance with regulations.

If a disconnected base performs maintenance for an extended time, the base might need to do the following:

Send technical record updates to keep wing command informed of the state of its fleet.
Receive baseline updates if the Central Engineering Authority has updated the baseline.
Receive resupply shipments of inventory required for maintenance.

The Disconnected Operations solution is set-up with multiple instances or installations of IFS Cloud, one for the Central Engineering Authority, one for the central Technical Records Repository, and separate instances for each MOB and FOB that will export or import assets or records. When assets are deployed in the real world, assets, baseline records, and technical records must be exported from one IFS Cloud instance and imported to another.

Each base or location that you intend to export from or import to, including the central Technical Records Repository and the Central Engineering Authority, is modeled as an AIRPORT location. Each base or location that imports shipments of inventory, has a DOCK sub-location to receive shipments.

The following applications and features are part of the Disconnected Operations solution:

Component or application	Description
IFS Maintenix	Application used to define system, equipment, and baseline configuration, plan maintenance, handle part and tool availability, record maintenance and maintain compliance. Shipments of pack-up kits and loose inventory are created in Maintenix.
Disconnected Operations Workflow Manager	Application used to export files from source site and import files at destination site when aircraft and inventory shipments are deployed or resupply shipments, baseline updates, or send technical record updates are sent.
Central Engineering Authority (CEA)	An instance of IFS Cloud in which engineers use IFS Maintenix and Allowable Configuration to maintain the maintenance and equipment baselines. Baselines are maintained exclusively in this instance and updates are exported to bases.
Aviation Technical Content Manager-Allowable Configuration	Application used by configuration specialists to update part group information based on changes from external sources such as manufacturer's Illustrated Parts Catalog (IPC), Air Worthiness Directives, or Service Bulletins/ Letters. Changes are published to Maintenix in the Central Engineering Authority instance of IFS Cloud. (Part group changes are not made in Maintenix.)
Technical Records Repository (TRR)	An instance of IFS Cloud which serves as the central storage location for the technical records of aircraft and other inventory. Each instance of IFS Cloud has a TRR with a portion of an asset's records, but the full set of records required by planners and others is only available in the central location. Bases keep the central TRR updated by sending technical record updates.

When assets are exported using the Disconnected Operations Workflow Manager, the exporting system archives the asset. This ensures that there is only one active asset record.

Summarizing broadly, the data included in the transfer files when assets or records are exported is as follows:

The aircraft asset itself and its sub-assemblies with the current snapshot of aircraft baseline configuration, installed inventory, state, usage, last done tasks, and open faults.
Baseline and system engineering data including the equipment and maintenance baselines. To enable aircraft and inventory items to be successfully imported (without compliance issues) at a FOB destination, the baseline at the FOB must be updated for the incoming assets. Asset transfers automatically include baseline updates the deployment export file. Baseline updates can also be sent separately to a base that has been disconnected for an extended time.
The technical records of maintenance history for aircraft and inventory assets (not the whole history, but a portion as configured for a specified number of days).
Shipments of pack-up kits (or loose inventory and tools required for maintenance), including all open faults and tasks for the inventory items.

You might deploy from a MOB to a FOB or from FOB to FOB, FOB to MOB, or MOB to MOB. When deployed aircraft assets complete a mission and return from a FOB to a MOB, or are transferred elsewhere, the export and import process is performed in reverse, exporting from the FOB, and importing to the MOB.

Central Engineering Authority

The Central Engineering Authority creates and maintains the maintenance and equipment baselines in a separate instance of IFS Cloud.

The equipment and maintenance baselines are updated in the IFS Maintenix application with the exception of part group updates which are made in Allowable Configuration and published to IFS Maintenix.

During the initial set-up, the full baseline is created in the Central Engineering Authority instance and in MOB and FOB instances of IFS Cloud. After the initial set-up, when engineers in the CEA create, update, or delete baselines - for example, they add a new assembly or revise a job card definition, the baseline changes are bundled into batches by a scheduled task. Batches are saved in the CEA instance and are available for export.

The published batches of updates are transferred in the following ways:

When baseline updates are sent by the Central Engineering Authority or sent from a MOB at the request of a FOB, all updates are sent, unless you know the batch number a that a base is currently using and you can select a specific batch as a starting point. A FOB can check the batch number its system is using and communicate the number to the MOB. The baseline update includes the starting batch number and the batches up to the current number in use at the sending location.
In full deployments, 52 batches of baseline updates are automatically transferred with assets. The number of batches sent is configurable.

Depending on your operation, the CEA might export baseline updates primarily to MOBs. The MOBs in turn might export baseline updates to disconnected FOBs. The transfer of updates to a disconnected FOB might rely on the manual transport of the data on a USB stick carried by a pilot deployed from a MOB to a FOB.

Not all elements of the maintenance and equipment baselines are exported. For example, the Maintenance Program feature in IFS Maintenix that groups all maintenance requirements for an asset, is not supported in the Disconnected Operations solution. Some elements of the baseline, such as Bins, are created, updated, and deleted in the local base instance.

Data transferred with deployments and updates

When aircraft assets and inventory shipments are deployed, or when baseline and technical records updates are sent, data is transferred from one instance of IFS Cloud to another. The following data is exported and imported:

Assets

The following details are included in the asset transfer file when aircraft and installed sub-components, or loose inventory are transferred (as appropriate for the inventory class):

Data	Includes	Excludes
Inventory details	OEM part number Manufacturer code Serial number Barcode Manufacturer date Received date Applicability code (Aircraft, ASSY) Operator code (ASSY only) Condition Authority Owner Quantity (only loose inventory)
Aircraft details (unique for aircraft)	Registration code Capability code Country code Regulatory body OEM Variable Number OEM Line Number Operating status Forecast model Capabilities levels (Capabilities tab)
Configuration snapshot	Configuration slots Part groups Installed parts 'Holes' or slots without installed inventory
Last done COMPLETE baseline task	Last completed, historical tasks Blocks on sys slots: One-time recurring and non-recurring Requirements JIC task associated with last done requirement Task details transferred: Task Name and Task Barcode (ID) Inventory ID (Manufacturer, Part Number, Serial Number, Bar Code) Task Status Task Completion Date Usage at task completion	Block Chain recurring and non-recurring Attachments Task details: Part Requirements Labor Requirements Action information for executable requirements
Faults	Open Deferred Damage records	Attachments
Usage	Current usage of the asset and installed sub-components (ASSY, TRACK)

How it works: ACTV baseline tasks

Active baseline tasks aren't exported. Instead, the system creates them at the import location. Here's how: when an aircraft or asset with recurring tasks is exported, the last done block or requirement is exported. When assets are imported, baseline synchronization runs and initializes active instances of blocks, requirements, and job cards for the assets. Asset transfers always include baseline batch updates, so if the baseline at the import location is out of date or less current than the export location, the baseline batch number at the import location is automatically updated. So the task that was active at the export location is recreated properly at the import location. Baseline synchronization also creates forecasted tasks for the imported assets.

Technical records

A portion of an asset's technical records is automatically transferred when assets are deployed or when a base sends a technical record update to another base or the Technical Records Repository. By default, the portion is 365 days worth of records before the date on the deployment export file. The number of days is configurable.

When technical records of the maintenance and usage history are exported, the following historical information is included:

Historical record	Aircraft	Components
Faults completed and deferred
Tasks completed (BLOCK, REQ, JIC, ADHOC tasks)
Work Packages completed
Component work packages completed
Flights completed
Usage values recorded for completed events and usage corrections (assembly, tracked, and serial parts)
Configuration (component removals and installations on tracked and assembly configuration slots)
Installation (assembly, tracked, and serial parts)
Reliability notes resolved

Baseline data

When aircraft or inventory items in shipments are transferred in a full deployment, by default, 52 batches of baseline data are automatically included in the export file. The batch numbers included are the current batch number in use at the exporting location and additional batches counting back 51 previous updates. The default value is configurable; the value set is the maximum number of updates that are transferred with assets. (Initially, at the time of an asset transfer, there could be less than 52 batches in a system.) The time span covered by one batch of baseline updates, depends how baseline publishing is configured. For example, if batches are created once a week, then 52 batches represents 52 weeks of baseline updates.

During import, if the current batch number in the importing system is less than the highest batch number in the transfer file, the system updates the current batch number in use. For example:

MOB with a current batch number of 104 exports to a FOB that's on batch number 100. After import, the FOB's current batch number in use is updated to 104.
A FOB with a current batch number of 100 exports to a MOB that's on batch number 104. After import, the MOB's current batch number is unchanged.

When baseline updates are sent separately from assets, all batch updates are sent up to the current batch number in use at the sending location - unless the sender manually selects a particular batch as the starting point for the range of updates. (A base can find the last baseline batch number imported at their location and request an update starting at a specific batch number.)

The following baseline data is included in deployment or update transfers:

Activated task definitions including:
- Requirements (excluding advisories, impacts, technical references, warranties, zones, panels, tail number-specific and part-specific scheduling rules, weight and balance, execution details)
  - Replacement (REPL)
  - Part transformation (MOD)
  - Overhaul (OVHL)
  - Corrective action (CORR)
  - Discard (DISCARD)
  - Repair reference (REPREF)
  - Follow-on (FOLLOW)
  - Requirement (REQ)
- Job cards
  - Clean (CLEAN)
  - Close (CLOSE)
  - Close Panel (CLOSEPANEL)
  - Inspection (INSP)
  - Install (INST)
  - Job Card (JIC)
  - Open (OPEN)
  - Open Panel (OPENPANEL)
  - Approved Repair (REP)
  - Removal (RMVL)
  - Servicing (SRVC) Routine tasks
  - Test (TEST)
- Blocks (excluding technical references, task links, and part-specific or aircraft-specific scheduling rules)
- Fault definitions
- Deferral references in Active status
- Part numbers (excluding technical references, alternate purchasing units of measure, repair locations, vendors, bin levels, and advisories)
- Part groups, including incompatible parts
- Configuration slots, including usage parameters and positions
- Assemblies (excluding capabilities, flight measurements, failure effects)
  - Basic details
  - Usage definitions
  - Sensitivities
  - Zones and panels
- IETMs -interactive electronic technical manual
- Measurement definitions

Transfer process and transfer types

To deploy aircraft and inventory shipments, an administrator in a source location uses the Disconnected Operations Workflow Manager to create and export a file out of IFS Cloud. The administrator saves the file on their local machine, then copies it to a file path, address, or device such as a USB stick where the file can be accessed by the destination location. An administrator or crew member at the destination location uses the Disconnected Operations Workflow Manager to access and import items contained in the file into their instance of IFS Cloud. The same process is used to transfer technical records and baseline updates.

Depending on what you need to do, you prepare a full deployment or send an update.

Deployment option	Use to	Notes
Full deployment	Deploy aircraft and shipments Deploy aircraft Deploy shipments (send resupply shipment)	A portion of the asset's technical records are automatically included in the exported file. Baseline updates are automatically included in the exported file.
Send update	Send technical record updates Send baseline updates

Preparing and exporting a file

Creating and exporting a file is a two-step process of preparing the deployment and then exporting a ZIP file. On the Prepare Deployment page, you select the type of deployment, the destination, and the assets. A unique Transfer ID is generated for the export file. After you make your selections, the system starts to prepare the file and guides you to the Export File page. Here you monitor the status of the file and export the ZIP file when it's ready.

The file status changes as the items you selected for the transfer are processed. The items inside the file have their own statuses which you can view if you expand the file. When all the selected items are ready, the file is ready to export. If there are errors for some items, you might decide to proceed with a partial export. Here are the statuses a file can have:

File status	Description
In Progress	The system is preparing the file.
Ready To Export	You can export the file. After you export the file, the Transfer ID is automatically Marked As Done.
Ready With Errors	One or more of the selected items has an Error status and is not included in the file. You can proceed to export the file, but you must prepare another deployment for the remaining items. If you proceed to export the file, enable the Mark As Done option.
Partially Exported	A file with the Ready With Errors status was exported, or a subset of items in a file was exported. The file is not yet Marked As Done.
Done	The file was exported, manually Marked As Done, or canceled during preparation.
Error	The file cannot be exported.

When the system starts preparing the ZIP file, changes that relate to the selected items occur in the exporting instance of IFS Maintenix. For example,

Aircraft and inventory records lock and baseline synchronization cannot alter the records.
Active (ACTV) tasks on assets are canceled.
Aircraft and inventory assets are archived. Their condition and location changes to ARCHIVED.
Shipment status changes to COMPLETE.

The export file is created as an Associated Signature Containers - Extended (ASiC-E) file with a ZIP format. The file includes a folder with XML files for assets, baseline, or records to be exported, and it includes a META-INF header with information, such as the sender, export date, exporting user, intended destination, list of aircraft tail numbers, and list of shipment IDs. The maximum size of the compressed file is 4 GB.

The exported file name includes a date-timestamp, the source location code, and the destination location code.

Canceling a deployment or update

If you start to prepare a deployment or update but cancel it before you click Finish, inventory records in IFS Maintenix remain unlocked and unarchived. After you click Finish, the system locks and archives the asset records in IFS Maintenix and there is no cancel option. At this point, on the Export File page, before you export, or after you do a partial export, you can enable the Mark As Done option. Inside the transfer file (in the nested list), the asset files that were not exported change status to canceled but you must manually unarchive the asset records in IFS Maintenix.

Security

When you export a file, you enter a password and the file is encrypted. Files exported using the Disconnected Operations Workflow Manager can only be imported using the Disconnected Operations Workflow Manager. To import a file, the data administrator must enter the same password that was used to export the file.

Placing exported file in accessible location

After the file is exported out of IFS Cloud, it is saved in the local system. The administrator copies the file to a file path, USB stick, or drop box where the destination location can access and import the file.

Importing a file

In an instance of IFS Cloud, a member of the deployed crew or an administrator uses the Disconnected Operations Workflow Manager to navigate to the location where the exported file is saved, upload the file, select what to import, and import the selected files. The same process is used by any FOB, MOB, or Technical Records Repository instance that is importing files.

During import, the system decrypts the file, verifies signatures, and extracts the file. The contents of the imported file are extracted with separate folders for aircraft, inventory shipments, technical records, and baseline updates. Note that when importing assets, the baseline and technical records files are hidden from view.
During import, the file categories are processed in the following order:

Baseline updates
Aircraft
Shipments of loose inventory
Technical records for selected aircraft and shipments

On the Import Files page, the file status changes as the items you selected for import are processed. Here are the statuses a file can have:

File status	Description
In Progress	The system is preparing the file.
Ready To Import	You can import the file. After you import the file, the Transfer ID is automatically Marked As Done.
Ready With Errors	One or more of the selected items has an Error status and is not included in the file. You can proceed to import the file, but you must prepare another import for the remaining items. If you proceed to import the file, enable the Mark As Done option.
Partially Imported	A file with the Ready With Errors status was imported, or a subset of items in a file was imported. The file is not yet Marked As Done.
Done	The file was imported, manually Marked As Done, or canceled during preparation.
Error	The file cannot be imported.

The data in the import file is treated as the source of truth if there are differences between the data in the imported file and the data in the system at the import location. If an asset was previously imported to a base and then exported, the system at that base has an archived inventory record. If the same asset is imported again at a later date, the import process unarchives the inventory record and updates the asset with data from the imported file.

When assets are imported successfully, the following changes occur in the destination instance of IFS Cloud:

The current baseline batch number in use at the location is updated if the import includes a higher (more recent) batch number.
Asset records are created in the system and unlocked.
If an asset previously existed in the system, it is unarchived, unlocked, and updated.
Baseline synchronization runs on the assets.
The asset location changes to the default destination. Note that the status of the inventory does not change as a result of the transfer; and importing inventory to the DOCK location does not trigger the 'Force Inspection on Receipt' logic for items that have this flag enabled.
If a completed task or fault in the imported file already exists at the import location as an open task, then the status of the task or fault at the import location changes to CANCEL (Canceled) with a Reason of REPLACED (Replaced By Import). If an imported task is complete in the import file and at the import location, it is ignored.
If an exact duplicate of a technical record already exists in the destination system, the import ignores the record because no updates are required.
If a duplicate of a technical record already exists in the destination system, but the records are not an exact match, the source record takes precedence and the destination record is updated.
If a task definition exists in the system and a later revision of the same definition is imported, the existing revision status changes to SURPSEDE and the ACTV revision is now the imported one.
Batch inventory is given a new batch number.
The configuration information for sub-assemblies is updated in Maintenix if there is a conflict with the information in the imported file. (Inventory will be detached or attached). However, if the system detects that a component installed on an imported aircraft is also installed on an active (unarchived) aircraft at the site, then the component is detached from the imported aircraft and the imported aircraft is left with a hole. This situation is not expected to occur, and requires investigation.