Optimization of Wheel Suspension Packaging Methodology Development, Data Transfer from ADAMS/Car to CATIA V5 Master thesis in Product Development KARL HANSEN ANDREASSON MATTIAS LINDER Department of Product & Production Development CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2016 MASTER’S THESIS 2016 Optimization of Wheel Suspension Packaging Methodology Development, Data transfer from ADAMS/Car to CATIA V5 KARL HANSEN ANDREASSON MATTIAS LINDER Department of Product & Production Development CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2016 Optimization of Wheel Suspension Packaging Methodology Development, Data transfer from ADAMS/Car to CATIA V5 KARL HANSEN ANDREASSON MATTIAS LINDER © KARL HANSEN ANDREASSON & MATTIAS LINDER, 2016. Supervisor: Daniel Molin, Volvo Cars Supervisor: Magnus Bengtsson, Department of Product & Production Development Examiner: Magnus Bengtsson, Department of Product & Production Development Master’s Thesis 2016 Department of Product & Production Development Chalmers University of Technology SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: SPA Rear-wheel suspension. Typeset in LATEX Printed by Reproservice Gothenburg, Sweden 2016 iv Optimization of Wheel Suspension Packaging Methodology Development, Data transfer from ADAMS/Car to CATIA V5 KARL HANSEN ANDREASSON MATTIAS LINDER Department of Product & Production Development Chalmers University of Technology Abstract Finding an optimized and balanced concept of the wheel suspension, and its surround- ing components, is of great importance for future competitiveness. In order to do this, requirements need to be met in the early phases of development and design loops need to be shortened. This is a pre-requisite for enabling cost, weight and lead time reductions while also allowing for more design loops to be carried out, thus reducing the risk for late changes. A complex system, such as a wheel suspension, requires a methodology which enables CAE driven development on several levels, where a natural part is design optimization and a tight coupling between design and analysis (CAD & CAE). This master thesis aims at establishing the tight coupling through development of an applica- tion which can transfer motions from a multi-body dynamics simulations, in ADAMS/Car, to a kinematic model in CATIA V5. The work has covered the entire development process, from pre-study and requirement specification to concept development, detail design and testing & verification. Through- out the development effort there has been an ongoing dialogue with future users, as to understand their needs and develop a user-centered product. The end result is an application which increases precision of packaging analysis while also reducing the lead times of packing critical components of a wheel suspension, thus shortening design loops. The application is ready to be incorporated into Volvo Cars working methodology. Keywords: Optimization, CATIA V5, ADAMS/Car, kinematics, wheel suspension, data transfer. v About the Authors Karl Hansen Andreasson I received my BSc in Mechanical Engineer- ing at University West in Trollhättan, there- after I pursued my MSc in Product Develop- ment at Chalmers University of Technology in Gothenburg. I would like to thank my grandfather Paul for inspiring me to pursue engineering at the university. I also want to thank my family for their love and sup- port throughout my education, specifically my mother Cindy and my father Janne who have been my biggest supporters. Mattias Linder I received my BSc at the program Automa- tion and Mechatronics at Chalmers Uni- veristy of Technology. Afterwards I contin- ued with the MSc program Product Devel- opment at Chalmers. I would like to thank my dad Thord, for inspired me to study at Chalmers and become an engineer. I would like to thank my mother Gunnel who has supported me through all my educations. At last, I would like to thank my sisters Jennifer and Josefin for their love and support. vii Acknowledgements First of all we would like to thank our supervisor at Volvo Cars, Daniel Molin. Who has supported us on a daily basis throughout the entire project. We would also like to thank our supervisor at Chalmers University of Technology, Magnus Bengtsson for his guidance. Further we want to thank David Fredriksson and Albin Johnsson, at the Vehicle Dynamics Department, for their help within ADAMS/Car. We would also like to thank Fredrik Sjögren at MSC Software for his collaboration. Finally we would like to thank Harald Hasselblad of Volvo Cars Optimization Culture Arena for giving us the opportunity to take part in its Master Thesis Collaborations. Karl Hansen Andreasson, Gothenburg, June 2016 Mattias Linder, Gothenburg, June 2016 ix Nomenclature x̂ The unit vector for the x-direction ŷ The unit vector for the y-direction ẑ The unite vector for the z-direction ψ Represents the rotation around the third axis in a given rotation sequence θ Represents the rotation around the second axis in a given rotation sequence ϕ Represents the rotation around the first axis in a given rotation sequence API Application Programming Interface CAD Computer Aided Design CAE Computer Aided Engineering COG Center Of Gravity CS Coordinate System DoE Design of Experiments Jounce Suspension Compression KNU Knuckle LCA Lower Control Arm OEM Original Equipment Manufacturer Rebound Suspension Extension UCA Upper Control Arm xi xii Contents List of Figures xvii List of Tables xix 1 Introduction 1 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.5 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6 Related Master Theses . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.7 Optimization Culture Arena . . . . . . . . . . . . . . . . . . . . . . . . 3 1.8 Volvo Cars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Theory 7 2.1 Conventional Product Development . . . . . . . . . . . . . . . . . . . . 7 2.2 E-design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 The E-design Paradigm . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 Product Performance Analysis . . . . . . . . . . . . . . . . . . . 11 2.2.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Coordinate System & Rotations . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Rotation Sequences . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2 Rotation Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 CAD: Catia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.1 Wireframe model . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.2 Kinematic model . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.4 Envelopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5 CAE: ADAMS/Car . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.1 Body Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.2 Logging Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.3 ADAMS/Car .res-file . . . . . . . . . . . . . . . . . . . . . . . . 22 2.6 Wheel Suspension Theory . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6.2 Wheel Suspension Parameters . . . . . . . . . . . . . . . . . . . 25 3 Methodology - Interface Design Between CAD & CAE 29 xiii Contents 3.1 Current Working Process . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2 Pre-study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.1 Market Review . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.2 Software Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3 Requirement Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.4 Concept Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.4.1 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . 37 3.4.1.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.4.1.2 Pre-processing . . . . . . . . . . . . . . . . . . . . . . 40 3.4.1.3 Post-processing . . . . . . . . . . . . . . . . . . . . . 41 3.4.2 Data Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.4.2.1 Data Extraction . . . . . . . . . . . . . . . . . . . . . 43 3.4.2.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . 44 3.4.2.3 Replay File Generation . . . . . . . . . . . . . . . . . 49 3.5 Detail Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4 Results 55 4.1 New Working Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2 ADAMS/Car Template Modification . . . . . . . . . . . . . . . . . . . . 57 4.3 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.2 Pre-Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3.3 Post-Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.4 Features from detail design . . . . . . . . . . . . . . . . . . . . . 66 4.4 Possible Additional Functionality . . . . . . . . . . . . . . . . . . . . . . 70 5 Implementation Plan 73 6 Discussion 75 6.1 Development Methodology During Project . . . . . . . . . . . . . . . . . 75 6.2 Working Methodology Comparison . . . . . . . . . . . . . . . . . . . . 76 6.3 Application Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.4 Application Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.5 MSc. Thesis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.6 Trends in Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.7 Further Improvements & Future Areas of Use . . . . . . . . . . . . . . . 80 6.8 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7 Conclusions 83 8 Future Work Proposals 85 8.1 Flexible Body Implementation . . . . . . . . . . . . . . . . . . . . . . . 85 8.2 Hardpoint Optimization Through CAD & CAE Loop . . . . . . . . . . . 85 8.3 Application Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.4 Combined Drive-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Bibliography 87 xiv Contents A Wheel Suspension Types I A.1 Wheel Suspension Trends . . . . . . . . . . . . . . . . . . . . . . . . . . I A.2 Rigid Axle Suspension Systems . . . . . . . . . . . . . . . . . . . . . . II A.3 Semi-Rigid Axle Suspension Systems . . . . . . . . . . . . . . . . . . . II A.4 Independent Suspension Systems . . . . . . . . . . . . . . . . . . . . . . III B An example of "Create Replay" script VII C Requirement List IX D An example of .res file XVII xv Contents xvi List of Figures 2.1 The Design Paradox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 Cost of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Cost/ECR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Improved Cost/ECR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Shifted Design Paradox . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6 The E-design Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.7 The Cartesian Coordinate System . . . . . . . . . . . . . . . . . . . . . 13 2.8 The Intrinsic 3-1-3 rotation sequence . . . . . . . . . . . . . . . . . . . . 15 2.9 The Extrinsic 1-2-3 Rotation Sequence . . . . . . . . . . . . . . . . . . . 15 2.10 CATIA Wireframe Model . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.11 Kinematic Analysis Flow Chart . . . . . . . . . . . . . . . . . . . . . . . 18 2.12 CATIA Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.13 CATIA Rotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.14 Wheel Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.15 Template Modification Workflow . . . . . . . . . . . . . . . . . . . . . . 22 2.16 Vehicle Coordinate System . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.17 Vehicle Roll Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.18 Camber Angle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.19 Toe Angle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1 Current Working Process . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2 Project Working Process . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3 The V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.4 Application Function Breakdown . . . . . . . . . . . . . . . . . . . . . . 36 3.5 Mapping Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.6 Early GUI Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.7 Pre-processing Working Procedure . . . . . . . . . . . . . . . . . . . . . 41 3.8 Post-processing Work Flow . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.9 Component Distortion Through Rotation . . . . . . . . . . . . . . . . . . 43 3.10 Data Transfer Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.11 Data Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.12 Get Value IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.13 Get Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.14 Replay File Generation Process . . . . . . . . . . . . . . . . . . . . . . . 50 4.1 Proposed Working Process . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2 Working Process Comparison . . . . . . . . . . . . . . . . . . . . . . . . 56 xvii List of Figures 4.3 Measure Point Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.4 Mapping Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.5 Mapping Process Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.6 Pre-processing Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.7 Post-Processing Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.8 Wheel Suspension Info Tab . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.9 Move Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 A.1 Cost/Configurability Plot . . . . . . . . . . . . . . . . . . . . . . . . . . II A.2 Rigid Axle Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . III A.3 Semi-rigid Torsional Suspension Types . . . . . . . . . . . . . . . . . . III A.4 Longitudinal Link Suspension Systems . . . . . . . . . . . . . . . . . . . IV A.5 Double Wishbone Suspension System . . . . . . . . . . . . . . . . . . . V A.6 Multi-link Suspension System . . . . . . . . . . . . . . . . . . . . . . . VI xviii List of Tables 2.1 Rotation Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Simulation Information Table . . . . . . . . . . . . . . . . . . . . . . . . 53 xix List of Tables xx 1 Introduction This chapter presents the scope of the work and the cluster of master theses in which this thesis has taken part, as well as some company history about Volvo Cars. 1.1 Background Volvo Cars have set the goal of a time-to-market for new models to 20 months in the year 2020 [1]. This is a reduction of 12 months compared to the current time-to-market of 32 months (2016). In order to achieve this great investments are being made into increasing the efficiency and effectiveness of the company’s current working methods, as well as establishing new methods were necessary. An important part in this work is to enable CAE integration early in the development process, which reduces the need for costly and time consuming physical testing in later design stages. In order to integrate CAE early on the importance of data and information transfer between analysis and design (in Volvo cars’ case ADAMS/Car and CATIA) becomes a central issue. 1.2 Purpose The purpose of this master thesis is to optimize the working methodology for generating design spaces of critical components in the wheel suspension. This can be broken down into two main objectives both of which concern data transfer from CAE (ADAMS/Car) to CAD (CATIA) software. The simulation results from ADAMS/Car produce more realistic results as flexible bodies are used and bushing stiffness is accounted for. Due to limitations in CATIA V5’s Kinematics Workbench these two factors must be accounted for by tolerances and generic rules. The first objective is to reduce the lead time of producing a design space for an arbitrary component. This will be done by automating the data transfer from ADAMS/Car to CATIA V5, resulting in shorter lead times (in the range of 50 effective working hours for a critical component [2]). The second objective is to increase the accuracy of the packaging analysis in CATIA V5. This will be done by using the transferred data as input, instead of mimicking the movement within CATIA V5’s Kinematics Workbench, which is the case today. By doing so the tolerances and generic rules can be replaced by actual motions. 1 1. Introduction 1.3 Aim In order to fulfill the objectives stated in Section 1.2 an interface which allows motions from drive-case simulations in ADAMS/Car to be transferred into CATIA and used to control the wheel suspension kinematics. This interface must: • Read data from ADAMS/Car, either from a standard file or through requesting certain information. • Enable mapping of CATIA instances to motions extracted from ADAMS/Car. • Automatically generate a replay file in CATIA V5. • Incorporate post-simulation analysis into the solution. • Increase the capacity of data handling, compared to today’s working process. • Minimize information loss during data transfer. • Be intuitive to handle and not require extensive training. • Allow for further improvements to be added in the future. • Not deviate significantly from the current working procedure and today’s role distri- butions. 1.4 Limitations • Tests during the project have been limited to the rear wheel suspension of Volvo Car’s SPA platform, set up in the S90/V90 configuration. • The tests carried out have been limited to ADAMS/Car sub-system models of the wheel suspension, with an emphasis on kinematics and compliance. Full vehicle models are not included. • This project will not include hardpoint optimization as it is limited to developing a methodology which will help to enable this. • The project is limited to working with software which is currently available at Volvo Cars Wheel Suspension department. • The project is limited to 20 weeks of full time work by two Master students. • The scope of this project has been limited to transfer motions of rigid bodies from ADAMS/Car, however preparations for including body flex have been carried out. 2 1. Introduction 1.5 Research Questions • How can packaging of the wheel suspension be optimized in a fast and flexible way with respect to system dynamics, forces and moments? • How can data be transferred from ADAMS/Car to CATIA V5 and which is the most efficient way, with respect to user friendliness and efficiency? • How can knowledge from other areas/applications be automatically integrated into CATIA V5? 1.6 Related Master Theses This master thesis is part of a cluster consisting of three master theses within the area of design optimization. The three theses focus on different stages of the wheel suspension development process. This master thesis, ”Optimization of Wheel Suspension Packaging”, focuses on methodology development within data transfer from CAE to CAD software. The second master thesis, “Balancing of Wheel Suspension Packaging, Performance and Weight” [3], focuses on methodology development concerning the balancing of design spaces within a system. The third master thesis, "Structural Topology and Shape Optimization" [4], concerns methodology development regarding structural optimization of an individual component. The intention is to, sometime in the future, implement the methodologies developed in the three theses and thus create a complete working process from hardpoint placement down to topology optimization on component level. 1.7 Optimization Culture Arena The three theses in the cluster have been part of a larger “Optimization Culture Arena” at Volvo Cars. The aim of the “Optimization Culture Arena” is to share knowledge, support implementation and develop methods for CAE driven optimization across Volvo Cars entire organization. The scope is to involve all areas and work towards fully cross-functional optimization. Within this arena meetings are held where master theses which involve CAE driven optimization meet and share knowledge as the projects progress.[5] 3 1. Introduction 1.8 Volvo Cars Volvo, Latin for: “I roll”, was founded in 1927 as a subsidiary to the Swedish ball bearing manufacturer SKF. The two founders Assar Gabrielsson and Gustaf Larson planned to manufacture a Swedish car which could withstand the harsh winter and bad road conditions of the north. The emphasis was therefore, from the very beginning, set on safety and durability. [6] "Cars are driven by people. The guiding principle behind everything we make at Volvo, therefore, is and must remain, safety" - Assar Gabrielsson and Gustaf Larson, 1927 Volvo soon began to broaden its production to trucks and thereafter further by acquiring production within engines and components for air crafts, as well as marine engines. After the end of the Second World War Volvo experienced rapid growth partly due to the successful introductions of the Volvo PV444, PV544 and the Amazon, which was regarded as one of the safest cars of the time. In 1954 Volvo had 4500 employees and a turnover of 483 Million SEK [7]. By the beginning of the 1970s Volvo had 40 000 employees and a turnover of 6 Billion SEK [7]. Volvo experienced some tougher years during the oil crisis of the 1970s with a low number of model launches and focus set on acquisitions within completely new industries, e.g. the pharmaceutical industry. This was part of Volvo’s plan to diversify the company, as the automotive industry became more and more competitive. However, during the 1980s Volvo’s success within the automotive industry increased and the company manufactured record breaking volumes twice during the decade. The first time in 1983 and the then again in 1987, when the company manufactured 372 400 cars and 423 800 cars, respectively. It was also during the 1980s that Volvo launched its famous 740 model. [7] By the beginning of the 1990s Volvo sold its ownership in the previously mentioned acquisitions which were not related the Volvo’s core business, the company kept its business within trucks, buses, airspace engines, marine engines and cars. During the 1990s the 740 was replaced by the 940, both cars were known for their reliability and robustness. These models are still seen on the road today, especially in Sweden. During 1993 Volvo came close to merge with the French car manufacturer Renault, the merger was waved off days before it was to take place due to large resistance by the companies employees and senior management. This made the current CEO Pehr G Gyllenhammar (who was appointed in 1970) resign with immediate effect, marking the end of an era. During the rest of the 1990s the design language of Volvo’s cars changed dramatically, resulting in the S80 of 1998. In 1999 Volvo decided to sell its car manufacturing business to Ford Motor Company, the reason behind the sale was the high cost of developing new models for a small car manufacturer such as Volvo. The management team believed that the brand could live on as a part of a larger conglomerate. This led to the branching of Volvo Cars and Volvo AB, 4 1. Introduction where Volvo Cars became part of Ford Premium Automotive Group (PAG) together with Aston Martin, Land Rover and Jaguar. Ford’s strategy was to position Volvo Cars, close to the premium segment, a market position better suited for a car manufacturer with the production volume of Volvo Cars. During the beginning of the 21st century Ford, along with the other American Car manufacturers, were losing sales. Volvo on the other hand continued doing well, production increased at a steady rate and several popular new models were launched, including the first generation XC90. Volvo reached new record sales 2004 when 456 000 cars were sold. This in contrast to Ford, which was not faring nearly as well. By 2007 Ford had sold both Aston Martin, Jaguar and Land Rover. Rumours were beginning to emerge that Ford was considering selling Volvo as well. In 2010 The Chinese investment company Zhejiang Geely Hoolding Group had bought Volvo Cars for an, under the circumstances moderate price of $1.8 Billion SEK[8]. Under the ownership of Geely Volvo Cars continued the journey upwards through the segments. After the separation from Ford Volvo Cars made the decision to develop its own engines and a completely new product platform. Great resources were invested into the development of the new SPA – The Scalable Product Architecture – platform. The SPA platform was to function as a foundation for the company’s mide-size (60-series) and premium-size (90-series) vehicles. The first vehicle to be launched on the new platform was the 2nd generation XC90, launched in 2014 it became an immediate success, winning prestigious prizes around the globe and exceeding expected sales by some distance. Volvo Cars are currently in the process of launching both the S90 and V90, also based on the SPA platform. During the fiscal year of 2015 Volvo Cars broke its previous sales record, selling over half a million cars for the first time ever (503 127 cars were sold in 2015). The same year the company generated a revenue of 164 043 Million SEK, resulting in an EBIT of 6 620 Million SEK and a net income of 4 476 Million SEK. Volvo Cars had 28 119 employees at the end of 2015, an increase of 7% compared to 2014 (when the company had 26 101 employees).[9] Throughout the decades Volvo Cars have made some key innovations within the automotive industry, most of them within the area of safety. • The Three-point Safety Belt (1959) – Invented by the Volvo engineer Nils Bohlin, no other safety innovation is believed to have saved as many lives. Volvo waved its patent rights so that all vehicle OEMs could use the invention. • Rearward-facing child safety seat (1972) – An innovation which is used world- wide today, greatly decreasing the injury risk for infants and young kids. • The Lambda Sond (1976) – This little device, no bigger than a finger, is an oxygen sensing probe fitted to the engine. It reduces harmful emissions with up to 90% and is today used in every petrol engine car in the world. • Side Impact Protection (1990s) – By reinforcing cross-members and designing a strong structure of energy absorbing material Volvo greatly improved protection from side collisions, the side protection safety was further improved by introducing the first side airbag in 1994 and inflatable curtains in 1998. • Roll-over Protection System – ROPS – (2002) – As the popularity of SUVs in- 5 1. Introduction creased Volvo Cars realized the need for enhanced roll-over protection. ROPS includes a sophisticated electronic Roll Stability Control and boron steel reinforced structures. • Active Safety Innovations (21st century) – Volvo is a pioneer within active safety, introducing a flurry of innovation within the area. Innovations include Blind Spot Information System (BLIS), Collision prediction and pedestrian detection, both with full auto brake. 6 2 Theory The theory chapter contains different bodies of knowledge which are covered by this master thesis project. In the first two sections product development theory is presented, followed by rotations matrices. After this the software used is presented before the chapter is concluded with basic wheel suspension theory. 2.1 Conventional Product Development Conventional product development is based on a Design-Build-Test (D-B-T) philosophy [10]. Due to the D-B-T philosophy conventional product development is carried out in a sequential manner, which leads to a design process with prolonged lead times and elevated product costs. [11] The prolonged lead times and the elevated product costs are partly due a phenomena referred to as The Design Paradox [12]. The Design Paradox revolves around design flexibility, product knowledge and time, the paradox can be described in the following way: In the beginning of a product development project, the decision maker has high flexibility when making decisions, as no or few constraints are set. However in order to make informed decisions, the decision maker needs a certain amount of knowledge about the product. As the project has just recently begun it is quite probable that this knowledge has not yet been acquired. As the project progresses over time more and more knowledge is acquired, enabling more informed decisions to be made. However, previous decisions, which likely were less informed have imposed design constraints on the product, thus reducing the design freedom, Figure 2.1. This can lead to increased costs later on or even the need to re-take old decisions, which adds further to the lead time and development cost. The D-B-T philosophy relies heavily on building and testing of physical prototypes the development project becomes both time consuming and expensive. A second issue in the conventional product development process is that design and manufacturing tend to be disjointed. It is not uncommon that the product in question is adjusted to fit the available manufacturing processes after the final design has been released. Moreover, design changes at this stage tend to come with high costs and prolonged lead times and are thus undesirable [11], Figure 2.2 illustrates the cost of making changes at different stages of the development process. 7 2. Theory Figure 2.1: Illustrates the Design Paradox of product development. Figure 2.2: Illustrates the cost of implementing changes at different stages in the product development process. By restructuring the development process companies can save both time and money, Figure 2.3 illustrates just this. The index Cost/ECR (Engineering Change Request) is low during the design stage and peaks during testing. As the cost and complexity of implementing changes in later stages is high the product often becomes delayed. In order to make up for the lost time and deliver according to plan it is not unusual that product quality is compromised. According to Anderson [13] merely 8% is spent during the design stage. However, the decisions made determine 80% of the product lifetime cost. Thus making 8 2. Theory informed decisions early on becomes crucial for product lifetime cost, making the "right" decision in the design phase would lead to less ECRs later on, thus reducing product lifetime cost. Figure 2.3: Illustrates the Cost/Engineering Change Request in different stages of a conventional design cycle. 2.2 E-design E-design emphasises the integration of software and IT-related technology in product development. E-design itself is not a process which can replace the conventional product development process, rather it enables the use of concurrent engineering [14] through virtual and physical prototyping with a systematic and quantitative method enabling more informed decision making earlier in the design phase. In addition E-design excels at performance and reliability assessment, as well as improvement of complex, large-scale computation-intensive mechanical systems. [11] The E-design paradigm enables cross functional teams to simulate and design mechanical products concurrently in the early stages of development. This is done by introducing simulation and design tools earlier in the product development process. By intense use of simulation more product knowledge can be obtained early on, which enables the decision maker to make more informed decisions, thus increasing the likelihood that the "right" decisions are made. This leads to prevention or reduction of the “Design Paradox” phenomena described in Section 2.1, Figure 2.1. Ultimately the implementation of E- design leads to reduced development costs, as simulations can replace physical prototypes, and manufacturing costs, as issues are found and dealt with prior to production. By identifying issues earlier the number of late ECRs can be reduced, making it easier for engineers to deliver according the schedule while not forcing them to compromise on product quality. The E-design paradigm is heavily reliant on the advancement of computation time. With 9 2. Theory faster computation times more hardware tests can be replaced by computerized simulations, thus reducing costs and shortening the lead times even further. This can shift the Cost/ECR distribution, throughout the development process, as illustrated in Figure 2.4. The effect of the “Design paradox” can be reduced as more knowledge is obtained in the earlier stages of development, this is illustrated in Figure 2.5. Figure 2.4: Illustrates the shifted Cost/Engineering Change Request in a design cycle when using E-design. Figure 2.5: Illustrates the shifted design paradox by use of E-design. 10 2. Theory 2.2.1 The E-design Paradigm The E-design paradigm is comprised of the ares illustrated within white ellipses in Figure 2.6. The first iteration of a product is often based on the design engineers knowledge and experiences from previous projects. This knowledge and experience is highly desirable to capture and use as support for the current development project, as well as upcoming development projects. The ellipse named KBE (Knowledge Based Engineering), in Figure 2.6 represents this captured knowledge and can be used by other design engineers when developing new designs, both in CAD and CAE software [15]. Once the design is repre- sented by a CAD-model simulations regarding performance, reliability and manufacturing can be carried out concurrently, throughout the entire development project [11]. Figure 2.6: The white colored ellipses are the areas which are included in the E-design paradigm 2.2.2 Product Performance Analysis In order to replace much of the physical testing computerized simulations must be carried out in all areas which are covered by physical testing, this leads to quite a few different types of analysis. Some of which are explained in the list below and fall under the category Performance Analysis in Figure 2.6. • Motion Analysis - Simulations which include kinematics, rigid- and flexible-body dynamics and inverse dynamic analysis. These analysis’ can be used to evaluate packaging of a mechanical system, such as the wheel suspension. • Structural Analysis - By using finite elements a mesh which represents the model is created. The number of performance indices which can be evaluated is enormous. Some analysis types are linear static analysis, buckling analysis and fatigue analysis. • Fatigue and Fracture Analysis - Simulations are carried out using finite elements. Fatigue and fractures are a common occurrence in mechanical systems due to cyclic loading. • Product Reliability Evaluations - Evaluation of how often certain events could occur. An event could be how often a certain failure mode will occur. 11 2. Theory 2.2.3 Challenges Integrating CAD and CAE software is a complex task which software OEMs have begun working with in recent years. Several companies in various industries have found it more efficient, both time and cost wise, to develop their own interfaces using third party software. The list below summarizes the key challenges which must be overcome: • Consistency - One of the biggest challenges is to ensure consistency, between the CAD model and CAE simulation, throughout the product development cycle. If the consistency is not kept throughout, the simulations will be neither truthful nor useful. [11] • Configuration - Another challenge when creating the model is to ensure that the correct configuration is set. In the case of a kinematic analysis, this would mean ensuring that the joint types, force connections and reference system used match a corresponding physical test. [11] • Parametrization - In order to enable efficient exploration of several design alter- natives a parametrized CAD model is required. The CAD model is parametrized by defining a set of dimensions which control the entire model and by establishing relations between these dimensions. [11] • Stand-alone Software - Concurrent engineering requires simultaneous use of CAD and CAE, for design and analysis. Most commercial CAD and CAE software lack the ability to collaborate as they are stand-alone software. One reason for this is the depth required within each field. There is no universal solution which excels in all fields. There are even specializations within both CAD and CAE software [16]. One example of this is ADAMS/Car, described in Section 2.5, which is a CAE software developed solely for automotive analysis. • Data Handling - As most commercial CAD and CAE software are stand-alone data is built up and handled differently in each software. Thus information exchange be- tween different software is a rather complex task, often requiring in-house developed interfaces. [16] • Computation Cost - Depending on how the CAD and CAE integration will be set up the computing cost can be an issue. For example, setting up an autonomous opti- mization routine will required more computation time, increasing the computation speed would require more CPUs, which in turn would cost more money.[16] 12 2. Theory 2.3 Coordinate System & Rotations There are three types of Coordinate Systems (from her eon referred to as CS) which are used in CAD and CAE software; Cartesian, Cylindrical and Spherical [17]. Both ADAMS/Car and CATIA work with Cartesian coordinates as standard, however ADAMS/Car can be configured to work with any of the three. A point in a Cartesian CS is defined by the perpendicular distance to each axis, Figure 2.7. Figure 2.7: Illustrates the position of a point in the Cartesian coordinate system. In the XY-plane the perpendicular distance to the X-axis is the points position in the Y-direction, while the perpendicular distance to the Y-axis (also in the XY-plane) is the points position in the X-direction. The points distance in Z is defined as the distance from the XY-plane, when working, either in the XZ-plane or YZ-plane. The position of an arbitrary point can be expressed as in Equation 2.1: P = x̂+ ŷ + ẑ (2.1) 13 2. Theory 2.3.1 Rotation Sequences There are twelve types of approved rotation sequences [18, 19], these twelve can be divided into two groups of six depending on if two or three different axes are used for rotations. Euler angles use only two different axes while Tait-Bryan angles use three different axes. Academics argue about this categorization, some refer to all twelve sequences as Euler angles while others want to classify them as illustrated in Table 2.1. Table 2.1: Illustrates the twelve approved rotation sequences and how they are categorized into true Euler angles and Tait-Bryan angles. The rotation sequences are classified by the number of axes used during the rotation sequence. Euler Angles Tait-Bryan Angles 1-2-1 1-2-3 1-3-1 1-3-2 2-1-2 2-3-1 2-3-2 2-1-3 3-1-3 3-2-1 3-2-3 3-1-2 In order to understand the rotation sequences a global CS and a local CS (also referred to as body CS) must be defined. The axes of the global CS are denoted; x, y, z, while the axes of the body CS are denoted; X, Y, Z. Rotations may take place either around XYZ, xyz or both (in the scenario that XYZ and xyz coincide). A rotation sequence which takes place around xyz (the global CS) is called "an extrinsic rotation sequence", while a rotation sequence around XYZ (the local, or body, CS) is referred to as "an intrinsic rotation sequence" [18, 19], the later being the more common according to Boström [18]. Now that xyz and XYZ have been defined the rotation sequences can be explained. Below a 3-1-3 rotation sequence is explained 2.8. This is the sequence which ADAMS/Car uses as standard, the software can however be run with any of the twelve sequences. The Intrinsic 3-1-3 rotation sequence is referred to as an Euler sequence as only the X and Z axes are used for rotation, note however that this includes both x, X, z and Z, i.e. rotations can occur around both the global CS and the body CS. 1. The first rotation (ϕ) takes place around both Z and z as the two axes coincide, repositioning the x-axis and y-axis. 2. The second rotation (θ) takes place about the new x-axis (x’), repositioning the new y-axis (y’) and the z-axis. 3. The third rotation takes place about the new z-axis (z’), repositioning the new x-axis (x’) and the new y-axis (y”), these three steps are illustrated in Figure 2.8. 14 2. Theory Figure 2.8: Illustrates the order in which rotations take place around each axis in the Intrinsic 3-1-3 rotation sequence. The Extrinsic 1-2-3 rotation sequence is classified as a Tait-Bryan sequence as all three axes are used during rotation. This is the rotation sequence used in CATIA, Figure 2.9 • The first rotation (ϕ) takes place around the x-axis, repositioning the y-axis and z-axis. • The second rotation (θ) takes occurs about the original y-axis (y), repositioning the and the new z-axis a second time (z”). • The third rotation (ψ) takes place about the original z-axis (z), repositioning the new x-axis (x”) and the new y-axis (y”), these three steps are illustrated in Figure 2.9. Figure 2.9: Illustrates the order in which rotations take place around each axis in the Extrinsic 1-2-3 rotation sequence. 15 2. Theory 2.3.2 Rotation Matrices Rotations are, as mentioned, commonly represented by Euler or Tait-Bryan angles. The mathematical way of expressing the rotation of an object relative to a frame is by setting up a rotation matrix consisting of the three vectors. Thus obtaining a 3-by-3 rotation matrix [19], illustrated in Equation 2.2. Where the vector from the first rotation makes up the first row an so on. RotationMatrix = a1,1 a1,2 a1,3 a2,1 a2,2 a2,3 a3,1 a3,2 a3,3  (2.2) Every Euler and Tait-Bryan rotation sequence has a unique rotation matrix as the order in which rotations take place matter in 3D space [18]. Two of the most common are the 3-1-3 and the 1-2-3 sequences [18], which are presented below in Equations 2.3 and 2.4. As previously mentioned ADAMS/Car uses the Intrinsic 3-1-3 Euler sequence as default. R313(φ, θ, ψ) =  cφcψ − sφcθcψ cφsψ + sφcθcψ sφsθ −sφcψ − cφcθsψ −sψsφ + cφcθcψ cφsθ sθsφ −sθcφ cθ  (2.3) The 1-2-3 sequence is sometimes referred to as Cardan Angles. This rotation sequence is common in the aerospace industry and computer graphics. The Extrinsic 1-2-3 sequence, Equation 2.4, is the set of Tait-Bryan angles which CATIA is built upon. R123(φ, θ, ψ) =  cθcψ cθsψ −sθ sφsθcψ − cφsψ sφsθsψ + cφcψ cθsψ cφsθcψ + sψsψ cφsθsψ + sφsψ cθcψ  (2.4) 2.4 CAD: Catia CATIA is a CAD & CAE software developed by Dassult Systemes. The software offers an array of workbenches which support engineers in most stages of the product development process. From mechanical design, to structural simulation, to manufacturing. 2.4.1 Wireframe model The Wheel Suspension unit at Volvo Cars uses a kinematic wireframe model to explore hardpoint-setups in the early stages of development. The wireframe model is built up by hardpoints, which are defined joints positioned relative to the global axis system. Depending on where they are positioned the DOFs (Degrees Of Freedom) vary, some are completely locked while others have six DOFs. The wireframe model is thus a simplified model of the wheel suspension, referred to as an undressed model as no component 16 2. Theory geometries are included, Figure 2.10.The model allows design engineers to explore multiple concepts without investing too much time and effort, by allowing for quick adjustment of hardpoints without the need to modify any dressed geometry. For instance hardpoint 3, the joint between the LCA and Subframe, has the initial position (x,y,z), to explore different configurations design engineers can simply move this point to (xi,yi,zi) and preform a new kinematic analysis. Figure 2.10: Illustrates the wireframe model of the rear wheel suspension of the SPA platform in the S90 setup, courtesy of Volvo Cars. 2.4.2 Kinematic model A kinematic model, in CATIA, is a model which describes how a system moves and the components of the system relate to each other. In the initial development of a mechanical system it is often unclear how the system will behave and perform, the components of the system may clash and thus interfere with the overall system performance. The kinematic model allows design engineers to study the system and its behaviour in order to predict clashes and and evaluate system behaviour [11, 20]. Figure 2.11 illustrates the working procedure for setting up and running analyzes with a kinematic model in CATIA. In the first two steps, Product Model and Constraints, the design engineer positions and locks the components in their initial position. Once the components are connected joints between them need to be defined, the compo- 17 2. Theory nents will behave differently when motion is applied depending on which type of joint is used. Laws such as displacement limits, accelerations and other behaviour must also be defined. Joints are set in the third step, Mechanism and behavioural properties in the fourth step, Laws. Step five, six and seven, Simulation, Replay and Analysis consist of setting up displacement values for the simulation, running the simulation and creating a replay file. The replay file records the motion of the simulation, which enables it to be saved and replayed for further analysis. [20] Figure 2.11: Illustrates the work flow for setting up and running a kinematic analysis on an assembly in CATIA V5. 2.4.3 Replay Replay is an application within CATIA which allows the design engineer to create a "movie" from a specified set of motions. There are two ways to create a Replay in CATIA. The first, and most common way, is through a setting up a mechanism and simulation [21], this process is described in Section 2.4.2. The second way is through CATIA’s APIs, which can be accessed by running a script. The "Create Replay" script consists of two main parts. The first part of the script is handles declaration of which parts and products to include in the replay file. The second part contains all the specified movements, specified for each timestep. Movements are declared trough a combined rotation and translation matrix. CATIA operates using a 1-2-3 rotation matrix, which is described in Section 2.3.The structure of the "Create Replay" script is visualized in appendix B. Important to note is that, when the movement is executed, its not the virtual part object that is moved and rotated. Instead it is the part objects CS which is moved, this in turn moves the part object. So when a part moves 100mm from its origin, it is the axis system which moves 100 mm from its origin. In order to move the part an additional 100 mm the CS must be moved 200 mm from its origin, i.e the distance a part object is to be moved does not operate with ∆-values but with absolute values. See Figure 2.12 which illustrates how translations are handled. 18 2. Theory Figure 2.12: Illustrates how translations are handled in CATIA V5. Rotations are handled in the same way. That is, the object CS is rotated relative to its original position. Figure 2.12 illustrates how an object’s axis system is rotated around its Y-axis, relative to its origin, with the angle θ. Figure 2.13: Illustrates how rotations are handled in CATIA V5. 2.4.4 Envelopes An envelope is a representation of all positions which a component takes during a certain set of motions, i.e. the design space of that component. An envelope is usually visualized by a surface model in CAD software but may also be visualized as a diagram or a set of matrices. Envelopes are most commonly used for interference analysis and clash analysis [22]. In the context of the wheel suspension the most common envelope is that of the wheel. The wheel envelope is used to visualize the wheels movement during jounce, rebound and steering motions in combination with drive events such as break-in-pot-hole and drive-over-curb. A surface geometry of the wheel envelope is created, Figure 2.14, 19 2. Theory which allows the design engineer to check for interference and collisions within the wheel housing [23]. Figure 2.14: Illustrates a wheel envelope from a parallel wheel travel jounce and rebound simulation. 2.5 CAE: ADAMS/Car ADAMS (Automated Dynamic Analysis of Mechanical Systems) is a multi-body dynamics simulator developed by MSC Software®. ADAMS/Car is a package within ADAMS which enables virtual prototyping of cars. The package includes a number of modules which enable testing of the full virtual vehicle, both at system level and sub-system levels [24]. 2.5.1 Body Types ADAMS/Car offers four different kinds of parts when building a template. • Rigid Bodies - Cannot deform, have mass and inertia properties, are movable. • Flexible Bodies - Can deform when submitted to loads, have mass and inertia properties, are movable. • Ground Part - This part is static, it defines the CS and global origin, it is also used as a reference when calculating accelerations and velocities. The ground part must therefore exist in all models. • Mount and Switch Parts – Mount Parts are mass-less "place holders", which are replaced by other parts in an assembly. 20 2. Theory – Switch Parts are also mass-less, they act as switches for connections. By changing the switch part one part will connect to another. Flexible bodies are preferable, over rigid bodies, whenever component flexibility is believed to influence the system dynamics. Some of the implications for this thesis stems from the way the two component types are constructed and how component movement is logged. The movement of a rigid body is logged from the COG of the specific part, while the movement of a flexible body is measured by logging the movements of each node which the flexible body consists of. 2.5.2 Logging Data When running a simulation in ADAMS/Car it is often of interest to log the translations, rotations, velocities, forces and frequencies which certain components are subjected to. This is done by using Markers and Requests. A marker works like a sensor which logs any or all of the above mentioned parameters for a specified component, node within a component or set of nodes within a component. Logging data of individual nodes can be of interest when dealing with flexible bodies, the same goes for logging data from a set of nodes, thus obtaining a mean value. A request is used to extract the logged data from the marker, making it available for post-processing operations, either within ADAMS/Car post processor or for use in other software through the use of .txt-files, .xml-files or the .res-file, which is introduced in the next section. A request can be defined in three different ways: • By using type and markers - The user specifies if the request is to contain displace- ments, velocities, accelerations or forces. Further the user specifies the I marker (which marker tog log data from) and the J marker (which marker to log data relative to). • By defining a subroutine - The user may define a subroutine outside of ADAMS/- Car, e.g. in C, C++, Python or other programming language. The request calls the subroutine which may transform the logged data to a certain format or export it in a certain way. • Using function expressions- The user may specify an arbitrary function which transforms the logged data according to the users specifications. The standard output of a request is made up of eight slots of which four are reserved for translational parameters and four for rotational. Two of the slots are reserved for the translational and rotational magnitudes respectively while the remaining six can be defined as the user pleases. The user also has the possibility to modify all eight output slots to contain other data, such as accelerations, angular velocity or inertia to name a few. The process of placing a marker and defining a request is quite straight forward, Figure 2.15. All the work is done in the template builder mode, the user opens the templates which make up the assembly of interest and adds markers as explained above, thereafter the 21 2. Theory user defines requests which call the markers, also explained above. Finally it is important to save the changes in the template and close and re-open any active assemblies for the changes to take place. Load Template Place Markers Specify Requests Save Settings Figure 2.15: Illustrates the workflow of modifying the ADAMS/Car templates such that motion extraction is enabled. 2.5.3 ADAMS/Car .res-file ADAMS/Car produces, among other files, an output file of .res format. This file contains information about all components in the model and their behaviour during the simulation run. The .res-file begins by stating general information such as simulation date, solver, user, number of timesteps and units used. Thereafter the entities (which make up the model) are defined. Entities contain different information depending on their type, however every entity contains the following information classes: • Name - Entity name can be assigned by the user in the template builder. • Entity - States the original name, based on the structure in which the entity lies, if Name is not changed Entity will be the entity name as well. • Entity Type - States the type of entity, e.g flexible body, part or request, to name a few. • Object ID - Numbers the entities, numbering is performed for each entity type. 22 2. Theory Entities which contain motions also have an information class named Component. This class contains a certain motion, be it a translation, rotation, acceleration, etc. . . . Each component consists of three sub-classes: • Component Name - Self Explanatory, the name may be changed by the engineer who builds the template. • Units Value - Contains unit of the logged information. • ID - The ID states which position a certain components motion has for each timestep. To clarify, if a component, stating the translation around the x-axis for a certain entity, has the ID = 5629 then the motion will be the 5629th value stated for each timestep. The last, and largest part, of the .res-file contains the timesteps for the simulation, stated in order from 1 - n. Each timestep contains only the numerical value of each component for the given timestep, thus identifying a specific value can be tricky as there may be tens of thousands of component values. In order to put the size of a .res-file into context a simplified simulation run of one drive event with 10 timesteps takes up approximately 1100 A4 pages, containing approximately 12000 components. When "real" simulation runs are done the number of timesteps are increased tenfold, or more. 2.6 Wheel Suspension Theory In this section some key parameters for wheel suspension design are presented. For a description of different wheel suspension types see Appendix A. 2.6.1 Basic Concepts The Wheel Suspension is a vital system when setting the characteristics of a car, as it acts as the interface between the road and car body it influences both ride comfort, handling and safety. In order to understand how a wheel suspension system is designed there are some basic concepts which must be presented. When defining a system such as the wheel suspension a coordinate system is required. Most commonly used is the ISO 8855 coordinate system, Figure 2.16. Oriented from the driver position the x-direction is facing forward (the longitudinal direction of the vehicle), the y-direction to the drivers left side (lateral direction) and the z-direction heading upwards (vertical direction) [25]. The origin of the coordinate system has no fixed position and may be placed anywhere along the xz-plane. 23 2. Theory Figure 2.16: Illustrates the vehicle coordinate system as defined in ISO 8855 and DIN 70000 [25] Rotational motions around these three axes are referred to using separate names. Rotations around the x-axis are referred to as roll, rotations around the y-axis as pitch and rotations around z as yaw. Pitching motions (rotations around the y-axis) can be divided into dive, squat and lift. They take place during breaking an acceleration. Dive occurs when the nose of the car dips during breaking, simultaneously lift occurs at the back of the car. Squat occurs during acceleration, when the back of the car “sits down”, simultaneously lift occurs to the front of the car. Rolling motions take place mainly during cornering but are present in all situations where a lateral load is applied. Rolling motions occur around the vehicles roll-axis, which is obtained by drawing an imaginary line between the roll-centers of the two wheel pairs. The respective roll-centers are defined by two intersecting lines, one from the moment center of the wheel (seen from the rear) to the point of contact with the ground and the other through the center of the vehicle (draw vertically), thus the roll-center is positioned at the intersection between these two lines, Figure 2.17. However, note that as the center of the wheels moment is used to obtain the roll-center it will vary depending on the position of the wheels, as the center of moment shifts during e.g. jounce & rebound movements. 24 2. Theory Figure 2.17: Illustrates how the roll center of the vehicle is located. Yawing motions occur when the car rotates around its vertical axis, a scenario where this happens is be when the driver loses control and the vehicle starts spinning. All of these motions are desirable to control, both from a handing, ride and safety per- spective. The degree of motion which is desired varies depending on the targeted market segment, customer base and vehicle type. One factor which affects both pitching and rolling motions is the vehicle’s center of gravity (COG), by lowering the COG both dive, squat and roll can be reduced, which leads to better handling and thus also increases passenger safety [26]. Other factors which affect rolling and pitching motions are wheel- base and track width. The wheel base is defined as the longitudinal distance between the midpoints of the two wheel pairs, while the track width is the lateral distance between the midpoints of two wheels. Apart from counteracting pitching motions the wheel base also affects passenger space and handling. A shorter wheel base results in less room for passengers, but also increases maneuverability, e.g. when cornering or parking, and generally reduces weight and cost. By increasing the length of the wheel base there is more room for passengers and the ride is improved. The track width affects the handling, passenger space and aesthetics of the vehicle. By increasing the track width roll is reduced, thus increasing handling. Increasing track width also gives the car a more robust and luxurious appearance. Narrowing the track width leads to less stability, less packaging space and less room for passengers, therefore it is, in most cases, desirable to keep the wheel base as wide as possible.[26] 2.6.2 Wheel Suspension Parameters Even though steering is an important part of the wheel suspension it will not be treated in this report. The reason for this is the limitation to focus on the rear wheel suspension, where no steering is present. In order to meet the demands of today’s customers the wheel suspension must allow the wheel to move along a complex 3D trajectory during jounce & rebound. Vertical movements alone would not provide the necessary level of ride quality and handling. According to [26] the following five parameters are required to describe the wheel trajectory: Camber angle γ : The camber angle is the angle between the wheel center plane and the plane perpendicular to the ground plane, Figure 2.18. The camber angle affects lateral dynamics and by setting a slightly positive camber angle wheel wobble can be suppressed, 25 2. Theory however this is done at the expense of resistance to lateral forces. Race cars usually have a larger negative camber angle than ordinary cars in order to cope with cornering, as great lateral forces are applied when cornering at high speeds. The drawback with a high camber angle is asymmetric tire wear, due to the angle of the tire. Figure 2.18: Illustrates the camber angle. Roll Center: The point in the yz-plane around which the car rolls. If the roll centers of the two wheel pairs differ the roll center will be a mean between the two. Higher roll center reduces body roll as the distance between the roll center and COG is reduced, while a lower roll center reduces camber and track width changes during jounce and rebound. Toe angle δ & toe angle change: The toe angle is defined as the angle between the wheel center plane and a plane parallel to the xz-plane which runs through the wheel center, seen from above, see Figure 2.19 [25]. A slight toe angle is used to control handling, as the toe angle influences straight line driving stability, cornering behaviour and suspension tuning. 26 2. Theory Manufacturers also use the toe angle to compensate for elastic deformation while driving. Figure 2.19: Illustrates the toe angle, toe in when A < B, toe out when A > B. Note that the toe angle in this picture is greatly exaggerated for educational reasons. Camber angle change: During jounce and rebound the camber angle changes, thus influencing all the previously mentioned areas which the camber angle affects, it is desirable to control this change to the greatest extent possible. A theoretical example is straight line driving vs. cornering, during straight line driving a slightly positive camber angle suppresses wheel wobble, however a slightly negative camber angle improves the cars ability to cope with lateral forces which are present during cornering. 27 2. Theory 28 3 Methodology - Interface Design Between CAD & CAE This chapter is an integrated methodology and "execution of work" chapter where each challenge faced is treated separately. The chapter begins by presenting the current working process for packaging analysis of critical components in the wheel suspension. Thereafter the Pre-study is presented, followed by the Requirement study. The section on the Concept Development phase is initiated with a section describing the overall working methodology before treating the challenges faced, finally the chapter is concluded with a section about the Detail Design phase. 3.1 Current Working Process In order to understand where improvements could be made, the current working process for creating a packaging volume of critical components was mapped. Meetings were held with involved design engineers where the current process was presented and discussed, from these discussions the working process, visualized in Figure 3.1, was extracted. Figure 3.1: Illustrates the steps of the current working process for packaging of critical components. The process was carried out manually using generic rules, or tolerances, based on measure- ments and analyses, meaning that there were opportunities for improvements to be made both with regard to accuracy but also with regard to lead times. The data sheets received from the Vehicle Dynamics department had to be produced by customized runs where the model had to be modified in order to only include rigid bodies. Further the data from the analysis had to be summarized and visualized in an excel spreadsheet, which meant post-processing work for Vehicle Dynamics. A clear advantage would be to be able to use a compliant model (include flexible bodies and bushing stiffness) and read data from 29 3. Methodology - Interface Design Between CAD & CAE a standardized file format such as the .res-file which is automatically produced for every analysis, this way no post-processing work would be required from Vehicle Dynamics. The next three steps; Select Data Points, Create Design Table and Insert Components require the largest portion of time. As the data sheet from Vehicle Dynamics contains all specified drive cases for creating a packaging volume, for every drive line configuration, the content is quite vast. Manually selecting a number of data points from the data set is a time consuming task, adding to the amount of work is the fact that the task must be repeated for each drive line configuration. The selected data points are summarized in a design table, which is also set up manually. The design table is then used to acquire the location of each component at each measure point. This (inserting components) is the most time consuming step, a solid geometry representing each neighbouring component at each measure point must be created and inserted into the model. Once all components have been inserted for all five data points the component which is to be packaged can be treated. Those components which intersect with the component to be packaged are simply subtracted from it, producing the available packaging volume as a result. By automating this process the steps could be integrated in such a way that they require less time and effort, while producing a more accurate result. By supplying a tool, either within ADAMS/Car, CATIA or a third party software, which can read the result from ADAMS/Car, read the wheel suspension model from CATIA and allow motions to be mapped to components in the model improvements could be made within all three areas mentioned above. The time and effort required is reduced as the amount of manual work required is reduced. The accuracy is also improved as the generic rules can be replaced by actual motions transferred from ADAMS/Car. 3.2 Pre-study The pre-study was initiated by a market review where the purpose was to gain an un- derstanding of issues faced within the area of CAD & CAE integration as well as the state-of-the-art within the area. The second part of the pre-study involved learning the necessary software, this included specific CATIA modules and navigating in ADAMS/Car. 3.2.1 Market Review Both scholar articles, documents from Software OEMs and internal documents within the area of CAE & CAE integration were studied. This is a field which is currently experiencing rapid development. Two key drivers behind this is the need to reduce both development lead times and development costs [11], as explained in Section 2.2. To put the rapid development into context Waterman [27] describes how the ratio of engineers doing design or analysis has gone from six design engineers for every engineer doing analysis to 1.2 engineers doing analysis for every engineer strictly doing design. This means that more design engineers are performing analysis, although at a fairly simple level. The more complex analysis problems are left for the analysis engineers. So far much effort has been put on the transfer of CAD geometry to CAE software and 30 3. Methodology - Interface Design Between CAD & CAE how the data is handled to minimize information loss [11][28]. This process is handled by a so called "translator" which could be a stand-alone software or a module within a CAD software. The translator converts the CAD geometry to a neutral file format such as STEP or JT. Issues faced in this process range from more general cross-software communication issues such as information losses and data structure compatibility, to more specific issues such as the simplification of complex geometry to enable meshing and analysis [28]. The process of data transfer from CAE to CAD is a less explored area where Software OEMs just recently have begun developing solutions. There are however OEMs, both within the automotive industry and other manufacturing industries who have developed in-house solutions for this type of data transfer. The solutions are either integrated in the CAD & CAE software or developed using a third party software. The type of OEMs doing this are considerably larger than Volvo Cars and thus have the resources to develop their own software, tailored to their specific needs. 3.2.2 Software Study Training course material from Volvo Cars internal CATIA education was used to get acquainted with the kinematic workbench. The training included setting up and running a kinematic analysis, which included modelling of components, setting constraints, joints and laws. Thereafter specifying the desired motions and creating a replay-file for further analysis. Internal course material for ADAMS/Car was also used, in combination with expert consultation, to gain an overview of the necessary functions in ADAMS/Car. This involved setting up markers, requests, running analyses and handling the results. While executing the training exercises some features where identified which would need to be considered when designing the application. First of all the body CS’, in CATIA, are placed in the global origin by default but can be repositioned. However, a replay file is designed in such a way that all part CS’ are placed in the global origin. Consequently rotations will be amplified to an extent, depending on how far away from its CS the body is placed. The placement of the body CS’ must be considered when defining what data to extract from ADAMS/Car and how to extract it. I.e. the extracted data must match the movement of the body CS for a certain motion of the corresponding part. The reason for this is that a body is moved not by moving the body itself but by moving its CS. The fact that kinematics are involved means that great care must be taken in how motions are transferred between software. Rotations will need to be carried out in a certain sequence which matches the rotation sequence of the software, the theory behind this issue is described in Section 2.3. It will also be of importance that a single component can be assigned only one motion, otherwise CATIA will not be able to create a replay-file. It should however be possible to assign one motion to several components, if desired. 31 3. Methodology - Interface Design Between CAD & CAE 3.3 Requirement Study By the time that the requirement study was initiated it had become clear that the the most efficient way of developing a working methodology would be to develop an application which would automate cumbersome parts of the current working process. As the process of transferring data from ADAMS/Car to CATIA is both time consuming and has a low degree of automation this part of the process was chosen. There are various commercial translator software available which can connect CAE and CAD software in some way. Either through transferring data or handling the analysis in its own environment. Purchasing any of these software would involve corporate politics at the highest level and thus have large implications for Volvo Cars. Moreover purchasing a third-party software was not an alternative for this thesis as one limitation was to use currently available software licences. Instead three different environments where the application could be developed were identified, as seen in the list below: 1. ADAMS/Car. 2. Third-party software. 3. CATIA V5. . The environment selection was based on a set of initial requirements established in col- laboration with the project supervisor at Volvo Cars, Daniel Molin [23]. The initial requirements stated that the application must: 1. Allow for quick implementation. 2. Utilize the competence of design engineers within the department. 3. Not differ radically from the current working procedure, in terms of roles and tasks. 4. Add minimal work for the Vehicle Dynamics Department. 5. Preferably avoid increased costs due to new software licenses. Developing the application within ADAMS/Car would mean that information handling would be concentrated to one software, as wheel suspension movement during drive-events is simulated in ADAMS/Car. This would also mean that the precision would be high as no data conversion is required. However, it would also add to the workload of Vehicle Dy- namics, alternatively require design engineers who are used to working in CATIA to learn a fundamentally different software. Moreover this would require additional ADAMS/Car licenses which come at a high cost. Development in an ADAMS/Car environment would thus not fulfill requirements 2, 3, 4 and 5. Using a third-party software for data transfer, e.g. Matlab or Python, would enable utilization of specific features, e.g. Matlab’s excellence in solving mathematical equations. It would also allow for wide scale implementation across the company as these software can be integrated with most others. However, design engineers would need to learn new software and it is quite likely that more licences will need to be purchased, thus violating requirements 2 and 5. 32 3. Methodology - Interface Design Between CAD & CAE The third alternative is to develop the application within CATIAs VBScript environment. This would mean that the data transfer is handled by the design engineers in the Wheel Suspension department who will be working in an environment which they are familiar with. thus fulfilling requirements 2, 3 and 4. Working in CATIA also means that the required licences are already in place and that quick implementation is possible, thus fulfilling the remaining two requirements (1 and 5). As using a VBScript environment in CATIA fulfills all the requirements it was established that the application was to be developed in this environment. The next step was to set up a requirement specification and formulate the requirements. The layout of the requirement specification was influenced by Ulrich & Eppinger [29] and is based on seven columns with information: • Requirement Area - Lists the area which the requirement is derived from. • Requirement - States the title of the requirement. • Importance - Rates the importance of the requirement on a scale from 1 to 5. • Demand/Wish - States if the requirement is a demand (D) or a wish (W). De- mands must be fulfilled while wishes add extra functionality and increase customer satisfaction. • Description - Contains a short description of the requirement, where necessary. • Target Value - States just this, where applicable. • Verification Method - States how the requirement will be evaluated. The requirement areas were decided through dialogues with involved parties including design engineers, analysis engineers and representatives from the IT department. Based on the output from these dialogues the application was broken down into functional areas. The functional classification was selected as most of these functional areas can be devel- oped separately, with the exception of maintenance requirements which are implemented throughout. An alternative could have been to classify requirements by user group, however this approach would not fit the working approach with separate sub-system development as well. The functional areas from the breakdown are shown in in Appendix C and the list below: • Data Extraction from ADAMS/Car • Data Transfer • Data Insertion into CATIA V5 • User Interface • Post-processing • Maintenance Requirements were also gathered through close interaction with future users, both in 33 3. Methodology - Interface Design Between CAD & CAE the form of informal "hallway" meetings, formal meetings and a focus group meeting. The focus group meeting was structured as such that it begun with a short presentation of the planned application and its functional areas. Thereafter each area was discussed separately through an open dialogue, the authors functioned as moderators while also taking notes. In order to ensure that requirements from all user groups were gathered there were representatives from Vehicle Dynamics, The Wheel Suspension Group and IT-support present. The input from all of the meetings was analyzed and compiled into the requirement list seen in Appendix C. 3.4 Concept Development As this is a software oriented development project there are certain aspects which differ from a more conventional mechanical design based development project. One of the opportunities when developing software is the possibility of increasing the speed of design loops. This is possible due to two aspects. First off, writing and compiling code takes considerably less time than designing and simulating a set of load cases for an arbitrary component or system. Second, as no physical prototypes need to be built for testing lead times are reduced while no capital resources need to be tied up in producing and building of prototypes. This means that the number of design loops, including testing with quick n’ dirty prototyping, can be increased greatly. As design loops become shorter and integrate testing to a greater extent a structured work methodology which allows for this is required. The conventional product development process as described by Ulrich & Eppinger [29] has to some extent, influenced the overall structure of this master thesis, Figure 3.2. This is however a linear process, not very well suited for structuring the fast design loop iterations. Figure 3.2: Illustrates the working procedure which has been used during this master thesis. A method more suited for this task is the V-model [30], this method is based on a product breakdown using a top-down approach, sub-systems are then designed separately in integrated using a bottom-up approach. Applying the V-model to the concept development phase of this master thesis therefore meant that the application could be broken down at multiple levels. Sub-systems could then have separate design loops and be integrated when complete, Figure 3.3 illustrates the adaption of the V-model to this project. Initially Matlab was used for proof of concept during sub-system development, thereafter the sub-systems were developed in CATIA V5’s VBScript environment. 34 3. Methodology - Interface Design Between CAD & CAE Figure 3.3: Illustrates the breakdown of the application according to the V-Model [30]. This approach was used during the concept development phase of the project. The system, or application, breakdown was based on the functional areas established during the requirement study as these areas were easy to assign requirements to. Naturally the breakdown was structured in multiple levels, the application was first broken down into two domains: One which concerns the handling of data within the software and another which concerns user interaction and control. The application was then further broken down as illustrated in Figure 3.4. 35 3. Methodology - Interface Design Between CAD & CAE Application Data Handling Data Extraction Data Storage Data Acquisition Data Transfer Structure Data Read Data Data Insertion Apply Data to Model Graphical User Interface Pre- processing Infor- mation Selection Visual- ization MappingLoad Data Map Data Create Replay File Load & Save Settings Post- processing Visualize Data Select Data Select Measure- ments Figure 3.4: Illustrates the breakdown of the application. 36 3. Methodology - Interface Design Between CAD & CAE 3.4.1 Graphical User Interface All interaction between the user and the application is handled through the Graphical User Interface (GUI). This meant that user friendliness and layout structure were of great importance throughout the development effort. The intention was that the GUI should help the user not only to map motions from ADAMS/Car to CATIA instances but also to preview motion data and assist in post-processing operations such as data visualization. These functions are handled through the three tabs; Pre-processing, Mapping and Post-processing. In order to ensure a high degree of user friendliness a general structure, which all tabs were to be designed according to, was established. The general structure was set through discussions with the project supervisor who represented the design engineers of the Wheel Suspension department. Quite logically it was decided that the structure was to be based on that of a book written according to western customs, i.e. left to right, top to bottom. Further each step was to be enclosed in a numbered and labeled box. This may seem like an obvious way of structuring the layout but was nevertheless of great importance. An application with an ad-hoc GUI would add far less value to the customer and run the risk of being replaced or discarded quite quickly. 3.4.1.1 Mapping In order to be able to use the motions extracted from ADAMS/Car to control the model in CATIA the motions must be connected to their respective parts in some way. However, as previously mentioned there is a mismatch in the data structures between the two software. The motions are exported from ADAMS/Car within the .res-file whose structure is explained in Section 2.5.3 and Appendix D, for generating replay files CATIA uses the structure explained in Section 2.4.3 and Appendix B. Thus the data must be re-structured to fit the structure used in CATIA. This is done in the Mapping tab of the application. In order to perform the mapping operation four functions were identified as necessary. The user must be able to read the product tree from CATIA, import the .res-file from ADAMS/Car, map motions to instances and create a replay file. As an optional function, to further enhance user friendliness, the ability to save and load a set of mappings was added. Figure 3.5 illustrates the complete work flow, with both key functions and optional functions. 37 3. Methodology - Interface Design Between CAD & CAE Load saved mappings?Select .res-file Load saved mappings Select product tree Map motions & instances Save mappings? Save mappings Set name Create replay file No Yes No Yes Figure 3.5: Illustrates the proposed process of mapping CATIA instances to corresponding motions from ADAMS/Car. Figure 3.6 illustrates an early concept embodiment of the process illustrated in Figure 3.5. A step in the flow chart in Figure3.5 corresponds to a numbered box in the concept presented in Figure 3.6. The first step consisted of selecting and loading a .res-file from ADAMS/Car by browsing the windows explorer. Thereafter a product structure from CATIA was selected. The entire product structure, including all parts and products would be loaded. The instances and motions were, when loaded, visualized in the two curtain menus Instances and Motions. The mapping was carried out by selecting one instance, one motion and then pressing the Map button. When mapped the pair would appear in the Mapped Items box, but not disappear from their respective boxes. Once the desired components had been mapped the user would create a replay file by specifying and arbitrary name and pressing the Create Replay File button. 38 3. Methodology - Interface Design Between CAD & CAE Figure 3.6: Illustrates an early concept of the mapping tab in the GUI. Through testing and dialogues with future users it was soon realized that the mapping process was still time consuming, although not comparable with performing the task manually. As a product tree usually consists of a large number of instances looking up the right ones was time consuming. The same issue applied to the motions box, where only a 39 3. Methodology - Interface Design Between CAD & CAE fraction of the motions were of interest. It was therefore decided that some kind of filtering function was needed in both cases. Moreover the mapping became quite "click intense" as three clicks were required for mapping one pair, therefore it was decided that the mapping button was to be removed. This would mean that a pair would be mapped as soon as one instance and one motion were selected, thus eliminating one click. 3.4.1.2 Pre-processing During the mapping of instances and motions it could be of interest for the user to preview the motions in order to ensure that the correct data is selected. For this purpose the Pre-processing tab was developed, it allows the user to view a selected motion. Figure 3.7 illustrates the intended work flow. The .res-file which was previously loaded in the Mapping tab is transferred to the Pre-processing tab via a two-way link, this means that replacing the .res-file in the Pre-processing tab will also replace the .res-file in the Mapping tab. When the desired .res-file is loaded the motions can be screened in the same way as during the mapping process. Thereafter the desired motion is selected, the maximum and minimum value for each translation and rotation are illustrated, along with the timestep in which they occur. For further viewing there is to be a button which allows the user to export the motion to Excel where it can be plotted. The plotting was initially included in the GUI, however this solution was abandoned as VBScript does not support data visualization through plotting of a graph. 40 3. Methodology - Interface Design Between CAD & CAE Use loaded .res-file? Filter motions Load new .res-file Select motion View motion data Export motion data Yes No Figure 3.7: Illustrates the proposed workflow when using the pre-processing tab in the application. 3.4.1.3 Post-processing The Post-Processing tab allows the user to perform analysis on a replay file. The type of analysis which is of interest here is clash analysis, i.e to measure certain distances between instances during a replay. The original concept for the Post-processor was that the user would simply select the replay and the application would then automatically set up suitable measurements. However, due to limitations of CATIA’s ability to autonomously create and use measurements the Post-processor cannot be fully automated. Instead the user will need to set up the desired measurement manually. One benefit with this approach, compared to the fully automated one, is that the user gets a higher degree of freedom regarding the definition and use of measurements. The drawback obviously being increased lead time as the work must be done manually. However, since the engineers at the Wheel Suspension department already create measurements in their regular work the need for additional knowledge is not required. Figure 3.8 illustrates the working process for the Post-processor. Before the tab can be used, the user must create all measurements which could be of use during the clash analysis. Once the measurements have been created, the post-processor be used to analyze replay 41 3. Methodology - Interface Design Between CAD & CAE file. The user selects which replay file to be analyzed and imports all created measurements to the application. The user then selects which of the measurements he or she wants to include in the analysis. Once the replay file and the measurements have been selected the analysis can be performed. The application runs through the replay file and stores all measurement values for each timestep. After the analysis is complete, the user can view certain values directly in the application. The user can also export the data to an excel sheet for further analysis. Create measurements manually Select replay Import measurements Select measurements to analyze Run replay and log measurements Visualize the analysis Export analysis results Figure 3.8: Illustrates the proposed workflow of the Post-processing tab. The first step is carried out manually outside of the application, while the rest of the steps are handled from within the GUI. 42 3. Methodology - Interface Design Between CAD & CAE 3.4.2 Data Handling As the application will be based within CATIA, there are some basic functions which will be required. First the data from a drive event simulation must be extracted from ADAMS/Car. Second, the information needs to be transferred to, stored, and organized in CATIA so that it can be handled by the application. Third, the application needs a function which converts the data from the format used in ADAMS/Car to the format used in CATIA. These three functions will be described further in Sections 3.4.2.1 Data Extraction, 3.4.2.2 Data Transfer and 3.4.2.3 Replay File Generation. 3.4.2.1 Data Extraction The first step in transferring data between ADAMS/Car and CATIA is to extract the desired data from ADAMS/Car. In order to do this, one must establish which rotation sequences and data structures the software use. As mentioned in Section 2.5 and further explained in Section 2.3 ADAMS/Car uses an Intrinsic 3-1-3 rotation sequence by default while CATIA works with an Extrinsic 1-2-3 sequence, explained in Section 2.3. Moreover the replay model is built in such a way that the body CS’ are placed in the origin. This leads to a data mismatch between the two software. The motion of an arbitrary component relative to the origin cannot be used to control the replay model in CATIA. Using these motions would move the body CS along the same trajectory as the component moves. This would be fine as long as only translational movement is present, but as soon as rotations are introduced these motions become obsolete. The introduction of rotations lead to a mismatch as the body CS’ are placed in the origin and not 4000-5000 mm away (as is the case for the rear wheel suspension in the x-direction). Consequently, the distance from the origin to the arbitrary component will work as a lever, distorting the components movement, as illustrated in Figure 3.9. Figure 3.9: Illustrates how a rotational movement changes the position of the wheel suspension with a lever effect. 43 3. Methodology - Interface Design Between CAD & CAE In order to extract motions which can be used for controlling the model in CATIA one must thus extract the motion of the arbitrary components thought body CS in ADAMS/Car. That is, logging the motion in ADAMS/Car such that is corresponds to the movement of the components body CS in CATIA. The issue here is that there is a mismatch between the placement of the body CS’ in the two software, as body CS’ in ADAMS/Car are not placed in the origin which is the case in CATIA. However, this is not the only issue at hand. One must also ensure that the extracted motions use the correct rotations sequence, which in this case is Extrinsic 1-2-3 rotations. The conventional way of logging and extracting motions from ADAMS/Car is through placing a marker on a node of the component of interest and then specifying a request for the motion of the marker, this process is described further in Section 2.5. By doing so the motion of the specific component, relative to the origin is obtained. As mentioned these motions are not of any use due to the lever effect. However, by modifying the marker such that it is placed in the origin and connecting it to the component of interest with a rigid axis the lever effect can be taken advantage of. This means that the motion obtained is that of the thought component body CS, as it is placed in CATIA. As the model is kinematic, an arbitrary node on the component of interest can be used to log the motion. In order to implement this way of logging motions Vehicle Dynamics must update all affected templates with the modified markers, this is however a one time task and not repetitive work. Even-though the correct motions can now be logged they must still be transformed to the correct rotation sequence. When specifying a request ADAMS/Car offers two standardized ways of exporting rotations. These are as Intrinsic 3-1-3 rotations or Extrinsic projected 1-2-3 coordinates [31]. However, through writing a script which is called by the request motions can be extracted on any of the 24 available rotation sequences. Once this feature was discovered the necessary script was developed in collaboration with MSC Software. The script which was written in C is called upon by the request, thereafter motions are transformed from Intrinsic 3-1-3 rotations to Extrinsic 1-2-3 rotations and stored in the .res-file in this format. The script was written in C partly because pre-defined conversion functions could be called from ADAMS/Car and partly due to the ease of implementation and maintenance. Volvo Cars already use similar scripts in other areas of its development work, consequently the company already has employees who are responsible for such scripts as well as defined processes for how to implement and maintain such scripts. The script would be compiled and maintained in a central database together with other similar scripts. Now that the correct motions are logged and stored in the .res-file the next step is to transfer the data from there to CATIA. 3.4.2.2 Data Transfer Since the application is developed in CATIA the data must be transferred from ADAMS/- Car’s .res-file into CATIA, in order to be stored and re-organized. However, CATIA does not currently support the .res-file format. One way to solve this problem is to let CATIA read the .res-file as .txt file, by doing so each line will be handled as a separate string. The requested data can then be extracted from the strings. This solution has both pros and cons for the functionality of the application. 44 3. Methodology - Interface Design Between CAD & CAE One advantage with extracting data line by line is that the application will be robust with respect to file sizes and what types of information the .res-file contains, as long as the general structure is the same. Another advantage is that adding more functionality for extracting other types of data will be simple. The only thing that needs to be added to extract additional data is a case that defines what happens to this additional data. Reading the file line by line also enables other engineers, without deep programming knowledge, to study and understand what is happening in the code. There are however some disadvantages to reading the file as a .txt file, one of these is the sensitivity to structural changes in the .res-file. As all the extracted data is dependent on the string of information and the declaration structure which the .res-file uses. If the declaration structure is changed, e.g. through a patch, the application may no longer be able to read the .res-file and extract the requested data. Thus, if the declaration structure is changed the application will need to be updated to be compatible with the new declaration structure. Depending on the extent of the changes in the .res-file the application may only need an update of certain indices and names, however if the whole structure of the .res-file is changed it is likely that the application will need to be re-written completely. Another disadvantage is that this method is relatively slow compared to other methods for data extraction from a file. But for this application, that speed reduction will have minimum effect for the user. It would be more efficient to optimize the code than to use another extraction technique. One final disadvantage, which can also be an advantage depending on whose perspective to take, is that by the selected method for extracting data is bi-stable, i.e. it either works or it does not. This is an advantage from a maintenance perspective as it becomes clear when changes need to be made. it is also an advantage in the sense that the user will not be able to extract the "wrong" information. The pros and cons of extracting data by reading each line as a string are summarized below. + Robust against file size variation. + Simple to add additional functions. + Easy to study. + Either it works or it doesn’t. − Dependent on name structure. − Relative slow process. − Difficult to update to new structure. − Either it works or it doesn’t. The process of reading and extracting data from the .res-file can be divided into the three main steps which are illustrated in Figure 3.10. In the first step it is declared how the extracted data will be stored and organized. The declaration also defines which data will be extracted based on the mapping that the user has declared, the mapping process is explained in Section 3.4.1.1. The second step is to obtain the IDs for all requested motion values. This is done so that the application knows where in the .res-file the motion values are located, for a description of the .res-file structure see Section 2.5.3. The third and final step is to extract the actual motions values from the .res-file and store them at the declared location within the application. The remaining text in this section explains the three steps illustrated in Figure 3.10 in greater detail. 45 3. Methodology - Interface Design Between CAD & CAE Declaration Get IDs for values Get values Figure 3.10: Illustrates the general process for transferring data. The first step in the main process is to declare where and how the extracted data will be stored and how it will be organized. The first step in the declaration process is for the application to receive a list stating which data to extract. The list has been defined by the user when mapping instances to motions, see Section 3.4.1.1. Each item in the list contains one instance, from CATIA, and one motion, from ADAMS/Car, which will be connected. The instance and its motion are extracted, for every item, and then used to create a class which can hold all the extracted data from the .res-file. After all items have been read and their corresponding classes been created the ID and other general information from the .res-file can be extracted, Figure 3.11 illustrates this sub process. 46 3. Methodology - Interface Design Between CAD & CAE Get list of mapping Read item Get part or prod- uct from item Get motion from item Create class Last item? Get value IDs Next item No Yes Figure 3.11: Illustrates the first step in the data transfer process. Where and how the extracted data will be stored. The extraction of the IDs and other general information is based on reading each line of the file as a string of information. The application loops through what essentially is an IF-statement for each line in the .res-file. When one line has been read, the code first checks if this is a valid line to extract data from?. Weather this statement is true of false depends on which motions the user has mapped. Apart from the validity check of the line, the application also checks what kind of information can be extracted. There are two types of information that can be extracted. Case A is that the motion name, object type and motion ID are extracted. Case B is that the ID for a translational X, Y, Z or rotational Psi, Theta and Phi value is extracted. When all lines in the .res-file have been read the .res-file will be read once mor