| DEX: (D003) task_set — Task Set | Date: 2010/03/25 17:49:46 Revision: 1.80 |
The ISO 10303-239 PLCS Application Activity Model (AAM) is an IDEF0 representation of the business activities that set the scope and information requirements for the PLCS standard. The model is composed of a set of figures and a set of definitions of these business activities and their associated information flows.
IDEFØ provides a graphical notation for function modeling of an organization or system. Activities can be described by their inputs, outputs, controls and mechanisms (ICOMs).
This DEX supports a subset of these business activities and information flows. These are highlighted in yellow in the figures Figure 1, Figure 2, Figure 3, Figure 4, Figure 5, and Figure 6.
The information flows marked with an asterisk are not explicitly represented within PLCS. This information is instead transferred by other means, e.g., handled by a document.
The activity labels in the AAM views above have the following definitions:
action to assemble the set of identified, valid tasks that are applicable to the PIF
NOTE Each task may be supported by a task description and a resource model. Each task may have a defined applicability in the context of the overall PIF. Specification of task triggers occurs in activity A2.3, in the context of a specific support solution.
action to assess the viability, risks and benefits of performing each task on different product groups or product versions, and in different locations, during different types of support opportunity
NOTE
An applicability of classification can be defined for viable tasks in relation to the options above. Non-viable tasks can be referred for task evolution, or identified as candidates for resolution by embedded support features within the product. Embedded support features include:
action to define the specific product elements to which each task applies
action to develop the applicable task specifications into the form in which they will be presented to support providers
NOTE This may include specification of the presentation format such as fonts, layout, and graphical user interface design or the adoption of specific language and editorial rules, such as simplified English, to remove ambiguity from potential end-users.
action to define the method by which a potential task shall be performed, including sequencing of steps within the task, requirements for additional or consequential tasks, warnings and cautions applicable to the task, the identification of task predecessors and successors, the task pre- and post-conditions and the support resources required to achieve the task, including necessary skills and experience
NOTE This activity can include estimating duration and level of effort of task, assessing alternative methods for performing a task, including the task risks and consequences, and an assessment of the task viability in relation to available technology, past experience, and predicted costs. Non-viable tasks can be re-worked with a different task method, or can give rise to recommendations to the product designer for a design change to remove the support driver, or for incorporation of the task into the product functionality (embedded support capability).
action to develop a support solution definition for each deployment environment, by defining the tasks that may be performed and specifying the conditions under which each task falls due
NOTE
This activity includes:
action to define the logical conditions that require a task to be done within a specific support solution definition and deployment environment, including a justification for the selection of the trigger, with appropriate reference to any analysis process that established the trigger condition
action to develop a resource consumption model for a potential task, including expected task duration and typical resource usage
action to develop a support plan option for each support concept to permit optimization of the support solution definition and raise work requests for the evolution of tasks where this is needed to optimize support
NOTE Each support plan should identify all tasks that can be required to satisfy the support solution requirements in the specified deployment environment, the logic through which tasks are combined or otherwise related, and the conditions under which each task would fall due.
action to develop and optimize the logic of a support plan by assigning tasks to product elements, setting task trigger conditions and rationalizing the grouping and sequencing of task in time and in space
action to define a task to the level needed to establish the task method and enable quantification of related resource requirements
NOTE
If the task requirement can be met by more than one method, each method should be defined as a separate task. This activity includes:
action to identify each possible task that may need to be performed on the PIF by support participants in one or more of the predicted support and operational environments
NOTE
This activity includes:
action to identify all the support resources that are needed to perform a required task and to compare required resources with resource items available, including the development of requirements for new or specialized resources that are not currently available to potential support providers
action to identify and define one or more economically viable and feasible support tasks to respond a support driver
NOTE
Activity A2.3.2 addresses individual tasks and their resources. Integration of tasks to form a support solution is performed by activity A2.3.3. Task analysis includes:
action to rationalize the set of necessary tasks and task triggers to develop a viable support plan for each product group, and support concept within a deployment environment
NOTE A further level of rationalization may be required across support plans and resource holdings across many product groups for the PIF as a whole. This activity is not made explicit in this AAM.
action to select the tasks needed to address relevant support drivers within a deployment environment
The ICOM arrow labels in the AAM views above have the following definitions:
name and identifier of a task that is applicable to a given support solution definition
collection of valid tasks that are applicable to a product in focus
NOTE Each task may be supported by a task description or task procedure, and by a task resource model. Task may be related to relevant support drivers and assigned to relevant product groups, versions, support locations, support opportunity type or class of task. The PIF task set may include tasks that are not used by any support solution definition such as commissioning tasks and tasks that are defined, but are not selected for use when the support solution definition is approved.
name, identifier and description of a possible support task
classification of a task based on its relevance to a PIF, a product group, a product version, a location or support opportunity type
NOTE Task applicability criteria may be extended or changed when the task is selected for use within a specific support solution definition.
definition of a method for performing a potential support task
NOTE The task description may include definition and quantification of the resources required to perform the task.
step-by-step instructions for undertaking a necessary activity in a form suitable for use by the support provider
NOTE The same task may be supported by several task procedures, each tailored to the needs of a class of users, with different skill levels or to alternative task methods.
identification and quantification of the resources that are needed to perform an individual task
NOTE This may include definition of required skills and experience of required support personnel.
relationship between a necessary task and the product element, or elements to which it applies
conditions that require a task to be done, in the context of its assignment to a specific product element within a support solution definition
© OASIS 2010 — All rights reserved