|DEX (D003):— task_set||Date: 2008/03/11 17:07:00
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 detailed information requirements given in this section is summarized into the UML Class Model in Figure 8. This overview is the overall UML Class Model for task information, into which each detailed requirement below is fitted.
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:
NOTE Details on the PLCS representation of the product in focus are defined in Section: 239 Representation - Product in Focus.
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.
Product in focus name
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.
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 consequences 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).
Task post condition
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.
Task elapsed time
Elapsed time is the time (duration) it takes to perform the task.
Task labour time
Labour time is the amount of work that is planned to be consumed performing the task. Labour time is often measured in manhours, manminutes etc.
Task document references
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, e.g. special tools required.
Task note / remark
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.
Resource description (specification)
A description or specification of the resource.
Resource document reference
References to documents containing e.g. descriptions or specifications of importance 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 identification
Identification of the part that can realize a material resource requirement. 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 part.
Material resource name
The name of the part that can realize a material resource requirement.
NOTE A part may have zero, one or many names.
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
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.
Human resource realization, includes the following human resource related information:
Human resource name
The name of the type of person that can realize a human resource requirement.
NOTE Names of types of persons that can realize a human resource requirement are often defined in terms of skill levels.
Organizational resources can be defined as, either specific organizations or types of organizations. A specific organization can refer to a specific CAGE code. Types of organizations includes e.g. maintenance levels, work centre's etc.
Organizational resource realization, includes the following organization resource related information:
Identification of a specific organization that can realize an organizational resource requirement.
The name of the type of organization, or specific organization, that can realize an organizational resource requirement.
NOTE Names of types of organizations that can realize an organizational resource requirement are often defined in terms of line of maintenance, or work centre.
Document resources refers 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.
Document resource realization, includes the following document resource related information:
Identification of a specific document that can realize a document resource requirement.
The name of the document that can realize a document resource requirement.
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:
Quantity of the resource required for the task.
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 requirements may also have a defined probability, i.e. likelihood for the resource being used or consumed per task occurrence.
Estimated resource cost
Any resource requirement may have an associated estimated cost.
Estimated resource elapsed time
Any resource requirement may have an associated estimated elapsed time.
Resource usage indicator
Each required resource may also be classified dependent on whether its usage/consumption is mandatory or optional.
Human resource estimated labour time;
Human and organizational resource requirements 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.
NOTE Details on the PLCS representation of task triggers are defined in Section: 239 Representation - Task triggers.
Scheduled task trigger
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).
Event based task triggers
Examples of event based task triggers include:
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 DEX (D001):— Product Breakdown for Support.
Task end item context information includes:
Zone, access and removal route can be assigned to usage of a breakdown element within an end item, or to the usage of a task if the task is to be performed at another location than the installation location for the breakdown element.
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:
Another example of on/off classification, is to determine how the task affects the availability of the end item:
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 a set of task steps.
Task structure information add the following information to the model:
NOTE Details on the PLCS representation of task structure are defined in Section: 239 Representation - Task structure.
Task step identification
A task step identification uniquely identifies the task step within a task.
Task step categorization
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 15 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.
Task step reference
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).
Aggregated task resources
Resource requirements, including its quantities, may be aggregated for the entire task.
Aggregated task elapsed time
Aggregated task elapsed time is the time (duration) it takes to perform the entire task, i.e. the time it takes to perform all the task steps. Aggregated task elapsed time may be defined as e.g.:
These aggregated task elapsed times may be further specialized.
Aggregated task labour time
Aggregated task labour time is the amount of work that is planned to be consumed performing the entire task, i.e. the amount of work that is planned to be consumed performing all the task steps. Labour time is often measured in man hours, man minutes etc. Aggregated task labour time may be defined as e.g.:
These aggregated task labour times may be further specialized.
Task step characterization
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:
Figure 16 gives an overview of the above mentioned classes, attributes and associations that might have a restricted effectivity/applicability. The blue arrows points at possible targets for an effectivity/applicability statement. Things that might control the effectivity/applicability are enumerated in the blue text above the UML diagram.
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.
A previous version of the task specification is being replaced by the new version.
Task revision change description
A summarized description of the differences between the new version of the task specification and the version that being replaced.
The status of the task being exchanged.
EXAMPLE Examples of task statuses are; 'Initial draft', 'Reviewed' and 'Approved'.
Task message information includes:
NOTE Details on the PLCS representation of task message are defined in Section: 239 Representation - Task message information.
Message sending organization
The organization sending the message.
Message receiving organization
The organization receiving the message.
Message date time extraction
The date and time when the data in the message was extracted from the sending system.
The contract in support of which the message is being sent.
© OASIS 2008 — All rights reserved