[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs] The saga on "manage identification" / NSN
Trine,
See comments below. Not adding any more fuel.... just my opinion.
Regards,
Simon.
-----Original
Message-----
From: Trine.Hansen@dnv.com [mailto:Trine.Hansen@dnv.com]
Sent: 05 November
2004 06:24
To: plcs@lists.oasis-open.org
Cc:
Leif.Tonning@dnv.com
Subject: [plcs] The saga on "manage identification" /
NSN
All.
The NDLO pilot, with their codifiying experts, recognises
an NSN to be an identity for a part from a supply and maintenance point of view.
However, the observation apply that the same NSN may be assigned to many
different part numbers (from different vendors). [Simon
Dick] agreed
The spec for the first part given the NSN may be the
common spec for new parts codified to the same NSN.
Similarly, more than one
NSN may play the role of resource item for a given task. [Simon Dick] Disagree - one resource item for a given task
(assuming the resource item was a spare part or tool) would have one NSN - I
don't know of any circumstance whereby different NSNs would meet the criteria
for the same required resource item. The actual part installed in an
equipment does own an NSN, however, this is not exclusive. We can from a PLCS
point of view easily agree that there are benefits of assigning the NSN to the
resource item, and have done so for all resources that has an NSN (including
tools etc). [Simon Dick] Agreed - an NSN is one way of
identifying a resource item. In short, we agree. Also, we have
no problem with somebody using the NSN as a serial number, although this seems
like a very special case. [Simon Dick] Disagree -
there are NO circumstances in which NSNs can be used as a serial number by means
of uniquely identifying an instance of a product. NSNs are a classification of
items (meeting the same form, fit, function). PLCS should not promulgate the
acceptability of using NSNs as serial numbers, and preferably, should refute it.
The only requirement is to classify the role of this identifyer as such.
The NSN may then occur twice in two different roles. Global rules. In our view,
a DEX specification represents a specific business object. These objects will
hold their own set of rules. Additionally, there will be a common need for rules
applying to DEX'es as such. These rules probably should be global.
We do
not intend to open the NSN discussion by adding more fuel. This is just to
present our agreement to an issue that we were guilty of
initiating.
Regards
Leif and Trine
-----Original
Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 28.
oktober 2004 09:12
To: 'Per-Åke Ling'; john.dunford@eurostep.com
Cc:
'Gordon Robb'; 'Tim Turner (Offsite)'; 'Tim King'; torirgen@eunet.no; Hansen,
Trine; Tonning, Leif; 'Leif Gyllström'; plcs@lists.oasis-open.org
Subject:
RE: [plcs] Re: The saga on "manage identification"
I agree with John that
NSN numbers should be an identification of a resource item.
However, if a
company is misusing NSN numbers to identify Prod_as_real, or Parts, in other
words treating them internally as Part numbers or Serial numbers, then there is
nothing we can do about it. What the translator must do is to export a
prod_as_realised or part and identify it according to the capability "assigning
identifiers"
What it should NOT do is classify the identification as an
NSN number.
We have had the "unique Id" debate over and over in
PLCS.
PLCS can not impose uniqueness on any identifier.
All it can do is
represent the Id in the context of the organization that created it. It is up to
that organization to ensure uniqueness. Consequently PLCS has been careful to
adhere to the DOD Memorandum "The Department of Defence Guide to Uniquely
Identifying Items, Version 1.3" dated November 25th, 2003. See (http://www.acq.osd.mil/uid) for the source. This
is documented in the capability Assigning identifiers.
I will start the
discussion about rules in a separate email
thread
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: Per-Åke Ling
[mailto:per-ake.ling@eurostep.com]
Sent: 27
October 2004 19:00
To: john.dunford@eurostep.com
Cc: 'Gordon Robb'; 'Tim
Turner (Offsite)'; 'Rob Bodington'; 'Tim King'; torirgen@eunet.no;
trine.hansen@dnv.com; leif.tonning@dnv.com; 'Leif Gyllström';
plcs@lists.oasis-open.org
Subject: [plcs] Re: The saga on "manage
identification"
Understood and completely agreed. However, there is an
issue 3, raised
by Rob regarding adding a rule to enforce identification. If
I
understood correctly this would be a rule at PLCS schema level, and
it
was that issue I debated and was not happy with. If Rob meant adding
a
rule to the capability, my apology and my reasoning is beside the
point.
Regards,
Per-Åke
John Dunford wrote:
> Sorry to
prolong this exciting debate (especially as I started it) but
> there are
two issues here and they are getting muddled up.
>
> Issue 1
considers whether to impose uniqueness requirements on the
>
"id/organisation" pair within a capability or DEX. I support this
>
idea, although it will require action by the translators of some
> legacy
systems to define the assigning organization, where this is
> implicit
within the system itself. And no bad thing I hear you say!
>
>
Issue 2 concerns the nature of the item being identified. Here my
>
concern is make sure that PLCS Capabilities and DEXs establish a
>
coherent approach to handling the problems caused by the misuse of
>
specific identifiers - notably the NSN - within legacy systems.
>
>
The solution to this problem is neatly explained by Tim's in the "Dear
>
John" note below! As Tim correctly states, in PLCS, an NSN is an
>
identifier of a resource_item AND OF NOTHING ELSE.
>
> Many legacy
systems however, do not recognize the distinctions made by
> PLCS between
resource_item, part_version, slot, and part_as_realized.
> As a result
they sometimes (often?) use NSN as identifiers for any/all
> of these
things. When mapping such data into a DEX, it is important
> to
re-establish clear distinctions, so that any recipient can
> understand
what the data in the DEX really means.
>
> It follows that NSNs
should ALWAYS be recorded in DEXs as the
> identifier of a resource_item,
WHETHER OR NOT THIS ENTITY IS
> RECOGNISED BY THE LEGACY SYSTEM. The
entity being identified should
> be mapped into the DEXs as whatever it
really is: a part, a slot, a
> realized part etc. If the entity in
the legacy system is anything
> other than a resource_item, it will not
have an identifier per se in
> the DEX file, unless one is generated by
the translator, but it will
> be related to a resource_item, identified by
the NSN.
>
> Can I please be assured that this approach is being
followed,
> especially in DEX 1, 4, 7 and 8.
>
> John
Dunford,
> Eurostep Limited,
> 25, Chaucer Road, BATH BA2 4QX,
UK
> Tel: +44 1225 789347
> Mobile: +44 0797 491 8202
>
www.eurostep.com
>
www.share-a-space.com
>
>
>
> -----Original
Message-----
> From: Per-Åke Ling [mailto:per-ake.ling@eurostep.com]
> Sent:
27 October 2004 10:18
> To: Gordon Robb
> Cc: Tim Turner (Offsite);
Rob Bodington; john.dunford@eurostep.com; Tim
> King; torirgen@eunet.no;
trine.hansen@dnv.com; leif.tonning@dnv.com;
> 'Leif Gyllström';
plcs@lists.oasis-open.org
> Subject: Re: The saga on "manage
identification"
>
>
> I agree completely. The standard only
states "...provide unambiguous
> identification..." without stating how
this unambiguity (sic) should be
> achieved. The capability, on the other
hand, does specify that the
> triplet [id,class,org] must be unique, which
is where such a restriction
>
> belongs. In the future a new id
capability could conceivably be
> defined
> with some alternate way
of achieveing uniqueness.
>
> If I do not read this wrong it
confirms my earlier longwinded
> argument, i.e. do not restrict PLCS, put
the restrictions in
> DEX/capabilities.
>
> Regards,
>
Per-Åke
>
> Gordon Robb
wrote:
>
>>Gentlefolk
>>Isn't it time to remind
ourselves of what the PLCS AP 239 definition
>>of
>>"manage
identification" states
>>
>>"Manage
identification
>>action to provide unambiguous identification of all
elements, and
>>versions, of the product or support system to which
reference needs to
>
>
>>be made, identification of
interfaces between elements, the necessary
>>assembly, and other
breakdowns structures, required to manage the
>>product through life
and definition of the information to be held for
>>each type of product
and support system element
>>
>>NOTE This
activity occurs throughout the product life cycle and is
>>the basis of
management of configuration change and
configuration
>>status
>>accounting of a product and all
constituent configuration items. The
>>purposes and benefits of this
activity include:
>>
>>·
determining the structure (hierarchy) of a product and
the
>>organization and relationships of configuration documentation
and
>>other
>>product
information;
>>
>>·
documentation of the performance, interface and other
>
>
attributes
>
>>of a
product;
>>· determination of the
appropriate level of identification
>
>
marking
>
>>of product and
documentation;
>>· unique
identification of a product or component part of a
>
>
product;
>
>>· unique
identification of the technical documents describing
>
>
the
>
>>product;
>>·
modification of identification of product and documents to
>>reflect
incorporation of change;
>>·
distinction between product
versions;
>>· correlation of
document revision level to product
version;
>>· correlation of a PIF
to related user or maintenance
>
>
instructions
>
>>at the configuration item
level."
>>
>>That definition is catered for by Capability
(C001):-
>>assigning_identifiers which states in its introduction "The
purpose of
>>this capability is to assign identifiers to entities
within the model
>>that may be the subject of identification. There are
three components
>>to
identification;
>>
>>
the identifier and its
assignment
>> the
organization that owns the
identifier
>> the meaning of
the identifier (e.g. serial number) as provided
>>by the classification
The approach adopted here is compatible with
>>that provided in the DOD
Memorandum "The Department of Defence Guide
>>to Uniquely Identifying
Items, Version 1.3" dated November 25th,
2003.
>>See
>>(http://www.acq.osd.mil/uid) for the source. This
memorandum applies
>
> to
>
>>high value tangible
assets (such as an aircraft). However, the
>
>
approach
>
>>here is much broader than the DoD approach and
covers none tangible
>>assets (such as a maintenance
task).
>>
>>NOTE The identifier shall be
unique within the organization that
>
>
owns
>
>>it.
>>
>>EXAMPLE A
DUNS code or a CAGE Code is an example of an
>
>
identification
>
>>that can be assigned to an
organization.
>>
>>EXAMPLE A Part Number is
an example of an identification that can
>
>
be
>
>>assigned to the design of a
Part.
>>
>>EXAMPLE A Serial Number is an
example of an identification that can
>
>
>>be assigned to
a physical instance of a Part (a
Product_as_individual)
>>
>>The methodology of
'References to Identification_Assignment' is
>>depicted in the
attachment.
>>
>>Whilst the modellers may wish to battle out
their preferences I would
>>like to state that the way DEX 1 and DEX 8
are compiled (noting there
>>will be fine tuning to take place post the
revision to module 1164 PAI
>
>
>>and possible 1251
Interface) meet the business requirements for
>
>
managing
>
>>the id.
>>
>>The bottom line is
that a serial number allocated by the 'OEM' is a
>>through life serial
number that provides unambiguous identification
>
>
and
>
>>traceability of the asset if required. Through
configuration changes
>
> in
>
>>its life the PIF
part number//section/reference number//National or
>
>
NATO
>
>>stock number will change BUT the serial number remains
the
same.
>>
>>regards
>>
>>Gordon
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>-----Original
Message-----
>>From: Per-Åke Ling [mailto:per-ake.ling@eurostep.com]
>>Sent: 26 October 2004 18:55
>>To: Tim
Turner
>>Cc: Rob Bodington; john.dunford@eurostep.com; 'Tim
King';
>>torirgen@eunet.no; trine.hansen@dnv.com;
plcs@lists.oasis-open.org;
>>leif.tonning@dnv.com; 'Leif
Gyllström'
>>Subject: Re: [plcs] Workshop #2 - Synchronise work on DEXs
and
>>reference data between PLCS pilots and
OASIS/PLCS
>>
>>
>>Hmmm, yes. But, it would be a
headache to ensure uniqueness in the
>>model iteself, as you pointed
out it should be a business issue. If
>>specified at all it should be
in a DEX, not in the model. The reason
>>for this being that it is very
difficult to define what constitutes
>>uniqueness, consider the
following cases:
>>
>>1. same id, different
organisations
>>2. same id, different effectivity
>>3. same
id, different classification
>>4. same id, different
context
>>...
>>
>>So, given that identification is
multidimensional, what constraints
>>can the model enforce that would
sit comfortably with every
>>implementation ?
>>
>>On
the other hand, considering the DEX as a well defined subset
and
>>restriction, it could well be that for a specific area
of
>>applicability of PLCS (i.e. the DEX) a specific rule could
be
>>specified enforcing some rule of
uniqueness.
>>
>>To summarize, I believe that PLCS (the model)
is fine as it is with
>>all its flexibility (and warts), the
restrictions should instead be
>>specified in the DEX. Since probably
nobody would claim conformance
>>with PLCS as a whole (a somewhat
nebulous claim) this is not a
>>problem, I rather see an application
claiming conformance with e.g.
>>DEX #1, #7 and #13 (or whatever). This
will achieve the constraints
>>without restricting the model itelf, and
thereby keeping it
more
>>futureroof.
>>
>>Regards,
>>Per-Åke
>>
>>Tim
Turner wrote:
>> > Per,
>> >
>> > I can see
your point. The contents of the identifier is a
business
>>issue,
>> > not a modelling one.
>>
>
>> > However, if (are?) we responsible for
enforcing
>>consistency/uniqueness in
>> > the model, then
we probably need some rules. Any global rules
would
>
>
>>need to
>> > be established at the
capability/dex level - not the PLCS schema
>
>
level.
>
>> >
>> > I think the implementors will
be cursing us if we give them
>>conflicting or
>> >
ambiguous requirements that can be interpreted differently
>
>
resulting in
>
>> > different populations of the data - so we
need to strike the right
>>balance.
>> >
>> > I
think we need to ensure at least consistency in the data. The
>
>
real
>
>> > question then is how restrictive do the rules need
to be for this.
>
> I was
>
>> > agreeing with
Rob, in suggesting that we need to ensure that there
>
> is
an
>
>> > identification of the P.A.R, and (going further)
that there should
>>alsways
>> > be at least one identifier
that is classified as a 'serial
>>identification
>> > code'
(and owned by an Org'n).
>> >
>> > Whether we go further
& ensure that the content of that identifier
>
>
is
>
>>unique
>> > at all (I presume within the Dex),
across all P.A.R's, P.A.P's
>
>
and/or
>
>>all
>> > Parts is the issue.
>>
>
>> > So the next question, I hinted at earlier, is whether we
as
>>developers of
>> > the model are responsible for
*ensuring* uniqueness of the data, or
>
>
>>do
we
>> > pass on that problem to the implementors?
>>
>
>> > kind regards,
>> > Tim
>>
>
>> > NB. I am not certain that this is an issue from both
the
>
> integration and
>
>> > data exchange uses
of plcs (but certainly from the latter).
>> >
>>
>
>> >
>> > ----- Original Message -----
>>
> From: "Per-Åke Ling" <Per-Ake.Ling@eurostep.com>
>> > To:
"Rob Bodington" <rob.bodington@eurostep.com>
>> > Cc: "'Tim
Turner'"
<timturner11@bellsouth.net>;
>><john.dunford@eurostep.com>;
>>
> "'Tim King'" <tmk@lsc.co.uk>;
<torirgen@eunet.no>;
>><trine.hansen@dnv.com>;
>>
> <plcs@lists.oasis-open.org>; <leif.tonning@dnv.com>;
"'Leif
>
> Gyllström'"
>
>> >
<leif.gyllstrom@aerotechtelub.se>
>> > Sent: Tuesday, October
26, 2004 12:24 PM
>> > Subject: RE: [plcs] Workshop #2 - Synchronise
work on DEXs and
>
> reference
>
>> > data between
PLCS pilots and OASIS/PLCS
>> >
>> >
>>
>
>> >>I fail to see this as a PLCS problem. PLCS provides a
mechanism for
>> >>identification, to be meaningful this should
at least be qualified
>> >>by classification and an organisation
claiming ownership, i.e. the
>> >>PLCS is flexible and rich
enough to handle any identification
>> >>scheme.
>>
>>
>> >>Whether or not NSN numbers are unique is surely a
problem
>
> irrespective
>
>> >>of PLCS, i.e.
the organisation assigning the numbers will have
>> >>problems
regardless.
>> >>
>> >>On the other hand, I am not
sure global rules are a good idea
>
> unless
>
>>
>>one can ascertain that it will always be true for any
conceivable
>
> use
>
>> >>of PLCS that an
identification always will have an organisation
>
>
(and
>
>> >>likewise for other rules). I am not happy about
restricting the
>
> PLCS
>
>> >>schema this
way, but a DEX (or capability) could certainly impose
>> >>such a
restriction.
>> >>
>> >>Regards,
>>
>>Per-Åke
>> >>
>> >>
>>
>>Quoting Rob Bodington <rob.bodington@eurostep.com>:
>>
>>
>> >>
>> >>>We can't stop someone
using an NSN as a serial number . but
>> >>>
>>
>>>If an identifier is a Serial number, then the
>
>
identification_assignment
>
>> >>>should
>>
>>>be classified as such.
>> >>>
>>
>>>If the identifier is an NSN the identification_assignment
should
>
> be
>
>> >>>classified
>>
>>>as an NSN - not a serial number.
>>
>>>
>> >>>
>> >>>
>>
>>>
>> >>>
>>
>>>Regards
>> >>>Rob
>>
>>>
>>
>>>-------------------------------------------
>>
>>>Rob Bodington
>> >>>Eurostep Limited
>>
>>>Web Page: <http://www.eurostep.com> http://www.eurostep.com
>>
>>><http://www.share-a-space.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 Turner [mailto:timturner11@bellsouth.net]
>>
>>>Sent: 26 October 2004 16:14
>> >>>To: Rob
Bodington; john.dunford@eurostep.com; 'Tim King';
>>
>>>torirgen@eunet.no
>> >>>Cc: trine.hansen@dnv.com;
plcs@lists.oasis-open.org;
>> >>>leif.tonning@dnv.com; 'Leif
Gyllström'
>> >>>Subject: Re: [plcs] Workshop #2 - Synchronise
work on DEXs and
>>reference
>> >>>data
>>
>>>between PLCS pilots and OASIS/PLCS
>>
>>>
>> >>>
>> >>>
>>
>>>Y'all,
>> >>>
>> >>>
>>
>>>
>> >>>I tend to agree with Rob (the heretic!) -
since I also recommended
>
> the
>
>> >>>use
of
>> >>>global rules to help with consistency and to enforce
what is being
>> >>>described by the Dexs. What is the point
of not doing what we
>> >>>preach?
>>
>>>
>> >>>
>> >>>
>>
>>>The validation of a serial number is not something that the
model
>> >>>should enforce. However, the Dexs state what type
of reference
>> >>>data
>
> should
be
>
>> >>>associated with an identifier of a
Product_as_realized.
>> >>>
>>
>>>
>> >>>
>> >>>What worries me is
the subsequent issue; that if a NSN is used in
>
>
place
>
>> >>>of a
>> >>>serial number
(but classified as a serial number) - is the issue
>
>
of
>
>> >>>uniqueness.
>>
>>>
>> >>>
>> >>>
>>
>>>
>> >>>If this situation can occur once, then the
same NSN may be used
>> >>>elsewhere - also as a serial
number. Hence we may have two (or
>> >>>more) identical
identifiers (NSN)
>> >>>both classified as serial numbers.
Will this not present a bigger
>> >>>problem?
>>
>>>
>> >>>
>> >>>
>>
>>>regards,
>> >>>
>>
>>>Tim
>> >>>
>> >>>----- Original
Message -----
>> >>>
>> >>>From: Rob
<mailto:rob.bodington@eurostep.com>
Bodington
>> >>>
>> >>>To:
john.dunford@eurostep.com ; 'Tim King' <mailto:tmk@lsc.co.uk>
>
> ;
>
>>
>>>torirgen@eunet.no
>> >>>
>>
>>>Cc: trine.hansen@dnv.com ; plcs@lists.oasis-open.org ;
>>
>>>leif.tonning@dnv.com ; 'Leif Gyllström'
>>
>>><mailto:leif.gyllstrom@aerotechtelub.se>
>> >>>
>> >>>Sent: Tuesday,
October 26, 2004 10:21 AM
>> >>>
>>
>>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs
and
>>reference
>> >>>data
>>
>>>between PLCS pilots and OASIS/PLCS
>>
>>>
>> >>>
>> >>>
>>
>>>John
>> >>>
>> >>>I
disagree.
>> >>>
>> >>>The rule will say
that there must be at least one identification
>> >>>assigned
to product_as_realized.
>> >>>
>>
>>>
>> >>>
>> >>>I do not see how
you can represent a product_as_realized without
>>
>>>identifying it. The id attribute are legacy step which we
would
>> >>>like to get rid
>
>
of.
>
>> >>>
>> >>>
>>
>>>
>> >>>I am not saying that the identification
must be a serial number.
>
> Just
>
>>
>>>that you
>> >>>must identify the
product_as_realized. Reference data will tell
>
>
you
>
>>what
>> >>>type
>>
>>>of identifier it is.
>> >>>
>>
>>>
>> >>>
>> >>>I was thinking of
doing the same to Part as well.
>> >>>
>>
>>>
>> >>>
>>
>>>Regards
>> >>>Rob
>>
>>>
>>
>>>-------------------------------------------
>>
>>>Rob Bodington
>> >>>Eurostep Limited
>>
>>>Web Page: <http://www.eurostep.com> http://www.eurostep.com
>>
>>><http://www.share-a-space.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: John Dunford [mailto:esukpc15@gotadsl.co.uk]
>>
>>>Sent: 25 October 2004 15:05
>> >>>To: 'Rob
Bodington'; 'Tim King'; john.dunford@eurostep.com;
>>
>>>torirgen@eunet.no
>> >>>Cc: trine.hansen@dnv.com;
plcs@lists.oasis-open.org;
>> >>>leif.tonning@dnv.com; 'Leif
Gyllström'
>> >>>Subject: RE: [plcs] Workshop #2 - Synchronise
work on DEXs and
>>reference
>> >>>data
>>
>>>between PLCS pilots and OASIS/PLCS
>>
>>>
>> >>>
>> >>>
>>
>>>Rob, please don't apply a rule to serial id. I like
Tim's
>
> explanation
>
>> >>>of
how
>> >>>things will work for the situation when reference is
made to
>
> realized
>
>> >>>parts
by
>> >>>"improper" means! PLCS must recognise that in
many current
>> >>>applications, references need to be made to
realized parts without
>> >>>serial ids.
>
>
This
>
>> >>>is done
>> >>>in various
ways including using NSNs, or Slot, or Part
>>
>>>numbers/descriptions (e.g. when reporting a Fault, or hours
run,
>> >>>on the Starboard Outer
>
>
Feed
>
>> >>>Pump).
>> >>>
>>
>>>
>> >>>
>> >>>I have a little
more sympathy with a global rule on organization
>>
>>>assignment, although this again may require such data to
be
>> >>>generated by a translator, if
>>
>>>the organization id is implicit within a given legacy
system.
>> >>>
>> >>>
>>
>>>
>> >>>
>> >>>
>>
>>>John Dunford,
>> >>>
>>
>>>Eurostep Limited,
>> >>>
>>
>>>25, Chaucer Road, BATH BA2 4QX, UK
>>
>>>
>> >>>Tel: +44 1225 789347
>>
>>>
>> >>>Mobile: +44 0797 491 8202
>>
>>>
>> >>>www.eurostep.com <http://www.eurostep.com/>
>>
>>>
>> >>>www.share-a-space.com <http://www.share-a-space.com/>
>>
>>>
>> >>>
>> >>>
>>
>>>-----Original Message-----
>> >>>From: Rob
Bodington [mailto:rob.bodington@eurostep.com]
>>
>>>Sent: 26 October 2004 12:24
>> >>>To: 'Tim King';
john.dunford@eurostep.com; torirgen@eunet.no
>> >>>Cc:
trine.hansen@dnv.com; plcs@lists.oasis-open.org;
>>
>>>leif.tonning@dnv.com; 'Leif Gyllström'
>>
>>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs
and
>>reference
>> >>>data
>>
>>>between PLCS pilots and OASIS/PLCS
>>
>>>
>> >>>I sort of agree with you Tim. However, I am
considering writing a
>>global
>> >>>rule
(a
>> >>>heretic statement I know) that forces a
product_as_realised to
>
> have an
>
>>
>>>identification_assignment to carry the serial number. I was
also
>> >>>considering a rule to force the assignment of an
organiztion
>> >>>assignment to to
>
>
the
>
>> >>>identification assignment.
>>
>>>
>> >>>
>> >>>
>>
>>>Regards
>> >>>Rob
>>
>>>
>>
>>>-------------------------------------------
>>
>>>Rob Bodington
>> >>>Eurostep Limited
>>
>>>Web Page: <http://www.eurostep.com> http://www.eurostep.com
>>
>>><http://www.share-a-space.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: 26 October 2004 11:11
>> >>>To:
'john.dunford@eurostep.com'; torirgen@eunet.no
>> >>>Cc:
trine.hansen@dnv.com; plcs@lists.oasis-open.org;
>>
>>>leif.tonning@dnv.com; 'Leif Gyllström'; 'Rob Bodington'
>>
>>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs
and
>>reference
>> >>>data
>>
>>>between PLCS pilots and OASIS/PLCS
>>
>>>
>> >>>
>> >>>
>>
>>>Dear John,
>> >>>
>> >>>This
business practice is not an issue for the PLCS model because
>
>
we
>
>> >>>just map
>> >>>things where
they should go (i.e. the NSN is mapped to the
>>
>>>Identification_assignment for the Resource_item). We do not
need
>
> to
>
>> >>>autogenerate
anything. The Product_as_realized instance stands in
>
>
its
>
>> >>>own right
>> >>>and needs
no Identification_assignment (i.e. there is no serial
>
>
number
>
>> >>>to
>>
>>>distinguish). If the legacy systems requires the
"identifier"
>
> then one
>
>>
>>>can
>> >>>trace back through to the Resource_item
that applies and find the
>
> NSN
>
>>
>>>there.
>> >>>This means "we do not have a serial
number for this part of the
>>realised
>>
>>>ship
>> >>>but we know it is on there (never
needing tracking) and we are
>
>
using
>
>>the
>> >>>NSN as
>>
>>>a proxy identifier". (Of course, I am not sure if the system
has
>
> a
>
>>flag
>>
>>>to
>> >>>indicate which serial numbers are real
and which are NSNs - but
>
> that
>
>>
>>>could be
>> >>>determined by intelligent
inspection.)
>> >>>
>>
>>>Cheers,
>> >>>Tim.
>>
>>>
>> >>>
>> >>>
>>
>>>-----Original Message-----
>> >>>From: John
Dunford [mailto:esukpc15@gotadsl.co.uk]
>>
>>>Sent: 25 October 2004 10:49
>> >>>To: 'Tim King';
torirgen@eunet.no
>> >>>Cc: trine.hansen@dnv.com;
plcs@lists.oasis-open.org;
>> >>>leif.tonning@dnv.com; 'Leif
Gyllström'; 'Rob Bodington'
>> >>>Subject: RE: [plcs] Workshop
#2 - Synchronise work on DEXs and
>>reference
>>
>>>data
>> >>>between PLCS pilots and
OASIS/PLCS
>> >>>
>> >>>
>>
>>>
>> >>>Tim, the problem that Tor refers to is the
opposite of the one you
>
>
>>cite.
>>
>>> He is
>> >>>not facing an application which uses
its own, special, identifiers
>
>
>>for a
>>
>>>part.
>> >>>He is facing one where the NSN has
been mis-used for this purpose.
>
>
>>This
>>
>>>is OK
>> >>>if everyone know this is what has been
done (as the host system
>
> users
>
>>
>>>probably
>> >>>do), but it could cause significant
problems, in a wider context,
>
> if
>
>>
>>>the
>> >>>practice is spread (by a PLCS DEX) to a
broader community.
>> >>>
>> >>>I suspect we
will encounter many such examples of "id confusion"
>
>
in
>
>> >>>current
>> >>>systems
(not least in SSDD and UMMS, where I suspect the famous
>
>
ACCREF
>
>> >>>Number
>> >>>means
different things to different people).
>> >>>
>>
>>>So, how should PLCS handle this? If we are all agreed
that NSN's
>> >>>should be
>> >>>recorded by
PLCS as identifiers of classes of resource_items (and
>
>
it
>
>> >>>seems we
>> >>>are), how
should we deal with the mapping when a particular
>
>
application
>
>> >>>uses an
>> >>>NSN
to identify a product_as_realized? Should the DEX
translator
>
> auto
>
>>
>>>generate
>> >>>a new unique id for the p_a_r, and
relate the NSN to the p_a_r, as
>
> the
>
>>
>>>id of the
>> >>>associated resource_item; or is
there another way of handling
>
> this?
>
>>
>>>
>> >>>Forgive me if I'm am treading ground
already resolved, but I
>
> suspect
>
>>
>>>"id
>> >>>confusion" may well be the biggest
problem that PLCS implementers
>
> will
>
>>
>>>face, and
>> >>>a consistent, well document
approach will be needed.
>> >>>
>> >>>John
Dunford,
>> >>>Eurostep Limited,
>> >>>25,
Chaucer Road, BATH BA2 4QX, UK
>> >>>Tel: +44 1225
789347
>> >>>Mobile: +44 0797 491 8202
>>
>>>www.eurostep.com
>>
>>>www.share-a-space.com
>> >>>
>>
>>>-----Original Message-----
>> >>>From: Tim King
[mailto:tmk@lsc.co.uk]
>>
>>>Sent: 20 October 2004 10:09
>> >>>To:
'torirgen@eunet.no'
>> >>>Cc: 'john.dunford@eurostep.com';
trine.hansen@dnv.com;
>> >>>plcs@lists.oasis-open.org;
leif.tonning@dnv.com; Leif Gyllström
>> >>>Subject: RE: [plcs]
Workshop #2 - Synchronise work on DEXs and
>>reference
>>
>>>data
>> >>>between PLCS pilots and
OASIS/PLCS
>> >>>
>> >>>
>>
>>>
>> >>>Yes. But the example you give just
means that for the initial
>> >>>allocation of the NSN there
is a one-to-one correspondence. If
>> >>>someone else
finds a
>
> new
>
>> >>>use for
>>
>>>the form, fit and function that the part_version embodies then
the
>
> NSN
>
>> >>>is the
>>
>>>common link across those different applications and
potentially
>> >>>eventual different manufacturings. In
principle, the NSN only
>> >>>enables
>
>
supply
>
>> >>>rationalisation but can not really force
people not to find a way
>
> to
>
>>
>>>distinguish
>> >>>their own designs from
others.
>> >>>
>> >>>Cheers,
>>
>>>Tim.
>> >>>-----Original Message-----
>>
>>>From: torirgen@eunet.no [mailto:torirgen@eunet.no]
>>
>>>Sent: 19 October 2004 09:44
>> >>>To: Tim
King
>> >>>Cc: 'john.dunford@eurostep.com';
trine.hansen@dnv.com;
>> >>>plcs@lists.oasis-open.org;
leif.tonning@dnv.com; Leif Gyllström
>> >>>Subject: RE: [plcs]
Workshop #2 - Synchronise work on DEXs and
>>reference
>>
>>>
>> >>>data between PLCS pilots and
OASIS/PLCS
>> >>>
>> >>>
>>
>>>
>> >>>John,
>> >>>Well in the
case of the Norwegian Frigates the NSN applies
>
> sometimes
to
>
>> >>>
>> >>>part_version, and
even worse the part_version only apply to ONE
>
>
ship...
>
>> >>>
>> >>>but in
principle I tend to agree with you.
>> >>>Best
regards,
>> >>>Tor Arne
>> >>>
>>
>>>
>> >>>
>> >>>
>>
>>>>I completely support John's comments. We reviewed this
at
>
> Seattle and
>
>> >>>
>>
>>>>when
>> >>>>I have time, I should be
writing this up ... ideally as a
>
> capability.
>
>>
>>>
>> >>>>Cheers,
>>
>>>>Tim.
>> >>>>
>>
>>>>-----Original Message-----
>> >>>>From:
John Dunford [mailto:esukpc15@gotadsl.co.uk]
>>
>>>>Sent: 18 October 2004 12:02
>> >>>>To:
Trine.Hansen@dnv.com; plcs@lists.oasis-open.org
>> >>>>Cc:
Leif.Tonning@dnv.com; Leif Gyllström
>> >>>>Subject: RE:
[plcs] Workshop #2 - Synchronise work on DEXs and
>>
>>>
>> >>>reference
>>
>>>
>> >>>>data between PLCS pilots and
OASIS/PLCS
>> >>>>
>> >>>>
>>
>>>>Trine, in briefly reviewing you PowerPoint and spreadsheet I
was
>> >>>
>> >>>surprised
>>
>>>
>> >>>>to see no mention of the entity
Resource_item. Apart from
>
> anything
>
>>
>>>
>> >>>else
>> >>>
>>
>>>>this is the key to modelling NATO STOCK NUMBERS, which
are
>
> identifiers
>
>> >>>
>>
>>>of
>> >>>
>>
>>>>resource_items. The whole Class, Group, Item structure is
one
>
> set of
>
>> >>>
>>
>>>>ready
>> >>>>made Reference Data,
applicable to this entity. The NATO RD
>
>
should
>
>> >>>
>> >>>not
be
>> >>>
>> >>>>applied to part_version,
because an NSN may be satisfied by any
>
>
number
>
>> >>>
>> >>>of
>>
>>>
>> >>>>part_versions from different
suppliers.
>> >>>>
>> >>>>Indeed the
resource_item/managed_resource area probably deserve
>
>
more
>
>> >>>>attention from the DEX community than
it has so far received.
>
> These
>
>>
>>>>concepts were specifically designed to provide somewhere to
hold
>
> the
>
>> >>>
>>
>>>large
>> >>>
>> >>>>set of
information which applies to items within an
>
>
Inventory/Stock
>
>> >>>>management environment, and
not to a specific part_version, and I
>
> am
>
>>
>>>
>> >>>sure
>> >>>
>>
>>>>you'll find plenty of this across the NDLO!
>>
>>>>
>> >>>>John Dunford,
>>
>>>>Eurostep Limited,
>> >>>>25, Chaucer Road,
BATH BA2 4QX, UK
>> >>>>Tel: +44 1225 789347
>>
>>>>Mobile: +44 0797 491 8202
>>
>>>>www.eurostep.com
>>
>>>>www.share-a-space.com
>> >>>>
>>
>>>>-----Original Message-----
>> >>>>From:
Trine.Hansen@dnv.com [mailto:Trine.Hansen@dnv.com]
>>
>>>>Sent: 15 October 2004 18:03
>> >>>>To:
plcs@lists.oasis-open.org
>> >>>>Cc:
Leif.Tonning@dnv.com
>> >>>>Subject: [plcs] Workshop #2 -
Synchronise work on DEXs and
>
> reference
>
>>
>>>
>> >>>data
>> >>>
>>
>>>>between PLCS pilots and OASIS/PLCS
>>
>>>>
>> >>>>
>>
>>>>All.
>> >>>>Please find
attached
>> >>>>(1) An updated figure of the proposed
example "business concept"
>
> that
>
>>
>>>
>> >>>will
>> >>>
>>
>>>>be used in the planned workshops and
>>
>>>>(2) Spreadsheet with draft input to the reference
data
>
> discussions.
>
>> >>>>The
attached spreadsheet is a draft input to the reference data
>>
>>>>discussions. Column A, E, F and H refer to instantiation
diagrams
>> >>>>and
>
>
capabilities
>
>> >>>
>>
>>>>produced in the Norwegian pilot and should only be viewed
as
>> >>>
>> >>>references
>>
>>>
>> >>>>only.
>>
>>>>
>> >>>>
>>
>>>><<Business concept v2.ppt>>
<<equipment&part_values.xls>> Regards
>>
>>>>Trine Hansen
>> >>>>UCTNO940, Information
Quality Management
>> >>>>Det Norske Veritas AS
>>
>>>>( + 47 67 57 96 38 (office)
>> >>>>( + 47
90 83 44 24 (mobile)
>> >>>>*
trine.hansen@dnv.com
>> >>>>http://www.dnv.com
>> >>>>
>> >>>>
>>
>>>>**************************************************************
>>
>>>>Neither the confidentiality nor the integrity of this message
can
>
> be
>
>> >>>>guaranteed following
transmission on the Internet.
>> >>>>All messages sent to a
DNV email addressee are swept by Sybari
>
>
Antigen
>
>> >>>
>> >>>for
>>
>>>
>> >>>>the presence of computer
viruses.
>> >>>>DNV acknowledges that SPAM email represents
a potential security
>
> risk,
>
>>
>>>
>> >>>and
>> >>>
>>
>>>>DNVs filters to block unwanted emails are therefore
continuously
>> >>>
>>
>>>adjusted.
>> >>>
>> >>>>DNV
has disabled "out of office" replies to the Internet
>>
>>>>**************************************************************
>>
>>>>
>> >>>>
>>
>>>>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
>> >>>
>> >>>
>>
>>>
>> >>>
>> >>
>>
>>
>> >>
>> >>--
========================================================
>>
>>Per-Åke
Ling email:
per-ake.ling@eurostep.com
>> >>Eurostep
AB
mobile: +46 709 566 490
>> >>Vasagatan
38 http://www.eurostep.com
>>
>>SE-111 20 Stockholm
>> >
>>
>
>>
>>--
>>========================================================
>>Per-Åke
Ling email:
per-ake.ling_AT_eurostep.com
>>Eurostep
AB
mobile: +46 709 566 490
>>Vasagatan
38 http://www.eurostep.com
>>SE-111 20
Stockholm
>>
>>
>>*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
*
>>
>>
>>
>>
>>
>>
>>----------------------------------------------------------------------
>>--
>>
>
>
--
========================================================
Per-Åke
Ling email:
per-ake.ling_AT_eurostep.com
Eurostep
AB
mobile: +46 709 566 490
Vasagatan
38 http://www.eurostep.com
SE-111 20
Stockholm
**************************************************************
Neither
the confidentiality nor the integrity of this message can be guaranteed
following transmission on the Internet.
All messages sent to a DNV email
addressee are swept by Sybari Antigen for the presence of computer
viruses.
DNV acknowledges that SPAM email represents a potential security
risk, and DNVs filters to block unwanted emails are therefore continuously
adjusted. DNV has disabled "out of office" replies to the
Internet
**************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]