[11] NS: better define it as ‘predicted_operating_environment’.
[12] LdB: a particular usage_scenario instance could be ‘all usage scenario’
[13] LdB: ‘anticipated service life’.? Is it a supportability requirement?
[14] NS: overlap with SEDRES? Needs better explanation.
[15] LdB: see ISO/CD 10303-44 Annex E ‘Examples’
[16] LdB: see ISO 10303-41 product_property_schema, product_representation_schema, measure_schema
[17] NS: Failure is too strong. Suggest to use Anomaly
[18] Ldb: it should be recognized that not all tasks are generated by the failure analysis. For example, the availability of a new software upgrade is not a failure but give rise to tasks.
[19] NS: RCM also produces output that needs to be captured.
[20] NS: wrong. Maintenance level is an attribute of task and product_design association. LDB: and usage_scenario?
[21] NS: assumes date returns ‘days’ as integer.
[22] LDB: e.g. product_physical_design instances classified as ‘on board sensor’ or ‘built-in test equipment’.
[23] LDB: this would allow the definition of base_stages (the building block) prior to their assignment to a task.
[24] LDB: method_stages with the same description but with different resources are in fact different method_stage(s).
[25] NS: The value for role should be given by a separate entity enabling a standard set of value to be defined by a given project/organization and referenced rather than duplicated.
[26] Martin Scalway’s note: item 2 talks about a product instance being owned, whereas item 13 talks about it being controlled. I would suggest that ownership is a form of control and that the data model would be simpler if this were recognised. I would therefore eliminate item 2 and re-word item 13 as follows:“A product instance maybe controlled by 0,1 or many organisations at a given point in time in one or more control methods”. Control methods will then need to be defined, but financial ownership, physical custodianship and responsibility are potentially three examples.
[27] SD: also more than one?
[28] NS: No. States need to be treated separately
[29] SD: What about the journey between two locations?
[30] NS: plus accuracy or tolerance
[31] NS: needs to be expanded
[32] JD: need to address ‘obsolescence’. Is it a support discrepancy?
[33] NS: it may have reached end of life without becoming defective but still be replaced.
[34] JD: need to differentiate between ‘WHAT’ is the identified resolution (i.e. what is being changed) and ‘HOW, WHEN or by WHOM’ it should be implemented. Suggest to split the entity implementation_directive into two entities: identified_resolution and implementation_directive
[35] LiC: a request can also be a request for modification to support testing, for examples, drilling a hole into a vehicle so that a camera be mounted to record a dtest shot of a new weapon. Mounting the camera is temporary, but the hole is permanent and only a single product_instance is affected.
[36] LdB: this approval means that the request contents are approved as request. There is no implication of approval to implement.
[37] LdB: there may be many implementation directive that result from a single request.
[38] LdB: Example: the request analysis may lead to a resolution that address a different product_design(s) from those identified in the request.
[39] LdB: This is the approval of the implementation directive (when, why and by whom the change is to implemented)
[40] LdB: This is the approval of the applied resolution.
[41] Note: does this deal adequately with changes to documents and other items related to product e.g. the support tools? How far do we need to go in cross-referencing changes. One request could lead to many hundreds of detailed changes.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.