Implementors Forum - November 10, 1999 - New Orleans, LA, USA Minutes

Attendees: D. Adam/ Halliburton, R. Barra/ ATI, P. Brorson/ Volvo, J. DeLoof/ PDES, Inc., S. Gillies/ CanSTEP, B. Gischner/ Electric Boat, W. Gruttke/ Team SCRA, S. Han/ KAIST, H. Hiraoka/ Chuo University, J. Holmlund/ Lockheed, T. Inouye/ Fujitsu, Z. Junfeng/ China Standardization Research Center, H. Kakuno/Kawasaki, T. Kato/Toyota, R. Klass/ DaimlerChrysler, I Van Koetsveld/ CIM Architects Delft B.V., Chie Kouchi/ JECALS, S. Lindgren/ EDI-Odette, M. Loeffler/ GM, D. Lofredo/ STEP Tools, H. Mak/NRC Canada, A. Moreno/ENEA, N. Newling/ Royal Navy, K. Ohkoshi/ JECALS, Y. Oota/ Hitachi, P. Rivault/ GALIA-Odette, H. Satoh/ JECALS, T. Segami/ MicroCAD, T. Shirai/ ENAA, K. Simon/ Volvo, H. Somemiya/ JECALS, G. Staub/ PDTec, N. Swindells/ Ferroday, E. Szmrecsanyi/ DaimlerChrysler, T. Tanaka/ Nissan, C. Tierney/ GDLS, T. Thurman/Rockwell, M. Toho/ Mazda, K. Ueyama/CTIE, M. Yoshida/ Toyota, T. Yoshinaga/ Hitachi


Introductions- L. McKee

Open Issue Review- L . McKee

Long Term Archival using STEP- MOSLA - T. Kato

EXPRESS-X for PDM- G. Staub

Epistle Implementors Report- D. Adam

The BIG Issues- L. McKee

AP Interoperability- L. McKee

Unified PDM Schema- L. McKee

Upwards Compatibility- L. McKee

Certification Testing- L. McKee

Shipbuilding Implementors Report-Burt Gischner

AP 210- J. DeLoof/T. Thurman

Modularity- R. Barra

CAx/PDM Implementors Forum- L. McKee

Open Discussion

Open Issue Review - L. McKee

Summary- 44 Issues - 5 Open - 1 Added this forum

Note: The issue log will be updated to reflect when issues were logged (according to our records). We will use this to track implementor/standards progress on issues.

Issue: 004 ARM vs AIM remains open. Issue: 016 Polyline remains open and needs to be resolved with some input from the WG3 shape representation team. Issue: 028 Processor Usage remains open to see what CAD companies or third parties might do to assist. Issue: 036 AP Identities remains open, but progress is being made in correcting AP interoperability. Issue: 041 Defining New Conformance Class

was deemed closed (pending Mr. Udagawa's concurrence) since new classes can be defined via TCs, amendments or new editions of APs. This can be driven by the market.

New Issues

Solid Model History

The STEP standard needs to support the transfer of solid model construction history information to allow for incremental modification of the received solid. The current information structure results in a unary solid which is difficult to use for collaboration.

Long Term Archival using STEP- MOSLA - T. Kato

MOSLA is the Maturity Of Standard for Long-term Archiving. MOSLA is specifically concerned with the long term archiving of CAD data for 2D/3D models and drawings. There is a web site at http://www.mosla.org/.

We need to retain data for long periods. These can be 40 or more years. In the case of an automobile company, the number of permanently preserved drawings can be 200,000 per year. In Japan alone, this can be ten million cases per year!

This gets more important with each passing year as we move from "drawing authority" to "data authority". The preservation of native CAD data requires preserving the hardware, OS, CAD system software and the CAD data. We need a neutral standard. JSTEP began looking at this in 1996. The current proposal is to use a combination of AP 202 and 203. AP 202 was deemed acceptable for use by JSTEP in 1998.

The MOSLA project began in the fall of 1998. The members of the project are: Toyota, Mitsubishi, KHI, IHI, IBM Japan, Unisys Japan, iSiD, TSE, JIM, and MicroCAD. The project has developed software for a STEP Viewer and AP202 file creator. In early 2000, the project will publish a book detailing recommended practices (mapping agreements and standards usage guide). They are in the process of trying their mappings in both an automotive and aircraft trial.

MOSLA is meant for internal company data retention and NOT data exchange. The project has chosen subsets of AP 203 and 202 and provided extensions where data was deemed missing. This is intended to be a de facto standard initially. It may then be proposed to ISO.

EXPRESS-X for PDM- G. Staub

This effort was a part of the PDMI2 effort and involved PDTec, DaimlerChrysler and debis. The PDMI2 STEP DIALOG Processor is a mapping of DaimlerChrysler BOM system DIALOG to STEP AP214 AIM. The initial focus was on export to AP214 Conformance Class 8 (CC8).

The effort involved translation from DIALOG to an EXPRESS representation of DIALOG. This was a direct translation with all 1:1 mappings. The EXPRESS representation of DIALOG was then mapped via EXPRESS-X (10303-14) to the AP 214 ARM which was in turn mapped via Express-X to the AP 214 CC8 AIM.

Phase 1 used an EXPRESS-X-Parser provided by DaimlerChrysler Research and Technology. It was found that the mapping specification is easier to read and understand than conventional mapping code (e.g., using SDAI and C/C++). Also numerous issues against EXPRESS-X were found.

Phase 2 used the ECCO XXL Toolkit of PDTec GmbH which enabled complete syntactic and semantic tests of the EXPRESS-X mapping specification with full automatic code generation. This allows the direct execution of the mapping specification. The tool causes a significant reduction of needed effort for coding the mapping where coding time was 1/16 compared to conventional coding (based on previous SDAI implementation experience at debis SH Industry).

Epistle Implementors Report- D. Adam

David explained that EPISTLE is made up of POSC/Caesar, PISTEP, USPI-NL and German Power. He then listed the members of POSC/Caesar, PISTEP and USPI-NL.

He then described the implementation projects performed by the group. The Statoil Asgard project uses Intergraph's NOTIA with POSC/Caesar data model. The ELF Elgin Franklin effort is using Intergraph's NOTIA with POSC/Caesar data model. Shell's Shearwater project worked by AMEC and uses Quillion's PETS product with PIPPIN based data model. The OMAN LNG (Shell) effort is being worked by Foster Wheeler using PrismTech's product OpenBase with POSC/Caesar Data Model. The Shell Pernis refinery has two projects pending which are an INCA Application of AP221 for piping exchange of data and GE200 Application of STEP (details to be specified). Nigeria LNG has a multi-billion dollar Liquid Natural Gas train which uses STEPlib reference data (Shell). Nanhai has a new chemicals site (joint venture of Shell Chemicals & Chinese partners) multi billion dollar budget, wide use of A221 and STEPlib included in project requirements. NAM/GLT is creating a document management system with storage & retrieval using STEPlib and are working SAP and MATRIX on an implementation using STEPlib as Engineering dictionary for standardisation. Lyondell Chemicals ha a project in Botlek Europoort on Hold which may include a STEP Data Warehouse. BP Grangemouth E4 Plant has information being passed to operations via a Quillion data warehouse. In Japan a chemicals refinery for JGC and Fujitsu has linked an engineering database to a maintenance database using Quillion's PETS product.

There are also internal company developments. Foster Wheeler has a project called "FLAIR" Foreword Lifecycle Asset Information Architecture in 1997. Now developing an asset lifecycle database (ALD). AMEC is working on corporate engineering repository development. Shell has created an Asset Information Management (AIM) group. UMOE is developing data warehouse capability using I+C=S Products for use in late 1999 based on the POSC/Caesar data model. Statoil is working on what they call the "Cyber Org".

In R&D, the GDT project is an application to exchange data between companies on a STEP AP221 basis using generic data templates. The I&C/2 Project is an application to exchange Functional Control Logic Diagram between contractors/plant owners and DCS vendor / suppliers. Demonstration planned for Nov 99. The PIPES/2 Project is a catalogue for piping data using STEP AP221. Demonstration planned for Q-1 2000. SYNERGY is a project worked by PRISMTECH, Oracle, Chevron, Foster Wheeler,and Statoil. The HOPE/2 effort is creating a pump data catalogue using STEP AP221 with a demonstration planned for July '99

The BIG Issues- L. McKee

The BIG Issues are AP Interoperability and Upwards Compatibility.

AP Interoperability-L. McKee

Currently the process to resolve this involves: identifying the focus areas of overlap between APs; isolating specific issues; resolving the issues; testing the resolutions; standardizing the resolutions.

In this process integrated resource changes have been identified as well as AP changes. There will also be part 21 extensions to support AP interoperability to allow multiple schemas and data sections in one file and inter-referencing between data sections.

Some of the current techniques exhibited in AP 208 and AP 214 DIS CC6. The interoperability focus areas are the Unified PDM schema and Modules/ Extensions. Rogerio Barra will discuss modules later in the day.

Unified PDM Schema- L. McKee

The PDM schema goal and plan was presented. The schema itself is an effort to come up with one way for STEP to do PDM. Product Data Management (PDM) is an enabling technology that helps a work group, department, division, or enterprise manage product data and the development process throughout the product life cycle. It is file access and control. It is management of data relationships. It is configuration and version management. It is engineering change control. It is establishing multiple linked views of product data. It enables integration.

Essentially the goal here is to capture in a standard way the information commonly found on parts lists and applications lists. PDM is data about data and the overall linkage between graphic and business data. It can and does transcend the life cycle. It is the basis for the product data continuum. It is the "backbone" of the body of product data.

The schema is available now and has a complete usage guide. It will be standardized in APs (a la AP 214 CC6) and in modules. There are currently 36 defined modules. They can be divided into blobs. There are Foundation modules (FMs) like Date/ Time/ Organization/ Product/ etc. There are also Application Modules (AMs) like Part/ Document/ File Identification; Assemblies/ Relations; Part to Part/ Part to Document/ Part to File, etc; Engineering Change and Configuration Identification/ Effectivity.

It should be noted that AP 203 and the PDM schema are not identical or upwardsly compatible. THIS I S NOT NEW NEWS. We knew (and said) at the outset that AP interoperability would require changes. PDES, Inc. plans to make converters available for current users of AP 203 (see charts for details).

Upwards Compatibility- L. McKee

The story here is good. The current 40 series DISs, 40 series TCs and the Part 21 amendment are all upwards compatible from a physical file perspective.

Currently, there is a proposal to stop creating short names for entities and types. The issues being raised are NIST would like to drop support for registry and there is a questionable technical value of short names since available compression algorithms work much better.

Certification Testing- L. McKee

US Pro Testing Details

The scope of US Pro testing (contact: Chuck Stark) will be STEP AP203 cc1a, cc6a for initial test period which is for six months or up to six products/applications. The cost for initial test period $5,000 for pre and post processor. A processor may have up to two re-tests, if required. The cost of re-test $2,500 per preprocessor or postprocessor. Common sense will prevail in judgements (e.g. no re-test required for misinterpretations, typos, etc.)

The sample test data available on certification web site at no cost. Vendors encouraged to process sample data first. The test analysis not included on free site. There is a STEP structure checker and other tools available on other sites.

The official testing process is: apply to US PRO for test account; account established with "live data"; ten business days allowed to process and submit data files; results available from test lab within ten business days; debriefing conference call to explain results; re-test if necessary or apply for use of the mark

GOSET Testing Details

The scope of the GOSET testing (contact: Alain Bezos) is STEP AP203 all classes using the French Z68-333 standard (This is the same as 203 with TC2.) The accreditation of GOSET's laboratory by the COFRAC ensures the recognition of the test reports in 16 countries. Moreover, partnership agreements signed with AFNOR and its counterparts ensure an international recognition of NFTI Technical data exchange certificates.

Shipbuilding Implementors Report-Burt Gischner

The Shipbuilding community sees STEP as facilitating faster design times, better communication and longer lasting data. STEP supports design reuse, data retention, and provides access to data across a product's entire life cycle.

Low cost information sharing with STEP results in reduced time to market; reduced development; reduced overall costs; increased quality and increased flexibility.

The Shipbuilding Application Protocols are: AP 215 - Ship Arrangements which was implemented by MariSTEP; AP 216 - Ship Moulded Forms which was implemented by MariSTEP and SEASPRITE; AP 217 - Ship Piping which was implemented by MariSTEP; AP 218 - Ship Structure which was implemented by MariSTEP and SEASPRITE and a joint schema was implemented for MARISPRITE and AP 226 - Ship Mechanical Systems which is not yet implemented.

The current ship APs result from a long legacy of requirements definition. NIDDESC (Navy Industry Digital Data Exchange Standards Committee) which was active from 1987 - 1992 represented initial efforts to define product modeling data exchange standards within the shipbuilding industry. It developed exchange specifications for Ship Structure, Ship Piping, Ship HVAC, Ship Electrical & Cableway, and Ship Outfit & Furnishing . In Europe, EMSA (European Marine STEP Association has had several projects (NEUTRABAS, MARITIME, ShipSTEP and SEASPRITE.

MariSTEP/Shipbuilding-3 year effort to use STEP for shipbuilding data exchange. It began in July, 1996 and will conclude by December, 1999. The goals of the project are/were:

The MariSTEP Team Members are Avondale Industries, Inc., Ciarrai Computer Systems Ltd., Electric Boat Corporation, Ingalls Shipbuilding, Intergraph Corporation, Kockums Computer Systems, Inc., Newport News Shipbuilding, Parametric Technologies Corporation, University of Michigan, and Advanced Management Catalyst, Inc. The design systems were CV/ PTC/ Ciarrai, CATIA, Intergraph, VIVID and Kockums/ TRIBON.

Project participants split into two teams for early implementation. One team of 3 shipyards and their CAD vendors first implemented APs 215 - Ship Arrangements and 216 - Ship Moulded Forms. This included: Intergraph, KCS, and NNS. The second team of 2 shipyards and their CAD vendors first implemented AP217 - Ship Piping

This included : EB and Ingalls/Ciarrai. This approach enabled MariSTEP to perform successful transfers in both the Structural and Piping disciplines at a demonstration in Charleston, S.C. in August, 1998. The two teams subsequently switched tracks and the first team implemented AP217, while the second team implemented APs 215 and 216.

MariSTEP froze its schemas before translator development. Any problems encountered were resolved by implementor's agreements which were captured in a Systems Requirements Document (SRD). MariSTEP's success in identifying and resolving problems with the ISO schemas was facilitated by the adoption of a formal testing process. Rigorous testing was considered a very important phase of translator development. Each test involved Preprocessor Worksheets, Postprocessor Worksheets, and Entity/Attribute Checklists. Team exchange tests for each AP were organized into "Campaigns". Test cases started simple and built up to more complicated exchanges. Burt showed pictures of test cases (see slides).

The MariSTEP program demonstrated the potential for reducing the time and effort required to participate in a data exchange program. It identified a subset of STEP objects to be used to demonstrate data sharing and exchange in the virtual enterprise. It also captured and validated product model data requirements for several application domains of shipbuilding.

MariSTEP Project will conclude by December, 1999. The participants are currently completing final testing and documentation of their AP218 translators. A Lessons Learned Report has been issued which captures some insights from the Project

The MariSTEP Schemas and Systems Requirements Document (SRD) are being published as Interim NSRP Standards and can be invoked on U. S. government contracts.

Some MariSTEP participants have modified their AP218 implementations to accommodate a joint schema agreed to with the SEASPRITE Project. This will enable structural product model data exchange between U. S. and European Shipbuilders, CAD Vendors, and Regulatory Agencies. This will be demoed here in New Orleans.

STEP implementation for Shipbuilding in the United States will continue as part of the MARITECH A. S. E. Program. Evolution of STEP (ESTEP) is part of the Integrated Shipbuilding Environment Consortium (ISEC) Project. ESTEP will continue development of translators and standards for Shipbuilding.

AP 210- J. DeLoof/T. Thurman

John DeLoof discussed AP210 (Electronic assembly, interconnect, and packaging design). AP210 passed both the ISO and IEC Draft International Standard ballots and is being prepared for submission as an International Standard. An AP210 Recommended Practices Guide and a Concept of Operations document are currently in work, and Mentor Graphics and LKSoft are developing commercial AP210 translators. The scope of AP210 involves configuration-controlled design capture of electrical or electronic assemblies, interconnection, packaging, and associated library data. AP210 offers a separate model of the assembly and the interconnect and supports thermal, structural, and other physical analytical methods. AP210 also supports 2D and 3D design and usage views and offers parts modeling capability.

Tom Thurman presented on an AP 210 usage scenario for box level continuity. Box level continuity verification is the evaluation of the conformance of the physical interconnect to the intended interconnect between functional elements. AP 210 can support this since it can represent the board level netlist (CC 6), the box level netlist (CC 4), the box level physical interconnect layout and assembly model (CC8), a 3D to 2D standard model for connectors (CC1 subset) and functional to physical pin mapping.

The real challenge is to get mappings of various MCAD and ECAD part libraries to support the standard industry scenarios (EE - 2D ME - 3D) and have this be transparent to the operator. There must also be a functional pin mapping between the 2D and 3D libraries.

Modularity- R. Barra

Rogerio Barra presented that the major requirements for modularization are the high cost and lengthy time for developing an AP; companies requiring the implementation of a combination of multiples APs or AP extensions; the expectations from vendors for the reuse of application software; the duplication and repeated documentation of the same requirements in different APs; and the reuse of data generated by an implementation of one or more APs, by an implementation of one or more different APs (AP interoperability). One of the planned uses for modules is in the creation of extensions which could be applied to existing APs.

Rogerio discussed the PDM modules which were presented in detail earlier. There are presently around 30-40 of these. They are scheduled for ISO submission as technical specifications by year end. The modules are based on the PDM schema. The usage guide for the schema has been delivered and is available at http://www.pdm-if.org. This guide

provides the basis for PDM-IF and pilot project implementations.

In Geometric Dimensioning and Tolerancing, the team has developed Application Modules and Usage Guides for Default Tolerances for Geometric Dimensions and

Geometric Dimensioning and Dimensional Tolerances. They are working on Application Modules for Value with Unit and Multi-Language String.

A project has been started to address the requirements for solid model history using modules. The team has discussed relationships between CSG (Constructive Solid Geometry) and Features in solving this problem. The team believes they should move more toward feature-based development at present.

Rogerio next went into Drafting Annotation/Notes. This area is currently made up of the associative text and the associative dimension and model viewing capabilities. Since the last ISO meeting, they have delivered recommended practices for associative dimensions, model viewing and drawing structure to the vendors and improved documentation of recommended practices for associative text (after review). Both documents produced in cooperation with ProSTEP and are available at http://www.cax-if.org.

Rogerio explained that the first set of modules to be standardized would be those for shape appearance and layers. This is composed of 9 modules with one of the nine being shape appearance and layers itself. This high level module is the only one users would care about. They would have little concern for the lower level foundation modules (like colour). These modules have had their module EXPRESS schema combined with AP203 has been implemented by STEPnet vendors. They are based on AP214. They will be submitted as Technical Specifications shortly.

Lastly, Rogerio talked about the Geometric Validation Properties efforts. This has been a real success story. The module has been constructed and recommended practices document completed and harmonized with ProSTEP. Most CAD vendors have implemented this capability in test translator versions. The capability will be tested in the PDES, Inc./GOSET Aerospace Engine Alliance Pilot.

CAx/PDM Implementors Forum- L. McKee

In round 1J of CAx testing Alias, Autodesk, debis, SDRC, Bentley, PTC, UG Solutions, Theorem, STEP Tools, and Theorem participated. The results showed that for the draughting model - view and association came in at 100% success rate; view layout at 50%. The Geometrically bounded surface - 77.1%; topologically bounded surface- 63.1%. The solid assembly - volume change less than 1% was 68% successful; area change less than 1% was 57% successful. For Colors: Solid - 95.7%; Face - 100%; Edge - 100%. For associative text there was a 50% overall success rate. For validation properties - Centroid - 79%; Area - 57%; Volume - 50%. Different implementation methods of units caused most of the problems.

In the second round of CAx Implementor Forum testing, the following companies participated in the testing: AutoDesk, debis, UG Solutions, PTC, Euclid, ITI/CADDS, Bentley, Dassault, ITI/SDRC, STEP Tools, and Theorem Solutions. The success rate for validation properties ranged from 75% to 83% with the success rate for colors and associative text averaging around 80%. Production models will be added to the scope of testing in the next round.

The first round of PDM Implementor Forum testing yielded some challenges. The companies/systems playing were: BMW/ Prisma, Volkswagen/ KVS, STAMP/ Sherpa, DaimlerChrysler(debis)/ GIS, Dassault Systemes/ ENOVIAvpm, Eigner+Partner/ CADIM/ EDB, SAP/ R3, ProSTEP/ PDM Editor, UG Solutions/ iMAN. The testing covered Part Identification, Categorization, and Authorization; Document Identification, and Authorization and External File Identification. There were issues with familiarity with testing procedures, "Realism" of test data and test process and "realistic" scenarios.

Preparations are underway for the second round of testing in the PDM Implementor Forum. A new version of the PDM Schema file checker has been installed, and test cases are being developed, which will be distributed to vendors in early November. Testing will be completed in mid-December. The Implementation Support team is nearing completion of the PDM Schema to/from AP203 file converter, which was demonstrated for the TAC along with the web interface.

It was note by Reinhold Klass that user testing of surfaces and solids are yielding higher results. This seems to be caused by a lack of regression testing by the vendors prior to the CAx forum. It is also important to note that this is alpha/beta software. The production code is typically better. The vendors were asked to focus on details and do some home testing before the forum to try to eliminate silly errors.

Open Discussion