Transactions of the Institute of
`Measurement and Control
`
`http://tim.sagepub.com/
`
`
`A test-bed facility for hybrid i c-engine/battery-electric road vehicle drive trains
`J.R. Bumby and P.W. Masding
` 1988 10: 87Transactions of the Institute of Measurement and Control
`
`DOI: 10.1177/014233128801000205
`
`The online version of this article can be found at:
`
` http://tim.sagepub.com/content/10/2/87
`
`Published by:
`
`http://www.sagepublications.com
`
`
`
`On behalf of:
`
`The Institute of Measurement and Control
`
`
`
`
`
`Additional services and information for can be found at:Transactions of the Institute of Measurement and Control
`
`  
`    
`
`
`
`
`
`
`http://tim.sagepub.com/cgi/alertsEmail Alerts:
`
`
`
`http://tim.sagepub.com/subscriptionsSubscriptions:
`
`
`
`Reprints:
`
`
`http://www.sagepub.com/journalsReprints.nav
`
`
`
`http://www.sagepub.com/journalsPermissions.navPermissions:
`
`
`
`Citations:
`
`http://tim.sagepub.com/content/10/2/87.refs.html
`
`
`
`>>
`
`Version of Record
`
`- Apr 1, 1988
`
`What is This?
`
`
`
`Page 1 of 12
`
`
`
`Downloaded from Downloaded from
`
`
`
`tim.sagepub.comtim.sagepub.com
`
`
`
` at WAYNE STATE UNIVERSITY on January 21, 2014 at WAYNE STATE UNIVERSITY on January 21, 2014
`
`FORD EXHIBIT 1106
`
` 
`  
` 
` 
` 
` 
` 
` 
`

`

`A test-bed facility for hybrid
`i c-engine/battery-electric road
`vehicle drive trains
`
`by J. R. Bumby, BSC, PhD, CEng, MIEE and P. W. Masding, BSc
`
`This paper describes the design and development of a test-
`bed facility for hybrid internal-combustion-engine/battery-
`electric vehicle power trains. The control hierarchy within
`the microprocessor control systems is discussed, and the
`influence this has on the software design is described. The
`instrumentation and computer software systems necessary
`for both data acquisition and drive train control are
`described. It is shown that drive train control over an urban
`cycle can be successfully achieved using a modified propor-
`tional-plus-integral controller.
`Keywords: Hybrid electric vehicles, electric vehicles,
`automotive test-bed control.
`
`List of symbols
`Final drive ratio
`g¡
`M2Inertia equivalent to vehicle mass, kg m2
`Ip~
`M Vehicle mass, kg
`r~, Wheel rolling radius, m
`
`
`
`1 Intr~~i~~~~c~~
`
`A hybrid electric vehicle combines the use of both an
`internal combustion engine (ic engine) and an electric
`traction drive in order to improve some aspect, or
`aspects, of the vehicle performance. Such hybrid drives
`have been considered intermittently for use in road
`vehicles ever since the invention of the ic engine.
`Although Pieper ( 19~5 patented a hybrid drive with the
`sole purpose of improving the performance of the then
`limited i c-engine vehicle, it was not again considered
`seriously until the 1960s and early 1970s. At this time the
`vehicles were seen as one way of reducing the staggering
`exhaust emission problem of some North American
`cities, and a demonstration vehicle was built and success-
`testes by 1976 (Wouk, ~.97~).
`By the mid 1970s the 1973 oil crisis had focused atten-
`tion on the hybrid drive as a means of reducing the
`amount of petroleum fuei used in the transport sector.
`The Ford Motor Company how the hybrid
`drive, operating essentially as an engine management
`system, could improve fuel economy by 30-70% depend-
`ing upon the vehicle type (Unnewehr et al, 1976). At the
`same time, a demonstration programme by Volkswagen
`~~~~rscl~, 1978) in Europe was showing how the hybrid
`drive could be used to substitute electricity for petroleum
`fuel and eliminate exhaust emissions in environmentally
`sensitive areas.
`
`’
`
`* School of Engineering and Applied Science, University of
`Durham, South Road, Durham, England DH1 3LE.
`
`This aim of substitution of petroleum with electricity
`was fundamental to the Electric and Hybrid Vehicle
`Research, Development and Demonstration Programme
`launched in the United States of America in 1976 (US
`Congress, 1976). Design contracts for a hybrid vehicle
`were placed with four manufacturers (Sand berg, 1980),
`the design produced by General Electric being selected
`for construction during the demonstration second phase
`(Burke and Miersch, 19881).
`In Europe, Volkswagen has continued its work and has
`recognised the hybrid drive as the only general purpose
`electric-based drive that can be used in the road transport
`sector (Kalberlah, 1986). This view, shared by the
`authors (Forster and Bumby, 1988), arises because of the
`range problems associated with the electric vehicle and
`the time required to charge the traction batteries.
`With the presence of two on-board power sources,
`optimum scheduling of the drive is best looked after by a
`microprocessor controller. This, in turn, implies the
`development of a ’drive-by-wire system’ whereby the
`driver communicates his power demand via the accelera-
`tor pedal to the microprocessor controller. The micro-
`processor then schedules the instantaneous outputs of the
`power sources. However, the way in which the power
`should be scheduled is not clear and earlier work (Forster
`and Bumby, 1988; Bumby et al, 1984,11985; Bumby and
`Forster, 1987; Burke and Somuah, 1980) has developed
`advanced computer simulation methods to investigate
`this problem. The work at Durham University demon-
`strated how power should be scheduled to meet driver
`demand, and postulated a possible sub-optimum control
`scheme to achieve this. To investigate how easily such a
`scheme can be incorporated into the hybrid drive, a full-
`scale laboratory test facility has been constructed in the
`School of Engineering and Applied Science at Durham
`University. It is the purpose of this paper to describe this
`test-bed facility, its instrumentation and overall control.
`
`2 cOli11tw@i hgerarchy
`Given thal two power are avai!aMe within the
`vehicle drive system, there are a number of ways in which
`they can be combined to produce torque output at the
`road wheels. However, earlier work (Bumby et al, 1984;
`Bumby and Forster, 1987) has shown the parallel
`arrangement of Fig 1 to have the greatest potential for use
`in a hybrid car. A similar arrangement has also been used
`by General Electric (Burke and Miersch, 1981), Volks-
`wagen (Miersch, 19’78~ and Lucas (Harding et al, 1983).
`With this parallel arrangement, either the electric trac-
`tion motor or the i c engine is capable of driving the road
`wheel directly, and independently, through a common
`87
`
`Page 2 of 12
`
`Downloaded from
`
`tim.sagepub.com
`
` at WAYNE STATE UNIVERSITY on January 21, 2014
`
`FORD EXHIBIT 1106
`
`

`

`transmission. Such an arrangement offers the potential to
`maximise the overall transmission efficiency between
`either prime mover and the road wheels while minimising
`the component count. If necessary, the i c engine can also
`drive the road wheels and the electric traction system, but
`now with the traction motor running as a generator. This
`enables the engine to charge the battery if required.
`With the arrangement shown in Fig 1, the electric trac-
`tion motor is connected permanently to the drive shaft,
`while the i c engine is connected through a ’one-way
`clutch’ or ’freewheel’. Such a connection allows’the trac-
`tion motor to drive the road wheels when the engine is
`stationary, but the electric motor must turn with the road
`wheels regardless of the drive source. This arrangement
`guarantees that regenerative braking into the battery is
`immediately available when required. Thus, during brak-
`ing, the i c-engine speed would reduce rapidly, owing to
`compression braking in the engine) and the vehicle con-
`troller would then allow vehicle kinetic energy to be
`returned to the battery via the electric traction system.
`Such use of regenerative braking substantially increases
`the overall drive-train efficiency.
`The consequence of the ’free-wheel’ in the it-engine
`connection also means that the electric traction system
`can move the vehicle from rest, and the i c engine need
`only be started and synchronised with the drive shaft
`when load demand is high. It is at such low-speed low-
`load situations that the i c engine is inefficient compared
`with the electric traction system.
`From this brief discussion it is apparent that the hybrid
`drive can be operated in a number of ways or modes.
`These possible are m Table 1 and described
`in detail in -Forster and Bumby (1988). In addition,
`depending on the driving situation, battery state of
`charge, etc, the vehicle controller must be capable of
`deciding which mode of operation listed in Table 1 is
`most appropriate. Thus a control hierarchy can be
`defined as shown in Fig 2. At the top of the hierarchy is
`the main vehicle control algorithm which decides when
`different operating modes are to be used to meet the
`particular driving conditions. In general, this logic control
`is non-tine-sensitive and, as will be seen in Section 5, can
`run very conveniently as the general background program
`associated with the mode-control algorithms. The mode-
`
`Fig 1
`
`Parallel hybrid configuration
`
`TABLE 1: Possible operating modes
`
`control algorithms (Table 1) form the next level in the
`hierarchy and decide how much torque, etc, should be
`produced at each instant from either of the two power
`sources. These algorithms interact directly with both them
`driver commands through brake- and accelerator-pedal
`movement, and communicate their requirements to the
`responsible for the control of the drive-line com-
`themselves. For exampie, would sand a
`torque demand to the chopper control unit on the DC
`drive system or a throttle position demand to the engine
`management system. These individual drive-train-
`component controllers may be microprocessor-based,
`hardwir~;-basec~ or software control algorithms running in
`the same processor as the mode-control algorithms.
`Operating around this vehicle control system is the
`overall test-bed control. Because the hybrid drive system
`must be exercised over driving cycles representative of
`urban, suburban and motorway conditions it is necessary
`to have overall control of the test bed, preferably by
`
`88
`
`Page 3 of 12
`
`Downloaded from
`
`tim.sagepub.com
`
` at WAYNE STATE UNIVERSITY on January 21, 2014
`
`FORD EXHIBIT 1106
`
`

`

`computer, in order to obtain the maximum repeatability
`in results. Manual control of the test bed must also be
`possible. The overall arrangement of the test-bed control
`is shown in Fig 3. The following sections concentrate on
`the hardware and software associated with the test facility
`and the overall test-bed control.
`
`3 The mechanical system
`The layout of the laboratory test facility representing
`the hybrid drive arrangement of Fig 1 is shown in Fig 4.
`The mechanical arrangement divides into two parts: first,
`that which emulates the road load and the vehicle inertia;
`and second, the hybrid drive system itself.
`Vehicle mass is represented by a variable-inertia fly-
`wheel with an inertia range between 2.02 and 15.57 kg
`is 2. As no final drive is present within the system, the
`vehicle mass is related to an equivalent rotating inertia by
`
`( )~
`Ie&dquo; = 9f
`where r~ is the wheel rolling radius and g~ the final drive
`ratio. Depending on wheel radius and final drive ratio,
`vehicles of up to about 2 tonnes can be represented.
`
`
`
`...(1)...(1)
`
`Fig 3 Test-bed control
`
`Energy loss equivalent to drag and rolling resistance is
`provided by a water-cooled dynamometer. This dyna-
`mometer can also be used to carry out load testing on
`both the i c engine and the electric motor. In selecting the
`dynamometer, significant attention was paid to low-speed
`torque capability which, for an electric traction system
`can be 200 to 300 N m.
`The drive system incorporates both a Ford 1100 cc
`petrol engine and a Lucas Chloride DC traction motor
`(the type used in the Bedford CF and Freight Rover
`Sherpa 1-tonne panel vans (Manghan and Edwards,
`19833)). Both the i c engine and the electric traction motor
`are connected to the same drive point by a toothed-belt
`drive. To improve drive performance a belt drive with a
`trapezoidal tooth section and a ground back has been
`used.
`The i c engine is connected to the common drive point
`through a friction clutch, free-wheel, short drive shaft and
`torque transducer. The DC system is similarly connected
`via a flexible coupling and torque transducer. The drive
`system is then connected through a standard four-speed
`transmission to the variable-inertia flywheel.
`As the electric-motor drive shaft is subjected to both
`motoring and regenerative braking torque, a flexible
`coupling with zero backlash must be used. In this instance
`a ’tyre’-type coupling has been used because of its posi-
`tive drive nature, ease of connection and its ability to
`lightly damp the high-frequency torques produced in the
`drive shaft due to the armature and field chopper control
`systems. The electric motor is connected electrically to
`the lead-acid traction battery via the appropriate Lucas
`Chloride control unit. This control unit employs a thyris-
`tor armature chopper with field weakening being pro-
`vided by a transistor field chopper. A summary of the
`drive system ratings is given in Table 2. It should be made
`clear that the components used in assembling the drive
`train were those most readily available but yet still repre-
`sentative of the components ideally required for a mid-
`range European passenger car. Forster and Bumby
`(1988} and Bumby and Forster (1987) discuss these ideal
`ratings in more detail. Perhaps the component that shows
`greatest discrepancy is the lead-acid battery system, with
`a weight of about 1 tonne. In practice, a lead-acid battery
`pack of 400 kg (or preferably a nickel-zinc battery of 200
`kg) would be used (Bumby and Forster, 1987).
`Braking is provided both by regenerative braking from
`the electric drive system and by air-brakes in the variable-
`inertia flywheel.
`
`4 Instrumentation and control equipment
`4.1 Computing equipment
`1. 9 ~~t~ar~a~~ M68000 system
`The M68000 microprocessor system is the of the
`drive-train control system and has two main tasks to per-
`form. First, it must implement the hybrid-vehicle control
`strategy which means controlling the electric traction
`system, i c engine and transmission in the most efficient
`way to meet driver demand. Second, during a test, it must
`act as a data logger.
`The M68000 system has been designed with all the
`interface hardware necessary to perform these tasks.
`Specifically, it includes a M68000 processing unit operat-
`ing at 8 MHz, 192k of random-access memory, four
`6522 versatile interface-adaptor [VIA] chips, a 16-
`89
`
`Page 4 of 12
`
`Downloaded from
`
`tim.sagepub.com
`
` at WAYNE STATE UNIVERSITY on January 21, 2014
`
`FORD EXHIBIT 1106
`
`

`

`Fig 4 Test-bed layout
`
`TABLE 2: Basic test-bed component ratings
`
`channel, 12-bit analogue-to-digital converter board
`[ADC] with interrupt facility, eight 12-bit digital-to-
`analogue converters [DAC] and finally two standard
`timer/counter chips [STC] each with five 16-bit counter/
`timers. These devices are shown in Fig 5. This interface
`hardware, when connected to suitable signal-conditioning
`circuits, gives the M68000 system the ability to gather
`data from the rig and respond with control outputs.
`Software for the M68000 is written mostly in the ‘~’
`programming language, with small amounts of software
`written in M68000 assembler. This is necessary for mani-
`pulation of registers within the VIA and STC chips. The
`
`’C’ programming language is particularly useful for real-
`time control applications as it is at a sufficiently high level
`to allow complex control structures to be written easily,
`and yet compiles efficiently to produce fast execution
`times. ’C’ also interfaces easily with M68000 assembler
`routines with a simple system of parameter transfer
`between the two. All program development is carried out
`on a M68020 development system and downline loaded
`into the M68000.
`
`4.1.2 The DUET 16 personnel computer
`This computer does not carry out any direct control of
`the drive train. Its purpose is to interact with the operator
`for overall rig control, to display graphically, in real time,
`selected test results and, when a test is complete, to
`accept data from the M68000 system and display
`selected data after suitable analysis.
`All the PC software is written in BASIC. Although
`BASIC suffers from slow running speed and lack of struc-
`ture, its interactive nature and ease of use in graph plot-
`has proven useful for displaying results.
`The DUET has a useful range of peripheral devices
`including a dual drive, a colour graphics monitor and
`a dot-matrix which is used to obtain hard copy of
`selected graphs.
`
`4.2 Instrumentation
`
`Instrumentation on the test bed falls into two cate-
`gories : first, that necessary for protection; and second,
`that necessary for data acquisition and test-bed control.
`In some instances signals necessary for control are also
`required for protection. In the most important cases,
`separate transducers are used for each application. Thus
`hardwired, failsafe, electronic protection is provided in
`case of overspeed of the i c engine, DC traction motor or
`
`90
`
`Page 5 of 12
`
`Downloaded from
`
`tim.sagepub.com
`
` at WAYNE STATE UNIVERSITY on January 21, 2014
`
`FORD EXHIBIT 1106
`
`

`

`Fig 5 Test-bed computing and interface equipment
`
`TABLE 3: Summary of main data sources
`
`flywheel. Speed signals are provided via magnetic probes
`from toothed wheels. In the case of the i c engine the
`engine starter ring is used. These transducers are also
`used to give the operator a visual check on speed. In addi-
`tion, visual checks on battery state of charge, engine
`temperature, oil pressure, fuel use, battery current and
`voltage, motor armature current and voltage, motor field
`current and voltage and engine, motor and dynamometer
`
`torque and power are provided. Temperature checks
`using temperature-sensitive paper are also used liberally
`throughout the rig, particularly on bearing supports. All
`DC motor and battery currents are monitored using Hall-
`effect current transducers, and both filtered (average) and
`unfiltered (instantaneous) outputs are available. Similarly,
`all voltages are connected through high-impedance
`operational amplifers (voltage transposers). Again filtered
`(average) and unfiltered outputs are available.
`As well as the hardwired protection, protection is also
`included within the software running on the M68000
`system. Should any data source exceed preset bounds,
`then the drive system is shut down automatically. This
`shutdown mechanism is also activated by a watchdog
`timer should there be a failure of the software.
`The M68000 system continuously monitors all the
`transducers around the rig for both data logging and
`control purposes. A list of these transducers is given in
`Table 3. In all cases inputs to the M68000 are buffered
`and, for the analogue signals, second-order Butterworth
`niters are used, typically a cut-off frequency of under >
`10 Hz. In the case of speed signals these are digitally
`filtered before being used for control. Both raw and
`filtered values are available for logging.
`
`4.3 Control
`As well as monitoring the data sources the M68000
`system also controls the power output from both the i c
`engine and the electric traction motor. The ic-engine
`output is controlled by a stepper motor control system on
`the engine throttle valve with the stepper motor pulses
`
`Page 6 of 12
`
`Downloaded from
`
`tim.sagepub.com
`
` at WAYNE STATE UNIVERSITY on January 21, 2014
`
`91
`
`FORD EXHIBIT 1106
`
`

`

`and direction control being generated by the M68000
`using two of its VIA chips. On initial start-up the throttle-
`control system is initialised by closing the throttle on to a
`microswitch. The electric motor output is controlled via
`the M68000 DAC interface which feeds analogue
`voltages to the Lucas Chloride electronic control unit.
`One signal is used to control acceleration and another to
`control regenerative braking. Software interlocks are
`used to prevent brake and motor operation being applied
`simultaneously.
`To improve power-train efficiency when the engine is
`not in use it is shut down. Thus, when power from the i c
`engine is demanded by the vehicle controller, the
`M68000 system must activate the ignition and start the
`engine. This is done using the conventional starter motor.
`To accommodate this control requirement, a micro-
`processor-controlled starting system is connected in
`parallel with the operator’s main control panel.
`
`5 Software systems
`Computer software is required on both the M68000
`system and the DUET 16 PC for data collection, vehicle
`control, rig control, real-time data display and, after a test
`is complete, data analysis. The software tasks can be con-
`veniently divided into those which are time critical, those
`which are not time critical and those required for subse-
`quent data analysis. Such varying demands are met using
`the software structure shown in Fig 6.
`
`5.1 System initialisation
`On system start-up all data sources and control func-
`tions are initialised and all parameters accessary for a7test
`
`set. These parameters include, for example, sampling
`period, data to be collected, controller parameters and
`information about the driving cycle over which the drive
`system is to be exercised. The driving-cycle velocity pro-
`file is stored on disk in the PC and is transferred to the
`M68000 system at the start of the test. By adopting this
`approach, different driving cycles can be easily and readily
`used (and modified) without the need to modify and
`recompile software on the M68000 system. New driving
`cycles can be created easily and quickly using a small
`BASIC program which requires cycle speed and time
`data to be specified by the operator. This technique also
`minimises memory-storage requirements within the
`M68000 system.
`
`5.2 Background tasks
`During a test, software tasks are ordered such that all
`tasks which require accurate timing are interrupt driven
`and those less-time-critical tasks are run as a background
`program. Consequently, during a cycle test, the M68000
`runs a background task which handles all non-time-
`sensitive control functions and also communicates with
`the ~’~. Although this background task handles non-time-
`critical functions, these functions are still processed very
`rapidly and, as far as the operator is aware, appear to
`happen immediately. It is the job of the background task
`to accept commands from the operator, via the PC. A list
`of such commands is given in Table 4. Each command is
`transferred in the form of a single character and, in the
`case of the PC, represents a key pressed. The background
`task in the M68000 is structured so that it scans the input
`bufffer for data continuously. As soon as data are
`detected, the M68000 compares them with a list of
`options and passes control to the appropriate sub-
`routine.
`The other major tasks of the background program is
`’real-time’ data transfer to the PC and the handling of
`nc~n-time-sensitive control functions. An example of the
`latter would be the decision to start the engine. However,
`once the decision to start the engine has been taken, the
`control of the engine and run up to speed is time critical
`and requires closed-loop control. Consequently, once an
`engine start has been initiated by the background pro-
`gram, responsibility for engine control is passed to the
`interrupt routines.
`
`TABLE 4: Operator commands
`
`Fig 6 Software structure
`
`92
`
`Page 7 of 12
`
`Downloaded from
`
`tim.sagepub.com
`
` at WAYNE STATE UNIVERSITY on January 21, 2014
`
`FORD EXHIBIT 1106
`
`

`

`Real-time data transfer to the PC is necessary to keep
`the operator informed how the test is progressing. Once
`the data have been transferred to the PC, the BASIC
`program running on the PC will present data either
`graphically and/or numerically.
`As will be seen in Section 5.3, interrupts occur every
`20 ms for control and data acquisition purposes. The
`interrupt routines must run in under 20 ms and leave time
`for the background task. During this time data transfer
`must take place. Indeed, to guarantee software reliability,
`data transfer is only allowed during this time window. To
`minimise data transfer time, all data are transferred using
`integer variables.
`
`5.3 Use of interrupts
`Data-acquisition and sampled-data control algorithms
`must be processed at regular time intervals. This is
`achieved in the M68000 system by ensuring that all such
`routines are interrupt driven. The source of the interrupt
`signal is a 0.8 MHz clock on the ADC board. This 0.8
`MHz signal is divided down to give a 20 ms sampling
`period. This sampling period is quite adequate to control
`the drive-train components. For example, on no-load, the
`time constant of the i c engine is approximately 0.6 s, or
`30-times the sampling period. Although the control
`algorithms are executed at each interrupt, data values are
`not necessarily stored each time as, during the initialisa-
`tion of the data logging software, a data-sampling period
`in multiples of 20 ms is set.
`Once the interrupt routine has started, the data sources
`are immediately read using an initial data gathering
`program of short assembler sub-routines. These sub-
`routines retrieve data from actual chip registers and store
`this information in a temporary array. The control soft-
`ware now follows having suffered minimum delay in
`recovering its data.
`At the end of the interrupt, a second data logging
`routine is called to transfer selected values from the
`temporary array into a large array which builds up with
`each interrupt. The advantage of only recording data
`specified by the operator is that it saves memory and
`therefore allows a higher sampling rate to be maintained
`throughout a long experiment.
`The control routines fall into two categories: those
`required to control the actual drive-train components;
`and those necessary to drive the rig through a cycle. This
`requires changing the set point to the mode-control
`algorithms in line with the velocity-time profile to be
`followed. As shown in Fig 3, this can be achieved using
`either ciosed-ioop control, with the M68000 system vary-
`ing the set point as required by the drive cycle, or by the
`operator manipulating the brake and accelerator pedals
`directly. Pressing of pedals the position
`of a potentiometer which is connected to the M68000
`through the ADC interface. The signals on the ADC
`board are accessed by interrupt-driven input routines,
`enabling the operator to ’follow’ the velocity-time profile
`displayed on the PC. The operator is now part of the
`feedback loop.
`When closed-loop cycle control is used, a cycle defini-
`tion routine is executed on every interrupt which calcu-
`lates cycle time by incrementing a counter on each
`execution. This counter value is then multiplied by the
`interrupt period to give the cycle time. Linear interpola-
`tion between values is used to calculate the required set
`
`point in km/h. This speed is then converted to a drive-
`shaft value using the back-axle ratio, wheel diameter, the
`number of teeth on the speed transducer disc and the
`current gearbox ratio. This value now becomes the new
`set point and is fed to the driving-cycle control routine as
`shown in Fig 7.
`
`Fig 7 Test-bed closed-~c~op drive-cycle control
`
`5.4 Data analysis
`At the end of a test run, data are transferred from the
`M68000 memory to the PC, where they are permanently
`stored on disk. This information is then displayed graphi-
`cally on the screen of the PC using a BASIC graph plot-
`ting and data analysis program. The interactive nature of
`BASIC makes it easy to refine a graphics display into a
`pleasing format. These features have been exploited to
`produce a graph drawing program capable of coping with
`all the different data types. The graphics program begins
`by retrieving the sampling period and data code word
`from the disk file. This provides the information neces-
`sary to label the y axes and also specifies what increment
`to use between points along the time axis.
`With two or more data sources, the program can use
`two independently scaled y axes. The program allows the
`operator to specify which data sets from the file are to be
`plotted on the same axis. It then retrieves all the data
`points from disk searches for maximum and mini-
`mum values to scale the axes automatically and therefore
`make the best use of the screen size.
`Hard copies of the arc obtained from dot
`matrix printer.
`
`6 Test-bed control
`As shown in Fig 3, control of the hybrid drive train
`either by operator manipulation of the brake and acceler-
`ator pedals or by closed-loop computer control is pos-
`sible. Of the two, the latter is preferred in order to obtain
`maximum repeatability in results. However, manual
`operation is invaluable for short-term testing and drive-
`ability studies. The rig control system must be able to
`accept either mode of operation.
`
`Page 8 of 12
`
`Downloaded from
`
`tim.sagepub.com
`
` at WAYNE STATE UNIVERSITY on January 21, 2014
`
`FORD EXHIBIT 1106
`
`93
`
`

`

`An approximation to the European ECE-15 urban-
`driving cycle is shown in Fig 8 and is currently used in
`Europe for urban fuel-economy specification. As well as
`defining a cycle velocity-time profile the ECE-15 stand-
`ard also specifies gear-change points as a function of
`speed throughout the cycle (manual transmissions only).
`These gear-change speeds are such that fourth gear is
`never used. From a control point of view, the discon-
`tinuities after each acceleration period cause particular
`problems.
`
`Fig 8 EGE-’3 ~ urban driving cycle.
`
`Experience has shown that acceptable cycle following
`can be achieved using a proportional plus integral con-
`troller synthesised using backward difference discretisa-
`tion. The structure of the controller is shown in Fig 9 and
`consists of two proportional plus integral controllers: one
`for acceleration and cruise; and another for braking.
`During acceleration, cruise and periods of gentle braking,
`ie, when the braking torque required is less than that
`produced by the system losses, application of the brakes
`(via regenerative braking) is not allowed, while during
`heavy braking, operation of the acceleration control is
`prohibited. Also included is an ’expert-control’ block and
`a software limit function to keep the accelerator and
`brake demand voltages within defined bounds. The dis-
`continuities after each acceleration phase require particu-
`lar attention if the cycle velocity profile is to be followed
`precisely. This is the purpose of the expert-control block.
`Speed following using the proportional plus integral
`
`controllers is shown in Fig 10a, but without the expert
`controls, for the drive system operating in a pure electric
`mode. Fig 10b shows the corresponding electric-motor
`torque throughout the cycle. These figures clearly show
`the velocity overshoots at the end of each acceleration
`phase, and the undershoot at the end of the deceleration
`phase of the third block, and are attributable to the
`integral term in the controller.
`Speed following can be improved by recognising that
`for a given set of vehicle parameters, each cruise phase,
`and the start of each acceleration (deceleration) phase,
`corresponds to a particular accelerator (brake) setting. By
`resetting the integral term in the controller at each dis-
`continuity in the cycle to the appropriate accelerator
`(brake) value, cycle following can be dramatically
`improved (see Fig 11). Once reset, each individual con-
`troller acts in the normal way to deal with small changes
`occurring within the system. For example, during constant
`acceleration, although acceleration torque remains
`constant, the dynamometer torque, representing vehicle
`aerodynamic drag and rolling resistance, increases as a
`function of speed. The expert control is used to move the
`controller setting rapidly to the correct region, with
`control then being handed back to the proportional plus
`integral controller. As Fig 11 demonstrates, the over-
`shoots on speed and torque apparent in Fig 10 have been
`removed successfully and speed following throughout the
`cycle improved substantially.
`
`7 Conclusions
`The preceding sections have described the test facility
`for hybrid electric-vehicle drive trains designed and
`constructed at the University of Durham. Throughout the
`design process special attention has been paid to develop-
`ing a system, in both hardware and software, that is
`flexible in operation and allows modifications and addi-
`tions to be made easily.
`Computer software has been developed for both data
`acquisition and control with the system hardware, allow-
`ing easy transfer of data between the vehicle control
`(M68000) and test-bed control (PC) computers. Exten-
`sive use has been made of graphical output.
`Some of the problems associated with computer-
`controlled testing over pre-defined driving cycles have
`been discussed. It has been shown that modified propor-
`
`94
`
`Page 9 of 12
`
`Downloaded from
`
`tim.sagepub.com
`
` at WAYNE STATE UNIVERSITY on January 21, 2014
`
`FORD EXHIBIT 1106
`
`Fig 9 Structure of drive cycle
`controller
`
`

`

`Fig 10b Electric-mot