Minutes
Implementors Forum -
February 16, 2000 - Melbourne Australia
Attendees: P. Germain-Lacour/ Calvacom, S. Gillies/ CanSTEP, B. Gischner/ EB, F.Glantschnig/ AMT Consulting, S. Han/ KAIST, T. Inouye/ Fujitsu, R. Klass/ DaimlerBenz, L. Klein/ LKSoftware, H. Mak/CNRC, L. McKee/ IBM, K. Ohkoshi/ JSTEP, A. Ohtaka/Cadceus, Y. Oodake/Toshiba, Y. Oota/ Hitachi, M. Palmer/ NIST, M. Pratt/ NIST, N. Sandsmark/ POSC/Caesar, G. Siebes/ JPL, H. Satoh/ JSTEP, E. Szmrecsanyi/ DaimlerChrysler, T. Tanaka/ Nissan, C. Vaughan/Rolls Royce, C. Viel/GOSET
Agenda
Introductions/Open Issue Review- L . McKee The BIG Issues AP Interoperability- L. McKee Unified PDM Schema- L. McKee Upwards Compatibility- L. McKee Functional Diagrams/Intelligent Schematics- M. Palmer The BIG Issues (Cont.) Modularity- L. McKee STEP Meta Data- J. U'ren The BIG Issues (Cont.) Solid Model History- L. McKee CAx/PDM Implementors Forum- C. Donges Implementation Forms Discussion- L. Klein EXPRESS short form implementations Problems with usage of several data sections in a p21-file How to know the "complex entity data types with several leaves" Open Discussion
Open Issue Review-
Martin Hardwick
Issue: 004 ARM vs AIM
Refer- Propose this be referred to QC as an AP mapping issue
Issue: 016 Polyline
Needs Exploder Discussion. Discuss 16 via exploder and resolve.
Issue: 028 Processor Usage
Closed- provided as guidance to CAx-IF and put in Knowledge Base.
Issue: 036 AP Identities
Open- Big Issue
Issue: 044 Solid Model Construction History
Open- Big Issue
Issue: 045 STEP File Meta Data
New issue- Meta data in Part 21 file. See notes on Jim U'ren presentation later. It would be helpful if Meta Data about STEP file contents could be placed in the file data section or header
This would assist in cataloging files on the web.
Stuff that came up this week- Martin Hardwick
**Positions on spherical coordinate and part 42 combination limitations to be sent out via the exploder. The going in position is that removing spherical coordinate from Part 42 E2 is OK, but the other 42 stuff needs further study and an explicit proposal on what will or won't be allowed.
The Big Issues
AP Interoperability- Martin Hardwick
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 214 DIS CC6. The interoperability focus areas are the Unified PDM schema and Modules/ Extensions.
Unified PDM Schema- Martin Hardwick
The PDM schema goal 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.
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 39 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 upwardly compatible. THIS IS 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- Martin Hardwick
The story here is very good. The current 40 series new editions, 40 series TCs and the Part 21 amendment are all upwards compatible from a physical file perspective.
Should we be concerned that the 15926 standard is not upward compatible with STEP? Unknown. On the surface it appears to sound concerning, but these are different arenas. 15926 is targeted for data warehouses while STEP is product centric. This may not be an issue, but more study is necessary. Maybe Matthew West or David Adam should present on this at some forum in the future. Larry will look into this.
Intelligent Schematics- Mark Palmer
Mark presented on the need for a STEP capability (possibly a module) that would deal with representing functional diagrams or intelligent schematics. It was generally agreed that such a capability was needed. There are questions on what should be provided. Replicating the existing schematics capability that is used by piping and electrical engineers is potentially available in APs 227 and 212. A generic diagram capability is available in 201/202/214 and other APs. Mark said he had talked with the STEP parametrics team and they walked him through their activities in intelligent models for simulation.
There is definitely a need to represent and define functions and connections between functions. It was suggested that Mark ask for advice and input from the Systems Engineering (AP 233) community. He said he intended to do that. He asked who might be willing to help. Larry McKee said he was interested in this area and would help get it started. Larry also suggested that Mark talk to Rob Bodington at BAE SYSTEMS.
Larry provided the current status and plans for module suites for PDM, drafting, tolerances, geometric validation properties and engineering analysis. The PDM and engineering analysis module suites are currently being developed in HTML. The PDM modules are to be ready by Bordeaux. There should be a first draft of the engineering analysis modules by the end of March. The plan for geometric validation properties is to continue testing in CAx-IF and the Aerospace Engine Alliance pilot and produce a technical specification in third quarter. The geometric dimension and tolerance and drafting modules are planned to be submitted as technical specification in the fourth quarter.
Finding things on the web can be difficult. Most search engines are like drinking from a fire hose:
More than you can handle; can't get what you want; Don't know where the hose has been and if you should be drinking from it. Jim said that STEP files and data will have limited use if they are not available and findable via the web.
The web has a set of META tags in HTML which are extremely underutilized. NASA is working with others to propose and standardize through W3C and ISO a standard for Core Meta Data. This is minimum TAGs and object should carry with it to help identify and classify it.
The proposed standard lists the following as the Core Meta Data for an object: Title, Contributor, Source, Creator, Date, Language, Subject, Type, Relation, Description, Format, Coverage, Publisher, Identifier, Rights. (See Slides for details.) Larry McKee stated that a number of these are covered by the PDM schema in STEP, but that would not help the web cataloging problem unless it were made live or understood by web servers/ browsers.
Larry suggested that Jim talk to David Price or WG11 and see what their thoughts would be on mapping the proposed Core Meta Data to STEP. For Part 21, these could become new standard header entities. There may be other solutions in the SDAI and XML implementation methods.
Solid Model History- Martin Hardwick
M. Pratt and A. Ohtaka joined the forum for this discussion. STEP has an issue at present since the solid models currently exchanged have limited usability. The solids arrive as a single whole with no history. This limits changes to what can be done by boolean operations. This is much too limited to perform collaboration which is done by editing the solid creation operations.
A study has begun to look at what current CAD capabilities exist for users. The goal is to design a STEP structure that will enable application that mimics the normal CAD operations. The team has developed a list of high priority capabilities which include: Linear sweeps of sketch (extrusion), Rotational sweep of sketch, Boolean operations (union, intersection, diff.), Blending (including rounding, filleting, etc.), Rigid body transformation (translate, rotate) , Generation of feature patterns, and Use of system defined features from a library.
The STEP CSG operations can be used as a starting point for this capability. There are problems that exist since current CAD systems do not use CSG type operations for creating blends and fillets. These are problematic from a history point of view since bit of the original model are deleted or disappear. In order to record these operations, a scheme of global unique identifiers may be needed for all elements in a model. This can be tough to guarantee since uniqueness must be guaranteed for all entities in a file or database.
Mr. Ohtaka pointed out that design intent also needs to be preserved. This means that a simple recording of what one designer did is not enough. We may need to know why it was done. This can be very important where the granularity of solid operations differs between systems.
Mike Pratt stated that his team is working the problem aggressively but could use help from vendors. They are looking forward to results of a planned experiment in CAx-IF that will try solid model history based on CSG to see what issues arise and how much is covered.
CAx and PDM Implementors Forums- Christian Donges
Christian stated that CAx-IF and PDM-IF are joint STEP testing activities of ProSTEP and PDES, Inc.
Christian introduced the participating vendors in CAx-IF and the schedule since its inception in March of 1999. The current round of testing is 3J which is the third joint round. This round began in December 1999 and ends at the end of March 2000. The test cases are: a draughting test case with 3 views of a block, a validation properties simple assembly test case, a toy surprise capsule model for testing colour and text, and a block with holes to test features. This round would also test some sample production models. Further information on this can be found at either the www.cax-if.de or www.cax-if.org web sites.
Christian next described the PDM-IF activity. He introduced the participating vendors in PDM-IF. The translators tested are prototypes or in development versions of commercial PDM interfaces. The testing uses common PDM data schema generated and maintained by PDES, Inc., ProSTEP and JSTEP. This is a real subset of PDM from relevant STEP APs (AP203, 212, 214, 232). The functionality supported for parts and documents is Identification, Versioning, Structures incl. transformations, Approvals and authorization, Project, Work order, Work request, Effectivities, Classification and Properties. The current test round will be based on the PDM usage guide 4.0 which is available at the www.pdm-if.org site and test all the capabilities of the schema except security classification.
Christian said there were many implementations of the PDM schema. Most of these are prototypes at present. The implementations are listed on his last slide. Further information on PDM-IF can be found at either the www.pdm-if.de or www.pdm-if.org web sites.
Implementation Forms Discussion- Lothar Klein
Lothar is using his own (LKSoftware) toolkit to build applications based on STEP and JAVA. He favors implementing from the short form. The JSDAI toolkit works on any of 9 AP schemas in short form (202, 203, 207, 209, 210, 212, 214, 224, 225), 18 AIC schemas, 49 IR schemas, 4 PLIB schemas (20, 42), 3 ARM schemas (210, 212, 214) and 2 Mappings (210, 214). In traditional computer systems, every application has its own isolated memory space. Lothar predicts that pure Java systems will have a kernel based on the operating system, JAVA virtual machine, Java API library and special purpose (e.g. STEP) API libraries. This extended kernel will interface with a Java application which will have a common memory space. Application will be based on reusable components (beans) hooked through an API to an implementation. The implementation can have a Java SDAI (based on Part 27) API hooked through a SDAI session to application data, which is navigated, based on a dictionary and mapping. The implementation can get data from the outside world through a Java SDAI server or STEP Part 21 files. An AP 203 application can be built base don a 3D viewer bean and PDM beans. This can all be done by navigating short forms (see slides).
This technique has been utilized in the German 3DMID project which takes MCAD AP 203 data and GERBER/HPGL electrical PCB data and can store it in a SDAI repository or use it to drive an 8 axis LASER machine for producing non-planar PCBs on the inner surface of a plastic case. This implementation uses extensions to AP 203 to describe tessellation data and other structures needed that are not supported in 203 natively.
Lothar went on to describe a problem which has been mentioned many times by SDAI implementors. The STEP data models are very loose in regard to limitations of permutations and combinations of SUBTYPE combinations of geometric (and other) entities. Lothar suggested that STEP should move to designing models that describe only the combinations of SUBTYPEs which are required. At present, the current models allow for huge numbers of permutations most of which are not possible in reality.
Open Discussion- There were no other topics and time was up so the forum was closed.
** NOTE- Subsequent to the meeting, PPC, WG12 and other decided that the spherical coordinate issue would be solved by removing the entity from Part 104 and using a TC to add it to the 1994 edition of 42 (with cylindrical, polar, etc.) This does change 209 and 104 but is a minimal change. See WG12/Change management minutes for the exact details.