[Discuss] open hardware documentation survey

[Charlie]

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.   

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.   

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.      

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.   

Here is a Wikipedia article I drafted on AP242.

http://en.wikipedia.org/wiki/Wikipedia_talk:Articles_for_creation/AP_242

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.   

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

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.   

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.   

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.   

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oshwa.org/pipermail/discuss/attachments/20130327/e6c45f4c/attachment-0001.html>