Common building blocks to create modular Application Protocols (AP) within ISO 10303.
See: (http://en.wikipedia.org/wiki/ISO_10303_Application_Modules)
An acceptance process to ensure that a released task has been completed in accordance with the maintenance plan.
The text of the actual security access restriction. In some cases, specific text is required by law.
U.S.A. DoD Access Restriction Codes:
2MAN - Two-person access material
CNWDI - Critical Nuclear Weapons Design Information
CRYPTO - Cryptographic information
FRD - Formerly Restricted Data
-NOFORN - Not releasable to foreign nationals
RD - Restricted Data
SAR - Special Access Required
SCI - Special Compartmented Information
WINTEL - Warning: Intelligence methods and sources disclosed
Normative Ref: DoD 5120.22-M, DoD 5200.1-R (U.S.A. DoD).
2549document-security-access-restriction-text DED0157, document-security-access-restriction-code DED0085.
An organisation that acquires or procures a system, software product or software service from a supplier.
The process of obtaining a system, software product, or software service.
Not recommended.
Action and Activity are synonyms in STEP. Activity is the preferred term at the business level.
An operation doing some type of work to produce some identified output.
An IDEF0 model that describes an application in terms of its processes and information flows.
An event which has occurred.
The STEP equivalent if event_as_realised.
A task on which work has started.
Note 1: The actual task may diverge from the task description.
Note 2: The equivalent STEP terms are Activity_as_realised (ARM) and Actual_action (AIM).
The total time the product instance is inoperable due to delays in maintenance that are attributable to administration and logistics (e.g. supply).
Configuration item, which is impacted by change.
An item affected by the identified solution.
An accepted and unambiguous statement of a support need suitable for inclusion in a support solution requirement.
The definition of terms and conditions under which a working relationship will be conducted.
Requirements that have been allocated for consideration during the design of a support solution.
Allocated requirements are typically a subset of the product requirement and may not take into full account of all applicable stakeholders.
Design change to a research, experimental or development product that fulfils the criteria of a modification.
Change to a Configuration Item (CI), which corrects errors in design records, makes minor manufacturing changes, introduces an agreed alternative item or brings design records in line with manufacturing practices.
Manage the documented configuration management issues, by analysis of the issues to determine whether there is a need for change action, the originator and sponsor make preliminary judgements to determine the processing method.
This process can be very simple and intuitive it often requires careful weighing of alternatives and cost benefit trade-offs. These preliminary judgements concern:
The reason for the requested change
The basic scope and description of the requested change
The definition of its impact
The desired effectivity
Its urgency and importance
The resolution or breaking up of something complex into its various simple elements. The exact determination of the elements or components of something complex. A statement of the result of such an operation.
An anomaly (n) is an undesirable state of the product.
Note 1: Anomalies includes
faults (n)
degradations (n)
Note 2: The need for a modification or upgrade is not treated by PLCS as an anomaly.
The root cause of an anomaly, traced back to something that can be rectified.
A bringing-forward of the performance of a scheduled maintenance activity.
Anticipations are the antithesis of extensions, such that they cause a scheduled task to be performed earlier than the scheduled requirement. Like extensions, anticipations are applied to actual product, not generic design. Anticipations must be authorised, but are not associated with a limitation. Records of anticipations and who authorised them must be kept.
An ISO 10303 STEP Application Protocol (ISO10303-239) supporting the Product Life Cycle Support.
Any condition or situation that may limit the scheduling, performance, and/or completion of a task. For example, this may be operational availability of the product-in-focus, special facility requirements that are only available at certain locations, special labour certification requirements, etc.
(1) Where a product is used (e.g., commercial systems, defense systems, and facilities).
(2) Where a system or process is executed within an enterprise (i.e. material handling, design development process, etc.
See: software environment
Common building blocks to create modular Application Protocols (AP) within ISO 10303.
See: (http://en.wikipedia.org/wiki/ISO_10303_Application_Modules)
Application Protocol - an implementable component of ISO 10303 STEP which specifies an information model to support a specific business domain.
Recognized sanction that a product or process is complete and suitable for use.
The action of approval.
A state signifying approval.
Information that has been approved and is the official (identified) version of the information until replaced by another approved version.
The disposition of one or more changes.
The assured set of information (APSI) needed to develop and deliver support for a specific product in focus, which is subject to configuration change management, plus related information generated by support activities or used to provide support.
The AP239 definition for Assured Product and Support Information corresponds to the EIA 649 term "product configuration information". It 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.
Related information may include any content. It includes records of the history of the usage and support of realized products, design and support analysis results and reasons why decisions were taken.
Examples:
Design and Failure Analysis records
Logistic Support Analyses
running hours
environment
operating profiles
test results
records of maintenance activities
resources used
faults found
Proposal for updates to the APSI reflecting findings from verification or audit activities.
Information that has been retained for historical purposes that can be retrieved and is usable over the time designated for retention
The number of a repairable product instances that is estimated to be delivered to a repair agency/contractor in a given period.
A middle item within a physical decomposition.
Has both parents and children.
Carry out a risk assessment against the change package and identify the most beneficial solution that meets the intent of the original change requirement with the lowest risk of failing the authorisation process.
The refinement of the preliminary assessment to determine all potential consequences of the change to enable decision making (disposition), the necessary co-ordination between and within the impacted areas of responsibility and to provide information for next sub processes.
The level of analysis required will be dependent upon the change but will need to take account of facilities, resources (jigs, tooling, people) and other approved changes.
The detailed activities involved in assessing the impact of a change shall lead to determination of:
Effects on the performance or physical characteristics and interfaces with other products
The design development and test effort involved
The modification required to be made to tooling, manufacturing, assembly, installation, and test
-The product documentation revision or replacement required.
Operating or maintenance instructions or training devices and training materials
The effect on delivered product (e.g. does it require recall, retrofit, replacement or no action)
-This information is essential to determine effectivity
Assess impact on operations reports items that are acceptable within the Support solution which impact normal product-in-focus operation or availability to the System Operator, or information of relevance to operators on the readiness of the support system and availability of support elements and services.
This may include information such as:
additional maintenance requirements
limitations on PIF performance within the Support Solution, for example:
cautions
limitations of speed/altitude or
environmental conditions to be avoided
information of relevance to operators on the readiness of the support system and availability of support elements and services
information on limitations on availability (time/plans etc)
any anticipated impact on operational plans from PIF condition, e.g.
requirement to do maintenance within specific time
inability to do maintenance before a certain time
finishing early
Assesses issues for relevance and need for further activity.
Produces a task for impact assessment, analyses subsequent impact reports and classifies the issues as:
Requiring change action
Rejected
-Variances that need to be recorded in the APSI
Updates to the information set which require no further action
Issue from analysis of assessment results, which may require change to the assessment strategy.
A report arising from assessment activities.
May include:
reports on the support system performance in relation to support objectives or metrics
recognized deficiencies or proposed improvement to the product or support solution
issues with the support solution requirement
The strategy for assessing and validating the support solution, and the support engineering program, against agreed objectives and metrics.
Issue that may require a change to the assessment strategy.
May 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
The reference to the person(s) to whom a job is allocated.
A task expected or required to be performed on a specific target , e.g. a product version.
The set of information, needed to develop and deliver support for a specific product-in-focus.
Assured Product and Support Information is subject to configuration management.
A support solution that is authorized for use in providing support or disposal to one or more product or support element.
Systematic, independent and documented process for obtaining evidence and evaluating it objectively to determine the extent to which audit criteria are fulfilled.
Person or organization requesting an audit.
Outcome of an audit decided by the audit team after consideration of all the audit findings.
Set of policies, procedures or requirements against which collected audit evidence is compared.
Organization being audited.
Records, verified statements of fact or other information relevant to the audit.
Audit evidence can be qualitative or quantitative.
Results of the evaluation of the collected audit evidence against audit criteria.
An issue arising from configuration audit and verification feedback.
Person qualified and competent to conduct audits.
Feedback from audit or verification tasks reporting the progress of work and audit or verification findings.
May include configuration records or reports of variance for realized products.
See: validation, verification and audit plans
Set of audits to be carried out during a planned time frame.
Extent and range of a given audit.
The scope may be expressed in terms of factors such as physical location, organizational units, activities and processes.
Requests for verification tasks.
One or more auditors conducting an audit, one of whom is appointed as leader.
Note 1 : The audit team may also include auditors-in-training and, where required, technical experts.
Note 2: Observers may accompany the audit team but do not act as part of it.
Review the total justified change package and make a decision in respect to the authority or rejection or deferment (customer disposition) of the change.
If authorised to proceed a Change order for implementation will be issued. If the change is considered non-effective it will be rejected either on price or technicalities. On either rejection a further review can be initiated.
Authorise maintenance plan is the approval process for obtaining maintenance plan approvals from personnel with maintenance plan approval authority. The authorised maintenance plan ensures that the draft plan has addressed all appropriate issues.
A task on which work may begin.
A measure of the degree to which an product instance is in an operable and committable state at the start of a mission when the mission is called for at an unknown (random) time.
The lowest element in any given physical assembly tree from a specified viewpoint.
Has parents, but no children.
Information required to evaluate the potential cost, risks and benefits of any element of a proposed change.
A Business Object is a description in business terms of a concept required for data exchange in a given business domain, coupled with a mapping to relevant PLCS entities. A Business Object is defined in the context of a DEX.
A Business RDL is a Reference Data Library that specializes the OASIS RDL further in order to achieve semantic precision in a specific business context. A Business RDL is a Reference Data Library that specializes the OASIS RDL further in order to achieve semantic precision in a specific Context.
A Business Template is a Template that represents a Business Object or part of a Business Object.
A description of how EXPRESS entities are used to represent a given concept (a specific "functionality" or "capability"). It provides guidance and rules on what Entities should be used to represent a given concept, how the entities should be related, and what Reference Data should be used. As well as general guidance, a set of Templates are documented within a Capability to provide precise specifications of which Entities should be instantiated to represent identified concepts.
Configuration Change Management
Configuration and Data Management
Plan that identifies and schedules the tasks required to develop a change.
A report on progress against the Change development plan.
A task requested in order to proceed with the development of a change.
Work orders and work requests that result from the configuration change management process.
Change directives serve as controls on the implementation or investigation of an identified change. Change directives may include: change orders, change tasks, change plans and change requests.
Business case for change, including assessment of cost, benefits and risks.
Acts a s a control when authorizing change.
Identification of configuration items affected by change or a group of changes and the relationships between such changes.
An authority to implement a change to a product and/or its support solution.
It defines the change and authorizes release of the update to the APSI which will define what work is to be done. It will also specify
why the change is being done
who is implementing the change
when the implementation is to occur
what requirements are for reporting progress and completion
Information defining the tasks required to implement a potential solution including the required time, resources and budget.
Includes:
Change development plans
Change implementation plans
Change validation verification and Audit plans
A priority, which has been assigned in accordance with information management (IM) rules (and local business rules) to enable adequate subsequent processing.
A proposal to change the configured state of two or more instances of product instance.
Risk register for change.
The elements of the PIF, of its support system or related information (APSI), that are subject to configuration change.
A change may have many change targets.
A task related to the development, planning or implementation of a configuration change.
Note 1: Change tasks may be reflected in an associated change plan.
Note 2: Instructions to implement a change are conveyed by a change order.
Examples:
Work to define a change, develop solutions, assess impact, or develop a business case.
Work to conduct an audit or provide validation or verification.
Distinguishing feature.
There are various classes of characteristic, such as:
Physical, e.g. mechanical, electrical, chemical or biological characteristics
Sensory, e.g. related to smell, touch, taste, sight, hearing
Behavioral, e.g. courtesy, honesty, veracity
Temporal, e.g. punctuality, reliability, availability
Ergonomic, e.g. linguistic or physiological characteristic, or related to human safety
Functional, e.g. range of a plane
A 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.
The checklist may form part of the life cycle directives.
The selected solution which fulfils the life cycle owners change request.
Configuration Item
a set of individuals grouped together because they share a common set of properties.
a class can have subclasses
Mammals are a class of animals that are warm blooded.
Dogs are a class of animals that have four legs and a tail.
An element of the PIF or its support system which has been identified and assigned to one or more classes of element, plus any relationships between elements which need to be tracked for support purposes.
Unambiguous identification includes the assignment of a name (for use by humans) and an alphanumeric identifier (for use within computers), which are unique within a context.
The context for a name or identifier is the organization, which provides the name and id.
Elements may have more than one name/identifier assigned by different organizations.
The classification of an element may include a class which helps identify the Assured Product and Support Information that is required for this element type (e.g. this element is a ships system, therefore we will hold a functional performance statement, a system diagram, a set of system drawings, a test form, an electrical wiring diagram).
Relationships may include:
Element to Element views
Elements to Product views
Document to product structure
A potential solution to a valid need for change.
This includes 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.
Categorization of elements used to provide convenient reference in the business context.
It is assumed that the classification method will also assist in defining information needs.
Classification of elements may include:
-The selection of Configuration items and Configuration item interfaces
Differentiation by size/complexity e.g. major unit, minor unit, assembly, raw material etc
Differentiation by relation to types of data to be held. e.g those items that require load test
??major unit, minor unit and Configuration item interfaces are not defined??
Classifies the chosen solution with respect to the appropriate priority.
Configuration Management
Configuration Management Plan
The review, analysis, and processing of data generated for export and updating APSI and related information.
A CAGE (Commercial And Government Entity) Code is a five (5) position code that identifies
companies doing or wishing to do business with the Federal Government. The codes are
assigned by Defense Logistics Information Service (DLIS). The format of the code is
that the first and fifth position must be numeric. The second, third and fourth may
be any mixture of alpha/numeric excluding I and O. All positions are non-significant.
For details see: In PLCS it is used as a
Reference Data class as part of the identification of an Organization.
Reports on the progress of commissioning activities against the plan. Recommendations for change to the support solution, the product or the commissioning schedule, arising from commissioning experience.
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
An objective to be achieved by the commissioning activity. The objectives may address any phase of the commissioning process including acquisition, construction, testing or certification of support system elements.
The logical constraints and relationships applicable to intended commissioning activities.
A schedule showing the intended timing and sequencing of intended commissioning tasks.
Commissioning tasks are those required to create the support system.
Data on the progress, resource consumption and issues arising from performing commissioning tasks.
Information provided to identify trends or potential problems from applying a commissioning solution.
Metrics applicable to the performance of commissioning tasks.
Request for the development of a task specification for a commissioning activity not included in the current PIF task set.
Review the total change package and complete a justification for the implementation requirements with a recommended classification and priority.
Record of successful completion of a task required by a support schedule.
Part of a larger whole, any subdivision of interest.
Synonym to element.
Authorization to use or release a product that does not conform to specified requirements.
A concession is typically limited to the delivery of a product that has nonconforming characteristics within specified limits for an agreed time or quantity of product.
(1) The product attributes of an existing or planned product, or a combination of products.
(2) One of a series of sequentially created variations of a product.
???
Abbreviation: CDM
The CM function that validates a requirement has been fulfilled.
Examples:
Examination to determine whether a product conforms to its product definition information
Reviewing procedures, processes, and systems for repeatability
Assessing performance requirements against observed and measured data
The attributes of a product at a point in time, which serves as reference for activities throughout its life cycle.
A change to a product and its product configuration information.
The configuration management activity that ensures that changes to product configuration information are properly identified, recorded, evaluated, approved, incorporated, and verified.
The configuration change management activity applies to:
Applicable configurations of a product
Supporting and interfacing products
Associated product and support configuration information
Abbreviation: CCM
The configuration management activity, which selects, describes and organizes product attributes and assigns and applies identifiers to a product, its components, and its configuration information.
Information to identify and define a product's attributes.
Includes but is not limited to
specifications
drawings
support information
Item designated for Configuration Management (CM).
Abbreviation: CI
The activity that establishes and maintains consistency of a product with its requirements and configuration information throughout its life cycle.
Configuration management consists of the five interrelated activities:
Configuration management and planning
Configuration identification
Configuration change management
Configuration status accounting
Configuration audit
Abbreviation: CM
The document that describes the scope of configuration management (CM), the CM organization, and the CM activities for a product and its support throughout the life cycle of that product.
The CMP provides details of the processes, schedules and associated toolset for performing Configuration Management including resources and skills.
Development of the CMP is not addressed within this AAM but is an integral part of the CM process defined by ISO 10007.
Abbreviation: CMP
A record of the configuration of a realized product.
Configuration status record 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.
The configuration management activity that manages the capture, storage, retrieval and access of product configuration information necessary to account for the configuration of a product.
Abbreviation: CSA
The output of the Configuration Status Accounting (CSA) activity.
The configuration status record (CSR) is the source of configuration information to support through life program activities including program management, system engineering, manufacturing, software development, logistic support, maintenance and modification. The CSR contains the status information of the Configuration Item (CI) at any stage in its life cycle, including where appropriate, the current version of each CI.
Abbreviation: CSR
The configuration change management activity, which verifies that the product has achieved its requirements and is accurately documented.
Fulfillment of a requirement.
This definition is consistent with ISO/IEC Guide 2 but differs from it in phrasing to fit into the ISO 9000 concepts.
An activity that needs to be included in a schedule as a consequence of another task.
May include additional tasks required by the proposed activity logic or by resource preparation requirements (e.g. set up and calibrate a test rig).
The act of changing the configured state of two or more instances of product instance
The merging of solution(s) with the/their impact reports for risk assessment.
Specialists include: engineering (Design/System/Support), supply chain, production, manufacturing, commercial.
(1) A restriction, limit, or regulation imposed on a product, project, or process.
(2) A type of requirement or design feature that cannot be traded off.
Anything consumed by operation of a product or a support activity.
e.g. fluids, lubricants in general, paints, adhesives, fuel, oil, chemicals, cleaners, solvents, abrasives, metals, fabrics.
The portion of product instance life accrued through being used.
The purchase and use of product instance.
A "context" is a domain in which a specialized vocabulary is employed. This may be an individual organization, a larger business community, or a particular project (or initiative). A number of DEXs and Templates are identified within a given Context and each DEX is defined using the specialized vocabulary and terminology.
See Concise Oxford English Dictionary
The offer that is generated subsequent to the authorisation of the change proposal.
Contractual requirements are the obligations that have to be fulfilled based on the contract.
Part of life cycle directives.
An acceptance process to ensure that a released task has been completed in accordance with the maintenance plan??
Action taken to eliminate a detected nonconformity.
Note 1: A correction may or may not be made in conjunction with a corrective action.
Note 2 : A correction may involve repair, rework or regrade.
Action taken to eliminate the cause of a detected nonconformity or other undesirable situation.
Note 1: Corrective action is taken to prevent recurrence whereas preventive action is taken to prevent occurrence.
Note 2: There is a distinction between correction and corrective action.
Quantified change with life cycle costs incorporated.
The total monetary cost to rectify the failure/defect.
Ensures that "release dependencies" are collected together in a structured format.
This ensures that certain product information is released together with (before/after) other product information and only to approved recipients. In an electronic CM model this latter will simply consist of pointers to the modified information sets.
Create the maintenance plan is the activity that integrates maintenance activity objectives (maintenance tasks) to be accomplished and time phasing for all levels of maintenance, including both preventive and corrective maintenance. It includes modelling for matching maintenance tasks with facility capabilities and availability to produce an authorised maintenance plan.
Maintenance plans and schedules have specific planning horizons such as annual, quarterly, monthly, weekly, and daily. Each schedule is a subset of the larger time period covered under the plan. Maintenance tasks are scheduled against a specific products/equipment in focus. The maintenance schedule contains all scheduled jobs and tasks, beginning/completion trigger event such as time, cycles, hours, lists specific resources and locations as to where the work package, job, or task will be accomplished.
The collection of ideas and comments generated by support personnel to identify opportunities for making the support solution's application efficiency and effectiveness better.
Configuration Status Accounting
Configuration Status Record.
The configured state of two or more instances of product instance at a given point in time.
Organization or person that receives a product.
Examples:
Consumer
Client
End-user
Retailer
Beneficiary
Purchaser
A supplier can be internal or external to the customer's organization.
A lifecycle directive confirming the approval, deferment or rejection of a change by a customer or other external authority.
The disposition may specify:
Planned
In work
Complete
Rejected
Approved
Deferred
Pending
Concurrent Versions System, a revision control system, popular for open source and commercial software development.
Damage is an external event that causes new product anomalies.
Data Exchange Specification - a subset of the ISO 10303-239 PLCS information model, designed to support data exchange for specific activities, providing guidance and rules for how to use and combine the selected entities and external Reference Data in that exchange. Each DEX includes a complete EXPRESS schema. This is a subset of the ISO 10303-239 schema with a derived XML Schema. Both can be used to define and validate a data exchange file. A DEX defined and managed by the OASIS PLCS TC may be referred to as a "PLCS DEX", as opposed to a "Business DEX".
A deviation from the design.
A defect may result in a degradation in the ability to perform an intended function and may be an incipient failure.
Definition?
Abbreviation: DRACAS
The method of delaying the work required to fix a reported fault.
Deferments are applied to actual product instance. They enable product instance that has known faults to continue to be used (possibly with limitations). Deferments have to be authorised and can have limitations associated with them (these may be role based or stress related). Additionally, an authoriser may only be empowered to authorise certain classifications of deferment. It is not usual to fit product instance to which deferments apply to parent product instances. An product instance with a deferred fault will continue in use whilst it is fitted, but will be classified as unserviceable once removed from the end product instance. Records of deferments and who authorised them must be kept.
A set of product structure views/breakdowns that the life cycle owner has chosen to establish and maintain for the life of the PIF.
Produce the Information management strategy requirements.
The requirements are usually derived from individual customer/companies policies/standards (e.g. IT/B2B/CM/QA etc) and the customers contractual requirements (EEG CMP/CO) create the outline Information Management (IM) model. The process of defining the structure and organisation of data in an media for a digitally driven virtual enterprise. An information model is produced which defines how the product data will be held. It may describe a set of tools, but preferably it will specify an open data architecture. Define the associations and relationships between data and documents and how that information is represented in different views. (EIA 836 (2549)).
The production of the guidelines and constraints pertaining to the creation, use, maintenance and disposal of information by life cycle users.
This defines the methodology and creates a structured set of IM rules.This defines the methodology and creates a structured set of IM rules.
The production of the configuration information and associated support information that is required to enable the support solution to be implemented and maintained throughout the life of the product.
A configuration element could have a large quantity of information associated with it. Examples to consider when defining what is required are: design data, configuration item interface specifications, interface control documentation, analysis of support requirements, support solution and technical publications.
Establishment of the scope and nature of interfaces between elements.
The nature of interfaces depends on the nature of the elements themselves They 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 process enables the check list, used when changes to elements are proposed, to be developed ensuring that all consequences of proposed changes are considered and it also provides a starting point for the development of product structures.
Establish necessary links between different product structure breakdowns and networks.
Examples: conceptual, design, functional, physical, spatial, zonal.
The identification of the subset of support engineering approved maintenance tasks developed in the support solution that are required for submittal to develop the maintenance plan. Maintenance objectives identify what maintenance tasks must be accomplished for all levels of maintenance, including both preventive and corrective maintenance. Maintenance activity objects are maintenance tasks required for various scenarios and environments.
Provide the top-level description of the scope of the PIF, in accordance with the life cycle directives and the customer requirements. Ith will also define the depth to which the requirement needs to be decomposed in order to provide the appropriate level of support.
The product boundary is defined (AAM CM A1211). It identifies the classified elements and their relationships to other elements and is used as an initial identifying process when change is being explored.
Definition of the scope and depth of configuration breakdown is required will be an iterative process. The latter being largely driven by the output of the support engineering process.
The product structure fundamentals are established. These are considered as "essentials" for its construction and maintenance.
The requirement is for a single product structure that provides a controlled and complete product definition for the PIF across the product life cycle. The product structure view requirements are established within Information Management - Identify product structure views (AAM CM A1322). In addition AAM CM A13 produces the Information management rules that act as a constraint on this process.
A degradation is an anomaly that does not cause loss of a required function.
The formal handing over of property.
Collective term used to describe the availability performance and its influencing factors
reliability performance, maintainability performance, and maintenance support performance [IEC 60050 (191)].
Note 1: Dependability is used only for general descriptions in non-quantitative terms.
Note 2: Dependability is a time-related quality characteristic.
A subset of the product-in-focus, operating environment and support environment for which a support solution is required
It may be necessary to define several deployment environments for a given PIF, each giving rise to a different support solution.
The deployment environment may include details of:
the number of products to be deployed and their groupings
the duration of deployments
the intended frequencies, duration (time and distance) , profile and nature of operating periods and support opportunities
the anticipated physical and climatic environments in which usage or support is expected to occur
the assumed capability of each identified support location in terms of facilities, infrastructure and personnel
assumptions relating to the availability of specific and critical support facilities, capabilities or organizations
local commercial, social or political constraints affecting the provision of support
The role of a person or organisation responsible for the
design
approval of the design
changes to the design
of a product.
Information resulting from translating requirements for a product into a complete description of the product.
See: product definition information
Formal, documented management process that is used to subject a design to a systematic critical study. Its purpose is to establish that the design satisfies the specified requirement.
The method by which a failure/defect is detected.
An event that triggers one or more tasks.
Comparison of actual task results done against predicted task results to identify discrepancies and anomalies for feedback to support engineering (SE). This also includes observations of product conditions outside the support solution requiring analysis and direction by support engineering.
??
The refinement of the preliminary assessment to determine all potential consequences of the change to enable decision making (disposition), the necessary co-ordination between the impacted areas of responsibility to enable the effectivity to be determined.
The level of analysis required will be dependant upon the nature of the change taking into account effects on Support engineering and Resource management and impacts on other approved changes.
Development of the Information management strategy requirements and the customers contractual requirements to create the outline Information Management (IM) model.
The information strategy is usually derived from individual customer/companies policies/standards and the customers contractual requirements to create the outline Information Management (IM) model.
The production of a conceptual data model to define the entity, attributes and relationships required by the product, it establishes the "required to be captured" information methodology in which the relevant information can be obtained and subsequently managed in a consistent format .
Plan of the activities required to develop and evaluate a possible change.
Production of solutions that may meet the change requirement.
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.
Assembly of physical and functional aspects of the PIF to form a well-structured skeleton.
The physical/functional aspects will contain a number of classified elements and relationships that are linked together in a hierarchical fashion. Some elements will be unique to the functional element which defines the operation of the PIF, and some unique to the physical element to support the representation of the build of the PIF. The structure includes parent-child relationships, aspects, networks and classification of products.
The actual data (i.e. a package of data that is exchanged, or a data exchange file) that is exchanged in accordance with a DEX information model.
DEXlib is the XML environment created for the development of PLCS OASIS DEXs and components. It is also used for the development of Business DEXs and components. DEXlib has been deprecated and development is now based on
Authority to perform a specified activity.
A directive may be communicated by an approved work order, responding to a work request.
Recognised sanction that a product or process is neither complete nor suitable for its use.
A replacement part that is disposed after removal from a product needing support in accordance with the support solution.
A replacement part not technically or economically feasible to repair related to the product-in-focus.
Action to terminate ownership.
An element of the product, or its support system, leaving the control of the life cycle owner.
Disposed elements may include:
waste products arising from support tasks (e.g. dirty oil)
resources no longer required for planned tasks
elements removed from the product
a product retiring from use
Information and its support medium.
Examples:
Record
Specification
Drawing
Report
Standard
Note 1: The medium may be paper, magnetic, electronic or optical computer disc, photograph or master sample, or a combination thereof.
Note 2: A set of documents, for example specifications and/or records, is frequently called 'documentation'.
Note 3 : Some requirements relate to all types of documents, however there may be different requirements for specifications and records.
The conceptual visualisation and complete documentation of a change.
This results in a "valid need for change" which enables the change to be effectively processed and helps to ensure that the associated configuration documentation provides a comprehensive historical record of the full lifecycle of the change.
A change opportunity or identified problem complete with the change priority.
Defect Reporting And Corrective Actions System
An effect is a predicted property, or behaviour, of a product, arising from one or more anomalies.
The fault (or failure) analysis process links effects to anomalies. The effect may have different probabilities of occurrence in different mission phases/plant states
Measure of the extent to which planned activities are realized and planned results achieved.
A designation defining the product range (e.g. serial, lot numbers, model, dates) or event at which a change to a specific product is to be (or has been) effected, or to which a variance applies.
A definition of which realized products shall be affected by a change.
May define the "production break in" point or the applicability of modifications to realized product already built.
Relationship between the result achieved and the resources used.
The amount of time between two events (e.g. between starting a task execution and finishing a task execution).
Part of a larger whole, any subdivision of interest.
Synonym to component.
Identified interfaces between elements to which reference must be made.
A potential requirement on the design of the support solution, reflecting the desires and expectations of a recognized stakeholder.
Elicited support needs are derived from analyses of customer and stakeholder needs and priorities with associated rationale, including source documents or agreements.
Elicited support needs may include:
intended life time of product and support
intended duration of deployments
quantities of products to be supported
needs for standardization in order to interface effectively with other organizations, users or partners, to reduce needs for new or additional investments, or to comply with life cycle needs of the product and its support; information from development, production, use, support and disposal of similar products
experience from similar organizations, environments and scenarios
experience from use and support of the product since its introduction into service.
May use AP233.
The effects on the top level product instance (or end product instance) in which the product instance is a component when the failure mode occurs.
Top element in any physical assembly tree, or the object of the decomposition, from a specified viewpoint
End items have children, but no parents.
Synonym to top item.
One or more organizations with a set of goals and objectives to offer products and/or services.
An organization may be involved in several enterprises and an enterprise may involve on or more organizations.
A bounded engineered asset delivering functional capability.
Non-preferred word.
Synonym to product.
Provision of other identifiers.
Examples are: National/NATO Stock Number, Manufacturer's Part Number, Manufacturer Code (e.g. CAGE), Logistic Control Numbers [e.g. LCN, Alternative LCN (ALCN), End Item Acronym Code (EIAC)], Colloquial names and aliases. This activity will allow links to product information related to the element, which will be enabled when the product structure is populated.
The business solution is developed and the change approved in accordance with the Configuration management plan. This enables the change to be implemented and verified, resulting in the creation of the required Change orders.
The approval authority for a change can be delegated to different levels in the organisation, dependant 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. The most complex multi-level configuration change management is practised on projects in which authority for making change decisions is structured around tiered " Change boards". The change approval authorities span many contractor and customer organisations each with defined limited authority to approve changes to the portion of the "system" under their organisation. Those changes, which exceed the authority of lower level change approval authorities, are elevated to a higher level.
The cost of the change is evaluated by subjecting the most beneficial solution(s) to a commercial pricing exercise which creates a price that meets the implementation (effectivity) requirements.
This activity optimally sequences maintenance objectives to reflect successful accomplishment within the task constraints.
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.
The conceptual visualisation and preliminary assessment of the problem or change opportunity.
This includes documentation of the change opportunity or problem and the creation of a suitable description (AAM CM A1122) an analysis of the problem/opportunity and the reason for a possible change along with a statement of its impact sufficient for evaluation (AAM CM A1123), determination of the appropriate level of priority (AAM CM A1121) and the raising and the approval of a Valid need for change as an input to (AAM CM A113) - Evaluate and co-ordinate solution or variance.
Development of the valid need for change devising potential solutions to meet the need and selecting a solution.
The activities involved in developing, implementing and verifying the change solution(s) are planned (AAM CM A1132), the business case is developed and the solution authorised, deferred or rejected in sub-process (AAM CM A1133). Evaluate and co-ordinate is the process of reviewing the impact assessments, determining in detail impact of the change in respect to operation, support, schedule, effectivity and cost in order to approve or reject the proposal. Includes the process of grouping changes to make economical and/or convenience/opportunistic packages. Variances will be subject to this activity to establish effects on other CIs.
Considers the technical, support, schedule and cost impacts of a requested change before making a judgement as to whether the change should be approved for implementation and incorporation in the PIF and its documentation.
An opportunity to improve the performance of a support solution, which shall be addressed as part of the support engineering program.
Evaluated support improvement opportunity may be expressed as specified tasks or as work requests.
A systematic determination of the extent to which an entity meets its specified criteria.
The occurrence or existence, at a point in time, of something of interest.
A past event about which information may be held.
The rate for which a unit of monetary currency may be exchanged for a different monetary currency.
A replacement part for which no authorized inspection procedure exists.
!!Needs discussions within SSE!!
E.g. split pins, nuts, bolts, washers, circlips, cable ties that are generally used only once then discarded after removal.
The point in time at which the life of a product instance expires.
The STEP product data specification language. It consists of language elements that allow an unambiguous data definition and specification of constraints on the data defined. Defined in ISO 10303-11.
A graphical representation for a subset of the constructs in the EXPRESS language. Defined in Annex F of ISO 10303-11.
A postponement of the performance of a scheduled maintenance activity.
Extensions are applied to usage factor limits (e.g. Bay servicing), and do not affect accrued usage factor. An extension has to be authorised and can have limitations associated with it (these will usually be stress related). Additionally, an authorising authority may only be empowered to extend certain characteristics and only by a given percentage. Extensions apply to actual product instances, not to product designs.
Extensions do not transfer with sub assemblies. If a task that is due on a subassembly is extended, and the assembly is removed from the parent prior to the task being performed, then the extension is cancelled and if the subassembly is fitted to a new parent, the task must be performed at the original time, or re-extended. Records of extensions and who authorised them must be kept.
See: anticipation
Factors in the external environment that offers opportunities or pose risks to the successful provision of support.
The physical means or equipment for facilitating the performance of an action, e.g., buildings.
Synonym to support infrastructure.
Failure is termination of the ability of an item to perform a required function.
Note 1: Failure is
an event
a state
Note 2: After a failure a fault will exist for some period of time.
Note 3: Faults may exist without a failure having occurred (e.g. faults as built, maintenance errors, damage).
Note 4: A failure, or the existence of a fault, in one component may cause a failure, and hence a fault, in another.
Note 5: A failure may have probability of occurrence during a given mission..
Note 6: A fault may have a probability of existing during a mission.
A failure mode is an event (E.g. failure, damage), or sequence of events, through which a particular fault, or set of faults, may arise. .
Note 1: A failure mode may be compensated by operator action or design provision.
Note 2: A failure mode may have a probability of occurring, during a mission.
Note 3: A failure mode may only be relevant to certain plant states/mission phases.
Note 4: The same fault may result from different failure modes.
Note 5: In some other standards the term "failure mode" is used as a synonymy for fault.
Definition??
Abbreviation: FRACAS
A fault is an anomaly that causes loss of a required function.
The requirement for the function, and hence the failure condition, may vary with circumstances. The same anomaly, on the same product, could be classified as a fault under one circumstance (E.g. full power state) and as a degradation in another (half power state).
Feedback of information of relevance to product support.
Includes:
work requests or issues which 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 (see own definitions).
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.
Requests for further information to support conflict resolution between requirements.
The date when a support element is required for first operational use.
The first use date is used to establish the schedule of commissioning activities.
Failure Reporting And Corrective Actions System
A task, action, or activity performed to achieve a desired outcome.
Measurable performance parameters.
Functional attributes are expressed in terms of quantitative performance parameters such as:
range
speed
lethality
reliability
maintainability
safety
operating
logistics parameters
along with their respective tolerances.
The ability to fulfill the design intent.
The inability to perform an intended function (E.g. cannot provide motive power).
??
An alphanumeric identifier, which identifies a group of like units of the same product
(1) which are manufactured or assembled under uniform conditions and which are expected to function in a consistent manner (E.g. lot).
(2) used to designate a specific volumetric quantity (batch) of a material (usually a chemical mixture) created at the same time and expected to have properties similar to, but not necessarily the same as, other batches created at other times.
Document stating recommendations or suggestions.
Human Resource
human resource requirements
Requirements for the provision of human resources that are or may be needed to provide adequate support to the operational product-in-focus.
Abbreviation: HR requirements.
input, control, output and mechanism.
a functional modeling language.
An element of the PIF with an unambiguous identifier within the context of Product Life Cycle Support.
An element is any subdivision of the PIF, the Support system or related information to which consistent reference needs to be made. Certain elements will be selected as Configuration items.
Identification of a potential solution that may satisfy a valid need for change.
Identification and description of an intended location or geographical area where support may be required or provided.
Alphanumeric string assigned to the product for the purpose of identifying the product within a defined context.
Determination of those CIs that will be affected by the possible solutions.
The identification of change opportunity based on necessity, urgency or impact of the change, to enable various routes of processing.
Variations and variances will also be considered by the classification process. A change priority is determined in order to enable adequate subsequent processing. Typical ways of prioritising change are: Class 1, Class 2, Major, Minor.
Provide name, ID and owner for all elements of the product (of interest to support of the product) and of the support system.
Develop the means of organising the composition of the product.
The product structure is a representation of the breakdown hierarchy (product tree) from top down to the lowest level. Each level will be able to reference associated configuration documentation such as engineering models, bills of materials, specifications, software requirements, design documents, processes and operating procedures.
The fundamentals for a product structure are:
A product comprises a single set of elements, which can be parts, materials, and proprietary items.
Each product will have a unique product structure.
Elements within a product structure will have both a "private view" and "public view" information linked to them which will have to be managed. Functional view (depicts parent/child relationships and is constructed to support the definition of the PIF in terms of functionality, certification,qualification, operation, maintenance and support in a auditable manner). Physical view (a hierarchical structure, depicting parent/child relationships and constructed to represent how the build of the PIF will be achieved and the impact of any change to the PIF).
Aspects can be viewed as "As Designed", "As Planned", "As Built", "As Maintained". As Designed view holds specifications, forecasts, plans etc against high level definitions which are expanded as the PIF progresses through its life cycle. The view is initially completed when it contains how the product operates. It is maintained throughout its life cycle to reflect authorised changes. As Planned view is populated with lower level elements defining the way the PIF is to be assembled. As Built view is how the PIF as been built up to the point of delivery. As Maintained view is populated with the support information from the point of delivery until disposal. It will contain all change information.
Information Management
Consequences that a potential solution has on other changes that are proceeding in parallel
Example: Solution 3 to change 5 requires redesign of the interface with Item YYY, which is also subject to Change 8. Change 7 to item XXX must not be implemented unless Change 6 has already been installed.
A report on the potential impact of an issue providing an input to a decision on whether to proceed with a change.
Information Management Plan
Describes the resolution applied to the related request.
An implementation directive may include description of tasks, manpower, facilities, parts, kits, support equipment and money needed to apply the actual resolution. It also identifies the organization responsible for applying the actual resolution and the timetable for completion.
A plan for implementing a solution to a valid need for change.
Execution of the release process in accordance with a change order.
The physical performance of released task(s) on the product-in-focus. Implement task includes the complete work process from start to finish, associated data reporting, and return of support element equipment/material resources to their proper location.
Information Management Rules
Request for a change to the assessment strategy, because of available information collection mechanisms cannot provide the required feedback.
Incorporate the results of the assessment reports into the change.
This process can initiate a reassessment as a result of analysing these co-ordinated responses. The output "Potential solutions" must include the justification for the change solutions and the resulting impacts of each solution as well as a reconciliation of requirements and the various impact reports. Justification and reconciliation must be carried out for each of the potential solutions proposed.
an instance that is a member of a class
Fido is a Dog.
The expected configuration and condition of an individual product at the start of the support opportunity.
Arrow Note: This information may be available from the APSI and related information.
Requirement for an activity to collect assessment information.
Requirement may be met by:
adding a task step to an existing task required for other reasons (E.g. to record time taken to perform a specified task)
or by adding information collection tasks to the support engineering program, or the support solution (E.g. conduct a maintenance evaluation of a new product, measure and record hours run)
or by adding embedded support capability in the product (E.g. health monitoring capabilities)
Information originating either inside or outside the PLCS model that feeds PLCS activities.
Note 1: Information feedback includes:
request for identification (ID) of product and support elements
impact assessment reports
issues
configuration status reports
accepted price offers
accepted solutions
data received as a result of operating, maintaining and upgrading the product
Note 2: In combination with other inputs to the CM process, information feedback may, after analysis, prompt the need for a change. It will also assist the process of developing a change from a valid need for change.
Information that has failed the approval process and requires reassessment.
Information on the identity, description or in-service performance of other products or support systems of relevance to the PIF.
This information could be supplied in AP239 format, but may only be available on paper or in other non-STEP compliant data formats.
A plan for developing, collecting and releasing the information required for product support.
Note: This includes a control to ensure that the APSI is released in a timely and appropriate manner.
Abbreviation: IM Plan
The set of rules and interpretation guidance provided to achieve effective information sharing and exchange across the PIF scope.
The information Management rules 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.
Specification of the information to be acquired or disposed of with the product or support elements as they enter or leave the information management domain defined by the PIF scope.
AP239 (PLCS) is part of the information rules.
Instructions to record specific information during support activities may be included within task specifications.
Abbreviation: IM Rules
The intended approach to managing information for a given product in focus.
A model to define how product and support information shall be structured.
The information model is one component of the Information Management Rules.
Specification of the information that shall be developed and maintained within the APSI for any PIF or support system element or class of elements.
A schedule defining the timing for the release of assured information.
The information release plan may specify who needs what information, when, where, in what formats and what media.
An IT capability able to provide timely, convenient and effective access to all participants in support activities for entering and receiving information.
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.
The two components which provide this capability are the information technology service or infrastructure (this arrow) and the information management rules.
Information the system operator required regarding the condition of the supported product.
This information includes:
that arising from the maintenance of a realized product and affecting subsequent operation (for example, 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 availability
any anticipated impact on operational plans from product-in-focus condition (for example, requirement to do maintenance within specific time, inability to do maintenance before a certain time, finishing early)
responses to operator requests on operational or support problems.
Minor corrections to the APSI, arising from assessment of issues, or from configuration audits, that does not require formal change action.
System of permanent facilities and equipment of an organization.
??See OED, c.f.??
CIs that will be affected by the proposed solutions need the impact of the change assessed. This activity has two outputs:
Request for solution and impact assessment(s)
and
Need for revised solutions.
Conformity evaluation by observation and judgment accompanied as appropriate by measurement, testing or gauging. [ISO/IEC Guide 2]
[ISO/IEC Guide 2]
The act of installing an instance of a child product instance within a parent product instance.
A product which is capable of being exchanged with another product which has equivalent or similar product attributes without alteration of the products themselves, or of adjoining products, except for adjustment.
The interchangeable product is capable of being exchanged for the other product without selection for fit or performance, and without alteration of the products themselves or of adjoining products, except for adjustment.
Person or group having an interest in the performance or success of an organization.
Examples: Customers, owners, employees, suppliers, bankers, unions, partners or society.
A group may comprise an organization, a part thereof, or more than one organization.
The product attributes that exist at a common boundary of two or more products.
The process of identifying, recording, and managing interfaces.
The record of an identified interface.
A period between events.
An interval may be measured by elapsed time from a start point, or by a number of events (e.g. landings).
ISO 10303 is an ISO (http://www.iso.org) standard for the computer-interpretable representation
and exchange of industrial product data. Its official title is Industrial automation
systems and integration -
Product data representation and exchange, and it is also known as STEP or the Standard
for the Exchange of Product model data.
ISO 10303-21:2002, Industrial automation systems and integration — Product data representation and exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure.
ISO 10303-21 defines the encoding mechanism on how to represent data in ASCII according to a given EXPRESS schema.
See: (http://en.wikipedia.org/wiki/ISO_10303-21) and (http://www.iso.org)
ISO 10303-239 Industrial automation systems and integration — Product data representation and exchange Part 239: Application protocol: Product life cycle support,
See: (http://en.wikipedia.org/wiki/ISO_10303) and (http://www.iso.org)
ISO/TS 10303-28:2003, Industrial automation systems and integration — Product data representation and exchange — Part 28: Implementation methods: XML representations of EXPRESS schemas and data.
ISO 10303-28 specifies the use of the Extensible Markup Language (XML) to represent EXPRESS schema (ISO 10303-11) and the data that is governed by those EXPRESS schema.
See: (http://en.wikipedia.org/wiki/ISO_10303-28) and (http://www.iso.org)
The method by which a failure/defect is isolated.
The ISO sub committee responsible for developing ISO 10303-239.
Any problem or proposal related to Configuration Management
Issues may include:
variances (E.g. waivers, deviations, production permits)
documentation error reports
configuration discrepancy reports (E.g. arising from change monitoring activity)
An issue that, following assessment, is deemed to be worthy of subsequent change action.
Any of a number of enumerated or listed things. (Oxford Concise)
Item Unique IDentification (IUID) is the strategic system implemented buy the DoD
to enhance the traceability of the property. It is an asset identification system
to uniquely identify a discrete tangible item or asset and distinguish it from other
like and/or unlike tangible items. Tangible items are distinguished from one another
by the assignment of a unique identifier in the form of a unique data string and encoded
in a bar code placed on the item. An item unique identifier is only assigned to a
single item and is never reused. Once assigned to an item, the IUID is never changed
even if the item is modified or re-engineered. IUID is similar to social security
numbering used to distinguish citizens of the United States from one another.
See also: (http://en.wikipedia.org/wiki/IUID)
Not used in PLCS.
Life Cycle Cost
The amount of time between the first request for the supply of an product instance, or service, from a supplier, to the availability of that product instance, or service at the geographic location where it is required for use.
The process of determining the most suitable maintenance level for repairing items of equipment.
There are two types of LORA:
Economic
Non-economic
Non-economic LORA is used wherever there are overriding factors affecting the repair location such as existing policy, accessibility, available skills, and equipment size.
Economic LORA is used only where cost of repair is the only variable.
Abbreviation: LORA
A predefined amount of usage which a product instance may accrue before it must be repaired/overhauled/maintained or retired.
A predefined life may be extended or reduced to reflect a change in local circumstances for a specific PIF.
The amount of time or usage of a product instance for which a life limiting characteristic applies.
A generic term for the life of a product from concept to disposal.
The cost of acquiring and sustaining a product over its life cycle.
The life cycle cost may include the costs of acquisition and development, and the cost of operation, support and disposal throughout the life of the system/equipment.
Life Cycle Cost (Costing) also known as Through-Life Costing (TLC).
Abbreviation: LCC
Directives from beyond the model boundary that initiate or constrain support activities from concept through disposal.
These directives include:
law and political dictates
environmental and safety directives
business, organizational and program strategies and policies
standardization policy and directives
program plans (what, when, where and who)
program business goals, objectives, targets and constraints (for example, annual budgets, performance targets, thresholds and skills)
information on the organization, portfolio, program, projects and so on related to the product in focus
priorities that are from the life cycle owner and affect the feasibility of providing needed support elements
decisions arising from consideration of requests to the life cycle operator
day to day management instructions that affect support activities.
Business, organizational and program strategies and policies address topics such as:
corporate support
risk
quality
procurement
contracting
configuration management.
Life cycle directives include any exceptional maintenance demands and information from the operational plan, sufficient to define each support opportunity, and to serve as a constraint on "Plan and control support delivery" (A4.1).
List of the stakeholders identified by the Life cycle directives.
The effects local to the product instance on which the failure mode occurs.
Definition of relevant environmental conditions at an identified location which could affect the provision of support and hence the support solution.
Example: arctic or desert conditions, covered dock.
The geographic location of something.
Activities to ensure that support items are in the right place, at the right time, in the right condition for use.
E.g. move, pack, hold, issue,
A potential physical element within a product design which has significance to the development of a support solution definition.
Note 1: Within Def Stan 00-60, Logistically Significant Items are identified by a physical Logistic Control Number (LCN).
Note 2: Logistically significant items cannot be made or purchased as they are types, not tokens.
A structured method of analyzing items of equipment as they are being developed, to identify any features of design that could result in unnecessary expense in-service.
Once identified, these areas can be the subject of trade-offs to amend the design in order to reduce these cost drivers.
Abbreviation: LSA
A database used to store and sort logistic support analysis (LSA) data relating to equipment and systems.
Abbreviation: LSAR
Level Of Repair Analysis
See: group identifier
Logistic Support Analysis
Logistic Support Analysis Record
Retain and preserve the fully serviceable condition of the product-in-focus within its currently allowed configurations and intended use.
E.g. inspection and determination of condition, remove, repair, fault isolation, cleaning, overhaul, servicing.
The ability of a product instance under stated condition of use, to be retained in or restored to a specified condition when maintenance is performed by personnel having specified skill levels under stated conditions and using prescribed procedures and resources.
The person who maintains the product instance.
The actions carried out to maintain a product.
Activity to detect and resolve actual or potential shortfalls in functional capability.
E.g. detect and diagnose failure, inspect, test, strip, assembly, modify, calibrate, perform operational and support tasks (E.g. fuel).
Work request identifying additional support tasks, which may be needed to restore products to serviceable conditions.
A plan that identifies the maintenance tasks required in order to assure the continuation of desired performance of a product-in-focus.
The maintenance plan is a subset of support plan and hence of the support solution. It may be mandatory or for guidance.
A step-by-step set of actions arranged in a logical sequence to do a maintenance task.
A schedule for one or more maintenance tasks.
The process of transforming the maintenance plan into a maintenance schedule.
A task performed to sustain product function.
A maintenance task is a type of support task.
Examples:
Remove a replacement part
Investigate a symptom
The recording and assessment all CM issues and the categorisation according to type and priority.
Issues that require change action are passed to the other CCM activities. A unique identifier is issued by configuration identification. CM issues include any issue, problem or proposal related to configuration management. These can be variances (waivers, deviations, production permits etc), documentation error reports from any source but principally from SE/RM/M and F or configuration discrepancy reports e.g. arising from change monitoring or audit activity.
Manage the information related to a PIF.
A Configuration and Data Management (CDM) activity, the major output is Assured Product and Support Information (APSI), which encompasses the entire configuration /support data. A subset of the APSI is the Configuration Status Record (CSR). The dynamic nature of the CDM 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, etc.) that comprise the CSR must be formally managed and approved. In essence, Approve, release and record is an activity that makes configuration and support documentation available for use, subjects it to Configuration Change Management (CCM) and formally maintains the APSI.
Capture and manage through life the information needed to support the Product-in-Focus (PIF).
This includes configuration identification of the product and support system and configuration change management of an integrated set of Assured Product and Support Information (APSI) used to develop and provide support. It also includes development of information management rules to govern the recording, storage and publication of the APSI and of all other information generated or used by support activities (E.g. maintenance history).
Coordinated activities to direct and control an organization.
In English, when the term "management" refers to people, i.e. a person or group of people with authority and responsibility for the conduct and control of an organization, it should not be used without some form of qualifier. For example, "management shall..." is deprecated whereas "top management shall..." is acceptable.
This activity represents the analysis, evaluation, and extrapolation of progress against the Authorised maintenance plan for the purpose of identifying tasks for release, reporting status, and the need for re-planning
Not used by PLCS.
Set of operations having the object of determining the value of a quantity [VIM].
The identification of the exact location on a product instance at which some form of measurement can be taken.
A middle item in any physical assembly tree, or object of the decomposition, from a specified viewpoint.
Has both parents and children.
Synonym to subassembly and, depending of viewpoint, to an assembly.
An alphanumeric identifier, that is used with products as a base identifier for the serialization of the product.
The model identifier remains unchanged when the product identifier for the assembly/product is changed unless the performance/interoperability of the assembly/product is significantly changed. Synonyms include model number, and nomenclature.
This activity defines the maintenance plan activities, establishes the maintenance plan logic, and schedules maintenance tasks. This activity produces a draft maintenance plan for the authorisation process.
A description of how EXPRESS entities are used to represent a given concept (a specific "functionality" or "capability"). It provides guidance and rules on what Entities should be used to represent a given concept, how the entities should be related, and what Reference Data should be used. As well as general guidance, a set of Templates are documented within a Capability to provide precise specifications of which Entities should be instantiated to represent identified concepts.
The action carried out to modify the product-in-focus.
Make changes to a product that affect allowed configurations.
Monitoring of the implementation of the change in all affected areas to maintain consistency between each element of the PIF and its applicable configuration and supporting information.
There are two main activities monitor update to Information which encompasses all activities to incorporate the change in the documentation affected by the change E.g. models, process sheets, flight manual, structural, and repairs manual and monitor the verification process to demonstrate that an activity is carried out in accordance with the applicable requirements and rules/ guidelines.
Standards and conventions that are to be applied when identifying elements of the PIF or support system.
Naming conventions are part of the Information management (IM) Rules.
Name and identification of a task applicable to a given support solution.
Identification of the information that needs to be collected to support assessment of support performance against the metrics specified by the support solution requirements.
Request for further work to find solutions to issues revealed by an impact report relating to a proposed solution.
An identified need for new elements (interfaces).
As a result of the activity define interfaces between elements.
The effects on the system in which the product instance performs a function, when the failure mode occurs.
(1) Names assigned to kinds and groups of products.
(2) Formal designations assigned to products by customer or supplier .
Examples:
model number
model type
design differentiation
specific design series
specific configuration
Non-fulfilment of a specified requirement for a product.
Non-fulfillment of a requirement.
Organization for the Advancement of Structured Information Standards (http://www.oasis-open.org).
The technical committee within OASIS responsible for developing the PLCS DEXs (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=plcs).
The Reference Data Library standardized and managed by the OASIS PLCS TC (managed in PLCSlib). Sometimes referred to as "OASIS PLCS RDL".
Request for changes to a support objective, which cannot be met.
A small, reusable schema (element grouping) that has some business sense that is used as a building block in the EIA-836 reference schemata.
Examples:
product identifier
document identifier
effectivity
address
The OMG Object Constraint Language (OCL), a formal language used to describe expressions on UML models. These expressions typically specify invariant conditions that must hold for the system being modeled or queries over objects described in a model.
The environment in which the PIF is, or will be, used, described in terms of relevance to the management of support.
Example:
Long haul environment vs short haul environment.
Antennae operating in funnel exhaust vs antennae operating in clean air.
Anticipated support opportunities and expected usage of one or more products needing support during a period of interest.
The environment in which the product instance is operated, maintained, transported, etc.
Can include a (E.g. South Atlantic, Desert etc) or "Theatre of operation".
Information that supports the use of a product.
Includes but not limited to:
operation manuals
maintenance manuals
user's manuals
instructions
procedures
diagram
An engineered asset providing functional capability for an operator.
E.g. a train, a process plant, an aircraft, a communication system or a software system.
A sequence of events expected during operation of system products.
Includes but is not limited to:
environmental conditions
usage rates
expected stimuli (inputs)
responses (outputs)
Information provided to support authorities by operators including information on product health and usage, and equipment problems discovered by operators.
May 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.
A formal (contractual) request for product instance or services to be placed on a supplier against a specified budget.
Group of people and facilities with an orderly arrangement of responsibilities, authorities and relationships.
Examples:
company
corporation
firm
enterprise
institution
charity
sole trader
association
parts or combination thereof
Note 1: An organization can be incorporated, public or private.
Note 2: This definition is valid for the purposes of quality management systems standards. The term "organization" is defined differently in ISO/IEC Guide 2.
Orderly arrangement of responsibilities, authorities and relationships between people.
Note 1: The scope of an organizational structure may extend to include relevant interfaces to external organizations.
Note 2: A formal expression of the organizational structure is often provided in a quality manual or a quality plan of a project.
An alphanumeric identifier for a specific organizational entity.
Examples:
Commercial and Government Entity (CAGE) code
Data Universal Numbering System (DUNS)
Design Activity Identifier (DAI)
Name
Acronym
Address
Logo
Identification of a task to be scheduled, that has not arisen directly from the application support solution or commissioning schedule.
May include change tasks, outstanding tasks from previous work, exceptional tasks required by the Life cycle owner, or tasks required to meet support opportunity objectives.
Web Ontology Language - A W3C recommendation (http://www.w3.org/2004/OWL/)for defining Ontologies (Class structures).
an Individual represented in OWL.
A measurable or quantifiable characteristic or feature.
Some but not all of a thing or number of things. (Oxford Concise)
A part is a discrete object that may come into existence as a consequence of a manufacturing process. (ISO 10303 Part 1022)
See: product identifier
A quantitative measure characterizing a physical or functional attribute relating to the execution of an operation or function.
Note 1: Performance attributes include
quantity (how many or how much)
quality (how well)
coverage (how much area, how far)
timeliness (how responsive, how frequent)
readiness (availability, mission/operational readiness)
Note 2: Performance is an attribute for all systems, people, products and processes including those for development, production, verification, deployment, operations, support, training and disposal. Thus, supportability parameters, manufacturing process variability, reliability and so forth, are all performance measures.
Report on the performance achieved in generating a support solution or in providing support.
A performance report may include:
a report on progress achieved in relation to the support engineering program
achievement v predictions v requirements in terms of the support metrics applicable to a given support solution
observations on the performance v expectations in regard to identified support objectives- observations on the ability of the PIF and its support solution to meet expectations of operators and support personnel
Quantitative and qualitative expressions of material features, such as composition, dimensions, finishes, form, fit, and their respective tolerances.
The general arrangement or layout of a product instance.
The inability of an engineered product instance to perform its intended function (E.g. The engine fails to start).
product-in-focus
The scope boundary of the set of products that require a support solution.
The PIF scope establishes a common boundary for:
the life cycle Configuration Management activity
the information management rules
the set of related support solutions drawing from a common task library.
PIF scope should be defined in sufficient detail to identify which products will require support, both at the design and realized level, and to indicate the required level or depth of support to be provided.
The integrated set of classified elements and interfaces, product structure views, and relationships between product structure views, as specified by "required structures" and other IM rules.
The PIF Structure comprises:
the individual structures (E.g. functional, physical, zonal, other) for the product design and the realized product, including effectivity statements on the current, required and permitted configurations of each individual planned or realized product
relationships between structures that the information rules require (E.g. functional-to-physical links and physical to zonal links for both design and individual structures)
identification of interfaces between elements
These structures are built from elements, which have been identified and classified.
Set of valid tasks that are applicable to the PIF.
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 (E.g. commissioning tasks and tasks that are defined but are not selected for use when a support solution is developed).
An intended future course of actions to accomplish an objective.
The process of identifying the actions and means necessary to accomplish an objective.
??See OED, c.f.??
Establish which elements(s) of the PIF are to be changed, including both production and retrofit as necessary. There are many influencing factors including an assessment of the urgency/priority of the change and the availability of parts and materials, software and spares. 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. It may involve changes to information on; operation and maintenance, build and test, and commercial documentation. The new or revised information is identified and released (via AAM CM A133). The release process collates the document revisions to the change(s). It is not always necessary to have a plan before a change task can be authorised, however a change implementation plan is always needed.
??See OED, c.f.??
The plan established under AAM CM A11321 is further embellished by the inputs from impact assessments in respect the effectivity of the change and any other additional work that establishes it as a quantified change. Plan the implementation of the change by establishing which existing and intended items will be changed (effectivity), i.e. the point in production at which the change will take effect and to determine for which units already in production or in service retrospective action is required. Related change tasks will be identified in this plan.
??See OED, c.f.??
The plans and schedules must enable allocation of resources for the tasks to be carried out and must enable monitoring of progress against the plan. The plans are to 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. It 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.
Plan identifying the tasks required to validate, verify and audit a classified solution.
Plan maintenance identifies maintenance objectives to be accomplished and time phasing for all levels of maintenance, including both preventive and unscheduled maintenance from the support solution. Maintenance planning creates a maintenance plan that is a specific product instance plan that identifies specific jobs and tasks in a maintenance activity's maintenance program; fixing the time when maintenance operations are to begin or be completed, and ensuring that all resources (materials, labour, support equipment, facilities, documentation) are also scheduled for availability at the time maintenance is performed.
Maintenance plans and schedules have specific planning horizons such as annual, quarterly, monthly, weekly, and daily. Each schedule is a subset of the larger time period covered under the plan. Maintenance tasks are scheduled against a specific products/equipment in focus. The maintenance schedule contains all scheduled jobs and tasks, beginning/completion trigger event such as time, cycles, hours, lists specific resources and locations as to where the work package, job, or task will be accomplished.
An event which expected to occur at some point in the future.
The "Plan support delivery" activity plans and controls the execution of maintenance tasks related to the product-in-focus.
??See OED, c.f.??
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. A change development plan is established and becomes an input to the business solution assessment
PLCSlib is the XML environment created for the development of PLCS OASIS DEXs and components. It is also used for the development of Business DEXs and components.
Fill the skeletal PIF structure.
The skeletal PIF structure, produced by activity AAM CM A122, is populated with the product information [could simply be in the form of a Bill Of Material (BOM)]. All relevant interfaces and interchangeability (ICY) information will be aligned the elements. The relevant product and support information for the PIF is attached. All this becomes the set of Product and Support Information (PSI) for that PIF.
Identification of the items forming a potential solution to a valid need for change, including conditions for super cession of existing items within a product design.
Identification and description of potential support provider in terms of the infrastructure, facilities, task capability, personnel types and environmental conditions of relevance to support at each identified location where support activity may be required
Name, id and description of a possible support task.
The predicted loss of operational time due to support activities during the operating period in question.
Predicted state and usage of the product after a period of operation, defined in terms that are meaningful to the task triggers.
The product state may include predictions of anticipated faults.
A prediction of the resources needed to support a product during a specified period of operation.
Identifies existing elements, interfaces and information potentially affected by the change and makes an initial judgment on change viability. It also identifies potential new elements.
Preliminary assessments are documented so that the implications of implementing the proposed change can be considered by both the CM team who are documenting the change and external authorities who will need to assess the implications to the operational scenario. A change proposal may be stopped as a result of the preliminary assessment.
The priority that will be assigned to rectification of the failure/defect
Specified way to carry out an activity or a process.
Note 1: Procedures may be documented or not.
Note 2: When a procedure is documented, the term "written procedure" or "documented procedure" is frequently used.
System of activities which uses resources to transform inputs into outputs
Note 2: Processes in an organization typically are planned and carried out under controlled conditions to add value.
Note 3 : A process where the conformity of the resulting product cannot be readily or economically verified is frequently referred to as a "special process".
Process data represents the transformation of data into a format which can be understood by the support system.
??See OED, c.f.??
Encompasses all activities to incorporate the change in the information databases affected by the change E.g. models, process sheets, operating manuals, service/ maintenance manuals. The change may involve the creation of completely new documentation or the incorporation of changes in already existing documents. In all cases the documents are to be identified according the applicable document identification and issue rules. This activity is triggered by feedback from the various activities identified in the implementation and verification plan. It can also be also triggered by a agreed Variance. Once all activities specified by a change order are completed the task is closed.
Something that is used or produced to satisfy a need or is the result of a process.
Synonym to equipment.
Examples:
facilities
systems
hardware
software
firmware
data
processes
materials
services
Result of a process.
There are four agreed generic product categories:
Hardware (E.g. engine mechanical part)
Software (E.g. computer program)
Services (E.g. transport)
Processed materials (E.g. lubricant)
Hardware and processed materials are generally tangible products, while software or services are generally intangible. Most products comprise elements belonging to different generic product categories. Whether the product is then called hardware, processed material, software or service depends on the dominant element.
Example: The offered product "car" consists of hardware (E.g. the tyres), processed materials (E.g.. fuel, cooling liquid), software (engine control software, the driver's manual), and service (E.g. the payment facilities or the guaranty).
Any information about the product-in-focus and related support elements that is required by participants in life cycle support.
This information includes:
product design
product performance
predicted failures
diagnostic data
descriptions
drawings
manufacturing records
other product characteristics of relevance to support
descriptions of people and organizations
In addition, this information may include the operating and maintenance history of individual acquired items if relevant to future support.
This arrow does not include information about the support solution.
All information related to the support of the product prior to authorization and release.
After release this information becomes Assured Product and Support Information (APSI).
Abbreviation: PSI
Performance, functional, and physical characteristics of a product.
The expected behavior of a product for support purposes.
This includes operating and fault states, expected values of measurable parameters, and relationship of symptoms to possible causes.
Information about a product in support of its life cycle phases.
Product configuration information includes product definition information and supplementary types of information (E.g. operating procedures, maintenance procedures, disposal methods) necessary to support all phases of the products life cycle. It does not consist of project or administrative types of information (E.g. cost, schedule, and planning)
Information relating to the characteristics of the product.
Includes design data, drawings, product structure etc. This information will have been subject to configuration management throughout the design, development and production phases of the PIF life cycle. Combined with the Support solution this becomes Assured Product and Support Information (APSI).
Design information that defines a product's attributes and provides the authoritative source for configuration definition.
Product definition information may include further information derived from the product definition information and made subject to configuration management (E.g. operating procedures, maintenance procedures, disposal methods).
Examples:
specifications
drawings
source code
The set of products, operated by one or more customers, that are to be addressed by a specific support solution.
The expected usage profile and life constraints applicable to a product group requiring a support solution.
A product group may have several usage profiles, including a prediction of the percentage of time for which each may apply.
This may include:
the duration of deployments
the intended frequencies, duration (time and distance) , profile and nature of operating periods
the anticipated physical and climatic environments in which usage is expected to occur
History of the product usage and condition derived from support feedback records.
A name or alphanumeric identifier, used to designate a part or assembly, of the same configuration, and to differentiate it from all other products.
These identifiers may include a supplementary identifier used to distinguish one of several sequentially created configurations of a product from the previous configuration of the same product (i.e. revision or version).
The set of operational products and related items sharing a common product design and support solution.
The PIF may include:
Many versions of the product design
Many operational products, used by different users in different ways
Any part of the operational product needing support
-Any support item or infrastructure element that are addressed by a given Support Solution
Abbreviation: PIF.
Product information that cannot be released as part of the authorized product information. It includes the reasons for rejection.
A specific instance of a product.
E.g. an aircraft by tail number.
The authorised duration (time or usage) in which product instance is deemed to be capable of performing its intended function.
The measure of ability of a product instance to perform an intended function in terms of its reliability, maintainability or availability.
The state of product instance at a given point in time.
E.g. running, standby.
The total use of a product instance within a relating theatre, scenario and phase.
E.g. product instance run hours, gun firings, deck landings.
A record of the usage of a product instance, with dates, times, usage consumed, plus relating context (usage theatre, usage scenario, usage phase, user). This will also include life consumed, with associated dates and times, status, location.
Identification of product conditions not recognized or addressed by the support solution that require analysis and direction.
The absence of a response to such exceptions may prevent release of the product to service. Product integrity exceptions may lead to an extension of the support solution.
The complete process of designing, manufacturing, operating and supporting a product, including its final disposal.
One or more realized products that require support.
The product needing support may include any realized element of the product-in-focus.
The product needing support may 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.
Feedback on the state of the product or support element on which a work is underway.
Includes information about the product configuration, product status and product condition.
Examples: Test results, readings, wear measurements and information derived from embedded capabilities such as built in test or condition monitoring.
Status report confirming that a realized product, having received support, is now ready for use.
Report may contain or make reference to:
the identity and configuration of the realized product
confirmation of ready for use status
a date/time stamp
the organization/location/person authorizing release
any restrictions/limitations applicable to product instance use (part of information to operators)
the tasks scheduled and completed
Notification of the current status of a product receiving support, as confirmed by the authority controlling the work.
Observations, measured characteristics or a record of the state of a product needing support.
The state of a product may include the existence of fault, an operational state or a status in relation to recognized steps/stages of a support process (E.g. awaiting test, ready for dispatch).
A statement on what breakdowns/views and relationships between views are to be provided.
Record of use of the product in performing operational activities.
Product use may be quantified against any usage parameter in any operational (usage) state E.g. life, number of landings, hours spent above 50% power.
Product use records may be contained in, or extracted from, logbooks or electronic record (tapes, discs, etc) provided by operators from the operational product
Requirements for change of the support engineering program arising from reviews.
Any code that is used to track the evolution or modification of something. For example the versioning of a task.
A property is a measurable or observable attribute of a product, or other item.
Note 1: Properties may describe physical attributes, such as mass, pressure, voltage and less tangible attributes such as "mean time between failures".
Note 2: Shape, colour, location and price are also treated as properties.
Note 3: Properties may apply to the environment, a product, a person or an activity.
Synonym to characteristics.
Provide a unique identifier, a name and description of each PIF element (as defined by the configuration identification activity).
The "Provide Support Activity" provides the framework within which a variety of concepts, programs, and allowances are developed to support a product-in-focus. The activity provides and integrates the support elements required to retain product-in-focus functional capability.
The act or an instance of providing.
Product and Support Information
The reference to the organization purchasing the product instance or service.
Part of quality management, focused on providing confidence that quality requirements are fulfilled.
Inherent characteristic of a product, process or system derived from a requirement.
A characteristic assigned to a product, process or system (E.g. the price of a product) is not a quality characteristic of that product, process or system.
Part of quality management focused on fulfilling quality requirements.
Part of quality management, focused on increasing effectiveness and efficiency.
The term "continual quality improvement" is used when quality improvement is progressive and the organization actively seeks and pursues improvement opportunities.
Coordinated activities to direct and control an organization with regard to quality.
Note 1: Direction and control with respect to quality typically includes establishment of the quality policy and quality objectives, quality planning, quality control, quality assurance, and quality improvement.
Note 2: Total quality management (TQM) is one form of quality management which is based on the participation of all members of an organization.
System to establish a quality policy and quality objectives and to achieve those objectives.
Document specifying the quality management system of an organization.
Quality manuals may vary in detail and format to suit the size and complexity of an individual organization.
Something sought, or aimed for, related to quality.
Note 1: Quality objectives should be based on the organization's quality policy.
Note 2 : Quality objectives are specified at different levels in the organization. At an operational level, quality objectives should be quantitative.
Note 3: Different terms are sometimes used for quality objectives, such as quality targets, quality aims or quality goals.
Document specifying the quality management system elements and the resources to be applied in a specific case.
Note 1: Quality management system elements typically include quality practices, assignment of responsibilities and sequence of activities.
Note 2: Examples of specific cases include a particular product, process, project or contract.
Note 3: A quality plan often makes reference to parts of the quality manual or to documented procedures.
Note 4: A quality plan should be distinguished from quality planning.
Part of quality management focused on setting quality objectives and specifying necessary operational processes and related resources to fulfill the quality objectives.
Establishing quality plans may be part of quality planning.
Overall intentions and direction of an organization related to quality as formally expressed by top.
A statement of:
What the change is
What work is to be done
Why the change is required
Who will carry out the work
When - i.e. fit opportunity and effectivity
Related changes (change matrix)
It also specifies the requirements for reporting progress and completion
The solution to the "request for change".
Definition of a potential solution to the valid need for change with plans for its implementation, validation and audit.
This includes:
what the change
what work is to be done
why the change is required
who will carry out the work
when - ie fit opportunity and effectivity
impact on related changes
It also specifies the requirements for reporting progress and completion.
A quantified metric, to be used for assessing the performance of the support solution.
This include:
the metrics to measure the characteristics
target values (quantified) to be reached by the support solution in terms of cost, availability, time, quantity, weight, volume etc
threshold values (quantified) that will or may result in program redesign or halt
Rapid Acquisition of Manufactured Parts
Proposal to change the assignment of tasks to products, or the task trigger conditions, to achieve rationalization of work packages within the support plan.
Reliability Centered Maintenance
The reason for replacement of a component.
E.g. scrap, modification, Missing product instance, Life limit exceeded, Not repairable in time.
A stakeholder with a legitimate role in the specification, design, commissioning or use of a support solution.
This may include: users, supporters, developers, producers, trainers, maintainers, disposers, acquirers, supplier organizations, regulatory bodies, members or groups in society, including representatives or designated proxy stakeholders.
The recommended solution to a valid need for change after comparison of potential solution options.
An issue that have been documented and identified.
The reference to the persons and/or organization that rectified the failure/defect.
Adjust or make right (correct, amend).
Reference Data is data that represents information about classes or individuals which are common to many users.
A Reference Data Class is Reference Data that represents a class. The class definition representing a Reference Data item (e.g. term, definition and rules), used to specialize entities of the information model, to make the use of them semantically more precise. It is sometimes called a "RDL class".
A Reference Data Library (RDL) is a managed collection of Classes and Individuals that are specified separate to and referenced from a data exchange file.
(1) A Change whose need has been established but has been rejected following evaluation. This can be on cost, effectivity or repercussions.
(2) A Variance, which has been rejected because it is not, considered an efficient method of correcting a non- conformance. A configuration change would normally be expected now to correct this variance.
An issue that has been rejected following assessment. The reasons for rejection may be attached.
Response that indicates no further action is intended in respect to an issue or change.
These rejected issues and changes include:
issues that will not be taken forward as change orders and for which exists no further planned configuration change management action
a change for which a need has been established but has been rejected following evaluation. This rejection can be on cost, effectiveness or repercussions.
a variance that has been rejected on the basis of inefficiency as a method of correcting a non-conformance. Such a non- conformance would usually be corrected by proposing a change.
Rejections should include reasons for rejection.
The customer failing to agree a price for the change or element of the proposed change.??
Notification of decision not to release product and support information as APSI.
A request for change that has not been accepted.
A variance which has been rejected because it is not considered an efficient method of dealing with a non-conformance.
A change proposal would normally be expected following a rejected variance.
Information that is related to the Assured Product and Support Information but is not subject to Configuration change management.
Includes feedback form operations and maintenance.
Information that may be released, under the conditions specified by the information release plan.
Dissemination or distribution of information and/or products after approval.
Release is subject to configuration change management.
"Release of task" is the activity that assigns the task for performance and authorises the task to begin. This includes transferring custody/control over all resources (materials, labour, support equipment, documentation) scheduled for availability during the time maintenance is performed.
This activity performs the formal approval process which changes the PIF status from "In maintenance" to "Ready for use". This includes the completion verification of all released tasks against the product-in-focus.
Transformation of PSI into Assured PSI (APSI).
The PSI is taken through a qualitative/quantitative check to ensure that it is fit for purpose, meeting the specific requirements called for in the change order. When released it becomes Assured Product and Support Information (APSI).
A support driver of relevance to a specific deployment environment and support concept.
The ability of a product instance to perform a required function under stated conditions for a specified period of time.
A disciplined logic or methodology used to identify preventive maintenance tasks to realize the inherent reliability of equipment at least expenditure of resources.
The potential failures are then analysed to decide whether a corrective or preventive maintenance task would be most appropriate.
Abbreviation: RCM
The act of removing a child product instance from a parent product instance.
The act that restores designed functionality.
A replacement part subject to being returned to a fully serviceable condition as defined in the support solution.
A replacement part commonly economic to repair over a period less or equal to the life of the product to which it is related. It may, however, be disposed of due to circumstances as defined in the support solution.
Synonym to repairable part.
Indication of whether the failure/defect can be rectified with the product instance in situ (in its normal operating location).
A replacement part subject to being returned to a fully serviceable condition as defined in the support solution.
Synonym to repairable (n).
The geographic location at which a repair activity can be performed.
A part of the product-in-focus that could be fitted to and removed from the product-in-focus or from another replacement part during a maintenance task.
Built up of repairables and/or discard parts. May also include consumables and expendables.
Request to provide a price/cost impact statement against the detailed Statement of Work.
The generic term for the initiative to start a change action.
The change request may arise in the contractor or in the customer organization. Initially it may be documented in any format, however it will be given an identifier so that it can be audited and traced by Configuration Status Accounting (CSA). It includes:
one off requests
resulting deviations
concessions
waivers
All of these will follow the same decision process.
Request to provide an effectivity for an envisaged change in the form of a "break-in" in production or a mod set delivery.
Request to provide identification for new elements of the product or support solution.
Requests may arise from
new product concepts
developing breakdowns of existing products
changes
A request for assessment of the impact of an issue to support a decision on whether to develop a solution.
Request for action resulting from assessment activities.
May include:
proposal to change the resource provision related to a given task
proposal to change the support solution
requests to relax support solution requirements
proposal to change the product
requests for additional data from existing source or for new data sources
Request for action that is not part of a change, arising from a documented problem.
May include request for additional information to support change action, or the deferral of change action to a later date.
Requests to stakeholders to re-assess allocated requirement, support objectives or elicited needs that generate requirement conflicts that cannot be resolved adequately by the support engineering program.
Requests for revisions to the support schedule as a result of feedback from task execution.
May include reports of deferred tasks or requests for additional activities that should be considered for inclusion in a subsequent revision of a support schedule.
Request for a change to the support concept.
Requests for a new or additional resource item required by a task, or for information on the feasibility and cost of obtaining these.
Arrow Note: Also captures the formal requirements and specifications for design, modification and/or acquisition of new or critical support items. Contains requests for information on support cost and lead time for products that are provided, maintained or modified inside their own life cycle, such as repairable components that are replaced on the product-in-focus.
Request for the further development of a task specification.
Request for the development of a task procedure for an intended task not addressed by the support solution.
Request for an update to an implementation plan, following authorization of a change.
Request for variance.
Request for impact assessment and potential design solutions that could satisfy a valid need for change.
Requests for action to assess the feasibility of changing the product to improve supportability, or to embed support capabilities within the design.
May result from requirements to improve reliability, maintainability, redundancy, durability, sustainability or product life.
Requests to embed may seek to incorporate capability within the product for prognostics, diagnostics, condition monitoring, built in test, safety or environmental protection that are needed for support reasons.
Request for a change identity and priority following assessment of a problem or opportunity. The result of this request may be a valid need for change following further analysis.
Request for action by the life cycle owner relating to activities beyond the scope of this model.
These include:
requests for action to develop support items
requests for information
proposals for changes to the product requirement, allocated support requirements, product design or life cycle directives to reflect support needs
Changes resulting from such requests will re-enter the model as configuration management issues.
These requests may result from supportability analyses, assessments or experience.
Examples include:
support requirements and constraints on design
standardization requirements
needs for embedded support capability such as built in test or condition monitoring capability
requests for design change to meet support needs
supportability test requirements
design discrepancies identified during operational use or support
requests for cost and feasibility information on alternative support elements and influences on existing support infrastructure, to meet a supplied specification
Request for action to better define the problem to be addressed.
The resources needed to support scheduled work at one or more support opportunities.
The set of product structure views or breakdowns that the life cycle owner requires to establish and maintain the PIF.
The tasks expected to be performed during the operating period of interest.
A requirement from the Life cycle owner that shall be taken into account when generating a support solution.
Note 1: May include legal requirements, business goals and organization policy that shall be taken into account when designing the support solution.
Note 2: Such requirements may conflict with allocated support requirements. Conflicts are resolved in A223.
Note 3: May use AP233.
Proposals for changes to support solution requirements arising from monitoring support system performance.
Requirement for product structure view.
(1) Specified essential product attributes.
(2) Need or expectation that is stated, generally implied or obligatory.
Requests to the life cycle owner to address issues identified by the task analysis activity.
Note 1: May 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 (E.g. to improve reliability or prevent a specific 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
Note 2 : All of the above can be communicated by Work Requests. Work requests may be supported by requirement statements, or specifications for required resources.
Note 3: May use AP233.
A request for the supply of logistics resources necessary to support and sustain an product instance.
The means to achieve an end or fulfil a function.
The assignment of a resource to a task as part of a plan or schedule.
Note: The assignment may specify dates, organisations and locations.
Assessment reports on adequacy and quality of resources provided to support a specific task, a specific deployment, a realized product or the overall support solution.
Identifies task and/or resource imbalance or deficiency that may justify a reassessment of the resource aspects within a task analysis.
A plan that identifies the resources, resource breakdown structure and resource specifications applicable to a task.
The scheduling of individual resources is linked to a support schedule
is undertaken in conjunction with defining the resource schedule
A schedule for the provisioning or use of resources.
Contains allocation of individual resources (quantity, timing, location, using organisation).
Record of the usage of a resource in the course of performing a support task.
Usage may be measured by elapsed time, number of starts, cycles of operation or other parameter.
It includes the consumption of spares or consumables; time spent by human resources in performing support tasks and the usage of support locations or facilities.
The incorporation of new design parts, or software code, resulting from an approved configuration change, into products already delivered.
Activity undertaken to ensure the suitability, adequacy, effectiveness and efficiency of the subject matter to achieve established objectives.
Example: Management review, design and development review, review of customer requirements and nonconformity review.
The analysis and interpretation of data to determine exceptions from the support solution, determine additional maintenance needs, assess and report the impact on operations, and create suggestions for improvement.
??See OED, c.f.??
Monitors the approved changes through a planned and scheduled implementation in all documents, facilities, hardware, and software affected. The implementation is carried out in accordance with the Change activity plans (AAM CM A1132). Change accomplishment in all impacted areas is monitored and verified to track progress and to maintain consistency between each unit of the PIF and its applicable configuration and support information (APSI).
Action taken on a nonconforming product to make it conform to the requirements.
Issues arising from identification of support drivers that may require action by the Life cycle owner for reasons of safety or critical significance to the delivery of viable support.
(1) Authorization and approval from a designated authority or body.
(2) Explicit or official approval, permission, or ratification.
The timing, sequence and allocation of tasks, resources and events.
The process of defining the timing, sequence and allocation of planned tasks, resources and events taking into account related the constraints applicable to specific support opportunities.
A task expected or required to be performed on a product needing support during a specific support opportunity.
This activity integrates the maintenance plan logic and activities, and identifies when the tasks are to begin or be completed. This fits maintenance activities within the operational schedule and support planning information regarding resource requirement availability.
Issues which prevent successful completion of the commissioning schedule.
May identify tasks that cannot be scheduled due to constraints from resource availability, operational schedule, or other reasons.
A declaration of intent to perform one or more actions, or to expect one or more events
Note 1: A scheme may represent a support solution or support schedule.
Note 2: Schemes may also represent any other type of expected events and actions, including those arising from configuration change management.
Note 3: Schemes include most types of plans, schedules and to-do lists.
An entry in a plan or schedule.
Example: An activity in a plan.
Action taken on a nonconforming product to preclude its originally intended usage.
In a nonconforming service situation, usage is precluded by "discontinuance" the service.
Examples: Recycling, disposal or destruction.
Discarded as useless.
The protection of information and data so that unauthorised persons or systems cannot read or modify then and authorised persons or systems are not denied access to them.
The change solution, complete with the coordinated impact assessments, which has been selected. This allows the change to be evaluated for effectivity and cost implications and work to plan change tasks can be initiated.
An activity required to establish a viable support system, capable of applying a support solution that shall be included in the commissioning schedule.
The organization, or organizations, selected to perform scheduled tasks.
This activity selects specific product instance tasks for carrying out specific jobs or tasks in a maintenance activity to meet maintenance objectives taking into account maintenance status and scheduling problems.
Maintenance activities detect and resolve actual or potential shortfalls in functional capability, e.g. detect and diagnose failure, inspect, test, strip, assembly, modify, calibrate, perform operational and support tasks (E.g. fuel).
The definition of order, taking into account dependencies and other constraints.
Successor and predecessor relationships are developed in a network format. This allows those involved in a project to visualize the work flow.
Ability to render service.
The severity of the effect of the failure/defect.
Expertness, practised ability, facility in an action (dexterity or tact)
Intellectual product consisting of information on a support medium
Note 1: Software can be in the form of concepts, transactions or procedures.
Note 2: A computer program is an example of software.
Definition of a potential solution plus recommendations for further work required to complete assessment of this option.
Definition of the solution plus information to enable the decision to proceed with design, development or implementation of the change.
??
Information stating requirements.
A specification may be related to activities (E.g. process specification and test specification), or products. (E.g. a product specification, performance specification and drawing).
Set of standardized business transactions that execute requests for the provision of resources, and provide responses on their expected delivery.
These transactions can include:
order an item (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 (for example, packaging standard, asset tracking reports need)
query a forecast delivery
request review and comments
request approval
request a specified repair or overhaul and so on
A state is the condition in which a thing is.
Note 1: A state may be defined, predicted or observed.
Note 2: States may apply to the environment, a product, a person or an activity.
Note 3: A sequence of states may be used to define stages within a process.
Note 4: States are used to define and describe normal and degraded conditions of a product, including operating states and faults.
A status indicates a "state" in time.
Report on progress of a task from the change development plan.
ISO 10303 - Product data representation and exchange (abbreviation stands for "STandard for the Exchange of Product model data"). A family of standards for product data exchange.
A supply or quantity of anything for use.
The quantity of a specific stock.
A further decomposition of an assembly.
Has both parents and children.
Synonym to middle item.
A system that is part of a larger system.
Suggestions to improve the support solution or product-in-focus.
This equates to change request for CM and could include changes to IM rules.
The reference to the organization supplying the product instance or service.
Provide or furnish a thing needed.
The actions carried out to support the product-in-focus.
Establish, retain, preserve and change the functional capability of the product-in-focus.
Includes commission, maintain, modify, pack, transport, store and manage resources.
A quantifiable parameter used to define an aspect of support system performance.
Requests back to the stakeholders for clarification of required support characteristics.
Not used by PLCS.
Identification and description of a justified need for support activity.
Consists of predicted product failure or degradation, safety drivers (legal and others), environmental drivers or operation and readiness drivers.
Also includes requirements for tasks to collect the information needed to assess support performance.
A realized product that is available to the life cycle owner for operational use.
Support elements are the physical items required to sustain product capability.
Support elements include:
Repair parts, which are the physical items that become part of the equipment during the equipment's life. Repair parts are either expendable or repairable as they are replaced during the equipment's life.
consumable items, which are the physical items that are consumed by the equipment as part of delivering its designed capability, but do not become part of the equipment
support tools and diagnostic and test equipment, which are required to undertake support tasks
trained people
In this activity model fixed support infrastructure is shown as a resource.
Observations on the condition, measured property or status of a support element, which has been, or is being used, as a resource for a task.
Possible states include:
consumed
in-use
available to re-locate
Objectives to be met by the support engineering program.
May use AP233.
A schedule that defines the processes (activities), procedures (task specifications) and resources required to develop a support solution which meets the support engineering objectives and the support solution requirement, within the constraints specified by the Life cycle directives and Change directives.
It includes:
a resourced schedule 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.
The environment, in which support is undertaken, described in ways that influence the work or working methods.
E.g. changing a wheel by a roadside v changing a wheel in a workshop.
Equipment required to maintain an item, system, or facility in its operational status, including related computer programs.
Information on the condition or usage of a product receiving support and on the execution of support activities.
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
The proposals generated by support engineering, to influence the design of a product or related support elements.
Support impact on design includes influence on the product design (from the support perspective) and plus statements of requirement for the design of support items.
An opportunity to improve the performance of a support solution, which may warrant investigation as part of the support engineering program.
The information needed to provide support to an operational product, in accordance with a support solution.
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 1: Requirements to capture specific information may be included in task procedures.
Note 2: This activity model assumes that:
the support information management rules include the use of AP239 to structure the Assured Product and Support Information and the collection of feedback as Related Information.
the support information management rules apply to all elements of the PIF and its support system. Where this is not the case, appropriate interfaces will need to be negotiated to link the AP239 information set to related, non-compliant information.
Permanent installation providing one or more functional capability needed to provide support.
Synonym to facility.
A request for action to resolve a problem arising from working on a product needing support
May include requests to modify the product or support solution.
Any product used in providing support.
See: consumables, part, repairable, tool, test equipment, facility.
The capability of the one or more support organizations at a given location, expressed in terms of their ability to undertake classes of tasks within a support solution.
Request for clarification of a support metric proposed by a stakeholder.
An opportunity to perform work on a product needing support.
Support opportunities may have dates, time and location. They may also have priorities and readiness requirements. Support opportunities may apply to any combination of operational products, parts of product, and to support elements. Support opportunities may arise whilst the operational product is in use.
Example: Ship on passage.
An occasion on which work can be done on one or more realized products or support elements.
Includes which realized products or support elements will be available, for how long, at what location (or possible locations) and under what conditions.
It may also specify the planned future usage of the product or support elements to assist identification of necessary tasks.
The objectives applicable to a specific support opportunity.
Identification and description of the type of opportunities that may be available when work can be done on a product needing support.
Examples:
when operating
a base maintenance period
an annual inspection
major refit
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.
A support plan may include a presentation of a typical maintenance program for a product needing support.
It may also specify non-maintenance tasks, such as activities required to provide and prepare required resources.
Some necessary tasks may never be implemented if the conditions under which they would fall due, fail to arise (E.g. a task to correct a rare fault state).
A possible support plan, corresponding to a specific support policy.
The support policy.
A prediction of the support system performance to be expected when applying a support solution in the context of a predicted operating or usage schedule and support provider performance. May include predictions on resource consumption, and hence on provisioning requirements.
The prediction of some metrics may require assumptions to be made about resource availability and delay times.
Identified needs to change program objectives, strategies or plans.
A schedule for performing one or more support tasks.
The status of the schedule will 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 (E.g. calibrate a test instrument).
The information required to support a set of products within a deployment environment.
The support solution may include:
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
identification of the deployment environment and requirements for which the support solution was designed.
The set of requirements that shall be addressed during the design of a support solution in the context of a deployment environment.
The requirement may include specified performance metrics for the support solution, with threshold or other tolerance values, defined in terms of agreed support characteristics.
May use Application Protocol 233.
The integrated sum of support elements.
To be updated!
How does it fit to support solution?
Confirmation that the system required to provide support, as required by a support solution, is in place and ready for use.
A task that form part of the work required to sustain a product in one or more deployment environments.
A type of task.
Examples:
Transport a replacement part.
Repair an operational product
Anomalies of actual task against predicted task.
Examples include:
task
instructions
resources used
tools
spares
skills
time
facility capability (E.g. power supply)
facts:
Discrepancy between predicted and actual task
Linked/associated with PIF
May include comments on Exceptions
Impact on dependencies and further tasks
May generate a CM issue
May generate a SE issue
Record of the state of a current or completed task.
This may include records of completion of individual task steps.
A symptom is an observed property, or behaviour, of a product, arising, or assumed to arise, from one or more anomalies.
Note 1: Symptoms
are the means by which faults are detected
may be observed without knowing which anomaly caused it
may indicate that a particular failure, or failure mode, has occurred but different anomalies, or combinations of anomalies, may cause the same symptom (effect)
Note 2: The diagnostics process is used to link symptoms to anomaly.
The OMG systems Modeling Language (OMG SysML™) is a general-purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities. In particular, the language provides graphical representations with a semantic foundation for modeling system requirements, behavior, structure, and parametrics, which is used to integrate with other engineering analysis models
Has two meanings within PLCS:
(1) A synonym of product. E.g. a communication system
(2) A subdivision of a product comprising a set of physical items that satisfy a given function (or deliver a capability). E.g. the fuel system.
Engineering requirements originating from the User requirements document and Systems requirements document. As the project is developed more detailed information is produced, this along with Support engineering requirements enables the process of configuration identification at all stages of the lifecycle.
A piece of work to be done or undertaken. (Oxford Concise). A possible or intended activity.
A task may be composed of other tasks (subtasks)
Assign a task to someone. (Oxford Concise)
Applicability of an identified task to a PIF, product group, product version, location or support opportunity type.
Task applicability criteria may be extended or changed when the task is selected for use within a specific support solution.
The work done to implement a support (or maintenance) task. A Task Execution may be in progress, paused or completed.
The task execution may diverge from the task procedure (or task method).
Information, in any form, on task progress, findings or resource uses prior to recording in the format required by the IM rules.
History of previous work on a product needing, or receiving, support derived from support feedback records.
The identifier used to refer to a task.
Note: A task may have several identifiers.
The logical sequence of the intended activities, reflecting the local constraints that apply.
A sequence of activities to realize a task objective.
Note 1: One task may have several task methods, leading to several different task specifications.
Examples:
Change a wheel using a jack
Change a wheel using a garage lift.
Note 2: The task method normally gives the major procedural steps and is the baseline for the task procedure.
The name of a task.
Note 1: A task may have several names.
Note 2: The task name may provide some level of description of the task.
What the task is meant to achieve.
Note 1: One task objective may be realized by different task methods, using different resources. These will result in different tasks.
Examples:
Remove wheel for car on the road
Remove wheels from car on an assembly line
Note 2: Tasks that accomplish the same objective in different ways should be given different names and identifiers.
A plan that identifies required tasks, task breakdown structure and reference to task descriptions applicable to a product design or individual product.
Example: A maintenance plan.
A step-by-step instructions for undertaking necessary tasks in a form suitable for use by support providers.
The same task may be supported by several task procedures, each tailored to the needs of a class of users (E.g. to accommodate different skill levels).
Information on the progress and status of the task, including resource use.
Examples include:
persons performing the task
task steps completed
manhours used
start time
elapsed time
spares used
tools used
consumables used
Model for calculating the likely task duration and resource use when the task is executed.
Human resources are included E.g. the time taken to perform the task by support staff with specified skill levels.
Identification and quantification of the resources that are needed to perform an individual task.
Includes definition of required skills and experience of required support personnel.
Information collected in the course of executing a task.
A schedule for tasks.
Contains tasks with sequencing, dependencies, timing, location and allocation of individual resources.
Collection of valid tasks.
Definition of the method for performing a potential support task.
Note 1: A task specification may include a task objective, a task method (including sequence within the task), task predecessors/successors, pre-/post conditions, required skills/skill levels, required resources, duration and level of effort, applicable constraints, the relationship to the support requirements, etc.
Note 2: The level of detail within a task specification is a business decision.
The smallest unit of work identified by a task procedure or a task specification.
A task step has a definite start and a definite finish.
A task, which is needed to establish the configuration or condition of a product prior to receiving support.
Relationship between a necessary task and the product element, or elements to which it applies
A task to be included in the work schedule for this support opportunity.
The conditions that require a task to be done, in the context of its assignment to a specific product element.
Note 1: The type of trigger will vary with the type of task:
Corrective tasks, including diagnostic tasks, are triggered by events (the occurrence of damage, the detection of a failure or a symptom.)
Preventative tasks, including preprogrammed inspections, are triggered by time, life, usage or other conditions (hours run, number of landings, interval, frequency, if frost is expected).
-Operational and servicing tasks are triggered by actual or intended product use (E.g. tow out of hangar, re-fuel, de-fuel, configure-for-role) .
Note 2: Triggers may include relative conditions e.g. 4 months after last inspection.
Note 3: If a usage scenario is adequately defined, and if tasks are linked to resources, the task triggers may be used, in conjunction with product reliability data, to forecast resource requirements and support system performance over a given period.
A Template is a precise specification of which objects (and attributes) in the PLCS PSM should be instantiated, and which Reference Data should be used, to represent a concept providing documented functionality which matches a business object.
The extent to which an objective and feasible test can be designed to determine whether a requirement is met.
Item used to perform tests on the PIF. Could be generic or specific.
The test equipment could be part of the PIF.
Synonym to operational environment.
The total elapsed time taken to rectify the failure/defect.
Item used to aid the performance of a task.
See: generic tool and special to type tool.
Top of any physical assembly tree, or the object of the decomposition, from a specified viewpoint
Top items have children but no parents.
Synonym to end item.
Ability to trace the history, application or location of that which is under consideration.
Note 1: When considering hardware, traceability may relate to:
The origin of materials and parts
The processing history
The distribution and location of the product after delivery
Note 2: Traceability may be used in the context of a service, for example, in order to track the degree of completion of the service.
Note 3: Cf. definition of traceability in metrology.
Property of the result of a measurement or the value of a standard whereby it can be related to stated references, usually national or international standards, through an unbroken chain of comparisons all having stated uncertainties.
Note 1: The concept is often expressed by the adjective "traceable".
Note 2: The unbroken chain of comparisons is called a "traceability chain". [VIM]
??
Responses to transaction requests, providing details of price, availability, delivery or forecast availability of requested resources.
A request for the provision of one or more required resources at a specified location and date, or hastening a previous transaction request.
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.
The act of moving a consignment from one location to another for the purposes of delivery to a customer.
A task, which the assured support solution declares to be due based on evaluation of the task trigger condition.
??
The OMG Unified Modeling Language™ - is an object modeling and specification language used in software engineering.
(1) One of a quantity of items.
(2) Identifier of measure
Examples of (1):
product
part
spare
Examples of (2):
litre
metre
US gallon
UK gallon
foot
Alphanumeric identifier.
Note 1: A unit identifier is used to designate the specific unit of the part, or assembly, and to differentiate it from all other units of that part, or assembly, with the same design.
Note 2: Unit identifier uses the first definition of unit - "one of a quantity of items".
Requests for action to resolve conflicts identified during support solution design or use, which cannot be resolved by the support solution without breaching requirements.
Support drivers for which no effective response can be found because support task opportunities are not technically feasible or economically viable within the support engineering program constraints and the Support solution requirements.
The quantity of measurable units accrued by an product instance as a result of its use.The quantity of measurable units accrued by an product instance as a result of its use.
A unit of measure for a life limiting metric of an item.
The phase of usage of the product instance.
E.g. take-off, berth, minesweep.
A specific type or mode of operation of an product instance which is significant in usage terms.
E.g. formation flying, aerobatics, ground strafe.
The scenario (historically war and peace but may be any definition of a scenario) in which product instance is used.
The persons and/or organization that operate the product instance.
The provision of a specific service at a given facility.
E.g. power supply, hydraulic supply, compressed air supply.
Confirmation and provision of objective evidence that the requirements for a specific intended use or application have been fulfilled.
Note 1: The term validated is used to designate the corresponding status.
Note 2: The use conditions may be real or simulated.
The established plans for carrying out activities identified within.
The plans and schedules enable allocation of resources for the tasks to be carried out and enable monitoring of progress. The plans are based on the decision taken concerning the introduction point and effectivity of the change. They 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 (Assured Product and Support Information (APSI)) including requirements and design information.
See: Validation, Verification and Audit plans
Confirmed requirement for configuration change action.
Note 1: A valid need for change may have one or more proposed solutions, but not all these will be evaluated solutions
Note 2: It includes:
an identifier
a name
a classification
the reason for change
sufficient description to permit impact assessment
A departure from the design intent as reflected in the Assured product and support information.
Note 1: Design intent includes the design of the support system, the manufacturing system etc. Acceptance of a Variance does not change the PIF baseline.
Note 2: Different organizations have one or more words to describe departures from the design baseline, thus this definition is intended to cover terms such as:
waiver
concession
non-conformance
production permit
acceptable fault
acceptable limitation
Confirmation and provision of objective evidence that specified requirements have been fulfilled.
Note 1: The term verified is used to designate the corresponding status.
Note 2: Confirmation may comprise activities such as:
Performing alternative calculations
Comparing a new design with a similar proven design
Undertaking tests and demonstrations
Reviewing the design-stage documents before release
Note 3 : In the field of metrology, refer to VIM.
The program of verification tasks.
See: Validation, verification and audit plans
Check that all required release approvals are present.
Segregates "private and public view" information, common configurations but different customers. These will be placed on different release plans.
A particular form of product which varies from other forms of the product.
World Wide Web Consortium (http://www.w3.org) - The standards body for the web.
Set of conditions under which a person operates.
Conditions include:
physical
social
psychological
environmental factors (such as temperature, recognition schemes, ergonomics and polluted atmospheres)
A group of related tasks that may be authorized or performed together.
Record of progress against a support schedule from the authority controlling support provision.
This represents 'transient' information on status ("in progress" or "suspended"), and it will change as the maintenance progresses. This will include the status of support resources involved in the maintenance task, E.g. unserviceable, available, in use, location.
Extensible Markup Language (XML) is a general-purpose markup language recommended
by W3C.
See (http://www.w3.org/XML/)
A schema language developed by W3C, used with XML data files. See (http://www.w3.org/XML/Schema).
A division into spaces or regions.