So could someone propose the standard
names for parameters and document it in the Info section.
-----Original
Message-----
From: Peter Bergström
[mailto:peter.bergstrom@eurostep.com]
Sent: 09 January 2007 20:23
To: Tim Turner;
Gordon Robb; Barker, Sean (UK); rob.bodington@eurostep.com
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part template
I agree entirely (at least until I get to see your parameter
names… ;-)
Peter
From:
Tim Turner [mailto:tjt@lsc.co.uk]
Sent: den 9 januari 2007 21:14
To: Peter Bergström; Gordon Robb;
Barker, Sean (UK); rob.bodington@eurostep.com
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part template
Hi Peter,
thanks for the comments.
I agree with most - but see specific notes below.
Tim
From: Peter
Bergström [mailto:peter.bergstrom@eurostep.com]
Sent: 09 January 2007 04:19
To: Tim Turner; Gordon Robb;
Barker, Sean (UK); rob.bodington@eurostep.com
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part template
Thanks Tim,
Some more comments:
I try to make the parameter names as understandable and short as
possible, and would prefer something like:
id (for the main entity, i.e. Part in this case)
version_id (for any versions)
_ecl_id (for any rdl)
domain (instead of pvd_ad), or app_domain
life_cycle_stage (instead of vdc_lcs)
I'm not saying you have to use my names, but I think they are
easier to understand.
[Tim Turner] It
would be nice to have some standard convention. I also would like to abbreviate
some of these to shorten the length of some of the parameter names,
because it can be awkward to fit on some of the figures. Hence I see
little difference for example, in using 'part_version_id' over 'part_vn_id'.
With the exception to version, I pretty much already use the first 3 of
your suggestions, prefixed - by the relevant entity. I will enhance te others.
I would like you to define default values for the following
in-parameters, if possible:
Part_org_id_class_name
Part_vn_org_id_class_name
[Tim Turner] No
problem
I would also like you to change the class definition to include
'Organization_name' in the list, because it might just as well be the name, not
the code.
[Tim Turner] In fact
I should have been using the Organization_name, not the code. But we
should be able to specify either a name or a code. I have added
Organization_name to the input parameter type list accordingly.
The default value you have for vdc_ap is too generic (should not be
used), I propose to use 'Product_life_cycle_support' instead, since we've done
that in other places (I hate the term personally, but until something better is
agreed we should use it).
The default value you have for vdc_lcs is too generic (should not be used), I
propose to use 'Support_stage' instead.
[Tim Turner]Some of the above is mixed up - but I get your point.
The class Application_domainis perhaps too generic, but I would
propose to default to 'Product_life_cycle_support', but allow the usage of any
Discipline_design. This is because by representing a part we are
representing a design (of some description). Likewise, the class 'Product_life_cycle_support' should be
replaced with Life_cycle_support, but defaulted to Support_stage.
Peter
From:
Tim Turner [mailto:tjt@lsc.co.uk]
Sent: den 9 januari 2007 03:11
To: Peter Bergström; Gordon Robb;
Barker, Sean (UK); rob.bodington@eurostep.com
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part template
Version 1.2 now uploaded.
Characterizastions still to be added.
From: Tim
Turner
Sent: 08 January 2007 10:14
To: Peter Bergström; Gordon Robb;
Barker, Sean (UK); rob.bodington@eurostep.com
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part
Notes below.
Will be completing draft 1.2 of the template for another 'round of
review' by end of today.
regards,
Tim
From: Peter
Bergström [mailto:peter.bergstrom@eurostep.com]
Sent: 08 January 2007 10:07
To: Tim Turner; Gordon Robb;
Barker, Sean (UK); rob.bodington@eurostep.com
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part
Im lost, Tim.
What are you suggesting to make optional?
- The id of part_view_definition?
[Tim
Turner] Yes
- The assembly/detail classification on Part?
[Tim
Turner] Yes
- The assembly/detail classification on Part_category?
[Tim
Turner] Replaced by above
Or what aspects are you referring to?
Peter
From:
Tim Turner [mailto:tjt@lsc.co.uk]
Sent: den 8 januari 2007 15:09
To: Gordon Robb; 'Barker, Sean
(UK)'; 'rob.bodington@eurostep.com'; Peter Bergström
Cc:
'plcs-dex@lists.oasis-open.org'
Subject: RE: [plcs-dex] RE:
representing part
I think
we are happy with the conclusion that these aspects will become optional.
Any
objections?
From:
Gordon Robb
Sent: 08 January 2007 05:57
To: 'Barker, Sean (UK)'; Tim
Turner; rob.bodington@eurostep.com; Peter Bergström
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part
We do
seem to go round in circles. This type of discussion was taking place over 3
years ago. I think what is needed is an example of a 'Change [modification] to
a product that is in service and also still in production with a frozen set of
APSI [Product Configuration Information [PCI]]. The 'change APSI' would then
dictate the number of changes that is necessary to the production and
in-service support engineering with the necessary "views". In
the 1st instance keep the example simple using KISS principles.
-----Original Message-----
From: Barker, Sean (UK)
[mailto:Sean.Barker@baesystems.com]
Sent: 08 January 2007 09:57
To: Tim Turner;
rob.bodington@eurostep.com; Peter Bergström
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part
One use
for which product_view_definition seems appropriate is the distinction between
the shape of a part as used in an assembly, the shape of a part as manufactured
for assembly, and the shape of a part as manufactured for spares. For example,
parts may be supplied with only some of the fixing holes drilled, with the
remainder being drilled with the part offered up to ensure accurate alignment
of holes between the part and the thing it is fixed to. Further, access paths
and jigs may be available in the initial assembly process which are not
available for field maintenance, which may mean that the spare differs from the
shape for initial assembly.
Sean Barker
0117 302 8184
From: Tim
Turner [mailto:tjt@lsc.co.uk]
Sent: 08 January 2007 01:26
To: rob.bodington@eurostep.com;
'Peter Bergström'
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part
|
*** 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.
|
The real issue here (to
me) is about ensuring that the correct
part_view_definition
(PVD) is used at the correct time for the correct reason.
There
should only be a single View_definition_context linked through the
inital_context attribute of the PVD (others are possible through the
additional_contexts). Hence Rob is correct in the sense that so long as
you only have a single PVD connecting to the Part Version, the associated VDC
that can be used to identify the PVD.
However,
there is nothing to stop another PVD from being defined for the same
Part_version, with the same VDC for another purpose (e.g. racing
bike 1 vs racing bike 2 view). This is important since one PVD may also
carry with it other related information such as property assignments & the
other may not. Without distinguishing between the two, I don't see how you can
identify the correct PVD.
The fact
that this is not seen so often may be because most exchanges
(post-design stage) are perhaps only focussing on one, or other end products -
and not specifically about multi-product design information. This
muli-product design view may be of more interest to the originating OEM
than to most others, hence I agree that making it optional may make most sense,
since it is in the post-design phase in which were are focusing.
From: Rob
Bodington [mailto:rob.bodington@eurostep.com]
Sent: 05 January 2007 10:44
To: 'Peter Bergström'; Tim Turner
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part
Why do
you need to Id View_definition_context
explicitly ?
The
identifier is provided by the "life cycle stage" and the
"application context".
[Tim Turner] Both of which are
attributes set through reference data that are asigned to the VDC, which
may not be unique.
What
would be really nice would be to have a standard set of "life cycle
stage" and the "application context"
[Tim Turner] The PDM Usage guide has a
number of these defined, which I think were carried over as examples in
AP239; e.g
application_domain:
the text that identifies the application
context that bounds the universe of discourse.
EXAMPLE 1 'assembly study', 'digital
mock-up', 'electrical design', 'mechanical design', 'preliminary design',
'process planning' are examples of application domains
If application_domain
is an empty string, the View_definition_context
shall be considered as not specific of any application domain.
life_cycle_stage:
the text that identifies a stage in the
life cycle of a product.
EXAMPLE 2 'design phase', 'production',
'recycling phase' are examples of life cycle stages.
If life_cycle_stage
is an empty string, the View_definition_context
shall be considered as not specific of any life cycle stage.
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)1452 810 960 (note new number)
Mobile: +44 (0)7796 176 401
-----Original
Message-----
From: Peter Bergström
[mailto:peter.bergstrom@eurostep.com]
Sent: 05 January 2007 15:38
To: rob.bodington@eurostep.com;
Tim Turner
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part
Regarding id on part_view_definition:
I have seen nobody make use of this id. In STEP files I have seen,
it has always been left empty, or it has been a made up id for the sake of
STEP...
I think it should at least be optional.
Talking about identifiers and View_definition_context:
I am really missing an identifier for View_definition_context,
since these are going to be 're-used' for many imports/exports, and it is very
important to be able to identify the View_definition_context and not start
creating new View_definition_context by mistake.
But this is not covered in any schema as far as I know, and I think
this is too late to change in AP239 now....
Peter
From:
Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: den 5 januari 2007 16:05
To: 'Tim Turner'
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE:
representing part
Anyone
else have views on this?
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)1452 810 960 (note new number)
Mobile: +44 (0)7796 176 401
-----Original
Message-----
From: Tim Turner
[mailto:tjt@lsc.co.uk]
Sent: 05 January 2007 05:30
Cc: plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] RE:
representing part
From: Tim
Turner [mailto:timturner11@bellsouth.net]
Sent: 04 January 2007 21:54
To: 'rob.bodington@eurostep.com'
Cc:
'plcs-dex@lists.oasis-open.org'
Subject: RE: representing part
Hi Rob,
see
below.
Regards,
Tim
From: Rob
Bodington [mailto:rob.bodington@eurostep.com]
Sent: 04 January 2007 12:01
To: Tim Turner
Cc: plcs-dex@lists.oasis-open.org
Subject: representing part
Hi Tim
I have had a quick look at
representing part template.
Could you make the EXPRESS-G
diagrams look like all the other diagrams (i.e. ones drawn by GraphicalExpress,
so is it possible to change the font and the colour of the entities?).
[Tim Turner] Will be done - just
want to concentrate on the template instantiations first.
Picky / subjective I know but
perhaps we could adopt a convention for how to draw the
product/versio/defitnion entities form top to bottom? Rather like has been done
in product as realized? ... just a suggestion
[Tim Turner] Time will
dictate
I am not sure that I agree with
passing in the detail as to whether the part is a part or assembly.
What is that supposed to tell the
receiving system?
That the part is an assembly (just
about every part is and assembly from someone's point of view)
Or is it telling me that there is
assembly information in the file.
[Tim Turner] Best see the issue
log on that - RBN-9 & the resolution which was posted. Essentially, the
intent was that once the representation of the part has been setup (Part,
Part_version & PV_definition) a reference to the Part (via a
Part_version) will enable a receiver of (just the reference & related
instances) to tell if the Part is composed of an assembly or a single item
etc.. without having to exchange the entire assembly model or breakdown to
dtermine this fact. This is useful in exchanges where the full product
model is not known to all parties.
It does
not imply whether the full assembly info is in the file or not, just that it
either exists or does not.
[RBN] I still think that this is
a really bad idea!
I think that we imposing a business
practice.
One persons detail is another person's
assembly.
If I send you a part + its assembly. Then I
send you a file that refers to that part. All I need to do is provide
sufficient information to identify the part.
I do not need to send you the assembly
again, nor do I need to tell you that you already received it.
In other words the sending system should
not have to tell someone whether they have received a part or not, the importer
should work that out.
I have spoken to several people who
have worked on production systems, including some PDM schema implementations.
In nearly all cases they do not send this information. Primarily because in
most cases whether something is a detail or an assembly changes depending
on who you talk to. Also a detailed part may have product structure and an
assembly may have no product structure. (think of a carbon fibre composite. Its
starts off as an assembly of plies, which end up as a component ).
In exchanges where detail and assembly were
provided, stating whether something was a detail or an assembly was subjective,
and the receivers of the information ignored it.
I recommend that we should make this type
of information optional. If a business practice needs it then you can add it,
but don't force it on everyone else.
The where rule (which is
horrible and restrictive) is:
ENTITY Part
SUBTYPE OF (Product);
WHERE
WR1: SIZEOF(['part', 'raw material',
'tool']*types_of_product(SELF))=1;
END_ENTITY;
Why not just have a default product category which is the 'part; to make the
model valid.
[Tim Turner] Yes - there is a default
product_category which is setup in this manner and connected to the Part
through the product_category_assignment to make the model valid.
[RBN] So remove the following and make it
optional as assigning ref data to the part (not the category)
-- provide the type of
the part by classification
/assigning_reference_data(
items=Product_category,
class_name=@detail_or_assembly_type,
ecl_id=@part_ecl_id)/
This should be reflected in the
EXPRESS-G
[Tim Turner] Agreed
The
instance of product_category is further classified with the detail/assembly
info to distinguish between those which may have an assembly or breakdown
model. By default, the classification is set to detail (i.e has no
assembly/decomposition defined for it).
[RBN] See above - but I really do not think
that we should do this in the template
I am not sure that we need to
identify the part_view_defnition - surely that is identified by the view
definition context?
[Tim Turner] As I understand it,
to fully represent a Part, the view definition is required, but you are
correct a definition can be identified by one (or
more) view_definition_contexts. However, this is only defining a view
(which may not be unique). To uniquely identify the Part_view_definition
within a design, which may have several assembly options for potentially
many product representations and variants it would seem reasonable to associate
an identifier to it as depicted in C001 - especially if this data needs to be
maintained over time.
[RBN] The uniqueness of the part view
definition is provided by the view_defn_context (Any system will have a set of
view_dfn_contexts - these will be unique) and the part version to which the
part view defn is attached.
Again, the production implementations that
we have seen do not need the id and either make it up or ignore it.
I am assuming from the instantiation
path that the following parameters
part_creator_org_id(Type='STRING')
part_creator_org_id_class_name(Type='CLASS')
part_creator_org_id_ecl_id
are to identify the part - they are
not necessarily the organization that created the part - more the organization
that owns the identifier that is being provided. So perhaps they should not
have creator in the name e.g:
part_org_id
[Tim Turner] Point taken.
You are also assuming that the same
organization owns the id for the part and the version .... is that always going
to be the case?
[Tim Turner] This can be
separated out to take account of where this is not the case. I had been using
my tunnel vision and thinking that where parts are getting
"re-badged" within another setting, a supplied_part_relationship
would be used between the supplied part and the new one created for
reselling/after-market usage. Of course, this would assume that the original
supplier info was available.
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)1452 810 960 (note new number)
Mobile: +44 (0)7796 176 401
This message contains
information that may be privileged or confidential and is the property of
Eurostep Group. It is intended only for the person to whom it is addressed. If
you are not the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any part thereof.
If you receive this message in error, please notify the sender immediately and
delete all copies of this message.
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.
********************************************************************
|
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
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