plcs message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: FW: [plcs] RE: DEX 8
- From: "Tim turner" <timturner11@bellsouth.net>
- To: "Plcs \(E-mail\)" <plcs@lists.oasis-open.org>
- Date: Wed, 25 Aug 2004 10:15:40 -0400
Title: Message
Here's
a copy of the other email sent yesterday but was mangled by the
exploder!
kind
regards,
Tim
John
& others interested in Dex8!
thanks
you for your kind insights. I like your example, though I think it raises
more questions than answers.
First,
we need to get the existing stages & scenarios straight - so we can get to
the stage you are talking about.
For
example, a "product as planned" (PAP) might add a line/assembly no during the
manufacturing life cycle stage. However, at the in-service stage of life, the
identifier for the PAP may be empty, the end user instead relying upon the part
number. Once the parts are fitted, the PAP is enhanced using the "product
as realized" (PAR) and the serial number provided. It seems more likely that an
OEM will have access to and need the PAP line/assembly information (e.g. a large
distributed manufacturer like Boeing perhaps?) rather than an end user. I have
generated a table & some thoughts/notes on each in the attached
spreadsheet.
Incidentally I think we need to be careful in the combinations
of these identifiers, life cycle stages and the implications of the
concepts such as design, planned & realized to ensure that we are not
contradicting ourselves. For example, should a product_as_realiazed be the
defined_version of a view_definition_context that has the life cycle/domain
set to design rather than in-service? Is "in-service" a valid entry for the RDL
- I couldn't find it.
Second, your example refers to "after-market" parts which are, as you say
not generally refered to through their serial numbers since they are mainly
generic designs - e.g. one design generally "fits all". However, some manufacturers state that you invalidate any product
warranties unless you use their own after market products. I presume that using
a brand made by the same manufacturer (or approved manufacturer) gives the
customer a) continued warranty, b) tested interoperability c) the
functionality desired and d) perhaps a configuration option in the design
data set. Such manufacturers are more likely to have serial numbers for these
parts that can be used in the PAR.
Thirdly, when planning to add a new after-market part (as in the child
seat example), I agree that you will likely not know the serial number ahead of
time, until it arrives for fitting. This seems to be in contrast to C045
(representing_product_as_realized) which which says "The
Product_as_planned represents a proposed or planned
artefact. It is identified by its serial number which is represented by
assigning an identifier classified as "Serial_identification_code" to the Product_as_planned.".
Fourthly, if the additional parts are not represented as configuration
options in the design, pap or par, are we to expect that we will then need to
create a new version of the product as described in C045
(representing_product_as_realized)?
This raises the
question of whether we expect to get a representation of the supplied part in an
exchange file or not. Next, should we expect this to be of the design, pap or
par? Or would we expect to manually carry out this update to the data set we
have for the product already in service? Lastly, do we need to consider
recording any feedback or status of the new part in the product (and hence
require updated support solutions), or are we to consider just those existing
requirements, but against a product whose configuration is now
modified?
I think that perhaps complex equipment such as weapon
systems will/should have their own support solutions and configuration
management etc.. The question is wether that information should be merged into
the product as a whole or handled separately. The interfaces are perhaps the
most iimportant aspects to get right. In
this sense, I may have a computer to which I add a peripheral - e.g. a printer.
But does adding the printer change the configuration of the PC - or just enable
the functionality already provided for? Should the printer configuration and
support solution be merged into that for the rest of the PC or handled
separately? Again, the interfaces seem to be the most critical things to get
right here.
I guess that some
classes of weapon systems may be part of the overall design and during service,
would be represented in the PAR. However, at what level do items such as
the ammunition get handled? In one way I could see these almost as
consumables. I guess that these get planned for re-supply on a regular basis,
rather than a refit for
this.
BTW, I - for my sins,
have been asked to look at getting Dex8 fit for
purpose..
Kind
regards,
Tim
Tim,
your
stages are valid, but there is a post-build condition to consider as well as
"product as planned" also has an important in-service role in defining the
desired/required configuration of a product needing support, after a support
period. (this is very similar to manufacture but starts with an existing
product, not an empty production line!)
A
simple example would be an instruction to fit a child car seat, when
cleaning the car on Sunday (because, on Monday we have to take out
granddaughter home from school!). This is an example of
desired/required role configuration (as opposed to permitted or
actual)). Typically. although such instructions apply to an
individual (my car, and my child seat) they tend to use part numbers/names,
not serial numbers.
It
is possible to envisage circumstances can arise where serial numbers are
used - e.g. fit the new (clean) seat, not the old one (with ice
cream stains), because we're also picking up great Aunt
Jemima!
A
serious practical example of this occurs in the RN with the so called
E-list (equipment list), which specifies the required state of the weapon
system of an individual vessel after a refit, as a detailed listing of
intended (planned) parts. The actual fit achieved may differ from
that planned e.g. because some bits arrive too late.
I
hope this explains the business need. As I observed earlier, whatever we do
here is likely to hit problems with implementation because the manufacturing
and support communities are largely unaware of the distinction between design
and individual (they only deal with the latter, but use the former to describe
them), and are often confused about the difference between permitted, planned
and actual!
PS -
is anyone actually developing DEX 8?
John Dunford,
Eurostep Limited,
25, Chaucer Road, BATH BA2 4QX,
UK
Tel: +44 1225 789347
Mobile: +44 0797 491 8202
Thanks for your feedback Tom,
I
conclude that this is a realistic scenario from the OEM perspective - but
would also propose to widen this out to the greater audience to get other
feedback - positive or negative...
cheers,
Tim
Tom,
just wanted to further a topic of conversation
regarding Product_as_planned.
My current understanding is that the life-cycle
stage adds information as it progresses as follows;
Stage:
Example: Adds:
---------
-------------- --------------------
Design
Product/Part Part
Number
Manufacture Product as
Planned Line Number
As-Built Product
as Realized Serial Number
Is this how you see it too? I assume that the LN
is to trace back to the production line so that the raw material, machines
& tools used can be checked in case of a fault discovery later in
life.
If this is the case, then do you have
any examples of this?
For the product as planned, is this the only
addition like this or are there others?
kind regards,
Tim
UseScenariosDex8.xls
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]