Development of power train ECU for AZ line※1 engine

27FUJITSU TEN TECH. J., NO.16 (2001)

AbstractMotor industry is globalizing rapidly in recent years, and the requests for short-term product development and cost reduc-

tion are increasing, with intensifying competition. Therefore, the demand for on-vehicle equipment quality is becomingmuch higher than ever before.

To correspond to such market factors, we reexamined each conventional operation step in the power train control field,from development to production. We then started the introduction and application of new technology and construction meth-ods.

In this article, we introduce the improvements toward the ease of manufacturing by surface mounting all electric parts, andnew inspection methods without using the ICT (in-circuit tester). In addition, improvements in software development tech-nique are introduced.※1: 2000cc engine (1AZ-FE, 1AZ-FSE), which is loaded on the RAV4 (’00/5) and the Opa (’00/8) by Toyota Motor Corporation.

● Norimitsu Yukumatsu ● Koji Sakamaki ● Akira Ikezoe

● Takuhiro Tarumoto ● Yuji Uno

Development of power train ECU for AZ line※1 engine

28

Development of power train ECU for AZ line engine

FUJITSU TEN TECH. J., NO.16 (2001)

1. IntroductionOur company has been producing power train system

ECUs for over twenty years. Initially, they were for emis-sion gas control, but recently developed ECUs haveincorporated advanced functions, such as fuel injection,ignition timing, transmission, and electronic throttle con-trol.

Furthermore, as mentioned in the Abstract, lowercost and a reduction in development period are alsoexpected of them.

To meet expectations such as these, our company'sMotoronics Headquarters, aiming to develop a revolu-tionary product, launched the SRM 2000 (Super RapidModule 2000) Project in November 1997, performingconcurrent development work with related departments(Quality Control, Manufacturing Engineering,Manufacturing, and others) starting from the productionplanning stage. As a result, we developed a power trainECU for the AZ system engine, which came off the linein May 2000.

This report will describe design-related actions thatwere taken to materialize the concept of the project activ-ities (Table 1).

2. Complete conversion to surface-mountedparts

Aiming for a slim product form that supports higherdensities and high-speed production, the company con-verted all electronic parts to surface-mounted types(reflow parts) and eliminated radiators (Fig. 1).

As a result, as shown in Fig. 2, it became possible tosimplify the manufacturing process and mount parts sim-ply by using a very-high-speed mounter.

To reduce the amount of power consumed by theECU internal power supply, which created a bottleneck, aswitching system (conventionally a series system) wasadopted for the first time for the internal power supply asa power train ECU destined for the Toyota MotorCorporation.

Here is a list of the power supplies required by the

ECU:① 3V power supply: For 32-bit flash microcomputer② 5V power supply: For system LSI circuit, 32-bit flash

microcomputer, and output predriver③ 5V precision power supply: For sensor, analog signal

processing circuit, knock processing circuit, and sys-tem LSI circuit

④ 8V power supply: For 32-bit flash microcomputerwritingEven if the currently developed product used a con-

ventional series system, the total power consumed by thepower supply unit would be 3.8 watts; thus, as shown inFig. 5, the power supply transistors, as lead-includedcomponents, would need a radiator in order to dissipateheat.

To solve this problem, the possibility of productmaterialization using a switching system was examinedfrom the perspective of required voltage accuracy. Thus,it was determined that adoptability was possible for ①

Speed

Slim

Inspection�Detecting � capability�Improvement

SRM2000Concept

Aim Quality�（Q）�

Cost�（C）�

Supply�（D）�Measure

Complete conversion to �surface-mounted parts

Reducing �number of parts

Improvement of software �development techniques

Special software for �inspections (ICT elimination)

Inspection of actual �vehicle modes

Table 1 Concept, manner, and aim of SRM2000

Conventional product

Developed product (except for connectors, all parts surface-mounted)

ConnectorLead part Radiator

Surface-mounted �part

Connector

Fig.1 Product configuration

Conventional productSurface A �mounting

Reflow part (mounting)

Lead part (horizontal)

Lead part (vertical)

Insertion of deformed parts

Flow soldering

Reflow


Reflow

Surface B mounting of glued partsVery-high-speed�

mounter

Surface A �insertion

Low-speed�insertion unit

Surface B �mounting

Very-high-speed�mounter

Surface A �mounting

Very-high-speed�mounter

Developed part

①Mounting possible with very-high-speed mounter only (improved speed)�②High-density mounting possible since parts are surface-mounted (slimming)�③Simplification of manufacturing process (improved speed/slimming)


Reflow


Reflow

Connector m

ounting

Connector flow

soldering

Fig.2 Manufacturing process

29



and ②. As a result, the total power consumption for ①and ② was 0.55 watt.

But because the power consumption was 0.25 wattfor ③, which required high voltage precision; and thepower consumption was 0.1 watt or less for ④; the con-ventional series system was adopted for use.As a result, the total power consumption was 0.9 watts,enabling the product to be developed as a surface-mount-ed part.

To supply power for ①, ②, ③, and ④, a custompower supply IC was newly developed, making it possi-ble to control all power supplies with a single IC.Furthermore, for the radiator-equipped lead IC shown inFig. 5, a SOP (surface-mounted) package with rear-sur-face radiator was adopted to actively radiate heat to the

circuit board (Fig. 3).

3. Measures for reducing number of partsDuring the development of this ECU, the develop-

ment of ICs by functional block (Fig. 4) was examinedand the following custom ICs were developed.

Cooling wheel� (pattern soldering)

Cooling�thru-holes

Cooling patterns Print board

Inside layer Cooling patterns

Fig.3 SOP (surface mounting) package with rear cooling wheel

Power supply unit

Drive circuit for 5V/3V switching power supply

Power supply IC

①5V/3V switching power supply control�②5V high precision power supply�③Power supply for flash memory writing�④Other

Input waveform shaping circuit

Sensor input (water temperature, intake air temperature, etc.)

Switch input (key switch, drive position, etc.)

Other input circuits

Vehicle interior communications buffer

BEAN communications

TRC communications

EFI communications

VSC communications

Other communications

Output circuit

Linear solenoid drive IC

ECT (CVT)/VVT output




32-bit flash �microcomputer①Engine control �(injection, ignition, etc.)�②Other

32-bit flash �microcomputer

①Electronic throttle control�②ECT (CVT) control�③Other

Integrated IC for 2000 EFI①32-bit microcomputer�②Knocking control�③Rotation group input buffer processing�(engine speed, vehicle speed, ETC speed, other)�①AD converter (40 CH)�②Immobiliser control�③Ignition control�④Other

Motor drive circuit

Injection output

Ignition output

Lamp output�(warning lamps/other)

Other output circuits

Electronic throttle control IC

Electronic slot output

�

Indicates new custom IC122-pin connector

Fig.4 Functional block

Conventional �product

Developed product

Power supply transistor� lead part + radiator Power supply unit�

Constructed with �surface-mounted �parts

Adoption of SOP �package with �rear-surface radiator

Lead IC �with radiator

Fig.5 Product configuration of development product

30



① 2000 EFI system LSI circuit② Electronic throttle control IC③ Linear solenoid drive IC④ Power supply IC

As a result, thinking of the number of parts in termsof the function of the developed product, we were able toreduce the number of parts from the original 1200 to 850.Fig. 5 shows the appearance of the newly developedproduct.

4. New inspection4.1 Adoption of special software for inspections

With an advanced ECU such as this, high-densitymounting inevitably becomes a necessity. Conventionally,an ICT (in-circuit tester, which checks by application ofmeasuring pin to print board) was used to check the con-stants of components. In this case, however, a test termi-nal was needed for each component on the print board, soit was an obstacle to high-density mounting. And since itis necessary to prepare a fixture for an ICT of severalhundred pins (and for the currently developed product, atleast six hundred pins) for each model and to perform asetup change for each flow, this has become a major fac-tor that complicates the manufacturing process and makesjoint use with a temperature (temperature characteristics)inspection more difficult.

But since a microcomputer with built-in flash memo-ry has now been adopted, the rewrite function will be uti-lized effectively, special software for inspections will bedeveloped, and a boundary scan function will exist for the2000 EFI system LSI circuit. Thus, it is possible to set upHi (5V) and Lo (0V) output and input arbitrarily for

microcomputer and system LSI circuit terminals.In this way, a microcomputer and system LSI circuit

will monitor the connector terminals in the case of outputsettings, and will send the input results to a personal com-puter or other measuring instrument in the case of inputsettings. This makes it possible to simultaneously inspectthe functions and component constants for each circuitblock (Fig. 6). As a result, the conventional ICT inspec-tion can be eliminated and this joint inspection can beconducted under temperature-insufficient conditions.Thus, improvement was made in detection capability andintegration with temperature (temperature characteristics)inspections.

Furthermore, as shown in Fig. 7, an automaticappearance inspection and actual vehicle mode inspectionwere newly introduced in an effort to improve detectioncapability.4.2 Introduction of actual vehicle mode inspectionWith the aim of improving the detection capability ofECU shipment inspections, an actual-vehicle simulator(CRAMAS [*2]) was newly introduced with this product,and an inspection was added for actual vehicle mode.

During this actual vehicle mode inspection, travelpatterns that have been recorded by the actual-vehiclesimulator (CRAMAS) are utilized to operate an ECU.The ECU's output signals are continuously monitored inorder to compare the expected values to real time (Fig. 8).

Furthermore, even in cases in which a phenomenonoccurs only under certain travel conditions, adding to thetravel patterns makes it possible to raise the level ofinspection.

*2 CRAMAS (ComputeR-Aided Multi-Analysis System)

Simulation system (developed by our company) that utilizes

vehicle models to efficiently verify ECU operations and debug

software under evaluation conditions that are similar to those of

an actual vehicle.

R1C2R3 R4

R6

R5

R2

R2

C1

Integrated �LSI circuit

R1

C2

R3 R4

R6

R5

C1

Integrated �LSI circuit

equipped with �boundary scan �function

Conventional product: Measurement with (several hundred) pins in board

Developed product: Verification of constants/functions at connector terminals

Control by serial communicationsTransmission of inspection commands/receipt of input results

Test terminal for each arrow

Microcomputer

special �software for �inspections

5V/0V/input�Set optionally

Monitoring of waveform

Personal computer

Fig.6 Inspection method

ICT QTFunction �inspection

Temperature �characteristics �inspection

Automatic �appearance �inspection

Actual�vehicle�mode

New temperature�characteristics inspection�(inspection software)

QT�(product software)

Integration of ICT elimination/inspection

Conventional product

Developed product

Improvement of inspection detection capability and �process slimming

Fig.7 Inspection process

31



5. Improvement of software development tech-niques

As a result of improvements in fuel economy, tight-ening of emission standards, and implementation of otherenvironmental measures in recent years, the demand forsoftware for power train control ECUs has grown in scaleand become more complicated. To meet such demandduring the development of this product, we did not limitourselves to simply standardizing software components;rather, we took the actions described below to improvereusability and ensure quality in order to effectively uti-lize the asset value of the software.5.1 Software structure

With this product, we further reviewed softwarestructure, an issue that we have engaged in for manyyears. To improve the reusability of software and adapt

flexibly to system changes, we introduced hierarchicalstructure software (Fig. 9), the company's first such soft-ware for power train control ECUs; and developed soft-ware for parts (modularization).5.1.1 Makeup of hierarchical structure software1) Platform layer① ECU hardware layer (ECU layer /CPU layer)

Processes ECU circuits and microcomputer (CPU)internal circuits.

② Application platform layer (APF layer)Absorbs sensor and actuator characteristics, and com-bines the application unit and ECU hardware layer.

2) Application layerPortion of software that is in charge of system con-

trol.

CRAMAS

Coding

Product requirement �specifications

Detail design

Examination of hardware/�software components

Coding inspection

Requirement analysisReview

Software structure design

Review

Review

Review

Program (unit) inspection

Program (combined) inspection

Hardware/software �combined inspection

ECU inspection

CAPAS

Design process Verification processShipment

Fig.10 Software development process

APF layer

ECU layer OS

CPU layer

Application level Failure diagnosis

Speed change �computation

Injection�computation

Platform level

OBD ECT ENG

Fig.9 Software composition in hierarchical structure

Product �(engine ECU)

Simulator�(CRAMAS)

ECU output

Ignition�timing

Amount of �fuel injected

・�・�・�

Travel patternEngine speed

Throttle opening

・�・�・�

Expected �value Check

Fig.8 Actual car mode inspection

32



5.1.2 Features of hierarchical structure softwareIn the past, when modifying the ECU circuit configu-

ration, CPU internal circuits, and other hardware, it wasalso necessary to modify multiple related software com-ponents. By adopting this software configuration, howev-er, it has become possible to adapt flexibly by replacingsoftware components of the platform layer, without hav-ing to modify the application or redesign.

Furthermore, emphasizing reduced memory andhigh-speed response for automobile control and introduc-ing a real-time OS that complies with ITRON specifica-tions has made it possible to achieve efficient applicationsoftware processing.5.2 Improvement of development process

To further improve software reliability while expand-ing the number of objects of software control, improve-ments to the conventional software development processwere added (Fig. 10).5.2.1 Features of improved development process1) Design process

Conducting a design review at each stage of designmakes it possible to conclude work at each stage andminimize needed corrections, which in turn reduces thedevelopment period.2) Verification process

Connecting the verification subject and designprocess helps to provide quality control for the designprocess as well. And when a problem arises, the nature ofthe work upstream helps to clarify the source of the prob-lem, which in turn helps to prevent recurrence.

These improvements can be incorporated into thesoftware development process, reducing the developmentperiod, and can serve as design standards for productsdeveloped after the current product.5.3 Use of tools

For a long time, tools have been used to improve theefficiency of software development. During the develop-ment of this product, too, as shown in Fig. 10, new toolswere introduced into each process of the software devel-opment process in an effort to achieve greater efficiency.① Strengthening of design review function (CAPAS

[*3])To ensure program quality, techniques that utilizetools, rather than humans, to perform automaticchecks have been generally adopted, and software,too, is available on the market.Our company makes use of its independently devel-oped CAPAS system to meet a variety of in-houseneeds.During the development of this product, the qualityof software in components was verified through the

development of software components; however, it isimportant to verify the compatibility of componentswhen mounting such components to the ECU.Here, in addition to the original function of theCAPAS system, we strengthened the review functionfor portions related to the compatibility of compo-nents. Thus, it has become possible to detect prob-lems during the early stages of the verificationprocess.

② Actual-vehicle simulator (CRAMAS)The recently developed CVT control was the firstsuch system of the Toyota Motor Corporation, soECU debugging required verification not only at thesoftware component level but required checks ofoverall vehicle operations. Moreover, a tool thatcould replace an actual vehicle was indispensable.CRAMAS was developed as an actual-vehicle simu-lator that could meet these needs, but although engineand transmission models were initially mounted, theywere simplified. To produce operation that moreclosely approximated an actual vehicle, it was neces-sary to develop a precision model.Thus, based on the CVT control specifications, amodel of vehicle conditions required for ECU debug-ging was developed and incorporated into the actual-vehicle simulator (CRAMAS) (Fig. 11).

During the creation of the model, MATLAB/SIMULINK was utilized to create a model block dia-gram. As development proceeded, the CVT equipmentadvanced to successively higher levels as did the corre-sponding model block. As a result, an effective evalua-tion environment that more closely approximated an actu-al vehicle was achieved.

*3 CAPAS (Computer-Aided Program Analysis System)A computer-aided software design and program analysissupport system.

Input data conversion

Sensor signal etc

External signal�Operating mode, environmental conditions

Actuator drive �signal etc

Model computation

ＣＲＡＭＡＳ�

Output data conversion

Fig.11 Actual car simulator (CRAMAS)

33



6. Positive results of developmentThrough this development, we have been able to

materialize both a higher-performing ECU and slimmerproduct form.

As a result, we have achieved greater-than-ever qual-ity, drastic simplification of the manufacturing process,and reduced cost.

Table 2 shows the effect of the currently developedproduct, which incorporates D4 control (fuel cylinderinternal injection), CVT (continuously variable transmis-sion), and electronic throttle control, comparing it to a

conventional product (1997 model).

7. Future development plan① During the development of the next model, create an

ECU that is easier to make and strive for animproved degree of completeness.Number of parts: 300 or lessCompactness: 235 × 170 mm 160 × 170 mm

② Utilize the actual-vehicle simulator for other controlsas well, and further improve the efficiency of ECUdebugging.

8. ConclusionThrough the aforementioned activities, we have been

able to raise the productivity of the manufacturing lineand improve our software design techniques. And in Mayof this year, we were able to start production of an ECUwhose functions are more advanced than any in the past.

In closing, we wish to express our deep thanks to theToyota Motor Corporation and SRM 2000 personnel whoprovided such outstanding support during the develop-ment of this product.

Profiles of Writers

Norimitsu Yukumatsu

Joined company in 1986. Initiallyengaged in development of automobilesensors and Hic, and since 1998 hasengaged in development of automobileelectronic equipment. Currently worksat Motoronics Headquarters,Engineering Department No. 1,Engineering Section No. 2.

Koji Sakamaki

Joined company in 1985. Since thattime, has engaged in development ofsoftware for automobile engine controlelectronic equipment. Currently worksat Motoronics Headquarters, SoftwareEngineering Department, SoftwareProject No. 2.

Akira Ikezoe

Joined company in 1982. Since thattime, has engaged in mechanismdesign and software development forautomobile engine control electronicequipment. Is currently manager ofSoftware Project No. 1 at MotoronicsHeadquarters, Software EngineeringDepartment.

Takuhiro Tarumoto

Joined company in 1984. Since thattime, has engaged in development ofsoftware for automobile engine controlelectronic equipment. Is currently man-ager of Software Project No. 2 atMotoronics Headquarters, SoftwareEngineering Department.

Yuji Uno

Joined company in 1984. Initiallyengaged in development of automobileHIC and high-density mounting tech-nology, and since 1999 has engaged indevelopment of automobile electronicequipment. Is currently manager ofEngineering Section No. 12 atMotoronics Headquarters, EngineeringDepartment No. 1.

�

�

Number of parts�

�

Processing cost (index)�

Number of manufacturing processes�

Line length�

Flow tact time�

Cost (function ratio)

Conventional product �

(1997 model)�

400 items�

�

100�

21�

80m�

30 sec�

100

Developed product�

�

850 items�

(conventional technology: 1200 items)�

75�

11�

45m�

20 sec�

75

Table 2 Comparison to the conventional type in development

Documents

Development of power train ECU for AZ line※1 engine