RE: Products and subtypes in stepmod;Re: A small textual addition onmodule 1022 "Part and version identification";Re: [plcs-dex] Interfacespecification

["Barker, Sean (UK)" <sean.barker@baesystems.com>]

IMHO these are discussions all stem from the "language pictures the world" philosophy, prevalent in popular culture. I have been arguing for many years that we should adopt a "language talks about the world" approach.

If I go to a robot grocery store and order "three green apples", I do not care what view of the world the robot has, as long as it behaves in the correct way. Green could be anything from a spectral analysis by the robot's eye to a reference data element download from a remote server. It is the behaviour that matters.

This approach has enormous advantages when dealing with process sensitive data, such as PDM data. For example, the meaning of the term "issued" is entirely dependent on the point in the process chain where "issue" occurs. In BAE SYSTEMS, for maturing products (transition from prototype to production) the "issue" point moved from the production and verification of the product model as CAD to the point where the complete manufacturing package - including models for design, condition of supply, condition of spare, manufacturing process plans etc - could be "issued".

I propose that the distinction between "product" and "document" is one of configuration control process. A product is controlled in its own right, whereas a document is a container used to control something else. A good analogy here is sending a book by courier. The bookshop controls the product (the book), however the courier controls the container (the envelope).

The implication is that any change to an assembly is directly associated to the part within the assembly to be changed - "replace part 123 with 124" - the part identifier is referenced (as is covered in the configuration identification section of the configuration control plan [Les and Gordon - excuse me if I am not up to date with the latest fad in CM terminology].)

A change to a document is associated to the physical realisation of the document, either in terms of page number or chapter number (e.g. "replace pages 23-42"). This does not directly identify the element to be changed, but simply point to where to find it, and the identifiers do not form any part of a configuration management plan. For example, if we add a new entity to a module, then many of the section numbers for existing entities will change, and no-one will care.

The difference in philosophy is between a drawing that may contain parts, and a part that may be represented in drawings. STEP has had a major impact on the move to parts based control from drawing based control, spawning the multi-billion dollar PLM industry in the process.

Therefore
1) An interface specification is a subtype of product, if and only if the identifiers of interface elements are controlled through a configuration plan, and not generated from a document that contains them.

2) the physicality of software is irrelevant to its classification w.r.t. to {document, product} if this an exhaustive partition of the space of "thingies".

3) therefore if the "physical realization" is criterion, then one would need to create a different upper level ontology or subclassify the existing ontology.

Point. (as the French say)

FYI I attach the ontology analysis of PLCS subtypes made as part of a separate study, together with some indications of the KB approach to classification used in the study.

Sean Barker
ATC Filton
0117 302 8184

-----Original Message-----
From: Lothar Klein [mailto:lothar.klein@lksoft.com]
Sent: 30 October 2004 10:21
To: stepmod@tc184-sc4.org
Subject: Products and subtypes in stepmod


               *** 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.

Product and Product_version (product_definition_formation) in part 41
and in stepmod are highly generic objects. Various subtypes makes them
more specific, using product_related_product_category.

Looking to stepmod I found these (hope the list is almost complete):
- Part and Part_version (1022)
- Document and Document_version (1121)
  further version subtypes in 1203, and 1110)
- Product_as_individual and _version (1164)
- Breakdown and Breakdown_version (1248)
- Breakdown_element and _version (1248)
- Slot and Slot_version (1250)
- Information_packet and Information_packet_version (1445) AP233
- Interface_specification and _version (1251)
- Interface_connector and _version (1251)
  and various version subtypes in 1294
- Requirement and Requirement_version (1140)
- Template and Template_version (to be added by AP210)
- Substance and Substance_version (to be added by AP210+235)
Indirectly (by mapping) we have also
- Justification (1263)
- are there more entities which map to product ???

Problems:
1) I think that it is very important that all these top concepts are
very clearly separated from each other. This is not the case today.
2) There is a major question whether we want to have
a) complex combinations such as Part&Document or
b) have all these top concepts ONEOF

Here the problem description ends.

I don't want to spam the stepmod@tc184-sc4.org exploder any more.
So I will send my opinions on these questions and further on
discussions only to those who want to listen and/or participate.
Let me know.

Lothar

--
// Lothar Klein, LKSoftWare GmbH
// Steinweg 1, 36093 Kuenzell, Germany
// +49 661 933933-0, Fax: -2
// url: http://www.lksoft.com





********************************************************************
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.
********************************************************************

DTIFeb04.ppt