Kollo2002 e.book Seite 217 Mittwoch, 6. März 2002 5:26 17 · ployees. The software development team at LuK is composed equally of mechanical engi-neers, electrical engineers, and

16

Kollo2002_e.book Seite 217 Mittwoch, 6. März 2002 5:26 17


219LuK SYMPOSIUM 2002

Think Systems - Software by LuK

Klaus KüpperRoland SeebacherOlaf Werner

16


16 Think Systems - Software by LuK

220 LuK SYMPOSIUM 2002

IntroductionFor over ten years LuK has not only beenworking in the conventional core business ofmechanical components, but also in the fieldof automated transmission systems. Rightfrom the start, in addition to mechanical com-ponents, the necessary automation strategieshave been developed and put into practice.

Naturally, the question is raised and continuesto be raised, as to whether LuK, as a classicmetalworking automotive supplier, shouldconcern itself with software development.However, experience has shown that the com-bination of components and software providesmany advantages for the customer.

This paper highlights these advantages and ex-plains the reasons why LuK undertakes soft-ware and system strategy development.

Furthermore, various principles of softwaredevelopment have evolved in recent years atLuK. Ultimately, they are simply an adaptationof those guidelines along which LuK has al-ways developed its products. Hence the cus-tomer gets software of the quality he hasgrown to expect from LuK.

Selected examples illustrate how those ‘the-oretical’ benefits and software developmentprinciples are transformed into reality at LuK.

Why Does LuK Develop Software?

Transfer of Drivetrain KnowledgeOver many years in its conventional clutch anddual mass flywheel business, LuK has placedgreat emphasis on not only offering the cus-tomer individual components, but optimisingthem within the whole field of the drivetrain.

This experience, which has been built up overmany years, is reflected firstly in the compo-nents, but also in the optimisation of the entiredrivetrain.

Fig. 1: Customer Benefits of LuK Software

It is exactly this experience that software de-velopment for XSG systems uses. In some re-spects software can be considered to be justanother component of the transmission sys-tem which has to be tuned in combination withall the others. However, software also offersthe possibility to actively (or ‘intelligently’) uti-lise all of LuK’s experience, where the theo-retically complex ideas could rarely be fully ex-ploited in a purely mechanical solution.

The customer therefore has the opportunity ofacquiring know-how (strategies and ideas)straight from LuK and applying it directly to hisvehicle. It is critical that knowledge about theclutch, which defines drivetrain comfort duringslip phases, is fully utilised in the software.And it is precisely in the field of clutches thatLuK can boast of long and extensive experi-ence.

Optimisation of the Entire SystemOnly by applying electronics and software dothe mechanics become a ‘mechatronic sys-tem’. This catchphrase, which has been wide-ly used in recent years, really only means thatinstead of mechanics, electronics and soft-ware being considered separately, they areviewed as an integrated concept, whose op-




timisation exceeds the boundaries of individ-ual components. Hence, really intelligent sys-tem strategies enable the saving of certainsensors, such as, for example, the gearbox in-put shaft speed sensor and the release travelsensor in the clutch bell housing. Softwaremakes the manufacturing tolerances of themanual gearbox controllable. Intelligent al-gorithms learn these tolerances at theend of line, so that they can then be tak-en into account in the subsequentcontrol operation. Finally, only byconsidering the entire system cancertain software requirements betransferred to the mechanics.One example of this is the adap-tation of the clutch to the require-ments of the control strategy.

In addition to improving the entiresystem itself, the customer cannaturally also look forward to op-timum integration, simply by usingthe LuK drivetrain knowledge men-tioned above.

Offering Complete SystemsLuK is working on various concepts in the fieldof drivetrain automation, based on a gearboxwith spur gears (XSG), which will be present-ed in other symposium papers. They are allcharacterised by the fact that they include abasic gearbox, a clutch, a clutch actuator, agear actuator, and electronics. Every individ-ual component fulfils a specific task for whichit is optimised.

It is only when they are combined with the aidand co-ordination of software, that these indi-vidual components form a system, see figure 2.

By developing strategies and converting theminto software, LuK is able to offer the customercomplete drivetrain automation instead of in-dividual components. Hence the customerneedn’t worry about the co-ordination and in-tegration of sub-components, but can insteadconcentrate on optimising the system to thevehicle.

Also this transition from component to systemsuppliers – a still quite strong trend in the au-tomotive industry – is a reason for LuK’s in-house software development.

Fig. 2: Complete System by Means of Software

Principles of Software Development

Over the years various principles of softwaredevelopment have been established at LuK.Obviously, every piece of software must fulfila multitude of requirements – just like everymechanical component. However, the princi-ples described in the following are of particularimportance; they are the benchmarks for eachnew strategy.

It is interesting that these principles are equal-ly applicable to the development of mechani-cal components and play a similarly importantrole there.




System Knowledge

As stated above, software should combine allindividual components into an entire XSG sys-tem. This again relates to the entire vehiclecontext or its drivetrain. It naturally follows thatthe person who writes the software must notonly understand all individual componentsand how they interact, but also the primarysystem ‘drivetrain’ in detail. Finally, the degreeof system knowledge determines the qualityof the strategies and software.

Besides this software development principleforming a clear part of the LuK method of work-ing, it is also evident in the calibre of the em-ployees. The software development team atLuK is composed equally of mechanical engi-neers, electrical engineers, and physicists.Hence the focus is on the scientific under-standing of problems, leading to the best, the-oretically well-founded solutions.

Fig. 3: Principles of Software Development

Robustness

For a long time, especially since the spreadof Windows computers, software has been as-sociated with a certain unreliability. This iscompletely unacceptable in the automotivefield. The second important principle of soft-ware development at LuK is therefore robust-ness. At the end of the day, software mustfunction in all vehicles and with all compo-nents over the entire service life and in everysituation.

Firstly, this means that the software itself mustnot contain any error which could lead to amalfunction of the system.

Furthermore, the system strategies must bedesigned so that they function perfectly, bothwith all tolerances as well as with all other var-iations, e.g. frictional or power output changesin motors. Even changes during the servicelife have to be taken into consideration.

Finally, the software must function correctly inevery unexpected situation, something whichalso requires careful consideration.

However, as with every technical application,a high degree of robustness may occasionallyrequire compromises with optimum function-ality be made. It is critical that it does not causeinconvenience to the driver.

An example of this is the start-up, which shouldideally always occur at the same engine speed.

A strategy which usually provides a preciseengine speed, but which, in the event of abuild-up of unfavourable conditions, mightcause a deviation of 500 min-1 or even enginespeed oscillations, would not be acceptable.A robust strategy that does not behave like thisis therefore chosen. Whilst this strategy maystill deviate from the ideal value by, say,100 min-1 among different vehicles in varioussituations, the driver would not generally no-tice this.

As in every aspect of engineering, a compro-mise must be found between accuracy and ro-bustness, which, in the case of doubt, falls infavour of robustness.

Safety

Specifically in the automation of the drivetrain,safety plays a primary role. Safety here notonly relates to actual software quality, but alsoto functionality. There is no place for compro-mise. Every function is therefore carefully test-ed in terms of safety-relevant issues. Our cus-tomers know just how much value LuK placeson this rule.

This practice will continue in the future.




Slip ControlSlip control is a typical area in which only soft-ware enables an idea to be realised.

The basic idea of slip control, isolating the driv-etrain against vibrations of the engine througha slightly slipping clutch, is not a new one andhas been repeatedly discussed over recentyears. Apart from various mechanical prob-lems in the past, insufficient opportunities tocontrol the clutch have prevented the use ofslip control first and foremost.

The vibrational principles and the design of thedrivetrain for slip control will not be examinedclosely here, as these issues were alreadydealt with in detail at the LuK Symposium in1998 [1].

Control Concept

The first task of control is to define an optimumdesired slip. This represents a compromise ofnecessary vibration isolation and permissibleincrease in wear or fuel consumption. It is pre-cisely here that extensive tests and simula-tions, in particular vehicle-specific, must beconducted.

The second key point is to set the calculateddesired slip as precisely as possible. A highlevel of control accuracy is necessary here,since if the slip deviates downwards, this canlead to sticking and thus to acoustic problems(booming); however, for reasons of wear andfuel consumption, neither should it deviate up-wards.

In order to achieve the required robustness ofsoftware strategy mentioned in the previoussection, LuK is pursuing an approach whichcombines open-loop control, adaptation andclosed-loop control. This combination charac-terises many LuK strategies and will be ex-plained in more detail in the slip control exam-ple.

In terms of definition, a closed-loop controlleralways feeds back the measured output of thecontrolled system (plant), in order to generatea control input for the plant such that the ‘error’is minimised (c.f. figure 4a).

Open-loop control, on the other hand, merelyuses the desired value as an input and – whilstknowing the system to be controlled – gener-ates a control input, which, in the ideal sce-nario, correctly sets the desired value (c.f.figure 4b).

For the moment, a potential error between ref-erence signal and output is not corrected here.

Fig. 4: a) Closed-loop Controlb) Open-loop Control

a)

b)




Nevertheless, in order to achieve good quality,the behaviour of the plant is observed – in thecase in question, the entire vehicle with en-gine, clutch and drivetrain. Using this informa-tion, the model of the controlled system, whichthe open-loop control uses internally, is adapt-ed to compensate for medium and long-termplant changes.

Both methods have pros and cons, which is whyin practice they are generally used in parallel.

LuK is pursuing the approach of using open-loop control as much as possible and closed-loop control as little as necessary. Using asmall proportion of closed-loop control shouldachieve the following in particular:

� The closed-loop controller will not becomeunstable in any tolerance positions or envi-ronmental situations.

� Oscillations or overshoots by the closed-loop controller won’t be noticeable.

� The speed advantage of the open-loop con-trol is exploited.

Obviously, at the same time, attention must bepaid to the fact that as much system knowl-edge as possible should be used, so that theopen-loop control only permits a minor error.

In the actual case of slip control, the systembeing controlled essentially consists of clutch,engine and drivetrain. The driver commandacts as an input on the engine. The slip controlacts on the clutch.

In order to achieve an already precise feed-forward control, the slip controller receivesvarious other information in addition to thedriver command, in particular about the enginecondition. This is used in a model of the plant tocalculate the necessary control input correctly.

Partial SlipExtensive investigations at LuK have shownthat sufficient vibration isolation is alreadyachieved in partial slip, as shown in figure 5.Partial slip is characterised by the fact that dueto the rotational irregularity of the combustion

engine, the sticking and slip phases alternatewith the ignition frequency.

For reasons of wear and fuel consumption, aslow a desired slip as possible is sought duringslip control. Its lower limit is pre-determined bythe necessary vibrational isolation and thecontrol accuracy. Continuous sticking shouldthus be avoided in every case. It is preciselythis what has previously been viewed as ex-tremely difficult, and low slip has thereforebeen widely avoided. LuK’s investigations,however, paint a completely different picture:

Firstly, the situation during partial slip is ana-lysed more closely (c.f. figure 5). The simula-tion shows that in the torque peaks, hence withgreater forward acceleration of the combus-tion engine, the clutch starts slipping. Duringslip, the transferred torque is limited to themaximum transferable clutch torque. As soonas the rotational irregularity of the engineleads to a sticking clutch, the torque trans-ferred into the transmission drops from thetransferable clutch torque to the internaltorque. This process, which is easy to com-prehend, has the effect that the average trans-ferred torque is below the transferable clutchtorque.

The average clutch torque transferred in par-tial slip is determined by the ratio of slip to con-tinuous sticking and the torque irregularity ofthe engine. This results in the physical behav-iour shown in figure 6: from slip speed zero totransition into full slip (the engine irregularitiesno longer lead to a temporary sticking of theclutch), the average transferred clutch torquerises constantly. It achieves the actual trans-ferable torque in the traditional sense duringtransition to full slip.

If this torque is interpreted as a friction co-ef-ficient, a positive ‘friction co-efficient gradient’can be assumed in partial slip, whereby thegradient increases at small slip speeds. A po-tential negative friction co-efficient gradient inthe true sense is even compensated for by theeffect described.

This important discovery of the positive ‘fric-tion co-efficient gradient’ in partial slip holdsa considerable advantage for slip control.




Fig. 5: Partial Slip

Fig. 6: Slip Dependency of the Transferred Torque

In contrast to the dreadednegative friction co-effi-cient with clutch linings, apositive friction co-effi-cient gradient does notlead to juddering, but rath-er independently stabilis-es the slip speed initiallyset: as soon as the slip in-creases through a slightlyhigher engine torque, thetorque transferred by theclutch increases, where-upon the slip again reduc-es.

This self-stabilising effectalso allows the use of amore agressive closed-loop gain in partial slip,without risking instability. Itis thus possible to ensurea particularly high level ofcontroller precision and afast response to errors ortorque changes.

Due to the increasinglypositive ‘friction co-effi-cient gradient’, control ac-

curacy can be optimised so that permanentsticking can continue to be safely avoided.

Only the careful analysis of behaviour duringpartial slip and the subsequent use of this dis-covery enabled LuK to demonstrate slip con-trol with high accuracy and low slip speeds.

Results

The combination of open-loop control andclosed-loop control during partial slip leads toa stable system strategy that also deliversvery good results.

Figure 7 shows a typical measurement. Thetop diagram shows the course of engine andgearbox input speed. It clearly shows how theslip speed is set during a back-out, whencoasting, during a tip-in, and during the sub-sequent acceleration.




Fig. 7: Vehicle Measurement Slip Control

The deviations in speed during large loadchanges prevent transmission vibrations with-out being acoustically noticed by the driver.Comfort during load changes can thus be in-creased without the responsiveness of the ve-hicle being impaired.

According to the slip characteristic map thedesired slip is continually reduced with in-creasing engine speed. As soon as the de-fined engine speed is achieved and there isno slip, the clutch torque is increased to higherload.

The lower part of the diagram shows how thedesired clutch torque consists of an open-loopcontrol dependent part and a closed-loop con-trol part. In accordance with the structure se-lected, the open-loop control proportion isclearly predominate. Furthermore, it can be

seen how, after 5 seconds, the closed-loopcontrol proportion becomes continually small-er in favour of the open-loop control propor-tion. The adaptation here ensures that theopen-loop control precision increases and theclosed-loop control proportion drops further.

The slip control described here has alreadybeen used in a vehicle – a Mercedes A-classA170 modified to a single mass flywheel,which was in an endurance run. It shows thata vibration isolation is achieved comparablewith a dual mass flywheel (DMF). At the sametime, the control was stable and reliable overthe endurance test. The extra wear on theclutch lining is only 0.2 to 0.4 mmper 100 000 km. Fuel consumption essential-ly remained unchanged, which was also dem-onstrated by driving cycle simulations. Thiscan be explained by the fact that the engineinertia was able to be reduced through theomission of the DMF. The reduction in accel-eration losses thus achieved compensates forthe minimal extra fuel consumption caused byslip. The results must naturally be verified foractual vehicle projects, each according to therequired and necessary driving and desiredslip profile.

Clutch ProtectionObviously, when used as a start-up element,the clutch can be overloaded due to driver mis-use. The robustness demanded for the softwaremeans that it protects the system better in thissituation than with a manual transmission.

A key example is driving or start-up on a hill.During a typical hill start-up with automatedclutch actuation, firstly the engine speedslightly increases and the clutch slips. Onlywhen a start-up speed that corresponds to thevehicle speed has been reached, will theclutch close completely. However, if the vehi-cle is driven uphill relatively slowly then the en-gine and clutch speeds may never synchro-nise. To avoid this constant slip, clutch controlimitates the ‘strategy’ of a normal driver:




As soon as the vehicle is moving, the clutchis slowly closed completely. This means thatthe vehicle drives uphill at low speed withoutloading the clutch. This strategy is shown infigure 8.

Another, particularly critical scenario would beif the vehicle was held on the hill by modulatingthe accelerator, as might occur in a traffic jamon a hill for example. A driver with a foot-op-erated clutch will not usually behave like this,because modulation via acceleration andclutch pedal is relatively difficult here. On theother hand, an automated clutch facilitateshill-holding.

A strategy for preventing misuse of the clutchis illustrated in figure 9. After a certain time,approximately 4 seconds, the clutch is grad-ually closed. Since the driver operates the ac-celerator and hence wishes to start up, andclutch torque is built up very slowly, the vehicleresponse comes as no surprise to the driver;he can respond appropriately: either by con-tinuing the start-up or holding the vehicle onthe hill by braking. He simultaneously experi-

ences and ‘learns’ the natural limits of the sys-tem.

Both these examples demonstrate how,through appropriate, relatively simple soft-ware measures, the robustness of the entiresystem can be substantially increased againstmisuse.

Monitoring ConceptThe processor monitoring system describedbelow can serve as an example of the safetyconsiderations necessitated by a shift-by-wiresystem, such as an ASG or another XSG sys-tem.

The micro-processor is a central componentin all XSG processes, be it gear selection, en-gine intervention or clutch control. For this rea-son, its monitoring has a special significance,since a single error can lead to dangerous sit-uations. In order to detect these situations andrender it safe, a multi-level monitoring concept,

Fig. 8: Clutch Protection: Very Slow Driving Fig. 9: Clutch Protection: Holding on a Hill




the so-called ‘Intelligent Safety Monitoring’(ISM), was developed.

The ISM mainly considers a series of partic-ularly critical situations, so-called ‘top events’.It is their occurrence, as the result of a proc-essor error, that it must safely prevent.

Safe Condition

The first question which is raised when devel-oping a monitoring concept regards the safecondition to which the system should be trans-ferred. If it is assumed, as is necessary here,that there is a processor error, there are onlyvery limited response possibilities in the eventof a failure. Since the ‘intelligence’ of the sys-tem has possibly failed, it is very difficult oreven impossible to respond to different errorsituations with various, perhaps even com-plex, strategies.

Figure 10 illustrates considerations on a safecondition for the clutch, which must be regard-ed as the most important power transferelement of the transmission system.

A clutch actuator can fundamentallyclose, open or stop in the present posi-tion as a potential response to an error.Other strategies, such as various timesequences of opening and closing, per-haps even as a response to external sig-nals, are barely conceivable during aprocessor failure.

For potential initial situations, i.e. clutchclosed, clutch in an intermediate positionor clutch open, it should be considered whichof the three responses mentioned above is thesafest.

If the clutch is closed, for example as a roll-off lock (top event: vehicle is on a hill with en-gine stopped and gear engaged), closure orremaining closed is the safest option. On theother hand, opening the clutch can lead to anunexpected response for the driver, i.e. the ve-hicle suddenly rolling away.

On the other hand, if the clutch is open, thenopening or remaining open is the safe option.

Closure that is totally unexpected by the driv-er, for example at a zebra crossing or trafficlights (top event), might have fatal conse-quences.

If the clutch is in an intermediate position, fur-ther opening or closing can either be safe orlead to very critical situations, depending onthe actual situation. Stopping the clutch actu-ator is the safest response here, since the driv-er will not be confronted with an unexpectedvehicle action.

It is clear that stopping the clutch actuator inall situations represents the safest option. Theadvantage of the electro-mechanical clutchactuator favoured by LuK is also shown here,namely, that when switching off the actuatoror power supply, the position remains un-changed and the clutch does not close oropen, as on a hydraulic system.

Fig. 10: Safe Condition during Total Failure

ISMTo fulfil the requirements of a shift-by-wire sys-tem, a monitoring structure with several levelswas developed jointly with Bosch. It is funda-mentally based on the fact that various soft-ware levels, as well as the main processorused and a monitoring processor control eachother. Figure 11 provides an explanation ofthe system.

The largest part of the monitoring runs at thevarious software levels in the main processor.Consequently, various monitoring levels are




Fig. 11: Structure of ‘Intelligent Safety Monitoring’

implemented here in addition to the actualfunctionality for ASG control (functional level).The main processor (an Infineon 80C167 inthe present ASG) and a monitoring computer(a Motorola 68HC05 in the present ASG sys-tem) are used as hardware.

Each of these computers can independentlyswitch off the power drivers of the XSG systemif necessary.

Furthermore, they can trigger a reset on thecontrol unit in order to re-initialise the systemin the event of a processor failure having oc-curred and enable driving to continue.

Level 1 (functional level) contains the com-plete functionality in normal and limp-homeoperation, that is to say clutch control, gear se-lection, or engine intervention.

Level 2 (functionality monitoring) monitorsLevel 1. For this, the input signals from Level 1and the output signals generated by it are readin and checked for plausibility. However, it is

not the entire functionality of Level 1 that iscovered, but only the safety critical functions(top events) that are monitored.

A simple example is the prevention of clutchclosure with an engaged gear, without the driv-er operating the accelerator. Independently ofall other computations, error monitoring or ad-aptations that the functional level must con-duct, functionality monitoring merely needs toensure that the clutch does not close beyondthe creeping torque. As soon as this relativelysimple rule is violated, the functionality mon-itor traces this back to a controller error andswitches off the power drivers.

Level 3 covers various tests which again en-sure the correct functioning of monitoringLevel 2. This includes a program executioncontrol, which ensures that every part of func-tionality monitoring is carried out, as well ascontinuous memory check of RAM and ROM.Command check for Level 2 is also executed.




This means that all relevant processor com-mands that Level 2 uses are checked for cor-rect functioning. This extensive monitoring ofLevel 2 by Level 3 can only be realised, be-cause Level 2 includes substantially less codecompared to Level 1.

The last module in the monitoring process isthe monitoring module. With the help of ran-domly selected ‘questions’ to Level 3 of themain processor and the answers generatedfrom the software modules of Level 3, themonitoring computer checks their integrity.The main controller also uses this exchangeof questions and answers in reverse, to mon-itor the second processor. The monitoringprocessor must therefore detect intentional‘false’ answers thrown in and verify these withthe main processor.

If a safety critical error is detected in one of thethree levels of the monitoring concept, thepower drivers are switched off and a reset ofthe computer is triggered. By switching off thepower drivers, the XSG system goes into thesafe condition defined above and can rectifyitself again if the controller error is only tem-porary. Otherwise, the system remains in safecondition, until the error is rectified.

The safety structure described is heavilybased on designs which are also used withother safety relevant components in the drivetrain, for example, on electronic throttle con-trol systems.

SummaryMore than ten years of software developmentat LuK have shown that the extension of LuKexpertise beyond mechanical components of-fers considerable advantages for the custom-er. It enables LuK to

1. transfer their transmission system knowl-edge, acquired over many years, beyondthe limits of mechanical hardware aloneinto software strategies

2. optimise the automated transmission sys-tem as a whole in the vehicle and

3. offer the customer complete systems forautomating transmission systems.

LuK is thus pursuing the development of entiresystem knowledge, maximum robustness anduncompromised safety as the most importantcriteria for software development.

This paper illustrates typical examples of theadvantages for customers and for the devel-opment guidelines, namely: slip control, whichhas already shown some very good practicalresults; some strategies for clutch protection;and a safety monitoring concept that makesthe shift-by-wire system acceptable in vehi-cles.

Literature[1] Fischer, R.; Berger, R.: Automation of

Manual Transmissions, 6th LuK Sympo-sium 1998.


Documents

Kollo2002 e.book Seite 217 Mittwoch, 6. März 2002 5:26 17 · ployees. The software development team at LuK is composed equally of mechanical engi-neers, electrical engineers, and