| Business DEX (NOLITO003):— Gripen_task_spec | Date: 2008/12/08 19:49:15 Revision: 1.13 |
This section provides a high level overview of the business information that can be represented by this Business DEX. A more detailed overview of the information is described in Gripen_task_spec Business Information Requirements , and a detailed definition of how the information is represented using ISO 10303-239 PLCS is provided inGripen_task_spec ISO 10303-239 Representation.
The information constituting the Gripen Task Specification that can be exchanged using this Business DEX is summarized in Figure 3 below.
The product in focus for the maintanance action is in ILS-DB identified through the Maintenance Object. Therefore, the exchange file must contain both the Maintenance Object (from ILS-DB) and the corresponding product in focus (from Teamcenter™), i.e. a Configuration Item or an Equipment, which is covered by DEX NOLITO001 Product Breakdown Structure for Support.
There is however no relationship implemented in the systems between the Maintenance object in ILS-DB and the configuration item or equipment in Teamcenter™, although that mapping exists implicitly in the naming of Maintenance objects etc. For the NOLITO project, a mapping table has been developed for the test data, and a similar approach would have to be used for production purposes as well.
The product in focus should be identified either by a Configuration Item Node valid in a certain Product Variant and Product Configuration Baseline, or as a Part (an equipment or sub-equipment). If no direct product in focus has been defined in Teamcenter™, the Maintenance Object should be related to the nearest higher Configuration Item Node or Equipment.
Each Maintenance Object have one or more Maintenance Actions assigned. Each Maintenance Action is defined through its content (steps) and it may have revisions. It should be classifed as either corrective or preventive maintenance action. Any environmental risks, such as risk for explosion, should be highlighted early in the action description.
A Saab Maintenance Action have a number of sequential Subtasks, each describing a certain step in the action procedure. Each Subtask may have a Carry Out Time (i.e. estimated duration), and Resources (described in more detail in Task resources). The Subtasks are of different types:
Both the Maintenance Action and its Subtasks may identify documents (publications) that should be used or referred to when executing the action (e.g. drawings, or standard procedures).
A Maintenance Action requires resources in order to be performed. Those required resources are here called Task Resources, and are of different types.
The lowest Maintenance Level at which a Maintenance Action can be performed is one such resource, related to the entire Maintenance Action.
The facilities required to carry out the maintenance action, or at least a specification of the facilities, is also a resource. There are some facility specification documents at SAAB, but sometimes the required facilities are only given by a name, e.g. "tire workshop" (which strictly speaking is not specifying the facility enough, but that's what is available).
Spare Parts are also a type of resource that must be referenced from the maintenance action. Almost all spare parts at Saab are identical to the parts used in the design assemblies. Some Parts, when they become spare parts, do have a specific time for when the maintenance clock starts ticking:
Requirements for consumables, expendables and tools (ground support equipment) should also be handled as required resources, similar to spare parts. For these material resources, it should be possible to express the quantity of the resource, e.g. "0.5 litres of oil", specific to each maintenance task. Each material resource has a Saab identifier and name, and its use in a maintenance action is classified as either "spare part", "consumable", or "support equipment".
It must also be possible to assign an additional identification and name to a material resource, i.e. the NATO stock number and name. This identifier is however applicable to the Resource itself, not to the Part .
A Task Trigger is what makes a maintenance action valid to perform on the end item. It can be a scheduled trigger type, for example calendar time (six months), operational usage (flight hours), operational cycles (starts or landings), etc. It may also be an even-based trigger, e.g. a fault condition that occurs. Sometimes, the trigger is expressed in a text string only.
Maintenance actions are performed on equipment and configuration items both when they are installed and when they are in storage. Therefore, there are up to four different values for task triggers given:
Teh task end item context is a classification of the maintenance action, identifying wether it is performed on aircraft (and therefore is stopping normal operation of the end item) or off aircraft (after the equipment has been removed from the aircraft).
The Task administrative information is really the Configuration Edition in ILS-DB, which defines a baseline in ILS-DB along with a set of Maintenance Objects. It is similar in nature to the Configuration Item Baseline in TC, although they are not the same. The Configuration Edition establishes a baseline of Maintenance Objects against a specific Configuration Item Baseline in TC at a point in time.
Each data exchange file contains one task message. A Task Message is the envelope around the maintenance tasks and maintenance objects that are being exchanged. The message is identified with date and time of data extraction, identification of sending and receiving organizations, and a contract identifier. Furthermore, the message references all maintenance actions in the message, thereby providing a handle for navigation.
© Saab AB 2010 — All rights reserved