· maintenance history may include date, type, responsible person/organization ;
· operational history[31] may include running hours, flight hours, shell fired;
72. a product_instance may be used as the alternate for another;
73. 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);
74. zero, one or many actual functionality may be related to a product_instance.
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 which 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 relationship make use of it.
A product_instance may relate to another product_instance. A typical relationship is the product_instance_assembly which 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 June1998. It is therefore possible to schedule the next calibration of ETS M09 S.N. 018992 for the end of December 1998.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.