analysis of operator and support feedback to validate and verify the support solution
against its requirements, to report support solution performance against agreed metrics,
and to raise issues or suggest improvements to the assessment strategy, the support
solution, or the product
Activity A1123: Analyze change problem or opportunity
analysis of a documented configuration management issue to determine whether there
is a need for change action; a request for clarification or resolution by other means
NOTE
While this activity can be very simple and intuitive, often there is a
requirement for careful weighing of alternatives and cost benefit
trade-offs. The preliminary judgments concern:
- the reason for the requested change;
- the basic scope and description of the requested change;
- definition of the impact of the requested change;
- the desired effectivity;
- the urgency and importance of the requested change.
Activity A32: Analyze commissioning data
analysis of data collected from the implementation of commissioning tasks to report
progress against the commissioning schedule and objectives or a need for proposal
for change to the product, the support solution, or the commissioning schedule
Activity A2121: Analyze external environmental factor
analysis of the political, legal, international, economic, social, cultural, and technological
factors in the external environment that offer opportunities and pose risks to the
successful provision of support
Activity A2312: Analyze previous experience
collection and analysis of information from other products, or from past experience
with the current support solution, to identify support related needs that should be
addressed during the design and support of the product
NOTE
This activity considers:
- support issues needing attention, and why;
- cost drivers and information relating to development, production, deployment, use,
support, and disposal of the product;
- factors affecting the ability of the product to perform its intended mission in the
intended use and support scenarios;
- risks and assumptions associated with the information from other products, or from
previous use, such as relevance and accuracy for comparison with the product;
- information on what has worked well and what not during previous use or during support
of similar products in similar environments and scenarios;
- requests for clarification of conflicting or ill-defined stakeholder requirements;
- additional requirements identified by the support engineer stakeholder and that perhaps
have not been formally specified by any other stakeholder, including legal and social
obligations that are not otherwise defined;
- guidance on how to explore technological opportunities, identify the metrics for support,
identify trade-off criteria, and provide information for trade-off analyses.
analysis of support feedback from individual tasks to determine exceptions from the
support solution, exceptional maintenance needs, the impact on operations, and suggestions
for improvement
Activity A42: Arrange support element provision
action to arrange provision of required resources, in the required quantity and state,
at the specified location, on the specified date as required by a resource schedule
NOTE
This activity assumes the availability of a standard transaction set that can be used
to achieve provision of the necessary human and material resources required by scheduled
tasks. The transaction set is assumed to include sufficient requests and responses
to complete the planning (activity A4.1) and execution (activity A4.3) of support
activities.
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.
Activity A2434: Assemble support solution
action to collect and assemble the information needed to define the support to be
provided to a group of products within a deployment environment
NOTE
The support solution includes:
- task procedure for all necessary tasks;
- the support plan;
- task triggers for all necessary tasks;
- predictions of the support system performance, under one or more operating schedules,
including predictions of resource usage.
action to monitor approved changes through a planned and scheduled implementation
in all documents, facilities, hardware, and software affected
NOTE
The implementation is carried out in accordance with the activity A1.1.3.2. Change
accomplishment in all impacted areas is monitored and verified to track progress and
to maintain consistency between each member of the PIF and its applicable configuration
and support information, in the form of APSI.
Activity A4424: Assess impact on operation
action to assess the potential impact on operations of the state of a product after
completion of a task including provision of advice or instructions to operators concerning
any limitations of use that apply
NOTE
This activity can include:
- information on additional maintenance requirements and the timing of future support
tasks;
- limitations on product performance, such as speed and altitude, or cautions on environmental
conditions to be avoided;
- information of relevance to system operators on the readiness of the support system
and availability of support elements and services;
- information on limitations on availability including possible impact on operational
plans arising from the product condition.
Activity A11314: Assess impact on related changes
action to identify and define the impact of a change on other related changes and
to define constraints on the order of change implementation
NOTE
This activity can initiate further assessment of this and related changes to establish
the full impact of a particular solution.
action to assess each issue for relevance, requesting and responding to required impact
assessments and classifying the issue according to the intended response.
NOTE
Possible classifications include:
- requiring change action;
- rejected;
- variance that needs to be recorded in the APSI;
- update to the information set and requires no further action.
action to assess the risks associated with a quantified solution to a valid need for
change
action to assess the performance of the support solution definition in relation to
the metrics specified by the support solution requirement
NOTE
This activity includes:
- identification of the information to be collected;
- specification of the means of collection;
- definition of the assessment strategy;
- analysis of the feedback obtained from support activity;
- identification of the need for corrective action.
Activity A24224: Assess task viability and applicability
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:
- static design features of the product provided for support reasons such as lifting
points or access panels;
- human factors improvements such as labelling or re-positioning of gauges and support
related functionality within the product such as condition monitoring or built-in-test
equipment (BITE).
Activity A243231: Assign task to product elements
action to define the specific product elements to which each task applies
authorisation, rejection or deferment of a recommended change based on the associated
justification
NOTE
If the change is authorized a change order will be issued for implementation. If the
change is rejected a further review can be initiated.
action to review commissioning feedback to confirm completion of all necessary tasks
and resolution of significant issues and to certify the support system as ready for
use
NOTE
This process should provide assurance that appropriate capability is in place to provide
required support.
Activity : Classify element or interface
action to classify elements to provide a convenient reference in the business context
NOTE
The classification method will also assist in defining information needs. Classification
of elements can include:
- the selection of configuration items and configuration item interfaces;
- differentiation by size or complexity, using distinctions such as, major unit, minor
unit, assembly, and raw material;
- differentiation in respect of types of information to be held, including those items
that require load testing.
action to classify the chosen solution with respect to appropriate parameters
NOTE
Change solutions can be classified in many ways, including:
- nature of change, such as safety critical;
- scale of change, such as major or minor;
- implementation impact, such as an in-service change;
- regulatory interest, such as FAA approval required.
action to collect and capture into the information technology infrastructure the data
generated by support activities or by use of the product
NOTE
Feedback includes:
- support task records, including product data collected by the task;
- product state and usage records;
- resource element state and usage records;
- product configuration information;
- any issues arising from work.
action to establish, test, certify and release all elements of the support system
required to provide the support defined by a support solution
NOTE
To avoid duplication of activities, the activity A3 is limited to planning and assessing
commissioning activities. The specification and execution of commissioning tasks is
performed in activities A2 and A4 respectively, as part of the activities that also
provide support.
Activity A11335: Compare solution options
action to select the solution that best meets the valid need for change
Activity A11334: Compile justification for solution
action to review the total change package and complete a justification for the implementation
requirements with a recommended classification and priority
Activity A2433: Complete task procedures
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 check and confirm that a released support task has been completed in accordance
with the task specification and the approved support schedule
activity to control work in progress to achieve efficient attainment of support opportunity
objectives in accordance with a support schedule including: releasing tasks on which
work may begin; monitoring task progress; certification of successfully completed
tasks and release of the product for use when all actions are complete
NOTE
This activity implements and manages achievement of a support schedule. The activity
controls the physical performance of the actions required to service, repair, test,
overhaul, modify, calibrate or inspect a product needing support as specified by the
task specification within the support solution definition or commissioning schedule.
This activity includes:
- releasing the support tasks for performance of work;
- monitoring progress;
- accepting support task completion;
- providing appropriate feedback data for record and planning purposes.
Activity A1341: Create information release plan
action to develop a schedule for the release of APSI in response to change orders
and implementation plans
NOTE
This activity ensures that assured product and support information is provided to
approved recipients in a timely manner consistent with the approval and implementation
of a change. Consideration should be given to:
- the scope and timing of the change;
- dependencies on other products;
- restrictions on the usage of the information;
- the user requirement for access.
Activity A4422: Create suggestion for improvement
action to collate ideas and comments generated by support personnel into clear proposals
for improving the support solution
action to provide a boundary definition of the set of products for which support is
required, including an indication of the level product decomposition at which support
is expected
NOTE
The PIF is the set of operational products, usually sharing a common product design,
for which support is required. This set of products may be further subdivided across
several deployment environments, each requiring a tailored support solution based
on a common set of task specifications.
action to identify and describe, for each product group and usage profile, the intended
resource items expected, or required to be available at each location where support
could be provided
NOTE
Resources items may include organizations, people, facilities, parts, tools or test
equipment. Resource items may be types or individuals.
Activity A311: Define commissioning objectives
action to define the objectives of the commissioning activity including any metrics
for commissioning tasks
NOTE
May include action to raise requests to the life cycle owner for action required beyond
the scope of activity A3 to resolve commissioning problems or issues.
Activity A312: Define commissioning tasks
action to identify the tasks required to commission the required support system
NOTE
These may include tasks previously defined by the support solution, and additional
tasks required only for commissioning purposes. The development of task description
for a commissioning task may be initiated by a commissioning task request.
Activity : Define deployment environment
dummy activity to collect the various inputs into a single output arrow, named deployment
environment, to simplify arrow flows at higher levels of this model
Activity A2232: Define environment at each location
action to define the environment at each potential support location in so far as this
may impact the support solution design
NOTE
The environment can be defined by terms including:
- covered dock facility;
- arctic conditions;
- a clean room to a given specification.
action to establish necessary information management rules to achieve unambiguous
information sharing and exchange capability in a digital environment including definition
of the meaning, structure and organization of data required by the extended enterprise
engaged in product support
NOTE
This activity covers the production of an information model that defines how the product
data will be held. The architecture may prescribe a set of tools or specify an open
data architecture. The activity generates the associations and relationships between
data and documents and a definition of how that information is represented in different
views. This may involve the specification of relevant parts of ISO 10303 or other
standards, such as EIA 836.
Activity A1323: Define information management procedure
action to produce guidelines and constraints pertaining to the creation, use, maintenance
and disposal of information by life cycle users
NOTE
This activity defines applicable methods and creates a structured set of information
management rules.
Activity : Define information required for element or interface
action to define what APSI shall be developed and maintained for each item in question,
to enable the support solution definition to be implemented and maintained throughout
the life of the PIF
NOTE
A configuration item can have a large quantity of associated information. Such information
can include:
- design data;
- configuration item interfaces;
- specifications;
- interface control documentation;
- records of support analyses such as reliability centred maintenance analysis, or level
of repair analysis;
- the support solution definition;
- technical publications;
- test results and certification;
- quality assurance documentation.
Activity : Define interface between elements
action to identify any interfaces between elements that will be subject to configuration
management
NOTE
The nature of interfaces depends on the nature of the elements themselves. The interface
description may include the physical and functional attributes of the connection,
spatial relationships, parent-child relationships and other forms of reference, such
as the links to product, support and configuration data. This activity provides the
foundation on which to generate the checklist that is used when changes to elements
are proposed and ensures all consequences of a proposed change are considered. The
descriptions of interface elements also provide a starting point for the development
of product structures.
Activity A2221: Define life and usage parameters
action to define the properties or characteristics to be used to quantify product
life and usage
action to define the intended life and usage pattern for a product group including:
overall product life; operating environments and usage scenarios of relevance to support;
applicable usage parameters and expected types and durations of support opportunities
NOTE
This activity can identify:
- ranges of frequency and duration for the intended operational scenarios or missions;
- critical frequencies (how often), duration (time and distance) and permitted time
for preparation for and conduct of the different states of the scenarios;
- how many times (ranges, minimum and maximum weighted) a state occurs in a scenario;
- relative importance (criticality) that product functions are available at the start
of and throughout the individual scenarios and states;
- required functional uptime during a state or scenario, and permitted functional downtime.
Activity A1222: Define link between product structures
action to establish necessary links between different product breakdown views, reflecting
relationships of interest
NOTE
Potential relationships include:
- connectivity relationships between parts that can be supported by interfaces;
- parts used to realize a function;
- parts located in a zone.
Activity A252: Define needed information
action to define the information that must be collected to support the assessment
process
Activity A211: Define objectives of support engineering programme
action to define the objectives to be applied to the support engineering programme
including identification of desired characteristics of interest with metrics and targets
Activity A2222: Define operating environments
action to identify and describe any operating environments likely to impact the requirement
for support or the options for support delivery
action to determine the potential faults or other degraded states that the support
solution shall address, including cause, effect and other relationships between them,
as applicable to each product function requiring support, part, and attachment slot
NOTE
The ARM of this part of ISO 10303 defines the concept of predicted states of a product
and this concept is appropriate for representation of faults. A product can be either
a part of a function. The sequences of individual faults involved in a failure can
be represented by the relationship between predicted states.
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 define any sub-groups of products, within a PIF, that may need a separate
support solution
NOTE
Separate support solutions may be needed for different variants of a product, operated
by a single customer or for sets of identical products operated by different customers.
action to develop the required views of each relevant product, in the form of assembly
structures or breakdowns built from classified elements and to establish necessary
relationships between the different views to provide navigation between views
NOTE
The managed set of product views (the PIF structure) provides unambiguous identification
of the PIF for support management purposes and a key mechanism for navigating and
managing the effectivity of all related information, including that specified by the
information need providing the product definition and support solution.
Activity A2233: Define support capability at each location
action to define and describe the resources and capabilities available to support
the product group at each identified location where support activity may occur
NOTE
This activity can including defining the organization of potential support providers
and their capability in terms on the type of tasks they can undertake, the quantity
and description of resources types available, and the planned or actual availability
of individual resources. This activity is used initially to record the assumptions
made to facilitate support analysis. As the analysis proceeds the assumptions are
updated to reflect intentions to record the planned and actual capabilities and resources
available at each location. Resources include infrastructure, facilities, personnel,
spares, tools, test equipment, ground support equipment and any other category of
resource required for product support.
Activity A2322: Define support characteristics
action to define the characteristics that will be used to quantify support objectives
and agreed support needs, and the metrics to be used for assessing the support solution
performance
action to define a context, or deployment environment, for each required support solution
per sub-group of product within the PIF that need tailored support
NOTE
The context definition consists of the product group, its intended life and usage
profile, potential support opportunities, support providers, and available resource
items. This definition will evolve through time, from an initial listing of assumptions
into a complete description of the support providers and available resources.
action to identify potential support solution performance metrics that could be used
to assess achievement of support objectives including, for each metric, the target
and threshold values that shall apply
NOTE
The metrics may be used as criteria for trade-off analyses, to predict support solution
performance or to measure actual performance of a support solution in use.
action to define the approach to be taken when designing the support solution for
a set of products within a support context, including any requirement to develop and
compare alternative support solution options
NOTE
The support policy includes:
- contractual arrangements for support such as organic support, contractor logistic
support, contract for availability;
- the maintenance philosophy to be applied such as reliability centred maintenance or
calendar based maintenance;
- the stock holding policy to be applied such as just in time supply or managed inventory;
- training philosophy to be used such as on-the-job training.
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:
- selection of required tasks;
- consolidation of tasks into logical packages of work;
- harmonization of tasks and task conditions to optimize the solution;
- identification of the precise relationship of tasks and task triggers to the state
of the individual product needing support;
- identification of optional tasks to suit differing usage scenarios or support environments
within a deployment environment.
Activity A2324: Define support solution requirement
action to consolidate the agreed support needs to establish unambiguous and quantified
requirements that shall be applied to the design of a support solution
NOTE
The requirement may include a statement of the required support performance, expressed
in terms of defined support characteristics with metrics to be used when assessing
compliance.
action to establish an unambiguous statement of the requirements to be addressed by
a specific support solution by de-conflicting any contradictory, ambiguous, inconsistent,
incongruous or unverifiable requirements from the complete set of elicited needs and
to define the metrics by which support performance will be judged
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 support solution definition to meet requirements for each recognized
deployment environment
NOTE
This activity can include:
- identification of reasons why support tasks may be needed;
- the development of a common set of task procedures applicable to the PIF;
- the optimization of a support solution for each recognized deployment environment;
- exploration of alternative support concepts and solution options within a support
solution;
- specification of the conditions under which any task falls due (task triggers);
- optimisation of the tasks, task triggers and task groupings within each support solution.
action to compare results obtained from actual tasks with those expected from the
task procedure to identify discrepancies and anomalies for feedback and to compare
results from observations of the product condition with expected values to identify
any product integrity exceptions
NOTE
The absence of an adequate response to the task or product discrepancies may prevent
release of the product to service.
Activity A4423: Determine maintenance need
action to identify any additional maintenance needs, not addressed by the current
support schedule, for consideration during this, or future support opportunities
NOTE
Maintenance needs may arise from work deferred or delayed by local circumstances or
from observations on the product condition.
Activity A251: Develop assessment strategy
action to define the approach to be taken, and activities required, to validate the
support solution against its requirements over the product life cycle, using the specified
performance metrics
action to refine the preliminary assessment to determine all potential consequences
of a possible change including necessary coordination between the impacted items to
enable effectivity to be determined
NOTE
The preliminary assessment occurs in activity A1.1.2. The level of analysis required
will depend on the nature of the change taking into account effects on support engineering
and resource management and impacts on other approved changes.
action to identify and schedule the tasks needed to commission a support system that
can deliver a support solution
NOTE
Commissioning tasks are performed in activity A4. These task include:
- planning and controlling the execution of commissioning tasks;
- arranging provision of all necessary resources (materials, labour, support equipment,
facilities, documentation) at required locations;
- certifying the support solution as ready for use.
Activity A2223: Develop expected scenarios and usage pattern
action to identify and describe any operating scenarios or patterns of use that shall
be taken into account when generating a support solution definition
Activity A12213: Develop functional breakdown
action to develop a functional breakdown that is for the PIF scope and can act as
a collector for product and support requirements and for other information relating
to functional aspects of the PIF
NOTE
Every element within a functional breakdown is a function. Design engineers can derive
a functional breakdown from the systems breakdown and use it for managing related
functional requirements and as an input to fault, hazard or failure analyses. Support
engineers can use the same functional breakdown, or a modification of it, to identify
functions that require support and to structure information on potential faults and
symptoms.
Activity : Develop hybrid or other breakdown
action to develop a breakdown that is either a hybrid breakdown or not a a system,
physical, functional or zonal breakdown, is for the PIF scope and can act as a collector
for product and support requirements
NOTE
Elements within a hybrid breakdown can be of any type. This capability enables the
modelling of miscellaneous breakdowns, which mix physical, functional, zonal and other
elements to create views for specific purposes. Such breakdowns are used extensively
in current logistic systems and standards. In general, hybrid breakdowns should be
remodelled as a set of related set of breakdowns with consistent element types in
order to ensure greater clarity as to the foundation and purpose of each breakdown.
Activity A131: Develop information management plan
action to generate a plan for the information management activities required to achieve
and sustain a coherent information environment, reflecting the information management
strategy and requirements
NOTE
Activities within the plan include specification of required information deliverables,
development of the information management rules, development of information exchange
agreements between participating organizations, development and testing of information
exchange capability, tasks to reformat information to comply with the rules. The information
strategy requirements usually originate in customer or contractor policies and standards
(covering information technology, business-to-business trading, configuration management,
quality assurance). The contractual requirements usually originate in the change management
plan or a change order.
Activity A1321: Develop information model
action to produce or select a conceptual information model to define the entities,
attributes and relationships of interest to product life cycle support, and define
the format in which required information shall be captured so that relevant information
can managed over time
NOTE
This part of ISO 10303 can be used for this purpose.
action to develop a physical breakdown that is for the PIF scope and can act as a
collector for product and support requirements and for other information relating
to physical aspects of the PIF
NOTE
Every element within a physical breakdown is a physical part or assembly. A complex
product may require many different physical breakdown views to serve different communities
of interest. Support engineers typically develop a physical breakdown of Logistically
Significant Items derived from, and related to, the product assembly structure. This
LSI breakdown differs from the product assembly structure in several important respects:
- it may reflect a different level of detail (sometimes less, sometimes more);
- it may need to expose repeated occurrences of parts, where these have different usage
or support requirements, such as a main, and standby pump;
- it may identify slots. This LSI breakdown is often used to structure and record the
analysis of support tasks.
Activity A24223: Develop resource model for task
action to develop a resource consumption model for a potential task, including expected
task duration and typical resource usage
action to establish the necessary breakdown views of the PIF by defining parent-child
relationships between related elements
NOTE
This part of ISO 10303 provides a generic mechanism for representing product assemblies
or product breakdowns from any required perspective. A product assembly structure
is usually developed by the engineering design process. This is used to define the
parts and versions that make up the product and to develop a bill of material for
product manufacture. Life cycle support activities will usually require the establishment
of other product breakdown views. These views can include a decomposition of product
functions from the operator or maintainer perspective and, in some cases, a zonal
description of the product to assist maintenance planning. Each breakdown will contain
similar classified elements, linked together in a hierarchical fashion.
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 develop a schedule for the work to be accomplished to meet the objectives
of the support opportunity by identifying required activities, developing activity
logic and defining the required timing of activities to reflect the task resource
models, the availability of required resources and the support opportunity objectives
Activity A12211: Develop system breakdown
action to develop a system breakdown that is for the PIF scope and can act as a collector
for product and support requirements
NOTE
Requirements may be allocated to any assembly or breakdown type. Elements in a system
breakdown can be:
- physical or functional in nature, or have aspects of both;
- satisfied by different a number of different products.
Activity A24221: Develop task description
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:
- identification of the support driver that justifies the task;
- definition of the conditions under which the task may be safely performed, including
any pre-task and post-task conditions;
- development and description of the method by which the task shall be performed including
the sequence of steps within the task;
- the development of additional tasks if the same objective is to be realized using
different methods;
- identification of related tasks that need to precede and succeed this task. This activity
can also reveal the need for additional tasks, causing the generation of a request
for task procedure.
action to develop a zonal breakdown that is for the PIF scope and can act as a collector
for product and support requirements and for other information relating to zonal aspects
of the PIF
NOTE
Every element within a zonal breakdown is a zone. A zonal breakdown is used to identify
areas or volumes of interest to which reference is made. Examples include rooms in
a building, compartments in ship and the modules from which an oil platform is constructed.
Support engineers can use a zonal breakdown to define the location of products requiring
support or to identify zones where access is difficult or special precautions apply.
Activity A1122: Document change opportunity or problem
action to document a problem requiring configuration change action, or to resolve
the problem by an information update
NOTE
This activity results in a valid need for change, enabling the change
to be effectively processed and helping to ensure that the associated
configuration documentation provides a comprehensive historical record of
the full life cycle of the change. To adequately evaluate a request for
change, the request must be clearly documented. It is important to
accurately describe even minor changes so that an audit trail can be
constructed in the event that there are unanticipated consequences or
unexpected product failures. Saving the cost of research involved in one
such incident by having accurate accessible records may be sufficient to
fully offset diligent, disciplined change processing. Changes can be
required as a result of problems reported during design, build, test,
operations and service activities. Changes can be initiated for a variety
of reasons including:
- to provide new capabilities desired by a customer;
- to enhance product support;
- to insert new technology;
- to effect product improvement;
- to cater for obsolescence;
- to correct product faults or deficiencies;
- to correct problems and prevent recurrence;
- to eliminate safety hazard conditions;
- to implement pre-planned product improvement;
- to reduce production cost or improve production efficiency;
- to prevent schedule slippage;
- to cover obsolescence.
action to capture the needs, wants, desires, expectations and constraints that each
recognized stakeholder wishes to apply to the support solution definition, including
action to seek clarification and justification as needed; review experience with similar
product or support systems for potential additional requirements and identify requirements
for standardization of the product or support elements
NOTE
Wherever possible stakeholder needs shall be expressed in a form that permits the
operational performance to be measured and assessed for conformance. Stakeholder needs
may include the needs and constraints imposed by society, the constraints imposed
by acquiring organization and the capabilities and limiting characteristics of operating
staff. Expressions of need should be analyzed to identify and remove inappropriate
constraints on support system solution options.
action to establish the business case for change, select a preferred solution and
authorize the change by approval of appropriate change orders to enable the change
to be implemented and verified
NOTE
Change approval should be conducted in accordance with the
configuration management plan. Approval authority for a change can be
delegated to different levels in the organization, depending upon the
classification of the change. As the life cycle progresses, the change
authority often transitions to individuals with greater management and
fiscal responsibility because the effect of a change can be more widespread
and, as a result, the cost impact of change decisions are normally
greater. Each contract should establish a specific change authority
structure taking some of the following factors into consideration:
- the organizational structure and relationships within the enterprise;
- the various levels at which change authority is vested;
- the phase of the product life cycle;
- the extent of technical, support, schedule and cost impacts;
- the customer involvement;
- the product attributes subject to formal control;
- the period of performance during which that level of control applies.
Activity A314: Establish commissioning programme logic
action to establish an optimal sequence for commissioning activities to take account
of constraints, relationships and interfaces of and between tasks such as those due
to temporal, spatial, or sequential dependencies, or imposed by safety or other policies
NOTE
This establishes constraints and relationships on and between tasks. These may be
due temporal, spatial, or sequential dependencies, or imposed by safety or other policies.
Activity A11332: Establish cost of solution
action to evaluate the cost of a change by subjecting the most beneficial solution
to a commercial pricing exercise, creating a price that meets the implementation and
effectivity requirements
Activity A253: Establish information collection mechanisms
action to identify the means by which information needed to assess performance will
be collected including the definition of additional tasks, or embedded support capabilities,
required to generate or collect assessment data that will not otherwise be generated
by operation of a support solution definition
NOTE
Additional assessment tasks may be needed during product and support solution development
such as conducting a maintenance assessment of a new equipment, or during normal operations
such as a requirement to measure hours run, or to conduct an annual review of some
aspect of performance.
action to document and assess the problem or change opportunity
NOTE
This activity covers documentation of the change opportunity or problem and the creation
of a suitable description, analysis of the opportunity or problem, and the reason
for a possible change along with a statement of expected impact sufficient for evaluation,
determination of the appropriate level of priority, and the raising and the approval
of a valid need for change as an input to evaluating and co-ordinating a solution
or variance.
action to collect and consolidate all potential requirements and valid stakeholder
needs, to establish an approved set of requirements for each support solution definition
and to define the scope and characteristics of the deployment environment to which
the solution applies
NOTE
This activity includes:
- definition of the characteristics to be used set goals and metrics for support delivery
and assess support performance;
- identification of explicit and implicit needs for performance of through life support;
- local and international legislation and standardization requirements;
- definition of the operational and support environments;
- lessons learned from other programmes such as experience from operation and support
of comparable products and usage;
- feasible and needed repair and supply policy and concepts;
- available skills and resources in existing support organizations;
- supportability, cost and readiness characteristics, goals and thresholds, and related
risks;
- available new technologies that may increase supportability or reduce support resource
requirements.
Activity A411211: Establish state of products needing support
action to predict or otherwise determine the configuration and condition of each individual
product needing support, as it is expected to arrive at the support opportunity including
the raising of work orders for any inspection tasks required to resolve ambiguities
in the product state
Activity A241: Establish support drivers
action to identify the reason why support activities may be required for a set of
products needing support in the context of one or more deployment environments and
to raise issue reports for any safety of support critical features that may require
action by the life cycle owner
NOTE
Support drivers can include:
- product fault states;
- failure effect indications and diagnostic opportunities;
- externally imposed damage or user abuse;
- requirements for work in the physical supply chain such as moving, holding, issuing,
lifting or packing resources;
- safety drivers (legal and others);
- environmental drivers;
- required operation or servicing tasks to be undertaken as part of the support solution.
action to establish the optimal sequence of activities applicable to a given support
opportunity that will best achieve the support opportunity objectives, within the
known task and resource constraints
NOTE
This activity establishes constraints and relationships on and between maintenance
support tasks. These constraints can be due temporal, spatial, or sequential dependencies,
or imposed by safety or other policies.
action to initiate development and assessment of potential solutions to a valid need
for change through identifying potential solutions requiring assessment, planning
and initiating the solution development, assessment, implementation and verification,
selecting a recommended solution, and developing a business case for its authorization,
deferral or rejection
NOTE
This activity includes:
- reviewing the impact assessments, determining in detail the impact of a change in
respect to operation, support, schedule, effectivity and cost in order to approve
or reject the proposal;
- the process of grouping changes to achieve economy of scale and convenience or opportunistic
packages. Variances will be subject to this activity to establish effects on other
configuration items;
- considering the technical, support, schedule and cost impacts of a requested change
before making a judgment as to whether the change should be approved for implementation
and incorporation in the PIF and associated documentation.
Activity A2123: Evaluate support improvement opportunity
action to analyze support improvement opportunities for their ability to contribute
to realizing the support objectives
NOTE
This activity includes the definition of actions needed to realize each potential
improvement opportunity, and to rank opportunities by their potential contribution
to optimum support by assessing potential costs, benefits and risks.
action to execute each released task by performing the steps specified by the task
procedure, including any associated data reporting
Activity A441 A441: Extract and collate information
action to extract and collate information from operation and support activities into
a form that complies with the information management rules
identify, develop, validate, and enhance an optimized support solution definition
for the product in focus, exercising appropriate influence on the product design
NOTE
This activity is assumed to be performed in an environment of concurrent engineering
and integrated teams as defined by the life cycle owner. It may applied when designing
the product and its support concurrently, when developing a support solution for a
pre-existing product that is not yet in use or when updating an existing support system.
The PIF maybe supported by several support solution definitions, each tailored to
a specific group of products, users, roles and support capabilities, collectively
known as a deployment environment. The activity includes:
- identification and analysis of support requirements;
- definition of the support activities;
- definition of the resources required for support, including skilled personnel;
- specification of design requirements for support elements and for embedded support
features;
- the identification, definition, generation and management of support engineering analysis
data;
- the identification, definition and analysis of support cost and readiness drivers;
- identification and analysis of product availability and support system performance
metrics during life cycle of the product. This activity can be necessary more than
once for any given product in focus in order to meet changing and evolving requirements.
Activity A1121: Identify and prioritize change
action to identify and classify a change opportunity or variance based on necessity,
urgency or impact of the potential change
NOTE
Classes for prioritizing change include:
- class 1;
- class 2;
- major;
- minor.
Activity A2321: Identify and resolve conflict between support needs
action to define and quantity support needs into an unambiguous and verifiable form,
resolving any contradictory, ambiguous, inconsistent, or unverifiable inputs, and
providing notification to stakeholders whose needs can not be met by an agreed support
need
action to determine those configuration items that will be affected by the possible
solutions
Activity A313: Identify commissioning resource requirement
action to identify the resources required to perform commissioning tasks, including
the resources needed to establish the support system and to issue transaction requests
for provision of resources at the required locations and dates
Activity A411215: Identify consequential tasks
action to identify additional activities that need scheduling to support the activity
logic or preparation of required resources
NOTE
This may include actions to fit temporary protection; calibrate a required test equipment
or flush a pipework system after an inspection task.
action to provide unambiguous names and identifiers for all elements of the Product
in Focus and the support system
NOTE
An element may have many identifiers, each assigned by a different organization. This
model assumes that the pair of values for "identifier" and "assigning organization"
are unique across the PIF scope. This should be reflected in the Information Management
Rules.
action to identify the tasks that need to be undertaken during a given support opportunity
to achieve the support objectives
Activity A411214: Identify other required tasks
action to identify any other activities that shall be included in a schedule, beyond
those arising from the support solution or commissioning schedule
NOTE
This activity may include tasks to implement a change, tasks deferred or brought forward
from another support opportunity, or exceptional tasks required to achieve the support
opportunity objective.
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:
- tasks to respond to identified support drivers;
- configuration change management tasks to be undertaken by support participants such
as fitting a local modification or conducting an audit of product configuration;
- tasks related to commissioning or other activities within this model.
action to provide both unambiguous identification and classification of all elements
forming part of the PIF and its support system to which reference needs to be made,
including interfaces and other relationships between such elements to which configuration
management shall apply
NOTE
Classification of elements and interfaces can be used to assist in defining information
needs.
Activity A1322: Identify product structure view
action to define which product breakdown views are required by relevant stakeholders
and support participants, to store, search and retrieve product and support information
Activity A41123: Identify required resources
action to identify the resources required to perform the selected activities, including
when and where the resources are needed
Activity A11311: Identify solution options
action to identify potential solutions that may meet the change requirement
NOTE
The development stage of the change will identify a choice of solutions that may meet
the change requirement. Viable solutions are developed so that the impact of each
can be assessed.
Activity A2313: Identify standardization requirement
action to identify standardization requirements related to support that could affect
the definition of the support solution, the product design or the requirements for
the support system
NOTE
This activity can include consideration of the following:
- support concepts;
- interfaces with other products and systems;
- partnerships for support;
- component and spares selection;
- test and training equipment;
- physical product characteristics;
- the need to share support resources with other products consuming similar resources
inside the existing organization or support environment;
- the need to share with other organizations using the same support resources.
Activity A2122: Identify support improvement opportunity
action to identify and review potential opportunities for improving a support solution
and identify those that shall be addressed as part of the support engineering programme
NOTE
This activity can include:
- screening opportunities for applicability to the support solution requirements;
- establishing requirement to address alternative solutions in trade-off analyses;
- proposals for work to be done to improve support.
Activity A2225 A2231: Identify support locations
action to identify locations at which support could be provided
NOTE
This activity can include the provision of support whilst a product is operating.
Activity : Identify support opportunities
action to identify the type of opportunities that may be available when work can be
done on a product needing support
NOTE
This activity can include opportunities such as when operating, daily checks, pre-flight
inspection or annual overhaul.
action to identify opportunities for improving the support solution in the form of
proposed tasks for inclusion in the support engineering plan, or for release as work
requests to the life cycle owner
NOTE
This activity includes:
- identification of opportunities for improving availability or reducing life cycle
cost arising from advances in technical capability or from experience with similar
product or support systems;
- analysis of factors in the external environment that could influence, or pose risks
to the support solution, including political, legal, international, economic, social,
and cultural aspects.
Activity A2311: Identify support stakeholder
action to identify the individual stakeholders or stakeholder classes that have a
legitimate interest in the product throughout its life cycle
NOTE
Stakeholders may include users, support engineers, developers, manufacturers, trainers,
maintainers, inventory managers, supplier organizations, regulatory bodies and members
of society. Where direct contact is not practicable, as with consumer products and
services,
representatives or designated proxy stakeholders may be identified in their stead.
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
Activity A411212: Identify triggered tasks
action to identify due tasks specified by the support solution by evaluating the task
trigger conditions using the individual product state, usage or other relevant parameter
Activity A1343: Implement information release plan
action to execute and monitor the release process in accordance with a change order
Activity A11313: Initiate solution development and impact assessment
action to raise work requests for the definition of a potential solution and assessment
of its impact
action to achieve the systematic proposal, justification, evaluation, coordination
and disposition of proposed changes, and the implementation of all approved changes
into applicable configurations of a product, associated product information and supporting
and interfacing products, and the associated information of those products
NOTE
Changes may result from various sources including the discovery of a problem, a suggestion
for product improvement or enhancement, a customer request, or a condition dictated
by the market place or by public law. Regardless of the type of product or phase of
the life cycle, a change to a product should be accomplished using a systematic, measurable
change process. The purpose and benefits of the configuration change management activity
are:
- enable change decisions to be based on total knowledge of all change impacts;
- limit changes to those that are necessary or offer significant benefit;
- facilitate evaluation of cost, savings and trade-offs;
- ensure customer interests are considered;
- provide orderly communication of change information;
- document and limit variances;
- facilitate continued supportability of the product after change.
action to provide unambiguous identification of all elements, and versions, of the
product or support system to which reference needs to be made, identification of interfaces
between elements, the necessary assembly, and other breakdowns structures, required
to manage the product through life and definition of the information to be held for
each type of product and support system element
NOTE
This activity occurs throughout the product life cycle and is the basis of management
of configuration change and configuration status accounting of a product and all constituent
configuration items. The purposes and benefits of this activity include:
- determining the structure (hierarchy) of a product and the organization and relationships
of configuration documentation and other product information;
- documentation of the performance, interface and other attributes of a product;
- determination of the appropriate level of identification marking of product and documentation;
- unique identification of a product or component part of a product;
- unique identification of the technical documents describing the product;
- modification of identification of product and documents to reflect incorporation of
change;
- distinction between product versions;
- correlation of document revision level to product version;
- correlation of a PIF to related user or maintenance instructions at the configuration
item level.
action to manage the information related to a PIF
NOTE
This activity corresponds to configuration and data management and the major output
is APSI, which encompasses the entire configuration and support data. A subset of
the APSI is the configuration status record. The dynamic nature of the configuration
and data management activity, and its importance within the operation of a consistent
configuration management process throughout the product life cycle requires a formal
approval process to attain APSI status. All configuration documentation (requirements
and design documentation) and associated operational information (operating procedures,
parts catalogues, and so on) that comprise the configuration status record must be
formally managed and approved. In essence, approve, release and record is a process
that makes configuration and support documentation available for use, subjects it
to configuration change management and maintains the assured status of the APSI.
action to capture, and manage through life, the information needed to support the
PIF
NOTE
This activity includes configuration identification of the PIF and its support system
plus configuration change management of the integrated set of APSI used to develop
the support solution and provide support. It also includes development of information
management rules that govern the recording, storage and publication of APSI and of
all other related information generated or used by support activities such as maintenance
history. APSI includes:
- product structure, including identification of permitted, actual and desired configuration;
- product performance, with tolerances and representations;
- support requirements and description of the support environment;
- product failure modes and diagnostic data;
- maintenance concepts, plans and task instructions including definition of the feedback
required when tasks are executed;
- resources needed to conduct maintenance.
action to record and assess issues according to type and priority
NOTE
Issues that require change action are passed to the other configuration change management
activities. A unique identifier is issued as part of activity A1.2 (manage identification).
Issues include any issue, problem or proposal related to configuration management.
Such issues can be variances, documentation error reports from any source but principally
from support engineering, resource management, maintenance and feedback or configuration
discrepancy reports, perhaps arising from change monitoring or audit activity.
action to monitor the support feedback to confirm task completion and product status,
to identify new tasks for release or the need for a scheduling revision
action to manage the development of a support solution definition for each deployment
environment, over the life cycle of the PIF, by defining objectives and acceptance
criteria, establishing a support strategy, developing a support engineering plan and
monitoring resultant activities
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:
- generation of work requests for action to identify, modify, design or acquire the
resources required by task, providing sufficient information on the resource requirement
to permit such activity to proceed;
- generation of requirements for changes in product functionality for support reasons,
including support related design features, such as lifting lugs, and requests to embed
support functionality, such as built-in-test capability, within the product design.
action to plan and control the execution of maintenance and support tasks
action to establish which members of the PIF are to be changed, including new production
and existing products
NOTE
There are many influencing factors on this activity including an assessment of the
urgency and priority of the change and the availability of parts and materials, software
and replacement parts. Determining an effectivity requires knowledge not only of the
lead times associated with changing the product (whether in production or by retrofit,
recall or other means) but of the actions and lead times necessary to effect the associated
change in all impacted support areas (such as the update of support software, availability
of spare and repair parts, or revision to operating and maintenance instructions).
Once the change is approved detailed implementation planning, which expands but remains
consistent with the basic planning is normally required. Implementation of a change
involves the release of new or revised configuration documentation including requirements
and design information. This implementation may involve changes to information on
operation and maintenance, build and test, and commercial documentation. The new or
revised information is identified and released within activity A1.3 (manage information).
The release process ties the document revisions to a change. It is not always necessary
to have a plan before a change task can be authorized. However, a change implementation
plan is usually needed.
Activity A11322: Plan change implementation
action to define the effectivity of the classified solution and to plan the work required
to implement a solution to a valid need for change, to the level of individual products
NOTE
This includes identification of the point in production at which the change will take
effect and identification of the realized products, in manufacture or in use, to which
the change applies. This activity extends the development plan to include assessment
of the impact of the proposed implementation and any additional work required to quantity
the change. Related change tasks will be identified in this plan.
action to create a schedule for a support opportunity including the identification
of objectives; the identification, sequencing and scheduling necessary tasks, and
arranging the provision and disposal of all necessary resources such as materials,
labour, support equipment, facilities and, documentation to be available at appropriate
times and locations
NOTE
Support schedules may have different planning horizons such as annual, quarterly,
monthly, weekly, and daily. One schedule may be a decomposition of another. Support
tasks should be scheduled against a specific products or support element. Each schedule
may be progressively refined and expanded until it defines the timing and location
for all tasks applicable to the support opportunity in question.
Activity A213: Plan support engineering activity
action to develop a programme of work for generating a support solution to meet the
support engineering objectives
Activity A11323: Plan validation verification or audit change
action to develop a plan for the tasks required to validate, verify or audit a change
NOTE
Such plans should be based on the decision taken concerning the introduction point
and effectivity of the change. It will cover both production embodiment and retrospective
embodiment, before or after the delivery of the product as appropriate. An approved
change is planned and scheduled for implementation in all documents, facilities, hardware
and software impacted change. The implementation is carried out in accordance with
the plan. Implementation of a change involves the release of new or revised configuration
documentation (APSI) including requirements and design information. The implementation
may involve changes to operation and maintenance information, build and test information,
and sales information (such as catalogues, marketing literature). The new or revised
information is identified and released as APSI. The release process should correlate
the document revisions to the change or changes incorporated. A common method of disseminating
document change is by means of document change notices, which establish a permanent
record of specific changes and facilitates distribution.
Activity A11321: Plan work to develop change solution
action to plan and monitor the work required to develop an adequate solution to a
proposed change
NOTE
The basic planning for implementation of the change is accomplished during the change
evaluation before the change is approved. The level of detail required in the plans
and schedules will be dependent upon the change complexities in respect to the interrelated
change activities across the whole business scenario.
Activity A133: Populate information structure
action to populate the PIF structure with the information specified by information
needs
NOTE
This activity captures all necessary information on product and support elements,
including relevant interfaces and inter-changeability information, and establishes
appropriate relationships with the PIF structure to establish a sufficient set of
product and support information for the PIF to meet life cycle support needs.
Activity A24352: Predict required tasks and downtime
action to predict, for each product, the tasks that will fall due during the operating
period of interest and their impact on product downtime
NOTE
Given sufficient information on the product state the required task can be derived
from the support solution by evaluating task trigger conditions. The expected downtime
can be estimated from the time needed to perform required tasks, plus logistic delay
time.
Activity A24353: Predict resource consumption
action to predict the resources needed to support a product during a specified period
of operation
Activity A24351: Predict state of product over time
action to predict the likely future state of each product needing support throughout
the period of intended use
NOTE
Predictions are required in terms of the parameters that define task trigger conditions
such as the likelihood of occurrence of fault states, product wear or other relevant
condition and usage parameters used by tasks triggers.
Activity A24354: Predict support performance
action to predict the performance of the support system over the operating period
of interest in terms of the support characteristics applicable to the support solution
definition
action to predict the performance of the support solution when applied under specified
conditions
NOTE
Performance may include predictions of the impact of the support regime on the product
downtime and availability, and predictions of the expected resource requirements or
consumption. Prediction of some metrics may require assumptions to be made about the
availability of required resources.
action to apply the support solution to one or more products needing support
NOTE
This activity includes planning of support delivery, provision and disposal of necessary
resources, implementation of authorized tasks, and collection and reporting of operational
and support feedback.
action to achieve and sustain efficient support of a product in focus throughout its
life cycle
NOTE
This activity covers the support and disposal of products, the definition, commissioning,
use and upkeep of the support system, and the management of support information. The
product is designed, tested, manufacture and operated outside the scope of this model.
Activity A243233: Rationalize tasks and task relationships
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 document, identify and monitor issues that can require a configuration change
management activity and impact assessment
action to authorize and release the assured information needed to achieve product
life cycle support
NOTE
This action involves checking the PSI for:
- completeness against the information need;
- compliance with the change order and the information management rules;
- timely release as required by the change implementation plan.
action to monitor the progress of work and the state of the product to enable release
of the product back to operational use
NOTE
This process must take account of any limitations or restrictions that have been recognized
or documented during the support cycle. It may not be possible to release the product
unless the condition and configuration are within the conditions specified by the
support solution.
action to authorize work to begin on a task in accordance with the support schedule,
the product status and the progress of work
Activity A214: Review support engineering programme
action to review the performance of the support engineering activities by comparing
progress against the support engineering plan and support system performance against
support engineering objectives and raising proposals for change as required
action to develop an activity schedule and resource schedule for the work to be undertaken
during a support opportunity
Activity A315: Schedule commissioning task
action to develop the commissioning programme logic and identify when commissioning
tasks must start and finish to make support capability available by the expected first
use dates, derived from the operational schedule
NOTE
Scheduling may involve multiple time planning horizons as long-range plans are progressively
refined.
Activity A411213: Select commissioning tasks
action to select tasks from the commissioning schedule due to be undertaken in a given
support opportunity
action to select the tasks needed to address relevant support drivers within a deployment
environment
Activity A24321: Select relevant support drivers
action to select the support drivers of relevance to a specific support context
Activity A4111: Select support opportunities to schedule
action to select, from the operating or resource use schedule, the support opportunity
in which work shall be scheduled and to establish the objectives and definition of
each support opportunity to the level needed for developing the support schedule
Activity A243234: Select support plan option
action to select the support plan option that best meets the support solution requirements
based on predicted or measured performance
action to select the support provider, or providers, to perform the scheduled activities
NOTE
Selection of the provider may alter the support schedule, owing to different locations,
skills or available resources.
Activity A1342: Verify suitability for release
action to check that all required approvals are present and segregate private and
public view information from common configurations but for different customers
NOTE
The private and public view information will be placed on different release plans.
set of information, subject to configuration change management, that is established
to develop and deliver support for a product in focus
NOTE
This term corresponds to the EIA 649 term "product configuration information" which
includes:
- product definition information that defines the product requirements, documents the
product attributes and is the authoritative source for configuration definition;
- product operational information, used to test operate maintain and dispose of the
product.
set of assured and related information used to develop and deliver support for a product
in focus, including feedback from using and supporting the product over its life cycle
NOTE
Related information includes records of the history of the usage or support of realized
products, design and support analysis results and reasons why decisions were taken.
Such information includes design and failure analysis records, logistic support analyses,
running hours, environment descriptions, operating profiles; test results, records
of maintenance activities, resources used, and faults found plus any other content
deemed relevant to life cycle support.
proposal for correcting the APSI to reflect findings from verification or audit activities
identification of the group of actual or potential operational products and related
items that require support during their life cycle
NOTE
The PIF scope can include:
- many versions of a product design;
- many operational products, used by different users in different ways;
- any part of the operational product needing support;
- any related item that requires support.
integrated set of classified elements and interfaces, product structure views and
relationships between product structure views required to provide life cycle support
NOTE
The PIF structure comprises:
- the set of breakdown and assembly views being maintained for the product in focus
including effectivity statements on the current, required and permitted configurations
of each individual planned or realized product;
- relationships between breakdown and assembly views such as functional to physical
links for both design and individual structures;
- identification of interfaces between elements.
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.
item affected by relevant solution
support need accepted as suitable for inclusion in a support solution requirement
requirements that have been allocated for consideration during the design of a support
solution
NOTE
Allocated requirements are typically a subset of the product requirement but may not
capture the needs of all recognized stakeholders
issue from analysis of assessment results and perhaps requiring change to the assessment
strategy
information arising from assessment activities
NOTE
Such information includes reports on the support system performance in relation to
support objectives or metrics; recognized deficiencies or proposed improvements to
the product or support solution, issues with the support solution requirement.
strategy for assessing and validating the support solution definition, and the support
engineering programme, against agreed objectives and metrics
issue that may require a change to the assessment strategy
NOTE
Such issues include:
- observations that the strategy for assessment of the support solution is inadequate
or unrealistic;
- the identification of information sources that do not provide the required information;
- reports on inconclusive assessment results due to inadequacies in the assessment method
or inadequate information.
support solution definition that is authorized for use in providing support or disposal
to one or more product or support element
issue arising from configuration audit and verification feedback
feedback from audit or verification tasks reporting the progress of work and audit
or verification findings
NOTE
This may include configuration records or reports of variance for realized products.
task on which work may begin
information required to evaluate the potential cost, risks and benefits of any element
of a proposed change
plan that identifies and schedules the tasks required to develop a change
task required to progress the development of a change
work orders and work requests that result from the configuration change management
process
NOTE
Change directives serve as controls on the implementation or investigation of an identified
change. Change directives include change orders, change tasks, change plans and change
requests.
business case for making a change, including assessment of cost, benefits and risks
NOTE
The change justification acts as a control when authorizing change.
authority to implement a change to a product
NOTE
The change order defines the change and authorizes release of updated APSI
information defining the tasks required to implement a potential solution including
the required time, resources and budget
NOTE
Such plans include change development plans, change implementation plans and change
validation, verification and audit plans.
priority that has been assigned in accordance with information management rules or
local business rules to enable adequate subsequent processing
risk relating to a potential change
detailed list of possible features of the product and its support solution that may
be affected by the change, each of which requires assessment before a change decision
can be made
NOTE
The checklist may form part of the life cycle directives.
element of the PIF or its support system and that has been identified and assigned
to one or more classes of element, plus any relationships between elements needing
to be tracked for support purposes
NOTE
Unambiguous identification includes the assignment of a name (for use by humans) and
an alphanumeric identifier (for use within computers) that are unique within a context.
The context for a name or identifier is the organization that provides the name and
identification. Elements can have more than one name and identifier assigned by different
organizations. The classification of an element can include a class that helps identify
the APSI that is required for this element type. Relationships can include any of
those specified by the information model of this part of ISO 10303.
potential solution to a valid need for change to which a class has been assigned
NOTE
The solution should include specification of the intended design change and related
impact assessments to be evaluated for effectivity and cost implications and work
to plan change tasks can be initiated
information on the progress of commissioning activities against the plan or recommendations
for change to the support solution, the product, or the commissioning schedule, arising
from commissioning experience
NOTE
This feedback includes:
- aggregated status of commissioning tasks;
- commissioning task discrepancies and proposals for improvement in the commissioning
solution;
- proposals for improvements to the support solution or product arising from commissioning
experience.
objective to be achieved by the commissioning activity
NOTE
The objective may address any phase of the commissioning process including acquisition,
construction, testing or certification of support system elements
logical constraints and relationships applicable to intended commissioning activities
schedule showing the intended timing and sequencing of intended commissioning tasks
NOTE
Commissioning tasks are those required to create the support system.
activity to create, test or validate an element of the support system
NOTE
This includes activities to establish resource items in appropriate locations and
work to bring support infrastructure to a state fit to receive a product needing support.
information on the progress, resource consumption and issues arising from performing
commissioning tasks
NOTE
Information provided to identify trends or potential problems from applying a commissioning
solution.
measures of performance applicable to the performance of commissioning tasks
request for the development of a task specification for a commissioning activity not
included in the current PIF task set
record of successful completion of a task required by a support schedule
document that specifies how configuration management is to be accomplished for the
product in focus
NOTE
The CMP provides details of the processes, schedules and associated toolset for performing
Configuration Management including resources and skills. Activities required to develop
the CMP are beyond the scope of this activity model. Further information on configuration
management can be found in ISO 10007.
record of the configuration of a realized product
NOTE
Records of configuration status may be required following incorporation of a configuration
change, the removal of a serialized item, the replacement of a serialized item or
the performance of a configuration audit task.
activity that needs to be included in a schedule as a consequence of another task
NOTE
May include additional tasks required by the proposed activity logic or by resource
preparation requirements such as the work needed to set up and calibrate a test rig.
quantified change with life cycle costs incorporated
lifecycle directive confirming the approval, deferment or rejection of a change by
a customer or other external authority
NOTE
The directive may specify a particular disposition such as in work, complete, rejected,
approved, deferred or pending.
context for which a support solution definition is created
NOTE
A deployment environment identifies the set of products and defines the operating
and support environment to which a support solution definition applies. A deployment
environment may relate to the entire product in focus, or to a subset of it. A product
in focus may thus give rise to several support solution definitions, each tailored
to a different deployment environment.
set of product structure views and breakdowns that the life cycle owner has chosen
to establish and maintain for the life of the PIF
plan of the activities required to develop and evaluate a possible change
element of the product, or its support system leaving the control of the life cycle
owner
NOTE
Disposed elements may include:
- waste products arising from support tasks;
- resources no longer required for planned tasks;
- elements removed from the product;
- a product retiring from use.
change opportunity or identified problem to which a change priority has been assigned
definition of which realized products will be affected by a change
NOTE
This report may define the production break-in point or the applicability of modifications
to a product already built.
potential requirement on the design of the support solution, reflecting the desires
and expectations of a recognized stakeholder
NOTE
Elicited needs are derived from analyses of customer and stakeholder needs and priorities
with associated rationale, including source documents or agreements. Elicited needs
may include:
- expectations for the lifetime of the product and its support;
- intended duration of deployments;
- numbers of products needing support;
- needs for standardization with other organizations, users or partners;
- needs derived from experience with the development, production, use, support or disposal
of similar products;
- needs derived from experience of similar organizations, environments and scenarios;
- needs derived from experience with the use and support of the product since its introduction
into service.
opportunity to improve the performance of a support solution, able to be addressed
as part of the support engineering programme
NOTE
Support improvement opportunities may be expressed as specified tasks or as work requests.
aspects of the external environment that provide opportunities or pose risks to the
successful provision of support
information of relevance to support that is derived from experience or observation
NOTE
In combination with other inputs to the configuration management activities feedback
may prompt the need for a change and assist the development of a change. Feedback
may include:
- work requests or issues that may lead to change;
- requests for identifiers for product or support elements;
- impact reports in response to change tasks;
- status reports on progress with change tasks;
- support and commissioning feedback.
requests for further information to assist conflict resolution between requirements
date when a support element is required for first operational use
NOTE
The first-use date is used to establish the schedule of commissioning activities.
hierarchical decomposition of the functions of a product
NOTE
The functional breakdown elements can require support.
hierarchical product decomposition consisting of elements that are either of various
types or not system, physical, functional or zonal
NOTE
Such a breakdown view of the product can be a hybrid, combining more than one different
type of breakdown element within the breakdown. The breakdown elements can be system,
physical, functional or zonal elements. These elements can require support.
any subdivision of the PIF, the support system or related information to which consistent
reference needs to be made as part of product life cycle support
NOTE
Certain identified elements may be selected as Configuration Items.
identification of a potential solution that may satisfy a valid need for change
identification and description of an intended location or geographical area where
support may be required or provided
predicted consequences of adopting a potential solution to a valid need for change
NOTE
This arrow communicates a solution definition report and an assessment of business
impact on support engineering. It will be combined with similar information from beyond
the model boundary assessing the impact on other technical domains.
consequences that a potential solution has on other changes that are proceeding in
parallel
NOTE
Such impacts can include the situation where one change is necessary before another
change can be implemented.
report on the potential impact of an issue providing an input to a decision on whether
to proceed with a change
plan defining the activities needed to realize a solution to a valid need for change
request for a change to the assessment strategy, arising because available information
collection mechanisms can not provide the required feedback
expected configuration and condition of an individual product at the start of the
support opportunity
NOTE
This information may be available from the APSI and related information.
expression of need for an activity to collect assessment information
NOTE
Requirement may be met by:
- adding a task step to an existing task required for other reasons;
- adding information collection tasks to the support engineering programme, or the support
solution definition;
- adding embedded support capability in the product such as product health monitoring.
information on the identity, description or in-service performance of other products
or support systems of relevance to the product in focus
NOTE
This information could be supplied in a format that conforms to this part of ISO 10303,
but is perhaps only be available on paper or in other data formats that do not conform
to ISO 10303.
specification and scheduling of the activities required to develop, collect, analyze
and publish the information needed for product support
NOTE
This includes a control to ensure that the APSI is released in a timely and appropriate
manner.
set of rules and interpretation guidance provided to achieve effective information
sharing and exchange across the PIF scope
NOTE
Such rules can include:
- policies and instructions on the management of APSI and related information specifying
what information shall be recorded, utilized and archived when performing support
activities;
- information models, standards, formats, business rules, naming conventions and reference
data required to achieve effective communication;
- specifications of the information to be acquired or disposed of along with the product
or support elements as they enter or leave the information management domain defined
by the PIF scope;
- references to this or other parts of ISO 10303 that shall apply to information of
relevance to the PIF.
intended approach to managing information for a given product in focus
model in EXPRESS or other modelling language provided to define how product and support
information shall be structured
NOTE
The information model is one component of the information management rules.
specification of the information that shall be developed and maintained within the
APSI for any PIF or support system element or class of elements
schedule defining the timing for the release of assured information
NOTE
The information release plan may specify who needs what information, when, where,
in what formats and what media.
information technology capability able to provide timely, convenient and effective
access to all participants in support activities for entering and reading information
NOTE
The activities defined in the model could be performed without this resource but the
model was designed to reflect the use of a shared, and integrated, data environment
by all participants.
information provided to the user or operator of a product needing support regarding
the condition of the supported product
NOTE
Such information can include:
- information arising from the maintenance of a realized product and affecting subsequent
operation, such as a power limitation pending further maintenance work;
- achieved availability or other aspects of support performance of relevance to operators;
- readiness of the support system and availability of support elements and services;
- limitations on product or support system availability;
- any anticipated impact on operational plans from PIF condition, such as a requirement
to perform further maintenance within a specific time period;
- responses to operator requests on operational or support problems.
minor corrections to the APSI that do not require formal change action, arising from
assessment of issues, or from configuration audits
quantification and predicted availability of support resources at each support location
of relevance to a product group
product attributes that exist at a common boundary of two or more products to which
reference needs to be made
question, concern or proposal related to Configuration Management
NOTE
Issues may include:
- variances such as waivers, deviations or production permits;
- documentation error reports;
- configuration discrepancy reports.
issue that, following assessment, is deemed to be worthy of subsequent change action
instructions or policies from beyond the model boundary that initiate or constrain
support activities from concept through disposal
NOTE
These directives may include:
- law and political dictates;
- environmental and safety directives;
- business, organizational and programme strategies and policies;
- standardization policy and directives;
- programme plans and schedules defining what action is needed, when, where and by whom;
- programme business goals, objectives, targets and constraints such as annual budgets
and performance targets;
- priorities from the life cycle owner that affect the feasibility of providing needed
support elements;
- decisions arising from consideration of requests to the life cycle operator;
- exceptional maintenance demands not reflected in the support solution definition;
- information from the operational plan, sufficient to define each support opportunity,
and to define the constraint on support delivery.
name, definition and representation options of a parameter used to define product
usage or set limits on product life
NOTE
Typical parameters include:
- elapsed time since vessel launch;
- numbers of landings;
- hours above 30% power;
- fatigue cycles of an identified component, measured in a defined way.
set of stakeholders identified by life cycle directives
definition of relevant environmental conditions at an identified location and that
could affect the provision of support and hence the support solution
NOTE
Such environments can include artic or desert conditions, or the use of a covered
dock.
work request identifying additional support tasks that may be needed to restore products
to serviceable conditions
standards and conventions that are to be applied when identifying elements of the
PIF or support system
NOTE
Naming conventions are part of the information management rules.
name and identifier of a task that is applicable to a given support solution definition
request for action to respond to issues revealed by an impact report relating to a
proposed solution
identification of the information that needs to be collected to support assessment
of support performance against the metrics specified by the support solution requirements
request for change to a support objective that can not be met
description of an environment in which a product may be required to operate, from
the viewpoint of its likely impact on the requirement for support
anticipated support opportunities and expected usage of one or more products needing
support during a period of interest
information provided to support authorities by operators including information on
product health and usage, and equipment problems discovered by operators
NOTE
Such feedback can include trouble reports, log books and other data from on-board
recording systems, passed to support authorities for analysis. The operator feedback
is structured to conform to the information management rules by activity A4.4 and
is communicated within this model by the support feedback arrow.
identification of a task to be scheduled that has not arisen directly from the application
support solution or commissioning schedule
NOTE
Such tasks can include change tasks, outstanding tasks from previous work, exceptional
tasks required by the life cycle owner, or tasks required to meet support opportunity
objectives.
information on the performance achieved in generating a support solution or in providing
support
NOTE
A performance report may include:
- information on progress achieved against the support engineering programme;
- comparison of achievements, predictions and requirements in terms of the support metrics
applicable to a given support solution;
- observations on the performance achieved against identified support objectives;
- observations on the ability of the PIF and its support solution to meet expectations
of operators and support personnel.
hierarchical decomposition of the physical elements within a product
schedule identifying the tasks required to validate, verify and audit a classified
solution
identification and description of each potential fault or other degraded state that
can affect each part, function or usage occurrence in each operating environment,
including cause, effect or other relationships between relevant states
NOTE
The product functions can be represented by a functional breakdown. Faults can be
defined as product states.
identification of the items forming a potential solution to a valid need for change,
including conditions for supersession of existing items within a product design
identity, description, organisation, location, environment and capability of each
potential support provider of relevance to a product group
name, identifier and description of a possible support task
forecast loss of operational time due to support activities during the operating period
in question
forecast state and usage of the product after a period of operation, defined in terms
that are meaningful to the task triggers, including predictions of anticipated faults
forecast of the resources needed to support a product during a specified period of
operation
any information about the product in focus and related support elements that is required
by participants in life cycle support
NOTE
This information may include:
- product definition information;
- product performance information;
- predicted failures;
- diagnostic data;
- descriptions of the product or support element;
- manufacturing records;
- product characteristics of relevance to support;
- descriptions of people and organizations;
- the operating and maintenance history of individual acquired items if relevant to
future support.
potential APSI prior to authorization and release
hierarchical view of a product based on the assembly of its constituent parts
NOTE
The product assembly may be used to derive a parts list or bill of materials.
expected behaviour of a product for support purposes defined in terms of operating
and fault states, expected values of measurable parameters, and relationship of symptoms
to possible and probable causes
set of products that are operated by one or more customers and are to be addressed
by a specific support solution definition
expected pattern of usage and life constraints applicable to a product group requiring
support
NOTE
A product group may have several usage profiles, including a prediction of the percentage
of time for which each may apply. Each profile may include:
- the duration and nature of deployments;
- the intended frequencies, duration, distance, pattern, and nature of operating and
support periods;
- the anticipated physical and climatic environments in which usage is expected to occur;
- usage parameters and limits on product use.
information of the product usage and condition over a period in the past, derived
from support feedback records
identification of product conditions not recognized or addressed by the support solution
that require analysis and direction
NOTE
The absence of a response to such exceptions may prevent release of the product to
service. The existence of product integrity exceptions may lead to an extension of
planned work or of the support solution definition.
one or more realized products that require support
NOTE
Such products include any realized element of the PIF. These elements include embedded
information of relevance to support activities. This information can take the form
of stamped on serial numbers, bar codes, embedded chips, log books or other media
carried with the product itself.
information on the state of the product or support element on which a work is underway
collected by observation
NOTE
This may include information about the product configuration, product status and product
condition such as test results, wear measurements and information derived from embedded
support capabilities.
information confirming that a realized product, having received support, is now ready
for use
NOTE
This report can contain or make reference to:
- the identity and configuration of the realized product;
- confirmation of ready for use status;
- a date and time stamp;
- the organization, location or person authorizing release;
- any restrictions or limitations applicable to product use;
- information on tasks scheduled and completed.
notification of the current state of a product receiving support, as confirmed by
the authority controlling the work
observations, measured characteristics or a record of the state of a product needing
support
NOTE
The state of a product can include the existence of fault, an operational state or
a status in relation to recognized steps or stages of a support process such as awaiting
test or ready for dispatch.
information of the past use of an operational product
NOTE
Product use can be quantified against any usage parameter in any pre-defined operational
or usage state such as product life, number of landings or hours spent above 50% power.
Product use records can be contained in, or extracted from, log books or electronic
records, such as tapes or discs, as provided by product operators or other personnel.
expression of need for a change of the support engineering programme
definition of a potential solution to a valid need for change, supported by plans
for its implementation, validation and audit
NOTE
A quantified solution should include:
- identification of the products or support elements that require change;
- definition of the new items generated by the change;
- definition of the work to be done, by whom and when, to complete the change;
- information on why the change is required, and how it was justified;
- impact on related changes;
- requirements for reporting progress and completion of change implementation.
performance measure, with target value, to be used for assessing the performance of
the support solution definition
NOTE
This includes specification of the performance measure in terms of agreed characteristics,
and the quantification of target or threshold values for use when assessing support
achievement. Quantification may be expressed in terms of any agreed characteristic
including cost, availability, time or rate of resource use.
proposal to change the assignment of tasks to products, or the task trigger conditions,
to achieve rationalization of work packages within the support plan
person or organisation with a legitimate role in the specification, design, commissioning
or use of a support solution definition
NOTE
Recognized stakeholders can include:
- users;
- supporters;
- developers;
- producers;
- trainers;
- maintainers;
- disposers;
- acquirers;
- supplier organizations;
- regulatory bodies;
- members or groups in society, including representatives or designated proxy stakeholders.
recommended solution to a valid need for change, after comparison of potential solution
options
work request or expression of concern that has been documented and identified
notification of decision not to release product and support information as APSI
recorded issue that has been rejected following assessment, possibly including the
reasons for rejection
message advising that no further action is intended in respect to an issue or change
NOTE
A rejected issue or change should be supported by a reason for rejection and may include:
- issues that will not be taken forward as change orders and for which exists no further
planned configuration change management action;
- a valid need for change that was rejected following evaluation on cost, effectiveness
or other grounds;
- a variance that has been rejected as a method of correcting a non-conformance.
request for change that has not been accepted
potential solution that has been rejected because it not an optimal response to a
valid need for change
information that is related to the APSI but is not subject to configuration change
management
NOTE
Such information includes feedback from operations and maintenance.
information relating to the product that can be released as APSI, under the conditions
specified by the information release plan
support driver of relevance to a specific deployment environment and support concept
request to provide a price or cost impact statement against a statement of work
request for an assessment of the impact of a proposal to apply a change to specified
products
request to provide identification for new elements of the product or support system
element
NOTE
Requests may arise from new product concepts, developing breakdowns of existing products,
or from changes.
request for assessment of the potential impact of an issue perhaps leading to a valid
need for change
request for action resulting from assessment activities
NOTE
May include:
- proposal to change the resource provision related to a given task;
- proposal to change the support solution;
- requests to relax support solution requirements;
- proposal to change the product;
- requests for additional data from existing source or for new data sources.
request for action that is not part of a change, arising from a documented problem
NOTE
May include request for additional information to support change action, or the deferral
of change action to a later date
invitation to stakeholders to re-assess allocated requirement, support objectives
or elicited needs generating requirement conflicts that can not be resolved adequately
by the support engineering programme
request for revisions to the support schedule as a result of feedback from task execution
NOTE
This may include reports of deferred tasks or requests for additional activities that
should be considered for inclusion in a subsequent revision of a support schedule.
request for impact assessment of potential design solutions that could satisfy a valid
need for change
request for a change to the support concept
request for the design or supply of a new or additional resource item required by
a task, or for information on the feasibility and cost of obtaining these
NOTE
This request can also communicate formal requirements and specifications for the design,
modification or acquisition of new or critical support items, and could also be used
to request information on support cost and lead time for products beyond the PIF scope
and that have relevance to the support of the PIF.
invitation to further develop a task specification
request for the development of a task procedure for an intended task not addressed
by the support solution definition
request for an update to an implementation plan, following authorization of a change
request for action to assess the feasibility of changing the product to improve supportability,
or to embed support capabilities within the design
NOTE
Such a request can result from requirements to improve reliability, maintainability,
redundancy, durability, sustainability or product life. Requests to embed can seek
to incorporate capability within the product for prognostics, diagnostics, condition
monitoring, built in test, safety or environmental protection that is needed for support
reasons.
invitation to allocate a change identity and priority following assessment of a documented
problem
NOTE
This request may lead a valid need for change, after appropriate analysis.
request for action by the life cycle owner relating to activities beyond the scope
of this model
NOTE
These requests can result from supportability analyses, assessments or experience.
They can lead to a further iteration of the in-scope activities, triggered by work
requests entering the scope of this activity model as feedback. They can include:
- requests for action to develop or acquire required resources not currently available
in the deployment environment;
- requests for information;
- proposals for changes to the product requirement, allocated support requirements,
product design or life cycle directives to reflect support needs.
invitation for action to better define a document problem
identification of the resources needed to support scheduled work at one or more support
opportunities
set of product assembly or breakdown views that the life cycle owner requires to establish
and maintain the PIF
tasks expected to be performed during the operating period of interest
information derived from the life cycle directives, expressed as a potential requirement
for a support solution definition
proposal for changes to the support solution requirements arising from monitoring
support system performance
need for a breakdown view that is necessary for life cycle support of the PIF
request to the life cycle owner to address issues identified by the task analysis
activity
NOTE
This can include:
- requests to designers to assess the feasibility of changing the product to improve
supportability;
- requests to investigate the feasibility of changing the product design to meet support
solution requirements by improving reliability or preventing a failure mode;
- notification of potential health, safety and environmental risks identified by the
task analysis that may require design activity;
- notification of constraints imposed by support activity on the intended use of the
product;
- requests for action to identify or modify existing resources required by tasks;
- requests for the provision of new resource capability and that perhaps lead to updates
of resource item descriptions within a deployment environment.
information on the adequacy and quality of resources provided to support a specific
task, a specific deployment, a realized product or the overall support solution definition
NOTE
This may identify a task or resource imbalance or deficiency that may justify a reassessment
of the resource aspects within a task analysis.
identification and description of the resource items expected to be available at each
location to support a product group
recommended holdings of resource items required to support a given support solution
definition, or the set of support solutions definitions
information on the past use of a resource in the course of performing one or more
support tasks
NOTE
Resource usage includes the consumption of spares or consumables, time spent by human
resources in performing support tasks and the usage of support locations or facilities.
Usage may also be measured by other parameters such as elapsed time, number of starts
or cycles of operation.
request for action by the life cycle owner, or an expression of concern, arising from
identification of support drivers that affect safety or other topics of critical significance
to the delivery of viable support
information on issues that prevent successful completion of the commissioning schedule
NOTE
Such information can identify tasks that can not be scheduled due to constraints from
resource availability, operational schedule, or other reasons.
activity required in the commissioning schedule to establish a viable support system,
capable of applying a support solution definition
organization, or organizations, selected to perform scheduled tasks
definition of a potential solution plus recommendations for further work required
to complete assessment of a potential solution
set of standardized business transactions that execute requests for the provision
of resources, and provide responses on their expected delivery
NOTE
These transactions can include:
- order an item, perhaps including requirements for delivery to a specified location
by or on a due date at an agreed price;
- order a service;
- request a move of item from one location to another, under specified conditions such
as use of a packaging standard or need to provide tracking reports;
- query a forecast delivery;
- request review and comments;
- request approval;
- request for a specified repair or overhaul.
information on the progress of a task in the change development plan
proposed improvements the support solution definition or the PIF
NOTE
Such suggestions can include a change request or proposed alteration to the information
management rules.
quantifiable parameter used to define an aspect of support system performance
requests to stakeholder seeking clarification of required support characteristics
requirements for support activity, linked to the source from which they arose
NOTE
Such drivers include requirements for the development of task specifications to address:
- predicted product failure or degradation;
- safety, legal or environmental concerns;
- operational or readiness related tasks to be addressed by the support solution definition;
- tasks to collect the information needed to assess support performance.
physical item required to sustain product capability
NOTE
In this activity model fixed support infrastructure is treated as a mechanism that
is separate from the concept of support element. Within the ARM of this part of ISO
10303, support elements and infrastructure are both represented as resource items.
Support elements include:
- repair parts, which become part of the equipment when used and can be expendable or
repairable when replaced;
- consumable items, such as oil, which are consumed by the equipment in the course of
delivering its designed capability;
- tools, diagnostic and test equipment used to undertake support tasks;
- trained people.
observations on the condition, measured property or status of a support element that
has been, or is being used, as a resource for a task
NOTE
Possible states of a support element include:
- consumed;
- in-use;
- available to re-locate.
target of goal to be met by the support engineering programme
NOTE
Objectives may be communicated as a structured requirement statement.
identification, timing and sequencing of the activities and resources required to
develop a support solution definition that meets the support engineering objectives
and the support solution requirement, within the constraints specified by life cycle
and change directives
NOTE
This schedule includes:
- a plan of activities and resource schedule for the work required to develop and monitor
the performance of one or more support solutions;
- task specifications and other documents related to the schedule specifying the policies
and processes to be used in conducting such activities.
observation on the condition or usage of a product receiving support and on the execution
of support activities
NOTE
Support feedback is generated when tasks are performed on a product needing support.
It includes information on:
- the operation, usage and location of the product or support element receiving support;
- the current configuration of the product or support element;
- the condition of the product or support element receiving support, before, during
or after the support activity, recorded as properties, states or observations;
- the progress and status of work;
- the resources used to perform work;
- issues arising from work done, including proposals for change to the product or support
solution.
possible means to improve the performance of a support solution perhaps warranting
investigation as part of the support engineering programme
information models, reference data and rules that specify for the PIF how support
information shall be collected and stored to achieve efficient management of support
delivery
NOTE
Requirements to capture specific information may be included in task procedures. This
activity model assumes that:
- the support information management rules include the use of this part of ISO 10303
to structure the APSI and the collection of feedback as related information;
- the support information management rules apply to all elements of the PIF and its
support system;
- appropriate interfaces and translators are provided to interpret non-compliant information,
such as that held in existing information technology systems, into a form that complies
with these rules.
fixed physical assets required to provide support
NOTE
Fixed infrastructure within a support system, such as docks, workshops, runways, or
test beds, is treated in this activity model as a tunnelled mechanism to relevant
activities. Mobile support elements, such as people, parts, tools, and mobile support
equipment, are treated as an input or resource to the relevant activity. The ARM in
this part of ISO 10303 treats both of the above as resource items. Support schedules
are assumed to address all required resources.
request for action to resolve, or an expression of concern about, a problem arising
from working on a product needing support
NOTE
This may include requests to modify the product or support solution definition.
ability of one or more support organizations at a given location, to undertake classes
of tasks within a support solution definition
request for clarification of a support metric proposed by a stakeholder
report to the life cycle owner advising that it is either not possible or perhaps
not feasible to satisfy one or more support objectives within a support solution definition
identification and description of an actual opportunity, or a type of opportunity,
when work could be performed on a product needing support
objectives applicable to a specific support opportunity
identification of the tasks required to support a product within a specified deployment
environment, including the logic through which tasks are combined or otherwise related
NOTE
A support plan can include a presentation of a typical maintenance programme for a
product needing support. It can also specify non-maintenance tasks, such as activities
required to provide and prepare required resources. Some necessary tasks can never
be implemented if the conditions under which they would fall due fail to arise. This
can include a task to correct a rare fault state.
possible support plan, corresponding to a specific support policy
statement defining the approach to be taken when developing a support solution definition
for a specific context
NOTE
This could include a requirement to apply a reliability centred maintenance approach.
forecast of the support system performance to be expected when applying a support
solution definition in the context of a predicted operating or usage schedule and
support provider performance
NOTE
This may include predictions on resource consumption, and hence on provisioning requirements.
The prediction of some metrics may require assumptions to be made about resource availability
and delay times.
identified needs to change programme objectives, strategies or plans
systematic plan or arrangement for performing one or more support tasks
NOTE
The status of the schedule may change as it develops. The support schedule may include
a maintenance schedule defining work to be performed on the product needing support.
A support schedule may also define tasks applicable to support elements or required
resources such as the calibration of a test instrument.
work required to support a group of products within a deployment environment
NOTE
The support solution may include:
- identification of the deployment environment and support solution requirements for
which the support solution was designed;
- a listing of relevant support drivers;
- a support plan, that identifies necessary tasks to respond to these support drivers,
and specifies the conditions under which each task falls due;
- justification for the above;
- task procedures for necessary tasks;
- identification and quantification of resources needed to achieve necessary tasks,
including types of person with skill level;
- resource models for necessary tasks;
- product definition data for required resource items.
set of requirements that shall be addressed during the development of a support solution
definition in the context of a deployment environment
NOTE
The requirement may include specified performance metrics for the support solution,
with threshold or other tolerance values, defined in terms of agreed support characteristics.
confirmation that the support system is in place and ready to accept products needing
support
anomaly between a realized activity and its related task specification
NOTE
Anomalies may occur in the task instructions or the resources used and may lead to
issues or changes affecting the product or support solution definition.
information on the state of a current or completed activity, including reports of
completion of individual task steps
realized product that is available to the life cycle owner for operational use
hierarchical decomposition of the system elements within a product
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.
information, in any form, derived from observation of a realized activity including
progress, findings or resource use, prior to the capture of this information in the
format required by the information management rules
information of previous work done on a product needing, or receiving, support derived
from support feedback records
logical sequence of the intended activities, reflecting the constraints that apply
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.
information on the progress and status of a realized activity, including resource
use
NOTE
This may include information on the person performing the task, task steps completed,
man hours used, start time, elapsed time, spares, tools or consumables used.
algorithm or formula for calculating the likely task duration and resource use when
the task is executed
NOTE
Human resources are included so that a task resource model could predict the time
required to perform a task by staff with specified skill levels.
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.
activity required to establish the configuration or condition of a product prior to
receiving support
relationship between a necessary task and the product element, or elements to which
it applies
activity to be included in the work schedule for a given support opportunity
conditions that require a task to be done, in the context of its assignment to a specific
product element within a support solution definition
responses to transaction requests, providing details of price, availability, delivery
or forecast availability of requested resources
request for the provision of one or more required resources at a specified location
and date, or hastening a previous transaction request
NOTE
Transaction requests arise from the need to supply resources to support work at a
specific support opportunity, or to position resources with a support system.
activity that the assured support solution definition declares to be necessary based
on evaluation of the task trigger condition
notification of a problem identified during support solution development or use and
that can not be resolved without breaching support solution requirements or constraints
support driver for which no effective response can be found
NOTE
Unresolved support drivers can arise because support task opportunities are not technically
feasible or economically viable within the support engineering programme constraints
and the support solution requirement.
confirmed requirement for configuration change action
NOTE
This may include an identifier, a name, a classification, the reason for change and
a sufficient description to permit impact assessment and may lead to one or more proposed
solutions.
departure from the design intent as specified by the APSI
NOTE
Design intent may apply to the support system and to the manufacturing system as well
as to the product itself. Acceptance of a variance does not change the PIF baseline.
Different organizations use one or more words to describe departures from design baseline.
Variance can include departures described by terms such as:
- waiver;
- concession;
- non-conformance;
- production permit;
- acceptable fault;
- acceptable limitation.
information on the progress of activities in relation to a support schedule
NOTE
This information on status is transient and will change as the work progresses.
hierarchical decomposition of the zonal elements within a product
NOTE
The zonal breakdown elements can require support.