| DEX (D003):— task_set | Date: 2008/03/08 09:26:51 Revision: 1.59 |
Section: Business overview provided a high level overview of the business information that can be represented by this DEX. This section provides a more detailed overview of that information. A description of how to represent this information using ISO 10303-239 PLCS is provided in Section: Task specification: ISO 10303-239 Representation.
The product in scope for the task specification is called product in focus.
A product in focus may be either a part, or an element in a logical breakdown structure of a defined end item.
NOTE A part or breakdown element may be the end item itself.
EXAMPLE The end item for an aircraft engine is the aircraft. The end item for a bell is the bicycle it is fitted to.
Each part and breakdown element may have the following characteristics:
Product in focus identification
Identification of the product in focus to which the task specification applies. Identification of the product in focus includes the progression codes such as revision numbers.
NOTE At least one identification needs to be assigned to the product in focus.
The name of the product in focus.
NOTE The product in focus may have zero, one or many names.
Product in focus support classification
Classification of the product in focus from a support perspective.
EXAMPLE Examples of product in focus support classifications are: 'repairable', 'replaceable', 'line_replaceable', 'maintenance significant' etc.
NOTE The product in focus may have zero, one or many support classifications.
NOTE Details on the PLCS representation of the product in focus are defined in Section: 239 Representation - Product in Focus.
A maintenance task is a defined maintenance procedure that is to be performed on a defined product. Each task definition may include:
NOTE Details on the PLCS representation of the task definition are defined in Section: 239 Representation - Task definition.
Task identification and revisioning
A task specification is often uniquely identified within a given context, such as an organization or a product. A task specification may evolve over time, and progression codes, such as revision numbers, may be applied to distinguish the various stages of evolution.
Task assignment defines the product in focus to which the task applies.
A task specification is also often referenced by a task name. However, a task name may not be unique within a given context.
The task specification is categorized according to classifications systems applicable within a given application context.
Task type codes and task category codes are examples of task specification categorizations.
The task description is a procedural description on how the task is to be performed.
Task objective is a specification of the expected result.
Summary of reason for the existence of a task. This may include a reference to identified support drivers, and possible concequences of not executing the task.
Classification of the importance of the task in order to retain and restore the specified functionality of product in focus, i.e. the breakdown element or part on which the task is to be performed.
A task precondition is a specification of a product and/or environmental state that has to be fulfilled before starting the task under consideration.
A task precondition may result in a requirement to execute one or more pre condition tasks (see Section: Task structure).
A task post condition is a specification of a product and/or environmental state that has to be fulfilled before the task under consideration can be closed.
A task post condition may result in a requirement to execute one or more post condition tasks (see Section: Task structure).
Task legal, health and safety advisories
Warnings and/or cautions provided in order to ensure that legal, health and safety issues related to the task, are addressed.
Legal, health and safety advisories may also include references to documents.
Elapsed time is the time (duration) it takes to perform the task. Elapsed time may be defined as e.g.:
These elapsed times may be further specialized.
Labour time is the time it takes to perform the task, often measured in manhours, manminutes etc. Labour time may be defined as e.g.:
These labour times may be further specialized.
References to related documents, both:
Task special requirements indication
An overall indication for the task, that the execution of the task includes some special resource requirements.
A note / remark provides the user with information that is helpful but does not belong to the immediate subject.
A task may require a set of resources in order to execute the task. Required resources may include:
Each resource requirement may have the following characteristics:
NOTE Details on the PLCS representation of task resources are defined in Section: 239 Representation - Task resources.
Resource identification (specification)
Each resource needs to be identified.
NOTE A resource may be an identified through a specification and not only as a part number, personnel category etc, that may realize the resource requirement.
NOTE Identification of a resource is often done using some identification code.
References to documents containing e.g. descriptions or specifications for the resource.
Material resources includes spare parts, consumables, test equipments, tools etc.
Material resource realization, includes the following material resource related information:
Material resource hazardous classification
Hazardous codes may be applied to material resources such as spares, expendables and consumables.
Material resource document reference
Material resources such as spares may have document references e.g. exploded views.
Material resource support classification
Material resources such as spares, expendables, consumables, tools and support equipment may have different types of classifications from a support standpoint. E.g.:
Facilities and infrastructure resources may include e.g. power supply, intranet connections, hangars, docks etc required to perform the task.
Human resources required to perform the task. These can be defined in terms of e.g. skill levels etc.
Organizational resources can be defined as, either specific organizations or types of organizations. A specific organization can refer to a spefic CAGE code. Types of organizations includes e.g. maintenance levels, work centres etc.
Document resources referer to documents that are an integral part of the task to be performed, e.g check lists which is to be filled out and signed.
Resource assignment defines the task in which the resource is to be used or consumed.
Definition of the role of a resource in a task.
E.g. the role of a material resource may be:
E.g. the role of a human resource may be:
Quantities may be defined as value with unit, count etc.
Quantities may also have an associated determination, which defines the method by which the value has been determined. Each required resource may be quantified on the basis of e.g. estimations, calculations, measurements, experience etc.
Resource quantities may either be defined per task step, or be aggregated for the entire task.
Resource requirements may also have a defined probability, i.e. likelihood for the resource being used or consumed per task occurrence.
Any resource requirement may have an associated estimated cost.
Estimated resource elapsed time
Any resource requirement may have an associated estimated elapsed time.
Each required resource may also be classified dependent on whether its usage/consumption is mandatory or optional.
Human resource estimated labour time;
Personnel resource requirement may have an associated estimated labour time.
Alternative / substitute resource requirement
An identified required resource may have references to alternative or substitute resources.
A task trigger describes the conditions which may cause a task to be executed. These condition may be dependent upon operational environment and support solution etc.
A task trigger may be scheduled or event based.
Examples of scheduled task triggers include:
NOTE The frequency of scheduled task triggers may change over time, e.g. the first two services are executed every 500 km, thereafter every 1000 km (thresholds).
Examples of event based task triggers include:
NOTE Details on the PLCS representation of task triggers are defined in Section: 239 Representation - Task triggers.
Determines dependencies between the task, the product in focus and the end item. The end item is the platform on which the product in focus is fitted (unless the product in focus is itself the end item).
EXAMPLE The end item for an aircraft engine is the aircraft. The end item for a bell is the bicycle it is fitted to.
NOTE A full definition of the position of the product in focus within the breakdown of end item is not within scope for this DEX. See Product Breakdown For Support..
Task end item context information includes:
NOTE Details on the PLCS representation of task end item context are defined in Section: 239 Representation - Task end item context.
On/off end item classification
On/off end item classification may be done in different ways depending on customer requirements.
One example of on/off end item classification, is to determine whether the task requires that the product in focus has to be removed from its end item:
EXAMPLE
Another example of on/off classification, is to determine how the task affects the availability of the end item:
EXAMPLE
Zone where the task is performed.
List of access points to be removed/opened to perform the task.
Reference to defined removal route(s) may be defined for breakdown elements.
A task specification may be subdivided into task steps. Any task step may refer to another task specification that describes the task step to be performed.
There may also be relationships between the task steps such as sequencing (task step flow).
NOTE Details on the PLCS representation of task structure are defined in Section: 239 Representation - Task structure.
Each task step in a task structure may be categorized. An example of categorization of task steps in a task structure is precondition-, core-, and post condition task steps. Each of those task steps may in turn refer to other task specifications. This is illustrated in Figure 14 below.
A precondition task step may be defined as a task that has to completed prior to the commencement of the core task step. A precondition task step may describe how to remove the part from its physical location. Pre condition task steps may either be described within the task specification under consideration, or be referenced as another task specification describing the precondition task step.
Core task steps are the tasks which serves as "event solvers". Events includes both failures and damages as well as scheduled maintenance activities.
A post condition task step is a task that has to be executed after the finalization of the core task step. Post condition task steps may either be described within the task specification under consideration, or be referenced as another task specification describing the post condition task step.
Each task step may be characterized using the task constructs described above, in terms of:
The validity of a task, or part thereof, may be constrained to a specific context. These constraints are referred to as effectivity or applicability.
Effectivity (applicability) of a task, or part thereof, may be constrained to the product in general, and can be defined in terms of:
Effectivity (applicability) of a task, or part thereof, may also be constrained for a specific customer, and can be defined in terms of:
Effectivity (applicability) may be applied to:
NOTE Details on the PLCS representation of task effectivity are defined in Section: 239 Representation - Task effectivity / applicability.
Task specification administrative information includes:
NOTE Details on the PLCS representation of task administrative information are defined in Section: 239 Representation - Task administrative information.
Task message information includes:
NOTE Details on the PLCS representation of task message are defined in Section: 239 Representation - Task messageadministrative information.
© OASIS 2008 — All rights reserved