The Engine Development Department of Skoda Auto was the winner of the 2003 PTC Award in Automotive for design of its Petrol Engine 1.2 HTP.

Skoda Auto, Mlada Boleslav, Czech Republic has been producing motor vehicles since 1899. After becoming one of the brands of the Volkswagen Group in 1991, the company began a period of transformation into a dynamic and prosperous firm with its own production program. Skoda Auto currently produces three model series of personal automobiles—Superb, Octavia and Fabia—that are now sold in 78 countries.

In 1998, Skoda Auto was charged with developing a wholly new group engine, the petrol 3-cylinder 1.2L 40kW. The objective was to develop an engine (for use in Skoda, VW and Seat vehicles) with better fuel consumption, longer service life, high torque at low engine speed, greater reliability, and capable of meeting the strict emission limits, among other requirements. This engine’s cylinder dimensions are a continuation of the EA111 VW engine group series, but is otherwise entirely new.

Skoda Auto developed the engine with two valves per cylinder and VW designed a modified version with four valves per cylinder (1,2L 47kW). The result is a new concept engine that was launched into series production in 2002.

Production in Pro/ENGINEER

The new engine was the first that Skoda Auto produced completely in CAD, from the first component to the last screw. The CAD model of the engine was created in Pro/ENGINEER® with the support of other CAx systems (calculations, simulations, collisions, kinematical and dynamic analyses, rapid prototyping, etc).

The large volume of CAD data for the project—generated by both Skoda Auto as well as its suppliers and partner design firms—made secure transfer and storage of information an immediate priority. For this reason, the company created a new job for a data manager (administrator of project data), and implemented a simple directory structure with appropriate access rights for users. (This mode of storage was chosen because development of systems administration for Pro/ENGINEER data was unclear at the time.) The data manager was responsible for securing the bi-directional exchange of data and for quality control and storage of data in Skoda Auto’s central archive system.

During the course of the project, it became clear that controlling data quality was a major challenge. For example, it often happened that models could be modified only with difficulty and some could not be regenerated. Conversion of the Pro/ENGINEER data to other formats was uncertain. Even among the models that were “successfully” converted, many needed corrections. In addition, poor data quality also made creation of DMU models for collision analysis difficult. All of these problems interrupt the process chain, causing delays and adding to costs. It was thus essential to find ways to eliminate problems due mainly to poor-quality CAD data.

Defining CAD Data Quality

Regardless of their size or reputation, many companies do not fully recognize what data quality means—even though it is now one of our major criteria for assigning jobs. For example, one of the most difficult (and widespread) attitudes to change is that if a 3D model is successfully displayed on the monitor, everything is in order.

A		B
Which model is right? A is the correct one, but how do we recognize it?

According to Skoda Auto’s standards, quality CAD data must:

1. Fully represent the required features of the product. This includes shape, appearance, functionality, producibility, and technological aspects, among others.

2. Meet the requirements for organizational quality. This refers to the company’s standards for creating data, including

• Starting models
• Sorting and naming of elements in the model tree
• Reference element type and method
• Using skeleton model techniques
• Creating drawings and its essentials
• Identification parameters

and many other methodical principles.

3. Meet the requirements for mathematical quality. This concerns the correctness of the mathematical description of the model (norm VDA 4955), including:

• Small elements
• Curvature and distance
• Tangential link of curves and surfaces
• Undulation of surfaces
• Tendency of curves
• Intersecting elements
• Curve polynom level
• Identical elements

among others.

It is important to note that CAD data directly or indirectly influence more than 50% of the departments at Skoda Auto. And as the following diagram shows, suppliers are also a very important part of the process chain. For this reason, it is critical to establish the requirements for data quality not only inside the firm, but also in the partner firms.

Improving Data Quality

It was not possible to complete the engine design without a comprehensive strategy. We therefore had to define the activities and processes that directly cause problems and propose a method for their solution. The following points proved to be of key importance:

• Where possible, eliminate all errors in the models that cause problems later on
• Explain the reasons, possible problems, and benefits of all available resources.
• Do not be persuaded by arguments like “it did not matter up to now” (although it is important to listen to the opinions and suggestions of users)
• Configure Pro/ENGINEER the same within the group and at the suppliers
• Use set procedures and techniques thoroughly
• Simplify operations with special applications and functions
• Use control tools continuously from the start of model development
• Train users continuously
• Store data conditionally in the PDM/PLM systems
• Require contractual commitment of suppliers.

The process of improving quality is clearly a long-term effort, requiring systematic and ongoing pressure on the concerned firms and people. But it is also necessary, right at the first definition of the shape of the part (before start of work in the CAD system) to define the method and philosophy for data creation, data structure, standards and conditions to adhere to and check continuously. Remedying quality only after the data are created does not lead to the correct result and comes at a huge cost in terms of both time and money.

At first, we only checked data quality using the standard Pro/ENGINEER tool. This was not only time-consuming, but it also didn’t allow us to systematically check all CAD data. In addition, the individuals who generated the data (including our own design engineers as well external firms) were very resistant to conducting checks at all. This made it clear that we lacked a simple, effective control tool.

Using ModelCHECK

A fundamental turning point in the project was the addition of ModelCHECK to the Pro/ENGINEER portfolio. From that moment, we had a quick, easy-to-use tool for controlling data quality that guides the designer through the solution of problems and generates a report of the control process. The preparation and testing of a configuration that would meet international (as well as our own internal) standards started immediately.

However, we were still not completely satisfied. ModelCHECK can check only the so-called organizational and, to a limited extent, the mathematical quality of the data. Even in the actual program, several areas could be improved.

In the beginning, only the engine development data manager used this tool. He was also the person that spread know-how in the area of Pro/ENGINEER data quality and put systematic, direct and ongoing pressure to improve data quality. The data manager saved nearly all CAD data in the engine development department to the central administration system and conducted its systematic check.

It was necessary to teach the individual designers how to use ModelCHECK. A big benefit is that the data manager works directly at the designers’ workplace and is in everyday contact with them. The designers have thus learned how to work with ModelCHECK and already use it regularly on their own. This helped to break down the general resistance and distrust of using the tool and performing the checking process.

Data provided by partner firms were analyzed regularly. Unsuitable data were returned for correction, accompanied by ModelCHECK error reports. In some cases, the analysis was made in the presence of the partner firm’s representative. Discussions have been held with some firms about the data quality problem. The engine development department put pressure on its partners to start using. ModelCHECK. It also helps that the tool has become part of Pro/ENGINEER, which eliminates the need to purchase additional licenses.

Additional Tools

Documentation. Beginning in early 2001, Skoda Auto has gradually transferred all important base data, instructions and standards for data exchange and quality, and files for configuration of the Pro/ENGINEER environment to all of its partner firms. The base data are usually delivered on CD to representatives of the firms. Their signature on protocol of hand-over guarantees the application of our standards to their work. Suppliers can also retrieve all the Pro/ENGINEER and ModelCHECK configurations and related documents on our supplier portal (new at www.vwgroupsupply.com).

Unified installation. The so-called GRI (Group Reference Installation) was implemented in the spring of 2001. Apart from the common and inviolable configuration of the Pro/ENGINEER parameters, it offers:

• a possibility to configure the system according to the custom of the individual brands and localities
• special Pro/TOOLKIT applications
• a possibility to integrate additional applications specific to the brand or locality
• co-operation and possibility to distribute tasks to the individual brands for preparation of new GRI versions.
• common release management.
• free configuration package and selected Pro/TOOLKIT applications for partners.

GRI has greatly simplified the work of the system administrators, but mainly of the users. This is especially appreciated by suppliers that earlier had to apply various configurations despite the fact that they in principle worked for the same company. Implementation of GRI has eliminated the problem of incompatible data that was mainly due to varying system configurations.

Simplified operation. The language barrier that always exists to a certain extent in international companies and the complicated work with the model parameters required the creation of the Pro/TOOLKIT application, Modpar (MODify PARameters). This has made the input of parameter variables that fill the drawing stamp and change table efficient and transparent. The online application interfaces with the central database of part numbers, eliminating the possible allocation of a nonexistent number. The part name is automatically assigned and linked with the part number. The application is at the same time linked with the materials library. Dislike for entering essential data has disappeared since the implementation of the application because the designer practically fills the drawing seal field directly instead of the often-meaningless names of the foreign language parameters.

Conditional storage of data in the PDM/PLM systems. Despite the existence of many directives, manuals, recommendations and standards, it is still necessary to persuade designers and partners to comply with them. From our previous experience with controlling data quality in CATIA, conditional saving of data to the central archive system is an effective tool. In practice, this means that saving data to the central archive system automatically initiates a ModelCHECK. The system evaluates the model and the data are accepted or rejected depending on the result.

This change cannot, however, be implemented all at once. Since mid-February 2004, Pro/ENGINEER data are checked in the central archive system and for the present is accepted regardless of the result. But each model is marked with an icon indicating whether it met the requirements of the check or not. Anybody thus sees how any designer or partner works. Rejection of data in case of a negative check result is planned for implementation during the course of next year.

Contractual commitment of suppliers. Skoda Auto currently includes the following text in its new so-called “Component Performance Specifications.”

Data communications for all design data are to be conducted in conformity with the purchaser’s CAD system guidelines. The relevant CAD libraries must be maintained by the contractor.

The contractor must take into consideration those sections of the in-house standard which refer to the performance specifications when developing vehicle part design with CAD systems and he must secure the fulfilment of the requirements.

In particular, the contractor shall test the data packages/design data to be delivered (called "data" in the following) with the Group-wide recommended test programs (ENDCHECK and VALIDAT for CATIA-models and ModelCHECK for Pro/E-models) in the course of the development process and submit the test report on delivery – preferably in the CAD-model. The contractor shall submit the data within a reasonable period of time before the deadline for delivery specified in the project, in order to allow the purchaser to conduct quality checks and the contractor to correct mistakes as necessary within the time schedule previously agreed on.

In addition to product liability in procurement conditions for material, the contractor is obligated to bear the costs arising from delivered data which do not comply with the requirements stated in the standard and incorporated in the contract. This applies only in case the contractor is unable to correct the mistakes in a reasonable way not compromising the purchaser. Especially not complying with development milestones or delivering the required data on the closing date will cause such an unreasonable and compromising situation. The costs will meet the extra expenditure caused by the required corrections. A lump sum based on an hourly rate of € 113 and dependent on the number and gravity of the mistakes will be charged. In case the contractor or the purchaser can prove that the actual extra expenditures are higher or lower than this lump sum, the actual expenditures are to be refunded.

The purchaser may claim the correction of mistakes instead of financial compensation.

Additional control tools. Over the course of the project, it became evident that the formal and mathematical quality of the model is not the only determinant of data applicability. Also important is the producibility of the actual part, which in the case of an engine involves a number of complicated castings. Until recently, the check of these parts was very complicated, time-consuming, and not 100% reliable. Everything depended on whether the user overlooked some critical point or made a section in the wrong direction.

For this reason, we decided to use 3DCaliper, a product that solves the problem of checking wall thickness without laying down special requirements for the operators. Unlike Pro/ENGINEER, the check covers the whole model, is very quick, and the processed results are easy to survey. This has successfully eliminated such problems as thin walls being machined through during the prototyping process.

Benefits of Data Quality Control

During the course of the project, it is normal that the designed part undergoes many changes. In the end, two suppliers may sometimes get the same job and work on it independently. This is the case with the oil pump housing. The first model was created more than three years ago according to the system available at the time (i.e., without any quality requirements). The main criterion for approval was successful display on a computer monitor and creation of a drawing.

The job was later assigned to a second supplier after the quality requirements were in place. A year ago, a wholly new model was supplied that meets all the requirements. Compare the results of the check of both models in the table below.

Generally the benefits of controlling data quality may be summarized as follows:

• Higher declarative capacity of the models
• Substantial increase in successful transfers to other systems and formats
• Reduced data volume, allowing faster download of models and lower disk space requirements
• Fewer iterations to attain a suitable model
• Easier and faster handling of data and its modification, requiring less communication
• Time and financial savings in all parts of the process
• Reduction of user frustration

Next Steps

The top priority is now to implement the complete CAD data quality solution in the rest of the departments that create or modify models in Pro/ENGINEER. It will be very important to get these users to adopt this goal as their own and not take it to be only one of many instructions. Parallel to this, the number of partner firms will increase. From the outset, it will be essential to continuously justify and explain our requirements to them and teach them everyday work with the tools so that they understand their tangible benefits.

No less important tasks are to:

• Implement automatic checks when saving data to the central archive system, including rejection non-conforming models.
• Add the check of mathematical data quality according to VDA 4955–configuration of the GeomIntegrityCHECK tools.
• Consistently impose contractual fines for partners that supply poor quality data.

Conclusion

It is necessary to emphasize that data quality cannot be changed in a leap. This is a long-term process of gradual improvement that more often than not will take several years. It is not possible to demand the elimination of all errors at once. This would raise huge time and financial costs, which in principle would paralyze the project.

Nevertheless, through systematic, ongoing and strong pressure for data quality, its running check, the engine development division at Skoda Auto has improved its typical ModelCHECK results to: ERROR=0 and WARNING=minimized, usually up to 5. Engine development was ready on time for general implementation of automatic quality checks when saving Pro/ENGINEER data to the central archive system.

From our partners that also cooperate with other companies in the world, we know that our data quality demands are very high. At the same time, though, we can confirm from our own experience that these are achievable and meaningful requirements.

Jan Dvorak, data manager in the Engine Development Division of Skoda Auto, can be reached at jan.dvorak@skoda-auto.cz. Jan Vesecky, manager of Skoda’s Pro/ENGINEER central administration, can be reached at jan.vesecky@skoda-auto.cz.