Publisher: LuK GmbH & Co. - Schaeffler Group · 2019-05-24 · Foreword Innovations are shaping our future. Experts predict that there will be more changes in the fields of transmission,

Publisher: LuK GmbH & Co.Industriestrasse 3 • D -77815 Bühl/Baden

Telephon +49 (0) 7223 / 941 - 0 • Fax +49 (0) 7223 / 2 69 50Internet: www.LuK.de

Editorial: Ralf Stopp, Christa Siefert

Layout: Vera WestermannLayout support: Heike Pinther

Print: Konkordia GmbH, BühlDas Medienunternehmen

Printed in Germany

Reprint, also in extracts, withoutauthorisation of the publisher forbidden.

Foreword

Innovations are shaping ourfuture. Experts predict that therewill be more changes in the fieldsof transmission, electronics andsafety of vehicles over the next15 years than there have beenthroughout the past 50 years. Thisdrive for innovation is continuallyproviding manufacturers and sup-pliers with new challenges and isset to significantly alter our worldof mobility.

LuK is embracing these challen-ges. With a wealth of vision andengineering performance, ourengineers are once again provingtheir innovative power.

This volume comprises papersfrom the 7th LuK Symposium andillustrates our view of technicaldevelopments.

We look forward to some intere-sting discussions with you.

Bühl, in April 2002

Helmut Beier

Presidentof the LuK Group

Content

LuK SYMPOSIUM 2002

1 DMFW – Nothing New? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Torque Converter Evolution at LuK . . . . . . . . . . . . . . . . . . . . . . . 15

3 Clutch Release Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Internal Crankshaft Damper (ICD). . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Latest Results in the CVT Development. . . . . . . . . . . . . . . . . . . . 51

6 Efficiency-Optimised CVT Clamping System . . . . . . . . . . . . . . . 61

7 500 Nm CVT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8 The Crank-CVT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9 Demand Based Controllable Pumps. . . . . . . . . . . . . . . . . . . . . . . 99

10 Temperature-controlled Lubricating Oil Pumps Save Fuel . . . 113

11 CO2 Compressors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

12 Components and Assemblies for Transmission Shift Systems135

13 The XSG Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

14 New Opportunities for the Clutch?. . . . . . . . . . . . . . . . . . . . . . . 161

15 Electro-Mechanical Actuators. . . . . . . . . . . . . . . . . . . . . . . . . . . 173

16 Think Systems - Software by LuK. . . . . . . . . . . . . . . . . . . . . . . . 185

17 The Parallel Shift Gearbox PSG . . . . . . . . . . . . . . . . . . . . . . . . . 197

18 Small Starter Generator – Big Impact . . . . . . . . . . . . . . . . . . . . . 211

19 Code Generation for Manufacturing. . . . . . . . . . . . . . . . . . . . . . 225

WESTEV

19 Code Generation for Manufacturing. . . . . . . . . . . . . . . . . . . . . . 225

225LuK SYMPOSIUM 2002

Code Generation for ManufacturingThe Electrical Central Release Bearing Software

Reinhard Ludes, AFT WerdohlThomas Pfund

19

19 Code Generation for Manufacturing

226 LuK SYMPOSIUM 2002

IntroductionSoftware plays a very significant role in auto-motive technology these days (figure 1).

Particularly in the vehicle itself, the numberand importance of mechatronic systems,which possess a high degree of integration ofmechanical and electronic software-basedfunctions, have increased markedly. The soft-ware here performs automatic control func-tions or automates behaviour previously per-formed by the driver.

The systems’ functionality is growing increas-ingly more complex, and this complexity ofsystem behaviour, as a result, is continuouslyshifting to the software. While more and moreplatforms are being used in the area of me-chanical and electronic hardware, evenacross brands, the tasks of individualising thesystem and the vehicle’s characteristics areincreasingly being given to the software.

This trend is supported by the apparent easewith which the software can be modified. It isalso encouraged by the emergence of high-performance processor systems, which arenot only becoming more and more affordable,but are offering ever more functions and in-creased storage space. This is an irresistibletemptation for ambitious development teams.

But what is often overlooked is the fact thatmore and more effort must be invested in soft-ware specification, implementation and test-ing and the validation of the entire mechatron-ic system, both on the test-bed and in the ve-hicle.

The reason is that the different methods ofgenerating software have not kept pace withthe demands made on software systems.They have also not kept pace with the com-plexities created or caused daily by large de-velopment teams.

Of course there is and has been progress inprogramming languages: a number of testingmethods have been established to optimisethe generation process and language exten-sions like object-oriented programming(OOP), which are also slowly becoming es-tablished in the area of real time programming.The fact remains, however, while it is makingsignificant contributions to control and auto-mation, software itself is generally still writtenby hand. Software development is thus still aclassical manufacturing process.

The present project takes an alternative routein developing the software for an electricalcentral release bearing. Using TDC, the ab-breviation for Total Development Chain, byAFT (Atlas Fahrzeugtechnik), the requiredcontrol software is generated automatically. Afull description follows.

Fig. 1: Software in Automotive Technology

software in automotive technology

control& automation of functions, tasks and procedures

in the vehicle:

• automatic control functions injection, ignition, engine management, ABS, ASR, ESP, etc.

• automation clutch (TCI), transmission (ASG)

in development& production:

• methods& tools CAD, CAE, CAM

• automation robotics



The Standard Development Process for SoftwareThe standard process for developing softwareis outlined in the section to follow. Naturally,there are many variations, but we will mentiononly the major and generally typical steps here(figure 2).

First, the control strategy is formulated basedon an idea. This can be accomplished by writ-ing a performance specification for the controlstrategy. An advanced procedure includes thespecification and all types of detailing of thecontroller design using a simulation program,where its structure and configuration is con-tinuously improved based on models. The ad-vantage of this method concerning writtenspecifications and drafts, is that it is easy forprofessionals specialising in different areas,such as systems analysis, control and simu-lation to discuss the control unit model.

Once the control or automation function – atleast in the area of simulation – has reacheda sufficient level, in the classical method, it isnow the software expert – whose qualifica-tions come from the area of real-time softwareand microcontroller design – who is ultimatelyresponsible for the implementation.

The basic controller concept is the beginningof a software expert’s work. They must alsofirst analyse the task given to them and createan appropriate design concept for the real-time system before they can even begin tothink about implementation, i.e., translatingthe functions into concrete code. The reasonfor this break, or gap in the process, as canalso be seen in the diagram, is the existenceof different points of view, which are ex-pressed in different model approaches.

In controller design, the main consideration isthe object to be controlled, such as, in the cur-rent case, the control motor as the actuatorand the clutch as the controlled system.

Fig. 2: Standard Development Process for Software



Fig. 3: AFT TDC in the Development Process

All models are oriented in this way. In real-timesoftware design, as in any other software de-sign, the architecture of the computer or mi-crocontroller system is the main issue. Themodels used as the basis are thus primarilyoriented toward the standard architecture ofcomputer cores or processors (Von-Neumannmachines), and all standard procedural pro-gramming languages are designed on this ba-sis.

The severity of this break is different, and de-pends on the languages and methods used.The break is, however, part of the basic natureof the task. Only object-oriented programmingshows a way to eliminate this.

There are several approaches for workingaround this break. Above all, the effects de-pend on the development process; how wellthe communications between the two basicdeveloper types work.

At LuK, for example, we have been successfulin providing both qualifications at the sametime in the team or with individual developers.In addition, code segments are transferredfrom the offline simulation to the source codelevel in the control software.

Code Generation in the Development ProcessIn this project, we have taken the road of au-tomatic code generation. The code generatorused here takes the controller’s model, or sim-ulation-based specification, and generatesclose-to-production real-time code for the mi-crocontroller in the automotive control unit.This is therefore a seamless path; from thespecification of the general, to the detailedstrategy, to the real-time code in the controlunit (figure 3).

This approach is in line with LuK’s philosophyof using only one expert or group of expertsto design and implement the entire system. Itis also the system engineer who designs thecontrol unit in the classical method. Theknowledge of how to generate the optimumcode is implicitly present in the code genera-tor. The functions relating to the vehicle or oneof its components are thus kept in mind fromthe beginning on. The processor, the pro-gramming language and the operating systemthat are used in the concrete application re-main in the background.



The break in the specification or the entire de-velopment chain is overcome.

Using TDC in Electric Central Release Bearing Engineering: The Closed Tool ChainThe use of the AFT TDC means more than justusing a code generator. TDC reflects a heter-ogeneous, but closed chain of tools, whichsupports the entire development process.Heterogeneous, because different tools areused together – in fact the exact tools that arebest suited for the specific project. Closed, be-cause the results of the test are fed back in toimprove the original model in a gradual evo-lution (figure 4).

In this project, we used MATLAB®-Simulinkfor simulation, TargetLink for code generation,AFT PROST as a suitable prototype controlunit, and MARC I for recalibration in the test

phase. It is also worth noting that this data,which is used for calibration, i.e., fine-tuning,is already specified in the simulation software.For the calibration system, description filesare also generated (according to ASAP 2),which are automatically read into the calibra-tion system. The test engineer therefore doesnot need to perform any additional configura-tion to his calibration system.

The data obtained during the calibration canalso be worked into the simulation model forfine-tuning the model. Furthermore, the meas-ured data obtained in the test can be fed backinto the simulation from the calibration systemor from additional installed measuring sys-tems. The dataloggers RAMboX™ andTORnadO® are available at LuK for this pur-pose and are currently in use.

Finally, only the code generator and a seriesof expansions to the calibration system hadto be installed in addition to be able to formthe development chain as described. All ad-ditional tools were on hand and known to thedevelopers.

Fig. 4: Characteristics of AFT TDC: Example – LuK Electric Central Release Bearing



The Electric Central Release Bearing Project as Reflected in the V ModelAs indicated in the previous illustration, TDCreflects a development method that goes be-yond pure code generation. It is a simulation-based development method with executablespecifications. The entire chain is based on theV model. Figure 5 shows the implementation ofthe V model with all components that are usedat AFT to develop software for control devices.

The following are characteristic of the V modelas the basis of the development strategy:

� Each design step on the left has a corre-sponding test and validation step shown op-posite on the right.

� Transfers and tests are required betweenthe steps on the left side to ensure that thespecifications given in the previous step arealso fulfilled.

� This also means that the later an error is de-tected, the more steps must be rerun duringthe redesign, i.e., the more difficult and ex-pensive correction becomes. Basic specifi-cations that are not or are improperly met,which can then be discovered only in the fi-nal step, are thus especially critical.

The left side shows the two significant designsteps:

� Specifications phase – the system specifica-tions are made to provide clear definitions, insome cases based on the simulation mod-els and automatic condition generators.

� Model generation – based on the systemspecification and any existing partial mod-els, a structure that can be simulated is gen-erated, embedded in a more or less exactplant model.

Both steps use MATLAB® SimuLink, first forthe rough system structures and specifica-tions and in the second step, the entire modelof the control unit and controlled system is de-fined in detail.

Fig. 5: Electric Central Release Bearing Project Reflected in the V model



The process ends in the peak of the V modelwith auto-code generation on the specific tar-get system. Thus the original control unit spec-ification is not only executable in a simulatedenvironment, but also on a control unit as thetarget system. The entire chain is continuous.

On the right side, across from the two designsteps are the corresponding test and valida-tion steps:

� Model-verification, i.e., validation of the ba-sic control function, in the SIL simulation(SIL = software in the loop) or if applicablealready in a HIL system (HIL = hardware inthe loop).

� Total system verification on the test stand ortest section.

The controller is first tested in an SIL simula-tion. In the SIL simulation, all interfaces to thespecified software are depicted as models, sothat the simulation can run without any addi-tional hardware expense. The system sup-ports this process in that the I/O interfaces tothe controller – operating system are availableas TargetLink – blocks and that a simulationis possible both with floating decimal and fixeddecimal arithmetic.

A HIL system is used for model verificationwhen individual components of the controlledsystem cannot, or can only with great effort,be represented in the simulation environment.However, at the same time a test in the entiresystem, e.g. due to high application expense,is not or not yet economically feasible. It mustalso be decided on a case-by-case basiswhich parts in the controlled system must bephysically present and which can be repre-sented as a software model.

No decision must be made for the control unit,whether it will be ‘operated’ for real or in thereal-time simulated controlled system. It isworth noting that in this simulation-based de-velopment process, the system model re-quired for the HIL simulator is largely alreadyavailable from the system specification step.In the project described here, the main partialsystems were installed on a test stand (centralrelease bearing against non-rotating clutch,

PROST control unit and higher-level TCI con-trol unit).

The system verification is based on the overallsystem design. If the behaviour of the clutchis determined in the vehicle, the validationmust also be completed in the vehicle or in avehicle-adequate system environment. In thiscase too, the final verification was performedin the vehicle.

Thus, all stations of the V model were run inthis project.

Additionally, the measured data that was ob-tained in the control design stage and in thefinal test was fed back.

Results, Part I: The Controller StructureThe specification of the controller consisted atfirst consisted of the initial rough blocks, whichwere then filled out in refinements and param-eter configurations. The blocks can be outputgraphically directly with their links (signalpaths) and thus can support an optimal spec-ification and documentation:

� the target and actual value calculation forthe controller

� the condition controller as the core

� the pre-control to raise the adjustment dy-namics

� the logic, which differentiates different basicconditions (e.g. normal, ‘limp-home’ and testoperation)

� the follow-up functions, which encompassdifferent engagement and disengagementprocedures

� the block ‘set outputs’ for checking limit val-ues and adjusting to the hardware

� the block ‘measured values on CAN’ as acontrol function during the test phase

A graphic display will be created automatical-ly. The integration at this point, however, issuch that it is far too extensive and detailed.Each block can be further broken down to



show more detail. The controller as an entiresystem is once more a block in the entire of-fline simulation model, in which the remainingcomponents of the controlled system are rep-resented: end stage, electric motor, the beltgears and the clutch itself.

Since the controller’s specifications finally endin a controller model that can run both ‘against’the model of the controlled system in the sim-ulation and after code generation in the controlunit ‘against’ the real controlled system, it isan executable specification.

When the controller is in a real control unit aftercode generation, the generated software ac-cesses the same input and output interfacesas it already showed in the model. The inter-face to the system software then makes up theAFT controller interface (ACI).

Results, Part II: Savings PotentialThree man-months were originally planned togenerate the controller for the electric central re-lease bearing: to design the simulation, imple-ment the code and for initial testing. The projectwas completed two weeks after the project’sstart using the new method. The new methodalso required a total of three man-months.

No control group was defined, which solvedthe same problem using conventional meth-ods. There is, however, sufficient experiencewith the definition and execution of suchprojects, that we can assume that approximate-ly the same amount of work was required.

Some of the effort certainly went into breakingin the new tools. The first decision was madeafter two weeks to change the method whichcost a few extra hours, since the simulationmodels had to be readjusted to the real-timerequirements.

It is estimated that the development time fortrained employees can be reduced about 50%to 1.5 man-months. This results first from ananalysis of the time records and secondly fromthe back-calculation: According to experi-

ence, 1.5 man-months are required to writethe coding for the controller, including testingand configuration of the calibration system, anexpense that is eliminated with the new method.

The possible ratio effect is thus a good 50%and results from eliminating the generation ofthe controller code and the time used for fine-tuning in the test phase, which is required toconfigure the calibration system.

It should be mentioned that validation steps re-quired for production release (functional contin-uous operation, code inspection, etc.) were notincluded in the time estimate. If these were takeninto account, the ratio effect would be reduced.

It is very important to establish at this point thatthis is not a purely functional representation ona high-performance automotive test system.

The AFT PROST prototype control unit includesa standard microcontroller with fixed-point arith-metic, suitable for production. Likewise, the gen-erated code is transferable to a conventionalproduction unit without any great effort.

This design, because it is closer to productionthan other systems that are based on high-performance floating-point processors andonly allow a functional depiction in a prototypevehicle, is thus far superior.

Answers to Frequently Asked Questions

What is the Source of the Ef-fectiveness of the Code Generator? What is it Based on?The effectiveness is based on the executiontime of the generated code. It is between 0.9and 1.2 times that of hand-written code, ac-cording to the manufacturer’s specifications.This is an excellent amount, since previouscode-generators generated code with 2.5 to3 times the runtime. Even in the worst casescenario, 20% additional runtime is absolutely



acceptable. It requires approximately thesame memory space as hand-written code.

This information was not tested in the courseof this project; the same tasks would have hadto be performed by experienced programmersat the same time. However, the runtimes andfile sizes are within the expected ranges.

There are essentially three reasons for thisrun-time efficiency:

First there is the use of special codes of thetarget processor that are not available to Cprogrammers. Second, the code generatorimplicitly has much special knowledge of theefficient programming of the target processorand the operating system environment used,which a code-writer would first have to pains-takingly establish. Furthermore, with properhandling of the tools, the variables are scaledto the value range used. This allows the useof favourable multiplication and division oper-ations, which would otherwise require a greatdeal of time. The scaling can be done auto-matically or by indicating the value range.

Is the Generated Code Readable?The code is readable. Variable names are like-wise taken over in a changed, but readable

form. A prefix or suffix is simply added to con-nect the data structure with the higher-levelsystem structure.

Certainly this question is related to the fact thatthere is a certain level of mistrust on the partof developers with regard to generated code.Even code generated by high-level languagecompilers is not generally subject to inspec-tion by the developers.

How Can I Work with Projects that Go Back to Existing Code?AFT TDC has particular advantages over oth-er development tools in this area: There aregenerally three sources (figure 6):

1. Code generation from the SimuLink mod-els as previously described.

2. Adding hand-written code in addition.

3. The option to integrate code from otherprojects.

In all cases, if the conventions are followed,even the parameter-setting for the calibrationsystem, i.e. the description data of the controlunit, can be generated.

Fig. 6: An Advantage of AFT TDC: Code Mixing



To What Extent is the Gener-ated Code Suitable for Production?As mentioned previously, the code is nearlyproduction-ready, since it is generated for con-ventional microprocessors as the target sys-tem. The function unit used – the automotiveprototype control unit AFT PROST – is like-wise close to production-ready. The resultsare thus transferable to the subsequent seriesdevelopment 1:1.

Summary and OutlookFigure 7 summarised once more the generaladvantages of a closed development chainand the specific advantages of AFT TDC.These advantages originate from the typicalcharacteristics, also shown.

The development of the central release bear-ing software was a pilot project, which the per-formance capabilities of the AFT TDC for thedesign and generation of the control unit pro-duction code covered. At LuK Bühl, the currentthinking is, after this pre-development project,to also run a pilot project in production devel-opment.

Other AFT projects have been completed suc-cessfully in the past. These include projectsfor DaimlerChrysler research, who – after ap-propriate training of their employees – havesince used the same tools and methods fortheir own development projects.

AFT carries out other projects as engineeringservice, using AFT TDC as the method andtool to complete projects quickly and cost-ef-ficiently. These also include the developmentof control unit software for LuK-FH in BadHomburg.

Fig. 7: Summary

summary

general features of TDC: general advantages of TDC:

• General simulation-based development pro-cess from initial design to implementation, including all test phases (SIL, HIL, applicati-on and testing)

• High-level design (model-based graphics)• Executable specification• Implicit documentation• Expertise real-time system, partially in code

generator

• shorter development times• reduction of possible error sources• cost-reductions• shifting the required expertise to the system

engineer• tested intermediate results in each develop-

ment step

basic characteristics of AFT TDC: specific advantages of AFT TDC:

• Heterogeneous system• Combination of the best components that

have proven themselves as standard:MATLAB®/SimuLink®, code generator by dSPACE, MARC I, RAMboX™, TORnadO®

• adaptable to changing standards• can be integrated into existing projects:

combination or mixture of hand-coded and automatically generated code

• adaptable to individual requirements by combining for the customer

• production-ready code

This book7th LuK Symposiumis intendend only for your personal use!

Documents

Publisher: LuK GmbH & Co. - Schaeffler Group · 2019-05-24 · Foreword Innovations are shaping our future. Experts predict that there will be more changes in the fields of transmission,