This document explains use of the EACM modules to record information about the identity of a product, of an activity in which a product is involved, and of a state in which a product exists.
Each of the concepts - product, activity and state - can be subjected to Product Data Management.
A principal focus of the EACM is:
The modules covered by this document are:
There are three principle concepts:
the whole life of a physical thing;
This is the identity of a thing throughout its whole life. There is no obvious name for this concept, so I suggest 'individual product'.
a segment of the life of a physical thing;
A segment in the life of a physical thing is an individual activity. Usually, we think of an activity as something more abstract because most activities are carried out by complex assemblies of physical things including people.
However, consider a material test. This is an activity carried out by people, a test machine, a surrounding environment, and a test specimen. We can divide this activity up into smaller sub-activities. At the most detailed level, there is the straining (say) of the test specimen itself. This is a segment of the life of the test specimen which takes it from an initial state to a final state.
an instant in the life of a physical thing.
An instant in the life of a physical thing is an individual state. A physical thing changes from instant to instant, so that the individual state is continuously changing. When we say that a physical thing stays in the same state, we mean that each individual state of the thing in a sequence is a member of the same class of state.
The design and analysis is concerned with classes. A designer creates a 'product design'. This is a class that an individual product can be a member of. An individual product that is a member of the class is 'to the product design'.
A product design has many different design criteria, so that an individual product is to the product design if, and only if, it meets all the criteria. Each criterion is itself a class, so that a product design is the intersection of a set of classes.
EXAMPLE - A design of a beam specifies:
- a length of 10 m (with a tolerance of 10 mm);
- a breadth of 2 m (with a tolerance of 5 mm);
- a depth of 4 m (with a tolerance of 5 mm);
- a maxmum cover of 20 mm over all reinforcing bars;
- the six arrangement and specification of the reinforcing bars;
- the specification of the concrete, and the method of pouring and curing.
An individual beam that meets each of these criteria is to the design. An individual beam that fails one or more of these criteria is not to the design.
A beam length between 9.99 m and 10.01 m is a class. It has each individual beam with a length in this range as a member.
During the design process it is possible that either:
When a design is refined, the new design is a specialisation of the old. The relationship between different designs is within the scope of the PDM modules, and not within the scope of the EACM modules.
A designer specifies the criteria for compliance with a design. An analyst predicts the consequences of compliance with a design, as shown below.
A design and a requirement are different things from the point of view of a business process, but are the same thing from the point of view of the EACM.
A product requirement has many different component criteria, so that an individual product meets the requirement as a whole if, and only if, it meets all the criteria. Each criterion is itself a class, so that a product requirement is the intersection of a set of classes.
EXAMPLE - A requirement for a beam specifies:
- a length of 10 m (with a tolerance of 20 mm);
- an in-service lifetime of greater than 100 years;
- a load of greater than 80 tonnes at failure.
An individual beam that meets each of these criteria meets the requirement as a whole. An individual beam that fails one or more of these criteria does not meet the requirement as a whole.
The beam design defined in the previous example meets these criteria. It meets the length criterion 'by design'. It is predicted to meet the in-service lifetime and the failure load criteria.
A design satisfies a requirement if each individual product to the design meets the requirement, as shown below.
The designs 'beam type XYZ' and 'beam type PQR' both satisfy 'my beam requirement because each individual product to these designs satisfies the requirement. The design 'beam type UVW' does not satisfy the requirement because its manufacturing tolerances are too broad. Some individual products to this design meet the requirement, but some do not.
The relationship between a design and a requirement is within the scope of the PDM modules, and not within the scope of the EACM modules.
The difference between a requirement and a design is determined by the business process. Consider the following classes:
Usually, properties to do with performance are specified for a requirement, but are predicted for a design. Usually, properties to do with form are not part of a requirement, but are specified for a design.
What properties are valid for a requirement and what properties are valid for a design, depends upon the particular business activity and cannot be specified in a generic information model. The EACM treats all properties the same, and merely says whether or not they are specified or predicted.
In a design assembly, some parts of the assembly can be designs and others can be requirements.
EXAMPLE - The design for bolted joint XYZ specifies:
- the form of the flanges;
- the number and position of the bolt holes; and
- the diameter of the bolts;
- the required yield strength of the bolts.
Hence the design for bolted joint XYZ is an assembly that contains required bolts. The requirements for the bolts specify:
- required length;
- required diameter;
- required yield strength.
A design for the bolt, containing information about the material, head and thread has not yet been created or selected.
The absence of a design for the bolts need not prevent some analyses of the joint as a whole.
In the EACM, the application object Specific_product_specification is a class that can be a requirement or a design or a combination of these. Whether or not a Specific_product_specification is a design or requirement is determined by its relationship to a business activity.
An enumerated set of similar individual products, such as an ensemble of test specimens or a particular production run, is also within the scope of the EACM and is also a Specific_product_specification.
The EACM application object Specific_product_specification maps to the STEP resource entity product_definition.
A Specific_product_specification is a class that an individual product belongs to throughout its life.
Similarly there are classes that an individual activity or an individual state belongs to. If we were consistent in terminology, then we would call these:
For simplicity it is intended to call these classes Activity and State instead. (It is not possible to have an uniformly simple approach because the word 'product' has been given a specific meaning by the PDM schema.)
This simple example considers a test carried out upon a test specimen, and a simulation of the test by a finite element analysis.
The example is taken from ASTM E 1434 - 93 'Standard guide for development of standard data records for computerization of mechanical test data for high-modulus fiber-reinforced composite materials', in 'ASTM standards in the building of materials databases', ASTM 1993.
The test specimen T5999-25-3/101 is subjected to a test.
Using the terminology of the ARM for this part of ISO 10303, the test specimen is an Individual_product.
The ARM instance corresponding to this individual product is as follows:
#201 = INDIVIDUAL_PRODUCT (); -- test specimen T5999-25-3/101
NOTE - There is much information that could be supplied about this individual product which is outside the scope of this discussion, including:
- the identification of the specimen;
- a membership relationship with the set of specimens tested as an ensemble;
- a 'made from' relationship with the stock material.
The test specimen is:
Each item in this list is a class that the individual product is a member of. The class '12 plies' can be regarded as a Property<. The class 'machined to pattern PDA-SK463331' can be regarded as a Specific_product_specification.
NOTE - There are some classes that sit in a grey area between Property and Specific_product_specification. In the EACM, both concepts are handled in a similar way and the choice is arbitrary. The choice is made when the dictionary of instances of class necessary to support the application is defined. The compiler of the dictionary decides whether 'layup [0]:12' (say) is a standard instance of Property or a standard instance of Specific_product_specification.
The only difference between a Property and a Specific_product_specification within the EACM is that a Property can be identified by a mathematical value with respect to a unit of measure, whereas a Specific_product_specification cannot.
Even this distinction is superficial, because a Specific_product_specification can be part of a parametric product space and identified by a parameter value.
Each classification of the test specimen by a class in the list can be specified separately. Alternatively a Specific_product_specification can be defined that is the intersection of the classes in the list. The test specimen is then classified once by this intersection class. Both approaches are supported by the EACM.
The ARM instances that record the classes are as follows:
#202 = SPECIFIC_PRODUCT_SPECIFICATION (); -- Graphite/Polyimide IM6/Avimid KIII #203 = SPECIFIC_PRODUCT_SPECIFICATION (); -- layup code [0]:12 #204 = PROPERTY (); -- 12 ply #205 - SPECIFIC_PRODUCT_SPECIFICATION () -- machined to pattern PDA-SK463331
NOTE - The way in which the standard instances of Specific_product_specification are identified within a dictionary is not within the scope of this discussion.
NOTE - The way in which the nature of the Property as 'number of ply' is specified, and the way in which the Property is identified by the number 12, is not within the scope of this discussion.
The ARM instances that record the separate classifications of the test specimen are as follows:
#206 = CLASSIFICATION (#202, #201); #207 = CLASSIFICATION (#203, #201); #208 = INDIVIDUAL_POSSESSION_OF_PROPERTY (#204, #201); #209 = CLASSIFICATION (#205, #201);
The ARM instances that record the intersection Specific_product_specification; its relationship to the other classes; and the classification of the test specimen as a member of the intersection, are as follows:
#210 = SPECIFIC_PRODUCT_SPECIFICATION (); /* Graphite/Polyimide IM6/Avimid KIII composite, layed up to code [0]:12, with 12 ply, and machined to pattern PDA-SK463331 */ #211 = SPECIALISATION_OF_CLASS (#202, #210); #212 = SPECIALISATION_OF_CLASS (#203, #210); #213 = POSSESSION_OF_PROPERTY (#204, #210); #214 = SPECIALISATION_OF_CLASS (#205, #210); #215 = CLASSIFICATION (#210, #201);
The specimen subjected to test activity 1988-12-31/01 carried out by PDA/MDL in Albuquerque, New Mexico.
This test activity involves many things - people, test machines and an environment, as well as the test specimen itself. There is a component activity 'straining of specimen in 1988-12-31/01', which is carried out solely by specimen T5999-25-3/101.
The ARM instances that record:
are as follows:
#216 = INDIVIDUAL_ACTIVITY (); -- test 1988-12-31/01 #217 = INDIVIDUAL_ACTIVITY (); -- straining of specimen in test 1988-21-31/01 #218 = INDIVIDUAL_COMPOSITION_OF_ACTIVITY (#217, #216); #219 = ACTIVITY_ASPECT_OF_INDIVIDUAL (#201, #217);
There is a great quantity of information that can be recorded about the testing activity as a whole. Selecting for this example, we can record that the testing activity is:
Both the items in this list are classes. The ARM instances that record:
are as follows:
#220 = ACTIVITY (); -- ASTM D 3039:1982 #221 = PROPERTY (); -- cross head speed 2.5 mm/min #222 = CLASSIFICATION (#220, #216); #223 = INDIVIDUAL_POSSESSION_OF_PROPERTY (#221, #216);
The individual activity 'straining of specimen in 1988-12-31/01' is something which we may wish to simulate by finite element analysis. The analysis is appropriate to any similar test specimen, and so the analysis is of a class of activity or activity design.
The ARM instances that record:
are as follows:
#224 = ACTIVITY (); /* straining of Graphite/Polyimide IM6/Avimid KIII composite specimen, layed up to code [0]:12, with 12 ply, and machined to pattern PDA-SK463331 at 2.5 mm/min' */ #225 = ACTIVITY_ASPECT_OF_PRODUCT (#210, #224); #226 = CLASSIFICATION (#224, #217);
The test takes the test specimen T5999-25-3/101 from an initial state to a final state through a sequence of intermediate states.
The ARM instances that record:
are as follows:
#227 = INDIVIDUAL_STATE (); /* Initial state for straining of specimen in test 1988-21-31/01 */ #228 = INDIVIDUAL_STATE (); /* Final state for straining of specimen in test 1988-21-31/01 */ #229 = INITIAL_STATE_FOR_INDIVIDUAL_ACTIVITY (#217, #227); #230 = FINAL_STATE_FOR_INDIVIDUAL_ACTIVITY (#217,#228);
There is a great quantity of information that can be recorded about the states of the test specimen. Selecting for this example , we can record that:
Using the 'loose' approach suggested in the usage guide for the property application module, the temperature of 24 degrees Celsius can be regarded as a classification of the whole straining activity. All the other items in this list can be regarded as classifications of either the initial or the final state of the test specimen for the straining activity.
The ARM instances that record:
are as follows:
#231 = PROPERTY (); -- 24 degrees Celsius #232 = PROPERTY (); -- 0.6% moisture content #233 = PROPERTY (); -- 0.0 strain #234 = PROPERTY (); -- 0.0117 strain #235 = STATE (); -- stable #236 = STATE (); -- failure #237 = INDIVIDUAL_POSSESSION_OF_PROPERTY (#231, #217); #238 = INDIVIDUAL_POSSESSION_OF_PROPERTY (#232, #227); #238 = INDIVIDUAL_POSSESSION_OF_PROPERTY (#233, #227); #239 = INDIVIDUAL_POSSESSION_OF_PROPERTY (#234, #228); #240 = CLASSIFICATION (#235, #227); #241 = CLASSIFICATION (#236, #228);
The individual states 'initial state for straining of specimen in 1988-12-31/01' and 'final state for straining of specimen in 1988-12-31/01' are something which we may wish to predict by finite element analysis. The prediction is appropriate to any similar testing activity, and so the prediction is about a class of state or state design.
The ARM instances that record:
are as follows:
#242 = STATE (); /* initial state for straining of Graphite/Polyimide IM6/Avimid KIII composite specimen, layed up to code [0]:12, with 12 ply, and machined to pattern PDA-SK463331 at 2.5 mm/min' */ #243 = STATE (); /* final state for straining of Graphite/Polyimide IM6/Avimid KIII composite specimen, layed up to code [0]:12, with 12 ply, and machined to pattern PDA-SK463331 at 2.5 mm/min' */ #244 = INITIAL_STATE_FOR_ACTIVITY (#224, #242); #245 = FINAL_STATE_FOR_ACTIVITY (#224, #243); #246 = CLASSIFICATION (#242, #227); #247 = CLASSIFICATION (#243, #228);
The preceding sections record:
There are many measured properties that can be recorded for each of these individuals.
An analysis is carried out for a test specimen design or class, and an activity design or class. The analysis can give a prediction of the stress field within the specimen for each state (design) within the activity (design). The recording of a property variation with respect to state, position within a physical object, or both, is discusses in the usage guide for the property application module.
For the final state (design), the analysis predicts a stress field, and hence a load. The individual final state of the test specimen complies with (is a member of) the final state design. The actual load for the individual final state can be recorded - it may or may not be consistent with the prediction.
The testing machine is an individual product that is involved in the testing activity. It is possible to record, either the identification of the test machine or both.
The ARM instances that record:
are as follows:
#248 = INDIVIDUAL_PRODUCT () -- the testing machine; #249 = CLASSIFICATION (#250, #248); #250 = SPECIFIC_PRODUCT_SPECIFICATION (); -- United FM-20-AE #251 = INDIVIDUAL_ACTIVITY (); -- role of test machine in test 1988-21-31/01 #252 = INDIVIDUAL_COMPOSITION_OF_ACTIVITY (#251, #216); #253 = ACTIVITY_ASPECT_OF_INDIVIDUAL (#248, #251); #254 = CLASSIFICATION (#255, #251); #255 = ACTIVITY (); -- role of test machine
NOTE - The identification of the test machine by manufacturers serial number, or by testing laboratory tag number, is not within the scope of this discussion.
NOTE - The identification of the product design as 'United FM-20-AE' is not within the scope of this discussion.
NOTE - The activity design or class 'role of test machine' is a standard instance. This class would be defined in a dictionary of standard instances appropriate to material testing.
It is usual to produce a set of specimens from the same batch, and to test each in the same way. This approach enables a judgement to be made about the repeatability of the test and the reliability of the test results. A set of individual test specimens is an Explicit_product_specification.
NOTE - Most relationships with Specific_product_specification are also valid for Explicit_product_set, so the two entities have a common supertype Product_specification_or_set.
A Specific_product_specification is a design or requirement, and has:
- deemed properties that are the criteria for membership; and
- properties that are predicted to be a consequence of membership.
An Explicit_product_set is an enumerated set of individual products, and has:
- being a member of the enumerated set as the sole criterion for membership;
- properties that are predicted to be a consequence of membership; and
- measured properties with statistics.
Similarly, an Activity can be an enumerated set of individual activities, and a State can be an enumerated set of individual states.
The ARM instances that record:
are as follows:
#256 = EXPLICIT_PRODUCT_SET (); -- enumerated set T5999-25-3/1 #257 = SPECIALISATION_OF_CLASS (#210, #256); #258 = CLASSIFICATION (#256, #201);
The ARM instances that record:
are as follows:
#259 = PROPERTY_SPACE (); - specimen width; #260 = PROPERTY_DISTRIBUTION_FUNCTION (#256, #259); #261 = MEAN_OF_PROPERTY_DISTRIBUTION_FUNCTION (#260,#262); #262 = POINT_PROPERTY (); -- width 12.9 mm #263 = STANDARD_DEVIATION_OF_PROPERTY_DISTRIBUTION_FUNCTION (#260,#264); #264 = PROPERTY_RANGE (); - width range 12.847 mm - 12.953 mm
NOTE - Statistics for a property distribution are discussed in the user guide for the possession of property statistics and probability application module.