The Express diagrams presented in this section are provided as visual aids to better describe the requirements and NOT as modeling solutions.
What is "PRODUCT"?
Defining a "product" is complex because there are many ways of looking at the same thing. STEP defines a product as "a thing or substance produced by natural or artificial processes." Use of the word `produced' in the above definition may communicate the idea that a product is always a physically existing object. This is not true. At the very early stage of its life cycle, a product may exist as simply as concept described by the customer needs and operational requirements. At the end of the design phase a product may be seen as physically realizable object or `design.' It becomes a physically existing object only at the end of the manufacturing process. Once realized the product is to be supported throughout the life cycle.
To manage products over their life cycle it is necessary to address these different views of product and to distinguish between the product "As Required," "As Designed," "As Built" and "As Maintained."
This can be accomplished as follows:
The life-cycle of a product starts with the definition of a product_concept that is the idea of a product as defined by customer needs. The `AS REQUIRED' view of a product is defined by the mission need that created the demand for the product and is described by its required functionality (product_requirement: e.g., expected features, capabilities, performance, et cetera);
The design activity, based on the required functionality, progressively defines the physically realizable objects or the `AS DESIGNED' view of the product. The set of related designs is then used to manufacture a quantity, possibly thousands, of physical products (product_instance);
The exact configuration of each of these product_instance(s) in terms of parts/components identification (e.g., by serial number and/or lot number) defines the `AS BUILT' view of the product.
Later in the life-cycle, each product_instance is maintained, repaired and part/components are replaced due to malfunctions or configuration changes. All information related to these activities identify the `AS MAINTAINED' view of the product.
In its broadest sense, a product consists of the sum of its product_concept + product_requirement + product_design + product_instance.
These objects are closely inter-related as shown in Figure 1. Relationships should be maintained throughout the life-cycle.
Figure 1 - The Product Architecture
The product_concept object is the collector or common root for all subsequent objects. The product concept is the idea of a product as defined by customer needs. It identifies a deliverable product as perceived by the customer (e.g., an item in the catalog of a supplier).
A product_concept may exist without a product_design or a product_instance. It is related to the object product_requirement that describes the required performance or behaviors of the deliverable product. The object product_requirement, in turn, is related to product_design making it possible to relate functionality to design.
The product_design object is the container of (1) functional design, (2) physical design and (3) support design. It is related to product_concept and to product_instance. The latter is the relationship between a specific actual object (identified, for example, by its serial number) to the design information from which it was developed. This relationship is optional since it is not always possible or necessary to relate product_instance(s) to a product_design.
The product_instance object is the container of data related to the ACTUAL physically existing object (e.g., an actual helicopter with a tail number).
The Viking Perspective
The VIKING objective is " ... to improve product availability by improving the quality and availability of the technical information needed to support the complex Viking product in-service." The term product in this definition should be seen and understood as the product_instance described above (only a physically existing object may be supported).
For Viking the main focus will be placed on the product_instance object.
To support a product_instance in-service, we need to know its ACTUAL configuration, role, condition state, maintenance history, and operational history (AS BUILT, AS MAINTAINED). Then we need a mechanism to link the product_instance to (1) the maintenance directive resulting from the support engineering activity; and (2) to the technical data resulting from the functional and physical design activity. In this proposed architecture, the linking mechanism between product_instance and the other product objects is achieved through relationships.
In Figure 2, each diagram in the stack is a coherent network of information. For each physical instance of the engine (e.g., Engine with S.N. 003), it is possible to navigate through the relationships to identify requirements, design information, and logistic information that are applicable for the specific engine.
Figure 2 - Product_instance relationship
This is true for all the specific engines that have been manufactured. In fact, there is a specific and unique set of data and relationships for each product_instance.
In this way, the effectivity of configuration, technical data, and logistic tasks to product_instance is explicitly defined through relationships.
Product Concept
A product_concept is the idea of a product as conceived by the user. It will often correspond to the items supplied to the user (e.g., an item in the catalog of a supplier). The definition of product_concept(s) is driven by user's needs and by user defined usage scenario. It represents the idea of a product based on user viewpoint and NOT as it might be designed or manufactured.
The basic relationships of product_concept are described in Figure 3.
Figure 3 - Product_concept Basic Relationships
Some detailed information requirements are the followings:
· a product_concept is defined by a name, an identifier and a textual description;
· the product_concept identifier is the combination the user organization identifier and a unique identifier assigned by that organization. It is assumed that the user organization issues unique identifier within its domain;
· product_concept(s) may be classified, decomposed, and aggregated. Class of product_concept should be defined;
· product_concept(s) may be versioned and may be subject to Configuration Change Control (configuration item);
· a product_concept may be related to different contexts or usage scenarios. This relationship is a many-to-many since the same product_concept may have many usage scenarios and a usage scenario may apply to many different product_concept(s);
· a usage_scenario may be described by:
· environment conditions (e.g., temperature, pressure, wind velocity);
· user conditions (e.g., human capability and limitations, national laws and regulations);
· support conditions (e.g., support resources, pipeline times);
· mission phase (e.g., landing )
· Simple conditions may be combined with AND, OR and XOR operators to define complex usage_scenario(s);
· Usage_scenario(s) may be organized in classes. Most probable scenario and worst-case scenario in peacetime and wartime employment are examples of usage_scenario classes.
Product Requirement
A product_concept in a specific usage_scenario may be characterized by a set o required or expected product features, performance or behaviors identified by the user or derived by the user's needs.
Figure 4 - Product_requirement Basic Relationships
A product_requirement relates to one or more product_concept_usage_scenario association and to zero, one or more product_design. This implies that a product_requirement instance may exist without a product_design but it could not exist without a product_concept and the associated usage_scenario.
Product requirements have a number of associations with organizations. A typical association is the one used to identify the organization defining the requirements.
Some specific data requirements could be the following:
· Product_requirement(s) may be classified, decomposed and aggregated;
· A complex combination of product_requirement(s) with conditions may be specified by composing one or more product_requirement(s) that are related by conditions;
· Classes of requirement may be defined. Some product requirement classes may be:
· Constraint definitions (e.g., budget constrains, human limitations);
· Functional requirements (e.g., to provide an output voltage of 24 Volts plus-minus 0.5V);
· Operation requirements (to work ceaselessly for 2500 hours in usage_scenario n.2). Includes also mobility, mission frequency and duration;
· Support requirements (to be repaired on site within 48 hours);
· Physical requirements (not more than 5 Kilos);
· Change of a product_requirement should be addressed by configuration change control entities such as change request, implementation directive and applied solution (see paragraph 6.7.1.1);
· Associations between a predecessor product_requirement and a successor product_requirement should be maintained. This association states that the successor requirement is created by modifying the predecessor requirement;
· Product_requirement(s) may be described by using STEP IRs constructs such as property definition, property representation and measure schema;
Product Design
The product_design object has a number of relationships with the other views of the `product' (see Paragraph 6.1 and Figure 5).
Figure 5 - Product_design Relationships
The product_design may consist of functional design, physical design, and support design. These three components are related each other, making it possible, for example, to derive the product_physical_design instances that are involved in a function or the product_support_design instances applicable for a particular physical design.
Product Functional Design
The product functional domain describes what activities are performed, within a system, in one or more usage scenario, to fulfill a requirement.
The diagram in Figure 6 describes the basic relationships:
Figure 6 - Product_functional_design Basic Relationships
A function could provide a service, process materials or change the state of the system environment. Functions form a hierarchy, with the top level being the function of the product_concept itself and the bottom level being individual actions.
For example if `Electric Generator' is the product_concept, the functional hierarchy top level would be `Produce Electric Power' with such sub-functions like `Provide Fuel to the Combustion Chamber' which in turn could be decomposed into "Store Fuel," "Supply Fuel" and "Inject Fuel." The functional analysis is useful to identify the physical products that need to be designed to perform the activities (e.g., in our case: the fuel tank, the fuel ducts and the injectors.)
In the above example, only mechanical functions are involved. In other cases, we may have functional hierarchies that include a set of interacting sub-functions some of which could be mechanical, some information processing, and some hybrid (both). The function "Track Target," for example, may be an abstraction of the functions "Identify Target," "Obtain Current Position," and "Maintain Course." The realization of these functions may involve diverse technologies such as radio communications, radar tracking, interaction with a GPS satellite and computing equipment to calculate a course.
Functional design is not achieved solely by hierarchical decomposition of top-level function. In addition to hierarchical relationship, functions may interact in many other ways. For instance, a function could be activated based on the result of a previous function. In this case, a chain of functions is defined. In the above example the function `Obtain Current Position' cannot be activated until the function `Identify Target' has been completed.
A typical relationship in the chain is the one between a caused_function and a causing_function meaning that the first is affected by a status change of the second. In a wider sense, each function may be controlled by a behavioral interface or `control-port' that affects its state.
Some of the data requirements for product functional design are the followings:
· A product_functional_design relates to one or many product_concept(s) and to zero, one or more product_requirement. This implies that a product_functional_design instance may exist without a product requirement, but will always be related to at least one product_concept;
· A product_functional_design is realized by zero, one, or more product_physical_design;
· A product_functional_design is uniquely identified by the combination of the designing organization identification and by the identifier assigned by that organization;
· A product_functional_design may be controlled by zero or one organization at a given point in time in one or more control methods;
· Control methods should be defined. Authority for approval is an example of control methods.
· A product_functional_design may be categorized. A class of product_functional_design may in turn be organized in a class hierarchy;
· Agreed classes of product_functional_design should be defined;
· A product_functional_design may relate to another product_functional_design;
· The rationale for the relationship between two product_functional_design(s) shall be defined (e.g., a functional breakdown);
· A mechanism to trace function execution sequence (causal_chain) should be provided;
· A function may be associated with zero, one or many control_port(s);
· A function cannot be activated unless all control_port objects associated with the function are enabled.
· Whether a control_port is enabled is decided by the value and type of its attributes;
· A product_functional_design has multiple representations in various formats such as plain text, structured text (SGML, HTML, XML), drawings, video, audio or external documents.
The diagram in the Figure 7 covers most of the above requirements:
Figure 7 - Product_functional_design High Level Model
Product Physical Design
Product physical design is an abstraction of product_instance or the design of a product_instance. It may be used to represent the design throughout the design phase, from the initial design through detailed design including variations in the design that may meet different requirements or different functionality.
The subject of product_physical_design is the identification, the classification, and representation of designs and the relationships between them.
This relationship may define a product design in term of its product structure as a set of constituent product designs.
A product_physical_design has a number of relationships with other views of product (see Figure 5).
Some detailed information requirements are the following:
· Each product_physical_design is identified in the context of an organization. This implies that the same product_physical_design may have multiple identifications for different organizations.
· Different types of product reports should be possible by using the product_physical_design. These reports should be able to describe the product structure to many levels of details. Level of details may address, for instance, the degree of decomposition (e.g., single level or multi level) and the type of decomposition (e.g., exploded, flattened, indented ... etc);
· Bill of Material, Part List, Illustrated Part Catalogue Structures are example of product reports;
· A product_physical_design is characterized by zero, one or more properties;
· Product_physical_design properties may be represented using STEP IR constructs;
· In addition, product_physical_design properties may be represented by plain text, structured text (SGML, HTML, XML), drawings, video, audio or references to external documents;
· Product_physical_design may be classified. Class of product_physical_design may in turn be organized in a class hierarchy;
· A class of product_physical_design may have a set of predefined properties that must or may be filled-in to represent a product_physical_design instance that is a component of that class;
· Product_physical_design changes should be addressed by change process information such as change request, implementation directive, and applied solution.
Product Support Design
In simple terms, the objective of support engineering is to determine what can go wrong with a product and what has to be done to sustain availability (see 5.1.1). This includes actions to repair or to prevent problems from occurring.
Basically, support engineering consists of Failure Analysis, Task Analysis, and Spares Analysis. These activities are conducted on the basis of the user's Support Requirements. (Note: support requirements, a sub-type of product_requirement, relates to the association between product_concept and usage_scenario).
The focus in this section is NOT on how these Analysis are conducted, but on the information that are generated by these activities (output) that constitute the logistic technical information needed to support a product_instance during its life-cycle.
Failure Analysis
It is assumed that, at the end of the design phase, a residual number of predictable failures still exist. This occurs because it is either impossible or not cost effective to eliminate the failures or because they result from external agents. Each one of these predictable failures should be addressed by a maintenance strategy to:
· Reduce the risk of failures to a minimum (preventive maintenance);
· Provide a remedy should the failure occur (corrective maintenance).
A failure involves a product_physical_design while performing a certain function in a particular usage scenario.
More precisely, the predicted failure of a product applies to one or many product_physica_design and happens in the context of one or many product_functional_design and of one or many usage_scenario. (See Figure 8).
Figure 8 - Failure Context
A failure is described by its:
· Cause: failure causes may be classified as internally generated within the system by an inherent property of the product or produced by external factors (usually human or environment);
· Effect: failure effects fall into two major classes: local_effects (e.g., increased engine smoke) or failure_inducing_effects (e.g., failure in an oil pump leading to a failure of the engine).
The notion of failure_inducing_effects introduces the need to manage a cause-effect chain. At a very simple level, two failures, Failure 1 and Failure 2, may be associated to define that Failure 2 is caused by Failure 1.
In a more complex situation, Figure 9, a particular failure (Failure 4) will occur only if two other failures (Failure 1 and Failure 2) occur together or if a third (Failure 3) occurs by its own and not with the first two.
In a cause-effect chain it should be possible to combine failure causes with:
AND operators, when the related causes must occur together;
OR operators, when the related causes can but need not occur together;
XOR operators, when the related causes are mutually exclusive.
Figure 9 - Consequential Failures
The association between failure and effects may be used to capture additional information such as probability and safety hazard severity (e.g., critical, minor, none).
Detection Method: the detection method describes how the operator or the maintenance technician detects a specific failure. Warning devices, test equipment, and their normal or abnormal indication are described by the detection methods.
Task Analysis
The basic objective of the task analysis is to define necessary tasks for the support and operation of the product. Reliability Centered Maintenance techniques can be used to decide what needs to be done to either correct a failure or to prevent a failure from occurring.
A task applies to one or more product_physical_design instances. These are not necessarily the same product_physical_design instances identified in the failure analysis.
A task is performed in a support_scenario that describes under which conditions (environment, national regulations, available skills, etc) the task is expected to be performed.
The diagram in Figure 10 describes the task context.
Figure 10 - Task Basic Relationships
A task provides the instructions on how to perform a particular activity or action.
Some information requirements related to task are the followings:
· Task(s) may be classified. Servicing Tasks, Scheduled Tasks, Occasional Tasks are examples of task classes;
· A task may relate to another task for a particular reason;
· The possible rationale for two task(s) to be related should be defined. Alternate task(s) is an example of this rationale;
· Maintenance level, criticality, and other qualifications may be assigned to a task;
· Some task characteristics such as time to perform and cost may be derived by the roll-up of sub-task attributes;
· When and whether to perform a task depends on conditions. A simple condition may define, for example, that a task is to be performed every three months (e.g., do task `A' IF date(current)-date(task_A_last_done)>90);
· Simple conditions may be combined with AND, OR and XOR logical operators to define more complex conditions (e.g., do task `A' IF date(current)-date(task_A_last_done)>90 .OR. mileage(current) - mileage(task_A_last_done) > 3000 );
· Condition monitoring may require that certain parameters of product_instance and support_scenario be measured and recorded. Where data is collected automatically, the source sensor should be identified.
· A task is usually decomposed in elementary task stages or steps that may be seen as modular building blocks. Tasks may be defined by assembling the elementary (base) stages using selected criteria.
Some requirements for base_stage are the followings:
· A base_stage may be assigned to zero, one or many task(s). This implies that a base_stage may exist without a task and that the same base_stage may be assigned to many task(s);
· A base_stage may be either a method_stage (what to do) or an advisory_stage (warnings, cautions, ... );
· A task shall include at least one method_stage;
A method_stage may be described in different forms, e.g., by a simple narrative description of what to do or by more sophisticated forms of representations such as video, audio, virtual reality;
Some resources may be needed to perform the activity described by a method_stage. Resources may have a role (e.g., spare parts, consumables, test equipment, calibration equipment, etc.) and may be quantified;
The identified resources include the following:
· Facility_or_infrastructure: this may be a reference to a generic facility (e.g., 220V power supply) or a generic infrastructure (e.g., a dry-dock). It also may be a reference to a specific named and located facility;
· Information_requirement: a reference to the applicable information (drawings, wiring diagram, manuals);
· Personnel_with_skill: a reference to the needed skill subject and grade
· Material: it is a reference to part, subassemblies that play a role in the method_stage. This includes tools and support equipment;
· Time: optional definition of the expected time required to perform a method_stage. Time qualifiers may be mean time, maximum time, etc.
· Money: optional definition of the expected cost to perform a method_stage;
· Build in facilities in the existing product;
· Consumables (e.g., oil, water .. )
Having defined the entities task and base_stage, there is still the need to define how the base_stage(s) are assembled together to form a task.
Basically, a task may be seen as a linear flow or sequence of base_stage(s). In such simple instance, Task `A' is made up of Step `1' (the base_stage) followed by Step `2' and so on.
More frequently, however, the flow of actions is not a plain linear sequence of base_stage(s). For example, the flow of actions (what to do next) may depend on the results of a test condition.
A flow control structure that is external both to task and to base_stage may be used to alter the flow of actions of a task. Use of a control structure would enable Interactive Electronic Technical Manual (ITEM) style functionality to be provided directly from the Product Life-cycle Support database. The constructs that should be supported by the control structure are the following:
· Base_stage_sequence: it is the list of base_stage(s) to be carried out in order;
· Control_transfer: rather than referencing a base_stage, the control structure is allowed to call another base_stage_sequence or even another task. This means that tasks and sequences can be nested within each other;
· Conditional_transfer: enables a choice between different routes depending on the result of a test condition. The choice could be between two alternatives (IF ... ELSE ... ENDIF) or between many (DO CASE . CASE ... ENDCASE);
· Looping_method: enables one or more base_stage(s), base_stage_sequence(s) or task(s) to be repeated. There are three ways of controlling the numbers of repeats and these can be combined:
1. Repeat_count: repeat a specified number of times (FOR ... NEXT);
2. Repeat_until: repeat until a test condition is met (DO UNTIL ... ENDDO;
3. Repeat_while: repeat while a test condition remains true (DO WHILE ... ENDDO).
· Concurrent_methods: gives a group of base_stage(s), base_stage_sequence(s) or task(s) to be carried out during the time it takes to do the longest.
Together these provide a capability not unlike a programming language so that tasks can be structured flexibly, and tracked and presented with IETM style functionality.
Product Instance
A product_instance is the physical realization, through the manufacturing process, of a product_physical_design. In this paragraph, the term product_instance refers to a specific physical object (e.g., Helicopter with tail number 97-01).
Some detailed requirements for product_instance are the following:
· A product_instance is the physical realization of zero or one product_design. The relationship between product_instance and design is optional since it will not always be possible or necessary to establish this relationship;
· A product_instance is owned by exactly one organization at a given point in time. Ownership may change over time during the life-cycle. The capability to associate a date and time with an ownership change and to maintain history of ownership shall be provided;
· A product_instance is manufactured by one or more organizations;
· A product_instance is supplied (sold?) by one or more organizations
· The combination product_instance identification and the assigning organization identification will uniquely define the product_instance;
· A product_instance may have a serial number that enables to distinguish it from other product_instance(s) based on the same design;
· A product_instance may have a lot or batch number that enables identification of a group of units of the same design which are manufactured or assembled by one producer under uniform conditions and which are expected to function in the same manner. A block identifier may be assigned to designate a quantity of consecutive production of product_instance(s) which will have similar characteristics;
· A product_instance may have both a serial number and a lot number. At least one of the two is necessary to identify the product_instance. If both are assigned, a correlation of serial numbers and lot numbers is to be maintained;
· The capability to assign additional customer defined identifiers should be provided. If multiple identifiers are assigned, their correlation is to be maintained;
· A product_instance may be categorized in classes of product instance. A class of product_instance(s) may in turn be organized in a class hierarchy;
· Possible classes should be defined. Class of product_instance may include role, function and condition state (e.g., "in repair," "spare parts").
· A product_instance structure may be the assembly of other product_instance(s). As a minimum, a product instance structure should include the component product_instance identification.
· A product_instance structure may be subject to changes due to a configuration variant or replacement of defective items. The old components (predecessors) and the new components (successors) shall be identified. The capability to associate a date, time and organization responsible for the change with each change implementation and to maintain history and rationale of changes shall be provided;
· Product_instance structure changes due to configuration variant shall be referenced by Configuration Change entities such as change_request, implementation directive and applied_solution;
· A product_instance may be controlled by zero, one or many organizations at a given point in time;
· Control of a product_instance may have different forms (e.g., operational, logistics, storage, etc.). There is exactly one controlling organization associated with each control form at a given point in time;
· Product_instance control may change over time during life-cycle. The capability to associate a date and time with each transfer of control and to maintain history of control shall be provided;
· A product_instance exists at one location at a given point in time. It may be moved from one location to another. The capability to associate a date and time with each change of location and to maintain history of location change shall be provided;
· A product_instance is characterized by the properties defined for the related product_design;
· In addition, a product_instance is characterized by zero, one or more actual characteristics that are either measured from or assigned to the object. Qualifiers (e.g., calculated, measured) may be applicable to characteristics.
· Product_instance characteristics may be organized in classes. A class of product instance characteristics may, in turn, be part of a class hierarchy;
· Product_instance characteristics may be subtyped according to their representation. Possible subtypes are:
1. Narrative: described by a textual description;
2. Quantified: defined by a measure and a unit of measure;
3. Point in time: defined by a date and time;
4. Period: defined by a time measure.
· The capability to maintain product_instance(s) maintenance history and operational history shall be provided:
1. Maintenance history may include date, type, responsible person/organization;
2. Operational history may include running hours, flight hours, shell fired;
· A product_instance may be used as the alternate for another;
· A product_instance operates in one scenario at a given point in time. This relates to the information_objects and tasks defined for that scenario (e.g., maintenance tasks in desert operations);
· Zero, one or many actual functionality may be related to a product_instance.
The diagram in Figure 11 is a high level model that covers most of the above requirements.
Figure 11 - Product_instance High Level Model
Product_instance(s) have a number of relationships with organizations; these include identification, ownership, and control. Ownership relationship is the easiest to understand. In this model, an ownership change (e.g., the action of selling) is covered by recording a new ownership relationship and setting the end effectivity for the previous ownership. The current ownership is identified by the relationship that has a date for a start effectivity and has a blank field (empty date) for the end effectivity.
This concept of start effectivity and end effectivity is not shown in the high level model in Figure 11 but most of the above relationships make use of it.
A product_instance may relate to another product_instance. A typical relationship is the product_instance_assembly that defines a parent-child relationship between two product_instance(s) in an assembly structure. This relationship is used to describe, for example, that the Accelerometer with Serial Number 100267 is part of the Guidance Set with Serial Number 0982701 which is mounted on the SS-01 Missile with the Serial Number 003982-45.
The product_instance_succession relationship identifies that one product_instance (predecessor) has been replaced by another product_instance (successor) for an identified reason. This entity may communicate information such as that the Accelerometer with Serial Number 100267 replaced, on 09 July 1998, the Accelerometer with Serial Number 100208 because of an out of tolerance reading during the preventive electronic test.
A product_instance may be classified. This classification should not replicate information already defined in the product_design classification or product_design properties. The fact, for example, that the ETS with Serial Number 018992 is an M09 Electronic Test Equipment used to check the SS-01 Missile Guidance Set is information already available through the relationship to the product_design schema. A class of product_instance(s) could be, for example, the class "in Repair." This would give the capability to query the database and derive the list of product_instance(s) that are under repair. In any case, the possible product_instance classes should be constrained in an Agreement of Common Understanding between the partners sharing this information.
A product_instance has characteristics. It is important to distinguish between product_design properties and product_instance characteristics. For example, the fact that the size of the ETS with Serial Number 018992 is 30x20x20 +/- .05 cm. is a property of product_design not of product_instance: in fact all M09 Electronic Test Equipments have the same size. A product_instance characteristic would describe, for example, that the ETS with Serial Number 018992 is painted in red for a particular user defined color coding.
There is a requirement to support forward maintenance schedules. For example, let's assume that the Support Engineering analysis identified a specific calibration task to be performed every 6 months on the M09 Electronic Test Equipment. This information is part of the AS DESIGNED view of the product. Data available for the ETS with Serial Number 018992 (AS MAINTANED view) indicates to us that it was last calibrated on 30 June 1998. It is therefore possible to schedule the next calibration of ETS M09 S.N. 018992 for the end of December 1998.
Configuration Management
Configuration Management applies to a wide variety of data objects. From a life-cycle perspective, the configuration management addresses product requirements, product design, specific physical instance, and their relationships.
Different life-cycle organizations may have different views over what configuration items they need to manage.
For example:
· The user may decide that he will control configuration of product_instance(s) while the product_design configuration control will be the responsibility of the equipment supplier;
· The main contractor may decide not to maintain configuration control of items supplied by a subcontractor.
In any case, a standardized interface is needed to exchange consistently configuration information across different users of the system.
Configuration Management essentially deals with (1) Configuration Identification and (2) Configuration Change.
Configuration Identification (CI)
The subject of CI is the identification of items, the composition of which is to be managed. The item to be managed is specified as a Configuration Item. It is usually under control of the organization that does Configuration Management.
The identification of the Configuration Items is dependent on viewpoints.
The User Perspective
The Configuration Items from the user perspective are the product_instance(s), End Item) usually identified by a serial number, and their main Components also normally identified by serial numbers. Whether to consider particular Parts as Configuration Items is a user decision. Configuration Identification from the user perspective is achieved at three different levels:
At the atomic level, Components and Parts should be identified by the manufacturer's identification and a unique identifier assigned by the manufacturer to differentiate between units of product (Serial Number) or between groups of product (Lot Number). If additional user identifiers are defined, correlation between them should be maintained.
At the assembly level, the product_instance structure should be uniquely identified by the top element identifier, e.g., End Item or Component, by the identification of all atomic elements that are used in the assembly and by the relationships between them.
At the macro level, product_instance which are Configuration Items should be unambiguously linked to the AS DESIGNED and to the AS REQUIRED views of the product (see figure)
Configuration Identification: The User Perspective
In the above figure, the Truck with Plate Number UI-3210 (user identifier) will be identified by its primary key and by the foreign keys inherited from the parent data entities. The complete identifier would be:
GC-991.RN-01.GC-082.PN-011.GC-354.SN-4030.GC-076.UI-3210
The Engine mounted on Truck with Plate Number UI-3212 has a NATO Stock Number as user defined ID. In this case its completed identifier would be:
GC-991.RN115.GC-082.PN-02960.GC-354.SN-00323.GC-076.NSN-2219
The Designer Perspective
To be developed
| 
