<p class="MsoNormal">Regarding ISO 10303 STEP with respect to issues in these OSHW
discussions, what follows are comments from my perspective of being involved in
several aspects of STEP and related standards/specifications.   </p>

<p class="MsoNormal">ISO 10303 is a broad and deep collection of standards to
represent the product data model for exchange, sharing and repositories over
the lifecycle.   The official 10303 documents
are developed by ISO TC184/SC4, copyright and available for purchase.   However
for some purposes like CAD data exchange, the EXPRESS schemas and recommended
practices that are freely available through STEPmod on sourceforge and the
CAX-IF, respectively, are sufficient for software implementers.    The
major mechanical CAD authoring and translator software vendors participate in
the private CAX-IF test rounds, and some publicly list their implementation
coverage on the CAX-IF web site.   There
exist mechanical CAD open source and free STEP implementations such as BRL-CAD/STEPcode,
FreeCAD/OpenPLM/OpenCascade, and IDA-STEP Viewer/JSDAI, and there are
commercial software toolkit vendors.   </p>

<p class="MsoNormal">The CAX-IF has recently focused on the requirements of LOTAR
International for Long Term Archiving and Retrieval of commercial aircraft type
certification data, such as Product Manufacturing Information (PMI) associated
with geometry in AP242.   The sponsors of
related technology such as JT, 3D PDF, HOOPS, 3D XML, etc. participate in the
CAX-IF, so it is a forum for communication on common issues.   LOTAR manages a standards and technology portfolio,
and sponsors pilot demonstrations.   LOTAR
is funding the development of AP242 for PMI, AP239 implementations for PDM and
Meta-data, and harmonization between AP239 and AP242.   A key part of STEP for CAD is validation:
how do you measure from a STEP import or export, other than through a visual
diff, that what was received is well-formed and corresponds what was sent?   So there are validation properties in the
EXPRESS schemas for critical metrics, and there rules, functions and procedures
that STEP files must satisfy when validating against a schema using an EXPRESS
compiler.   The feedback loop from requirements,
modifying schemas, developing recommended practices, testing data files, and
identifying implementation issues has reached a regular cadence with new
schemas and test rounds several times a year.  
   </p>

<p class="MsoNormal">Like the CAX-IF, LOTAR is a joint project between PDES Inc.
and ProSTEP iViP.   ProSTEP works closely
with the auto industry, and supports automotive AP242 use cases for managing assemblies
and kinematics for digital mock-up applications, including shapes in native
CAD, JT or STEP.   This involves a new
high level model in AP242 called the Business Object Model.   AP242 also inherits a manufacturing process
planning model from AP214, so the BOM and shape models could be used for clash
detection in manufacturing.   The AP242
BOM also serves as a basis for a higher-level API into AP domain specific
terms, such as those for composite structure and shape, which map into the
lower level representations in the STEP integrated resources used in CAD
exchange.   Others plan to use the 242
BOM for publish-subscribe to a shared PDM repository, incremental updates to
product structures, and engineering change request/order/note.   </p>

<p class="MsoNormal">Here is a Wikipedia article I drafted on AP242.</p>

<p class="MsoNormal">http://en.wikipedia.org/wiki/Wikipedia_talk:Articles_for_creation/AP_242</p>

<p class="MsoNormal">Other organizations such as the ASD/AIA Integrated Logistics
Support S-series specifications are using AP239 Product Life Cycle Support
(PLCS) through the PLCSlib (and deprecated DEXlib) integrated development
environment for Data Exchange Specifications (DEX’s).   PLCSlib
and DEXlib are under the authority of the OASIS PLCS TC, which has liaisons
with ISO and other relevant organizations.  
PLCSlib is a toolkit for creating DEX’s that is easier to use, has more
built-in quality checks, and uses more common SysML and OWL development tools
than STEPmod or DEXlib, which use EXPRESS.  
Most importantly, PLCS entities, properties and relationships are
extendable to subclasses with OWL reference data to a domain specific terminology.   In this way, new elements can be added for
different uses as in the OSHW discussions.  
</p>

<p class="MsoNormal">There are other AP’s (Application Protocols) for CAE (AP209),
Systems Engineering (AP233), Electro-Mechanical (AP210), etc. that are built
using the STEP modular architecture (STEPmod), but not as widely implemented as
CAD.   Other non-modular AP’s include
AP238 for CNC.   The STEP integrated
resources are also used by other specifications, such as the Industry
Foundation Classes (IFC) which are widely used in Building Information Modeling
(BIM).   </p>

<p class="MsoNormal">There is a legacy non-modular AP232 Technical Data Packaging
(TDP) that is still in production use, but LOTAR and others plan to use the
more recent modular AP239 PLCS for packaging. 
 For instance, there is a TDP
message DEX, and LOTAR PDM and Meta-data DEX’s in development are for other packaging
aspects.   PLCS is a highly-relational
and extendable model, and edition 2 includes most of AP233 Systems
Engineering.   Several types of
high-level API’s have been built based on PLCS, for instance for the
Behavioural Digital Aircraft DEX’s used in the EU CRESCENDO program.   </p>

<p class="MsoNormal">Even within a schema like AP242, some data models have not
been widely implemented, nor tested within the CAX-IF.   For instance, AP242 and its ancestor AP203,
contain information such as requirements, functional breakdowns, person &
organization, approvals, security classification, information rights,
project/contract, etc.   However, recommended
practices on how to use these in exchanges have never been developed by the
CAX-IF, so it is not likely that they are exchanged between different software
applications.   The current strategy in LOTAR
Meta-data is to put this information in a wrapper based on PLCS and point to the
shape files, or in MIL-STD-31000 to encode the information in User Defined
Attributes in AP242.   </p>

<p class="MsoNormal">To summarize, STEP has been developed by large automotive
and aerospace companies to solve very similar problems as those faced by OSHW.  IMHO, STEP schema and standard development
should be left to the experts because it takes considerable effort to get up to
speed on the specialized technologies.  
The OSHW community could work through existing STEP experts and
organizations to get what OSHW want implemented in the standards.   However, it takes persistent effort to synch
up with the various relevant ISO, CAX-IF, LOTAR, PDES, and ProSTEP meetings, projects,
and schedules.   A less onerous approach
is to track the STEP developments and use them for OSHW purposes.   For instance, like the MIL-STD-31000 TDP community,
OSHW could come up with modeling practices and model attributes that they need
and propose modeling guides for the former, and a set of User Defined
Attributes to encode the latter.   PLCS
is more accessible than the rest of STEP, and existing PLCS templates and DEX’s
in development could be modified for OSHW purposes.   For instance, the LOTAR DEX’s could be used
as a basis for OSHW packaging.   Through
reference data, PLCS is capable of incorporating terminology from other standards
and specifications, like from OSHW.   In
the meantime, the OSHW community can develop their own domain terminology (while
mapping it to STEP and PLCS) and use it in lightweight data formats like Excel
files, pdf forms, and XML schemas.   This
latter approach has been used successfully by ProSTEP when developing the ReqIF
standard and simulation data management specifications.   </p>

<p class="MsoNormal"><o:p> </o:p></p>

<p class="MsoNormal"><o:p> </o:p></p>