Terms: d | Terminology index |
The terms defined in the terminology dictionary and in the Business DEXs.
damage | |||
Definition: | Damage is an external event that causes new product anomalies. | ||
Synonyms: | anomaly (n) | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | complete |
Data Exchange Specification (DEX) | |||
Definition: | 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". | ||
Source: |
[1] DEXlib definitions, . |
||
Version: | 1.0 | ||
Status: | in_business_review |
defect | |||
Definition: |
A deviation from the design.
NOTE A defect may result in a degradation in the ability to perform an intended function and may be an incipient failure. |
||
Source: | ![]() |
||
Version: | 1.1 | ||
Status: | in_work |
defect reporting and corrective actions system | |||
Definition: |
Definition?
NOTE Abbreviation: DRACAS |
||
Synonyms: | DRACAS | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | in_work |
deferment | |||
Definition: |
The method of delaying the work required to fix a reported fault.
NOTE 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. |
||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | in_work |
Define inform req for each element and interface | |||
Definition: |
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.
NOTE A configuration element could have a large quantity of information asssociated with it. Examples to consider whenn defining what is required are: design data, configuration item interface specifications, interface control documentation, analysis of support requirements, support solution and technical publications. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Define information architecture and rules | |||
Definition: |
Produce the Information management strategy requirements.
NOTE The requirements are usually derived from individual customer/companies policies/standards (eg IT/B2B/CM/QA etc) and the customers contractual requirements (eg 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)). |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Define information management procedures | |||
Definition: |
The production of the guidelines and constraints pertaining to the creation, use, maintenance and disposal of information
by life cycle users.
NOTE This defines the methodology and creates a structured set of IM rules.This defines the methodology and creates a structured set of IM rules. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Define interfaces between elements | |||
Definition: |
Establishment of the scope and nature of interfaces between elements.
NOTE 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. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Define links between product structures | |||
Definition: |
Establish necessary links between different product structure breakdowns and networks.
NOTE Examples: conceptual, design, functional, physical, spatial, zonal. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Define maintenance activity objectives | |||
Definition: | 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. | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | in_business_review |
Define PIF boundary | |||
Definition: | 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 appriopriate level of support. | ||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Define product elements | |||
Definition: |
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.
NOTE 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. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Define product structures | |||
Definition: |
The product structure fundamentals are established. These are considered as "essentials" for its construction and maintenance.
NOTE 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. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
defined structures | |||
Definition: | A set of product structure views/breakdowns that the life cycle owner has chosen to establish and maintain for the life of the PIF. | ||
Synonyms: | IM | ||
Source: |
[1] PLCS Activity Model, 2000. |
||
Version: | 1.2 | ||
Status: | in_business_review |
defined structures | |||
Definition: | A set of product structure views/breakdowns that the life cycle owner has chosen to establish and maintain for the life of the PIF. | ||
Synonyms: | IM | ||
Source: |
[1] PLCS Activity Model, 2000. |
||
Version: | 1.1 | ||
Status: | in_business_review |
degradation | |||
Definition: | A degradation is an anomaly that does not cause loss of a required function. | ||
Synonyms: | anomaly (n) | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | complete |
delivery | |||
Definition: | The formal handing over of property. | ||
Source: |
[1] Oxford English Dictionary, . |
||
Version: | 1.1 | ||
Status: | in_work |
dependability | |||
Definition: |
Collective term used to describe the availability performance and its influencing factors
reliability performance, maintainability performance, and maintenance support performance [IEC 60050 (191)]. NOTE Note 1: Dependability is used only for general descriptions in non-quantitative terms. Note 2: Dependability is a time-related quality characteristic. |
||
Source: |
[1] ISO 9000, Quality Management System - Fundamentals and vocabulary |
||
Version: | 1.1 | ||
Status: | in_business_review |
deployment environment | |||
Definition: |
A subset of the product-in-focus, operating environment and support environment for which a support solution is required
NOTE 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:
|
||
Synonyms: | operating environment, support environment | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 5.1 | ||
Status: | complete |
design authority | |||
Definition: |
The role of a person or organisation responsible for the
of a product. |
||
Source: |
[1] Def Stan 05-07, United Kingdom Ministry of Defence Standard 05-57 Issue 4 Configuration Management of Defence Materiel |
||
Version: | 1.1 | ||
Status: | in_business_review |
design information | |||
Definition: |
Information resulting from translating requirements for a product into a complete description of the product.
NOTE See: product definition information |
||
Source: |
[1] EIA/ANSI EIA-649-A, National consensus standard for configuration management , 2004. |
||
Version: | 1.1 | ||
Status: | in_business_review |
design review | |||
Definition: | 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. | ||
Source: |
[1] Def Stan 05-07, United Kingdom Ministry of Defence Standard 05-57 Issue 4 Configuration Management of Defence Materiel |
||
Version: | 1.1 | ||
Status: | in_business_review |
detection method | |||
Definition: | The method by which a failure/defect is detected. | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | in_work |
Detection of a symptom | |||
Definition: | An event that triggers one or more tasks. | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | in_work |
Determine exceptions | |||
Definition: | 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. | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | in_business_review |
Determine maintenance needs | |||
Definition: | ?? | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | in_business_review |
Develop change | |||
Definition: |
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.
NOTE 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. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Develop information management plan | |||
Definition: |
Development of the Information management strategy requirements and the customers contractual requirements to create the outline
Information Management (IM) model.
NOTE 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. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Develop information model | |||
Definition: | 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 . | ||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Develop solutions | |||
Definition: |
Production of solutions that may meet the change requirement.
NOTE The development stage of the change will identify a choice of solutions that may meet the change requirement. Viable solutions are developed so that the impact of each can be assessed. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_business_review |
Develop structures | |||
Definition: |
Assembly of physical and functional aspects of the PIF to form a well-structured skeleton.
NOTE 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 structurei ncludes parent-child relationships, aspects, networks and classification of products. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_work |
development plan | |||
Definition: | Plan of the activities required to develop and evaluate a possible change. | ||
Source: |
[1] PLCS Activity Model, 2000. |
||
Version: | 1.1 | ||
Status: | complete |
DEX Data Set | |||
Definition: |
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![]() |
||
Source: |
[1] DEXlib definitions, . |
||
Version: | 1.0 | ||
Status: | in_business_review |
DEXlib | |||
Definition: | 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. The ongoing work in the DEXlib development environment is published on a daily basis in HTML at (http://www.plcs.org/plcs/dexlib/dex_index.htm). | ||
Source: |
[1] DEXlib definitions, . |
||
Version: | 1.0 | ||
Status: | in_business_review |
directive | |||
Definition: |
Authority to perform a specified activity.
NOTE A directive may be communicated by an approved work order, responding to a work request. |
||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | complete |
disapproval | |||
Definition: | Recognised sanction that a product or process is neither complete nor suitable for its use. | ||
Source: |
[1] EIA/ANSI EIA-649-A, National consensus standard for configuration management , 2004. |
||
Version: | 1.1 | ||
Status: | in_business_review |
discard part | |||
Definition: |
A replacement part that is disposed after removal from a product needing support in accordance with the support solution.
NOTE A replacement part not technically or economically feasible to repair related to the product-in-focus. |
||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 4.1 | ||
Status: | complete |
disposal | |||
Definition: | Action to terminate ownership. | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 2.1 | ||
Status: | complete |
disposed element | |||
Definition: |
An element of the product, or its support system, leaving the control of the life cycle owner.
NOTE Disposed elements may include:
|
||
Source: |
[1] PLCS Activity Model, 2000. |
||
Version: | 2.1 | ||
Status: | complete |
document | |||
Definition: |
Information and its support medium.
NOTE Examples:
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. |
||
Source: |
[1] ISO 9000, Quality Management System - Fundamentals and vocabulary |
||
Version: | 1.1 | ||
Status: | in_business_review |
Document change opportunity/problem | |||
Definition: |
The conceptual visualisation and complete documentation of a change.
NOTE 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. |
||
Source: | PLCS OASIS | ||
Version: | 1.1 | ||
Status: | in_work |
documented problem | |||
Definition: | A change opportunity or identified problem complete with the change priority. | ||
Source: |
[1] PLCS Activity Model, 2000. |
||
Version: | 2.1 | ||
Status: | complete |
DRACAS | |||
Definition: | Defect Reporting And Corrective Actions System | ||
Synonyms: | defect reporting and corrective actions system | ||
Source: |
[1] PLCS terminology dictionary, 2000. |
||
Version: | 1.1 | ||
Status: | complete |
© OASIS 2010 — All rights reserved