Frequently Asked Questions
|
|
NASA STEP FAQ Frequently Asked Questions |
The information generated about a product during its design, manufacture, use, maintenance, and disposal is used for many purposes during that life cycle. The use may involve many computer systems, including some that may be located in different organizations. In order to support such uses, organizations need to be able to represent their product information in a common computer-interpretable form that is required to remain complete and consistent when exchanged among different computer systems.
STEP (ISO 10303) is an International Standard for the computer-interpretable representation and exchange of product data. The objective is to provide a mechanism that is capable of describing product data throughout the life cycle of a product, independent from any particular system. The nature of this description makes it suitable not only for neutral file exchange, but also as a basis for implementing and sharing product databases and archiving.
STEP technologies include STEP translators for CAD/CAM/CAE tools, STEP-based data management applications (database systems and applications that recognize and interact with STEP data), and STEP-based utilities for browsing, visualizing, and merging and splitting CAD/CAM/CAE models in the STEP format. "Merging" and "splitting" refer respectively to the combining of different engineering discipline models (e.g., mechanical CAD and electrical CAD) and the separating out of one discipline model from another that contains it (e.g., a mechanical model from an electromechanical model).
No -- there are fundamental differences between STEP and the IGES and DXF formats.
STEP provides a complete product information architecture, which includes a file exchange format, and several other implementation methods. IGES and DXF are just geometry file exchange format specifications.
The STEP architecture includes:
IGES and DXF only define file exchange formats, and they only address the geometrical aspects and some very simple physical properties of a product -- they do not have a systematic information architecture.
Engineers do not need to acquire an in-depth knowledge of STEP, but it will be beneficial to them to know how it works in general terms. STEP provides a neutral data format for the exchange of CAD/CAM/CAE models and PDM data -- which is generically referred to as "product data".
It is also useful to know that there are essentially two "levels" at which STEP can be used, which I will call Levels A and B (this is a simplification of the 4 levels of implementation that were originally conceived for STEP ... which I will not describe here, since they are more technical and require more knowledge of STEP "internals"):
Level A: STEP File Exchange
At this level, one buys CAD/CAM/CAE tools that have STEP translators and uses the translators to exchange data between tools via STEP files. STEP file exchange currently supports data exchange between tools capable of reading/writing the same STEP Application Protocol (AP), which -- since all mature commercial STEP translators currently are based on AP 203, which supports configuration-controlled 3D design -- enables models to be exchanged MCAD-to-MCAD and MCAD-to-Analysis (for some analysis tools, such as MSC Patran, that can read AP 203 files). In the future, as more STEP translators are implemented and more AP's are added to STEP, STEP files will support exchanges of other types of data (e.g., FEA data) between similar tools, as well as exchanges of data between different types of tools (e.g., ECAD-to-MCAD, etc.). However, to fully leverage the Product Data Management capabilities inherent in STEP's data structures, a Level B implementation is necessary.
Level B: STEP Database Application
A STEP database application can take many forms, from a simple database that stores and manages STEP files to a sophisticated Product Data Management (PDM) system that uses the STEP data structures as the core of its database schema. The power of utilizing the STEP data structures is that the database application then has "internal knowledge" of the models it is managing, even though they were originally created in proprietary formats on COTS CAD/CAM/CAE tools.
The Level B STEP capability is beyond the current state of the art of COTS PDM tools, although several OEM's (Boeing, Lockheed Martin, and IBM, for example) have proprietary in-house systems that are beginning to implement that type of capability -- which they, quite rightly, regard as a significant competitive edge. Of course, NASA's in-house systems will never be as sophisticated as Boeing's or Lockheed Martin's, but to implement the collaborative and highly integrated engineering environments needed for the next generation of NASA missions requires advanced PDM capabilities that can only be implemented properly, from a software engineering perspective, using an internal database schema that maps invertibly to the most important STEP Application Protocols.
IMPORTANT: Level B requires Level A. STEP translators must be available for the CAD/CAM/CAE tools that are used, so that their models can be translated to STEP for management within the STEP-based database application.
The documents of the STEP standard (ISO 10303) are copyrighted and published by ISO. They are available electronically and can be procured from ANSI (the U.S. American National Standards Institute) -- go to:
... and search on "10303" or something similar.
If you are interested in really understanding a STEP Application Protocol (e.g., if you are creating an application that needs to read or write files containing STEP data), I strongly recommend that, in addition to obtaining the ISO document that defines the application protocol, you check whether there is a Recommended Practices document -- the place to look is the PDES, Inc. web site.
PDES, Inc. is a government-industry consortium formed for the specific purpose of developing and implementing STEP (ISO 10303). The consortium's computer lab and technical and administrative staff are located at SCRA in Charleston, SC. Member companies of PDES, Inc. include Boeing, Lockheed Martin, Northrup Grumman, Rockwell, British Aerospace, Ford, GM, Rolls Royce, and many others. The projects of the consortium are funded by its members. Companies who are members of PDES, Inc. pay membership dues each year and contribute 1 or 2 technical personnel full-time to PDES, Inc. projects. Government members do not contribute money but must contribute 2 FTE's per year (which can be contractors).
PDES, Inc. projects are divided into 2 major categories: Development and Deployment. The products of PDES, Inc. projects depend on their category:
(a) PDES, Inc. Development Projects
Development Projects are focused on testing, maintaining, and extending the STEP standard. Some of these projects develop STEP Application Protocols (AP's), and some contribute to the further development of the STEP architecture and the EXPRESS language, which is the computer-sensible information modeling language in which the STEP standard is formulated.
For example, PDES, Inc. is the "owner" of AP 203, the most widely used of the STEP Application Protocols (AP 203 defines the STEP data structures for the exchange of configuration-controlled 3D designs). "Owner" in this sense means "editor and configuration manager" (the copyrights for all the documents of STEP is, of course, owned by ISO), so PDES, Inc. manages and technically coordinates all corrections, enhancements, and upgrades to AP 203.
Another example of PDES, Inc.'s contributions to STEP is the STEP Modularization Initiative -- a major revision to the STEP architecture which will greatly enhance the re-usability of STEP-based software applications. This PDES, Inc. initiative has been enthusiastically received by the international STEP community.
(b) PDES, Inc. Deployment Projects
Deployment Projects are also known as Pilot Projects, in which several PDES, Inc. member companies/agencies participate in the joint development of a STEP-based data exchange capability. An example is the Electromechanical Pilot, in which Boeing (Seattle), Delphi Delco Electronics Systems, NASA, and International TechneGroup, Inc. (a developer of STEP translators) are participating. The EM Pilot is developing the capability to exchange design information for electronic boards, packaging, and enclosures between electrical CAD and mechanical CAD groups working concurrently.
The benefits to NASA from its participation in PDES, Inc. are (1) access to PDES, Inc. "Products", which are available only to PDES, Inc. members and which include software, technology evaluations, and technical papers; (2) access to detailed information on the application of STEP to the integration and management of CAD/CAM/CAE models in the engineering design and manufacturing process; and (3) hands-on experience working with technical personnel from PDES, Inc. member companies who are using STEP for database and application software development.
The bottom-line benefit is the acquisition of knowledge by engineering data management personnel (such as myself, the IMDC programmers I work with, and our counterparts at the other NASA Centers) of the structure of STEP and techniques for applying STEP to (1) the integration of CAD/CAM/CAE tools with Product Data Management systems, and (2) the procurement and development, implementation and configuration of STEP-based COTS and in-house developed software applications to support concurrent engineering.
It is necessary for NASA's engineering data management personnel to have this knowledge in order to implement an agency-standard, open (standards-based) software infrastructure for Configuration Management (CM) and Product Data Management (PDM) for the inter-disciplinary CAD/CAM/CAE models that will be used in NASA's Collaborative Engineering Environment (CEE).
To answer the second question first: yes, some aerospace companies are prototyping STEP technologies. The ones who are doing this are the large OEM's (e.g., Boeing, Lockheed Martin, Northrup Grumman, etc.), all of whom are members of PDES, Inc. The fact that these large aerospace firms are prototyping STEP will benefit NASA indirectly, but it does not help NASA to make the best use of STEP within its own engineering processes. In order for NASA to get the maximum benefit from STEP, we need to have in-house STEP-based database applications that go beyond simple file exchange -- i.e., the "Level B" implementation.
And now for the first part: prototyping STEP technologies in the NASA testbed could accomplish three things:
In the following excerpt from a short report entitled "Taking a step forward with FLAIR (Foster Wheeler Lifecycle Asset Information Architecture -- ISO-10303 Standard for Exchange of Product Model Data)", arguing that information management is more important than information technology, Ian Glendinning of Foster Wheeler describes the progress being made towards putting STEP into practice in the process industries:
At last year's UK Process Industry IT Strategy Conference, organised by IChemE and PRIMA, several speakers referred to the success of IT in many service and manufacturing industries and contrasted this with the failure of billions of dollars of IT investment over 10 years to deliver such benefits to the process industries. The lack of success was blamed on 'failure in the boardroom to grasp the information management agenda.'These same speakers -- directors from the oil, gas and chemical majors -- shared their visions of information and knowledge as their key corporate asset to be exploited by making it available to anyone, anywhere in their organisations. Most agree that the key issue is not IT but Information Management, and that a major dimension of this involves soft issues like knowledge, people, and business culture.
Although the data integration and standardisation objectives are widely accepted, few people ... would accept STEP as fully proven in the bottom line. However, there is already a threefold drive to create a strategic framework ... at this stage:
Firstly, the pace of change in IT continues to be so great that planning future exploitation cannot be left until the potential is fully proven and developed in detail.
Secondly, the potential changes are so far reaching in terms of 'business re-engineering' possibilities that the cultural changes needed cannot simply be switched on once STEP becomes a shrink-wrapped solution.
Finally, the complexity of the detail is such that fully detailed STEP solutions will not arise from standards development alone, without the iteration provided by early implementation.
The idea of using STEP to support a systems perspective is definitely dependent on using STEP at Level B (the database level): the only way to get a systems perspective (via computer) of a modeled system (i.e., a system of which the only representation is set of CAD/CAM/CAE models) is to have a complete model of the system, in which all the engineering discipline-specific models' data for all parts of the system have been integrated. At the present time, I know of no COTS applications that can integrate models at this level, but this is exactly the type of capability that a STEP database can enable. In this sense, STEP is truly advancing the state of the art in computer-aided systems engineering. In fact, this is part of a class of capabilities (that I refer to as "Intelligent PDM") made possible by a "STEP-literate" database. By "Intelligent PDM", I mean a Product Data Management application that understands the semantics -- the internal data structures and their meanings within the application context -- of the product model data that it manages.
Using this STEP-based model database as a foundation, intelligent systems engineering applications can be developed to check models from various systems perspectives -- e.g., assembly-level and interdisciplinary design rule-checking, manufacturability analysis, etc. Using a STEP-based, interdisciplinary master model template, which is populated incrementally with the evolving fragments of a product design over the course of its development life cycle, the sky is the limit for knowledge-based systems engineering applications.
Although I have surveyed the Product Data Exchange Working Group to identify the PDM requirements at the NASA centers, I have not yet discovered any PDM requirements that are unique to NASA. On the basis of all input to date, I must conclude that all NASA requirements for PDM are included in the PDM requirements that have already been identified by the STEP community. I am therefore implementing PDM capabilities based upon the STEP PDM Schema, which has been designed to cover all known industry requirements for PDM. Within those requirements, I am collecting the priorities of the NASA Centers, and I will use those priorities to determine the order of their implementation within the STEP Testbed.
The fact that NASA has no "new" PDM requirements beyond those already identified by the STEP community should not be surprising, since one would naturally expect the PDM requirements of companies like Boeing, Lockheed Martin, and IBM, who are three of the most active companies contributing to STEP, to be at least as comprehensive as NASA's.
Commercial PDM systems do not currently offer the capability to integrate multi-vendor (much less multi-discipline) models. That capability will, over time, become available as some PDM vendors adapt their systems to utilize the STEP paradigm, but the capability to do the "Intelligent PDM" that I have described will require fundamental re-engineering for many of these commercial PDM systems.
Our initial demo will focus on basic PDM capabilities which, in themselves, could be done (at greater expense) using a COTS PDM product. The critical difference is that we are defining this basic PDM capability in such a way that the "mission characteristics" that have been identified as the most important parameters to define and monitor in initial systems engineering activities will be modeled in an intelligent (XML) format that will make them accessible for mapping, as the STEP Testbed continues its development, to the internal characteristics of all later design models, analysis models, simulation models, test data, and fabrication models of the mission -- including spacecraft, science instruments, flight subsystems, and support systems. Thus, this initial demonstration is just the first checkpoint on the way to the long-term goal of implementing the "Intelligent PDM" capability I have described above.
In asking the cost/benefit question implied by "what are we doing that PDM vendors can't do?" -- which is always worth asking -- it is important to maintain the "Total Cost Accounting" view of software acquisition. Two observations in this regard:
(1) Large, complex software systems that fit into and dictate enterprise processes and capabilities always require, beyond their purchase price, a substantial investment in skilled personnel to install, adapt, program, configure, operate, and maintain them. The more open and standards-based these systems are, the better the long-term return on the investment in those personnel resources (which are probably going to be at least as expensive, if not more expensive, than the price of the software itself). Their knowledge and skills will then be aligned with a standard technology rather than with a proprietary, vendor-specific technology that may become obsolete tomorrow.
(2) PDM systems can be implemented at many levels, from simple workgroup systems to enterprise-wide -- possibly distributed -- systems and anywhere in between. Even at the workgroup level, PDM systems are non-trivial, and require detailed configuration and adaptation to local processes and software with which they must interoperate.
The point of these observations is: the size of the investment in a large, complex COTS software system is significant enough that it should be weighed carefully against the alternative of using a standards-based framework of software components (some of which may be procured and some developed in-house) with which in-house software and systems personnel can become intimately familiar, and which can be used to interface with standards-compliant commercial software products. Such a standards-based framework will be interoperable with any sufficiently standards-compliant COTS product, so that various specific workgroup, project, and center requirements can be met by an optimal combination of COTS and in-house developed software tailored for each particular locale and requirements set. This approach also facilitates the development and integration of specific capabilities that are not available off-the-shelf, as is the case with the target capabilities of the STEP Testbed.
The primary goal of the STEP Testbed is to define and develop such a standards-based software component framework for NASA PDM, and especially for its more advanced ("Intelligent PDM") applications.
A Conformance Class (CC) defines a valid subset of an Application Protocol (AP) that supports a related set of use-cases or a business process. For each CC or combination of CCs, a number of test cases can be generated and used during the formal Conformance Testing of an implementation of the AP.
The complete schema for any AP is a large and complex Product Information Model, whereas its CCs are more easily comprehended, semantically coherent subsets. Moreover, an AP is not a simple hierarchy of classified types but a network of interrelated Entities (data objects) that may be populated in many different ways to reflect their information content.
Although it is theoretically possible to define CCs for every permutation of the possible populations of an AP, it would be counter-productive to do so, as it would result in the creation of several thousand CCs. The creation of a few canonical CCs is the more realistic approach that is taken by STEP. These CCs are then used as required for focused implementation and testing.
Put simply, an AP is larger in scope and has a greater range of functionality than any particular engineering software tool or application. Thus, it is unlikely that many software vendors will implement an AP in its entirety.
Therefore, APs are generally implemented in smaller chunks that match application scenarios. These chunks -- the CCs -- may be combined if necessary. CCs may also be used (individually or in combination) to formally describe the scope of a conformant application (such as a translator).
Obviously, the scope of the application may be greater than that of an individual CC, but the information that the end users will wish to share in a particular exchange or interaction will usually fit into one CC, although combinations of CCs may also be used. The vendor of the engineering software application seeking conformance is then at liberty to choose how the CCs are combined.
Although CCs may be used formally to define the scope of an exchange file, most engineering end-users will not need to know the details of CCs. All they need to be assured of is that when dealing with applications that have overlapping sets of CCs, exchange of useful and semantically valid data is possible using STEP.
A Conformance Class (CC) is a valid subset of an EXPRESS AP schema. A CC is specified as a "short form" EXPRESS schema using STEP schema interfacing. Conformance Class schemas contain no entity or type declarations, merely the USE FROM and the REFERENCE FROM declarations. All the entities referred to in a CC schema are declared explicitly in the long form schema.
If instances of these entities were created and their attributes correctly populated, the set of data produced would be coherent and valid, and if it were exported from the STEP data repository, a valid STEP Part 21 file would result. At the same time, information conforming to a CC is compatible with the complete AP schema.
Here are some places to start:
Responsible NASA Contact:
Steve Waterbury
Chair
NASA Product Data Exchange Working Group
NASA WWW Home Page