plcs-dex message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [plcs-dex] Assigning identifiers with no organization
- From: Tim Turner <tjt@lsc.co.uk>
- To: "'Barker, Sean (UK)'" <sean.barker@baesystems.com>, "'plcs-dex@lists.oasis-open.org'" <plcs-dex@lists.oasis-open.org>
- Date: Thu, 10 Nov 2005 01:54:57 -0000
Title: Message
Hi Sean,
I admit, there is perhaps an issue to say that these part
relationships should ideally be in representing_parts rather than in
assembly_structures. The context though, is usually through an assembly &
identifiying the source of the part, rather than beginning at a part. Having
said that, generating a parts list etc., inc. source organizations would need
this if present.
If an OEM is managing parts then I would expect to see a
full set of information enabling the UID to be in place.
With that said, a
part instance and it's corresponding instance of part_version would then
have both an organization & a date-time stamp associated with them.
Assuming that the original part instance then gains another
part number (2nd identification) with a detailed, although different orgn,
but no
additional version id set on the existing instance of part_version, then it
has to be assumed that any version is acceptable. The default
(usually) being the latest version issued.
Thus the version
refered to by receivers of data from Orgn 2 (b) in your example below will be
the one issued by either Orgn1 or Orgn3 depending upon the date-time stamp set
alongside the respective versions. If the
order presented below is in date order (the last being the newest), then it
will be R0.
If there is no date-time stamp, then the latest managed
version should be identifiable by recursing through the
product_version_relationship aspect of the model to establish
which was the preceeding version and which the successor. However, this assumes
that the product_version_relationship has been populated. If it has, then it
requires distinct instances of part_version.
Thus, by definition, the answer is not unambiguous, but
that's due in part to catering to the chaotic side of some businesses &
also in part to PLCS being so flexible.
I would say one more thing about this. PLCS creates the
possibility that this data could be represented inconsistently but correctly in
an exchange file. For example, the version sequence defined through the
product_version_relationship attributes could be used incorrectly to assign the
older version as the successor and the newer version as the predecessor
(relating vs related issue) - which would be obvious if each carried a date-time
assignment, but less so if the date were not present. I don't believe that there
are any constraints to ensure against this.
Regarding the problem faced by a distributed
environment. I think the digital mock up assembly of C003 provides for the
basic case where a subcontractor is detailing the design of a sub-assembly and
creates the new parts. In such a case the subcontractor need not require or need
to see the full product model. On receiving the sub-assembly design, the prime
contractor would then capture this using their own part numbering mechanism
through the drawing envelope mechanism described alongside the text of
supplied_part_relationship in C003. The point here and question that this
raises, is whether the prime contractor should then maintain this relationship
in future exchanges downstream in the lifecycle.
I also understand that in a tightly integrated, but
distributed/subcontracting envrionment, the prime may issue the subcontractor
with a set of part numbers to use in advance (though I guess that must be pretty
close to the final design iteration). Thus, if the subcontractor uses their own
part number scheme & then maps them to those provided by the prime, I would
assume they would be responsible for providing both sets of this information an
the exchange file to the prime.
These discussions probably are best in a workshop type
environment, as there is a lot of detail to read & the examples are not as
thorough as they should be (need instance diagrams), but the results should be
made visible & documented where necessary.
Regards,
Tim
NB You are right about the description in C003 does show
separate instances of part rather than a single instance as I described in b),
which I think is fine, except that this was documented wrt compatibility with
the PDM schema usage without this issue in mind. The reason to point to the same
instance of part was because of reducing the amount of redundant data if
only another part number is added. For example, all the product_category rules
and other associations that a specific instance of product has, will need to be
satisfied in order to complete the product model. I believe though, that two
distinct instances of part (one for each part_version) should be acceptable, but
then the new part id should not be assigned to both.
Tim,
Thanks for point the section in
representing assembly structure out - its not somewhere I'd have thought to
look.
How I read it was, in the case of a supplied
part, rather than apply two identifiers to the same part, two separate parts are
identified as being identical. (I assume that the details are only described
once under one of the parts). I think this is different from your description in
b).
[Tim Turner Replies:] There is a
little difference
The problem with an organization using the same id as
another only occurs when there is a third organization which then assigns both
an id and a separate version id:
a) Org 1
assigns item id=A123 and version id=V1
b) Org 2 assigns item id=B456 but no
separate version id (your (e))
c) Org 3 assigns item id=C789 and
version id=Rev0
What is the version reference for Org 2 - V1 or Rev0.
Perhaps one solution is to apply two organization assignments to V1, one ORg 1
as identifier_owner, the other Org 2 as identifier_user?
The problem of updating multiple version numbers in a
distributed organization remains, since any one transaction may only see the
updates from a subset of the organizations.
I guess this is a problem best discussed in a
meeting.
Sean Barker
0117 302 8184
All, interesting
discussion. Here's my my 2-cents worth...
Creating sense from chaos is always a valuable
thing to do. However, it is the lack of application of any standard that creates
the chaos. Should we then really be trying to bring order to the chaotic rather
than trying to enforce the regimen of control?
Maybe I don't appreciate the point here, but I don't think
that I have seen the argument that invalidates the advice agreed in C001/2 &
3. For instance;
a) C002 - Representing _parts quite clearly states
that both part & part_version shall have their id assignments classified and
that the organization responsible is assigned to the id. The date and time of
this is optional. C001 Representing Identifiers states that a single
instance of part may have more than one identifier assigned to it. This would
include distinctions of the relevant organizations as stated above and this
caters for the re-numbering of parts.
b) Re-versioning of parts is a little different in that
(for this scenario of suppliers re-issueing OEM products), a second instance of
part_version should be created. The supplier organization details are again
added to the identifier that is assigned to the second part_version. Both
part_version instances point to the original part instance. The two part_version
instances are then related by an instance of supplied_part_relationship (C003 -
representing_assembly_structure).
c) The supplied_part_relationship establsihes the original
OEM part_version (which is identified as a particular version along with the OEM
responsible) as the relating_version and the new supplier part_version as the
related_version. Each part_version is identifiable through the organization
assigned.
d) If a different part number has been assigned, by the
supplier organization, this will be available through the identification
assigned to the part by the same organization. If no new part number has
been assigned then the user has no alternative but to use that provided by the
OEM as provided.
e) If no version id has been issued by the supplier, then
there will be no additional part_version identification with the supplier
organization's details assigned to it. Hence the OEM version will have to
be used.
f) Where a supplier updates the versioning info for the
same product (e.g. decides to re-package it), then there should be a third
instance of part_version created and related by an instance of
product_version_relationship (of type 'sequence) between the two supplier
versions. However, this is only necessary if they wish to manage their version
numbers. If this is not important then we can just go back to step b) above
& treat as if re-versioning the part for the first time.
It is not required to establish another
part_view_definition which refers to the new version, although it may be
adviseable if trying to select information from a supplier's viewpoint. In doing
so, the initial_context should be identical, but there should be another
(additional context) which provides the supplier's context. It should be
clear, however, that the original OEM assemblies in which the part is located,
are linked through the original part_view_definitions, not the suppliers. The
supplier is, of course, able to define a
separate assembly.
Note, if we were to assume that only the original
part_version instance is used, and we assigned the new supplier's version
identifier (& orgn details) to the original version (whence there will be
two identification assignments (with respective orgn details) to the single
instance of part_version), we cannot then use the supplied_part_relationship as
this requires two distinct part_versions.
Not providing the assigning organization details for a new
part_version (as I think was mentioned a few emails back) will create a
problem if there are multiple identifiers for an instance of part. In this
situation is necessary, I would suggest that another instance of part is created
for the supplier's part numbers. The two can again be related by the
supplied_part_relationship. In either case, a new instance of part_version
should be created.
I don't know that
providing identical part_version identifiers is necessary or desireable, just as
it would seem unecessary to create identical part numbers - if only to signify
that the supplier uses the same numbers as issued by the
OEM.
It would seem that the recommended approach is
for every organization which is applying
identifiers
the organization should also apply its own
version identifier (even if it is identical to an existing
one)
It will be assumed (in the absence of an
*identifier_relationship) that the version identifier matches the item
identifier which is assigned by the same organization.
Do we need to establish a process specific rule which says
that, when a new version is created, either:
The creating organization adds new version codes
for all known identifiers
or
The creating organization adds a new version
code for only its own new version, and other organizations must generate their
own codes.
The problem with the former rule is that the creating
organization may not know the rules for creating version id's for the other
organizations, or have a complete list of these identifiers.
The problem with the latter is of deciding the meaning of
the absence of an identifier for a specific organization when
that organization has supplied an item identifier. It cannot mean that they have
not accepted the version, since they have no rights to set the version status
(although they might have rights to approve the use of a
version by their organization). This situation could arise either because the
organization is yet to generate the version id, or the information has arrived
via a route that did not happen to include that organization, and so not has not
collected the version id.
The solution to this is to require that the version
sequence is defined through an item-version_relationship. If item X has an
identifier "123" assigned by organization alpha, then it should also have at
least one version for which organization alpha has assigned a version id - "v2"
say. In the absence of the next version having an organization alpha version
identifier, this version would be known as Successor-of X123 V2, where
"successor-of" is deduced from the item-version_relationship. On the arrival of
version I6 of part 987 from organization beta, organization alpha would identify
987 as being the same as what it calls 123. It would then need to trace back
from version I6 to a version which had one of its own version id's, and then
work forward again, applying new version id's as it goes.
This does rather suggest we need a version synchronization
DEX to re-establish version numbers after change. And possibly a book explaining
how numbering works in distributed environments - dissenting opinions get to
write it.
Sean Barker
0117 302 8184
Folks
Gordon's description and especially the Harrier rudder
follows one particular business approach.
In
other businesses, where parts (even big things like diesel engines) are
procured from organization and then sold on again, the second
organization will often add its own part and version number. There is no
requirement in this situation for the version numbers to be
in the same sequence and quite possibly there will be versions at the first
organization which never reach the second organization. The ultimate
customer then orders spares, etc., against the middle org's numbers and they
translate them back to the original supplier's numbers. We know of
cases where this happens (in fact while Share-A-space has been used
to remove the resulting confusion, the difference part number/version
schemes are still in place - for commercial reasons that will not
change)
Just
because it does not make sense to have different conventions in a supply chain
for one project, does not mean that other projects will not do
so.
Nigel
Gentlefolk,
Within the context of AP 239 the Assured Product and Support
Information (APSI) provides the level of assurance and identification that
should enable clarity of what a person is viewing.
Version management in the context in which you are using it is
only a permeable view of an allowed configuration to
a Contractor/Customer agreement. The Information management rules
dictates how and when a new configuration is established and everyone is the
'food chain' will be aware of this. It is the lack of configuration
management rules[subset of IM rules] that allows everything go
'belly-up'.
In
respect to allowable configuration ids there are enough external standards
that dictate the methodology for marking/identification (FOR EXAMPLE BS
8888 // ASME Y14 SERIES) - these are usually contracted
against.
In
the context of Sean's example I don't think I have met such a situation and I
don't think it possible.
When
referring to versions of a part, the original discussions (as Sean stated)
centred on part numbers and there can be different version of the same part in
service by different organisations
Basic version of a Harrier II vertical stabilizer (Rudder in
UK) 75A210000 - 1001; AV-8B version 75A210000-1003; GR5 75A210000
-1005, Spanish version /Italian version etc etc. As the product life cycle
evolves thru change [modifications] the variant dash numbers (1000
series) will incrementally increase.
Gordon
Nigel,
Thanks for you comment. This then next
raises the next question:
Does it happen that every organization applies its
own version numbering convention (and therefore version number) when it
applies an organization specific number to an item? If not, we might have
the following:
Org 1 creates part 123
version 1 and gives it version id=1
Org 2 buys part 123, and
renumbers it A123, but uses Org 1's version
number
Org 1 up issues 123 to version 2,
and gives it version id=2 (Org 2 does nothing)
Org 3 buys part 123,
and calls it part X987, version id =
2
Now, when Org 2 refers to part A123 version id=1,
someone looking at the data will see version id=2 where identifier owner =
Org 1, and version id =1 where identifier owner = Org 3. This is clearly a
mess.
Potential solutions:
1) Every organization that applies its own item id must
also apply its own version id
2) Every organization that applies its own item id must
also apply an organization_relationship identifying the organization that
supplies the version identifier
3) Only one version identifier is
allowed
4) *the version identifier for an organization is shown
by an *identifier_relationship (which entity does not exist) from the
primary identifier to the version id.
Opinions please.
Sean Barker
0117 302 8184
I
believe you will find in most organizations there is a policy for version
numbers which determines the form and ordering convention. Thus there is a
context in which they should be interpreted which may be organization
specific. Thus the relationship to organization is along the lines of
"according to convention established by" rather than owned by. To be
really explicit the document concerned (in which the conventions are set
down) could itself be assigned to the identification_assignment. (one
notes that over a 30 year life cycle the possibility of change to the
conventions)
Different versions for the same design could arise
if supplier and customer use different versioning conventions.
My
2-small-currency-units worth.
Nigel
Tim,
1) Items have multiple identifiers, such as original
manufacturer number and customer stock number
2) The data model allows versions to have multiple
version numbers - does this ever happen in practice?
3) If it does not happen, do we therefore need an
organization against the version number?
My memory of the discussion was that it centred on
part numbers, where an organization is definitely needed, rather than on
version numbers.
Sean Barker
0117 302 8184
*** 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.
|
Apologies if I have misunderstood but I am uncomfortable
with this. I thought PLCS had firmly established the principle of
requiring the assigning organization in all situations. If truly
"the item being versioned provides the context information" then surely
this would be the purpose of the ".id" attribute on Product_version?
Unless you are trying to say that multiple identifiers of version are
possible in the context of the item and the identification assignment
requires further context specification through classification (I can not
think of a real example, I was going to suggest "design" versus
"manufacturing" but that seems to be another example of different
organizational contexts).
Cheers,
Tim.
-----Original Message-----
From:
Barker, Sean (UK) [mailto:sean.barker@baesystems.com]
Sent: 05 November 2005 08:46
To: plcs-dex@lists.oasis-open.org
Subject:
[plcs-dex] Assigning identifiers with no organization
In assigning a version number, it is normally assumed that
the item being versioned provides the context information (i.e. that the
version number is effectively the second part of a compound key, the first
part of which is the item number). Assigning version numbers should
therefore use the template for assigning an identifier without an
organization, and logically this template should be migrated to the
assigning identifiers capability, rather than be in the assigning
organization capability. Comments?
Additional Observations
Question to Business users: I have made the assumption
that where multiple identifiers are applied to the same item, these do not
independently define version numbers. Is this true?
Sean Barker
0117 302 8184
********************************************************************
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
********************************************************************
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
********************************************************************
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
********************************************************************
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]