Racing car design using Knowledge Aided Engineering - CiteSeerX

Racing car design using Knowledge Aided Engineering Lorenzo Susca1, Ferruccio Mandorli2, Caterina Rizzi1, and Umberto Cugini1

1 Dipartimento di Ingegneria Industriale, Università di Parma 2 Dipartimento di Meccanica, Università di Ancona

Corresponding author: Lorenzo Susca Mailing Address: Dipartimento di Ingegneria Industriale, Università di Parma, Parco Area delle Scienze, 181/A, I43100 Parma, Italy Tel. +39 0521 905892, Fax +39 0521 905705, Email: [susca, rizzi, cugini]@ied.unipr.ir

N. pages: 24 (including this one) N. Tables: 5 N. Figures: 14

Racing car design using Knowledge Aided Engineering Abstract CAD systems and related technologies evolution has improved the development of software for automatic configuration of mechanical systems. This happened with the introduction of KAE systems that enable computer to support the designer during the decision making process. This paper presents a knowledge-based application that allows the designer to automatically compute and evaluate mass properties of racing cars (IRL Dallara). The system is made by two main components: the computing core, which determines the car model, and the graphic user interface, which makes the system usable also by non-programmers. The computing core creates the model of the car based on a tree structure, which contains all car subsystems (e.g., suspension and chassis). Different part-subpart relationships define tree model and link an object (e.g., suspension) to its components (e.g., wishbones and wheel). Independent parameters (including design variables) and relationships definition allows the model to configure itself evaluating all properties (dimensional, positional, mass, etc.). The graphic user interface allows the end user to interact with the car model editing independent design parameters. It visualises principal outputs of the model, which consist of numeric data (mass, centre of mass of the car and of its subsystems) and graphic elements (car and subsystems 3D representation).

Keywords: Knowledge Based Systems, Design process, and Racing cars.

1 Introduction Concurrent Engineering methodology and process analysis and modelling showed the importance of tools that allow designers evaluating, from the beginning, different aspects involved with the

product definition (Vernadat, 1996). Problems due to manufacturing, assembling, time and costs, and aesthetic aspects, become often evident too late, when the costs of design correction and change are high. 3D-CAD systems, simulation tools and virtual prototyping technologies allow foreseeing these kinds of considerations during the design stage. During last ten years, these software tools have been widely studied and a large number of new systems are nowadays available on the market. Different technologies can be used to support the different stages of the production process: CAD for design, CAM for manufacturing, CAPP for process planning, etc. (someone refers to the set of these technologies as CAx: Computer Aided for x). This premise can give the impression that, thanks to CAx, the production process can be fully supported and controlled following the Concurrent Engineering paradigm. Unfortunately, in many cases this assumption is not completely true. This is due to the fact that CAx system are general purpose systems, i.e. they are not tailored to support the production process of a specific product or component (think, as an example, to the different problems related to the design and manufacturing of a gear pump, and an hydraulic cylinder). Only during the last few years, thanks to the ever increasing competition in the field of software tools development for engineering applications, CAx vendors seems to take in more consideration aspects related to system customisation and new tools, that allow the user to realise its own productdependent application, are now appearing on the market. We have focused our interest on the class of software tools named KAE developing shells. An application developed by using a KAE shell can be placed, within the design process, before traditional CAD systems. In particular, vertical applications realised using these tools can support experts during the decision making process when evaluating alternative solutions, can provide a kernel for the integration of different technologies, and then they represents a basic step for the succeeding development of the product design (Cugini & Colombo, 1992)

Knowledge based design process means in this way acquisition and re-organization of information and rules that are part of the experts' personal skill and that let them analyze and solve problems. This information is determinant both for a correct preliminary design and for the generation of robust foundation and common reference to specific design tasks. Another objective of KAE systems is the creation of a knowledge base that can be shared among various activities and univocally interpreted. Different works showed the importance of the development of ontologies that allow only intended meanings to be captured in the knowledge base (Salustri, 1998)(Guarino, 1998)(Soinien et al., 1998). Communication and knowledge sharing are becoming main evolution trends into industrial scenario where an integrated design environment is needed. In this paper we present a decision support system for IRL (Indy Racing League) cars with regard to the computation of mass properties. The system has been developed in collaboration with Dallara, an Italian company that produces cars for F1, IRL and other leagues. First part of the paper focuses on decision making process for IRL car design and the fundamental role of mass distribution with respect to car performances and components dimensioning. Second part presents the car structure analysis and the definition of the knowledge required to address the problem of mass distribution and to define a suitable car model. The model structure, where atomic components are represented by a set of significant properties, and grouped to form hierarchical sub-assemblies, will be described in details. Third part concerns practical aspects of the development of the computing core, which determines the car model, and the graphic user interface, which makes the system usable also by nonprogrammers. Some experiments and results achieved with the implemented prototype will be also described.

The last part is about the integration of the prototype with traditional software tools that allow the designer re-using knowledge to perform specific tasks, like semi-automatic generation of 3D model of car components and simulation of dynamic behavior of the car or its main sub-assemblies.

2. Decision making process for IRL car design Indy Racing League was founded on 1996 and it is held on oval circuits in US. The purpose of the league was to organize a highly spectacular championship with low costs for the teams. Therefore the number of producers has been limited to two engine producers, two tyre suppliers, and two producers for the chassis and the bodywork (Dallara and Gforce). Moreover, a detailed normative concerning car size and structure has been established (Indy, 1996). As a result, IRL car designers have to face different problems concerning the research of high ratio reliability • performance / costs within normative constraints. During the design process, car components are sized in order to optimize the weight/strength balance with respect to the overall constraints imposed by the normative. Car mass distribution is then derived from the sizing of the car sub-assemblies. However, mass distribution is a fundamental parameter to be taken in account during design because of its contribution to car performances. As a result, the decision process the designer has to put in place is as shown in Fig. 1. FIGURE 1: DECISION MAKING LOOP The designer tries to improve car performances starting from the idea of a new car configuration. In this stage the designer is guided by the perspective of achieving some particular advantages that he/she can foresee relying on personal expertise. Possible alternative solutions are evaluated in order to define the strategy of the following steps. Detailed and dept analysis of the selected solution allows the designer to evaluate his/her original idea, performing a feedback of results on hypothesis.

To perform the loop, the designer applies his/her knowledge and skill, foreseeing and verifying results are main steps of this job that affords the improving of the car. While ideas development and design conceptualization involve creativity, expertise (Cross, 1998) and ability, evaluating and verifying alternative design solutions is a traditional engineering problem that implies routine jobs and manual computation and often requires enormous waste of time. Traditional CAD systems are not useful in this phase of the work, when the design is still evolving and general perspective is needed. More appropriated tools are KAE (Knowledge Aided Engineering)

systems

(Kariko-Buhwezi

&

Cugini,

1996)(Ognjanovic,

1998)(Mandorli,

1997)(Moulilianitis, 1999) that release the designer from boring tasks performing as much as possible automatic computation and leaving him/her the possibility to improve the product. KAE systems are developing shell providing Object Oriented languages as software tool to define the knowledge base representing the product models. The language features allow encapsulating within the model different types of knowledge (technological and functional properties as well as shape aspects and dimensioning rules).

3. Knowledge base definition First step to build the car prototype is the definition of the knowledge base (design variables, material properties, dimensioning rules, component features and functionality, data) involved in computation of mass properties. Mass distribution computation of a car needs the research of parameters and relationships that determine shape, geometry and position of any part of the car. In this stage, making decisions about if and how a part is relevant is very important for the final result. Some parts of the car, because of their contribute to mass computation, have been studied in detail, while other parts, didn’t require an accurate analysis. An example of the first case is the suspension system (front or rear): if the designer modifies any suspension variable, the car set up and

performances change. An example of the second case is the engine, which is produced by a different company and, even if it’s very heavy, can be considered as a constant of the problem. A deeper analysis of the engine doesn’t improve computing of the car mass distribution. These examples show as car analysis, from mass point of view, refers to car subsystems as the engine and the suspension system. In fact, in order to reduce the general problem into different simpler ones, the car has been subdivided in main subassemblies, that can be first studied in detail and then related to each other. The result of this process is shown in figure 2 in form of a hierarchical structure that represents the car with its main subsystems. Each car subassembly has been identified in accord with the functionality it plays in the whole system. Dallara know-how on the problem and engineers experience gave a fundamental contribution to this step and allowed the definition of parameters and relationships needed to calculate mass distribution of car parts. In the following sections we report as examples two car subassemblies (chassis and suspension) which play an important role in determining car mass distribution.

FIGURE 2: CAR TREE STRUCTURE (WITH MAIN SUB-ASSEMBLIES)

3.1 Suspension System Front and rear suspension systems support the car floor at a given distance from the ground. Moreover their configuration defines wheels axis. For these reasons car mass distribution depends on suspension subsystems, both for mass value and center of mass location. For example front wheels axis displacement involves a change of front suspension structure and mass. New suspension configuration generates also redistribution of loads on front and rear wheels, with consequently change of car attitudes. Fig. 3, shows tree representation of suspension assembly with

main components, each one characterized by its function; they are: suspension arms, which link the chassis with the upright, wheels, ARB and damper system which drive wheels vertical movements.

FIGURE 3: SUSPENSION TREE REPRESENTATION Different parameters, concerning geometry, shape and material, define all components. Some parameters are independent, while other ones depend on geometry and functional constraints. For example every tubular rod, which makes up wishbones, tie rods and push rods, presents material density and cross section dimensions as independent parameters; while rod length depends on the distance between points to link. Main independent parameters of suspension assembly concern positions of wheels axis, chassis/wishbones linkages, chassis/damper and /ARB linkages, cross sections of rod elements and material density of all parts. Once these values are defined, mass and center of mass co-ordinates can be easily evaluated, as reported in equation (a) and (c). Equation (b) evaluates single part mass and depend on the real shape (and dimensions) of the component. N

Ptot = ∑ Pi , where

(a)

i =1

Ptot = total mass

Pi = Vi (ϕ i ) ⋅ d i , i-nth part mass

(b)

Vi = i-nth part volume, shape (ϕ) dependent, di = material density, N = actual number of components.

N

G tot =

∑ P ⋅G i

i =1

i

N

∑P

, where

(c)

i

i =1

G tot = suspension assembly center of mass, G i = i-nth part center of mass. 3.2 The chassis Another important component of the car is the chassis, which represents a reference for other subsystem positioning. Chassis is made by composite material, which improves lightness and stiffness of the structure. Three different layers make up composite material: internal and external skins of carbon fiber and an intermediary honeycomb structure. The thickness of three layers determines chassis mass. IRL normative gives detailed information on chassis design; it defines ranges of layer thickness and chassis main dimensions. Moreover the system has to overcome a crash test that allows evaluating chassis behavior during racing accidents; driver’s safety must be assured in every condition. Normative gives also constraints on chassis shape and dimensions with the introduction of four stiffening bulkheads that define as many chassis cross sections. The end chassis cross section is positioned at the engine interface; the engine, produced by two different companies (Nissan and Oldsmobile), defines this section profile. The definition of chassis shape and dimensions allows theoretical computing of the subsystem mass (and center of mass), as shown in equation (d):

[

]

P = ∫ (d honeycomb ⋅ s honeycomb ) + (d C1 ⋅ sC1 ) + (d C 2 ⋅ sC 2 ) + d glue ⋅ ds + Pstiffwning , S

and in equation (e):

G=

∫ [(d

honeycomb

]

⋅ s honeycomb ) + (d C1 ⋅ s C1 ) + (d C 2 ⋅ s C 2 ) + d glue ⋅ g ⋅ ds + Pstiffwning ⋅ G stiffening

S

P

,

where: P = computed chassis mass, Pstiffening = total mass of additional stiffening parts (retrieved from a data base), dhoneycomb, dC, dglue = density of the honeycomb, carbon fiber and glue, shoneycomb, sC1, sC2 = thickness of the honeycomb and internal and external carbon fiber,

ds = infinitesimal surface element, S = chassis surface, g = center of mass of infinitesimal surface element, G stiffening = center of mass of stiffening elements,

G = center of mass of the chassis. 3.3 Other subsystems Other car component analysis follows the method adopted for the chassis and the suspensions. Mass of bodywork system and wing assemblies, mainly composed in carbon fiber, depends on surface area and thickness of different skins and can be calculated as in equation (d). Some parts, as engine or gear system, come from different companies, together with known mass properties. In the end, fluid systems (oil, fuel and water) present difficulties for mass computing, because of the non-solid element presence. In particular cases (e.g., in static conditions) mass properties can be evaluated with the introduction of simplifying suppositions (e.g., considering liquids as solids for center of mass computing). In all cases, the handbook of car components is useful for a comparison between results coming from theory calculating and experience.

4. Computing core development The analysis of the car and of its main sub-system allowed the definition of knowledge base needed to calculate mass distribution of the system. The knowledge base was captured and formalized, using an appropriate software tool (Selling Point), to build a structure that makes up the Computing Core. The computing core allows the automation of calculating process and generates a model of the car (figure 4) that simulates its main mass properties. Next section introduces the tool supporting the computing core and the reasons that justify this choice. Afterwards the car prototype will be presented.

FIGURE 4: REPRESENTATION OF THE CAR PROTOTYPE (SELLING POINT ENVIRONMENT)

4.1 Selling Point: a developing shell for product configuration applications The development of car prototype requires some fundamental functionality to enable automatic configuration of the model: 1) representing complex structure as composition of simpler parts, sorted hierarchically in a tree model (as required by car study, section 3, figure 2); 2) making use of graphical parametric primitives (for car components representation) with known geometry and mass properties; 3) linking external data base (e.g.: book of car part masses); 4) generating models able to configure themselves automatically, once the tree structure and independent parameters are defined. Selling Point, of Concentra Corporation (http://www.concentra.com), satisfied these requests and allowed prototype development. The car model has been described making use of SP language

(GSL = Generative Specification Language), an object oriented language that supports the description of objects listed in a user library (Concentra, 1995). SP disposes of standard libraries (e.g.: geometric library for graphical primitives) whose items can be used by GSL programmer. All defined objects (member of user or standard libraries) can be reused to compose different assemblies; internal linkages, represented by relationships among properties of different objects (= nodes), define the resulting tree structure. For this reason, the development of the prototype begins with the definition of basic elements and ends with the description of the tree root, representing in this case the entire car model. Once the tree structure has been defined, SP generates a parametric model in a standard configuration based on given default values of independent parameters. The end user interacts with the model editing the properties of different components; the model re-computes all dependent parameters and configures itself automatically. Fig. 5 shows an example of Selling Point working environment, with the chassis property page, the parameter editing window, the car library and the car tree representation.

FIGURE 5: SNAPSHOT OF SELLING POINT WORKING ENVIRONMENT Next stage describes main features of the car prototype and its next applications. 4.2 The car prototype The car prototype represents the computing core of the system; its development involved the formalization of knowledge captured during the study of the car. All data coming from experience or provided by the factory have been saved in a database that represents the system data source. The system database contains all data retrieved from Dallara handbook and other information needed to perform some parts dimensioning.

For example ball joint dimensioning needs a comparison between calculated values of design variables (e.g., linkage screw diameter) and available part dimensions (e.g., hole diameters of ball joints actually produced). As the end user modifies the linkage screw diameter, the system uses the new value as an input for a table (table 1) of the database including all properties (code, type, dimensions, mass) of available ball joints. As a result the system provides a new ball joint whose hole diameter best approximates the given value. There are even tables including all dimensional parameters of a particular system (e.g., chassis, antirolling bar). In these cases it is possible to save alternative configurations of the same component, that can be identified synthetically by a configuration code. This option is in particular useful when teams need different configurations for some assemblies or components. It is possible to easily fit the prototype to alternative solutions inserting into the database different sets of values for the same group of independent parameters (related to a desired component or assembly). Each set corresponds to a specific configuration and it can be directly retrieved modifying the prototype parameter related to the table identification code within the database.

TABLE 1: BALL JOINTS DATA Once the system database has been organized, different functional, dimensional and positional relationships have been identified and re-processed in accord with model hypothesis. Use of graphical primitives and sweeping blocks, whose mass and geometric properties are automatically evaluated by SP, allows the description of car components and determines mass computing. For example theoretical equations (a) and (c) for mass analysis of the suspension assembly (represented in figure 6) become: M

Ptot = ∑ Pi ⋅ C i , i =1

Ptot = total mass,

(f)

Pi = Vi (φ i ) ⋅ d i ,

(g)

Pi = i-nth calculated part mass, Vi = i-nth part volume1, di = material density, Ci = corrective coefficient of the i-nth part, M = number of represented components.

FIGURE 6: FRONT SUSPENSION ASSEMBLY Equation (g) evaluates single part mass and depends on the shape φ (and dimensions) of the component represented in the model. M

G tot =

∑ P ⋅G i

i =1

M

∑P i =1

i

,

(h)

i

G tot = suspension assembly center of mass, G i = i-nth part center of mass. At the same time theoretical equations (c) and (e) for mass and center of mass evaluating of the chassis (represented in figure 7) become: 4

P = ∑ Pi + Pstiffening ,

(i)

i =1 4

G=

∑ P ⋅G i =1

i

i

+ Pstiffening ⋅ G stiffening

P

,

where:

P = computed chassis mass,

1

Automatically evaluated by Selling Point

(l)

[

]

Pi = Ci ⋅ (d honeycomb ⋅ S hi ) + (d c ⋅ S c1i ) + (d c ⋅ S c 2i ) + d glue ⋅ Supi ,

(m)

Pi = mass of one of the 4 sections delimited by subsequent bulkheads, dhoneycomb, dC, dglue = density of the honeycomb, carbon fiber and glue, Shi, Sc1i, Sc2i = thickness of the honeycomb, internal and external carbon fiber for the i-nth section, Supi = area of the i-nth section2, G = center of mass of the chassis, G i = center of mass of the i-nth section2, G stiffening = center of mass of stiffening parts. Notice that integrals of equations (d) and (e) have been replaced with discrete summations (i) and (l), because of the representation of real chassis surface trough different sweeping blocks (see figure 7).

FIGURE 7: CHASSIS SYSTEM WITH CENTRE OF MASS Mass properties of all components represented in the prototype depend on the approximations introduced using solid primitives; corrective coefficients (Ci) have been used to balance model results and data coming from experience. In some cases (engine, bellhousing, gear system) graphical representation concerned only positional properties; mass has been evaluated statically as the sum of the single component masses, retrieved from the system database. Last class of car components includes parts without a graphical representation (e.g., liquids, air jack system, electric system, and driver); in these cases both mass and center of mass are constant and come from the system database. The end user can access the model editing the independent parameters. Table 2 reports some of the available parameters and shows the impact on car asset.

TABLE 2: CONFIGURATION PARAMETERS OF FRONT SUSPENSION ASSEMBLY As the model re-computes all dependent parameters new configuration of the car is generated. The user can retrieve all interested results that consist both of mass properties of the car and main components and of part dimensions evaluated through design rules. The following section will introduce the user interface of the prototype.

5. Prototype user interface Applications developed using Selling Point have a user interface strictly oriented to the programming environment. To interact with the prototype, the end user should know its structure as well as the programming language GSL. For example, he/she must know the name used within the program of the parameters to be modified, in order to study a new car configuration. Therefore a graphic user interface has been implemented using Visual Basic. The user interface has the same look & feel typical of all applications developed in Windows NT or 95 environment. Fig. 8 shows the main window of the user interface. The enduser can interact with the prototype at different levels of the car structure simulating in this way the designer’s activity during the car study.

FIGURE 8: SNAPSHOT OF THE USER INTERFACE (MAIN WINDOW) He/she can access to the car model from general point of view as well as to each car sub-assembly and related detailed information. To this end it is available a browser, named Model Tree View, that allows the user to navigate within the hierarchical structure of the car. Fig. 9 shows the Model Tree View and the interaction with the bodywork system.

2

Automatically evaluated by Selling Point

FIGURE 9: MODEL TREE VIEW AND BODYWORK SYSTEM WITH WINGS Car parameters have been functionally organized in independent and dependent (calculated results) parameters. The main window (representing the entire car model and the root of the tree structure in figure 9) and those of each car sub-system (representing intermediary nodes) provide dynamic graphic representations of specific assembly and collections of data concerning mass properties calculated by the computing core.

FIGURE 10: CHASSIS PARAMETERS WINDOW The designer can indirectly modify these data editing the value of independent parameters of each component, which are collected into related windows (the leaves in the model tree view). The user directly from the sub-assembly window or from the model tree view can access sub-system component windows. Different pictures of the component help the user to evaluate consequences of his/her intervention, as shown in Fig. 10. When the user selects an available parameter, its meaning is highlighted in the graphic representation of the current car part. After each parameter modification the system automatically updates the mass data and the graphic representation of the car. The designer can generate and save different car configurations to compare and evaluate possible alternatives or retrieve previous projects. The organization of different information provided to the user within the hierarchical interface structure, based on the car one, is reported in table 3 below; examples of typical available data allow an easier comprehension of the interface system.

TABLE 3: ORGANISATION OF INFORMATION WITHIN THE INTERFACE

6. Experiments and results The tool developed has been tested comparing the results provided by the prototype with the information retrieved from Dallara measurements. Different configurations of the car model have been evaluated in order to reproduce the conditions of some racing cars. Main results validated the prototype: in fact computed mass and center of mass coincide with little approximation (see table 4) to the same data supplied by the factory. Results analysis emphasized a problem due to variation of static load distribution (aerodynamic supplementary loads aren’t considered) between front and rear wheels during the race. In particular, because of the different position of centers of mass of the whole car and of the tank/fuel system, fuel burning induces a backward displacement of the first one.

TABLE 4: MAIN RESULTS PROVIDED FOR A STANDARD CONFIGURATION, WITHOUT DRIVER In order to decrease as much as possible this undesired effect a new configuration of the prototype has been developed. The ideal condition can be achieved when the two points lay on the same vertical axis. In this way the x co-ordinate (see car reference system in figure 8), of car center of mass doesn't depend any more on fuel charge and, at the same time, the problem concerning wheels load changing is solved. Assuming that the tank can’t be moved, because of the normative, the center of mass of the car has been moved toward the center of mass of the tank/fuel system. This result could be achieved trough the forward displacement of some parts which are not fixed to a specific position by the normative or by functional constraints. Table 5 reports the results provided by the prototype with the new configuration. It is possible to evaluate car asset improving comparing the values of the front load rates (from empty to full load of fuel) obtained for the current (1.25%) and the proposed configuration (0.59%).

TABLE 5: MAIN RESULTS PROVIDED BY THE PROTOTYPE FOR THE NEW CONFIGURATION Fig. 11 repeats the results just reported and gives a graphical representation of the problem presented. The picture on the left shows the distance between centre of mass of the car and of the tank/fuel system for a standard configuration of the prototype. The picture on the right gives the same information for the new configuration of the prototype.

FIGURE 11: TANK WITH CENTRE OF MASS OF THE CAR (GOLD) AND OF TANK/FUEL SYSTEM (BLUE)

7. Knowledge sharing Use of automatic configuration systems during preliminary design allows designer managing all significant knowledge concerning the product and its life cycle, from general point of view. Possibility of re-using and sharing this information during successive design stages gives an important support to the process. Different specific tasks can go on simultaneously and in coordinated way, thanks to the shared knowledge base that allows communication among various areas. Increased integration level resulting from this methodology supports the development of more controlled products from ideas to production. The objective can be identified with the understanding that product quality can be improved by improving the design and manufacturing process. In the context of the work that has been presented here, possibility of re-using car prototype information in commercial CAD/CAE systems has been tested. In particular we verified two different integrative solutions:

•

first one is about the automatic generation of 3D CAD model of a car component (front suspension wishbone); the software used permits also semi-automatic generation of technical drawings;

•

second one concerns the possibility of exporting and re-using geometric elements produced by the prototype in a simulation environment; the objective is to analyze dynamic and cinematic behavior of the car and of the front suspension assembly.

Benefits come from the fact that designers, once approximate car configuration has been defined, can carry on working with the detailed definition of car parts or with analysis of car behavior having a feedback on initial hypothesis. Different activities can be developed at the same time, starting from robust common base provided by car prototype. 7.1 Automatic generation of wishbone 3D model Knowledge based system described supports experts during the decision making process, and allows high level problem managing, in relation with the preliminary car design phase. During next stage the adopted decisions affect significantly the generation of detailed parts design that requires specific tools and methods. Distance between the two activities can be decreased creating a bridge that permits the prototype automatically controlling 3D CAD models generation. This happened by linking model parameters to data and dimensions that the car model evaluates when configuring itself. As an example, it is presented a model of the front suspension wishbone. The prototype updates this part dimensioning, testing various rules regarding the chassis dimensions and shape, the front wheel dimensions and position, the ARB system configuration, and normative constraints. The end user determines the wishbone dimensioning editing cross section of rods (rods make up the wishbone) and modifying the configuration of the chassis and of the front suspension assembly. The system recalculates automatically the dimensions and writes them in a database that drives the 3D-model generation. The tool used for the wishbone 3D modeling is Solid Edge, a commercial system that

supports the integration with the car prototype. This modeling environment allows also generating the technical drawings of the parts or assemblies represented (Fig.12). FIG. 12: AUTOMATIC GENERATION OF WISHBONE 3D-MODEL AND TECHNICAL DRAWINGS It can be noticed that after the preparatory stage, dealing with the creation of the part model and of the bridge between the two systems, the prototype automatically updates the model of the part every time the designer modifies the car configuration. 7.2 Dynamic simulation Car mass distribution and asset affect performances during races: for this reason it can be useful comparing different car configurations through dynamic and cinematic simulation. Elements represented by the system can be exported into a simulation environment that allows verifying car dynamic behavior. The tool that supports the integration of the prototype for the simulation is Working Model; information provided by different tests acts as a feedback for designer's starting hypothesis. The prototype development loop (Fig. 13) is based on a typical design procedure: results analysis, performed by the designer, determines changes to the set of independent parameters that define the prototype configuration. When performances foreseen through simulation, coincide with expectations, an accepted model of the car is send to output. FIG. 13: CAR DEVELOPMENT LOOP (IDEF0) Outcomes from other activities (like wind tunnel tests) affect the configuration of the prototype and impact the dynamic simulation results: for these reasons they should be considered as input of the loop. It's worth underling that different aspects and problems concerning car performances are dependent and, for this reason, it is necessary to assure data exchange among concurrent activities. The experiences presented are about the analysis of front suspension behavior; results provided were used to compare performances and different attitudes of the car while changing properties and

configuration of the sub-system on which the study was focused. Fig. 14 shows the suspension (with approximate chassis and rear wheels) model during a simulation test, with a diagram of the chassis velocity.

FIG. 14: SNAPSHOT OF A SIMULATION TEST

8. Conclusions A prototype application for the evaluation of IRL cars mass distribution has been studied and implemented within a KAE environment. The tool presented has been used to simulate mass properties of the car in relation to a set of independent parameters that define the car asset. We will summarize the results of our work from two different points of view: one related to the skill and the approach required developing a KAE application, the other about the developed system itself. From the beginning the most critical part of the work has been the knowledge acquisition. During this phase the experience of Dallara experts has been fundamental in order to define the system requirements and the car model structure. The prototype developer had the same engineering background of problem experts, however a short training period was necessary to be able to start the system implementation. The fact that the actors had the same background has been the guarantee for a successful development. This allowed eliminating the misunderstandings that are often introduced when experts of different domains (typically engineering and computer science) have to find a common language to transfer the knowledge into the computerized system. Speaking about the prototype itself, we had to introduce some acceptable simplification for the generation of complex shapes. On the other hand, the flexibility provided by the developing

language has facilitated the tuning of the application on the basis of available experimental results. After the tuning activity, the difference between the computed values of total weight and center of mass and the experimental data is less than 0.57%. We also would like to underline how the definition of external data bases containing experimental data and standard components will facilitate future system updating. Finally, the possibility to export both geometrical and functional data in standard formats gives to the system the opportunity to share data with more traditional design/analysis support systems and then to be fully integrated into the car development process.

References Colombo, G., Cugini, U. (1992). Knowledge Aided Design: Requirements, Systems and Applications. Revue internationale de CFAO et d'Infographie, 7(3), 293 – 309. Cross, N. (1998). Expertise in Engineering Design. Research in Engineering Design 10, 141 – 149. Guarino,

N.

(1998).

Formal

Ontology

and

Information

Systems.

Proc.

FOIS'98

(www.ladseb.pd.cur.it/infor/ontology/papers.html). Kariko-Buhwezi, B., Cugini, U. (1995). A Knowledge Based Computer Programming for the Automatic Design of a Gear Pump. Proc. First IFIP WG 5.2 Workshop, Knowledge Intensive

CAD-1 (KIC ‘95), pp. 421-434. T. Tomiyama, M. Mantyla and S. Finger Eds.. Mandorli, F., (1997).Customized Product Design: Shearing Dies Test Case. Proc. 10th ADM

Conference, Design Tools and Methods in Industrial Engineering, 189 – 198. Moulianitis, V. C., Dentsoras, A.J., Aspragathos, N.A. (1999). A Knowledge-based system for the conceptual design of grippers for handling fabrics. AIEDAM, 13(1), 13-27. Ognjnovic (1996). Decisions in Gear Train Transmission Design. Research in Engineering Design

8, 178 – 187.

Salustri P. (1998). Ontological Commitments in Knowledge Based Design Software. Proc. KIC98, 32-42. Soininen, T., et al. (1998). Towards general Ontology of Configuration. AIEDAM, 12(4), 357-373. Vernadat F.B. (1996). Enterprise Modeling And Integration – Principles and Applications. Chapman and Hall.

Tables Code

D int

D ext

Radius

Thickness

Mass

3

4.826

15.875

11.0998

8.3058

14.075

4

6.35

15.875

11.0998

8.3058

14.074

5

7.9375

17.4625

11.0998

8.0518

15.89

6

9.525

20.6375

12.7

10.3124

27.24

7

11.1125

23.8125

14.2748

11.2268

36.32

8

12.7

25.4

15.875

12.827

45.4

9

14.2875

28.575

17.2212

13.6144

61.29

10

15.875

30.1625

19.05

14.4018

72.64

12

19.05

34.925

22.225

16.002

108.96

14

22.225

41.275

22.225

19.177

158.9

16

25.4

53.975

34.925

25.527

440.38

TABLE 1: BALL JOINTS DATA

Parameter Code

Meaning, Impact

Axis

Distance between front wheel axis and chassis/engine interface

Link1

Dist. 1th linkage lower wishbone / engine interface

Link2

Dist. 1th linkage upper wishbone / engine interface

Link3

Dist. 2nd linkage lower wishbone / engine interface

Link4

Dist. 2nd linkage upper wishbone / engine interface

L_steer

Steering arm length

D_Rim

Rim diameter

D_brake

Brake disc diameter

D_upright

Upright reference diameter

W_wheel

Wheel width TABLE 2

Level Root

Example

Related available information

Entire Car (Main

Dynamic Graphical Representation,

Window)

Car Mass and Centre of Mass

Intermediary Node Rear Suspension Dynamic Graphical Representation,

Leave

Assembly

Assembly Mass and C. of M.

Wheel Sub-

Help Pictures, Independent

Assembly

Parameters of the sub-assembly TABLE 3

Fuel Load Rate → Mass [kg]

Empty (0%)

Medium (39%)

Full (93%)

734.5

781.5

841..9

Centre of Mass Co-ordinates [mm] (-1786.3, -2.5, 238.9) (-1770.8, -2.5, 230.6) (-1757.2, -2.2, 237.7) Front Load [kg]

296.9

319.9

348.4

Rear Load [kg]

437.6

461.6

493.5

Front Load Rate (computed)

40.41%

40.93%

41.38%

Front Load Rate (measured)

40.18%

40.96%

41.43%

Difference

0.23%

0.03%

-0.05%

TABLE 4

Fuel Load Rate→ Mass [kg]

Empty (0%)

Medium (39%)

Full (93%)

735,3

782,3

842,7

Centre of Mass Co-ordinates [mm] (-1702.3, -3.9, 237.9) (-1692.0, -3.6, 229.6) (-1684.3, -3.3, 236.1) Front Load [kg]

312,6

335,2

363,2

Rear Load [kg]

422,7

447,1

479,5

Front Load Rate

42,51%

42,85%

43,1%

TABLE 5

Figures

New solution development

Idea (hypothesis and previsions)

Result analysis

Feedback on hypothesis

FIGURE 1: DECISION MAKING LOOP

Car

Bodywork

Rear wing

Rear Susp.

Steering sys.

Front Susp.

Chassis

Front ARB

Rear ARB

Back sys.

FIGURE 2: CAR TREE STRUCTURE (WITH MAIN SUB-ASSEMBLIES)

Front wing

Suspension Assembly Right Suspension Arms Tie Rod (Steering arm) Upper Wishbone Arm Rod I/Board Bush Arm Rod I/Board Bush Stiffening arm O/Board Ball Joint Lower Wishbone Arm Rod I/Board Bush Arm Rod I/Board Bush Stiffening arm O/Board Ball Joint Left Suspension Arms Damper & ARB System Right Wheel System Left Wheel System

FIGURE 3: SUSPENSION TREE REPRESENTATION

FIGURE 4: REPRESENTATION OF THE CAR PROTOTYPE (SELLING POINT ENVIRONMENT)

Parameter editing window

Prototype Library

Prototype tree structure

Component (node) property page

FIGURE 5: SNAPSHOT OF SELLING POINT WORKING ENVIRONMENT

FIGURE 6: FRONT SUSPENSION ASSEMBLY

FIGURE 7: CHASSIS SYSTEM WITH CENTRE OF MASS

Main Menu Toolbar

Main Weight Parameters

Graphic Area

Message Bar

FIGURE 8: SNAPSHOT OF THE USER INTERFACE (MAIN WINDOW)

FIGURE 9: MODEL TREE VIEW AND BODYWORK SYSTEM WITH WINGS

Help Picture: dimension related to selected parameter

Selected Parameter

FIGURE 10: CHASSIS PARAMETERS WINDOW

FIGURE 11: TANK WITH CENTRE OF MASS OF THE CAR (GOLD) AND OF TANK/FUEL SYSTEM (BLUE) Variable Name lung1 lung2 angolo copia assemag assemin spessore dforovert altezzavert ...

Value 539.205 539.205 132.820 136.840 42.800 18.700 1.200 20.000 18.700 ...

Unit mm mm ° ° mm mm mm mm mm ...

Solid Edge wishbone 3D-model

Database table with parameters

Selling Point prototype wishbone

Wishbone technical drawings (SE)

FIG. 12: AUTOMATIC GENERATION OF WISHBONE 3D-MODEL AND TECHNICAL DRAWINGS

Used at:

Author:

Universita' degli Studi di Parma

Date:

Project:

Knowledge Based Systems

Rev:

04/23/99

READER

WORKING

DATE

Context:

DRAFT RECOMMENDED

Notes: 1 2 3 4 5 6 7 8 9 10

Configuration control information

X

Designer Know How

Design parameters

Simulation control information

PUBLICATION

Performances objective

Configure car prototype

Car model A1

Simulate dynamic behaviour

Outcomes from other activities (stress analysis, wind tunnel tests, ...)

Performances A2

Analyse configuration

Approved configuration A3

Knowledge Based System Node:

A0

Title:

Changed design parameters

Simulator

Designer

Configure and simulate car prototype

FIG. 13: CAR DEVELOPMENT LOOP (IDEF0)

Number:

2

FIG. 14: SNAPSHOT OF A SIMULATION TEST