Activity A254: Analyze assessment data
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.
Activity A2423: Assemble pif task set
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.
Activity A114: Assess audit feedback
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.
Activity A1112: Assess issue
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.
Activity A11331: Assess solution risk
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
Activity A11336: Authorize change
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.
Activity A33: Certify support system
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.
Activity A11333: Classify solution
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.
Activity A4123: Confirm task completion
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
Activity : Define pif boundary
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
Activity A2224: Define potential faults
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).
Activity : Define product groups
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.
Activity A2323: Define support metric
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.
Activity A2431: Define support policy
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
Activity A243232: Define task trigger
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.
Activity A4421: Determine exception
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.
Activity : Develop physical breakdown
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.
Activity : Develop zonal breakdown
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.
Activity A41122: Establish task logic
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.
Activity A43: Execute authorized task
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
Activity A11312: Identify affected item
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.
Activity : Identify element
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.
Activity A2421: Identify potential task
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.
Activity A24222: Identify task resource
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.
Activity A4121: Manage progress
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.
Activity A1111: Register issue
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.
Activity A4124: Release product for use
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.
Activity A4122: Release support task
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
Activity A41124: Schedule activities
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
Activity A24322: Select necessary tasks
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
Activity A4113: Select support provider
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.
On diagrams: A13 A134
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.
On diagrams: A11
proposal for correcting the APSI to reflect findings from verification or audit activities
On diagrams: A1 A12 A121 A13 A132 A2 A21 A22
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.
On diagrams: A1 A12 A122 A13
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.
On diagrams: A0 A1 A13 A2 A24 A242 A243 A2432
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.
On diagrams: A1131
item affected by relevant solution
On diagrams: A232
support need accepted as suitable for inclusion in a support solution requirement
On diagrams: A-0 A0 A2 A21 A212 A23 A231 A232
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
On diagrams: A25
issue from analysis of assessment results and perhaps requiring change to the assessment strategy
On diagrams: A2 A25
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.
On diagrams: A25
strategy for assessing and validating the support solution definition, and the support engineering programme, against agreed objectives and metrics
On diagrams: A25
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.
On diagrams: A0 A4 A41 A411 A4112 A41121
support solution definition that is authorized for use in providing support or disposal to one or more product or support element
On diagrams: A11 A111
issue arising from configuration audit and verification feedback
On diagrams: A11 A1132
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.
On diagrams: A4 A41 A412 A44 A442
task on which work may begin
On diagrams: A113 A1133
information required to evaluate the potential cost, risks and benefits of any element of a proposed change
On diagrams: A1132
plan that identifies and schedules the tasks required to develop a change
On diagrams: A1132
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.
On diagrams: A1133
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
On diagrams: A113 A1133
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.
On diagrams: A112
priority that has been assigned in accordance with information management rules or local business rules to enable adequate subsequent processing
On diagrams: A1133
risk relating to a potential change
On diagrams: A113 A1132 A1133
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.
On diagrams: A12 A121 A122 A1221
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.
On diagrams: A1133
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
On diagrams: A0 A3 A31
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.
On diagrams: A3 A31
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
On diagrams: A31
logical constraints and relationships applicable to intended commissioning activities
On diagrams: A0 A3 A31 A4 A41 A411 A4112 A41121 A412
schedule showing the intended timing and sequencing of intended commissioning tasks
NOTE    Commissioning tasks are those required to create the support system.
On diagrams: A41121
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.
On diagrams: A0 A3
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.
On diagrams: A3 A31
measures of performance applicable to the performance of commissioning tasks
On diagrams: A0 A2 A24 A242 A3 A31
request for the development of a task specification for a commissioning activity not included in the current PIF task set
On diagrams: A412
record of successful completion of a task required by a support schedule
On diagrams: A11 A111 A112
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.
On diagrams: A44
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.
On diagrams: A41121
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.
On diagrams: A1133
quantified change with life cycle costs incorporated
On diagrams: A113 A1132 A1133
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.
On diagrams: A122 A1221
set of product structure views and breakdowns that the life cycle owner has chosen to establish and maintain for the life of the PIF
On diagrams: A113 A1131
plan of the activities required to develop and evaluate a possible change
On diagrams: A-0 A0 A4
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.
On diagrams: A112
change opportunity or identified problem to which a change priority has been assigned
On diagrams: A1132
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.
On diagrams: A23 A231 A232
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.
On diagrams: A21 A212
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.
On diagrams: A212
aspects of the external environment that provide opportunities or pose risks to the successful provision of support
On diagrams: A-0 A0 A1 A11 A111 A113 A1132
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.
On diagrams: A23 A231 A232
requests for further information to assist conflict resolution between requirements
On diagrams: A0 A3 A31 A4 A41 A411 A4112
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.
On diagrams: A1221
hierarchical decomposition of the functions of a product
NOTE    The functional breakdown elements can require support.
On diagrams: A1221
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.
On diagrams: A121
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.
On diagrams: A1131
identification of a potential solution that may satisfy a valid need for change
On diagrams: A223
identification and description of an intended location or geographical area where support may be required or provided
On diagrams: A0 A2 A21
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.
On diagrams: A11 A112 A113 A1131
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.
On diagrams: A111
report on the potential impact of an issue providing an input to a decision on whether to proceed with a change
On diagrams: A1 A1132 A13 A134
plan defining the activities needed to realize a solution to a valid need for change
On diagrams: A25
request for a change to the assessment strategy, arising because available information collection mechanisms can not provide the required feedback
On diagrams: A41121
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.
On diagrams: A2 A23 A232 A25
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.
On diagrams: A13 A132
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.
On diagrams: A1 A13 A132
intended approach to managing information for a given product in focus
On diagrams: A132
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.
On diagrams: A1 A12 A121 A13 A132
specification of the information that shall be developed and maintained within the APSI for any PIF or support system element or class of elements
On diagrams: A134
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.
On diagrams: A-0
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.
On diagrams: A-0 A0 A4 A44 A442
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.
On diagrams: A1 A11 A111 A112 A13
minor corrections to the APSI that do not require formal change action, arising from assessment of issues, or from configuration audits
On diagrams: A22 A223
quantification and predicted availability of support resources at each support location of relevance to a product group
On diagrams: A121
product attributes that exist at a common boundary of two or more products to which reference needs to be made
On diagrams: A111
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.
On diagrams: A11 A111 A112
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.
On diagrams: A222
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.
On diagrams: A23 A231
set of stakeholders identified by life cycle directives
On diagrams: A223
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
On diagrams: A121
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.
On diagrams: A243 A2432 A24323
name and identifier of a task that is applicable to a given support solution definition
On diagrams: A1131
request for action to respond to issues revealed by an impact report relating to a proposed solution
On diagrams: A2 A24 A242 A2422 A25
identification of the information that needs to be collected to support assessment of support performance against the metrics specified by the support solution requirements
On diagrams: A21
request for change to a support objective that can not be met
On diagrams: A222
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
On diagrams: A-0 A0 A4 A44
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.
On diagrams: A41121
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.
On diagrams: A2 A21
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.
On diagrams: A1221
hierarchical decomposition of the physical elements within a product
On diagrams: A1132
schedule identifying the tasks required to validate, verify and audit a classified solution
On diagrams: A22 A222
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.
On diagrams: A113 A1131 A1132
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
On diagrams: A22 A223
identity, description, organisation, location, environment and capability of each potential support provider of relevance to a product group
On diagrams: A242 A2422
name, identifier and description of a possible support task
On diagrams: A2435
forecast loss of operational time due to support activities during the operating period in question
On diagrams: A2435
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
On diagrams: A2435
forecast of the resources needed to support a product during a specified period of operation
On diagrams: A-0 A0 A1 A12 A121 A122 A1221 A13
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.
On diagrams: A13 A134
potential APSI prior to authorization and release
On diagrams: A1 A12 A122 A1221
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.
On diagrams: A24
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
On diagrams: A22 A222
set of products that are operated by one or more customers and are to be addressed by a specific support solution definition
On diagrams: A22 A222
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.
On diagrams: A412
information of the product usage and condition over a period in the past, derived from support feedback records
On diagrams: A442
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.
On diagrams: A-0 A0 A4
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.
On diagrams: A412
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.
On diagrams: A412
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.
On diagrams: A4 A41 A412 A44
notification of the current state of a product receiving support, as confirmed by the authority controlling the work
On diagrams: A44
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.
On diagrams: A44
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.
On diagrams: A21
expression of need for a change of the support engineering programme
On diagrams: A113 A1132 A1133
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.
On diagrams: A232
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.
On diagrams: A24323
proposal to change the assignment of tasks to products, or the task trigger conditions, to achieve rationalization of work packages within the support plan
On diagrams: A23 A231 A232
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.
On diagrams: A1133
recommended solution to a valid need for change, after comparison of potential solution options
On diagrams: A111
work request or expression of concern that has been documented and identified
On diagrams: A1 A13 A134
notification of decision not to release product and support information as APSI
On diagrams: A11 A111
recorded issue that has been rejected following assessment, possibly including the reasons for rejection
On diagrams: A-0 A0 A1 A11 A113 A1133
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.
On diagrams: A11 A112
request for change that has not been accepted
On diagrams: A113 A1131 A1133
potential solution that has been rejected because it not an optimal response to a valid need for change
On diagrams: A1 A13
information that is related to the APSI but is not subject to configuration change management
NOTE    Such information includes feedback from operations and maintenance.
On diagrams: A134
information relating to the product that can be released as APSI, under the conditions specified by the information release plan
On diagrams: A243 A2432
support driver of relevance to a specific deployment environment and support concept
On diagrams: A1132
request to provide a price or cost impact statement against a statement of work
On diagrams: A1132
request for an assessment of the impact of a proposal to apply a change to specified products
On diagrams: A1 A12 A121 A122 A1221
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.
On diagrams: A11 A111
request for assessment of the potential impact of an issue perhaps leading to a valid need for change
On diagrams: A2 A21 A25
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.
On diagrams: A11 A112
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
On diagrams: A2 A23 A231
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
On diagrams: A41 A411 A4112 A412
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.
On diagrams: A113 A1131 A1132
request for impact assessment of potential design solutions that could satisfy a valid need for change
On diagrams: A243 A2432 A24323
request for a change to the support concept
On diagrams: A2422
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.
On diagrams: A24 A242 A2422 A243 A2432 A24323
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
On diagrams: A113 A1132 A1133
request for an update to an implementation plan, following authorization of a change
On diagrams: A2422
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.
On diagrams: A112
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.
On diagrams: A-0 A0 A2 A3 A31
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.
On diagrams: A112
invitation for action to better define a document problem
On diagrams: A4 A41 A411 A4112 A41121
identification of the resources needed to support scheduled work at one or more support opportunities
On diagrams: A122 A1221
set of product assembly or breakdown views that the life cycle owner requires to establish and maintain the PIF
On diagrams: A2435
tasks expected to be performed during the operating period of interest
On diagrams: A23 A232
information derived from the life cycle directives, expressed as a potential requirement for a support solution definition
On diagrams: A2 A23 A231
proposal for changes to the support solution requirements arising from monitoring support system performance
On diagrams: A132
need for a breakdown view that is necessary for life cycle support of the PIF
On diagrams: A2 A22 A223 A24 A242 A2422
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.
On diagrams: A2 A24 A242 A2422
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.
On diagrams: A22 A223
identification and description of the resource items expected to be available at each location to support a product group
On diagrams: A2 A22 A223 A24 A243 A2435
recommended holdings of resource items required to support a given support solution definition, or the set of support solutions definitions
On diagrams: A44
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.
On diagrams: A24
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
On diagrams: A31 A4112 A41121
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.
On diagrams: A31
activity required in the commissioning schedule to establish a viable support system, capable of applying a support solution definition
On diagrams: A411 A4112 A41121
organization, or organizations, selected to perform scheduled tasks
On diagrams: A113 A1131
definition of a potential solution plus recommendations for further work required to complete assessment of a potential solution
On diagrams: A-0 A0 A4
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.
On diagrams: A1132
information on the progress of a task in the change development plan
On diagrams: A442
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.
On diagrams: A232 A243 A2435
quantifiable parameter used to define an aspect of support system performance
On diagrams: A232
requests to stakeholder seeking clarification of required support characteristics
On diagrams: A24 A242 A2422 A243 A2432
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.
On diagrams: A-0 A0 A4
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.
On diagrams: A44
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.
On diagrams: A2 A21 A212 A23 A231 A232
target of goal to be met by the support engineering programme
NOTE    Objectives may be communicated as a structured requirement statement.
On diagrams: A2 A21 A22 A23 A231
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.
On diagrams: A0 A2 A21 A212 A25 A4 A41 A412 A44 A442
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.
On diagrams: A212
possible means to improve the performance of a support solution perhaps warranting investigation as part of the support engineering programme
On diagrams: A132
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.
On diagrams: A-0
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.
On diagrams: A44
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.
On diagrams: A223
ability of one or more support organizations at a given location, to undertake classes of tasks within a support solution definition
On diagrams: A232
request for clarification of a support metric proposed by a stakeholder
On diagrams: A2 A21
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
On diagrams: A22 A222 A411 A4112 A41121
identification and description of an actual opportunity, or a type of opportunity, when work could be performed on a product needing support
On diagrams: A411 A4112 A41121
objectives applicable to a specific support opportunity
On diagrams: A243 A2432 A24323
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.
On diagrams: A243 A2432 A24323 A2435
possible support plan, corresponding to a specific support policy
On diagrams: A243 A2432 A24323
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.
On diagrams: A21
identified needs to change programme objectives, strategies or plans
On diagrams: A4 A41 A411 A4112 A412
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.
On diagrams: A0 A1 A13 A2 A24 A243 A2435 A25
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.
On diagrams: A0 A3 A4 A41
confirmation that the support system is in place and ready to accept products needing support
On diagrams: A442
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.
On diagrams: A44
information on the state of a current or completed activity, including reports of completion of individual task steps
On diagrams: A-0 A0 A4
realized product that is available to the life cycle owner for operational use
On diagrams: A1221
hierarchical decomposition of the system elements within a product
On diagrams: A242 A2422
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.
On diagrams: A242 A2422
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.
On diagrams: A4 A44
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
On diagrams: A412
information of previous work done on a product needing, or receiving, support derived from support feedback records
On diagrams: A4112 A41121
logical sequence of the intended activities, reflecting the constraints that apply
On diagrams: A243
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.
On diagrams: A412
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.
On diagrams: A242 A2422
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.
On diagrams: A2422
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.
On diagrams: A41121
activity required to establish the configuration or condition of a product prior to receiving support
On diagrams: A24323
relationship between a necessary task and the product element, or elements to which it applies
On diagrams: A4112 A41121
activity to be included in the work schedule for a given support opportunity
On diagrams: A24323
conditions that require a task to be done, in the context of its assignment to a specific product element within a support solution definition
On diagrams: A-0 A0 A3 A31 A4 A41 A411 A4112
responses to transaction requests, providing details of price, availability, delivery or forecast availability of requested resources
On diagrams: A-0 A0 A3 A31 A4
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.
On diagrams: A41121
activity that the assured support solution definition declares to be necessary based on evaluation of the task trigger condition
On diagrams: A232
notification of a problem identified during support solution development or use and that can not be resolved without breaching support solution requirements or constraints
On diagrams: A24 A242
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.
On diagrams: A11 A112 A113 A1131
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.
On diagrams: A11 A111
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.
On diagrams: A4 A41 A411 A4112 A41121 A412 A44
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.
On diagrams: A1221
hierarchical decomposition of the zonal elements within a product
NOTE    The zonal breakdown elements can require support.