STEP – ensuring that the exchange process is identified correctly and managed properly

Citation

Ranger, T. (2004), "STEP – ensuring that the exchange process is identified correctly and managed properly", Aircraft Engineering and Aerospace Technology, Vol. 76 No. 1. https://doi.org/10.1108/aeat.2004.12776aaf.001

STEP – ensuring that the exchange process is identified correctly and managed properly

STEP – ensuring that the exchange process is identified correctly and managed properly

Keywords: Data exchange, Aerospace technology, Components, Software

For a decade now the “digital mock-up” has become a major part of the development of high technology products. The interrelationships of companies developing these products have also grown more complex. The OEM companies work together with their suppliers to create the designs for each component part of the product. The need to share these design models from concept to manufacture on a day to day basis has created a demanding load on the ability of hardware and software to satisfy that need.

Whereas data exchange used to mean the communication of single files representing each part – typically IGES or VDA format files on a half inch tape – it means the sending of a single massive file or a large set of interrelated component and assembly files on a daily basis using the World Wide Web.

With the single file transport of yesteryear it is important to ensure the correct identification of the file, the format of the data, the format of the tape and so on. Data exchange control sheets had to be filled out carefully to make sure the right file go to the right person in a timely manner and that the recipient knew what to do with it. No doubt, many data exchange specialists can remember receiving a tape in the post with no paperwork and no label and not knowing what to do with it!

Nowadays, it is even more important to ensure that the massive amounts of data transferred are identified correctly and that the exchange process is managed properly. STEP – more formally ISO 10303 – helps to ensure that process. STEP is more than just an improved IGES – much, much more. Communication of STEP data allows the metadata associated with a design model to accompany the data in a controlled way. In fact, in many cases nowadays the metadata is exchanged independently of the geometrical models enabling up to date PDM information to be available amongst the partner companies involved in a project as the product is developed and maintained. Even this capability is just a small part of what STEP offers – for information about STEP see the Canadian STEP Centre's STEP Web site: http://strategis.ic.gc.ca/STEPguide.

PDES Inc. is an international industry/ government consortium and has as its principle objective the requirement to accelerate the development and implementation of STEP. The wide range of PDES Inc. member companies includes industrial giants (and competitors) such as Boeing and Airbus, US Government organisations such as NIST and NASA and small software developers such as Theorem Solutions (UK), EPM (Norway) and LKSoft (Germany). See the PDES Inc. Web site: http://pdesinc.aticorp.org for more information.

One of the ways in which the PDES Inc. objective is pursued is the use of pilot projects amongst the members. In the early 1990s the AeroSTEP pilot demonstrated how STEP AP203 (Configuration Controlled 3D Designs of Mechanical Parts and Assemblies) could be used to support the digital mock-up of the Boeing 777 aircraft, sharing data between Boeing and their engine suppliers – Pratt & Whitney, Rolls-Royce and General Electric.

Through the 1990s the use of STEP has widened and experience of what can be done and what needs to be done has grown. One of the current PDES Inc. pilot projects is also based on the sharing of data between an airframe company and an engine supplier, but intends to extend and improve the STEP-based techniques available. The Aerospace Engine Alliance (AEA) pilot project is aimed at improving the efficiency and control of exchanged geometrical data and of extending the sharing of the metadata to include a link of the PDM systems at each end of the exchange pipeline.

One of the key “lessons learned” – which emerged soon after the start of the pilot – was the necessity of being adaptable. An early report displayed the legend “It's a changing world we're living in”. Bill Marler of Pratt & Whitney, who is the pilot leader, was constantly faced with the need to redirect the work of the team to meet the challenge of this changing world. During the course of the pilot one of the main companies – Airbus – has begun a transition from the use of CADDS and EPD Connect as their design and design data management systems to CATIA V5 and Windchill. As the project moves towards the final furlong Pratt & Whitney are involved in an implementation of IMAN which will also link into the pilot activities. The exchange process has also evolved to meet the business requirements of the principal partners.

PDES Inc. pilots have to include some novel use of STEP in a business process. The desire is to move the technology forward and so a project which merely repeated the demonstration of STEP usage between the new partners would not be acceptable to the PDES Inc. board. Since the AeroSTEP pilot had shown how airframe and engine companies can share their data the AEA pilot had to cover new ground. The areas in which this pilot planned to move STEP technology forward can be summarised as follows.

1. 1.

   The use of “Validation Properties” to improve the verification of exchange quality.

2. 2.

   The use of external referenced files to improve the efficiency of exchange processing.

3. 3.

   The exchange of metadata between the PDM systems in parallel with the geometric data files.

The AEA pilot was initiated in 1999 with the participant companies being Airbus, Pratt & Whitney and General Electric (who together form “The Engine Alliance”), Theorem Solutions, PTC and Unigraphics Solutions (now EDSPLM).

The main deliverable of the pilot is the demonstration of a production worthy capability. The most recent stages of the pilot have reached this level and led to production usage of the techniques being developed and demonstrated within weeks of the pilot activity.

“Validation Properties” were developed by the CAX Implementors Forum as a means of verifying the exchange of solid and surface geometry. As STEP usage developed the testing for a successful exchange also progressed. The primary test for the successful exchange of a solid was that a valid solid in the target system was created. However, it was found that this status could be achieved but the geometry forming the solid might be incorrect. Key parameters for ensuring that the geometry was also correct were deemed to be the surface area of the solid, the volume of the solid and the centre of volume of the solid. Although these are not exact values which can be calculated for every solid due to the mathematical algorithms employed, testing showed that the numbers would provide a reliable test for verification of the translation of the correct geometry. They are named as “validation properties” rather than as “mass properties” since it is only the geometry under design conditions which is being checked. There is no effect from the material properties of the part being designed or the usage environment and so it was felt that the distinction should be drawn.

The AEA pilot took the usage of validation properties from the original definition. As the AEA pilot was aimed at assembly exchange, there was a need to extend the recommended practices for validation properties from their use at the single part level to enable the validation of assemblies and sub-assemblies. The result is that the additional properties validate the position of each component within the assembly. Using the practices developed within the AEA pilot it is possible to check the data at every level within the assembly so that if there is a discrepancy the specific node at which the error occurs can be identified. Although the reason for the error might take quite a while to identify and fix, the exchange process can continue by manual intervention to enable the business process to go ahead without significant delay.

This advanced capability – known as “extended validation properties” or “Val Props 2” was developed by the pilot team. This extension was implemented by PTC for their Pro Engineer STEP processor and by Theorem Solutions for two of their processors – the Unigraphics STEP processor and the CADDS5 STEP processor. The enhanced processors were delivered in 2001 allowing full validated assembly exchange between the three systems to be demonstrated.

The second area of development of the use of STEP was to use external references. AP203 allows the exchange of assemblies and this capability was used in the AeroSTEP pilot. With this method, the data for the whole assembly is collected in a single file. STEP itself has no limits and so the amount of data supported could grow and grow. Modern software also has few limits with dynamic allocation of memory being the norm and so from a programmatic point of view there is no need to define limits for the size of file which could be supported. However, this dynamic allocation relies on the availability of real or virtual memory on the hardware platform. STEP file sizes grew from a few megabytes, through files of the order of tens of megabytes to single files holding hundreds of megabytes of information. Indeed, there have been individual reports of sightings of files of over a gigabyte. Whilst software and hardware developments will support such activity the load on the hardware can frequently become a bottle neck for the business process. Another side effect was that if the processing of the individual file was aborted through program failure or hardware going down, it would be necessary to start the whole thing off again. If the problem turned out to be some data which the current program could not handle the processing would fail again leaving a partially translated assembly.

The STEP external reference mechanism allows the creation of the data in a way which avoids this large file size issue. The assembly and metadata information can be created in a single file with the geometry files being defined externally. The assembly file refers the geometry files at the appropriate point in the product structure definition. The positional information is held within the file allowing the assembly to be translated separately from the geometry files. In fact, the STEP file is not limited to only referencing STEP files since the document reference mechanism used supports PDM management of files of any sort. This allows native geometry files to be used as well as STEP files. Whilst the AEA pilot initially demonstrated the use of external references with STEP files, the business process needs of the companies involved have taken that development on to the support of native files also. In this instance, AP214 is the STEP Application Protocol which is used as the format for the assembly information. The reason for this is that AP214 is harmonised with the PDM Schema Express definitions and the corresponding recommended practices for the exchange of external references. AP203 supports a form of external reference, but it is not consistent with the preferred PDM Schema mechanisms – in fact a new edition of AP203 is being considered through the ISO ballot process to bring it in line with that preferred method.

This has been the major development of the AEA pilot.

The two engine companies have a shared library which is kept in Unigraphics native format since both members of the alliance use the same design system. Responsibilities for exchange with the airframe company are shared. One company is responsible for receiving data from the airframe company and the other is responsible when data have to be sent out.

The engine data to be sent to Airbus is sent by Engine Alliance East – Engine Company two. They have the assembly and geometric data in UG prt files. In house digital mock-up tools are used to identify and collect the parts that need to be exchanged.

For the later stages of the pilot – transitioning into the emerging production capability as required by Airbus, the need is for the exchange files to consist of a STEP control file containing the product structure, assembly positional information and external references to native CATIA V5 geometry files.

Going from the engine company, the data begins in the form of a unigraphics assembly and ends in the exchange form of a STEP file referencing a collection of CATIA V5 CATPart files. The process to achieve this change has been named as AutoSTEP.

AutoSTEP consists of two stages providing a total of three forms of translation. The first takes the UG assembly and uses the Theorem UG to STEP AP214 CADVerter to create a STEP assembly file with external references to each of the UG prt files. This is one of the options of the CADVerter – the standard operation allows all the assembly files to be converted to STEP and merged into the single AP214 file. This is fine for small assemblies, but for the amount of data being transferred within this business process the files would be enormous. The STEP format for the external references points to the file and also defines the format of the file – i.e. it is a UG file. The assembly file is named as ug.stp. It is a STEP file which points to UG native geometry files.

The second stage of the process is performed by some software developed by Theorem Solutions as a part of the pilot activity of this project. A product known as EXTRESTEP is used (EXT ernal RE ference STEP processor). This allows a STEP file using the standard external reference mechanism to be processed and for the referenced files to be translated from one file format to another. For example, the files could be translated from UG files to STEP geometry files. At the same time, the assembly file data is modified to reflect this change of format of the referenced files. So, the description of the format would change from UG to STEP. The modification also provides control of the renaming of the file so that if the two file formats being used have differing naming rules, those rules can be satisfied. The modified assembly file is named as cat.stp. It is a STEP file which points to CATIA V5 native geometry files.

This second stage manages the third translation which is the translation of the geometry files from one format to another. In this usage scenario, the UG .prt files are translated to CATIA V5 CATPart files. This is effected by running the UG to CATIA V5 CADVerter for each component file in turn. As each file is run, the validation properties are checked and the report file resulting from the overall translation provides success/error information.

The resulting output is a single STEP AP214 file and a set of CATIA V5 files. These files are packed up and sent to Airbus using FTP.

Pratt & Whitney has developed a second, similar process known as AlterSTEP. This is used as a back-up procedure for AutoSTEP. If there are any problems with the usage of the output from AutoSTEP at the Airbus site, the alternative form of data can be sent which might work where the first form does not. This second process has other benefits. It will work with other partners who are not CATIA V5 users. It also provides a method for collecting neutral format data for long-term data retention requirements.

In the early days of the pilot, the usage scenario was planned as being one of “send everything, every time”. In order to ensure that the digital mock ups at each end of the pipeline were kept in step, the safe approach seemed to be to keep repeating the process of sending all the data from one site to the other. Obviously, this is not a very efficient method of operation and would tend to slow the process down. During the pilot it was found that a more efficient approach was available and has proved to be reliable enough for the business requirements. It has been labelled “the poor man's net change”.

In the initial exchange process for an assembly or for a selected sub-assembly, the whole set of files is translated as part of this process and the data can be used at the Airframe Manufacturer end for design or digital mock-up purposes.

Subsequently, there may be changes to individual component parts of the assembly. In this case, it is possible to send only a part of the whole assembly design to the other system. The ExtreSTEP processor can be run with an option which requests that only those files with a change date after a specified date should be translated. In this case, all of the referenced files are checked and only the modified files are translated. However, all the external references are modified as if they had changed. Another option can be used which requests the processor to skip the translation of the geometry files altogether. In this case also the external reference data is modified as if the referenced files were to be transferred to the different naming format and with a different file format descriptor, but the third translation step – the UG to CATIA V5 CADverter translation is not processed. For this situation it is then up to the exchange controllers to invoke the CADverter independently and send the files across separately. This process which has been given the acronym INCH – IN cremental exCHange.

This is the process as it is operating at the moment. The next stage of the pilot is to move onto the third area of technology advance – the linking of the metadata from the PDM systems. Since the initiation of the pilot Airbus has begun to move to Windchill for their Product Data Management. Pratt & Whitney is undergoing an implementation of IMAN – known as Team Centre engineering. The use of these PDM systems and the exchange of data between them is a new area for the companies involved. At this point, the pilot is still at the investigation stage as to what will be possible and how this will be achieved.

Although this PDES Inc. pilot is far from over – and the odds on it becoming the longest running pilot ever are shortening – it has already achieved significant benefits. The “extended validation properties” recommended practice has been defined, implemented and demonstrated to be successful. The method of using external references to break up the otherwise massive single files has been demonstrated as a successful and beneficial way of exchanging assemblies. At the same time, new methods for enabling an efficient business process have been developed as a part of the project. The ExtreSTEP processor combines a number of tasks to remove what would otherwise be an onerous manual process. The AutoSTEP, AlterSTEP and INCH methods developed within Pratt & Whitney have also provided recognised benefits to support the Airbus – Engine Alliance business process.

The proof of the pudding is in the eating – and the pilot techniques described have already been transitioned into production use with gigabytes of data exchanged already. With over 2,000 parts to be shared between the airframe and engine companies for this DMU process the methods developed in this pilot will prove to be a major benefit.

This paper contains significant contributions from Bill Marler of Pratt & Whitney and Ernie Mintel of CSC (working at P&W).

Details available from: Theorem Solutions. Tel: 44 (0)1543 444455; Fax: 44 (0)1543 444454; E-mail: john@theorem.co.uk

Tony RangerTechnical DirectorTheorem Solutions