OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

plcs-dex message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [plcs-dex] RE: Capability (C045): representing_product_as_rea lized - Representing a product as realized - Issues [2/5]


Title: RE: [plcs-dex] RE: Capability (C045): representing_product_as_rea lized - Representing a product as realized - Issues [2/5]

Dear All,

I do not see the issue here as being a simple "version change".

There are several aspects covered by the previous messages:

- the design is a set of assembly and configuration option rules (a Part & Part_version correspond to the bike or airfcraft for the top-level of the assembly);

- these rules can change, e.g. the specification of a new brake assembly, which I believe will lead to a business decision as to whether this is a new design version (new Part_version) or a new part number (new Part).  At the top-level assembly, I would not normally expect a new brake assembly to lead to a new bike part number (but if the brake assembly is quite different then the brake will perhaps have a different part number);

- the Product_as_realized needs a breakdown to identify which of the configuration options are current (dates on the Breakdown_element_realization provide history).  Tim Turner and I have just been discussing that in some circumstances, the Breakdown_element_realization will be to a Part_view_definition that corresponds to a Part_version (design) and sometimes to one that corresponds to a Product_as_realized (this depends on whether the configuration option is in the form of an item that is managed by serial number or not);

- the Product_as_realized needs a Product_design_to_individual to identify the current applicable design (and the history through dating all instances of this entity).  This establishes the applicable assembly rules.  However, the Breakdown_element_realization indicates the actual design in place at any given time, either through Product_as_realized or Part_version (see previous point);

- the VIN and registration plate can both be identification assignments on the Product_as_realized.  Use of dates will indicate the different applicability of these identifiers (e.g. the registration plate might change when someone buys a personalised plate and the number can be re-used on a different vehicle at some later date);

- the only thing I can never remember our working agreement on is the of_product attribute of the Product_as_realized but I think that this points at a Product instance that is not the design and does not correspond to a specific part number (because this can change, see above).

That is the way I see it anyway ...

Cheers,
Tim.


-----Original Message-----
From: Blenkiron, Adrian S [mailto:adrian.blenkiron@rolls-royce.com]
Sent: 13 July 2004 10:16
To: 'Rob Bodington'; 'Gordon Robb'
Cc: 'Plcs-Dex teams (E-mail)'
Subject: RE: [plcs-dex] RE: Capability (C045): representing_product_as_rea lized - Representing a product as realized - Issues [2/5]


Hi Rob/Gordon,

the "tail number" was a particularly bad example to choose. I agree with Rob; the aircraft will have a manufacturers' serial number, separate from the tail number. The manufacturers' serial number is what I regard as "product serial number" (even though we don't see this very often). In the car example the VIN is the (manufacturers') serial number and the registration plate number the equivalent of the tail number. It was the VIN number that caused Rob's car to be recalled, though of course this may be linked (by the dealer network) to a particular registration number and hence owner.

Is the distinction that you are discussing at all related to the difference between PERMANENT changes (ie the brake assembly) or REVERSIBLE changes (night fighting equipment)?

If the distinction is between change to an individual product, selected products or all products then we are in the murky (at least to some of us!) world of configuration change management, and we know who is the world's expert on that subject!


HTH, Regards  

Adrian
Landline +44 (0) 117 979 5820
Mobile +44 (0) 788 0798 370
-----Original Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 13 July 2004 09:54
To: 'Gordon Robb'
Cc: 'Plcs-Dex teams (E-mail)'
Subject: [plcs-dex] RE: Capability (C045): representing_product_as_realized - Representing a product as realized - Issues [2/5]


Thanks Gordon
I see what you are saying but I would have thought that what you describe is really a different configuration of an individual Harrier, not a version.

I always understood a version to mean a product that has had a change made to it. E.g.
My car has had a product recall and a new brake assembly fitted.
The car is now at version 2.
The change to the brake assembly was not a configuration option, but the result of a change directive (choose your favourite business term). Hence there is a new version of the car. I would never remove the brake assembly unless another change was to be implemented. In your Harrier examples, the Harrier is being configured according to mission, not according to product changes.

I understand that some products have a "strike" plate which gets marked according to the changes that have been implemented.

The product has the same serial number, but the changes has been applied, so the configuration record reflects a new version.

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: Gordon Robb [mailto:gor@lsc.co.uk]
Sent: 13 July 2004 09:16
To: 'Rob. Bodington (E-mail)
Cc: Plcs-Dex teams (E-mail)
Subject: Capability (C045): representing_product_as_realized - Representing a product as realized - Issues [2/5]

Hi Rob,
I  note the following issue is still open
Issue: RBN-1 by Rob Bodington (04-03-13) minor_technical issue
Resolution: Accept. Status: open

How are Product_as_realized versioned? Does each version keep the same serial number and then just have a new version number assigned?

ANSWER - Yes - the product keeps its original serial No. thru life. The version depicts its operational 'capability'.
e.g - A Harrier GR 5 serial ZX 138 is a day attack fighter/bomber, the same aircraft (ZX 138) converted to a GR 7 version provides an additional night attack capability. On the product configuration status record (CSR) it would show additional OEM references, a CUM No. ( a as designed serial number as identified on the drawings; a LBS (line build sequence) No as depicted on the manufacturing process. This provides the traceability of the product thru both 'design and manufacture linked to the actual operators serial (in this example 138)

I understand in a commercial aircraft environment the OEM serial for the product would  be the 'master' in respect to the realized products CSR, the tail no. would be a 'master' in respect to operator.

In the PLCS bike example the serial of the bike remains the same irrespective if it is in racing or road wheel 'trim'/version.

regards
 Gordon

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




The data contained in, or attached to, this e-mail, may contain confidential information. If you have received it in error you should notify the sender immediately by reply e-mail, delete the message from your system and contact +44(0)1332 242424 (the Rolls-Royce IT Security Director) if you need assistance. Please do not copy it for any purpose, or disclose its contents to any other person.


An e-mail response to this address may be subject to interception or monitoring for operational reasons or for lawful business practices.


(c) 2004 Rolls-Royce Group plc


Registered office: 65 Buckingham Gate, London SW1E 6AT
Company number: 1003142. Registered in England.


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]