SPECIAL ISSUE PAPER 13

Standard multi-body system software in the vehicle development process

E Fischer BMW AG, 80788 Munchen, Germany. email: ewald.scher@bmw.de The manuscript was received on 23 February 2006 and was accepted after revision for publication on 18 July 2006. DOI: 10.1243/1464419JMBD59

Abstract: In the developmental processes of a complex product, such as a passenger car, simulation software tools are used today to such an extent that the notion of a virtual development process is justied, paralleling the hardware-based development process. In conjunction with several other software tools, a multi-body software system (MBS) can be an integral part of the virtual process, covering the area of suspension analysis and vehicle dynamics, provided it is tailored to the specic needs of the product, the software users, and the industrial organization. This article describes these needs by showing the context in which MBS is used, its interface with other tools, and the expectations of the users and concludes with an assessment of the current state. Keywords: virtual vehicle development processes, standard multi-body simulation tools, suspension and vehicle dynamics development

INTRODUCTION

One can imagine that in the past 50 years ago products such as passenger cars and their subsystems were designed on paper, then built in hardware, and tested. Like everywhere in the world of engineering, these three steps have to be understood as an iterative process, which has to be repeated several times before a development is complete. These days, the three steps still exist and work as before, but in a different manner not only was the paper replaced by computer disks as storage mediums for the designs, but also a lot of hardware testing was replaced by software testing. Probably, the most prominent example for this achievement is that the highly expensive hardware crash tests can today be virtually completed via computer simulation. This example illustrates other important aspects of the topic. First, it is not expected that the car will be delivered to the customer having only been tested virtually. Even though both simulation software vendors and simulation software users strive to become better everyday, it has been accepted that virtual testing is just another technique, which can fail. This fact, in conjunction with customer expectations and governmental legal requirements, guarantees the use of hardware tests in the foreseeable future.
JMBD59 # IMechE 2007

The statement still holds that the nal instance is always the (hardware) experiment. Hence, hardware testing and virtual testing should co-exist, and if a company does not want to waste resources, it will make them collaborate. The second aspect of the crash test example alludes to the major justication of using virtual testing in that it is signicantly cheaper than hardware testing. Even if it is true that virtual testing usually helps engineers better than hardware testing to gain insight into a certain phenomenon, i.e. to make a human understand a problem, the economic rationale will simply ask for the least expensive way to achieve a certain goal. Given the historical fact that hardware testing existed before virtual testing, it is not surprising that hardware testing has set the rules with which virtual testing must follow, i.e. guidelines for experimental techniques and measurements. Additionally, and not only for historic reasons, virtual testing has the burden to prove the correctness of the virtual results or to explain the discrepancies with hardware test results, and not vice versa (although, in some cases, the virtual techniques have helped the hardware world to improve, too). This could all be summarized in the sentence: virtual testing, in order to justify its existence, must
Proc. IMechE Vol. 221 Part K: J. Multi-body Dynamics

14

E Fischer

be capable of executing the same experiments, producing the same results, and hence allowing the same engineering processes as hardware testing just faster and cheaper. This statement is correct, but it should be regarded as a necessary condition only. On top of that, the potential of the virtual testing has to be fully exploited. In particular, virtual testing must be able to do experiments that cannot be done in reality, must be able to measure quantities that cannot be measured in reality, and must be able to combine subsystems or components that cannot be combined in reality. The following sections will try to translate these general requirements for virtual testing into requirements for use in standard multi-body software (MBS) system as used in the day-to-day development processes for suspensions and vehicle dynamics. When assessments are given on how well these requirements are met, it will refer specically to the software tool MSC.ADAMS/Car-AT and the processes in BMWs chassis development.

the future at least as long as computer science does not provide truly intelligent articial intelligence. However, in general, it also seems necessary that these tools be integrated more closely, and that MBS systems specically, must easily interact with FE systems in order to cover the effects of the exibility of parts. 2.1 Computer-aided design

MBS AND OTHER TOOLS

Before describing requirements and implementation of an MBS system for virtual development of suspensions and vehicle dynamics, its neighbours in the computer-aided engineering (CAE) world and their relations to the MBS system must be explained. The neighbours taken into account here are: (a) (b) (c) (d) (e) computer aided design (CAD); product data management (PDM); nite element (FE); vehicle dynamics tools; control system design tools.

The metaphor of neighbourhood is somehow misleading as it may be associated with steadiness and exact boundaries, whereas the history of the various CAE disciplines and tools is better described in terms of fuzzy boundaries, overlapping application areas, constant yet slow changes, and a bit of competition. For example, general-purpose MBS systems have claimed for quite sometime to be able to simulate control systems, whereas FE tools have claimed to be able to run kinematic analysis and so on. Both these claims are somehow justied, but only to a certain degree. Having said this, the areas of application of these CAE tools, as described subsequently, do not express what tool specialists can do with their tool, but show the range of application the average users can in fact cover. How these application areas will develop in the future is an open question, and owing to the current division of labour, doubts exist over whether a single integrated system will be the tool for everybody in
Proc. IMechE Vol. 221 Part K: J. Multi-body Dynamics

Most CAD systems offer functionality for basic kinematic analysis or basic stress analysis and alike and these functions can denitely help the designers in the development process. However, they cannot replace a full analysis by a specialist, partially because the functionality is still limited sometimes intentionally and partially due to the lack of expertise of the average CAD user. Nevertheless, CAD is denitely the source of geometric data, and thus, an appropriate interface between CAD and MBS is essential for the virtual process. Given the current state of the division of labour roughly equal to the boundaries between CAD users and MBS users an appropriate interface must provide rst of all the bidirectional transport of the socalled hardpoints, i.e. the location and orientation of important points in the system such as joints. It must be bidirectional, because an optimization process may start with the hardpoint locations of the CAD model, then perform the kinematic and elastokinematic optimization with the help of the MBS system, and then return the updated set of hardpoints to the CAD system for cross-checks on packaging. Other data that are supposed to be easily obtainable from a CAD system are mass and inertia. However, the problem exists that the grouping and the granularity of CAD parts do not care about the needs of the MBS system and so CAD cannot be a direct source. Also, because other systems in different elds of the development process have to know inertia information as well, but most likely in a different granularity, the task to derive the required information is left to these systems and then CAD is just one source of data among others or to a dedicated process, which should, in fact, offer the data in a PDM system. 2.2 Product data management

PDM systems are supposed to be the information warehouses for other items required by the MBS system, but usually not obtainable from the CAD package, as for example spring rates or tyre properties. The ideal PDM system would be a data-backbone, which contains all kinds of information for every part or component or assembly, and every version or variant of it, and the associated conguration information for existing products, prototypes, or virtual
JMBD59 # IMechE 2007

Standard MBS system

15

prototypes. Ideally, an MBS system would be just one of many computer-aided-something (CAx) systems, which are both consumers of data stored in the information warehouse and producers of data, which may be used by other systems, as shown in Fig. 1. Unfortunately, such systems are not yet reality, and consequently, an MBS system and its users are forced to handle most of the data management tasks themselves, possibly leading to intermediate solutions, where a kind of poor mans PDM is provided within the MBS tool itself the MBS tool offers not only a simulation engine with various test-rigs or test environments, but also models which are ready to use, which can be modied and developed further by the users. As a compensation for this data service, the users are urged to store their newly created models in this central place but once they are ready for publication within the development community. Automatic quality assurance procedures and versioning tools such as Concurrent Versions System (CVS) as known from software development help them in this process. Additionally, direct interfaces between CAx systems which have been developed in the past, e.g. between CAD and MBS, must be maintained, although they contradict the concept shown earlier. 2.3 Finite element

for simulations of vehicle manoeuvres. Being very fast when compared with simulations with the ordinary MBS models, they are naturally the optimal partner for Hardware-In-The-Loop systems. In contrast, they need, as input, descriptions of the vehicles suspension properties, and these can be delivered by hardware measurements or by virtual measurements on MBS models. To provide for the latter, the MBS tool should have the appropriate canned application series of specically designed virtual experiments to derive the data for these models. Especially in the form of white box models, implemented in the block-diagram-oriented software systems for controls systems design, these tools are highly suited for the development and verication of strategies of control systems for suspension and vehicle dynamics. Thanks to their smallness, they also require a signicantly smaller amount of data, which, in turn, makes them the preferred tool for both basic investigations of the system vehicle and in development in the early phases when precise data are not available.

2.5

Control system design tools

In the past, FE tools were mainly consumers of data gained by the MBS techniques such as load data. Today, they are also providers of exible body models, as requested more and more in the MBS tests. The required interfaces and processes on both sides are fairly dened, yet the ease of use and the reliability in the daily work still have to be improved. 2.4 Vehicle dynamics tools

There exists a class of specialized tools which can also be described as small MBS models used only

As discussed previously, the combination of control system models with mechanical models inside an MBS simulation is possible. However, owing to the signicantly higher requirements for data input and simulation time, this combination is not the ideal tool for developing control systems. However, this combination has to be used when there is a demand for verifying the interactions between the mechanical system and the control system, as is likely to happen in the later phases of the development process. Consequently, there is a need to interface control system models with MBS models, and the required interfaces and processes do exist in principle, but again the ease of use and the reliability in the daily work are still to be improved. 3 REQUIREMENTS FOR A STANDARD MBS SYSTEM

The system vehicle and its development processes, as they exist today, pose certain requirements on an MBS system, which are partially of general nature and partially specic to MBS. As seen from the users point of view, one could group these requirements into: (a) (b) (c) (d) ease of use; scalability; re-usability; reliability.
Proc. IMechE Vol. 221 Part K: J. Multi-body Dynamics

Fig. 1

Data management concept

JMBD59 # IMechE 2007

16

E Fischer

3.1

Ease of use in modelling

It must be stated that owing to the market requirements in the vehicle industry, which among others enforces the development of more cars in less time, it is not possible anymore to run the virtual threads of the development processes as a handcraft business. Instead, an industrial approach is required, which as a rst step requires the division of labour into two groups of MBS tool users. First, there is a group called the expert users. These are MBS experts who have the skills and experience to build up virtual models and to run virtual experiments on a level as described in reference [1], which will be called the MBS solver layer level. Their main area of expertise involves building models using the specic tools and deriving methods to best offer such models to the second group of users, called the end-users. The primary area of expertise of the members of this particular group involves the product, i.e. the vehicle. A simplied description of the relation between the two groups could read that the expert users prepare the models and experiments the end-users need to develop a virtual car. Not surprisingly, the number of second group users far exceeds that of the rst group. One could argue that the group of expert users should be regarded as part of the core business or if it should be sourced out. However, because the service they provide to the end-users must follow habits, rules, techniques, and conventions specic to the company, it is not advisable to source out this business completely. The second step in providing the required ease of use is to add another software layer on top of the MBS solver layer. This layer not only hides the details and the idiosyncrasies of the general-purpose MBS solver from the end-user, but also delivers a Graphical User Interface as is expected from an up-to-date software product. In addition, this layer must also provide facilities to manipulate the models, thus taking advantage of general properties of vehicles such as symmetry. It must also exploit the almost natural hierarchical modularity of the hardware product, which can be described as follows: (a) vehicle assembly (possibly including trailers); (b) subsystems, such as suspensions, steering, driveline, and so on; (c) components, such as rubber bushes and tyres. This natural hierarchical modularity also yields the following list of virtual experiments, which must be made available to the end-users by this layer. 1. With vehicle assemblies, one can perform driving manoeuvres such as steady state cornering, step input, braking in a turn, roll-over tests, obstacle
Proc. IMechE Vol. 221 Part K: J. Multi-body Dynamics

drive-over, uneven road driving, test track handling, and ride performance. 2. The vehicle assemblies consist of subsystems that have been tested using experiments on specic test-rigs. For example, the elasto-kinematic properties of the suspensions are veried on a suspension test-rig by running wheel travel, steering, or load-case experiments. 3. Even on the component level, specic test-rigs are needed. This applies particularly to complex components such as tyres, where the user may wish to verify the required properties of both the tyre model and a specic tyre data set by performing tests on a virtual tyre test-rig before applying these tyres to a car model. Thanks to this additional software layer, for which the term vertical application was coined. An enduser will not have to care about the syntax of a force-displacement relationship for a rubber bushing in the particular MBS solver. Instead they will look at the curves of various instances of bushings; select a suitable one or modify some; modify a suspension such that this specic bushing is referenced; make virtual tests with the suspension or a full vehicle model; and assess the results and possibly bring the model as the next design state into the public library. None of these actions will require a direct interaction of the user with the solver, and the interaction between the software user and the software system is done with objects the user knows from the hardware world, such as springs and bushes, and not in terms of solver objects. Additionally, the layer must be highly customizable, because the software has to adopt to existing processes and organizations and not vice versa. Obviously, the vertical application must also provide modelling and testing facilities for the expert users. However, by default, these should be hidden from the end-users.

3.2

Re-usability

From a certain point of view, a vast majority of the features built into the vertical application support the target of re-usability the primary goal of an industrial approach. A rst example was given above, wherein a bushing was replaced in a suspension before a virtual test was performed. Obviously, all data and the remainder of the model were re-used. A more serious example is when a suspension model is run in both kinematic and elasto-kinematic modes, such that the ideal joints (constraints) are replaced by compliant bushings and vice versa, although all other data can safely be re-used. When the suspension with the modied bushing is assembled into a full vehicle model, the other subsystems are re-used.
JMBD59 # IMechE 2007

Standard MBS system

17

The re-usability of subsystems and components must be supported by a certain design of the MBS models. It must, for example, allow a suspension model to be used with imposed motions or forces similar to that on a suspension test-rig, where the height of the wheel centre is dened by a jack. Obviously, this jack must be excluded when the suspension model is used in a full vehicle model. This eventually leads to a setup, where all subsystems of the vehicle model do not contain facilities for external excitations, as all are built into special subsystems called test-rigs. Therefore, an executable model must always be assembled from the subsystems and from a complementary test-rig, as shown in Fig. 2. This looks like a nasty overhead likely to confuse users, but the vertical application can hide potential traps to a large extent, and the notion of a (virtual) test-rig helps the end-users to understand how and which (virtual) experiment is performed, especially when the virtual test-rigs functionality is similar to that of the hardware test-rig. Whether the virtual test-rig must be a more or less detailed model of the corresponding hardware test-rig or if it is sufcient that it models just the effects of the test-rig depends on the specic experiment. Another advantage of re-usability is the separation of data and topology, whereby special classes of subsystem models, called templates, are introduced. These models contain all the topological information and modelling know-how, but they do not contain real data. The real models are create and only by adding the full set of data to such a template, e.g. a specic instance of a suspension. Naturally, templates are prepared by expert users, and end-users rarely have to deal with templates directly. This is

because they select only the data sets for a specic instance when assembling a model, and the processing of the right template is done by the vertical application behind the scenes. To add more re-usability one can equip these templates with switching facilities, for example, a roll bar is attached to different parts of the suspension dependent on the setting of the switch and other switching facilities are kinematic and elastokinematic modes, as discussed previously, and the ability to switch parts in the models to exible bodies, if the appropriate FE model exists. Another type of re-usability requested by the development process is the ability to combine certain sets of experiments and their respective postprocessing into well-dened processes. This may also include model modications between experiments and the ability to execute such processes automatically. This then naturally translates into the requirement that these processes can also be driven from external meta-tools providing methods for design of experiments and optimization.

3.3

Scalability

An illustrative example for scalability is the modelling of roll bar stabilizers, as shown in Fig. 3. The simplest method is to add a term to the forces acting on the wheels which is dependent on the wheel travel difference between left and right wheels. This model produces nothing but the effects the device was invented for, and hence, it is suitable for basic handling investigations. However, it omits, for example, mass effects and forces in attachments. A more detailed model with two rigid bodies connected by a torsion spring will provide for such effects and hence can be used in vehicle handling simulations

Fig. 2

Front suspension model on test-rig

Fig. 3

Roll bar models

JMBD59 # IMechE 2007

Proc. IMechE Vol. 221 Part K: J. Multi-body Dynamics

18

E Fischer

and, up to a certain degree, can predict loads in attachments when used in suspension test-rigs. Owing to the neglect of bending, the error in the predicted location of the roll bar ends will soon exceed the accuracy required in todays packaging process for passenger cars. To overcome this limitation, an FE model must be used. In general, the MBS approach puts on the (expert) user, as intended, the burden of making the right model for a specic problem. This can be regarded as a signicant difference to standard FE, where the model is, in a certain sense, dened once the geometry exists. Naturally, the end-user must not be confused by such features. If one wants to run an elastokinematic analysis, the system must use the elastokinematic mode of the attachments in the model. This statement holds true until the user explicitly requests the opposite, and this can be achieved by a context-sensitivity of the submodels and components. However, it must be avoided that such context-dependent changes to the model happen unperceived, and as so, they must be supported by changes in the graphical representation and alike. The ability to cover mass business is another dimension of scalability, and this could be seen as orthogonal to the dimension of submodel complexity described earlier. At rst glance, this appears to be just a matter of having a sufcient number of computers and software licenses. However, this is not true. For a tool used within an organization, which has to cover many different virtual vehicles and product series and which wants to take advantage of synergy effects, it is essential that users have the appropriate techniques to nd their way through this jungle. 3.4 Reliability

these changes have a great potential for causing problems. Sometime ago, it was said that the software industry should strive to improve their developmental processes in such a way that it could achieve the reliability and predictability of the development processes of the automotive industry. Possibly, as a response to this statement, a few years ago, the software industry claimed that one reason for the need of more virtual prototyping would be the fact that the number of recalls in the automotive industry had exceeded the number of cars delivered. One could discount this as a marketing argument, but if one assumes a grain of truth in both statements, one must conclude that techniques and methods for assuring the quality of the virtual techniques are essential for those who want to use them. The only known method to minimize the probability of unwanted effects of changes on any level is repetitive testing and, in this case, involves testing not only of the software itself, but also of the virtual product. Consequently, the MBS tool should also support testing and provide means to assess such tests, e.g. tools to compare results of virtual tests. It should be noted in this context that the software as delivered by the software vendor is the most important part of the tool and yet, only a part. It has to be complemented by models and data that originate from the software customers side; hence, both software and hardware models have common needs in the area of quality assurance. 3.5 Ease of use in result generation and processing

Like any user of a technical system, the users of a software system are not amused when the system shows an unexpected behaviour or even a malfunction. Typically speaking, software is not as reliable as users would desire. Especially for programs that are constantly being upgraded, unexpected crashes are common. In the case of the industrial use of MBS, regular changes are often initiated from outside the virtual development process, such as a new version of the operating system, a new version of the MBS solver, and a new version of the vertical application. In addition, these changes must never affect the physical contents of the virtual tests. In contrast, there are changes from within the customers development process, when, for example, a new type of suspension is added to the model library or a new class of a bushing model; or when the data set of a damper is updated. Unfortunately, all
Proc. IMechE Vol. 221 Part K: J. Multi-body Dynamics

Earlier, it was stated that the reference for any virtual testing is the hardware testing. Hence, it is not surprising that users of a virtual test expect that there is a certain set of standardized results available once they have managed to execute the desired test on the model to be investigated. This predened set of virtual measures should closely follow in number and denition those of the hardware. On the contrary, the virtual testing should not be as restricted as the hardware testing in the sense that it must always be possible to perform any measure after the experiment was nished without repeating the experiment. This ability gives a big advantage to virtual world over real world in that it must not be given up. X Y plots of quantities such as displacements, velocities, acceleration, and forces are the common method for presenting the results of a virtual experiment in all general-purpose MBS tools, but the vehicle development process requires many additional results toe and camber change which have to be derived from these base results,
JMBD59 # IMechE 2007

Standard MBS system

19

by methods, for example, as described in reference [2], and which have to be presented in highly specialized forms. Owing to the iterative nature of the overall development process, an easy visual comparison of all these results is necessary as such comparisons are the base for design decisions. Animation of the results, both for the geometrically dened entities and the mathematical entities such as accelerations or forces, is not only a nice convenience, but a necessary complement to X Y plots supporting the discussions on the development teams. Animation and comparison facilities, especially comparisons between virtual results and hardware results, are also necessary for the debugging of models and for validation. Finally, the support of interfaces to the neighbours mentioned earlier must be given, e.g. provisions to generate load input to FE programs or input to vehicle dynamics programs, and owing to the usual lack of standards, this has be done in proprietary formats.

ASSESSMENT ON THE STATE-OF-THE-ART

Today, nobody can deny that there is, as desired, a signicant frontloading in the developmental process of systems such as passenger cars, due mainly to virtual testing. Nevertheless, it would be ridiculous to state that virtual methods dominate the complete developmental process. In contrast, the potential of virtual testing is by far not fully exploited. This is partially due to a lack of system or modelling know-how and partially due to software deciencies. In the eld of MBS applications, there are two major areas where decits in modelling techniques limit the usability of these systems. These are tyre models and driver models. Virtual tyres, as described in references [3, 4], are used for MBS applications. However, taking into account that, in reality, tyres are still the most important component for the vast majority of properties of the nal product, todays tyre models are still not comprehensive and precise enough. Driver models, as described in references [5, 6], are also used in conjunction with MBS in order to predict the handling performance of a vehicle. To a certain degree, they also cover aspects of human perceptions and behaviour, but their applicability in the daily work is still under discussion. However, as the automotive industry has to deliver the perfect complement for a manmachine system, the need for progress in driver models persists. If software deciencies become prevalent, the rst proposal to overcome them would be to bring the power of the object-oriented approach to the endusers and to the programmers. Today, many CAE tools claim to be object-oriented. However, ones
JMBD59 # IMechE 2007

that are longer in the market consequently have a signicant market share provide only limited aspects of the object-oriented approach and not a complete and consistent system, as described in reference [7]. The vendors of these tools have a good and perfectly valid explanation for that, namely, the legacy. The users do not want to rebuild their existing models when migrating to a new system, and hence, progress is very slow in this respect. Consequently, todays applications still suffer from problems that caused the computer scientist to develop the concepts of object orientation: modularity, extendibility, reusability, classes and inheritance, exception handling, information hiding, to name just the ones relevant to end-users. An obvious problem that should be solvable by object-oriented methods is that the solver layer issues error messages, which are not understandable to the end-users. A proper exception handling would translate these messages from the solver world into the world of the enduser. Another example of how truly object-oriented facilities could help is if the concept of abstract classes existed. A user would then build up new models from such classes and, for visualization purposes, would assign them preliminary or guessed data. The system would, however, refuse to run tests against such a model as long as it contained a single abstract subobject, i.e. one with guessed data. In contemporary software systems, it may well happen that a guessed datum goes unnoticed into a virtual test model, causing, in the worst case, a wrong result for the virtual test. Building and maintaining virtual components, submodels, and models have denite similarities to writing software functions for big software systems, and so the user community encounters similar problems. Therefore, there is a need to provide users with version control techniques, which are well known in the software industry itself. It is fairly practicable to combine a public domain version control system such as CVS with an MBS system, and as such, one can get a lot of advantages from that. However, versioning should be regarded as a basic software technique and, hence, the MBS system should provide for that. Another indication on how far todays systems are away from being truly easy-to-use is the number of computer languages users have to master if they want to extract maximum performance out of their system. They will have to know C, or, if they are unlucky, FORTRAN to get special extensions into the solver; the proprietary solver language itself; a proprietary scripting language to drive the vertical applications; possibly another language to do postprocessing; special languages for data description; and probably one or more scripting languages such as PERL to glue everything together. Standardization
Proc. IMechE Vol. 221 Part K: J. Multi-body Dynamics

20

E Fischer

in this area is denitely necessary, but does, in fact, hardly exist. Because an OEM wants to buy virtual development engineering support and eventually even virtual components and subsystem such as hardware bought today, standardization on a higher level is also necessary, although it may conict with customizability. However, taking into account how long it took for early concepts of screws to become standarized as they are today, one can expect that this will still take sometime.

REFERENCES
1 Blundell, M. and Harty, D. The multibody systems approach to vehicle dynamics. SAE International, 2004. 2 Matschinsky, W. Radfuhrungen der straenfahrzeuge. kinematik, elasto-kinematik und konstruktion, 1998 (Springer, Berlin). 3 Paceijka, H. B. and Bakker, E. The magic formula tyre model. Proceedings of the 1st Tyre Colloqium, Delft, October 1991; Suppl. Veh. Sys. Dyn., 1993, 21, 1 18. 4 Gipser, M. FTire, a new fast tyre model for ride comfort simulations. Proceedings of the 14th European ADAMS Users Conference, Berlin, 1999. 5 Riedel, A. Fahrermodelle in der Praxis. Automotive Engineering Partners, 1998, 3, 88 91. 6 Frezza, R., Saccon, A., and Bacchet, D. SmartDriver: a sensor based model of a car driver for virtual product development. In Proceedings of IEEE/ASME International Conference on Advanced intelligent mechatronics, AIM2003, 2003, vol. 1, pp. 366 370. 7 Meyer, B. Object-oriented software construction, 1988 (Prentice Hall, New York).

SUMMARY

Virtual testing is a reality today, but its potential, especially in the MBS area, is by far not fully exploited. The reason is not that the product development process does not ask for more support from virtual testing, but that the virtual world is still not as reliable and as fast as it should be.

Proc. IMechE Vol. 221 Part K: J. Multi-body Dynamics

JMBD59 # IMechE 2007