In my experience with Maintenance Management Systems, the definition of
"equipment" and "parts" seemed to be very situational and varied more
with the management history than it did between industries.
Equipment tended to be things that Engineering and Operations knew
about. Parts were the things that Maintenance and Stores were concerned
about.
For example, a motor might appear on a drawing and exist in the plant
with a fixed asset number (or some other unique identifier). It also
would appear in the Stores inventory with a part number. It also
appeared in a supplier catalogue with a product number.
From the fixed assets point of view it was a leaf in the hierarchy and
was associated with a specification that reflected it role in the process.
From the maintenance perspective, it was a reparable unit with a
limited set of lower level parts that could be replaced. The number of
items in the part Bill of Materials was a subset of the BOM from the
supplier that depended on the plant's location, technical skill level
and taste for fiddling with things. The supplier BOM would include
replaceable parts with product numbers as well as non-replaceable parts.
The maintenance procedures might also introduce another set of
identifiers that are more general and do not vary or relate directly to
any of the numbers above. (01)
There could be many revision numbers and dependencies involved depending
on the point of view being considered. Engineering specification
revisions, supplier revisions, maintenance activity revisions are
frequently unrelated. (02)
On top of that, as mentioned previously, you will have serial numbers
associated with individual parts or assemblies for warranty or
regulatory reasons. (03)
I am not sure that there is a generally accepted way to develop a
general policy on how to design an ontology that handles this but I
wanted to add this view of "parts" to the discussion since the
maintenance view often gets overlooked by Engineering since they have a
different view of equipment and parts.
If these views are not considered, one gets into a real split between
the reality of the plant and the Engineering view so that process
changes are complicated by the plant actually being different than the
drawings and specs used to plan the change. (04)
Ron (05)
Mike Bennett wrote:The IBM component idea is pretty much universal
nowadays in system design, as the "Least Replaceable Assembly" or some
such name. Designers are encouraged to design such that these are
replaceable in the field with a minimum of spares holding, which leads
to something like object design for hardware, and of course standard
backplanes.As a result, something like a fire alarm system, HVAC system
or emergency shutdown system consists entirely and only of parts (like
your rifle). This is further complicated by the fact that the parts are
often arranged in a dual-redundant or triplicated arrangement. The
result is
> that the "Continuant Thing" which is your industrial system, continues
> to exist and function when any one of these parts fails, rather like a
> person with one kidney, except that it continues to perform according to
> the full design specification (all it loses when a component fails, is
> the ability to survive a further similar failure). So unlike the family
> axe or the rifle it remains the same thing, without that part.
>
> I must admit I struggled with the parts thing, having tried to create an
> ontology framework based around your first/second/third order,
> continuant v occurrent and concrete v abstract. I could not see that any
> of these corresponded to "Part" so I wondered whether to add that to
> this overall framework or if I was missing something.
>
> In the end I went for defining "Part" as a continuant, relative thing,
> with a relationship "is part of" to "Continuant Thing", with the inverse
> relationship "has part" from Continuant Thing to Continuant Thing. My
> reasoning was that a thing can be a continuant thing and still be a part
> of another thing, but a thing defined as a Part is a second order
> definition of that (first order, continuant) thing as a part. I'm not
> sure if the inverse property should be to Part instead.
>
> I've no idea if that's the best way to do it but it seems to cover the
> requirements. For example I have "Contractual Terms Set" as a part of a
> Contract, and this is used when modelling relationships between say a
> bond security and its interest payment terms, which are a kind of
> Contractual Terms Set.
>
> Mike
>
> John F. Sowa wrote:
>
>
>> This thread touches on many practical and philosophical issues, which
>> have important implications.
>>
>> MB> An interesting ontological problem, otherwise known as the
>>
>>> "Family axe" i.e. this axe has been in our family for generations.
>>> My father replaced the handle, his father replaced the head etc.
>>>
>> The US Army had a problem with identifying rifles. They kept
>> track of the rifle assigned to each soldier, but not of the parts,
>> which could be replaced. But what if a soldier requested parts
>> one at a time and reassembled them to form a duplicate rifle?
>>
>> Their solution was to declare that one part could not be replaced.
>> That was the stock, which had a unique serial number. If the stock
>> was broken, the soldier had to replace the entire rifle.
>>
>> SB> In engineering practice (at least as described through ISO
>>
>>> 10303), a part is either an inseparable component or an assembly.
>>> An assembly consists of sub-assemblies (which are assemblies)
>>> and components. The definition of assembly is recursive.
>>>
>> Fifty years ago, almost all products were built as assemblies.
>> Anybody who had modest skills with a screwdriver and a set of
>> wrenches could take apart, reassemble, and repair cars, toasters,
>> and even radios. But getting beyond replacing tubes in the radio
>> required some technical knowledge and skill with a soldering iron.
>>
>> When individual transistors became integrated circuits, the
>> "field replaceable units", as IBM called them, kept getting
>> bigger and more expensive. For their Quasar TV sets, Motorola
>> had the bright idea of designing components as pluggable units
>> that could be replaced as easily as vacuum tubes. Unfortunately,
>> the most unreliable components turned out to be the plugs.
>> Furthermore, the cost of maintaining a vast inventory of such
>> units was prohibitive. As a result, Quasar TVs were more
>> expensive and more unreliable than competing brands.
>>
>> LO> The replacement and maintenance problem in the "equipment" area
>>
>>> is very like to the "replacement" and "maintenance" in the Personnel
>>> area ! In the IFS ERP product they are under the common "object"
>>> topic . Suppose it will be good to have some common description
>>> for them although of course it will be hard to describe a body as
>>> an "assembling" .
>>>
>> For living organisms, there are no assemblies. Every component
>> grows from a single egg that divides and subdivides into the
>> specialized cells of every organ from skin to bones to lungs to
>> the heart and brain. A heart may be replaceable, but a successful
>> replacement requires adjacent cells to grow, subdivide, and bond
>> together. As a result, the new heart becomes seamlessly integrated
>> with the other organs of the body.
>>
>> RHM> Thus my concept hierarchy - my point of view - changes
>>
>>> with time, as the parts are assembled or disassembled.
>>>
>> That is one more reason why a strict tree is an inadequate
>> logical structure for representing an ontology. Aristotle's
>> syllogisms supported multiple inheritance, and Leibniz took
>> the next step of systematizing the partial order into a lattice.
>>
>> With a partial ordering (multiple inheritance) the type hierarchy
>> need not change, even though individual instances may be changing
>> constantly.
>>
>> DN> Alignment with UML at a conceptual level is probably a great
>>
>>> goal given it allows the structure to also be expressed in UML.
>>> If UML is not robust enough, custom stereotypes can easily be
>>> built into a UML profile.
>>>
>> I strongly agree. My major complaint about the Semantic Web is
>> that the designers ignored the most widely used official and
>> de facto standards and practices in comp. sci. and IT.
>>
>> UML and relational DBs are two examples, but there are many others
>> that they ignored. Now they complain that commercial enterprises
>> ignore their recommendations. That shouldn't be a surprise.
>>
>> John Sowa
>>
>>
>> _________________________________________________________________
>> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>> Shared Files: http://ontolog.cim3.net/file/
>> Community Wiki: http://ontolog.cim3.net/wiki/
>> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>>
>>
>>
>>
>>
>
>
> (06)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (07)
|