RE: DEX 8 - Some Answers

[timturner E-mail <timturner11@bellsouth.net>]

Having spent some time on the phone today I have some answers that may go
some way to determining the course ahead;
 
Dex 8 is named Product_as_individual to ensure that from the services
viewpoint, both PAP & PAR can be represented.
 
The main role of the PAP from what I have learnt is to allow for the
allocation of specific parts to a product under planned build process. These
specific parts may indeed already exist and have serial numbers which can be
allocated to the product planned. However, this cannot be mandatory since
the parts may not yet exist & therefore, serial numbers will not be
available to allocate. 
 
I had previously assumed that this was the case from the start, and could
see no way we'd see the serial number until the actual part is delivered
from the supplier. 
 
However, because the design allows for a variety of configurations, when the
final manufacture & assembly design is reached there must be a final
selection (if you will) of the different alternatives that can fill the slot
on the product. This is what the representation of the PAP is for. If there
exists an individual occurrence of one of these parts and the serial number
is known - this can then be allocated to the product planned.
 
However, I also think that when the serial number is not known, another type
of identifier might be used. For example a catalogue number or even a Nato
Stock Number would suffice during the life of the PAP. Once procurement has
found a part which conforms to the NSN, and the part gets delivered, then
the serial number can be added if still in the build process. If the build
has been completed, then the serial can be added to the PAR.
 
I think that this demonstrates that a variety of means of identification is
required for the PAP, not just serial numbers which may or may not be
available, and that this needs to be written up in the relevant
capabilities. The assembly/line number associated with the OEM exchange
scenario is also valid if the model is allowed to be flexible enough in the
capabilties for the Dex.
 
Although it may not still appear clear, the model for Dex 8 needs to be one
that can be iterated over as the product moves from the planned (product)
state to the individual (product) state. Hence in the early exchanges using
this Dex, there may not be any PAR instances - just PAP ones. As time
progresses, the state of the product may be reflected in the exchange file
in that more and more PAP instances disappear - being replaced by instances
of PAR. The final stage is when the file consists only of PAR instances. At
this stage the product is complete and enters into service. As time goes by
other planned configurations may be added to replace the existing one, so
exchange files may once again consist of a mixture of PAP and PAR instances.
This ultimately means that Dex8 has to be able to represent both PAR & PAP
data.
 
There are subtle distinctions between the Dex1 representation of the design
and the way in which the model represents the individuals, which means that
the two are not identical (from the model/representation point of view) and
I will endevour to go into that in another email.
 
The implication so far is that Dex8 scope is correct, but we need to now
determine if we are to extend the capabilities to deal with either PAP or
PAR instances, or whether to create mirror capabiltiies of the realized
ones, but with the PAP entity as the focus.
 
Kind regards,
Tim
 
NB - sorry if I'm just catching up to some of you others!!
 

-----Original Message-----
From: tim turner [mailto:tim_the_intrepid@yahoo.co.uk]
Sent: 24 August 2004 20:46
To: 'tim turner'; 'Hendrix, Thomas E'; Plcs (E-mail)
Cc: Robert M Mcbride (E-mail)
Subject: RE: DEX 8


Tom & other Dex8 gurus!
 
without wishing to stir up the hornet's nest - 
 
Dex8 has both within it's scope statement at present, but the capabilities
for this are all but none existant except for that explained within C045
(product_as_realized). Either Dex8 is seriously under-developed on the
representation of product_as_planned or a new Dex is required.
 
The business need for this is two-fold (probably others too?);
 
a) for OEMs to track designs thru to realized products & vice-versa
b) for in-service planning of refits & outfitting (however, we need to be
wary of the difference between this & re-supply of consumables).
 
My question to all is this; are we expecting to use Dex8 for exchanging BOTH
types of information? That is both products as planned and/or products as
realized? Is it expected that both product_as_planned & product_as_realized
views will always only be used in the same exchange scenarios, or can/should
they be able to be used separately? 
 
I think the decision on this will dictate whether we need to generate a
bunch more capabilities, or to amalgamate this functionality into other
existing ones.
 
Merging them is of course, means that dexlib will suck in all the express
entities for that additional functionality which is something previously
hotly contested by those who only want to implement the required entities
for a specific exchange capability.
 
Given the current capabilities in Dex8 (specifically C045), Dex8  has both
relationships product_design_to_individual and product_planned_to_realized,
it would also not be inconceivable to think that Dex8 would also cover
design data from Dex1 (albeit in the form of a different set of capabilities
which largely pull in the same information)!
 
Kind regards,
Tim
 

-----Original Message-----
From: tim turner [mailto:timturner11@bellsouth.net]
Sent: 20 August 2004 15:38
To: 'Hendrix, Thomas E'
Cc: Robert M Mcbride (E-mail)
Subject: RE: DEX 8


Tom,
 
just to get my head around the big picture, why are there no
product_as_planned capabilities? I'm sure that there's a good reason - I
just haven't had my periscope up at the right time!
 
Perhaps I could give you a quick call if you could send me your number -
else mine is 1-843-588-9679
 
Cheers,
Tim

<<attachment: winmail.dat>>