Virtual Car Process

Abstract

The Virtual Car Process comprises all activities required to structure, build and test computer-internal representations of motorized vehicles – so-called virtual cars. Containing both geometric and functional data, virtual cars are not only the basis to facilitate decentralized design in context but are also the most important lever to increase efficiency in vehicle development.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

4.1 Building Virtual Cars

4.1.1 Purpose and Benefits

Virtualization of products and processes is one of the areas in which automotive development has seen the most dramatic improvements over the last two decades. First 3D modelers helped designers to generate parts geometries – which then usually were converted back to 2D drawings. Over time, by attaching further geometric information (such as a part’s position in a common work space, surface properties etc.), administrative data (such as part numbers, bill of materials (BOM) structures, versions, variants and options etc.) and especially functional properties (such as material information, strength, color etc.), 3D parts became virtual cars which became the central communication platform for the co-operative vehicle development process.

A virtual car is the representation of all of a specified vehicle’s parts in a shared workspace that allows the simultaneous and coordinated development of the complete vehicle. In addition to being a platform for design-in-context , virtual cars represent the basis for simulation and evaluation of vehicle properties, functions, costs and weight. Usage of virtual cars enables fast prototype build and fast ramp-up by increased geometric consistency of parts and pre-checked assembly processes. Costly changes of hardware parts and manufacturing equipment can be dramatically reduced. Virtual cars substitute for hardware prototypes to an ever growing extent. In passive safety e.g., real crash tests – while still necessary – are expected to 100% confirm the findings from simulation (see Section 7.7.3).

The usage of virtual cars does not make personal communication unnecessary; rather it intensifies the need for it. The chassis designer who has worked several weeks to optimize his rear axle carrier and now wants to update it in the common workspace might realize that the body panel he used to take as a reference has just been changed and now makes his own design unusable. Neighbors within virtual cars must continuously communicate to realize the full potential of cooperative design.

4.1.2 Required IT System Environment

Collaborative creation and analysis of virtual cars requires a compatible and at least partly standardized IT system environment (see Fig. 4.1):

• 3D CAD modelerssuch asCATIA, Pro/ENGINEER, NX or Solid Works are used to create the 3D models of vehicle parts. As almost all visible surfaces of a vehicle must meet very high aesthetic requirements and might initially have been modeled in clay (see Section 7.3.1.4), freeform surface modeling is among the most important capabilities of CAD systems in automotive design. Because of its strength in this domain, CATIA has become a quasi-standard in the automotive industry. Pro/ENGINEER is used especially in engine design, where the main surfaces are analytical rather than freeform, and the advantages of parametric design can be fully exploited (e.g. when designing a four-cylinder-inline and a six-cylinder inline engine as one family). Relevant capabilities of automotive 3D CAD systems include advanced surfacing, advanced solid modeling, the ability to handle large assemblies [1]. While with first generation 3D CAD systems designers had to select and adapt elementary geometries or surfaces to create part geometries, they today can use feature oriented modelers that apply their design intent (such as a bore hole pattern or a groove for a sealing ring) to the part. In the same way, current 3D CAD systems offer specialized tools to generate models of e.g. harnesses, tubes or pipes.

• Product data management (PDM) systems manage and track creation and change of all geometric and non-geometric product information such as part numbers, description, cost, material, technical drawings etc. and link it to the respective 3D models. To store and retrieve this data, PDM systems operate a product database. PDM systems manage different configurations, versions and variants of the product. Thus, PDM systems are the tools to manage building and maintenance of virtual cars, e.g. by creation of a virtual BOM, the hierarchical structure of the virtual vehicle. To visualize the product structure and facilitate selection of parts needed for specific investigations (e.g. visualization of all parts inside or partially inside a defined box), a structure navigator is used as a user interface for the PDM system (see Fig. 4.1).

• While CAD systems focus on the detailed creation and change of single parts, 3D visualizers allow the user to envision bigger sub-assemblies or even a whole vehicle. As typical operations are moving, rotating and zooming in the product in question, visualizers need simplified models of the distinct parts to reduce the required computational effort. For this purpose, an envelope model is tessellated for each part and linked to it by the PDM system. With a state-of-the-art visualizer, a complete virtual car can be visualized and moved in real time - depending of-course on the performance of the graphics computer used. Visualizers offer additional functionalities such as fly-through with or without section pane, kinematics simulation or distance checking (see Section 4.2.2).

Fig. 4.1

IT environment for virtual car build

For further functional evaluation (such as crash behavior or cabin temperature), specific simulation tools are used to analyze the geometric and non-geometric data contained in the virtual cars. Simulation of complete vehicle characteristics is discussed in detail in Chaps. 7 and 8.

4.1.3 Specification

Starting with the concept phase, virtual vehicles are the shared workspace for cooperative complete vehicle design. Together with the integration processes, the virtual car team specifies the virtual vehicles regarding body type, country version, engine, gearbox and options. As provision and maintenance of virtual vehicles requires some effort, the key to virtual car specification is to find the least amount of vehicle configurations with which the required information can be obtained (compare Sect. 3.3.3). Figure 4.2 shows the structure tree for a set of specified virtual cars.

Fig. 4.2

Structure tree representing specified virtual cars (Source: BMW)

4.1.4 CA Data Provision

As a starting point for virtual cars, the virtual car team provides the structural environment and the shared workspace for each virtual car. Then, step by step the geometry data is added and positioned by the design CoCs . At the beginning of the concept phase, when the conceptual package of the new vehicle is created, components may be represented by simple geometric primitives (boxes, prisms etc.). The virtual car then becomes the basis for analytical design [2].

During the series development phase, every single part is separately modeled according to its geometric and functional needs. Over the PEP, the virtual cars grow and become more and more mature until their parts have a status that is ready for series production release [3]. Figure 4.3 depicts a detailed virtual car as it is used for series development.

Fig. 4.3

Detailedvirtual car (Source: BMW)

4.2 Geometric Integration

The term geometric integrationdenotes all activities that ensure geometric coherence of the virtual vehicle throughout the PEP to prevent interferences and ensure provision of functional clearance.

4.2.1 Collision Detection

If two designers should both independently check their part changes in context before publishing it in a virtual car – and then the two changed parts interfere, or a designer does not check the complete environment of his part before publishing his new version; in concurrent engineering of virtual cars with its highly simultaneous data provision, clashes and interferences among virtual parts do occur and hence must be eliminated by geometric integration to ensure realizability of the vehicle.

Before geometric analysis can start, the quality and availability of CAD-models need to be verified: Are the models complete? Are the models positioned correctly? Are the models up-to-date? Figure 4.4 shows a virtual belt drive in two geometrically inconsistent scenes: One with the generator missing and one with a redundant obsolete belt.

Fig. 4.4

Redundant obsolete part (left) and missing part (right) (Source: BMW)

When the virtual car in question is complete and up-to-date, it is then automatically checked for collisions by tools that are part of the 3D visualizer. The identified collisions are communicated back to the designers responsible for the colliding parts so that they can evaluate the criticality of the collision [4]. Figure 4.5 shows such an automatically generated collision list with manually added criticality remarks. The colliding parts are specified in the two left columns, criticality is indicated by red or green color in the right column.

Fig. 4.5

Results from an automated collision check (Source: BMW)

As Fig. 4.6 illustrates, the criticality of the detected collisions among virtual parts can vary significantly:

• The collision in the left picture is uncritical. The detected interference between a rubber hose and a bracket is settled in reality by the elastic material properties of the hose. Another typical example for uncritical collisions is interferences between door seals and the body side frame. The seals are usually modeled in their un-deformed shape and positioned in relation to the door. When loaded into the complete vehicle representation, the seals naturally collide with the body frame model, because the virtual sealing does not deform as the real ones would do.

• The center picture of Fig. 4.6 shows a collision stemming from the misalignment between the bolts of a rear light assembly and the respective body holes. While the collision definitely has to be changed before the parts are released, change requires a rather minor effort: The holes can easily be shifted in the 3D CAD model. During the series production phase, this kind of collision happens frequently when one part’s geometry is changed and the neighboring parts have not yet been updated accordingly.

• The collision shown in the right picture of Fig. 4.6 however is highly critical, an interference of rigid components. Concept-critical collisions like this require major design rework. During series development, this kind of full interference usually stems from wrong positioning of a part in the complete vehicle work space.

Fig. 4.6

Collisions: uncritical (left), minor (center) and critical (right) (Source: BMW)

Many designers feel that automated collision checks are a means to detect and publish design glitches and even feel provoked by the regular collision reports. They see collisions as normal, intermediate states during the product design process. “Wait for my next part version” is hence the typical measure that is proposed to solve their collisions. But as every designer can update his or her part at any time, it is very likely that the new version indeed removes the listed collision but at the same time creates another collision somewhere else in the virtual car. Automated collision checking is fundamental to design-in-context, which is the indispensable basis for simultaneous development of the complete vehicle.

4.2.2 EnsuringFunctional Clearance

The term functional clearance denotes the minimum clearance between two parts that is required to ensure proper functionality. A minimum clearance can be required to avoid heat transfer (e.g. between an exhaust pipe and a thermal shield), to allow collision-free movement of moving parts in all degrees of freedom (e.g. movement of the front wheels in their wheel housings) or to give enough space for oscillatory movements (e.g. small rotations of the engine as it reacts to the driving torque). While interferences among virtual parts can easily be detected by means of collision checking tools, ensuring functional clearance is approached manually. 3D visualizers usually offer tools to measure the minimum distance between two parts. In the example in Fig. 4.7, the minimum distance between an engine bracket and a coolant hose routed below it is measured as 7.5 mm.

Fig. 4.7

Analysis of parts’ clearance (Source: BMW)

The question of how much clearance is necessary can only be answered by the responding experts. Clearance libraries can provide initial recommended values. But as many parameters can influence the required distance, dependable values must be calculated or estimated by experts – e.g. the critical distance between a heater hose and the engine with regards to relative movement of the end fixed to the engine and the end fixed to the body, the elasticity of the hose which depends on the temperature and flow rate of the water, oscillations of the hose during operation of the vehicle etc.

4.3 Further Functional Geometry Evaluation

4.3.1 Storage of Personal Items

To ensure optimum practicality in terms of storing personal items in the cabin and the baggage compartment, these items are represented as 3D models and added to the virtual cars. Including this virtual load in the geometric integration processes, allows the size and accessibility of trays, pockets and the baggage compartment as a whole to be verified at an early stage of the PEP (compare Sect. ).

4.3.2 Evaluation of VehicleKinematics

Another advanced application of geometric integration processes is the validation of vehicle kinematics. This includes:

• Operational movements such as shifting the gearshift lever in every position (with different kinds of bottles in the cup holder and the ashtray lid open or closed) or simply the movements of the doors, hood and trunk lid.

• Functional movements such as jouncing and rebounding of chassis and suspension parts and tires, turning-in of steering parts and front wheels or lowering and lifting the side windows.

An effective approach to check clearance for these movements is to create an envelope model for the moving part by sweeping the part’s geometry along the trajectory of the movement and checking this envelope against the vehicle geometry (see [3]). An important application of this approach is the creation of the wheel envelope (see Fig. 4.8) which represents the maximum geometric expansion of all wheels and tires that should be used with the vehicle in question. Calculation of wheel envelopes must take into account the following parameters:

• Maximum jounce and rebound allowed by the suspension kinematics

• Maximum turn and tilt allowed by the steering kinematics

• Maximum elastic deformation of the tire according to longitudinal, vertical and lateral forces

• Maximum elevation of snow-chains (if applicable)

• Maximum and minimum tire pressure

• Wear conditions of the tire

Fig. 4.8

Wheel envelope as used for concept evaluation (Source: BMW)

This envelope is then checked for clearance against the wheel housing and components such as brake hoses, ABS sensor cables, or handbrake bowden cables. But the particular relevance of the front wheel envelope stems from its role in determining the geometry of the concept vehicle: During the concept phase, the front wheel envelope determines the maximum outer limits of the engine cradle and thus – with the width of the engine and the engine cradle beams given – the total width of the vehicle (compare Sect. 3.1.1).

Geometric evaluation of complex kinematics such as that of a retractable hard top is not possible with this quasi-dynamic envelope approach. It requires advanced multi-body simulation systems, that analyze the kinematics of parts linked together by joint-functions that constrain their relative movements [5].

4.4 Virtual Build Groups

Parallel to the “regular” continuous vehicle development, certain project milestones require the validation of the status of the complete vehicle at a specific point in time. While this was formerly done by means of hardware prototype build groups, today virtual build groups are carried through to create a comprehensive picture of a vehicle’s maturity. Virtual build groups can be structured in three main phases:

• During the planning phase, the vehicle properties which must be validated are agreed. According to these expected results, the required virtual cars are then specified by a build group specification. Usually, the virtual cars of a build group are copies of the existing virtual cars.

• In the design phase, supporting this design-in-context, the virtual car team iteratively checks geometric compliance of the virtual cars (geometric integration). Geometric problems are evaluated and fed into a problem management process (see Section 6.2) to monitor their solution. At the end of design phase, CAD and CAE data are 100% consistent: Complete, correct, clash-free. The virtual car is geometrically released and ready to be tested.

• During the evaluation phase, functional integration and production integration test functions and buildability of the virtual vehicles using the appropriate simulation tools and methods. Eventually, the findings of the virtual build group are reported to management to formally verify the project status.

The first two phases of a virtual build group are also carried through to ensure CAD data maturity for hardware prototypes before ordering prototype tooling and parts.