RE: [plcs-dex] Representation of scrap

-----Original Message-----
From: Tim King [mailto:tmk@lsc.co.uk]
Sent: 13 August 2004 07:18
To: 'Barker, Sean (UK)'; Rob Bodington; plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Representation of scrap

a) I am not sure that this can be a concern only against this one topic. Any distinction in reference data is subject to this caveat. We have never had a PLCS requirement that says safety critical aspects will be modelled in a specific way;

b) does not take account of the role of Product_view_definition. That is meant to cover life cycle aspects. We probably need to classify the Product_view_definition as "scrapped" and put the dates there too;
[Tim Turner:] I agree, the product_view_definition has an initial_context, but also a set of additional_contexts of type View_definition_context. This is where perhaps the changes in lifecycle (state?) would be recorded. This needs to be kept in-step with the use of design/planned/realized entities in that they should not be contradictory.

c) does not take account of the proposal in my earlier e-mails. If there is a business need, each fragment becomes a new Product_as_realized instance (although I am getting a bit hesitant as to what the Part instance is under these circumstances);

d) I totally accept this point but believe that one of the fundamental principles that Rob has long advocated (and I had come round to) is that Product_as_realized.of_product does NOT point at the Part instance that is the design. A Product_design_to_individual instance establishes this link to a seperate Part_version & Part instance pair. This can be dated. I have not checked if the DEXs have gone down this route.
[Tim Turner:] Actually this is something that needs everyone's attention. The Product_as_realized is itself a version which of course is a separate instance from the Part_version from the design - but we need to be categorical about whether both point to the same instance of Part or to a different one. Yes - the Product_design_to_individual links the two versions together.

Given Shaun's statements about re-working individuals into other assemblies, isn't this a case of planning the dis-assembly of the Product (hence we can map an individual to a realization of this new design view), followed by a new assembly which uses the make_from_relationship for those assemblies re-using dis-assembled parts. I presume that the serial numbers of those dis-assembled parts would be carried over.

-----Original Message-----
From: Barker, Sean (UK) [mailto:sean.barker@baesystems.com]
Sent: 13 August 2004 12:04
To: Tim King; Rob Bodington; plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Representation of scrap

1) Rob is correct in stating that the aircraft industry concern is to ensure that scrapped parts are not reconditioned and illegally brought back into the maintenance system - this is a significant safety hazard. It is correct to say that this requirement does not entail the tracking of parts of the scrap item.

2) I would expect other industries to have other concerns, particularly with regard to the decommissioning phase - for example, meeting recycling legislation or disposal of hazardous materials. Here it is conceivable that some level of fragment tracking may be required.

3) Crash investigation is certainly concerned with the analysis of fragments, and allocating properties to them.

There are four objections to the use of classification and the preferring of a separate sub-type of product as individual:

a) As yet we have little experience of the use of reference data, and how it will be handled. In particular, a system may fail to transmit all classifications, or fail to correctly interpret them, and yet not show any error. This would not acceptable in the case of safety critical data, and although it may be possible to classify classifications as "safety critical, embedding such semantics in classification of classifications seems pushing things a bit to far.

b) The use of classification in such a way implies that we need to define a lifecycle for the entity against that classification, and that the behaviour of the entity changes once the classification is added. Classification is intend to add semantics, not change behaviour.

c) The use of classification excludes the ability to directly track fragments. The fact that there is not a business requirement to track fragments is not a licence to exclude such a requirement. Our objective has been to enable users to do their business, not to define limits on what they may do.

d) Unique Asset Identification allows for the case of a part retaining its individual identity even after it has been reworked into another part. That is, the product_as_individual is now an instance of two different parts. The problem is how to maintain the individual's history without retrospectively changing the relation to the original part.

This, in more detail, is the rationale behind the issue, and the suggest product_as_scrapped. Actually, product_as_scrapped is a bad name, being more a placeholder for one of the aspects of the requirement than a definitive request. In the light of (d) perhaps product_as_superseded may be better, with classification of the relation between the individual and the superseding individual being used to define how the product has been superseded. Since this classification is required to interpret the relation, this would be better than classifying the part itself.

Sean Barker
ATC Filton
0117 302 8184
-----Original Message-----
From: Tim King [mailto:tmk@lsc.co.uk]
Sent: 11 August 2004 14:49
To: 'Rob Bodington'; plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Representation of scrap

*** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message.

My preference is for classification. I was only intending that the next_assembly_usage establishes that the bits are the constituents of the original whole part. I did not mean to sound definitive that tracking of the scrapped parts was not appropriate. I just wanted to make the point that I would see the one original product_as_realized instance being able to refer to the broken bits in some circumstances. But if the part was out of a nuclear reactor then each bit is likely to become significant for tracking purposes.

-----Original Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 11 August 2004 14:35
To: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Representation of scrap

My understanding of the business requirement is that in the aircraft industry they want to be able to track scrapped parts to make sure that they don't somehow end up refitted to an aircraft. Hence the requirement to mark the actual product as scrapped. You won't do this if you only use next_assembly_usage as that only indicates that the usage is scrap. You'll need to indicate that the product_as_realized is "scrapped". Either by a new entity or by a classification. My question is which approach should we take.

Sean - why is important to track the bits of a broken part? Surely the requirement is track the part that has been scrapped? I agree with Tim, I see no business significance in tracking the fragments of a scrapped part.

Regards
Rob
-------------------------------------------
Rob Bodington
Eurostep Limited
Web Page: http://www.eurostep.com http://www.share-a-space.com
Email: Rob.Bodington@eurostep.com
Phone: +44 (0)1454 270030
Mobile: +44 (0)7796 176 401
-----Original Message-----
From: Tim King [mailto:tmk@lsc.co.uk]
Sent: 11 August 2004 14:15
To: 'Rob Bodington'; plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Representation of scrap
The option that comes to my mind is to use product assembly structure to link together the two or more "scrapped" product_as_realized bits to the product_as_realized original. The constituent links would have dates that reflect when the original was broken. The original would have the same date to reflect the breaking. I do not think that breaking destroys the identity of the original part. If glue can put the parts back together then the temporary existence of two parts might be considered to be of no business significance and those parts need never be given an identity.

Cheers,
Tim.
-----Original Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 11 August 2004 13:57
To: plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] Representation of scrap
Hi
Sean has raised the following issue against: Capability (C045): representing_product_as_realized
Issue: SMB-1 by Sean Barker (04-06-23) minor_technical issue
Resolution: Accept. Status: open
How are scrap items to be designated? (I would suspect that merely classifying them as "scrap" would be unsafe, and would not cope with items broken in two.)

I think that there are two ways of addressing this. Either by classification, or adding the entity "product_as_scrapped" to the product_as_individual module.

In other words, modifying the EXPRESS to
ENTITY Product_as_individual
ABSTRACT SUPERTYPE OF (ONEOF (Product_as_planned,
                                Product_as_realized,
                                Product_as_scrapped))
SUBTYPE OF (Product_version);
END_ENTITY;
ENTITY Product_as_planned
SUBTYPE OF (Product_as_individual);
END_ENTITY;
ENTITY Product_planned_to_realized;
realized_product : Product_as_realized;
scrapped_product : Product_as_scrapped;
END_ENTITY;
We may want a different term to scrapped.
Any views?
Regards
Rob
-------------------------------------------
Rob Bodington
Eurostep Limited
Web Page: http://www.eurostep.com http://www.share-a-space.com
Email: Rob.Bodington@eurostep.com
Phone: +44 (0)1454 270030
Mobile: +44 (0)7796 176 401
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED***   The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG

DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

plcs-dex message