vector press book

252
Press Book 1 st Edition

Upload: andreas-neubauer

Post on 19-Jun-2015

1.286 views

Category:

Documents


21 download

DESCRIPTION

Selection of articles published by Vector and covering topics like FlexRay, AUTOSAR, ECU Testing etc.

TRANSCRIPT

Page 1: Vector Press Book

Press Book1st Edition

Press Book_Einleitungsseiten:Einleitungsseiten 09.02.2010 14:27 Uhr Seite 1

Page 2: Vector Press Book

Date: Febru ary 2010 · Respon si ble for the con tents: Vec tor Infor ma tik GmbH, Stutt gart, Ger ma ny

All men tioned prod uct names are either reg is tered or unreg is tered trade marks of their respec tive own ers. The con stant world wide avail a bil i ty of all pro ducts or serv i ces is not war rant ed.

No infor ma tion con tained in this cat a log may be repro duced with out expressed per mis sion, in writ ing, from Vec tor Infor ma tik GmbH.

Errors and omis sions except ed.

Illus tra tion & Design: SATZ TEAM Foto satz & Neue Medien GmbH, Eberd in gen, Ger ma ny

Press Book_Einleitungsseiten:Einleitungsseiten 09.02.2010 14:27 Uhr Seite a

Page 3: Vector Press Book

Dear reader,

in recent years, Vector has written – together with customers - numerous technical articles reporting

on standardization trends, development processes and software architectures for embedded systems.

In this way, we have provided our readers with a wealth of knowledge. Now you get a central point of

access to this know-how.

In this book, you find a selection of the best technical articles in a convenient and compact format.

These articles cover important topics such as design, development and test of networks, ECU cali -

bration and diagnostics as well as process management.

We hope very much that you find this book both useful and informative.

En joy read ing.

Sin cere ly,

Dr. Thom as BeckPres i dent

Press Book_Einleitungsseiten:Einleitungsseiten 10.02.2010 12:05 Uhr Seite b

Page 4: Vector Press Book

Contents

Serial Bus Systems

Serial Bus Systems – CAN

Serial Bus Systems – LIN

Serial Bus Systems – FlexRay

Serial Bus Systems – MOST

ECU Testing

Vehicle Diagnostics

Serial Bus Systems in the Automobile: Introduction 1/0Motivation, advantages, tasks and architecture of serial bus systems in the automobile

Serial Bus Systems in the Automobile: CAN 1/6Reliable data exchange in the automobile with CAN

Serial Bus Systems in the Automobile: LIN 1/12Simple and cost-effective data exchange in the automobile with LIN

Network Development across LIN Bus Systems 1/18Tools for efficient network design and conformance testing

Assuring the Quality of LIN ECUs 1/22Current and future strategies for LIN Master conformance tests

Serial Bus Systems in the Automobile: FlexRay 1/26FlexRay for data exchange in highly critical safety applications

The Optimal Operating System for FlexRay-Based Applications 1/32

Embedded Software for FlexRay Systems 1/38Special aspects and benefits of implementing modularized software

FlexRay becomes daily Routine 1/42Analyzing, simulating, and testing FlexRay ECUs and networks using CANoe.FlexRay

Case Study: Bertrandt 1/45

FlexRay Sets the Pace 1/46Real-time simulation of FlexRay systems

Efficient Access to the FlexRay Bus 1/50High-performance FlexRay hardware for analysis and simulation

AUTOSAR PDUs Conquer FlexRay 1/54Audi benefits from CANoe.FlexRay in developing FlexRay networks with PDU communication

Beyond FlexRay 1/58Requirements on a modern development environment

Serial Bus Systems in the Automobile: MOST 1/62MOST for transmission of multimedia data

Efficient Testing in Automotive Electronics 2/0One test environment from HIL simulation to diagnostics

Reliable Engineering Testing on a Wiper Motor Test Bench 2/8Time-synchronous recording and evaluation of bus messages and physical parameters

Case Study: Nippon Seiki Co., Ltd. 2/13

Comprehensive ECU Tests with Fault Simulation 2/14Fault simulation capability is needed in early test phases for efficient functional tests

Semi-Synthetic Regression Tests with Real-World Data 2/20Reducing time and hardware effort in software evaluations

Model-Based Testing for Better Quality 2/24Advantages of test case generators in model-based development processes

Efficient Airbag ECU Tests 2/28Increase efficiency by automated tests during development

Vehicle Diagnostics - The whole Story 3/0Efficiency gains by standardization and the use of tool-supported processes

Automatic Validation of Diagnostic Services by Use of a Diagnostic Integration 3/8and Validation Assistant

A Source Code Generator Approach to Implementing Diagnostics in Vehicle ECUs 3/16

ECU Software for Dry Dual Clutch has Stringent Requirements 3/20Integrated diagnostic and flash solution with script control

Flexible Flash Solution for every Job 3/24Open standards enable use of generic tool chains

Flash Programming via CAN requires Supplier’s Flexibility 3/28Satisfying strict requirements of Vehicle OEMs

Press Book_Einleitungsseiten:Einleitungsseiten 09.02.2010 14:27 Uhr Seite c

Page 5: Vector Press Book

ECU Calibration

ECU Software

AUTOSAR

Open Networks - SAE J1939

Open Networks - ISOBUS

Open Networks - IP

Open Networks - CANopen

Process Management

Use of XCP on FlexRay at BMW 4/0

XCP-on-FlexRay at Audi 4/4AUTOSAR-compatible XCP software modules for FlexRay ECUs

XCP at the Focal Point of Measurement and Calibration Applications 4/10

Quantum Leap in Microcontroller Measurement Technology 4/16Innovative ECU measurement concept for maximum data rates with minimal effects on execution time

Efficient Analysis of Model Behavior in ECU Function Development 4/20Visualize and parameterize Simulink models easily and efficiently

Accelerated Turbocharger Development with CANape 4/24Efficiently developing control concepts with a cost-effective rapid prototyping solution

Optimizing Driver Assistance Systems 4/28Verification of object recognition algorithms by driver assistance systems

Trends in Embedded Development 5/0Requirements and future concepts in hardware, software and tools

Timing, Memory Protection and Error Detection in OSEK Systems 5/4Requirements on a real-time and multitasking operating system

Current Challenges in Automotive Networking 6/0Reusability of software modules at Volkswagen and Bosch

The Universal Gateway ECU 6/4Flexible post-build configuration of AUTOSAR gateways

Early Migration creates Opportunitites for Innovations 6/10Mix of individual software and AUTOSAR components in vehicle electronics

AUTOSAR on its Way to Production 6/14

AUTOSAR: New Paths to ECU Software – Part 1 6/18Iterative collaboration between OEM, TIER1 and software supplier

AUTOSAR: New Paths to ECU Software – Part 2 6/24AUTOSAR in practice – Life cycle of AUTOSAR ECU software

Networking Heavy-Duty Vehicles Based on SAE J1939 7/0From parameter group to plug-and-play application

CAN and J1939 under Extreme Duty Conditions 7/6Vehicle electronics guarantees functionality in cold, ice and snow

Current Trends in Network Development for Heavy-Duty Vehicles 7/14Factors of success in electronic development

Automatic Interoperability Tests for ISO11783 Systems 7/18Universal test solution assures compatibility

Wireless Analysis in a Multi-Protocol CAN Environment 7/22

Moving Communication 7/26Wireless analysis of in-vehicle networks

Prototyping and Testing CANopen Systems 7/30Reaching goals rapidly with minimal effort

Automatic Testing of CANopen Devices 7/34

Before considering Tools it is easy to have a Handle on the Process first 8/0Interview about the management of engineering and management processes in the E/E development

Tool-supported Data and Process Management at MAN Nutzfahrzeuge AG 8/2An integrated development database manages all engineering data in the E/E development process

From Pilot Studies to Production Development 8/6Efficiency and quality in calibrating transmissions

Press Book_Einleitungsseiten:Einleitungsseiten 09.02.2010 14:27 Uhr Seite d

Page 6: Vector Press Book

Se ri al Bus Sys tems in the Au to mo bile

Mo ti va tion and ad van ta ges of se ri al bus sys temsin the au to mo bileRe cent his to ry of the au to mo bile is char ac ter ized by in ten -sive elec tron i fi ca tion. The driv ing force for this orig i natespri ma ri ly from cus tom er ex pec ta tions of a mod ern au to mo -bile which are be com ing in creas ing ly de mand ing. More over,leg is la tors are con tin u al ly plac ing strict er re quire ments onex haust emis sions. The ris ing com pet i tive and cost pres suresof glo bal i za tion al so pro duce con stant in no va tive pres sure.Au to mo tive OEMs have found elec tron ics to be a way to meetthis mul ti ple chal lenge. Par tic u lar ly this is re flect ed in themi gra tion of elec tron ic con trol units (ECUs) in to the au to -mo bile which be gan at the end of the 1970s.

At that time, the first em bed ded elec tron ic sys tems still per -formed their tasks ful ly au ton o mous ly. How e ver, very ear ly itwas recog nized that by co or di nat ing ap pli ca tions placed indif fer ent ECUs, it would be pos si ble to in crease ve hi cle func -tion al i ty im mense ly. This was the mo ti va tion for in te grat ingcom mu ni ca tion sys tems in the au to mo bile.

Ahead of ev ery thing else, at that time it was elec tron ic driv -ing dy nam ics con trol that dom i nat ed ad vanced de vel op -ment. How e ver the in ten sive wir ing ef fort util iz ing in di vid u -al ded i cat ed lines on ly per mit ted lim it ed da ta ex change. As away out of this di lem ma, bit-se ri al da ta ex change via a sin -gle com mu ni ca tion chan nel came in to ques tion. This sin gle

com mu ni ca tion chan nel in te grates all in di vid u al com mu ni -ca tion chan nels and is re ferred to as a bus. Us ing this busand as so ci at ed se ri al in ter fa ces it is pos si ble to join all ECUsto geth er in to a net work re fer to as a se ri al bus sys tem (Fig -ure 1). In this con text, ECUs are re ferred to as bus nodes.

Since the in tro duc tion of se ri al bus sys tems, the com plexand of ten di ver gent types of wire har ness es in the au to mo -bile have be come a thing of the past. Bus sys tems not on lysim pli fy project de sign and in stal la tion, but al so re duce theweight and space re quired for wir ing. More over, the low er

1/0

The share of elec tron ic com po nents in the au to -mo bile is grow ing from year to year. Elec tron icsplays a de ci sive role, not on ly in sat is fy ing pri ma -ry cus tom er wish es for bet ter driv ing safe ty andcom fort, but at the same time to achieve bet terfu el econ o my and re duced ex haust emis sions. An oth eras pect that should not be un der es ti mat ed is the con -tri bu tion by nu mer ous se ri al bus sys tems in the au to -mo bile. Many func tions would not even be pos si blewith out da ta ex change be tween elec tron ic com po -nents. This ar ti cle of fers some in i tial in sights in to theworld of se ri al bus sys tems in the au to mo bile.

Mo ti va tion, ad van ta ges, tasks and ar chi tec ture of se ri al bus sys tems in the au to mo bile

Part 1:

Fig ure 1:Bus net work ing: All elec tron ic con trol units (Black:Bus nodes) are joined in to a sys tem net work, the se ri albus sys tem, by means of a bus and re lat ed se ri al in ter -fa ces.

01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1

Page 7: Vector Press Book

The most press ing tasks of a se ri al bus sys tem in clude re al-time com mu ni ca tion and da ta in teg ri ty. A dis trib ut ed sys temcan on ly ful fill its in tend ed pur pose if all da ta reach the des -ti na tion node in time and with out er rors. A se ri al bus sys -tem’s per form ance and field of ap pli ca tion in the au to mo bilesub stan tial ly de pend on the de gree with which it can avoid,re ject, de tect and cor rect er rors, and can guar an tee time lyda ta trans port.

Da ta in teg ri tyQuan ti ta tive ly da ta in teg ri ty can be de scribed as the re sid u aler ror prob a bil i ty. This is a sta tis ti cal meas ure of da ta in teg ri -ty vi o la tion. Re sid u al er ror prob a bil i ty is un der stood as theprod uct of prob a bil i ty A that the trans mit ted da ta are cor -rupt ed and prob a bil i ty B that the cor rupt ed da ta re main un -de tect ed. The da ta in teg ri ty of a se ri al bus sys tem there forede pends first on the ex tent to which it avoids the cor rup tionof da ta, and sec ond on the de gree to which it can de tect cor -rupt ed da ta.

Var i ous in ter ac tions re lat ed to elec tri cal, ca pac i tive or in -duc tive coup ling, as well as elec tro mag net ic fields, come in -to con sid er a tion as po ten tial caus es of da ta cor rup tion inthe au to mo bile. Spe cif ic sour ces re spon si ble for cor rup tionmight be ac tu a tors, fan mo tors, high-fre quen cy sig nals gen -er at ed by the com mu ta tion proc ess in DC mo tors and fast da -

num ber of con nect ors re du ces the sus cep ti bil i ty to fail uresig nif i cant ly. These many ad van ta ges face nu mer ous com -mu ni ca tion tasks that must be mas tered by the se ri al bussys tem. The most im por tant com mu ni ca tion tasks are dis -cussed in the fol low ing.

Com mu ni ca tion tasksA pre con di tion for troub le free se ri al da ta ex change is theunique al lo ca tion of the da ta to be sent to the bus nodes. Es -sen tial ly a dis tinc tion is made be tween send er-se lect ive andre ceiv er-se lect ive al lo ca tion (ad dress ing). In case of send er-se lect ive ad dress ing the send er iden ti fies the de sired re ceiv -er by a unique bus node ad dress. In con trast, in case of re -ceiv er-se lect ive ad dress ing the da ta to be sent are ad -dressed. This means in prin ci ple that all da ta are avail a blefor any node to re ceive (Broad cast). There fore all bus nodeshave the task of fil ter ing out da ta that are rel e vant to them.This is ac com plished with the help of the ad dress re ferred tohere as iden ti fi er.

In or der that the re ceiv er ac quire the da ta and ad dress asone unit, the send er packs both of them to geth er as a frame.A typ i cal frame en com pass es the ad dress and da ta with astart and end rec og ni tion, which are pri ma ri ly used to syn -chro nize send ers and re ceiv ers. A “frame” is al so re ferred toas a “mes sage”.

1/1

Fig ure 2:Con trolled and ran dom bus ac cess.

01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1/1

Page 8: Vector Press Book

ta trans mis sions or re flec tions at the ends of bus es. Themore suc cess ful ly these caus es can be elim i nat ed, the great -er the noise im mu ni ty and more re li a ble the da ta trans mis sion.

To en hance the noise im mu ni ty of a se ri al bus sys tem, cer -tain im por tant meas ures are nec es sa ry. Be sides shield ingthe trans mis sion me di um, as well as all elec tri cal and elec -tron ic com po nents, it is im por tant to pro vide suf fi cient lylarge dis tan ces be tween da ta and pow er trans mis sion linesand be tween elec tri cal and elec tron ic com po nents. Fur ther -more, it is im por tant to lim it the da ta trans mis sion fre quen -cy and num ber of da ta sig nal edg es and their steep ness, toap ply the prin ci ple of dif fer en tial sig nal trans mis sion and fi -nal ly to ter mi nate bus ends with the char ac ter is tic im pe -dance of the trans mis sion me di um. Even with op ti mal phys i -cal sys tem de sign trans mis sion er rors can not be elim i nat eden tire ly. Er ror de tec tion mech a nisms are there fore es sen tial.Among the most fre quent ly util ized meth ods is the check summeth od, where in the send er com putes a check sum from theda ta block to be sent by a de fined al go rithm. It then sendsthis check sum at the end of the da ta block. Us ing this check -sum the re ceiv er is able to ver i fy the re ceived da ta block.

The more clev er the al go rithm, the short er the da ta block tobe pro tect ed and the longer the check sum, the bet ter the al -go rithm’s er ror de tec tion abil i ty. How e ver, due to lim it edband width and time re quire ments, a com pro mise must bereached be tween er ror de tec tion abil i ty and the ra tio be -tween da ta block and check sum size (trans mis sion ef fi cien -cy). Fur ther more one must con sid er that the check sum it selfis not im mune to dis turb an ces dur ing trans mis sion.

As a rule, aft er de tect ing a trans mis sion er ror, er ror cor rec -tion is need ful, e.g. by means of an er ror-cor rect ing check -sum. How e ver, un like sim ple er ror de tec tion that would re quire an ex plicit longer check sum. For ef fi cien cy rea sonser ror-cor rect ing check sums are not im ple ment ed in the au -to mo bile. The er ror cor rec tion hap pens by re peat ing themes sage: caused ei ther by an er ror flag set by the bus nodede tect ing the er ror, or au to mat i cal ly in the case of pe ri od icmes sage trans mis sion.

Re al-time ca pa bil i tyA sys tem with re al-time ca pa bil i ty must be able to guar an teetrans mis sion of all da ta to be ex changed be tween the var i -ous bus nodes with in a de fined time win dow. Key fac tors

1/2

Fig ure 3: Sim pli fied ar chi tec -ture of se ri al bus sys tems.

01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1/2

Page 9: Vector Press Book

oth er hand, cov ers all as pects of the Phys i cal Lay er, from thephys i cal bus in ter face to phys i cal sig nal trans mis sion overthe bus.

Gen er al ly the phys i cal bus in ter face is im ple ment ed with thehelp of a tran sceiv er. A com mu ni ca tion con trol ler cov ers theDa ta Link Lay er. If all of the bus nodes with in the sys tem fol -low the same com mu ni ca tion pro to col and the same Phys i calLay er spec i fi ca tion, then the fun da men tal pre con di tions fortroub le-free da ta ex change be tween the bus nodes are sat is fied.

In se ri al com mu ni ca tion the send er’s ap pli ca tion pass es tothe com mu ni ca tion con trol ler the da ta block to be sent. Thecom mu ni ca tion con trol ler in turn adds the ad dress andcheck ing and syn chro ni za tion in for ma tion to the da ta block,there by cre at ing a frame. The tran sceiv er now trans mits theframe over the bus. In the au to mo bile the phys i cal in ter con -nec tion struc ture is gen er al ly the line to pol o gy, which is veryeasy to man age due to the pas sive bus in ter face. On the re -ceiv er side the tran sceiv er ac cepts the frame and pass es it tothe com mu ni ca tion con trol ler, which eval u ates the in for ma -tion trans mit ted to it and in case of cor rect da ta re cep tionroutes the da ta block to the ap pli ca tion.This re sults in a hi er arch i cal and there fore trans par ent com -mu ni ca tion flow. This is guar an teed by com ple tion of thecom mu ni ca tion tasks as signed to the lay ers, and by the com -mu ni ca tion pro to col and def i ni tion of the Phys i cal Lay er(Fig ure 3).

For some tasks such as bus man age ment (in clud ing Sleepand Wake-Up func tion al i ty) or di ag nos tics and con fig u ra tionof bus nodes, the com mu ni ca tion func tion al i ty pro vid ed bythe Da ta Link Lay er is in suf fi cient. By def i ni tion high er lay -ers re spec tive ly high er com mu ni ca tion pro to cols the com -mu ni ca tion func tion al i ty can be ex pand ed.

CAN, LIN, MOST and Flex RayIn ten si fied com pe ti tion is con trib ut ing to ward more andmore safe ty and con ve nience func tions in the au to mo bile.This not on ly re sults in a per ma nent in crease in the num berof elec tron ic com po nents in ve hi cles, but al so a sub stan tial lygreat er de gree of net work ing with rap id ly es ca lat ing da ta

here are the num ber and siz es of mes sa ges, the avail a bleband width, and es pe cial ly the type of bus ac cess. In the lat -ter case a fun da men tal dis tinc tion is made be tween con -trolled and ran dom bus ac cess (Fig ure 2).

In se ri al bus sys tems with con trolled bus ac cess, bus ac cessrights are al ready clear ly de fined be fore the bus ac cess. Suchsys tems of fer de ter min is tic mes sage traf fic as an im por tantpre con di tion for at tain ing re al-time ca pa ble se ri al bus sys -tems. How e ver, since the en tire com mu ni ca tion se quence isex e cut ed ac cord ing to a sched ule and can not be in flu enced,se ri al bus sys tems with con trolled bus ac cess are char ac ter -ized by poor dy nam ic be hav ior.

This dis ad van tage does not ap ply to bus sys tems with un con -trolled bus ac cess. Each bus node has the right to oc cu py thebus at any time, e.g. in re sponse to an event that just oc -curred. This pro du ces very fast bus ac cess; how e ver there isthe in her ent risk of more or less acute col li sions, de pend ingon the event den si ty, mes sage siz es and the avail a ble da tarate. These are not good con di tions for achiev ing re al-timeca pa ble da ta trans mis sion.

Mon i tor ing of the bus by bus nodes wish ing to send sig nif i -cant ly re du ces the risk of col li sion. It can be pre vent ed en -tire ly by in tro duc tion of mes sage pri or i ties. How e ver, thesebus ac cess meth ods based on bus mon i tor ing and mes sagepri or i ties can not guar an tee time li ness. It is pos si ble, thatlow-pri or i ty mes sa ges will be de layed un rea son a bly long.

Ar chi tec ture of se ri al bus sys tems and bus nodesin the au to mo bileBased on the ref er ence mod el for da ta com mu ni ca tion spec i -fied by ISO (In ter na tion al Stand ard i za tion Or gan i za tion),the se ri al in ter face of a bus node in the au to mo bile is typ i -cal ly sub di vid ed in to two (com mu ni ca tion) lay ers: A low erlay er (Phys i cal Lay er) and a lay er above it (Da ta Link Lay er).

Some of the tasks han dled by the Da ta Link Lay er are ad -dress ing, fram ing, bus ac cess, syn chro ni za tion and er ror de -tec tion and cor rec tion. These tasks are de fined by a com mu -ni ca tion pro to col. The Phys i cal Lay er spec i fi ca tion, on the

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

1/3

01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1/3

Page 10: Vector Press Book

vol umes, since most new au to mo bile func tions can not dowith out da ta ex change any longer. To keep the grow ing com -plex i ty of au to mo tive elec tron ics man age a ble, au to mo tiveOEMs cre ate dif fer ent stand ards on the sys tem, func tion aland com mu ni ca tions lev els. On the sys tem or func tion al lev -el, “AU TO SAR” (Au to mo tive Open Sys tem Ar chi tec ture) is ex -pect ed to pro vide the nec es sa ry trans par en cy in the fu ture.Non-pro pri e tary com mu ni ca tion stand ards such as CAN, LIN,MOST and Flex Ray pro vide great er trans par en cy on the com -mu ni ca tions lev el.

CAN (Con trol ler Ar ea Net work) is used pri ma ri ly in the pow -er train, chas sis and con ve nience ar e as. LIN (Lo cal In ter con -nect ed Net work) serves to achieve sim ple and cost-ef fect iveda ta trans mis sion in the sen sor/ac tu a tor ar ea. MOST (Me diaOri ent ed Sys tem Trans port) is im ple ment ed in in fo tain mentto trans mit vid eo and au dio sig nals. Fi nal ly, Flex Ray en a blesthe most chal leng ing com mu ni ca tion in safe ty-crit i cal dis -trib ut ed ap pli ca tions. Fig ure 4 shows an ex am ple of ECU net -work ing with se ri al bus sys tems in a mod ern au to mo bile. Incon trast to CAN, LIN and MOST, how e ver, Flex Ray must firstbe come es tab lished in the au to mo bile. This fall the firstFlex Ray pro duc tion ap pli ca tion will hit the streets. The Mu -nich au to mo tive pro duc er BMW is in tro duc ing the in no va tivebus sys tem in an ac tive sus pen sion con trol sys tem on its newX5 au to mo bile.

CAN was de vel oped in the ear ly 1980s by Rob ert BoschGmbH, and in 1994 it be came an in ter na tion al stand ard (ISO 11898). Three of Vec tor’s ex ec u tive di rect ors played key roles in its de vel op ment, and in 1988 they found ed Vec tor In for ma tik GmbH. LIN, MOST and Flex Ray em a nat edfrom non-pro pri e tary or gan i za tions: The LIN Con sor ti um(www.lin-sub bus.org), MOST Co op er a tion (www.most co op er -a tion.com) and Flex Ray Group (www.flex ray.com). Al thoughthey have not been of fi cial ly stand ard ized, they can be con -sid ered de-fac to stand ards.

Re li a ble part ner for ECU net work ing and da taex changeThe spe cial ists at Vec tor sup port au to mo tive OEMs and sup -pli ers in CAN, LIN, Flex Ray and MOST net work ing with a uni -ver sal tool chain of de sign and de vel op ment tools as well assoft ware com po nents and base soft ware for AU TO SAR ECUs.Ad vis ing, con sult ing serv i ces and tools for proc ess man age -ment sup ple ment the ap pli ca tion ar e as. Its serv i ces are com -ple ment ed by a broad-based train ing pro gram on Vec tortools, soft ware com po nents and se ri al bus sys tems.

For en try-lev el work in au to mo tive ECU net work ing or da taex change the Stutt gart-based com pa ny of fers the one-daysem i nar “Se ri al bus sys tems in the au to mo bile”. Fun da men -tals sem i nars on CAN, LIN, Flex Ray and MOST are best suit ed as in tro duc tions to the var i ous de vel op ment ac tiv i ties re lat ed to au to mo tive elec tron ics. Ad di tion al in for ma tionand sched ules one can find on the In ter net: www.vec tor-in for ma tik.com

Out lookParts 2-5 of this se ries ad dress the se ri al bus sys tems CAN,LIN, Flex Ray and MOST in de tail.

1/4

Au thor:

Eu gen May er (Grad u ate En gi neer with Tech -ni cal Teach ing Cer tif i cate), aft er com plet inghis voc a tion al train ing to be come a com mu -ni ca tions tech ni cian, stud ied elec tron ics atthe Tech ni cal Col lege in Rav ens burg/We in-g ar ten, Ger ma ny, and stud ied elec tri cal en gi neer ing and voc a tion al teach ing at theUni ver si ty of Stutt gart. Since 1999 he hasbeen work ing at Vec tor In for ma tik where he

is em ployed as a Sen ior Train er.Tel. +49-711/80670-574, Fax +49-711/80670-111,E-Mail: eu gen.may er@vec tor-in for ma tik.de

01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1/4

Page 11: Vector Press Book

Developing automotive

once you have learned how to do it.

Whether you are new to the field of automotive electronics or

are an experienced pro, at the VectorAcademy you will cer-

tainly find the right workshop for your knowledge level. Your

benefit: You just sign up for the learning modules that you

really need.

CAN, LIN, FlexRay, MOST, AUTOSAR, Embedded Software...

instead of searching for answers in the books, quiz our trai-

ners. This is the most effective way to acquire knowledge and

skills. We guide you through practice-oriented exercises. And

you have the opportunity to share your experiences with col-

leagues from your field.

Don‘t settle for less. And it costs less than you might think.

Get a quick overview at our web pages.

www.vector-academy.com

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. 07 11 / 8 06 70-0

www.vector-academy.com

Want to try something new?

Visit our free of charge

E-Learning Portal:

www.vector-elearning.com

01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1/5

Page 12: Vector Press Book

Se ri al Bus Sys tems in the Au to mo bile

CAN stand ard, im ple men ta tion and in ter faceThe CAN tech nol o gy de vel oped by Bosch [1] has been stand -ard ized since 1993 and ex ists as ISO Stand ard 11898 which isor ga nized in sev er al parts (Fig ure 1). The first part con tainsthe CAN pro to col and cov ers the en tire da ta link lay er (fram -ing, ad dress ing, bus ac cess, da ta as sur ance) and part of thephys i cal lay er (phys i cal sig nal ing) of the stand ard ized ref er -ence mod el for da ta com mu ni ca tion (ISO 7498). In themean time a large num ber of cost-ef fect ive CAN con trol lershave be come avail a ble which im ple ment the CAN pro to col inhard ware.

The sec ond part de scribes the CAN High-Speed phys i cal lay -er, and the third part the CAN Low-Speed phys i cal lay er. The-se two parts cov er the Phys i cal Lay er of ISO 7498 (in clud ing

phys i cal bus in ter face, da ta rates and volt age lev els). TheCAN High-Speed phys i cal lay er is used pri ma ri ly in pow er -train and chas sis ap pli ca tions. It is es sen tial ly im ple ment edby the CAN High-Speed tran sceiv er, which sup ports a max i -mum da ta rate of 1 MBit/s. The CAN Low-Speed tran sceiv erwith a max i mum da ta rate of 125 KBit/s is gen er al ly used forthe CAN Low-Speed phys i cal lay er that is pri ma ri ly used inthe body/con ve nience ar ea.

Ac cord ing ly the CAN in ter face (Fig ure 2) con sists of a CANcon trol ler and a CAN tran sceiv er. While the CAN con trol lerhan dles the CAN pro to col, the CAN tran sceiv er as sumes thetask of phys i cal ly coup ling the CAN con trol ler to the CAN busop er at ed in dif fer en tial sig nal mode. Dif fer en tial sig naltrans mis sion en han ces noise im mu ni ty and re quires two

1/6

The re lent less pace of glo bal i za tion has brought grow ing com pet i tive pres sure to bear on au to mo tive OEMs and sup pli ers, which in turn leads to one in no va tive of fen sive aft eran oth er. Elec tron ics plays a de ci sive role here: In creas ing ly com plex elec tron ic sys temspro vide for a high lev el of safe ty and com fort in car driv ing. The CAN (Con trol ler Ar eaNet work) se ri al bus sys tem makes a cru cial con tri bu tion here with to its spe cif ic prop er -ties. It as sures re li a ble da ta ex change even un der harsh en vi ron men tal con di tions forex am ple. This tech ni cal ar ti cle is in tend ed to serve as an in tro duc tion to CAN tech nol o gy.

Re li a ble da ta ex change in the au to mo bile with CANPart 2:

Fig ure 1:CAN in the ref er encemod el for da ta com -mu ni ca tion (ISO7498), CAN stand ardand im ple men ta tion.

02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1

Page 13: Vector Press Book

hard ware or soft ware of ex ist ing bus nodes. How e ver this ison ly true if the add ed bus node is ex clu sive ly a re ceiv er.

Event con trolThe mes sa ges that are trans mit ted in a CAN net work andtheir se quence do not de pend on a time pro gres sion, rath erthey de pend on the oc cur rence of spe cial events. Each CANnode is in prin ci ple au thor ized to ac cess the CAN bus im me -di ate ly aft er an event oc curs. Giv en its rel a tive ly short mes -sage length of max. 130 bits in stand ard for mat and its highda ta trans fer rate of up to 1 MBit/s, this meth od en a blesquick re ac tions to asyn chro nous events. This is an im por tantpre con di tion for re al-time ca pa ble da ta trans mis sion in themil li sec ond range (1 to 10 ms), which is pri ma ri ly a re quire -ment of pow er train and chas sis ap pli ca tions.

Since CAN com mu ni ca tion is not based on any time sched ulethe mes sage traf fic is not de ter mined un til run time, and thisim plies that it car ries the in her ent risk of col li sions. This riskin creas es with in creas ing bus load, and it calls the re al-timeca pa bil i ty of the sys tem in to ques tion. To as sure re al-timeda ta trans mis sion in spite of ran dom bus ac cess, theCSMA/CA bus ac cess meth od is util ized in the CAN net work.

com mu ni ca tion lines (CAN-High and CAN-Low line), whichare ter mi nat ed with the char ac ter is tic line im pe dance toavoid re flec tions at the ends.

Mes sage dis tri bu tionMes sage ad dress es and mes sage fil ters are used in a CANnet work to or ga nize nodes and mes sa ges. Mes sage ad dress -es, com mon ly re ferred to as Iden ti fi ers (ID) do not iden ti fythe CAN tar get nodes, rath er they iden ti fy the mes sa gesthem selves, so that in prin ci ple all CAN mes sa ges are avail a -ble to be re ceived by all CAN nodes (mes sage dis tri bu tion).By means of a fil ter each CAN node se lects those CAN mes sa -ges from the mes sage stream that are rel e vant to it (re ceiv -er-se lect ive sys tem). The 11 bit wide ID per mits spec i fi ca tionof up to 2048 CAN mes sa ges in a CAN net work.

Mes sage dis tri bu tion of fers the fol low ing ad van ta ges:> Cost sav ings by shared use of sen sors, > Easy im ple men ta tion and syn chro ni za tion of dis trib ut ed

proc ess es, and above all:> High flex i bil i ty with re gard to the con fig u ra tion.This is be cause omit ting node ad dress es makes it pos si ble toin te grate oth er bus nodes with out hav ing to mod i fy the

1/7

Fig ure 2:CAN in ter face andCAN net work.

02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/7

Page 14: Vector Press Book

1/8

CSMA/CA bus ac cess meth odBus ac cess be gins when a CAN node wish ing to send first lis -tens to the CAN bus (Car ri er Sense – CS). If the CAN bus isavail a ble the CAN node may be gin to trans mit its mes sageim me di ate ly. On the oth er hand, if it de tects bus ac tiv i ty itmust post pone its send re quest un til the CAN bus is avail a bleand the cur rent ly run ning mes sage trans mis sion has beencom plet ed; in ad di tion it must wait a du ra tion of three bittimes (ITM In ter mis sion). An on go ing mes sage trans mis sionis not in ter rupt ed in this meth od – bus ac cess is non de struc tive.

If there are mul ti ple CAN nodes wish ing to send, bit wise ar -bi tra tion (Fig ure 3) pre vents col li sions from oc cur ring in spite of si mul ta ne ous bus ac cess (Mul ti ple Ac cess – MA). Inthe frame work of bit wise ar bi tra tion all CAN nodes wish ingto send place the IDs of the CAN mes sa ges they wish to sendbit wise on the bus, from the hi ghest to the low est sig nif i cantbit. The wired-AND bus log ic (0=dom i nant) that forms theba sis of the CAN net work en sures that there is al ways an un -am big u ous bus lev el. Aft er add ing on an ID bit, each CANnode com pares the bus lev el with the lev el it sent. The ar bi -tra tion log ic de cides wheth er a CAN node may con tin ue tosend or wheth er it must stop send ing. At the end of the ar bi -

tra tion phase the CAN node that gets send au thor i za tion isthe node trans mit ting the CAN mes sage with the least sig nif -i cant iden ti fi er. Low er pri or i ty CAN nodes first switch to theRx state and ac cess the CAN bus for a re newed send at temptas soon as the bus is free again.

Not on ly do the bus and ar bi tra tion log ic pre vent col li sions(Col li sion Avoid ance – CA), they al so pro vide pri or i ty-con -trolled bus ac cess: The low er the sig nif i cance of the iden ti fi -er, the high er the pri or i ty of the CAN mes sage, and this re -sults in fast er bus ac cess. The CAN mes sage with the small estiden ti fi er (ID=0) will there fore be trans mit ted with out de lay.

If the bus load is not too high, this type of ran dom, non de -struc tive, pri or i ty-driv en bus ac cess fa cil i tates cor rect andvery fast bus ac cess. On the one hand, it should be not edthat de lays grow with in creas ing bus load, above all de lays oflow pri or i ty CAN mes sa ges. In the worst case a sit u a tion mayarise in which CAN mes sa ges ar rive too late at re ceiv ers orare sup pressed en tire ly. On the oth er hand, the CSMA/CA busac cess meth od pro du ces a re cip ro cal re la tion ship be tweennet work ex ten sion and max i mum da ta rate. Dur ing bit wisear bi tra tion a re ces sive ly send ing CAN node must be able to

Fig ure 3:Wired-AND bus log ic,ar bi tra tion log ic andbit wise ar bi tra tionbased on ex am ple oftwo CAN nodes.

02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/8

Page 15: Vector Press Book

Fol low ing the SOF is the ID, which may be ei ther 11 bits(Stand ard-ID) or 29 bits (Ex tend ed-ID) in length. The stand -ard for mat dom i nates in the au to mo tive field. The ex tend edfor mat typ i cal ly plays a role in con junc tion with high er lev elpro to cols such as SAE J1939. The ID for mat be ing used is in -di cat ed by the IDE (Iden ti fi er Ex ten sion) bit. An oth er bitswitch (RTR bit – Re mote Trans mis sion Re quest) in di cateswheth er the frame is a Da ta or Re mote frame.

The 64 bit wide da ta field is avail a ble for trans mit ting use fulin for ma tion, in which the ex act num ber of use ful bytes is in -di cat ed by a DLC (Da ta Length Code). Fol low ing the da tafield is the so-called CRC se quence (CRC – Cy clic Re dun dan cyCheck). The send er gen er ates the CRC se quence based on allbits to be trans mit ted, a gen er a tor pol y no mi al and a well-de fined al go rithm. In de pend ent of the mes sage fil ter ing thesame proc ess oc curs at the re ceiv ing end with the ar riv ingbits. The two se quen ces are com pared, and the ac knowl edg -ment is made aft er the re ces sive CRC de lim it er in the Ac -knowl edge slot (ACK slot). At the end of a Da ta frame, aft erthe re ces sive ACK de lim it er, comes the sev en bit long and re -ces sive EOF (End of Frame).

Da ta pro tec tionThe prob a bil i ty that cor rupt ed CAN mes sa ges will re main un de tect ed is ex traor di na ri ly low. It is es ti mat ed to be 4.7 x10-11 [2]. Re spon si ble for this are er ror de tec tion mech a -nisms de fined in the CAN pro to col. On the re ceiv er side, be -sides the mes sage-fil ter ing-in de pend ent CRC that is ca pa ble

re li a bly de tect a dom i nant lev el. The bit time in ter val shouldthere fore be sized such that sig nal prop a ga tion times on theCAN bus are ful ly com pen sat ed. A length ex ten sion to a net -work there fore ne ces si tates a longer bit time in ter val, whichin turn de fines a max i mum us a ble da ta rate.

Da ta trans mis sionIt is pri ma ri ly Da ta frames that are re spon si ble for da tatrans mis sion in the au to mo bile (Fig ure 4). While in fact Re -mote frames al so ex ist for re quest ing da ta, they are hard lyev er used since da ta trans mis sion in the au to mo bile is nottyp i cal ly re quest-based, rath er it is pri ma ri ly pro vid ed onthe in for ma tion gen er a tor’s own in i ti a tive. The two types offrames have iden ti cal lay outs; the on ly dif fer ence is that theda ta field is omit ted in the Re mote frame.

A ba sic pre req ui site for trans mit ting Da ta and Re mote fra-mes is syn chro nism be tween send er and re ceiv er. Since aclock line has been omit ted for rea sons of cost and ef fort,syn chro nism is achieved by sig nal edg es and a well-de finedre syn chro ni za tion mech a nism. Each mes sage trans mis sionbe gins with trans mis sion of the dom i nant syn chro ni za tionbit (SOF – Start of Frame) and this gen er ates the first sig naledge (Bus-Idle ex hib its a re ces sive bus lev el). The re ceiv eren sures syn chro ni za tion over the en tire trans mis sion byeval u at ing each ar riv ing sig nal edge and adapt ing its ownbit tim ing as nec es sa ry. The bit stuff ing meth od en sures thata com ple men ta ry bit (stuff bit) ap pears at the lat est aft erfive ho mo ge ne ous bits, there by pro vid ing a sig nal edge.

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

1/9

Fig ure 4: Structure of the Data frame.

02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/9

Page 16: Vector Press Book

of de tect ing up to five er rors with in a CAN mes sage, checksare al so made of the for mat (Form Check) and bit stuff ingrule (Stuff Check). The send er per forms bit mon i tor ing andeval u ates the ACK slot.

If one as sumes an er ror rate of 10-3 in a CAN net work, thengiv en an an nu al op er at ing time of 1000 hours, a da ta rate of500 KBit/s, a mean bus load of 25 per cent and a mean mes -sage length of 80 bits, sta tis ti cal ly speak ing a cor rupt ed CANmes sage will re main un de tect ed by the CAN pro to col justonce ev ery 4000 years. What is un der stood as the er ror rateis the ra tio of cor rupt ed CAN mes sa ges to the num ber of alltrans mit ted CAN mes sa ges.

As soon as an er ror de tec tion mech a nism sig nals a trans mis -sion er ror, the CAN node de tect ing the er ror ter mi nates mes -sage trans mis sion by plac ing an er ror flag (six dom i nantbits) on the CAN bus. The er ror flag in ten tion al ly vi o lates thebit stuff ing rule so that net work-wide each CAN node per -ceives what un til then was a lo cal er ror and re sponds by ter -mi nat ing the mes sage trans mis sion, i.e. by ap pend ing an er -ror flag. This meth od as sures net work-wide da ta con sist en cywhich is so im por tant in dis trib ut ed ap pli ca tions.

Er ror cor rec tion con sists of rep e ti tion of the abort ed CANmes sage by the same send er as soon as the CAN bus is freeagain (aft er the er ror de lim it er and ITM). In de sign ing thesys tem it must be con sid ered that the CSMA/CA bus ac cessmeth od does not guar an tee im me di ate rep e ti tion. The er rorre cov ery time de pends on the pri or i ty of the mes sage andthe bus load.

Node mon i tor ingEr ror sig nal ing by er ror flag gives each CAN node the ca pa -bil i ty of ter mi nat ing on go ing mes sage trans mis sions. Sincethis al so ap plies to de fective CAN nodes, such nodes are ca -pa ble of bring ing the en tire CAN com mu ni ca tion to a stand -still. To pre vent this each CAN node has net work node mon i -tor ing (Fig ure 5) that can dis con nect (Bus off) a node foundto be de fective based on er ror coun ters and rules for con trol -ling the er ror coun ters.

Ac knowl edg ment of re ceived CAN mes sa gesIn a CAN net work each mes sage trans mis sion is ac knowl -edged si mul ta ne ous ly by all re ceiv ers in the ACK slot (in-fra-me ac knowl edge ment), in de pend ent of mes sage fil ter ing. Adom i nant lev el sig ni fies to a pos i tive ac knowl edg ment, anda re ces sive lev el sig ni fies a neg a tive ac knowl edg ment. Sincethe send er pla ces a re ces sive lev el in the ACK slot, just onepos i tive ac knowl edg ment is suf fi cient to con firm a cor rectmes sage trans mis sion. Be cause of this node-neu tral pos i tiveac knowl edge ment, neg a tive ly ac knowl edg ing CAN nodes areover writ ten and re main un heard. There fore they send an er -ror flag aft er the ACK de lim it er.If not a sin gle pos i tive ac knowl edg ment is re ceived, that isthe ACK slot is not over writ ten by any re ceiv er, the send erde tects an ACK er ror and aborts the on go ing mes sage trans -mis sion by send ing an er ror flag.

Out lookUn til just a few years ago CAN was the most sought aft er bustech nol o gy in the au to mo tive in dus try. The re lent less elec -tron i fi ca tion of the ve hi cle has caused CAN to en coun ter lim -its. Ve hi cle de vel op ers are ques tion ing the suit a bil i ty of theCAN bus es pe cial ly in band width-in ten sive, re al-time, crit i caland high ly safe ty-crit i cal mo tor ve hi cle ap pli ca tions such as

1/10

Fig ure 5:Net work node mon i tor ing us ing two er ror coun ters andthree node states.

02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/10

Page 17: Vector Press Book

ready been pub lished at the In ter net site of the Vec tor Acad -e my [4].

Lit er a ture and In ter net links:[1] www.bosch.com[2] Un ruh, J., Mat ho ny, H.J., Kai ser, K.H.: Er ror De tec tion Anal y sis of Au to -

mo tive Com mu ni ca tion Pro to cols, SAE In ter na tion al Con gress 1990. [3] www.vec tor-in for ma tik.de[4] www.vec tor-acad e my.de[5] May er, E.: Ser i el le Buss ys teme im Au to mob il – Ar chi tek tur, Auf ga ben

und Vor tei le [“Se ri al bus sys tems in the au to mo bile – Ar chi tec ture,tasks and ad van ta ges”]. El ek tron ik Au to mo tive 7/2006, pp. 70ff.

the “Lane Keep ing As sist ance” driv er as sist ance sys tem, butal so in cost-sen si tive con ve nience ap pli ca tions. There fore be sides CAN two oth er bus tech nol o gies have be -come es tab lished over the course of time for use in the au to -mo bile or they are on an ide al course in that di rec tion. Weare talk ing about LIN and Flex Ray here. LIN (Lo cal In ter con -nect ed Net work) is al ready be ing used for cost-ef fect ive net -work ing of sen sors and ac tu a tors in the con ve nience ar ea.Flex Ray is on the verge of be ing im ple ment ed in re al-timeand safe ty-crit i cal au to mo tive ap pli ca tions due to its time-trig gered com mu ni ca tion meth od, a da ta rate of up to 20MBit/sec and the pos si bil i ty of send ing over two com mu ni ca -tion chan nels. In its first pro duc tion ap pli ca tion world wideFlex Ray will be im ple ment ed in an ac tive sus pen sion con trolsys tem on the new BMW X5.

Re li a ble ECU net work ing and da ta ex changeThe spe cial ists at Vec tor In for ma tik [3] sup port au to mo tiveOEMs and sup pli ers, not on ly in CAN net work ing but al so inthe LIN, Flex Ray and MOST bus sys tems. For cus tom er pro -jects we of fer uni ver sal tool chains of de sign and de vel op -ment tools, op tion al ly with soft ware com po nents and basesoft ware for AU TO SAR con trol mod ules. These pro ducts aresup ple ment ed by cus tom er sup port, con sult ing serv i ces andtools for proc ess man age ment in var i ous ap pli ca tion ar e asthat en a ble cus tom ized ad ap ta tions to spe cif ic re quire -ments. These serv i ces are round ed out by a com pre hen sivetrain ing pro gram cov er ing Vec tor tools, soft ware com po -nents and se ri al bus sys tems.For an in tro duc tion to ECU net work ing or da ta ex change inthe au to mo bile the Stutt gart-based com pa ny of fers the one-day sem i nar “Se ri al bus sys tems in the au to mo bile”. Fun da -men tals sem i nars on CAN, LIN, Flex Ray and MOST con vey theba sic knowl edge need ed to quick ly gain fa mil i ar i ty with themany dif fer ent de vel op ment ac tiv i ties re lat ed to au to mo tiveelec tron ics [4].

The first part of this se ries of ar ti cles [5] ad dressed se ri albus sys tems in the au to mo bile in gen er al terms. Up com ingar ti cles three through five will dis cuss the LIN, Flex Ray andMOST se ri al bus sys tems. In ter est ed read ers will find sup ple -men tal and in-depth in for ma tion on these top ics that has al -

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

1/11

Au thor:

Eu gen May er (Grad u ate En gi neer with Tech -ni cal Teach ing Cer tif i cate), aft er com plet inghis voc a tion al train ing to be come a com mu -ni ca tions tech ni cian, stud ied elec tron ics atthe Tech ni cal Col lege in Rav ens burg/We in-g ar ten, Ger ma ny, and stud ied elec tri cal en gi neer ing and voc a tion al teach ing at theUni ver si ty of Stutt gart. Since 1999 he hasbeen work ing at Vec tor In for ma tik where he

is em ployed as a Sen ior Train er.Tel. +49-711/80670-574, Fax +49-711/80670-111,E-Mail: eu gen.may er@vec tor-in for ma tik.de

02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/11

Page 18: Vector Press Book

1/12

Se ri al Bus Sys tems in the Au to mo bile

Why an oth er da ta bus in the au to mo bile?Grow ing de mands of car us ers for driv ing con ve nien ces have led to

wide-ran ging elec tron i fi ca tion in this ar ea of ve hi cle tech nol o gy.

This is re flect ed in the mi gra tion of nu mer ous elec tron ic com po -

nents in to the con ve nience ar ea. For a long time it was usu al prac -

tice to in ter con nect the con tin u ous ly in creas ing num ber of sen sors,

ac tu a tors, step per mo tors and DC mo tors di rect ly to a cen tral con -

trol mod ule.

This trend grad u al ly met with crit i cism: It led to a rap id in crease in

wir ing costs, along with great er space re quire ments, in creas ing

weight and sig nif i cant ly great er sus cep ti bil i ty to faults. In ad di -

tion, grow ing in di vid u al i za tion re quired many dif fer ent wire har -

ness and con nect or var i ants, which in turn made pro duc tion, in -

stal la tion and main te nance con sid er a bly more dif fi cult.

De vel op ers quick ly recog nized that net work ing of com po nents over

a bus sys tem would be an ide al so lu tion in this au to mo tive ap pli ca -

tion do main too. How e ver, since the CAN bus was not a can di date

for use in the cost-sen si tive sen sor/ac tu a tor ar ea, many au to mo tive

OEMs and sup pli ers be gan to de vel op their own sen sor/ac tu a tor bus

sys tems as ear ly as the mid-1990s.

This grad u al ly re sult ed in the cre a tion of nu mer ous cost-ef fect ive

and sim ple yet pro pri e tary sen sor/ac tu a tor bus es. In the year 2000

LIN ar rived on the “net work ing mar ket” as an oth er se ri al bus sys -

tem for the sen sor/ac tu a tor ar ea. This tech nol o gy has pre vailed on

a broad front, and LIN can now be found in near ly all ve hi cles, typ i -

cal ly in con ve nience ap pli ca tions such as cli mate con trol, seat ad -

just ment, door con trols and mir ror ad just ment.

LIN Con sor ti um as sists in break throughAn im por tant rea son for the quick es tab lish ment of LIN was the

found ing of the LIN Con sor ti um [1], which prom i nent au to mo tive

OEMs and sup pli ers as well as sem i con duct or and tool man u fac tur -

ers had joined. Its goal was to cre ate a cross-OEM com mu ni ca tion

stand ard for the sen sor/ac tu a tor ar ea. With def i ni tion of a sim ple

and cost-ef fect ive Phys i cal Lay er based on ISO stand ard 9141, as

well as a sim ple and lean com mu ni ca tion pro to col, the LIN Con sor -

ti um has laid the foun da tion for suc cess. It set the stage for im ple -

men ta tion of sim ple and cost-ef fect ive bus nodes.

The LIN Con sor ti um not on ly fo cused on LIN com mu ni ca tion it self,

but al so pro vid ed a de vel op ment meth od ol o gy (LIN Work Flow), and

this fur ther ed ac cept ance of the bus sys tem in the au to mo tive in -

dus try sig nif i cant ly. LIN Work Flow makes it is pos si ble to au to mate

the de vel op ment of a LIN net work (LIN Clus ter), with re sult ing time

and cost sav ings. The cor ner stones of the de vel op ment meth od ol o -

gy are two da ta ex change for mats used to de scribe the en tire LIN

Clus ter and in di vid u al LIN nodes uni form ly (Fig ure 1).

Fig ure 1:LIN Work Flow: The stand ard ized and quick path to theLIN Clus ter.

In just a very short time the LIN bus has es tab lished it self as thetech nol o gy of choice for sim ple and cost-ef fect ive da ta ex changein the au to mo bile. To day, many au to mo tive OEMs are re ly ing onLIN to trans mit non-crit i cal sig nals in the body/con ve nience ar ea.The fol low ing ar ti cle points out the rea sons for the vic to ry of LIN(Lo cal In ter con nect Net work) in the au to mo bile and ex plains theun der ly ing tech nol o gy.

Sim ple and cost-ef fect ive da ta ex change in theau to mo bile with LIN

Part 3:

03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 1

Page 19: Vector Press Book

1/13

Serv ing to de scribe an en tire LIN Clus ter are the uni form syn tax

(LIN Con fig u ra tion Lan guage) and the stand ard ized LIN De scrip -

tion File (LDF). De fined in the LDF are all of a LIN Clus ter’s prop er -

ties, in par tic u lar com mu ni ca tion re la tion ships. Gen er a tor tools

util ize the LDF to gen er ate the soft ware com po nents need ed for LIN

com mu ni ca tion. Ad di tion al ly, the LDF pro vides nec es sa ry in for ma -

tion to anal y sis, meas ure ment and test ing tools and rest-of-bus

em u la tors.

Sim i lar ly, the de scrip tion of in di vid u al LIN nodes (LIN Slaves) is

giv en struc ture by the uni form syn tax of the Node Ca pa bil i ty Lan -

guage and stand ard ized Node Ca pa bil i ty Files (NCF). The NCF de -

scribes the per form ance char ac ter is tics of a LIN Slave (in clud ing

frame and sig nal def i ni tions, bit rates, di ag nos tics) and in the fra-

me work of sys tem de sign it rep re sents the foun da tion for au to mat -

ed gen er a tion of the LDF.

The two date ex change for mats and the con fig u ra tion proc ess de -

fined in the LIN spec i fi ca tion let us ers im ple ment a LIN Slave type

(e.g. step per mo tor) mul ti ple times in a LIN Clus ter or use a LIN Sla-

ve in dif fer ent LIN Clus ters (re us a bil i ty of LIN Slaves).

Mak ing just as im por tant a con tri bu tion to the suc cess of LIN is de -

tailed doc u men ta tion of the spec i fi ca tion. LIN spec i fi ca tion 2.1

[2], in ex is tence since No vem ber 2006, de fines the Phys i cal Lay er,

com mu ni ca tion pro to col, LIN Work Flow, LIN API as well as di ag nos -

tics and con fig u ra tion of the LIN nodes.

Sin gle-wire com mu ni ca tion at rates up to 20 KBit/secThe goal of cre at ing a low-cost com mu ni ca tion pro to col for se ri al

da ta ex change in the non-safe ty-crit i cal sen sor/ac tu a tor ar ea pri -

ma ri ly af fect ed the de sign of the Phys i cal Lay er. Phys i cal sig nal

trans mis sion in a LIN Clus ter does not in volve use of the dif fer en tial

sig nal trans mis sion fa mil iar from CAN, rath er a con ven tion al sin gle-

wire line is used. To as sure suf fi cient noise im mu ni ty in spite of this

meth od, the sup ply volt age and ground of the ECU elec tron ics are

used as ref er ence volt a ges for the bus lev el. A LIN tran sceiv er ser-

ves as the phys i cal bus in ter face. A lev el at least 40 % be low the

sup ply volt age is in ter pret ed by the re ceiv er as a log i cal “0”. Re -

ceiv ers in ter pret a lev el at least 60 % above the sup ply volt age as a

log i cal “1”.

The max i mum da ta rate is lim it ed to 20 KBit/sec to keep noise emis -

sions with in lim its. For line lengths up to 40 me ters the max i mum

rec om mend ed node count is 16. This takes in to ac count the node

and line ca pac i tan ces as well as the max i mum al low a ble time con -

stant of the LIN Clus ter pre scribed in the LIN spec i fi ca tion.

In terms of cir cuit tech nol o gy a LIN Clus ter is equiv a lent to an Open

Col lect or cir cuit. A pull-up re sis tor en sures that the bus lev el re -

mains near ly at the lev el of the sup ply volt age (High lev el) while

the Tx tran sis tors of all LIN nodes are in hib it ed. The bus lev el is pul-

led to near ly ground lev el (Low lev el) as soon as one of the Tx tran -

sis tors is en a bled. Ac cord ing ly, the Low state is re ferred to as the

dom i nant lev el and the High state as the re ces sive lev el.

Mas ter-Slave com mu ni ca tionCom mu ni ca tion in a LIN Clus ter is based on a Mas ter-Slave ar chi tec -

ture. A clus ter con sists of a Mas ter node (LIN Mas ter) and at least

one Slave node (LIN Slaves). For cost rea sons, ex plicit com mu ni ca -

tion con trol lers are not used. In stead LIN com mu ni ca tion is im ple -

ment ed by soft ware tasks in ev ery node, the so-called Slave tasks.

The LIN Mas ter al so has a Mas ter task that is used to co or di nate

clus ter com mu ni ca tion (Fig ure 2).

Co or di na tion is achieved by means of pe ri od ic ex e cu tion of the LIN

Sched ule that is or ga nized in frame slots (Fig ure 3). At the be gin -

Fig ure 2:Mas ter-Slave com mu -ni ca tion ar chi tec ture:All LIN nodes have aSlave Task to par tic i -pate in com mu ni ca -tion in a LIN Clus ter.One LIN node al sohas a Mas ter Task forcon trol ling the LINcom mu ni ca tion.

03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 2

Page 20: Vector Press Book

An ID serves to del e gate com mu ni ca tion; it is six bits in length and

is pro tect ed by two par i ty bits with even par i ty and odd par i ty. The

ID and two par i ty bits to geth er are re ferred to as the PID (Pro tect ed

Iden ti fi er). The first 60 IDs are avail a ble for use ful da ta com mu ni -

ca tion. The last four iden ti fi ers, ID 60 through 63, are re served (of

which ID 60 and ID 61 are used for di ag nos tic pur pos es).

The frame re sponse is com posed of up to eight da ta bytes and a

check sum for er ror de tec tion. A dis tinc tion is made be tween the

clas sic and ex tend ed check sum. The clas sic check sum is the in vert -

ed mod u lo-256 sum of all da ta bytes. There is a trans mis sion er ror if

re sult of add ing the mod u lo-256 sum to the ar riv ing da ta bytes

does not equal “0xFF”. The ex tend ed check sum al so con sid ers the

PID in form ing the in vert ed mod u lo-256 sum.

Since the LIN Slaves are usu al ly equipped with very sim ple and low-

cost mi cro con trol lers, not on ly are they al lowed to de lay trans mis -

sion of the frame re sponse a lit tle (Re sponse Space), but they may

al so in sert send ing pause (In ter byte Spa ces) be tween trans mis -

sions of SCI frames. Over all, this may length en the frame re sponse

by 40 per cent. The same ap plies to the frame head er, pri ma ri ly be -

cause there are dif fer ent meth ods for gen er at ing the Sync Break. It

is ab so lute ly es sen tial to con sid er the 40 per cent time re serve in

de sign ing the LIN Sched ule.

Spo rad ic, Event Trig gered and Di ag nos tic FramesThe LIN spec i fi ca tion con tains pro vi sions for mak ing the com mu ni -

ca tion cy cle that is rig id ly de fined by the LIN Sched ule more flex i -

ble and eco nom i cal. The two frame types “Spo rad ic Frame” and

“Event Trig gered Frame” are pro vid ed for this pur pose. In in tro duc -

ing these sup ple men tal frame types it has be come com mon prac tice

to re fer to the con ven tion al LIN frame as an Un con di tion al Frame.

ning of each frame slot the Mas ter Task trans mits a frame head er

with a Frame Iden ti fi er (ID), which all LIN Slaves eval u ate in their

Slave Task. Im me di ate ly aft er the frame head er a LIN Slave trans -

mits the frame re sponse as so ci at ed with the ID. The LIN Frame,

con sist ing of the frame head er and frame re sponse, is avail a ble to

be re ceived by ev ery LIN node (Broad cast ing) due to ID-based mes -

sage ad dress ing.

Da ta trans mis sion by LIN framesDue to the lack of a com mu ni ca tion con trol ler, se ri al da ta trans mis -

sion in a LIN Clus ter is han dled over the mi cro con trol ler’s se ri al in -

ter face (Se ri al Com mu ni ca tion In ter face - SCI) and is per formed

byte-by-byte. The SCI trans mits each byte with the LSB (Least Sig -

nif i cant Bit) first, and the byte is framed by a start bit and a stop

bit (SCI frame). That is, a LIN frame is com posed of a com bi na tion

of a num ber of SCI frames dis trib ut ed be tween the frame head er

and frame re sponse (Fig ure 4).

In trans mit ting the frame head er the LIN Mas ter per forms two key

com mu ni ca tion tasks: It syn chro ni zes the LIN Slaves and del e gates

com mu ni ca tion by as sign ing a send er and one or more re ceiv ers to

the frame re sponse.

Due to cost sen si tiv i ty is sues, the LIN Slaves may use on-chip res o -

na tors with a fre quen cy tol er ance of up to 14 per cent. There fore the

LIN Mas ter trans mits a Sync Break first to let all LIN Slaves know

that trans mis sion of a LIN Frame is be gin ning. The Sync Break is

made up of at least 13 con sec u tive dom i nant bits, and it elic its a SCI

er ror from all LIN Slaves. It is ter mi nat ed by the Sync Break De lim it -

er (at least one re ces sive bit). The LIN Mas ter trans mits the com mu -

ni ca tion clock pulse with the sub se quent Sync Byte (SCI Frame with

the val ue 0x55).

1/14

Fig ure 3:Cen tral mes sage dis tri bu tionsys tem: The LIN Mas ter con trolssend ing and re ceiv ing of all LINframes by the Mas ter Task andLIN Sched ule. A frame slot mustbe long enough to trans mit theas so ci at ed LIN frame. The lengthof the IFS de pends, among oth erthings, on the ex e cu tion cy cle(time base) of the Mas ter Task.

03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 3

Page 21: Vector Press Book

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

1/15

A Spo rad ic Frame is un der stood as an Un con di tion al Frame that

shares the same frame slot with oth er Un con di tion al Frames. Spo -

rad ic Frames are trans mit ted en tire ly by the LIN Mas ter as nec es sa -

ry, so col li sions are im pos si ble. If the LIN Mas ter has no need for

any of the frames, the as so ci at ed frame slot sim ply re mains emp ty.

The Event Trig gered Frame was in tro duced to com mu ni cate spo rad ic

chan ges or events on the part of the LIN Slaves. It es sen tial ly cor re -

sponds to an Un con di tion al Frame, but with the dif fer ence that

mul ti ple frame re spons es from dif fer ent LIN Slaves are al lo cat ed to

the frame head er. The frame re sponse that is used to com plete the

Event Trig gered frame head er de pends on the needs of the re lat ed

LIN Slaves. There is a need when there are new da ta to be trans -

port ed. The frame re sponse of the Event Trig gered Frame is iden ti -

fied by the PID of the as so ci at ed Un con di tion al Frame in the first

byte.

In con trast to the Spo rad ic Frame, how e ver, col li sions can not be

ex clud ed in the Event Trig gered Frame. In case of a col li sion the LIN

Mas ter is re spon si ble for trans mis sion of all Un con di tion al Frames

as signed to the Event Trig gered Frame. It does this by ac ti vat ing

and proc ess ing a “Col li sion Re solv ing Sched ule”.

Both con ven tion al Un con di tion al Frames and spe cial Di ag nos tic

Frames are suit a ble for di ag nos ing the LIN Slaves. Un con di tion al

Frames are used for sim ple sig nal-based di ag nos tics, while Di ag -

nos tic Frames are used ei ther for us er-de fined di ag nos tics or di ag -

nos tics based on a stand ard ized trans port pro to col [3] and uni form

di ag nos tic serv i ces [4] [5].

The LIN spec i fi ca tion de fines two Di ag nos tic Frames: The “Mas ter

Re quest Frame” and “Slave Re sponse Frame”. The Mas ter Re quest

Frame (ID=0x60) rep re sents the Di ag nos tic Re quest. In this case

the LIN Mas ter trans mits both the frame head er and the frame re -

sponse. For ex am ple, a Mas ter Re quest Frame is trans mit ted if there

is a Di ag nos tic Re quest via CAN. The Slave Re sponse Frame

(ID=0x61) cor re sponds to the Di ag nos tic Re sponse. In this case the

LIN Mas ter trans mits the head er, and the spe cif ic LIN Slave trans -

mits the re sponse.

Man age ment func tionsThe LIN spec i fi ca tion de fines Sta tus Man age ment and Net work

Man age ment. Sta tus Man age ment spec i fies that LIN Slaves must in -

form the LIN Mas ter of trans mis sion er rors that are de tect ed such

as par i ty or check sum er rors. This is done by a “Re sponse Er ror Sig -

nal” in an Un con di tion al Frame (“Sta tus Frame”); how e ver this fra-

me does not con tain any fur ther in for ma tion on the type of er ror.

The LIN spec i fi ca tion does not de fine er ror han dling rath er it leaves

this task to the us er.

The pri ma ry task of LIN Net work Man age ment is to reg u late the

tran si tion of all Slaves in a LIN Clus ter from the nor mal com mu ni ca -

tion state (Op er a tion al) to the Sleep state and in the oth er di rec -

tion (Fig ure 5). If the LIN Slaves do not de tect any bus ac tiv i ty for

four sec onds, they switch from the Op er a tion al state to the Sleep

state. The same con di tion elic its a Sleep com mand from the LIN

Mas ter, which is re al ly a spe cial Mas ter Re quest Frame.

Con verse ly, when a LIN Slave de tects a “Wake Up Sig nal” fol lowed

by a val id head er it switch es from the Sleep state via the In i tial i za -

tion state to the Op er a tion al state. The Wake Up Sig nal con sists of a

Fig ure 4:Each LIN frame is com posed of a frame head er and a frame re sponse. The frame head er is al ways sent by the LIN Mas ter.The frame re sponse may be sentby one LIN Slave or by the LINMas ter.

03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 4

Page 22: Vector Press Book

LIN, Flex Ray and MOST fun da men tals con vey the nec es sa ry ba sic

knowl edge need ed to quick ly be come fa mil iar with the wide va ri e ty

of de vel op ment ac tiv i ties re lat ed to au to mo tive elec tron ics.

The first two parts of this se ries of ar ti cles ad dressed the top ics of

se ri al da ta ex change in the au to mo bile and CAN. The next two ar ti -

cles will dis cuss the se ri al bus sys tems Flex Ray and MOST.

Lit er a ture and links:[1] www.lin-sub bus.org[2] LIN Spec i fi ca tion Pack age Re vi sion 2.1[3] Road ve hi cles – Di ag nos tics on Con trol ler Ar ea Net work (CAN) – Part 2:

Net work lay er serv i ces, In ter na tion al Stand ard ISO 15765-2.4, Is sue 4,2002-06-21

[4] Road ve hi cles – Di ag nos tics on con trol ler ar ea net work (CAN) – Part 3:Im ple men ta tion of di ag nos tic serv i ces, In ter na tion al Stand ard ISO15765-3.5, Is sue 5, 2002-12-12

[5] Road ve hi cles – Di ag nos tic sys tems – Part 1: Di ag nos tic serv i ces, In ter -na tion al Stand ard ISO 14229-1.6, Is sue 6, 2001-02-22

[6] www.vec tor-in for ma tik.com[7] www.vec tor-acad e my.com

dom i nant pulse min i mum 250 mi cros ec onds and max i mum 5 mil li -

sec onds in length, and it may be sent by any LIN node. The LIN

spec i fi ca tion pre scribes a max i mum In i tial i za tion phase of 100 mil -

li sec onds, i.e. the LIN Mas ter must be gin to ex e cute the LIN Sched -

ule at the lat est aft er this time span. If it re mains pas sive the rel e -

vant LIN Slave sends an oth er Wake Up Sig nal. The num ber of rep e ti -

tions and the in ter val be tween rep e ti tions, as well as time outs are

de fined in the spec i fi ca tion.

In case of net work ing is sues: Quick res o lu tion with ex ter -nal ex pert iseIn net work ing with LIN, CAN, Flex Ray and MOST, Vec tor In for ma tik

[6] sup ports au to mo tive OEMs and sup pli ers with a uni ver sal tool

chain, em bed ded soft ware com po nents, base soft ware for AU TO SAR

con trol mod ules and hard ware in ter fa ces. Us ers of the CA Noe.LIN

tool for ex am ple ben e fit over the en tire de vel op ment proc ess from

prac tice-prov en func tions for mod el gen er a tion, sim u la tion, func -

tion al test ing, con form i ty test ing, di ag nos tics and anal y sis. Mul ti-

bus de sign and main te nance of the com mu ni ca tion da ta of a net -

worked sys tem is sup port ed by Da Vin ci Net work De sign er for LIN,

CAN and Flex Ray for ex am ple. De vel op ment, cal i bra tion and di ag -

nos tic tools for in-ve hi cle ECUs com plete Vec tor’s ex ten sive prod uct

line-up. Be sides con sul ta tion the Stutt gart-based com pa ny al so of -

fers a tool en vi ron ment for the elec tron ic sys tems de vel op ment

proc ess. These serv i ces are round ed out by a com pre hen sive train -

ing pro gram cov er ing Vec tor tools, soft ware com po nents and se ri al

bus sys tems.

For an en try-lev el in tro duc tion to se ri al da ta ex change in the au to -

mo bile the Vec tor Acad e my [7] of fers the one-day train ing course

“Se ri al bus sys tems in the au to mo bile”. Train ing cours es on CAN,

1/16

Fig ure 5:Com mu ni ca tion state mod el of a LIN Slave.

Eu gen May er(Grad u ate En gi neer with Tech ni cal Teach ingCer tif i cate), aft er com plet ing his voc a tion altrain ing to be come a com mu ni ca tions tech -ni cian, stud ied elec tron ics at the Tech ni calCol lege in Rav ens burg/We ing ar ten, Ger ma -ny, and stud ied elec tri cal en gi neer ing andvoc a tion al teach ing at the Uni ver si ty ofStutt gart. Since 1999 he has been work ing atVec tor In for ma tik where he is em ployed as aSen ior Train er.Tel. +49-711/80670-574,Fax +49-711/80670-111,E-Mail: eu gen.may er@vec tor-in for ma tik.de

03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 5

Page 23: Vector Press Book

1/17

03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 6

Page 24: Vector Press Book

Net work De vel op ment across LIN Bus Sys tems

Apart from mi nor chan ges and clar i fi ca tions, sig nif i cant func tion al

im prove ments were made with the LIN 2.1 pro to col ver sion re leased

in No vem ber 2006 for event-trig gered frames, Slave iden ti fi ca tion

and Slave con fig u ra tion as well as for di ag nos tics over LIN us ers are

now await ing the LIN con sor ti um’s re lease of LIN 2.1 con form ance

test spec i fi ca tion in the sec ond quar ter of 2008. This doc u ment

spec i fies tests for val i dat ing the con form ance of LIN de vi ces ac -

cord ing to the dif fer ent parts of the LIN 2.1 spec i fi ca tion.

LIN Net work De signPri or to the de vel op ment and test phas es, many net work de sign

chal len ges must first be mas tered. These range from de fin ing the

sys tem to pol o gy and cy cle times to cre at ing LIN frames and sched -

ule ta bles as well as rout ing re la tion ships with oth er bus sys tems.

LIN com mu ni ca tion de sign needs to be com plete ly er ror-free and

con sist ent, since the re sult ing LIN De scrip tion File (LDF) is used for

all sub se quent de vel op ment steps: em bed ded soft ware gen er a tion,

net work anal y sis, con form ance test ing, sys tem and in te gra tion

tests, etc. (Fig ure 1).

The choice of net work to pol o gy de pends on var i ous fac tors. For ex -

am ple, it may be pos si ble to de fine a sin gle LIN net work rath er than

sep a rate net works for left and right door sys tems. In some cas es, a

func tion-ori ent ed ap proach is more ap pro pri ate, e.g. a ded i cat ed

LIN net work for cli mate con trol. It may al so be nec es sa ry to make a

dis tinc tion be tween net works de signed by the OEM and sub sys tems

de vel oped com plete ly by the OEM’s sup pli er.

Ef fi cient De sign across Net worksNet work de sign can be sig nif i cant ly sim pli fied by di rect ly rout ing

sig nals be tween net works. This re quires de fin ing unique sig nal

names for both CAN and LIN sig nals. Us ing this rout ing meth od, the

ECU’s ap pli ca tion code is re lieved of rout ing tasks, which al so con-

sid er a bly sim pli fies the code de vel op ment proc ess. Since LIN sup -

ports on ly “un signed sig nals”, glo bal ly de fined sig nals must also be

un signed. This lim i ta tion can usu al ly be ac cept ed by the CAN net -

works.

With out the ap pro pri ate tool sup port for net work de sign, it is very

dif fi cult to con sid er all de sign and qual i ty re quire ments. Ex ten sive

ex pe ri ence ac quired dur ing se ries pro jects for var i ous OEMs has

con trib ut ed to the suc cess of ver sion 2.0 of the Da Vin ci Net work

De sign er LIN (Fig ure 2). For ex am ple, in i tial sched ule ta bles can be

au to mat i cal ly gen er at ed by sim ply de fin ing the frame cy cle times.

The sched ule tim ings can then be eas i ly op ti mized and re fined de -

pend ing on, for ex am ple, the per form ance of each LIN Slave. The

de sign tool from Vec tor al so helps the us er to im ple ment de sign

rules such as nam ing con ven tions for mean ing ful iden ti fi ers and

sig nal types as well as for uni form en cod ing of phys i cal pa ram e ters.

1/18

The tran si tion from the cur rent LIN Version2.0 to LIN 2.1, con sist ent LIN net work de sign and ef fi cient test strategies were key top ics at the 3rd LIN Sym po si umhost ed by Vec tor In for ma tik GmbH in Feb ru a ry 2008 in Stutt gart. Over 150 par tic i pants from Ger ma ny andacross the globe learned about the lat est de vel op ments and trends re lat ed to the LIN bus, and shared their ex pe ri en ces on ef fi cient use of sim u la tion,de sign and test tools.

Tools for Ef fi cient Net work De sign and Con form ance Test ing

Fig ure 1:Typ i cal work flow for LIN net work de sign

04 Press Book_Seite_1-18_1-21:Press Report 4 09.02.2010 13:09 Uhr Seite 1

Page 25: Vector Press Book

De sign el e ments can be eas i ly re used, and con sist en cy checks are

au to mat i cal ly per formed. Es pe cial ly im por tant for the ef fi cient

net work de sign across bus sys tems is the uni form man age ment of

all sig nals in a glob al sig nal pool. Da Vin ci Net work De sign er is ca pa -

ble of im port ing ex ist ing net work de scrip tions via stand ard ized

da ta ex change for mats such as LDF, NCF, DBC or FI BEX. This avoids

in many cas es the re-en ter ing of sig nal and en cod ing def i ni tions.

From Mul ti bus Tool to Da ta Back boneA fu ture trend is the in creas ing move ment to wards glob al net work

de sign across CAN, LIN, MOST and Flex Ray bus sys tems. The cen tral

man age ment of all da ta and in for ma tion at the ve hi cle or mod el

lev el is be com ing in dis pen sa ble. Mul ti bus de sign tools not on ly re -

quire ac cess to a com mon, glob al sig nal pool, but must al so sup port

mul ti ple us er ac cess and rights. The eAS EE Tool Suite from Vec tor

pro vides a da ta back bone that not on ly man a ges all en gi neer ing

da ta for net work de signs, but can al so sup port the man age ment of

project plans, stor age of test da ta, co or di nat ed da ta main te nance

or ar chiv ing of de fined ver sion states be fore de liv ery to part ner

com pa nies.

Test Strat e giesThe pri ma ry meth od for guar an tee ing the qual i ty of LIN net works is

to ap ply the LIN con form ance tests to each ECU. A black test im ple -

men ta tion of such tests has the key ad van tage that the in ter fa ces

1/19

Fig ure 2: De sign of the LIN Sched ule with Da Vin ci Net work De sign er LIN

used for sim u la tion and ver i fi ca tion are ex clu sive ly ECU ex ter nal in -

ter fa ces. White or gray box tests, on the oth er hand, al ways re quire

ac cess to in ter nal ECU in ter fa ces. The Slave con form ance test pro -

vid ed with the de vel op ment and test tool CA Noe.LIN (Fig ure 3) is

im ple ment ed al most en tire ly as a black box test. The Mas ter con -

form ance test, on the oth er hand, is im ple ment ed a gray box test

i.e. as a com bi na tion of black and white box test. A spe cial test-LDF

and test ap pli ca tion is re quired to stim u late the Mas ter. The LIN bus

is used for ver i fi ca tion.

Pro to type of a Black Box Mas ter Con form ance TestAl though a gray box im ple men ta tion al lows the Mas ter con form -

ance test to be ful ly au to mat ed, it can on ly be ap plied a the start of

the V-mod el de vel op ment proc ess. This is main ly be cause the re -

quired test LDF and test ap pli ca tion are not iden ti cal to re al LDF

and ap pli ca tion of the Mas ter ECU. On re quest of an OEM, the LIN

spe cial ists from Vec tor have spec i fied a pro to type black box Mas ter

con form ance test. By ex tend ing the Mas ter driv er to pro vide elev -

en test serv i ces, it was proved pos si ble to per form the cur rent

LIN2.0 Mas ter con form ance test dur ing all phas es of de vel op ment

us ing the re al LDF and ap pli ca tion. The Vec tor con cept is not on ly

fun da men tal ly ex tend a ble; it can al so be eas i ly stand ard ized.

04 Press Book_Seite_1-18_1-21:Press Report 4 09.02.2010 13:09 Uhr Seite 2

Page 26: Vector Press Book

OEM-stand ard ized LIN-Port fo lioLast year, Audi, BMW, Daim ler, Porsche and VW cre at ed a doc u ment

for sup pli ers, which de scribes the re quire ments for the de vel op -

ment of OEM-in de pend ent “LIN port fo lio”. This doc u ment was first

pre sent ed to LIN con sor ti um mem bers at the All-Mem bers Meet ing

in Oc to ber 2007 and in Feb ru a ry this year to the rest of the LIN

com mu ni ty at Vec tor’s LIN Sym po si um. The main ob jec tive of this

in i ti a tive is to re duce de vel op ment and pro duc tion costs through

max i mum re us a bil i ty. The stand ard i za tion of the phys i cal lay er re -

quire ments across dif fer ent OEMs does not end with the choice of

tran sceiv er, but must al so in clude spec i fi ca tions for con nect ors, fil -

ter cir cuits, op er at ing and in stal la tion con di tions. A cur rent ex am -

ple for such a LIN de vice, is an in tel li gent bat tery sen sor de vel oped

for sev er al OEMs. A wip er mo tor and mir ror ad just er are al so in de -

vel op ment. In or der to in crease the size of the “LIN port fo lio”, each

OEM de vel op ing a LIN de vice in co op er a tion with a sup pli er, har mo -

niz es the spec i fi ca tions with oth er OEMs in tech ni cal com mit tees.

1/20

Fig ure 3: Us ing the Slave Con form ance TestMod ule, LIN con form ance tests canbe eas i ly in te grat ed in to your ownCA Noe test con fig u ra tions.

Ga vin C. Rog ers(B.Eng M.Sc.) is team lead er and prod uctman a ger for LIN de vel op ment and test tools.

Hans Quecke (In for ma tion Tech nol o gy de gree) is teamlead er and prod uct man a ger for tools used to de sign net work ar chi tec tures and com mu -ni ca tion da ta.

04 Press Book_Seite_1-18_1-21:Press Report 4 09.02.2010 13:09 Uhr Seite 3

Page 27: Vector Press Book

Count on the worldwide leading

solution for LIN!

Vector has the comprehensive solution for every phase of your

professional LIN network development:

Design your LIN networks systematically >

Simulate, analyze and test ECUs and entire networks >

efficiently with CANoe and the XL-Interfaces

Use our reliable LIN software components >

Make your ECUs and networks production-ready with >

calibration, stress and logging tools from Vector

Rely on our Vector service teams for development, training >

and support

For successful projects, take advantage of proven tools, scalable modules and over 20 years of networking expertise at Vector!

Visit us at: www.lin-solutions.com

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. 07 11 / 8 06 70-0

www.vector-informatik.com

Reserve a copy of the LIN

Reference Chart now!

www.lin-solutions.com

04 Press Book_Seite_1-18_1-21:Press Report 4 09.02.2010 13:09 Uhr Seite 4

Page 28: Vector Press Book

1/22

As sur ing the Qual i ty of LIN ECUs

In tro duc tionThe LIN con sor ti um pro vides in ad di tion to the spec i fi ca tions for

each the pro to col ver sion cor re spond ing con form ance test spec i fi -

ca tions. The LIN con form ance tests are used to ver i fy wheth er a LIN

de vice is con form to a spe cif ic pro to col ver sion and al so serve as a

ba sis for the LIN ac cred i ta tion. Since LIN net works op er ate ac cord -

ing to the Mas ter-Slave prin ci ple, the pro to col con form i ty of a Mas -

ter node is of ut most im por tance. The LIN con form ance tests are

spec i fied sep a rate ly for each OSI lay er: phys i cal lay er, da ta link lay -

er, net work man age ment and node con fig u ra tion. On ly ap pli ca tion

lay er tests need to be spec i fied by the OEM or sup pli er.

Black box tests are best suit ed for the me thod i cal im ple men ta tion

of con form ance tests, since they ex clu sive ly use a de vi ce’s ex ter nal

in ter fa ces (e.g. LIN in ter face) to stim u late and ver i fy each test

case. White box tests on the oth er hand al ways re quire ac cess to

a de vi ce’s in ter nal in ter fa ces (e.g. the LIN driv er’s stand ard ized

in ter face). A LIN Mas ter ECU of fers a very lim it ed num ber of stim u -

la tion op tions via its ex ter nal in ter fa ces such as CAN. Gray box tests

that com bine the two test meth ods are there fore the most com -

mon ly used meth od use to re al ize a LIN Mas ter con form ance test,

Fig ure 1.

Test En vi ron ment for LIN Con form ance TestsA typ i cal ECU test case re quires con fig u ra tion and in i tial i za tion

of the test sys tem and ECU un der test, as well as sub se quent

sti m u la tion and ver i fi ca tion. The Slave con form ance tests pro vid ed

with CA Noe.LIN from Vec tor are im ple ment ed al most en tire ly as

black box tests. The test er in its role as LIN Mas ter can usu al ly

per fo r m the stim u la tion and ver i fi ca tion di rect ly via the LIN bus.

Fig ure 1: The LIN Mas ter con form ancetest is usu al ly im ple ment ed asa gray box test. A black box testwould, how e ver, be pref er a ble.

High qual i ty and re li a bil i ty are es sen tial pre con di tionsfor the suc cess ful ap pli ca tion of bus sys tems to mod ernau to mo biles. Due to the sig nif i cant in crease in thenum ber of LIN (Lo cal In ter con nect Net work) com po -nents used in au to mo tive de vel op ments, ef fi cient teststrat e gies for this cost-ef fi cient bus sys tem are gain -ing in im por tance. This ar ti cle de scribes the cur rentpos si bil i ties for test ing LIN nodes ac cord ing to thelat est LIN con form ance test spec i fi ca tion. For Mas ter nodes a new and ef fi cient black box teststrat e gy is pre sent ed based on the well-known de vel op ment and sim u la tion toolCA Noe.LIN.

Cur rent and Fu ture Strat e gies for LIN Mas ter Con form ance Tests

05 Press Book_Seite_1-22_1-25:Press Report 4 09.02.2010 13:15 Uhr Seite 1

Page 29: Vector Press Book

1/23

On ly a few tests re quire man u al stim u la tion or ver i fi ca tion e.g. in

or der to stim u late a wake up sig nal. The Mas ter con form ance test,

on the oth er hand, is im ple ment ed by the Stutt gart-based tool

pro vid er as a gray box. A spe cial test LIN De scrip tion File (LDF) is

pro vid ed to en sure the cor rect con fig u ra tion of the Mas ter driv er.

To geth er the gen er at ed driv er code a spe cial test ap pli ca tion must

be down load ed to the Mas ter un der test. In this way, the LIN bus

can be used for both stim u la tion and ver i fi ca tion pur pos es, de spite

the test er’s role as LIN Slave.

The Del phi Tech ni cal Cen ter in Krak au, Po land, has gained con sid er -

a ble ex pe ri ence with CA Noe.LIN in the field of test ing for both

LIN2.0 and J2602, the U.S. ver sion of LIN. Since the LIN con form -

ance tests do not cov er the OSI ap pli ca tion lay er, Del phi TCK has

ex tend ed their test ac tiv i ties to cov er var i ous ap pli ca tion tests. The

main fo cus of these tests is to test: sig nals, sched ule ta bles, gate -

way rout ings, and di ag nos tics. The CAPL test func tions pro vid ed

with CA Noe.LIN have proved to be in dis pen sa ble in im ple ment ing

and au to mat ing such tests. Ac cord ing to Del phi TCK even very com -

plex test cas es were easy to im ple ment and ex tend us ing the C-like

CAPL syn tax.

Dis ad van ta ges of Gray Box Mas ter TestsWith re spect to us a bil i ty, a gray box im ple men ta tion of the Mas ter

con form ance test has sev er al dis ad van ta ges. For ex am ple it is not

pos si ble to per form this test dur ing all phas es of de vel op ment.

Fur ther more, some prep a ra tion ef fort is in volved, e.g. con fig u ration

and gen er a tion of the Mas ter driv er code ac cord ing to the test LDF,

be fore the Mas ter-ECU can be test ed.

The gray box Mas ter con form ance test al lows the Mas ter driv er in -

ter face to be in di rect ly ac cessed by the LIN-bus via a test ap pli ca -

tion. Al though full test cov er age can be achieved in this way, this

ap proach means that the usu al V-mod el de vel op ment proc ess can -

not be strict ly fol lowed. For ex am ple, it is on ly pos si ble to ver i fy

the Mas ter’s con form i ty at the be gin ning of the de vel op ment pro-

cess. As soon as the pro duc tive da ta base (LDF) and ap pli ca tion are

run ning on the Mas ter ECU, fur ther ver i fi ca tions can no longer be

eas i ly per formed. Fur ther more, the OEM can not re peat the Mas ter

con form ance test with out as sist ance from sup pli er.

The Way to a Black Box Mas ter TestCon se quent ly, many au to mo tive OEMs and sup pli ers of ten ask

wheth er the Mas ter con form ance test can be im ple ment ed as a

black box test. This would have the big ad van tage that OEMs and

sup pli ers could in de pend ent ly per form tests dur ing the en tire de -

vel op ment proc ess with min i mal con fig u ra tion ef fort.

How e ver, in or der for a black box Mas ter con form ance test to have

gen u ine ad van ta ges over a gray box test, cer tain re quire ments

must be first met. Prob a bly the most im por tant one is that the

same driv er soft ware used for de vel op ment must al so be used for

tests. One way of achiev ing this is to ex tend the LIN Mas ter driv er

with a spe cial test in ter face.

Fig ure 2: The test com mu ni ca tion re quired to re al ize aMas ter con form ance test as a black box test.

05 Press Book_Seite_1-22_1-25:Press Report 4 09.02.2010 13:15 Uhr Seite 2

Page 30: Vector Press Book

Mas ter’s nor mal ap pli ca tion. A com plete ly in de pend ent and par al lel

op er a tion of both test and ap pli ca tion proved to be im pos si ble. The

ap pli ca tion must there fore be in volved in the re al i za tion.

There are bas i cal ly two pos si ble strat e gies for han dling the in ter ac -

tion be tween the ap pli ca tion and the driv er’s test mode, Fig ure 3.

One way is clear ly in form the ap pli ca tion that a test is be ing ex e cut -

ed. An al ter na tive meth od is to hide the test ex e cu tion from the ap -

pli ca tion as far as pos si ble. Both strat e gies have their ad van ta ges

and dis ad van ta ges. The fi nal choice of strat e gy may de pend on the

feed back and wish es of Mas ter-ECU sup pli ers. In both cas es ex ist ing

driv ers need to be ex tend ed to sup port the re quired test serv i ces.

The ad di tion al code re quired for the test-serv er func tion al i ty has

been es ti mat ed to be 20–30 % of cur rent LIN2.x driv ers and can be

con sid ered un prob lem at ic for most Mas ter ECU pro jects.

The cur rent pro to type im ple men ta tion pro vides elev en serv i ces,

which is more than suf fi cient to sat is fy the LIN 2.0 Mas ter con form -

ance test, Fig ure 4. The pro posed con cept from Vec tor is not on ly

ex tend a ble, but can al so be eas i ly stand ard ized, since it is based on

the ex ist ing LIN de vel op ment proc ess and pro to col spec i fi ca tions.

Apart from these ac tiv i ties, Vec tor plans to fur ther de vel op

CA Noe.LIN. For ex am ple, sup port of LIN 2.1 Slave tests is planned

for SP4/5 of Re lease 7.0 in the third quar ter of 2008, as sum ing that

This driv er ex ten sion must per mit the di rect stim u la tion and ver i fi -

ca tion of the Mas ter un der test via the LIN bus by pro vid ing the

test er with spe cial test serv i ces, e.g. to change the sched ule ta ble

or read the driv er’s sta tus word. The test com mu ni ca tion over the

LIN bus be tween Mas ter and test er can use a spe cial di ag nos tic

serv ice, com pa ra ble to those used for re con fig u ra tion serv i ces.

A fur ther re quire ment on such a driv er ex ten sion is of course the

min i mal in crease in ECU re sour ces. The test in ter face should al so be

re mov a ble from the pro duc tive code, e.g. via a pre proc ess or de fine.

Pro to type of a Black Box Test for LIN 2.xThe LIN spe cial ists at Vec tor were re quest ed by an OEM to de sign

and spec i fy a black box Mas ter con form ance test. Dur ing spec i fi ca -

tion of the pro to type, it be came quick ly clear that the test com mu -

ni ca tion must not neg a tive ly af fect the nor mal op er a tion of the

Mas ter-ECU. This can be on ly achieved by ap ply ing the stand ard LIN

di ag nos tics con sist ing of Mas ter Re quests and Slave Re spons es us -

ing a new spe cial di ag nos tic serv ice. On ly in this case, it is the test -

er as Slave and not the Mas ter who in i ti ates com mu ni ca tion. The

test er sends a test com mand to the Mas ter-ECU, which can re spond

ei ther pos i tive ly or neg a tive ly, Fig ure 2.

Be fore send ing each test com mand it is nec es sa ry to ex e cute a test

log-in and a test in i tial i za tion. This rais es the ques tion to which ex -

tent a con form ance test can be im ple ment ed in de pend ent ly of the

1/24

Fig ure 3: Two pos si ble strat e gies forthe har mon ic in ter ac tion ofMas ter ap pli ca tion and testex e cu tion.

05 Press Book_Seite_1-22_1-25:Press Report 4 09.02.2010 13:15 Uhr Seite 3

Page 31: Vector Press Book

1/25

AS SUR ING THE QUAL I T Y OF LIN ECUS

the LIN 2.1 con form ance test spec i fi ca tions are pub lished in the

sec ond quar ter of 2008. Sup port of the LIN 2.1 Mas ter tests can be

ex pect ed with Re lease 7.1 of CA Noe.LIN in the fourth quar ter of

2008. In ad di tion to its de vel op ment, anal y sis and sim u la tions

tools, the Stutt gart-based com pa ny al so pro vides train ing and

work shops re lat ed to all as pects of net work ing with CAN, LIN, MOST

and Flex Ray. Through nu mer ous cus tom er pro jects, both OEMs and

sup pli ers al so prof it di rect ly from 20 years of net work ing ex pe ri -

ence and ex pert ise at Vec tor.

Ga vin C. Rog ersB.Eng M.Sc., is team lead er and prod uctman a ger for LIN development and test tools.

Fig ure 4:An over view of the 11 testcom mands, which al low a com -plete cov er age of the cur rentLIN2.0 Mas ter con form ancetest.

05 Press Book_Seite_1-22_1-25:Press Report 4 09.02.2010 13:15 Uhr Seite 4

Page 32: Vector Press Book

1/26

Se ri al Bus Sys tems in the Au to mo bile

Flex Ray is go ing in to pro duc tion for the first time. It will ap pearon the BMW X5, which was pre sent ed to the pub lic at the Par is Au to Sa lon in Au gust 2006, and it can be pur chased in Ger ma nybe gin ning in March of this year. With in its ac tive chas sis sys tem,Flex Ray pro vides for se cure and re li a ble da ta trans mis sion be -tween the cen tral con trol mod ule and the four sat el lite ECUs, onelo cat ed at each shock ab sorb er. This ar ti cle tra ces Flex Ray’s pathin to the au to mo bile and ex plains the key prin ci ples of Flex Ray bustech nol o gy.

Part 4:

Flex Ray for da ta ex change in high ly crit i cal safe tyap pli ca tions

Ac cord ing to the Ger man Fed er al Sta tis tics Of fice [1] driv ing on

Ger ma ny’s roads was nev er so safe as in the year 2005. Al though

ve hi cle reg is tra tions grew con sid er a bly, there was a near ly one per -

cent re duc tion in ac ci dents in volv ing per son al in ju ry (336619) com -

pared to the pri or year. There were al so sig nif i cant re duc tions in

the num ber of traf fic deaths (5361, -8.2%), se ri ous in ju ries

(76952, -4.6%) and mi nor in ju ries (356491, -1 %). This trend was

con tin ued in 2006: Be tween Jan u ary and Au gust, 3260 traf fic par -

tic i pants were killed, and this rep re sents a 7.8 per cent re duc tion

com pared to the pri or year. The num ber of in jured dropped by 5.8

per cent over the same time pe ri od.

De ci sive in low er ing the num ber of ac ci dents and re duc ing the se -

ver i ty of ac ci dent out comes are ac tive safe ty sys tems and as sist -

ance sys tems that sup port driv ers in their task of driv ing the ve hi -

cle. One study by a num ber of well-known au to mo tive OEMs sho-

wed, for ex am ple, that ESP re duced the num ber of skid ding ac ci -

dents by up to 80 % [2]. Mak ing just as im por tant a con tri bu tion to

re duc ing the se ver i ty of ac ci dent out comes are in creas ing ly saf er

pas sen ger cells and op ti mized re straint sys tems.

In light of the goal of halv ing traf fic fa tal i ties by the year 2010, the

au to mo tive in dus try is fo cus ing on fur ther de vel op ing ex ist ing ac -

tive safe ty sys tems and driv er as sist ance sys tems and de vel op ing

new in no va tive sys tems. Since these sys tems not on ly pro vide in -

for ma tion and in struc tions, but of ten al so make cor rect ive in ter -

ven tions and as sume driv ing tasks, it is no longer pos si ble to do

with out elec tron ic in ter fa ces to the chas sis and driv et rain. The

com bi na tion of brake-by-wire and steer-by-wire sys tems is thought

to have great po ten tial.

Re quire ments of fu ture da ta trans mis sion in the au to mo bileIm ple men ta tions of ev er more chal leng ing safe ty and driv er-as sist -

ance func tions go hand in hand with the in creas ing ly more in ten -

sive in te gra tion of elec tron ic ECUs in the au to mo bile. These im ple -

men ta tions re quire very high da ta rates to trans mit the in creas ing

num ber of con trol and sta tus sig nals. They are sig nals that not on ly

need to be trans mit ted ex treme ly quick ly; their trans mis sion al so

needs to be ab so lute ly de ter min is tic.

That is the rea son for the grow ing im por tance of com mu ni ca tion

sys tems that guar an tee fast and de ter min is tic da ta trans mis sion in

the au to mo bile. Po ten tial use of by-wire sys tems fur ther re quires

the de sign of fault-tol er ant struc tures and mech a nisms. Al though

by-wire sys tems may of fer wide-ran ging ca pa bil i ties and the ben e -

fits of in creased de sign free dom, sim pli fied as sem bly, per son al i za -

tion of the ve hi cle, etc., da ta trans mis sion re quire ments in the au -

to mo bile are el e vat ed con sid er a bly, be cause these sys tems be long

to the class of fail-op er a tion al sys tems. They must con tin ue to op -

er ate ac cept a bly even when an er ror oc curs.

CAN can not sat is fy these re quires due to its event-driv en and pri or -

i ty-driv en bus ac cess, its lim it ed band width of 500 KBit/sec based

on phys i cal con straints in the au to mo bile, and lack of fault-tol er -

ant struc tures and mech a nisms [3].

Flex Ray – The an swer to height en ed da ta trans mis sion re -quire ments in the au to mo bileThe cer tain ty that CAN could hard ly be ex pect ed to sat is fy grow ing

da ta trans mis sion re quire ments in the au to mo bile over the mid-

term, led to the de vel op ment of a num ber of de ter min is tic and

fault-tol er ant se ri al bus sys tems with far great er da ta rates than

CAN. Ex am ples in clude: TTP (Time Trig gered Pro to col) [4], Byte -

flight [5] and TTCAN (Time Trig gered CAN) [6]. Al though a de vel op -

ment part ner ship was cre at ed as ear ly as 2001 be tween Audi and

the TTP pro mot ing com pa ny TTTech, and al though Byte flight was

suc cess ful ly ap plied to BMW 7-se ries cars in 2001, it is Flex Ray that

has pre vailed in the au to mo tive in dus try.

An im por tant rea son for the suc cess of Flex Ray was the found ing of

the Flex Ray Con sor ti um [7], un der whose aus pi ces the two mo tor

06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:16 Uhr Seite 1

Page 33: Vector Press Book

1/27

com mu ni ca tion struc ture. How e ver, the Flex Ray nodes are not al -

lowed un con trolled bus ac cess in re sponse to ap pli ca tion-re lat ed

events, as is the case in CAN. Rath er they must con form to a pre -

cise ly de fined com mu ni ca tion cy cle that al lo cates a spe cif ic time

slot to each Flex Ray mes sage (Time Di vi sion Mul ti ple Ac cess - TDMA)

and there by pre scribes the send times of all Flex Ray mes sa ges (Fig -

ure 1).

Time-trig gered com mu ni ca tion not on ly en sures de ter min is tic da ta

com mu ni ca tion; it al so en sures that all nodes of a Flex Ray clus ter

can be de vel oped and test ed in de pend ent of one an oth er. In ad di -

tion, re mov al or ad di tion of Flex Ray nodes in an ex ist ing clus ter

must not im pact the com mu ni ca tion proc ess; this is con sist ent with

the goal of re-use that is of ten pur sued in au to mo tive de vel op -

ment.

Fol low ing the par a digms of time-trig gered com mu ni ca tion ar chi -

tec tures, the un der ly ing log ic of Flex Ray com mu ni ca tion con sists of

trig ger ing all sys tem ac tiv i ties when spe cif ic points are reached in

the time cy cle. The net work-wide syn chro nism of Flex Ray nodes

that is nec es sa ry here, is as sured by a dis trib ut ed, fault-tol er ant

clock syn chro ni za tion mech a nism: All Flex Ray nodes not on ly con -

tin u ous ly cor rect for the be gin ning times (off set cor rec tion) of reg u -

lar ly trans mit ted syn chro ni za tion mes sa ges; they al so cor rect for the

du ra tion (slope cor rec tion) of the com mu ni ca tion cy cles (Fig ure 2).

ve hi cle man u fac tur ers Daim ler Chrys ler and BMW and the two chip

pro duc ers Mo tor o la and Phil ips joined for ces in the year 2000.

Based on Byte flight bus tech nol o gy orig i nal ly de vel oped by BMW,

the Flex Ray Con sor ti um cre at ed the cross-OEM, de ter min is tic and

fault-tol er ant Flex Ray com mu ni ca tion stand ard with a da ta rate of

10 MBit/sec for ex treme ly safe ty- and time-crit i cal ap pli ca tions in

the au to mo bile.

To day the Flex Ray Con sor ti um is made up of sev en “core part ners”:

BMW, Bosch, Daim ler Chrys ler, Free scale, Gen er al Mo tors, Phil ips

and Volk swag en. Grad u al ly, a num ber of Pre mi um As so ci ate Mem -

bers (in clud ing Vec tor In for ma tik [8]) and As so ci ate Mem bers joi-

ned the or gan i za tion.

Mak ing a sig nif i cant con tri bu tion to the suc cess of Flex Ray was the

de tailed doc u men ta tion of the Flex Ray spec i fi ca tion. The two most

im por tant spec i fi ca tions, the com mu ni ca tion pro to col and the

phys i cal lay er, are cur rent ly in Ver sion 2.1. These and oth er Flex Ray

bus tech nol o gy spec i fi ca tions can be down load ed from the home -

page of the Flex Ray Con sor ti um [7].

Flex Ray com mu ni ca tion ar chi tec ture – Time-trig gered,fault tol er ant and flex i bleJust as in the case of da ta com mu ni ca tion in a CAN clus ter, da ta

com mu ni ca tion in a Flex Ray clus ter is al so based on a mul ti-mas ter

Fig ure 1:Prin ci ple of Flex Raycom mu ni ca tion.

06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:16 Uhr Seite 2

Page 34: Vector Press Book

1/28

This in creas es both the band width ef fi cien cy and ro bust ness of the

syn chro ni za tion.

Flex Ray com mu ni ca tion can be based on ei ther an elec tri cal or op ti -

cal phys i cal lay er. Speak ing in fa vor of elec tri cal sig nal trans mis -

sion is its sim plic i ty, which brings cost ad van ta ges. The com par a -

tive ly cost-in ten sive op ti cal sig nal trans mis sion is char ac ter ized by

sub stan tial ly bet ter elec tro mag net ic com pat i bil i ty (EMC) com pared

to elec tri cal sig nal trans mis sion.

Flex Ray com mu ni ca tion is not bound by a spe cif ic to pol o gy. A sim -

ple, pas sive bus struc ture is just as fea si ble as an ac tive star to pol o -

gy or a com bi na tion of the two (Fig ure 3). The pri ma ry ad van ta ges

of the ac tive star to pol o gy lie in pos si bil i ty of dis con nect ing faulty

com mu ni ca tion branch es or Flex Ray nodes and - in de sign ing larg er

clus ters - the abil i ty to ter mi nate with ide al bus ter mi na tions when

phys i cal sig nal trans mis sion is elec tri cal.

To min i mize fail ure risk, Flex Ray of fers re dun dant lay out of the

com mu ni ca tion chan nel (Fig ure 4). This re dun dant com mu ni ca tion

chan nel could, on the oth er hand, be used to in crease the da ta rate

to 20 Mbit/sec. The choice be tween fault tol er ance and ad di tion al

band width can be made in di vid u al ly for each Flex Ray mes sage.

Fi nal ly, an in de pend ent con trol mech a nism (Bus Guard i an) en sures

that a Flex Ray node on ly gets ac cess to the bus dur ing its turn in

the com mu ni ca tion cy cle. This pre vents bus mo nop o li za tion by a

de fective Flex Ray node (bab bling id i ot).

Flex Ray com mu ni ca tion: De ter min is tic and dy nam icEach com mu ni ca tion cy cle is equal in length and is es sen tial ly or ga -

nized in to a stat ic time seg ment and a dy nam ic time seg ment (Fig -

ure 1). Of cen tral im por tance here is the stat ic seg ment that be gins

each com mu ni ca tion cy cle. It is sub di vid ed in to a us er-de fin a ble

num ber (max i mum 1023) of equal ly long stat ic slots.

Each stat ic slot is as signed to a Flex Ray mes sage to be sent by a

Flex Ray node. As sign ments of stat ic slots, Flex Ray mes sa ges and

Flex Ray nodes are made by slot num ber, mes sage iden ti fi er (ID),

and the val ue of the slot coun ter im ple ment ed on each Flex Ray

node. To en sure that all Flex Ray mes sa ges are trans mit ted at the

right time and in the cor rect se quence in each cy cle, the slot coun -

ters on all Flex Ray nodes are in cre ment ed syn chro nous ly at the be -

gin ning of each stat ic slot. Be cause of its guar an teed equi dis tant

and there fore de ter min is tic da ta trans mis sion, the stat ic seg ment

is pre des tined for the trans mis sion of re al-time rel e vant mes sa ges.

Fol low ing the stat ic seg ment is an op tion al dy nam ic seg ment that

has the same length in ev ery com mu ni ca tion cy cle. This seg ment is

al so or ga nized in to slots, but not stat ic slots, rath er so-called min -

islots (Fig ure 1). Com mu ni ca tion in the dy nam ic seg ment (min i-

slot ting) is al so based on al lo ca tions and syn chro nous in cre ment -

ing of the slot coun ters on the Flex Ray nodes.

How e ver, it is not man da to ry to trans mit the Flex Ray mes sa ges as -

so ci at ed to the min islots with each com mu ni ca tion cy cle, rath er

they are on ly sent as need ed. If mes sa ges are not need ed, the slot

Fig ure 2:Clock syn chro ni za tion.

Fig ure 3:Com bined to pol o gy of pas sive bus and ac tive star.

06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:16 Uhr Seite 3

Page 35: Vector Press Book

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

1/29

CRC-pro tect ed da ta trans mis sionThe sig nals in a Flex Ray clus ter are trans mit ted by the well-de fined

Flex Ray mes sage, where in there is es sen tial ly no dif fer ence in the

for mats of the Flex Ray mes sa ges trans mit ted in the stat ic seg ment

and those trans mit ted in the dy nam ic seg ment. They are each com -

posed of a head er, pay load and trail er (Fig ure 6).

The head er com pris es the five-bit wide sta tus field, ID, pay load

length and cy cle coun ter. The head er-CRC (11 bits) pro tects parts of

the sta tus field, ID and pay load length with a Ham ming dis tance of

6. The ID iden ti fies the Flex Ray mes sage and rep re sents a slot in

the stat ic or dy nam ic seg ment. In the dy nam ic seg ment the ID cor -

re sponds to the pri or i ty of the Flex Ray mes sage. The in di vid u al bits

of the sta tus field spec i fy the Flex Ray mes sage more pre cise ly. For

ex am ple, the “sync frame in di ca tor bit” in di cates wheth er the Flex -

Ray mes sage may be used for clock syn chro ni za tion.

Aft er the head er comes the so-called pay load. A to tal of up to 254

use ful bytes may be trans port ed by one Flex Ray mes sage. The trail -

er en com pass es the head er and pay load-pro tect ing CRC (24 bit).

Giv en a pay load of up to 248 use ful bytes, the CRC guar an tees a

Ham ming dis tance of 6. For a larg er pay load the Ham ming dis tance

is 4 [8].

In net work ing is sues: Achiev ing ob jec tives rap id ly withex ter nal ex pert iseIn the year 2001, Vec tor In for ma tik was al ready of fer ing the first

prod uct so lu tion for the de vel op ment of Flex Ray sys tems. In the

mean time, de vel op ers can now ob tain a com pre hen sive port fo lio of

pro ducts [9]. These in clude tools for de sign ing, de vel op ing, sim u -

lat ing, an a lyz ing, test ing and cal i brat ing ECUs and dis trib ut ed net -

works. Da Vin ci Net work De sign er Flex Ray gives the de vel op er an

en vi ron ment for ef fi cient ly de sign ing net work ar chi tec ture and

com mu ni ca tion re la tion ships. Sim u la tion, anal y sis and test ing of

Flex Ray sys tems are per formed with CA Noe.Flex Ray, whose mul ti -

bus con cept en a bles si mul ta ne ous op er a tion of Flex Ray, CAN, LIN

and MOST bus sys tems. For pre cise study of the Flex Ray net work’s

sys tem be hav ior in re sponse to er rors and dis turb an ces, FRstress

gen er ates them on a chan nel in the Flex Ray clus ter. For di rect ac -

cess to in ter nal ECU var i a bles, the de vel op er needs a spe cial meas -

ure ment and cal i bra tion pro to col: XCP on Flex Ray. In the con text of

the de vel op ment of the ac tive chas sis sys tem on the new BMW X5,

BMW en gi neers im ple ment ed Vec tor’s meas ure ment, cal i bra tion

and di ag nos tic tool CA Na pe. As the XCP-on-Flex Ray Mas ter, CA Na pe

meas ures and cal i brates in di vid u al ECU pa ram e ters di rect ly via

Flex Ray. Be sides soft ware, Vec tor al so de vel ops stacks for ECUs.

coun ter of a min islot is in cre ment ed aft er the de fined time pe ri od.

While a (dy nam ic) Flex Ray mes sage is be ing trans mit ted, in cre -

ment ing of the slot coun ter is de layed by the mes sage trans mis sion

time (Fig ure 5).

The al lo ca tion of a dy nam ic Flex Ray mes sage to a min islot im plic it ly

de fines the pri or i ty of the Flex Ray mes sage: The low er the num ber

of the min islot, the high er the pri or i ty of the dy nam ic Flex Ray mes -

sage, the ear li er it will be trans mit ted, and the high er the prob a bil -

i ty of trans mis sion giv en a lim it ed dy nam ic time seg ment length.

The dy nam ic Flex Ray mes sage as signed to the first min islot is al -

ways trans mit ted as nec es sa ry, pro vid ed that there is a suf fi cient ly

long dy nam ic time seg ment.

In the com mu ni ca tion de sign it must be en sured that the low est

pri or i ty dy nam ic Flex Ray mes sage can be trans mit ted too – at least

pro vid ed that there are no oth er, high er pri or i ty needs. The de sign -

er of a Flex Ray clus ter must al so en sure that trans mis sion of the

long est dy nam ic Flex Ray mes sage is even pos si ble. Oth er wise, the

com mu ni ca tion de sign would not make any sense.

The com mu ni ca tion cy cle is com plet ed by two ad di tion al time seg -

ments (Fig ure 1). The “Sym bol Win dow” seg ment serves to check

the func tion al i ty of the Bus Guard i an, and the “Net work Idle Time –

NIT” time seg ment clos es the com mu ni ca tion cy cle. Dur ing the NIT

the Flex Ray nodes cal cu late the cor rec tion fac tors need ed to syn -

chro nize their lo cal clocks. At the end of the NIT, an off set cor rec -

tion is made if nec es sa ry (the slope cor rec tion is al ways dis trib ut ed

over the en tire com mu ni ca tion cy cle). There is no da ta trans mis sion

dur ing the NIT.

Fig ure 4:Pas sive bus struc ture with two com mu ni ca tion chan -nels min i miz es fail ure risk.

06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:16 Uhr Seite 4

Page 36: Vector Press Book

Flex Ray soft ware com po nents make it pos si ble to in ter con nect ap -

pli ca tions with dif fer ent bus or op er at ing sys tems in an un com pli -

cat ed way. For hard ware ac cess to Flex Ray bus es, suit a ble bus in -

ter fa ces con nect to the USB, PCI and PCMCIA ports of a PC or note -

book com put er.

The Vec tor Acad e my [10] can teach the ba sic knowl edge need ed to

quick ly be come fa mil iar with the di verse de vel op ment ac tiv i ties re -

lat ed to ECU com mu ni ca tion in the au to mo bile. This knowl edge is

shared in the con text of sem i nars on CAN, LIN, Flex Ray and MOST.

Lit er a ture and links:[1] www.des ta tis.de [2] www.bosch.com [3] May er, E.: Dat en kom mun i kat ion im Au to mob il – Teil 2: Si che rer Dat en -

aus tausch mit CAN im Au to mob il [“Da ta com mu ni ca tion in the au to mo -bile – Part 2: Re li a ble da ta ex change with CAN in the au to mo bile”]. In:El ek tron ik Au to mo tive 8/2006, pp. 34-37

[4] www.tttech.com [5] www.byte flight.com[6] www.can-cia.org/can/ttcan [7] www.vec tor-in for ma tik.com[8] www.flex ray.com [9] www.flex ray-so lu tions.com[10]www.vec tor-acad e my.com

Fig ure 6:Struc ture of the Flex Ray mes sage withhead er, pay load andtrail er.

Eu gen May er(Grad u ate En gi neer with Tech ni cal Teach ingCer tif i cate), aft er com plet ing his voc a tion altrain ing to be come a com mu ni ca tions tech -ni cian, stud ied elec tron ics at the Tech ni calCol lege in Rav ens burg/We ing ar ten, Ger ma -ny, and stud ied elec tri cal en gi neer ing andvoc a tion al teach ing at the Uni ver si ty ofStutt gart. Since 1999 he has been work ing atVec tor In for ma tik where he is em ployed as aSen ior Train er.Tel. +49-711/80670-574,Fax +49-711/80670-111,E-Mail: eu gen.may er@vec tor-in for ma tik.de

Fig ure 5:Ex am ple of com mu ni -ca tion flow in the dy -nam ic time seg ment.

1/30

06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:17 Uhr Seite 5

Page 37: Vector Press Book

Experience with series projects.

Choose proven FlexRay solutions.

Take advantage of our extensive experience with FlexRay series

projects. Use Vector’s comprehensive product portfolio for your

FlexRay networking:

> Simulate, diagnose and test ECUs and networks with the

sophisticated development environment CANoe and the

FlexRay interfaces.

> Profit from standardized ECU software. Vector software

modules can be flexibly configured and easily integrated.

> Ensure advantages in both quality and time: Rely on professional

support during development and training.

Get FlexRay on the road - with series-proven tools, scalable modules and 20 years of Vector networking know-how.

Get on board: www.flexray-solutions.com

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart, Germany

Tel. +49 (0) 7 11 / 8 06 70-0

www.vector-informatik.com

Get the FlexRay Reference

Chart now!

www.flexray-solutions.com

ECUCalibration

06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:17 Uhr Seite 6

Page 38: Vector Press Book

1/32

The Optimal Operating System for FlexRay-Based Applications

As a scalable high-speed communication system with deterministic

behavior, FlexRay is the right solution for use as a data backbone,

for distributed control systems or for safety-relevant applications

in the automotive area. In contrast to event-triggered CAN commu-

nication, all messages are assigned to fixed communication inter-

vals. This offers to each participating ECU a cleary timed availabili-

ty of its data. The design of a FlexRay network requires that certain

fundamental parameters be defined for all participating network

nodes in a very early phase of development. These parameters

include baudrate, cycle length, number and length of the slots in

the static and dynamic segments or macrotick duration. This sched-

uling of communication processes is mapped in the communica-

tion-specific software components, but it can also influence the

time structure of the application software.

The operating system (OS) coordinates the interplay of all par-

ticipating software components. Both event-triggered and time-

triggered operating systems are commercially available, each one

having different services. Another available option is operating

systems with memory protection.

Which operating system is best suited to a FlexRay-based appli-

cation, and how should it be configured? In particular the question

arises of whether a time-triggered operating system is absolutely

necessary for synchronized FlexRay communication.

Fundamentals of event-triggered and time-triggered operating systems

Until now, event-triggered operating systems have usually been

used in the automotive area. The broadest acceptance is enjoyed by

the OSEK/VDX [1] OS, which in the future will also be available in

the form of an ISO standard. The goal of an operating system is to

provide, under optimal utilization of the hardware used, a supple-

mental run-time environment for managing functional units.

Defined operating system services offer this functionality. In

designing an application, at first time-independent, concurrent

subtasks are defined. The outcome of this are tasks or interrupts

compete for run-time assignment according to the operating sys-

tem’s scheduling algorithm:

Tasks are triggered by alarms or events. A distinction is made >

between Extended Tasks and Basic Tasks. Extended Tasks are

distinguished by their ability to wait for events.

Interrupt Services Routines (ISRs) are hardware-specific and >

are triggered by the hardware periphery. They have higher

priority than tasks and should therefore only be reserved

for subtasks requiring the fastest possible reaction time.

In a time-triggered operating system all processes and actions

under the control of the operating system are solely depending on

the time. For the application this results in strictly deterministic

time behavior.

AUTOSAR OS

AUTOSAR has taken the OSEK-OS as a basis and extended it to

enable support of time-triggered functionalities. The specific prop-

erties of the AUTOSAR OS [2] are provided in four expansion stages,

the so-called Scalability Classes (SC). Table 1 shows a summary of

the relationship between these properties and the Scalability

Classes. Only properties relevant to a FlexRay-based application are

listed. These properties are explained in the following.

The currently available specifications of BSW (Basic Software) and

RTE (Runtime Environment) do not cover memory protection yet.

This will be addressed in future versions of the BSW and RTE

specifications.

FlexRay is either introduced for its deterministic behavior or for its quick data transfer, depending on the application. Currently, its use in safety-related applications only plays a subordinate role. Criteria to be considered in the decision of which operating system to use together with FlexRay, besides deterministic behavior and performance, include memory protection and time monitoring. This article explains what is important in selecting the operating system and presents specific solutions offered by Vector Informatik in the context of AUTOSAR.

Scalabilty Class Comment

SC1 Event-triggered

SC2 Advanced development of OSEKtime

SC3 Advanced development of HIS-Protected OS

SC4

Sche

dule

Tabl

es

Tim

e M

onit

orin

g

Glob

al T

ime/

Sync

hron

izat

ion

Mem

ory

Prot

ecti

on

Table 1: FlexRay-relevant properties of the AUTOSAR OS

07 Press Book_Seite_1-32_1-37.indd 207 Press Book_Seite_1-32_1-37.indd 2 09.02.2010 13:28:59 Uhr09.02.2010 13:28:59 Uhr

Page 39: Vector Press Book

1/33

budget, time monitoring guarantees lower-priority tasks or inter-

rupts access to the processor to execute their tasks.

If an interrupt lasts too long, as in Case C of Figure 3, it is can-

celled so that the extended task can continue to execute.

Schedule Tables

The operating system manages multiple schedule tables. Each

schedule table consists of a list of defined time-based actions that

either activate tasks or send events to tasks.

Time monitoring

In a real-time system what is important is to process all tasks at the

right times. In the design phase sub-tasks are allocated fixed time

windows. To avoid delays at runtime a task may not tie up the CPU

longer than specified in the design. Therefore the operating system

monitors the execution time of each individual task and each inter-

rupt. OSEKtime [3] provides classic deadline monitoring for this

purpose: Tasks must be completed before their assigned deadlines.

If a violation occurs, the overall system triggers a reset. This type

of monitoring is inadequate for extended tasks that can wait for

events. That is why the AUTOSAR-OS working group has defined

execution time monitoring for each individual task and each inter-

rupt. This monitoring is defined by various parameters in the

configurator.

When a monitoring parameter is violated, depending on the con-

figuration the operating system initiates a “Reset_OS”, “Kill_Appli-

cation”, “Kill_Task” or “Kill_Interrupt” as a reaction to the error.

Figures 1–3 represent an AUTOSAR OS Scalability Class 2 with

time monitoring tasks and interrupts.

Figure 1 shows the the monitoring of an application consisting

of an extended task. The extended task is disrupted suspended

several times by an interrupt.

Due to a longer execution time of the extended task, e.g. for

handling Event 1 (Ev1), this may result in error handling, see Fig-ure 2. This exclusively affects the originator. According to the

For each task:

Timeframe: Monitoring time >

period (greater than the

execution time; it is not

absolutely essential that the

task be completed within the

monitoring time period; cf.

Figure 1 Case A).

Execution time budget: >

Worst case execution time per

monitoring time period.

If multiple activation of a Basic

Task should be allowed in the

operating system’s configura-

tor, the execution budget con-

tains the total execution time

of all activations of the affect-

ed task. In principle multiple

activations are not possible for

extended tasks.

For each interrupt:

Timeframe: See Task >

Worst case execution time per >

execution

Max. number of interrupts per >

Timeframe

Multiple interrupts may be

allowed per Timeframe. Howev-

er the worst case execution time

only refers to a single loop pass.

The effect of an additional

interrupt per Timeframe is

shown in cases B and C of fig-

ures 2 and 3.

Figure 1: Case A – Without error handling

07 Press Book_Seite_1-32_1-37.indd 307 Press Book_Seite_1-32_1-37.indd 3 09.02.2010 13:28:59 Uhr09.02.2010 13:28:59 Uhr

Page 40: Vector Press Book

1/34

software modules from different producers are integrated in an ECU

the different software packets can be separated at runtime in terms

of their memory areas. A processor with hardware support is also

necessary. In addition, it should have a large memory and high

processing speed, since memory protection mechanisms slow down

operating system services by a factor of 1.5 to 2 on average.

Process of data exchange between FlexRay bus and application

Any of the four AUTOSAR-OS properties presented may be selected,

and their costs and benefits must be weighed against one another

from a production implementation point of view. Thereby consider-

ation must be given to the OS for optimal support of the synchroni-

zation of the data exchange between FlexRay and the application.

Global Time/Synchronization Support

Distributed control systems requiring synchronization of tasks

beyond ECU boundaries need the support of a global time provided

to the operating system on a regular basis. An application may syn-

chronize to the global time either:

Stepwise, as soon as the global time is made available and >

according to the maximum adaptation step from the

configuration (“smooth”), or

By complete adaptation in one step (“hard”). >

Memory Protection

Mechanisms for memory protection are necessary for early detec-

tion and prevention of disturbances by other modules. When

Figure 2: Case B – With error handling caused by excessively long execution time of the task

Figure 3: Case C – With error handling caused by excessively long execution time of an interrupt

07 Press Book_Seite_1-32_1-37.indd 407 Press Book_Seite_1-32_1-37.indd 4 09.02.2010 13:28:59 Uhr09.02.2010 13:28:59 Uhr

Page 41: Vector Press Book

1/35

the application needs and the availability of the operating system

properties. In principle, communication tasks should be triggered

by the CC’s FlexRay timer. Activation of application tasks, on the

other hand, could be triggered by any desired timers. Four solution

approaches are explained in the following:

Solution A – Alarms attached to the OS System Timer trigger the

application tasks.

At the beginning of each base cycle the “FlexRay Cycle Start

Interrupt” is triggered by the FlexRay controller. The communica-

tion task is activated immediately. Independently, the operating

system timer initiates the sequence of application tasks. Figure 4

shows a simplified form of this solution approach with just one

application and one communication task. It should be noted that

later triggering of a Cycle Start Interrupt, e.g. caused by drift

between the CC oscillator and the Host oscillator, results in delayed

processing of the transported FlexRay data (e.g. from frame 2) of

max. ∆tOS = 1 ms. If the application does not expect a quicker reac-

tion time, an OSEK-OS is sufficient.

Solution B – If the control system requires a shorter response

time (less than 1 ms), triggering of the application task requires a

High Resolution Timer (resolution approx. 10 microseconds) with

the OSEK-OS. A suitable timer is then needed.

Solution C – If the ECU does not have a High Resolution Timer,

the FlexRay timer can be additionally used to activate time-critical

application tasks. FlexRay-independent tasks can continue to be

attached to the OS System Timer.

In the FlexRay protocol up to 64 base cycles are combined to

form a continuously repeating round. Each base cycle contains

frames with different process data or signals for different applica-

tion tasks. With its global time the FlexRay protocol provides the

foundation for synchronized data exchange. As soon as the data

network has been synchronized this global time is available to

every Communication Controller (CC) in the network.

In a distributed control system a function is distributed among

multiple ECUs in a network. The dead time caused by the signal

propagation time from the sending application to the receiving

application can have a decisive influence on the quality of control.

In principle, a small dead time has a beneficial effect.

In event-triggered communication systems the exchange of data

between CC and Host is essentially interrupt-driven, and accessing

to the bus may result under some conditions in wait times. The sig-

nal propagation time cannot be predicted precisely; therefore a

worst case estimate is typically made. Not until a network-global

time of the FlexRay protocol is made available can the operating

system offer services for synchronization to this time. Via the TDMA

(Time Division Multiple Access) method all participating ECUs are

aware of the precise point in time each message is sent or received

in the static area of the FlexRay cycle. These two properties mini-

mize imprecision with regard to the signal propagation time of a

FlexRay-based application.

For synchronizing the exchange of data in a FlexRay-based appli-

cation various methods of resolution are possible, depending on

THE OPTIMAL OPERATING SYSTEM FOR FLEXRAY-BASED APPLICATIONS

Figure 4: Solution A – Data exchange between FlexRay and an application task with OSEK-OS

07 Press Book_Seite_1-32_1-37.indd 507 Press Book_Seite_1-32_1-37.indd 5 09.02.2010 13:29:00 Uhr09.02.2010 13:29:00 Uhr

Page 42: Vector Press Book

1/36

In startup behavior it should be noted that the FlexRay timer,

and consequently also the tasks that it activates, are unavailable

until the FlexRay controller has synchronized to the network for the

first time. If synchronization is lost afterwards, the FlexRay timer

can continue to operate based on its local time, provided that the

FlexRay controller was configured for this. An AUTOSAR OS of Scal-

ability Class 1 with schedule tables is sufficient for this purpose.

This solution enables a control system distributed over multiple

ECUs, since the FlexRay global time assures synchronization

between all ECUs. This solution approach is depicted in Figure 5.

Solution D – If in the above cases it is also necessary to monitor

the execution time of tasks and interrupts, an AUTOSAR OS SC2 or

SC4 is required. This prevents excessive execution times and

achieves time deterministic behavior.

Summary

A FlexRay-based application does not absolutely require a time-

triggered operating system. The choice of a suitable operating sys-

tem should be made individually for each ECU under consideration

of the application and architecture. For this purpose an analysis

pertaining to the synchronism among ECUs, safety requirements,

response time and time monitoring is necessary. Vector Informatik

offers the developer the optimal operating system for all FlexRay

applications: osCAN certified to the OSEK/VDX standard with or

without High Resolution Timer or osCAN AUTOSAR that covers Scal-

ability Classes SC1-SC4 according to AUTOSAR OS V2.0. The Vector

FlexRay software components will operate together with any of

these OS variants. The osCAN TimingAnalyzer analyzes the sched-

ulability of tasks from a worst-case perspective.

Vector supports the user with software components and individu-

alized service for universal development of FlexRay systems up to

series production. Development is simplified by mature tools that

are tuned to one another, like for instance DaVinci Network Design-

er for all FlexRay-typical design tasks or CANoe.FlexRay 6.0 for sim-

ulation and stimulation of a network, integration tests and rest-of-

bus simulation as well as analysis of the finished FlexRay network.

CANape 6.0 is used to access to all internal parameters of the

FlexRay ECU via the standardized measurement and XCP-on-FlexRay

calibration protocol. The FlexRay Evaluation Bundle provides for

quick and flexible implementation of a FlexRay network. This inte-

grated environment of software components and tools also includes

a sample application for a FlexRay system with two nodes.

Figure 5: Solution C – Data exchange between FlexRay hardware and an application task with AUTOSAR SC1 OS

07 Press Book_Seite_1-32_1-37.indd 607 Press Book_Seite_1-32_1-37.indd 6 09.02.2010 13:29:00 Uhr09.02.2010 13:29:00 Uhr

Page 43: Vector Press Book

1/37

THE OPTIMAL OPERATING SYSTEM FOR FLEXRAY-BASED APPLICATIONS

Literature references: [1] OSEK/VDX Operating System, Version 2.2.2, www.osek-vdx.org[2] AUTOSAR - Specification of Module Operating System V2.0, www.autosar.org[3 OSEKtime – OSEK/VDX Time-Triggered Operating System, Version 1.0, www.osek-vdx.org

Dirk Grossmann (Graduate Engineer) studied Electrical Engineering at the Univer-sity of Stuttgart. After graduating in 1997 he worked first in the development of operating systems at ETAS GmbH before assuming responsibility for operating systems as North American product manager for 2 years. Since 2003 he has been working at Vector as a team leader responsible for the development of FlexRay embedded software components.Tel. +49-711/80670-223, Fax +49-711/80670-111,E-mail: [email protected]

Pascale Morizur (Graduate Engineer) studied Physics/Electronics at the Grande Ecole ICPI in Lyon (France). After graduating in 1986 she worked for 10 years at MAN com-mercial vehicles in advanced development for CAN, J1939 and diagnostics. She is employed at Vector as a product management engineer in the area of FlexRay embedded software components.Tel. +49-711/80670-2211, Fax +49-711/80670-111,E-mail: [email protected]

Winfried Janz (Graduate Engineer) studied Electrical Engineering at the Univer-sity of Stuttgart. After working for 4 years developing software for embedded control-lers in control and automation engineering he came to Vector in 1995. Since 1997 he has been team leader and product manager responsible for the development of OSEK real-time operating systems. Through his work in OSEK and AUTOSAR working commit-tees he helped to give shape to the Operating System and Configuration specifications.Tel. +49-711/80670-367, Fax +49-711/80670-111,E-mail: [email protected]

07 Press Book_Seite_1-32_1-37.indd 707 Press Book_Seite_1-32_1-37.indd 7 09.02.2010 13:29:00 Uhr09.02.2010 13:29:00 Uhr

Page 44: Vector Press Book

1/38

Embedded Software for FlexRay Systems

The FlexRay bus protocol is an in-vehicle network on its way to the

starting line providing large transmission bandwidth for fast con-

trol systems. FlexRay enables 20 times greater bandwidth than CAN

and reduces complexity by using fewer gateways. Because of its

time-triggered control, it is especially well suited as a communica-

tion system for distributed, fault-tolerant systems and safety-rele-

vant applications. There is also the hope that the growing complex-

ity of vehicle electronics can be kept in check by standardization of

the software system architecture with AUTOSAR.

What does FlexRay ECU software need to look like?

To fully exploit the advantages of FlexRay-based communication, it

makes sense to fundamentally develop the associated basic soft-

ware according to the AUTOSAR specification. AUTOSAR specifies a

new development methodology, software architecture and basic

software. OEMs may gradually introduce it step-by-step on new

vehicle models. The standard-conformant ECU-specific software is

modularly structured (Figure 1). This enables partitioning of the

software components above the RTE and the basic software below

the RTE. The basic software has a modular internal structure and is

specified by clearly defined interfaces, so that software from any

source can be used in integration. In addition, the standard defines

which exchange formats can be used and how the interfaces

between individual modules need to operate.

This modularity makes it easier to scale software features to the

specific requirements of a vehicle variant or generation, e.g. ECUs

without network management. Development effort for the basic

software can be reduced for both OEMs and ECU suppliers because

the individual software modules can be delivered fully preconfig-

ured by the software supplier. This lets developers place greater

focus on innovations and the actual development of functions than

was previously possible in development.

Special aspects and benefits of implementing modularized software

Standardized software components will help in mastering the growing complexity of the interplay of all software compo-nents in an ECU. The ways in which today’s ECU software should be developed for FlexRay were presented at the Vector FlexRay Symposium in March of this year.

08 Press Book_Seite_1-38_1-41.indd 208 Press Book_Seite_1-38_1-41.indd 2 09.02.2010 13:25:59 Uhr09.02.2010 13:25:59 Uhr

Page 45: Vector Press Book

1/39

Network management handles the coordination of all ECUs in the

cluster with regard to communication needs for the bus system. If

all of the bus nodes no longer have communication needs, the syn-

chronous transition to the Bus Sleep ECU mode is initiated.

The FlexRay transport protocol is also placed on the FlexRay

interface. It handles the task of taking large data packets that can-

not be sent in one PDU, breaking them down into segments, and

reassembling them on the receiving side.

Just how modular adaptation works in practice is demonstrated

by the example of two FlexRay drivers for a FlexRay controller from

Freescale and from NEC. The driver is optimally adapted to the spe-

cific hardware used and utilizes its existing features while still

Embedded Architecture for FlexRay

The schematic layout of FlexRay basic software from Vector is

depicted in Figure 2. FlexRay-specific components such as the

interface, driver, network management (NM), and transport proto-

col (TP) are all contained in the FlexRay stack. The driver abstracts

the hardware, making it possible to service different communica-

tion controllers (CC). The driver initializes the controller, sends and

receives frames and detects controller errors. The interface commu-

nicates with the layers lying above it, processes PDUs (Protocol Data

Units) into frames and works in the reverse direction too. Moreover,

it issues send and receive acknowledgments to the affected layers.

Figure 2: Schematic layout of FlexRay basic software from Vector.

Figure 1: AUTOSAR layer model of ECU software with modular structure.

08 Press Book_Seite_1-38_1-41.indd 308 Press Book_Seite_1-38_1-41.indd 3 09.02.2010 13:26:00 Uhr09.02.2010 13:26:00 Uhr

Page 46: Vector Press Book

1/40

that accesses measurement data in an address-oriented way, which

are then acquired task-synchronously (event driven) in the ECUs.

Dynamic bandwidth management

A connection is established via an initial communication channel

that is defined in the ECU description file (A2L). By transport layer

commands, the XCP Master controls allocation of available slots in

the dynamic section of a cycle and thereby enables channel exten-

sion for transmission of measurement and calibration data. This

“load distribution” is performed dynamically at runtime for optimal

bandwidth utilization. Since multiple ECUs communicate over the

same bus, a slot cannot be assigned exclusively; rather so-called

slot multiplexing makes it available to multiple ECUs. This makes

sense if less bandwidth is needed for a measurement, e.g. if an ECU

does not need to send a message each cycle. Each message gets a

unique address for this purpose (LPDU-Id, Data Link Layer Protocol

Data Unit Identifier), which describes the slot, cycle and channel.

This makes it possible to fill the same slot with data from a differ-

ent ECU in each send cycle.

The measurement data are provided with a timestamp making it

possible to query measurement values at shorter intervals than the

cycle time. For example, a measurement may occur every 2.5 ms, even

if a system has a 5 ms cycle. It is only necessary to ensure that the

bandwidth is sufficient to transmit the data within a required time.

The ECU must reserve and dynamically configure transmission

and reception buffers by allocating RAM for this communication.

The RAM may be located in the controller or it may be necessary to

use external memory managed by the FlexRay driver.

Just how many slots are available for XCP and how slots should

be distributed must be defined early on – namely during system

definition. This is done in the FIBEX file by also defining the slots

reserved for XCP. Various scenarios are possible here:

providing the layer above it with an unchanged “view” and mode of

behavior. In the case of the 16-bit S12X controller from Freescale,

the FlexRay driver must manage the buffer-RAM, since in this case

the necessary memory space must be swapped out to the system-

RAM. The 32-bit NEC V850 controller already contains a large RAM

for the buffers in the FlexRay controller. This is where the driver

performs its efficient partitioning and utilization.

ECU calibration with XCP on FlexRay

It is even easy to integrate components developed at a later time in

the architecture, e.g. components that became necessary because

of new protocols or extended standards. These interfaces must also

conform to the AUTOSAR standard. For example, XCP functionality

might be added to the previously described FlexRay stack in order

to enable measurement and calibration of internal signals of the

FlexRay ECUs.

XCP is a universal communication protocol for optimizing the sys-

tem parameters of an ECU. Due to the separation of protocol layer

and transport layer, XCP can be operated in various types of com-

munication networks (XCP on CAN, FlexRay, Ethernet, USB, RS232

or SPI/SCI). The clear separation of layers is also reflected in the

integration in the FlexRay stack. The universal protocol layer XCP

lies above the FlexRay-specific transport layer (FrXCP), which in

turn enables signal exchange with the FlexRay interface (Figure 3).

Due to dynamic bandwidth allocation, the driver must handle the

additional task of buffer configuration during measurement or cali-

bration. Therefore, this module is replaced by an extended version

of the standard AUTOSAR driver.

XCP is an address-oriented protocol. Communication takes place

between a controller component and a similarly structured soft-

ware component in the XCP Master. Generally, the XCP Master is a

measurement and calibration tool (such as CANape from Vector)

Figure 3: Integration of XCP in the FlexRay stack with clear separation of proto-col layer (XCP) and transport layer (FrXCP).

08 Press Book_Seite_1-38_1-41.indd 408 Press Book_Seite_1-38_1-41.indd 4 09.02.2010 13:26:01 Uhr09.02.2010 13:26:01 Uhr

Page 47: Vector Press Book

1/41

Each ECU occupies its own slot >

Multiple ECUs utilize the same slot >

In this case each ECU has its own address (NAX, Node Address >

for XCP). XCP transport layer commands are used to activate or

deactivate the buffer

Buffers are configurable, which corresponds to dynamic >

allocation

Regardless of the transport protocol used, the user interface of a

tool (XCP Master) should always represent the actual measurement

and calibration task adequately. Applications engineers can then

optimally tune ECU parameters independent of the bus system used

for communication.

The calibration engineer works with symbolic names, which allows

the parameters and measurement variables to be found in the ECU

without needing to know the encoded addresses of specific vari-

ables. The calibration tool uses the ECU description file to come up

with the link between the name and the physical address (Figure 4).

Universal support in all development phases

The FlexRay developer gets universal support from the Vector com-

pany: From system description to implementation of the base soft-

ware and calibration of the ECUs. This includes tools for design,

development, simulation, analysis, testing of ECUs, and distributed

networks and their bus interfaces. The first measurement, calibra-

tion and diagnostic tool to support XCP on FlexRay is CANape. With

ready-to-use software stacks for ECUs and XCP-on-FlexRay support

on the part of the calibration tool, the user gets components that

are perfectly coordinated with one another, are set up to be univer-

sal with AUTOSAR conformance, and can thereby be flexibly

implemented.

EMBEDDED SOFTWARE FOR FLEXRAY SYSTEMS

Dirk Großmann (Graduate Engineer) studied electrical engineering at the Univer-sity of Stuttgart. Since 2003 he has been employed as team leader responsible for the development of FlexRay embedded software components at Vector.Tel. +49-711/80670-223, Fax +49-711/80670-111,E-mail: [email protected]

Oliver Kitt (Graduate Engineer) studied physics at the University of Stutt-gart. As team leader he is responsible for the development of measurement and calibra-tion protocols in CANape.Tel. +49-711/80670-327, Fax +49-711/80670-111,E-mail: [email protected]

Figure 4: XCP is implemented as a master/slave structure. The XCP slave is located in the ECU; the XCP Master is located in the measurement and calibration tool.

08 Press Book_Seite_1-38_1-41.indd 508 Press Book_Seite_1-38_1-41.indd 5 09.02.2010 13:26:01 Uhr09.02.2010 13:26:01 Uhr

Page 48: Vector Press Book

FlexRayBecomes Daily RoutineMore and more engineers are nowadays confronted in their daily

job with new challenges and tools required by the introduction of

FlexRay as a new bus system for automotive applications. This arti-

cle shows how engineers successfully meet the challenges of ana-

lyzing, simulating, and testing FlexRay ECUs and networks using

CANoe.FlexRay from Vector.

1 lA U T O M O T I V E 2 0 0 7 lS P E C I A L E D I T I O N F L E X R AY

D uring the development of FlexRay ECUs and

systems, engineers commonly encounter chal-

lenging tasks such as startup simulation, ECU

tests and network simulation. This article describes how

CANoe.FlexRay is already enabling FlexRay engineers

to efficiently perform these tasks in a routine way.

Startup Simulation

A synchronized bus is a major requirement for a FlexRay

communication. Before the application can communicate,

the bus must be started. During this startup phase the bus

is in an asynchronous mode until at least two ECUs have

synchronized their FlexRay clocks and provide sync frames

so that other ECUs can integrate into the TDMA (Time Divi-

sion Multiple Access) schedule. If the FlexRay communi-

cation of a single non-startup/sync ECU is being tested,

then the analysis tool needs to be able to simulate a Flex-

Ray bus that has already started. CANoe.FlexRay can gene-

rate two startup/sync frames in order to provide this type

of startup of a FlexRay bus. The startup phase of a cluster

can be observed using the asynchronous mode of Vector’s

FlexRay interfaces VN3300 (PCI), VN3600 (USB) or VN7600

(USB with CAN interfaces). It is possible for example to

receive wakeup pattern, symbols, startup and normal fra-

mes before the cluster is in synchronous mode. The bus

can also be analyzed in this mode without using a FIBEX

C A N O E . F L E X R A Y E N A B L E S E N G I N E E R S T O S O L V E B O T H R O U T I N E A N D C H A L L E N G I N G F L E X R A Y T A S K S

1/42

09 Press Book_Seite_1-42_1-45:Press Report 3 09.02.2010 13:16 Uhr Seite 1

Page 49: Vector Press Book

SPECIAL EDIT ION FLEXRAY lA U T O M O T I V E 2 0 0 7 l2

database. Only the baud rate is required in

order to initialize the bus interface. To star-

tup a sleeping cluster, wakeup pattern and

symbols can be sent. The synchronous

mode is the default mode, in which frames

can be sent. The asynchronous and syn-

chronous modes can also be combined so

that the interface changes its mode auto-

matically according to the clock synchroni-

zation state giving FlexRay engineers full

analysis and simulation features at all

times.

ECU Test by StimulationThe easiest way of testing an ECU is to

send frames interactively using CANoe’s FlexRay Frame

Panel. Using this integrated panel a FlexRay frame’s paylo-

ad (i.e. its signals) can be interactively modified during run-

time. Signals for all bus systems can be modified via user-

defined Control Panels. Using Signal Generators it is also

possible to change a signal’s value according to predefined

functions. For more advanced signal generation (e.g. arbi-

trary signal sequences or reactions to previous responses)

the programming language CAPL should be used. Using

the Test Feature Set of CANoe automated ECU tests can

be defined, executed, and reported.

ECU Test by ObservationDuring the development of any real ECU it is crucial to gua-

rantee that the ECU communicates in conformance with

FlexRay’s schedule table. Especially for frames in the sta-

tic segment a periodically time-triggered transmission is

assumed. CANoe can directly test and visualize whether

all expected frames (according to their Cycle Multiplexing)

of a specific ECU (sender) are on the bus. This feature is

implemented in CANoe.FlexRay as the FlexRay Cluster

Monitor. It helps engineers to identify the following:

Which nodes are online and sending?

Are all specified frames sent by a specific node?

Are the frames sent in all scheduled cycles?

The Cluster Monitor can also be used in offline mode to

analyze log files. More extensive tests can be implemen-

ted in the programming language CAPL (also for the offli-

ne analysis).

ECU Test by SimulationIn order to test the functional behavior of any real ECU, its

environment must be simulated. The system or device

under test is usually embedded into a (Hardware-in-the-

Loop) simulation. A minimal remaining bus simulation

generates input frames and reacts to output frames from

the ECU under test. Optionally an environment model can

be simulated, which generates sensor inputs and reacts to

actuator outputs. A simple example would be a model of a

discrete and interactive user panel. In more complex cases

a quasi-continuous control algorithm (e.g. defined by Mat-

lab/Simulink) may be executed under the control of CANoe.

Due to the time-triggered communication according to a

global FlexRay time, the algorithms for the simulated con-

trollers and ECUs must be synchronized with the FlexRay

schedule. The execution platform must therefore provide

synchronization points, guarantee small latencies as well

as constant and minimal jitters. This guarantees to provide

timely correct data updates on the bus. For the environ-

ment or remaining bus simulation the execution platform

must be deterministic. CANoe RT, along with its hardware

extensions RT Box and RT Rack, provides such a high per-

formance and deterministic platform.

CANoe and CANoe RT and their hardware

extensions can be seamlessly scaled to

meet the desired performance as well as

the number of required bus and I/O inter-

faces. For both CANoe and CANoe RT the

same (simulation) models can be used.

Cluster SimulationIn the early design phases of a FlexRay

system it is important to test whether the

timings are correct and/or the performan-

ce of an ECU matches the communication

schedule. In other words, to check whet-

her all frames can be received and trans-

mitted in the reserved time. The FlexRay

engineer therefore typically creates a (par-

Figure 1:The FlexRay Frame Panel makes it easy to interactively send

FlexRay frames

© automotive

Figure 2:The Cluster Monitor for displaying the send conformity

of FlexRay nodes and their messages

© automotive

1/43

09 Press Book_Seite_1-42_1-45:Press Report 3 09.02.2010 13:16 Uhr Seite 2

Page 50: Vector Press Book

3 lA U T O M O T I V E 2 0 0 7 lS P E C I A L E D I T I O N F L E X R AY

tial) remaining bus simulation by adding a FIBEX database

to CANoe.FlexRay and by defining the nodes required for

the system under test. The CANoe.FlexRay’s features

allow the full bus load, which is generated by all ECUs of a

cluster, to be simulated. The communication matrix and the

FlexRay schedule in the FIBEX database are used to confi-

gure the simulation of all required ECUs. All frames are

automatically sent on the bus with default values. With Vec-

tor’s interfaces the theoretical maximum frame throughput

can be sent without running into resource problems (e.g.

lack of send buffers). In this way all FlexRay ECUs can be

simulated using only one tool and one bus interface.

FlexRay offers direct support of network management and

sleep/wakeup functionality. The bus transceivers of the

Vector hardware interfaces can be switched to sleep mode

in order to simulate a power off node. In this case only a

wakeup pattern is received. Wakeup patterns can be sent

in order to wake up a sleeping cluster. Using a special

extension to CANoe.FlexRay, any simulated node can par-

ticipate at the network management layer according to the

AUTOSAR-NM protocol.

Gateway SimulationGateways are used to transfer messages/frames/signals

between two or more buses. CAN/FlexRay-gateways are

typically unavoidable when FlexRay is implemented for

automobiles based on CAN. As a multi-bus tool for CAN,

LIN, MOST, and FlexRay, CANoe is capable of both simu-

lating and analyzing gateway applications.

A virtual gateway can also be used to simulate errors in the

communication between ECUs. The device under test is

isolated from the real bus by a FlexRay-FlexRay-gateway

that is simulated by CANoe. Errors can be integrated by

manipulating signals that are sent by the real ECUs. Optio-

nally the two FlexRay clusters can be synchronized. Syn-

chronously running clusters guarantee minimal delays bet-

ween the signal occurrences on both buses.

SummaryAll these application scenarios occur during the routine

work of engineers developing FlexRay products.

CANoe.FlexRay is a powerful tool to help engineers in their

everyday work when handling the new technical challen-

ges of FlexRay buses. CANoe is the flagship of Vector’s

comprehensive portfolio of tools and embedded software

components which are ready for both current and future

FlexRay applications.

Figure 3: CANoe RT is a real-time capable and deterministic execution platform

© automotive

Gavin C. Rogers B.Eng. M.Sc. is TeamManager in the “Tools for Networks andDistributed Systems” product line.

Dr. rer. nat. Carsten Böke is Senior Soft-ware Development Engineer for the“Tools for Networks and DistributedSystems” product line.

© Carl Hanser Verlag, München 2007. All rights includingreprinting, photographic reproduction and translationreserved by the publishers.

1/44

09 Press Book_Seite_1-42_1-45:Press Report 3 09.02.2010 13:16 Uhr Seite 3

Page 51: Vector Press Book

The CustomerBertrandt AG is one of Europe’s leading development part-ners in the automotive and aerospace industries. About 5500 employees at 30 business sites in Europe and in the USA work on customized solutions ranging from indivi-dual components and modules to complete systems and vehicles.

The ChallengeTesting FlexRay ECUs effectively and reproduciblyProper behavior of FlexRay ECUs in normal operation and

under fault conditions is to be tested beginning in early

development phases. Test sequences of complex test cases

need to be executed, but it must also be possible to manually

start individual tests. The tests require a real-time capable

remaining bus simulation, to enable reliable statements

about the communication behavior of the ECU under test.

The SolutionECU tests within a remaining bus simulation on a FlexRay test benchBertrandt created a special test system to conduct reproduc-

ible testing of FlexRay ECUs. It contains a simulated vehicle

environment that is implemented with an extensive and real-

time relevant remaining bus simulation. CANoe.FlexRay is

used here to simulate the remaining bus for the ECU under

test. To fulfill demanding real-time requirements, CANoe RT is

used to distribute CANoe.FlexRay functionality between two

computers. The simulation is executed on a high-performance

computer, the Real Time Rack. The configuration and user

interface run on the host computer of the test bench. The two

computers are interconnected via Ethernet.

The AdvantagesA high-performance and flexible environment for complex ECU tests over the FlexRay busFor conducting the simulation, Bertrandt uses CANoe.FlexRay

together with CANoe RT and the Real Time Rack to implement

a high-performance test system for FlexRay:

Testing an ECU with remaining bus simulation Testing

is already possible in early development phases without

requiring availability of real ECUs.

Using OEM-specific modules such as the Interaction Layer,

Transport Protocol, checksum calculation, etc. in the

remaining bus simulation Quick and easy implementa-

tion of the remaining bus simulation and standardized

execution of OEM-specific functions.

Execution of remaining bus simulation with CANoe RT

Simulation is characterized by deterministic execution,

short latency and quick response times.

Remaining bus simulation is executed exclusively on the

Real Time Rack No disturbance of the simulation by the

PC’s operating system.

Real Time Rack is scalable Flexibly adaptable to future

test system requirements, e.g. number of FlexRay channels

or modification for other bus systems.

Case StudyTesting FlexRay ECUs effectively and reproducibly

We would be glad to provide you with an individual quotation:[email protected]

09 Press Book_Seite_1-42_1-45:Press Report 3 09.02.2010 13:16 Uhr Seite 4

Page 52: Vector Press Book

SPECIAL EDIT ION FLEXRAY lA U T O M O T I V E 2 0 0 6 l1

T o support the time-critical data transfer a FlexRay

simulation platform must be capable of genera-

ting periodic signals and messages at a high

cycle rate. Additional requirements include:

� the support of multi-rate systems with different cycle

periods (Cycle Multiplexing)

� constant and least possible jitter when activating and/or

executing application code

� short response times between receiving and sending of

frames

� permission of in-cycle responses.

To achieve the desired deterministic time behavior, one of

the main focuses is to aim for the least possible overhead

of the operating system, communication stack and run-

time environment.

In a simple but high-performance test system, ideally only

one simulation hardware (PC) and only one bus interface is

needed for real-time simulation of multiple FlexRay ECUs.

The limitations on TX and RX buffers like in real FlexRay

controllers should not exist here. Access to the FIBEX data-

base format is essential so that users can utilize symbolic

signal and message names from a relevant database. The

communication controller should be automatically pro-

grammed with the parameters read out from the FIBEX

database. Automatic sending of FlexRay messages based

on schedule tables in the FIBEX database is an important

requirement, too.

The system should detect and report any synchronization

problems between the bus schedule and the application.

The simulation model may require synchronism implicitly.

In actual operation, however, this requirement may be

violated by interruptions, jitter or incorrect modeling

(Figure 1).

Notification concept

The bus analysis, test and simulation tool CANoe.FlexRay

supports all mentioned requirements on remaining bus

simulations for FlexRay systems. In CANoe the notification

concept serves as the underlying architecture for executing

simulation models. For use with FlexRay it was specially

extended to include capability of synchronous notifications

at specific time points in the FlexRay cycle (Figure 2). That

is how actions can be executed regularly at the beginning

of the cycle or after a specific slot has ended. Of course,

notifications are also possible when frames are received or

To detect errors in the

design of a FlexRay system

or schedule it is important

to simulate the system early

in the development process. In choosing a simulation environment

the FlexRay developer sets demanding requirements on system com-

ponents to permit real-time simulation. This article shows how these

requirements are satisfied by a simulation platform based on the

bus analysis, testing and simulation tool CANoe.FlexRay.

FlexRay

Sets the Pace

1/46

10 Press Book_Seite_1-46_1-49:Press Report 1 09.02.2010 13:12 Uhr Seite 1

Page 53: Vector Press Book

2 lA U T O M O T I V E 2 0 0 6 lS P E C I A L E D I T I O N F L E X R AY

are missing. Any of the notifications may be limited to spe-

cific cycles (Cycle Multiplexing). The notification concept

implicitly assumes that the actions occur at the time points

named above.

Send requests are normally executed at the next possible

send time after notification. If this send time is no longer

achievable due to faulty modeling or interruptions, the

system instructs the user by an alarm indication. This ena-

bles detection of errors in the model or simulation platform

in very early modeling phases.

Support of the modelTo simplify specification of model behavior, first of all the

capability was created for symbolically accessing signal

and message definitions in a FIBEX database; signals may

be interpreted and modified outside of the frame view.

Second, a buffer mechanism (Signal Layer) was imple-

mented to enable reading and modification of signal values

at any time. CANoe.FlexRay automatically receives and

sends the associated FlexRay frames in background, whe-

reby the send times are prescribed by the schedule in the

database.

CANoe offers the capability of specifying the behavior of

models in CAPL, a C-like programming language. The code

is not interpreted, rather it is executed directly on the

machine level. That makes CAPL especially predestined for

high real-time requirements and discrete models.

The software is also capable of simulating very complex

and quasi-continuous models. MATLAB/Simulink models

can also be linked directly to CANoe using a DLL genera-

ted by the CANoe internal Realtime Workshop and a spe-

cial extension (Figure 3).

The data of different frames belonging to the same system

state must always be kept consistent. If at the time the

data is transferred to the TX buffer the send time of some

of the frames has already been exceeded, only some of the

messages can be sent correctly. The others will either be

missing or contain obsolete data from the previous cycle.

This problem is solved by CANoe’s strategy of transaction-

based updating of multiple TX requests, in which either all

or none of the send updates of a cycle are executed.

Dedicated simulation environmentIn simulating a model on hardware that is not real-time

capable and on a nondeterministic operating system, inter-

ruptions and delays may occur in notification and execution

under certain circumstances. This results in large and non-

deterministic jitter when accessing the communication

medium. However such types of problems can generally

be minimized by deactivating certain system services and

applications that are not needed.

In projects with especially demanding real-time require-

ments, CANoe benefits from its dual-PC architecture (Figu-re 4). This is realized by two sub-applications which run on

different computers, so that real-time processing can be

separated from analysis and user control. The Soft Real-

Time Client handles user interactions and the analysis sec-

tion, while the Real-Time Server is responsible for execu-

ting the models in real-time and interfacing to the bus

systems and other I/O interfaces. The Real-Time Server

may run on Windows XP Embedded, and Windows CE will

also be supported beginning in the first quarter of 2007. For

the most exacting real-time requirements Windows CE is

recommended together with special customized hard-

ware, e.g. VN3300 from Vector Informatik. This combina-

tion is capable of task switching times less than 10 micro-

seconds and response times of approx. 600 microseconds.

Figure 1. Example of undersampling and oversampling

in an unsynchronized application

© automotive

Figure 2. Examples of notification and activation time points in relation to the FlexRay schedule© automotive

1/47

10 Press Book_Seite_1-46_1-49:Press Report 1 09.02.2010 13:12 Uhr Seite 2

Page 54: Vector Press Book

The dual-PC architecture is fully transparent to the user,

since it handles all interactions and configuration tasks with

the Soft Real-Time Client. Ethernet is used to network the

two computers. The primary advantage of this highly opti-

mized run-time environment is that the Real-Time Server is

responsible for 100 % of the bus load of the FlexRay clu-

ster. Such a system is characterized by high update rates,

short response times and constantly small delays and jitter.

It enables simultaneous simulation of multiple ECU nodes,

executes the models precisely synchronous to the com-

munication cycle and handles in-cycle responses. Of cour-

se, in simulations with lower real-time requirements

CANoe can also deliver excellent results on single-PC con-

figurations under Windows 2000 or Windows XP.

Bus interfacesFor bus access the simulation systems need high-perfor-

mance interfaces that can be obtained from Vector. The

VN3300 is a FlexRay interface for the PCI bus that is espe-

cially well-suited to real-time capable simulations. The

VN3600 connects the PC to FlexRay busses via USB and

is designed for typical bus analysis tasks. Both interfaces

can receive and/or send the maximum possible bus load

per cycle. There is no limitation on TX buffers.

SummaryThe presented real-time simulation system CANoe.Flex-

Ray meets all requirements on a flexible and powerful

simulation system for a FlexRay bus. It decouples model

creation from the used execution platform, so that no adap-

tation effort is necessary. Its special simulation mecha-

nisms and dual-PC architecture also make CANoe a con-

vincing solution in projects with higher real-time require-

ments. All FlexRay solutions from Vector offer dedicated

and special features that support the special properties of

FlexRay systems optimally.

(All Figures: Vector Informatik GmbH)

SPECIAL EDIT ION FLEXRAY lA U T O M O T I V E 2 0 0 6 l3

Figure 3. MATLAB/Simulink support in CANoe© automotive

Figure 4. Dual-PC architecture of CANoe

© automotive

Dr. rer. nat. CarstenBöke is Senior SoftwareDevelopment Engineerfor the “Tools for Networks and Distributed Systems” product line.

© Carl Hanser Verlag, München 2007. All rights includingreprinting, photographic reproduction and translation reserved by the publishers.

1/48

10 Press Book_Seite_1-46_1-49:Press Report 1 09.02.2010 13:12 Uhr Seite 3

Page 55: Vector Press Book

1/49

10 Press Book_Seite_1-46_1-49:Press Report 1 09.02.2010 13:12 Uhr Seite 4

Page 56: Vector Press Book

Ef fi cient Ac cess to the Flex Ray Bus

The var i ous tasks of Flex Ray de vel op ment and as so ci at ed tests re -

quire in ter fa ces for both sta tion ary PCs and mo bile note books (Fig -

ure 1). In both cas es, they need to sat is fy spe cial re quire ments for

sim u la tion, anal y sis, cal i bra tion and test ing. For ex am ple, an ECU’s

stand ard con trol ler rec og niz es when er rors oc cur, but does not pro -

vide any in for ma tion what so ev er on their caus es. For a qual i fied

anal y sis, the de vel op er needs – be sides the Flex Ray mes sa ges and

sig nals them selves – pre cise time stamps, com pre hen sive in for ma -

tion and de tailed item i za tion of all states on the bus and in the in -

ter fa ces. Com pared to pre vi ous au to mo tive bus sys tems, tech ni cal

re quire ments for Flex Ray are sig nif i cant ly more strin gent. Since

Flex Ray’s op er a tion is not event-driv en, but in stead is time-trig -

gered, it is nec es sa ry to syn chro nize all bus nodes. Send times are

pre cise ly spec i fied by the cy clic and syn chro nous time-di vi sion

mul ti plex ing TDMA (Time Di vi sion Mul ti ple Ac cess) bus ar bi tra tion.

Flex Ray In ter fa ces for all Re quire mentsA new gen er a tion of Flex Ray in ter fa ces de liv ers the right so lu tions

for all sit u a tions oc cur ring in prac tice. In par tic u lar, one fo cus in

their de vel op ment was a high lev el of as sur ance of fu ture util i ty.

For ex am ple, up dates to the Flex Ray stand ard due to FPGA (Field

Pro gram ma ble Gate Ar ray) tech nol o gy are fed-in by cus tom ers

them selves with driv er up dates.

On the one hand, be hav ior of the Flex Ray in ter fa ces from Vec tor

con forms to the stand ard; on the oth er, they are able to log all con -

ceiv a ble bus events due to their sup ple men tal FPGA log ic. They

record 100% of the bus traf fic of both Flex Ray chan nels. The cen -

ter piece – an In tel PXA270 mi cro con trol ler to geth er with 8 MByte

RAM – is sup port ed by the Bosch E-Ray and Fu jit su MB88121B

Flex Ray com mu ni ca tion con trol lers. In ter change a ble as plug-in

mod ules, elec tri cal ly iso lat ed bus tran sceiv ers lend flex i bil i ty to

phys i cal bus ac cess with re gard to fu ture re quire ments.

Op ti mized for Anal y sisOver all, the in ter fa ces were op ti mized for the best pos si ble in ter ac -

tion with the sim u la tion and anal y sis tools CA Noe and CAN a ly zer,

and the meas ure ment and cal i bra tion tool CA Na pe (Fig ure 2). The

in ter fa ces not on ly recog nize all bus ac tiv i ties and buff er them as

nec es sa ry; rath er they al so pass all in for ma tion to the host. Dif fer -

ent than on con trol lers for ECUs, the con trol ler host in ter face is de -

1/50

PC in ter fa ces for var i ous stand ards arein dis pen sa ble tools in all de vel op mentphas es of au to mo tive elec tron ics, wher -ev er ac cess is need ed to what is hap pen -ing on the bus. OEMs and sup pli ers arebe ing con front ed with es pe cial ly com plex chal len ges with the cur rent in tro duc tion of the Flex Ray bus in firstpro duc tion ve hi cles. Much more than onthe CAN bus, high per form ance hard wareis a pre req ui site for ex pe ri enc ing re li a ble op er a tion in all sit u a tions andful ly ex ploit ing the po ten tial of soft waretools for sim u la tion and anal y sis.

High-per form ance Flex Ray Hard ware for Anal y sis and Sim u la tion

Fig ure 1: Hard ware in ter fa ces must al so be im ple men ta ble inmo bile Flex Ray ap pli ca tions.

11 Press Book_Seite_1-50_1-53:Press Report 4 09.02.2010 13:15 Uhr Seite 1

Page 57: Vector Press Book

achieve this. This per form ance is en a bled by the TX buff er that has

been ex tend ed to 2 MByte that can store over 1000 in de pend ent

send mes sa ges. Pre vi ous so lu tions typ i cal ly on ly had an 8 KByte TX

buff er.

The CA Noe RT plat form is es pe cial ly well-suit ed to small to mid-size

pro jects with re al-time re quire ments, such as hard ware-in-the-loop

sim u la tions. It iso lates vis u al i za tion and con trol func tions from the

re al-time sim u la tion. The sim u la tion is ex e cut ed troub le free on a

sep a rate com put er un der Win dows XP Em bed ded, and this guar an -

tees re li a ble up dates of send time points. The on ly in ter face that

comes in to con sid er a tion for this com put er, called a RT Box or RT

Rack, is a fast PCI in ter face such as the VN3300 (Fig ure 3).

For min i mal re sponse times and de ter min is tic tim ing be hav ior of

the ap pli ca tion, short la ten cy times and min i mal jit ters are

ab solute ly es sen tial. Be sides the time re quired for the ac tu al com -

pu ta tions of the ap pli ca tion, it is nec es sa ry to add the times for

trans port proc ess es through the dif fer ent com mu ni ca tion lay ers.

To achieve low PC load ing de spite this sit u a tion, DMA (Di rect Mem o -

ry Ac cess) was im ple ment ed in the Flex Ray hard ware. DMA en a bles

high trans mis sion rates and si mul ta ne ous ly re lieves the main pro -

cess or and gives it more time for com pu ta tions. La ten cy times were

signed to record all da ta, null and er ro ne ous frames as well as sym -

bols, in clud ing the as so ci at ed times tamps and pass them on to the

soft ware tools. This is the on ly way for de vel op ers to an a lyze,

mean ing ful ly in ter pret and there by sys tem at i cal ly troub le shoot

sour ces of er rors. If no Flex Ray syn chro ni za tion is es tab lished or no

FI BEX da ta base is avail a ble with TDMA pa ram e ters, an asyn chro -

nous bus anal y sis is pos si ble, in which it is on ly pos si ble to fol low

events and log them in read ing op er a tion. In this mode, it is al so

pos si ble to ob serve the star tup phase of a Flex Ray net work. The

meas ure ment and cal i bra tion tool CA Na pe gives de vel op ers the

abil i ty to ac cess in ter nal ECU pa ram e ters via the stand ard ized

XCP-on-Flex Ray pro to col. In this case, the Flex Ray hard ware sup -

ports re syn chro ni za tion of the Flex Ray in ter face if bus traf fic has

been in ter rupt ed.

Max i mum send Through put for Sim u la tionsThe re quire ments de mand ed by ECU sim u la tions on the PC, e.g. with

CA Noe, are sig nif i cant ly great er than those for anal y sis mode. Sin-

ce mul ti ple ECUs can be sim u lat ed si mul ta ne ous ly on a suf fi cient ly

fast com put er, the in ter face must al so be able to han dle the high er

da ta through put while tak ing all tim ing re quire ments in to ac count.

Par al lel sim u la tion of ten or more ECUs is en tire ly re al is tic. It is

note wor thy that it on ly takes one of the new Flex Ray in ter fa ces to

1/51

Fig ure 2:Hard ware in ter fa ces forthe en tire Flex Ray toolchain: Anal y sis, sim u la -tion, test ing and soft -ware mod ules as well asphys i cal gen er a tion ofbus dis turb an ces.

11 Press Book_Seite_1-50_1-53:Press Report 4 09.02.2010 13:15 Uhr Seite 2

Page 58: Vector Press Book

op ti mized – as was al ready done on CAN in ter fa ces from Vec tor. The

short est la ten cy times are sys tem-de pend ent and can be at tained

with PCI in ter fa ces.

In tel li gent aux il ia ry Func tions for ev ery day Work of Develop ersEx pe ri ence and cus tom er re quire ments on nu mer ous Flex Ray pro -

jects mo ti vat ed de vel op ers at Vec tor to in te grate a num ber of oth er

im por tant func tions in the Flex Ray in ter fa ces: hard ware sup port for

PDUs, au to mat i cal ly in cre ment ing mes sage coun ters, sim u la tion of

in ac tive ECUs, group up dates and au ton o mous bus start ca pa bil i ty.

To de cou ple the trans port lay er from the ap pli ca tions, in the lat est

Flex Ray net works PDUs (Pro to col Da ta Units) have been in tro duced,

in stead of work ing di rect ly with the rel e vant bus-spe cif ic da ta con -

tain ers. Sev er al such log i cal PDUs may lie with in a Flex Ray frame.

In this case, an ad di tion al piece of in for ma tion is need ed for each

PDU, in di cat ing wheth er or not the con tents are val id for the cur -

rent cy cle. One and the same PDU may al so be de fined in mul ti ple

frames.

The PDU con cept en han ces flex i bil i ty and en a bles easy re use of the

ap pli ca tion, but its dis ad van tage is that con sid er a bly more ef fort is

re quired to gen er ate and de code the Flex Ray frames. Pow er ful

FlexRay in ter fa ces com pen sate for this dis ad van tage by han dling

the mul ti plex ing and de mul ti plex ing of the PDUs in to and out of

the frames on the hard ware side.

Hard ware-based in cre ment ing of a pay load ar ea serves to re li a bly

sim u late a send er’s heart beat. That is be cause, if it is not pos si ble

to guar an tee this gen er a tion in a soft ware-based sim u la tion, the

re ceiv er might re ject the sig nal or even switch it self off. The in tel li -

gent hard ware pre vents this by re peat ed ly send ing the old sig nal

val ues with coun ter in cre ment ing, there by re li a bly sig nal ing that

the send ing de vice is still “alive”.

Sim u la tion of in ac tive ECUs en a bles lat er de le tion and sup ple ment -

ing of frames to be sent, even if the us er has not yet de fined them

at star tup. The bus tran sceiv ers can be switched to in ac tive (Sleep

mode), aft er which wake up pat terns are still de tect ed, how e ver.

The bus tran sceiv ers can al so ac tive ly ex e cute a wake up.

If da ta that be long to geth er do not fit in a Flex Ray slot, there is a

risk that it might not be pos si ble to con sist ent ly trans mit the da ta

in two frames of the same cy cle. This is rem e died by a “group up -

date”, where in the in ter re lat ed frames are al ways sent to geth er.

To start up a Flex Ray clus ter, it is nec es sa ry to have at least two

1/52

Fig ure 4: VN in ter fa ces from Vec tor ful fill the strict bus in ter -face re quire ments im posed by the Flex Ray bus. The USBvar i ants VN3600/VN7600 are suit a ble for mo bile ap pli -ca tions, anal y ses and sim ple sim u la tions. The PCI var i -ant VN3300 sup ports com plex sim u la tions of mul ti pleECUs with re al-time re quire ments.

Fig ure 3: Strin gent re quire ments are sat is fied by the re al-timeca pa ble and de ter min is tic CA Noe RT run time plat form.

11 Press Book_Seite_1-50_1-53:Press Report 4 09.02.2010 13:15 Uhr Seite 3

Page 59: Vector Press Book

In the ar ea of Flex Ray net work ing, Vec tor of fers a uni ver sal tool

chain, mod u lar soft ware mod ules as well as in ter face hard ware and

sup port for spe cif ic pro jects and a train ing pro gram. The Stutt gart-

based spe cial ist’s ac tiv i ties as a Pre mi um As so ci ate Mem ber of the

Flex Ray Con sor ti um en sure that ad vanced de vel op ments and the

lat est pro to col spec i fi ca tions are al ways con sid ered in the de sign of

tools and hard ware in ter fa ces.

ECUs that can ex e cute a star tup. Some ECUs are not star tup-ca pa -

ble; they al ways in te grate them selves in the com mu ni ca tion aft er a

suc cess ful ex ter nal star tup. If a net work line on ly has these kinds

of de vi ces for the meas ure ment or sim u la tion, the bus sys tem can -

not be start ed up due to the lack of star tup-ca pa ble nodes. There -

fore, a sec ond com mu ni ca tion con trol ler or star tup con trol ler has

been in te grat ed in all Flex Ray in ter fa ces.

In ter fac ing ded i cat ed Ap pli ca tions with the Hard wareThe new gen er a tion of Flex Ray in ter fa ces from Vec tor of fers high-

per form ance hard ware so lu tions for the most sig nif i cant PC plat -

forms and in ter face types. These in ter fa ces are spe cial ly tai lored to

the re quire ments in sim u la tion, anal y sis, cal i bra tion and test ing

(Fig ure 4). The strengths of the USB var i ants VN3600 and VN7600

lie in the mo bile ar ea. They are ide al ly suit ed to anal y sis and sim ple

sim u la tions, while the VN3300 PCI card is in tend ed for com plex

sim u la tions in volv ing mul ti ple ECUs un der re al-time con straints.

Cur rent ly, Flex Ray bus es are pri ma ri ly used to geth er with ex ist ing

CAN net works. The VN7600 Flex Ray/CAN-USB in ter face ad dress es

this sit u a tion ap pro pri ate ly with two Flex Ray chan nels and three

CAN chan nels in one de vice. De vel op ers of Flex Ray/CAN ap pli ca -

tions ben e fit from si mul ta ne ous ac cess to both bus sys tems in anal -

y ses and sim u la tions with just one hard ware mod ule. The com bined

hard ware so lu tion for Flex Ray and CAN es pe cial ly sim pli fies pre cise

syn chro ni za tion of the dif fer ent bus sys tems with high ly pre cise

time stamps and a com mon time base. In this re gard, a sig nif i cant ly

high er lev el of qual i ty is achieved com pared to mul ti ple sep a rate

so lu tions, since la ten cies must al ways be ex pect ed when USB is

used for in ter fac ing.

A pro gram ming li brary of ba sic func tions is sup plied with the

FlexRay hard ware. This makes it pos si ble for ded i cat ed ap pli ca tions

to ac cess the Vec tor Flex Ray hard ware. The “Ad vanced Flex Ray Driv er

Li brary” is avail a ble for ex tend ed func tions. The de vel op er us es this

li brary to ac cess ex tend ed func tions of the in ter fa ces, such as the

sec ond com mu ni ca tion con trol ler, ex tend ed TX buff er and au to mat -

ic pay load in cre ment.

Sum ma ryFlex Ray pla ces dis pro por tion ate ly great er de mands on hard ware

and soft ware than CAN or LIN net works, for ex am ple, due to its

time-trig gered trans mis sion meth od and con sid er a bly high er trans -

mis sion rates. Here, the tim ing be hav ior of the hard ware has a de ci -

sive in flu ence on the qual i ty of soft ware serv i ces that can be pro -

vid ed. Sig nif i cant per form ance in creas es are re al ized by trans fer -

ring soft ware func tions to the hard ware.

EF FI CIENT AC CESS TO THE FLEX RAY BUS

1/53

Dr. Car sten Böke stud ied In for ma tion Tech nol o gy at the Uni -ver si ty of Pad er born. From 1995 to 2004, hewas em ployed as a sci en tif ic as sist ant at theHeinz Nix dorf In sti tute in the ar ea of Par al lelSys tems De sign. While there he was pri ma ri lyin volved with au to mat ic con fig u ra tion of em -bed ded com mu ni ca tion sys tems. Since 2004he has been em ployed as a Sen ior Soft wareDe vel op ment En gi neer at Vec tor In for ma tikGmbH, where he de vel ops tools for bus anal -y sis and bus sim u la tion of Flex Ray sys tems.

Al fred Klessstud ied Elec tri cal En gi neer ing at the Tech ni -cal Col lege of Es slin gen. From 1991 to 2004,he worked in the ar ea of Test Sys tem De vel -op ment at the com pa ny AL CA TEL. Since2004, he has held the po si tion of Busi nessDe vel op ment Man a ger at Vec tor In for ma tikwhere he is re spon si ble for the prod uct lines“Net work In ter fa ces” and “Meas ure ment andCal i bra tion”.

Mar tin Goßnerstud ied Com put er En gi neer ing at the Tech ni -cal Col lege of Ulm. Since 1998, he has beenem ployed in the “Net work In ter fa ces” ar ea atVec tor In for ma tik GmbH. Since 2000, he hasbeen team lead er for driv er and firm waredevel op ment. As a prod uct man a ger, he isrespon si ble for Vec tor Flex Ray in ter fa ces.

11 Press Book_Seite_1-50_1-53:Press Report 4 09.02.2010 13:15 Uhr Seite 4

Page 60: Vector Press Book

AUTOSAR PDUs

Conquer FlexRayAudi is using FlexRay in their newest vehicles. The developed Flex-

Ray network communication uses PDUs (Protocol Data Units) that

are fully AUTOSAR compatible. PDUs are logical data containers

for exchanging signals between applications and allowing greater

decoupling from the underlying communication system. Audi bene-

fited immediately from Vector’s CANoe as a bus analysis and simu-

lation tool which can natively handle PDUs.

24 lA U T O M O T I V E 2 0 0 8 lS P E C I A L E D I T I O N F L E X R AY

With the release of the frame-oriented FIBEX2.x database format, a new description sem-antic was needed to define PDU communi-

cations between network nodes. To overcome this gap,Audi successfully developed the FIBEX+ descriptionsemantic. Vector was able to immediately supportFIBEX+ in its tools. Profiting from their experienceswith FIBEX+, Audi introduced PDUs into the new FIBEX3.0 standard from ASAM (Association for Standardisa-tion of Automation and Measuring Systems [1]).Continuous feedback from Audi enabled Vector engineersto integrate important PDU features during the early phases

of tool development. Service Packs were delivered regular-ly to Audi, thus, allowing early testing of ECUs with PDUcommunication stacks. Audi delivered their latest FIBEX+database versions to Vector in order to ensure CANoe’s con-tinuous compatibility. Close collaboration between Audi andVector accelerated the tool development and led to a pro-fessional analysis and development platform for FIBEX+ andthe new FIBEX 3.0 based FlexRay networks.This article illustrates the impact PDUs have on the inter-nal structure and features of a FlexRay development toolCANoe.FlexRay and how Audi engineers benefit fromappropriate tool support.

F L E X R A Y T O O L S S U C C E S S F U L L Y S U P P O R TD E V E L O P M E N T S W I T H P D U -B A S E D C O M M U N I C A T I O N S

1/54

12 Press Book_Seite_1-54_1-57.indd 212 Press Book_Seite_1-54_1-57.indd 2 09.02.2010 13:23:50 Uhr09.02.2010 13:23:50 Uhr

Page 61: Vector Press Book

SPECIAL EDIT ION FLEXRAY lA U T O M O T I V E 2 0 0 8 l25

PDU Layer for NetworkAnalysisPDUs are managed by tools for analysis,simulation, and test as high-level com-munication data containers (e.g. messa-ges) containing signals. A FlexRay framecan contain several PDUs. Since the lay-out of a frame can also change from cycleto cycle, the same PDU can be mappedto multiple frames. PDUs are uniquelyidentifiable by their position in a FlexRayframe in a specific slot during a specificcycle. Vector identifies PDUs in CANoevia the PDU Layer (Figure 1). The PDULayer introduces PDU objects and is loca-ted between the bus and the user inter-faces, respectively. The layer is enabledor disabled according to the assignmentof an appropriate database (FIBEX+ orFIBEX 3.0) to CANoe. If the layer is ena-bled, then the complete symbolic databa-se interpretation (PDU names, signals,timings, etc.) of the network communica-tion is performed at PDU level.The PDU’s main property, which is defi-ned by the Update Bit, is decoupled fromthe frame’s occurrence on the network.Thus, frames on the network may containupdated and non-updated PDUs at thesame time. Update Bit values can be visu-alized as pre-defined signals or can beevaluated (e.g. in the graphics window,see Figure 2). As a default for simple ana-lysis or simulation received PDUs, whichhave not been updated, are ignored. For adetailed analysis, however, non-updatedPDUs can optionally be displayed and pas-sed on to the simulated nodes. In addi-tion, FlexRay frames including their pay-load can be displayed and received as so-called Raw Frames. Such PDU-based ana-lysis features were heavily used by Audiduring their integration tests.

PDU Layer for NetworkSimulationAlthough the FlexRay protocol defines frames to be trans-mitted cyclically (even without any update), native PDUsdo not have this property. If a PDU is not updated, the recei-ver will normally not recognize the PDU. In order to triggerthe receiver cyclically, PDUs must be updated periodically.If the automatic transmission of PDUs with the Update Bitset (i.e. without any explicit data update) is required, thenthe network designer can define these PDUs to have cyclictimings. For this reason an Interaction Layer (see Figure 3)on top of the PDU Layer was developed to handle thoseconstraints. As an extension to the FlexRay protocol, PDUsmay also be sent cyclically with (nearly) arbitrary periodswith set Update Bit (without being updated).

Message counters and check sums were defined by Audias additional but optional validity attributes of a PDU. Infact, the Update Bits, message counters, and check sumsof a PDU are set independently from the application inCANoe by the Interaction Layer in order to simplify theremaining bus simulation. Thus, the engineer can concen-trate on setting appropriate signal values. A further usecase is the insertion of explicit failures into the remainingbus simulation in order to test an ECU’s reaction. Therefo-re every automatic feature in CANoe can be disabled andthe Interaction Layer can be used for fault injection.A simulation of communications with an ECU depends onthe occurrence of specific events (event-based simula-

Figure 1: CANoe’s Architecture with Abstraction Layers for Signal and PDU Hand-

ling and Sending Behaviour (IL). © automotive

Figure 2: CANoe’s visualization of PDU’s Update Bits in Graphics and Trace.

© automotive

1/55

12 Press Book_Seite_1-54_1-57.indd 312 Press Book_Seite_1-54_1-57.indd 3 09.02.2010 13:23:51 Uhr09.02.2010 13:23:51 Uhr

Page 62: Vector Press Book

26 lA U T O M O T I V E 2 0 0 8 lS P E C I A L E D I T I O N F L E X R AY

tion). One of the most important events is the reception ofmessages or changes in signal values from the bus. Assuch, notification handlers for PDU reception and signalchanges are triggered by the PDU Layer.

Performance AspectsThe additional (but mandatory) PDU Layer does createsome overhead. When receiving FlexRay frames, PDUshave to be extracted from the frame and then forwardedto their notification handlers in the application. The samePDU can be contained in different frames. Thus, a sort ofde-multiplexing of PDUs from frames is implemented bythe PDU Layer. These procedures are highly optimized.On transmitting PDUs, they must be stored in the appro-priate frame. The PDU can be located in different framesaccording to the current (cycle) time or a different set ofPDUs may be contained in the frame. This results in a high-ly time-dependent multiplexed mapping of PDUs to Flex-Ray frames. If this is not fast enough, then frame slot mis-ses should be expected. For maximum performance, Vec-tor has implemented those functions to run on the hard-ware for the FlexRay bus interfaces of the VN series.

Testing PDU-based NetworksAudi and its Tier1 suppliers also benefited from CANoe’sAUTOSAR features. This includes a check for communi-cation conformance in order to test the AUTOSAR com-munication stacks (especially the PDU Router) of theECUs. Here it is of great importance to be able to compa-re the real bus entities (Raw Frames) with the symbolicinterpretation (PDU abstraction level). This helped the Audiengineers to identify in early phases an incorrect PDU orUpdate Bit position in the raw FlexRay frames.Tests can be split into two categories: First the applicatio-n’s transmission behaviour can be checked with respect toupdated PDUs and secondly, a signal’s integrity can be veri-fied according to the application. Audi‘s engineers havesuccessfully detected incorrect PDU update timings inearly development phases. These tests are fully supported

in CANoe’s Test Feature Set for PDUs. Additionally, for sti-mulus and response observations, PDUs can be sent inter-actively (PDU Panel) by implicitly manipulating signals(Input Panels), higher level protocols (transport, diagno-stics), or by a remaining bus simulation (CAPL, MATLABmodels, etc.).

ConclusionPDU-based communications will not only be used in migra-tion scenarios, e.g. when porting applications from CAN toFlexRay networks, but also for new FlexRay develop-ments. Audi has strongly influenced the development ofFIBEX 3.0 based on lessons learned with FIBEX+. Vecto-r’s experience with FIBEX+ allowed the quick support ofthe new FIBEX 3.0 standard with CANoe. As communica-tions become more complex and extensive, appropriatemodelling standards (i.e. FIBEX 3.0 and/or AUTOSAR), aswell as their professional tool support, are essential requi-rements for an efficient FlexRay development.

Literature:

[1] www.asam.org

Dipl.-Ing. (FH) Wolfgang Brandstätter

is Hardware and Protocol Engineer for FlexRay; AUDI AG, 85045 Ingolstadt, Germany

Dr. rer. nat. Carsten Böke is Senior SoftwareDevelopment Engineer for the “Tools for Net-works and Distributed Systems” product line;Vector Informatik GmbH, 70499 Stuttgart,Germany

Figure 3: The Interaction Layer (IL) of CANoe controls the sending behaviour of PDUs with set Update Bit inclusively

their extended validity attributes (message counter, user CRC).

© automotive

© Carl Hanser Verlag, München 2009. All rights including reprinting, photographic reproduction and translation reserved by the publishers.

1/56

12 Press Book_Seite_1-54_1-57.indd 412 Press Book_Seite_1-54_1-57.indd 4 09.02.2010 13:23:51 Uhr09.02.2010 13:23:51 Uhr

Page 63: Vector Press Book

1/57

12 Press Book_Seite_1-54_1-57.indd 512 Press Book_Seite_1-54_1-57.indd 5 09.02.2010 13:23:52 Uhr09.02.2010 13:23:52 Uhr

Page 64: Vector Press Book

These requirements are fulfilled by FlexRaydevelopment tools quickly and extensively,sometimes in completely new ways. This

article discusses the requirements that need to bemet for an effective development platform. Itaddresses special requirements of the FlexRay busfor remaining bus simulations, higher-level proto-cols, diagnostics, highly specialized tests andAUTOSAR development methodology.

Quick and reliable simulation of ECUsIn the development process of an ECU, it is essentialto be able to operate the ECU before it is integrated inthe total system. The other ECUs of the FlexRay net-work must therefore be simulated as communicationpartners. This is referred to as a remaining bus simu-lation. The strict time requirements associated withFlexRay are very difficult to maintain; often simula-tions on the FlexRay bus are non-deterministic in theirexecution. The resulting slot misses result in over-sampling or undersampling of data on the bus. There-fore, it is often urgently recommended that thesesimulations be executed on a dedicated, jitter-free anddeterministic (real-time capable) platform. Availablesolutions include expensive HiL systems and difficult

Figure 1: CANoe RT is used to simulate

or test ECUs in real time. © automotive

Beyond FlexRay

The FlexRay communication bus and the FIBEX database exchange format

represent the current state-of-the-art of in-vehicle networking. In this

context, the FlexRay bus must fulfi l requirements related to remaining bus

simulation, diagnostics and higher protocols, testing and AUTOSAR deve-

lopment methodology, over the entire development process.

R E Q U I R E M E N T S O N A M O D E R ND E V E L O P M E N T E N V I R O N M E N T

22 lA U T O M O T I V E 2 0 0 9 lSPECIAL EDIT ION FLEXRAY

1/58

13 Press Book_Seite_1-58_1-61.indd 213 Press Book_Seite_1-58_1-61.indd 2 09.02.2010 13:24:05 Uhr09.02.2010 13:24:05 Uhr

Page 65: Vector Press Book

to implement rapid prototypingplatforms. Nevertheless, thereis an effective and cost-savingsolution specifically designedfor remaining bus simulations intesting: execution of the simula-tion on the hardware interfacesof the bus simulation or analysistools being used. For example,in the case of CANoe RT (figure

1), available on the high-endinterface VN89xx (mid 2010),the user can run a simulation ofthe total system in real-time, orhe uses a FlexRay interfacefrom Vector to execute thesimulation for one ECU. Thesesolutions are seamlessly inte-grated in the simulation and testtool CANoe. This means thatdevelopers can always use thesame platform and the samecode, regardless of whetherthey are implementing a puresimulation or remaining bussimulation, or whether they aretesting real ECUs on the bus. The tools and platforms offer additional functions for aremaining bus simulation as well. For example, the sendbehavior of ECUs is automatically modified (InteractionLayer) based on global system states (e.g. ignition on/off).Alive counters are incremented and supplemental check-sums are already computed autonomously. This allows de-velopers to focus fully on development or testing of theapplications of their ECUs. Naturally, in the case of testing itis also possible to inject errors on the communication level.

Protocols on higher layersECUs not only exchange signals such as vehicle speed andoil temperature, they also communicate via protocols onhigher layers of the ISO OSI model – such as transport pro-tocols, network management protocols, in flashing or cali-brating. During normal operation of the ECU, such proto-cols are needed to coordinate bus communication. In ser-vice phases, the protocols are used to evaluate or updatethe ECUs. The ECUs of a specific OEM each have their owncharacteristics, e.g. of a transport protocol including OEM-specific modifications. Modern development tools mustnot only be able to analyze or represent the basic data onthe FlexRay bus based on the FIBEX description but alsoevaluate the mentioned protocols and transmitting infor-mation through them. These functionalities are provided inthe form of add-ons or plug-ins (figure 2). A modern modular approach to development tools enablesre-use of plug-ins in different tools and seamless integra-tion in the tool itself. Ideally, extensions are integrated as ifthey were a native component of the tool. Protocol exten-sions provide special dialogs for setting and querying para-meters of the protocols. The functions of plug-ins can be

used in dedicated programs or scripts via internal interfa-ces. This allows developers to influence and have anaccess to communications by program control.

Testing by diagnosticsAccess to an ECU’s diagnostic functionality is very impor-tant, especially in early phases of the development pro-cess, e.g. for reading out fault memory or for flashing. Sincediagnostics normally access an ECU via a CAN bus, a CAN-FlexRay gateway is needed for a FlexRay ECU. However,such a gateway is generally unavailable in early develop-ment phases. That is why CANoe’s Diagnostic Feature Setand the measurement and calibration tool CAN-ape supportdirect access to the diagnostic data over the FlexRay bus(figure 3). Special transport protocols for FlexRay (AUTO-SAR, ISO and OEM-specific variants) are supported in thiscontext. After loading the diagnostic description databases in CAN-dela or ODX format, diagnostic dialogs and functions areavailable in CANoe and CANape. For example, this allowsreading out the fault memory and displaying it includingsymbolic interpretation of the trouble codes. In addition,the diagnostics console is used to symbolically send andevaluate all diagnostic requests, including their responsesand parameters. Diagnostics communication is displayedin its domain-specific notation in traces. A dedicated dia-gnostics-API is also available, which enables easy accessin programming, testing and tool control.

A simpler way to create ECU testsFrequently used standard tests often run according to thesame scheme. Therefore, a test tool should support fre-

SPECIAL EDIT ION FLEXRAY lA U T O M O T I V E 2 0 0 9 l23

Figure 2: A powerful module concept is available for CANoe.FlexRay that lets

users integrate additional protocols as well as application-specific and communi-

cative control of simulation behavior. © automotive

1/59

13 Press Book_Seite_1-58_1-61.indd 313 Press Book_Seite_1-58_1-61.indd 3 09.02.2010 13:24:06 Uhr09.02.2010 13:24:06 Uhr

Page 66: Vector Press Book

24 lA U T O M O T I V E 2 0 0 9 lSPECIAL EDIT ION FLEXRAY

quently recurring test patterns. For CANoe, it is very easyto create sequential tests and test steps using the TestAutomation Editor. Prepared or user-specific libraries arelinked for this purpose; they allow the test engineer to simply select and parameterize the test cases. Optionally,complicated or high-effort tests can be specified algorith-mically. This makes it possible to execute loops or bran-ching based on the results of prior tests. Static and algo-rithmic tests may be combined. Along with stimulation tests, the bus communication cansimultaneously be monitored regarding the FlexRay proto-col. This includes detection of null frames and erroneousframes as well as monitoring of the frame period, re-sponse time behavior etc. Monitoring activities are per-formed by so-called observational checks, which are alrea-dy contained in CANoe and only need to be activated andparameterized before use. For Hardware-in-the-Loop or environment simulations, it isfrequently necessary to connect the ECU to its real sensorsand actuators. The digital and analogue input and outputvariables must be provided or read-in. The “VT System” byVector was developed for this purpose and for open-loopsimulations and tests. It provides automotive-capable I/Oports that can be integrated easily in tests. Unlike generaldigital or analog I/O cards, the system can selectivelyswitch between connection of an original load or originalsensor or else a suitable simulation of the input or output.At the same time, large voltage ranges and currents can behandled by suitable signal conditioning. This also makes itpossible to simulate faulty behavior of a sensor or actuatoror a short circuit.

Testing AUTOSAR-functionality in FlexRay systemsIn the AUTOSAR design methodology, communication asa basic service for the application is transparent. In the framework of the overall system, communication is de-fined in the “AUTOSAR System Description”. If an AUTO-SAR-ECU needs to be tested simply and quickly, the testtool has to know the communication description for theECU. It is more user-friendly to directly read in the “AUTO-SAR System Description” rather than the FIBEX databa-ses. This will be supported by CANoe.FlexRay. Key concepts in the AUTOSAR context are: “SoftwareComponents” (SWCs), “Runtime Environment” (RTE) and“Virtual Functional Bus” (VFB). Even if the ECU does notphysically exist yet, it must still be possible to test its “Soft-ware Components”. For this purpose, the “DaVinci Com-ponent Tester“ is able to integrate the real ECUs code of aSWC in the test environment. CANoe provides the RTE,VFB and basic software. The test is executed with the well-known functions of CANoe, including the automatic crea-tion of a test report.

OutlookIn future, the number of AUTOSAR ECUs and the numberof included SWCs will grow rapidly. These complex

systems require a powerful analyzing capability to test theinternal communication between the SWCs. Therefore,the test tool needs access to the communication on theVFB. This is usually done via XCP-on-FlexRay. But especially extensive testing needs a higher perfor-mance. Therefore, the coupling of the control unit with thetest environment CANoe is done via a JTAG or Nexusdebug port. Only in this way parameters of the VFB, RTEor basic software (BSW) of a real AUTOSAR ECU can beread-in and calibrated quickly. This will be done by connec-ting the VFB of the real ECU to the test environmentCANoe. Thus, the testing and analyzing at the ECU-internalinterfaces of the SWCs can be done quite similarly in futu-re, as today at the external control connections of an ECU. If the requirements described are realized in a sophistica-ted way in the development tools and in the implementa-tion of FlexRay systems, FlexRay networks can be de-veloped more efficiently than CAN networks.

Dr. rer. nat. Carsten Böke is Senior SoftwareDevelopment Engineer for the Tools for Net-works and Distributed Systems product lineat Vector Informatik GmbH.

Vector Informatik GmbHwww.vector.com@@

Figure 3: CANoe.FlexRay directly accesses the ECU’s diagnostic

functions over the FlexRay bus. © automotive

© Carl Hanser Verlag, München 2009. All rights including reprinting, photographic reproduction and translation reserved by the publishers.

1/60

13 Press Book_Seite_1-58_1-61.indd 413 Press Book_Seite_1-58_1-61.indd 4 09.02.2010 13:24:06 Uhr09.02.2010 13:24:06 Uhr

Page 67: Vector Press Book

1/61

13 Press Book_Seite_1-58_1-61.indd 513 Press Book_Seite_1-58_1-61.indd 5 09.02.2010 13:24:07 Uhr09.02.2010 13:24:07 Uhr

Page 68: Vector Press Book

1/62

Se ri al Bus Sys tems in the Au to mo bile

Elec tron ics is re spon si ble for a large num ber of in no va tive safe ty

and con ve nience func tions in au to mo tive tech nol o gy. Ex perts pre -

dict that in just a few years elec tron ics will rep re sent a share of up

to 30 per cent of ve hi cle val ue, and the world wide mar ket for elec -

tron ics in cars will grow by ap prox. 6 per cent an nu al ly to 230 bil lion

eu ros by the year 2015. The au to mo tive in dus try is fore cast to ex -

hib it rap id growth rates, above all in the in fo tain ment ar ea, giv en

the con tin u al ly in creas ing ve hi cle-kil o me ters on Ger ma ny’s roads

(ac cord ing to DIW [1] ap prox. 700 bil lion). The av er age cit i zen

spends about 270 hours in a car an nu al ly, wheth er it is on the way

to work, shop ping or va ca tion.

Over the course of time, the car ra dio was sup ple ment ed by the CD

and MP3 play er. This came to in clude CD chan gers and nav i ga tion

de vi ces, and fi nal ly dis play screens al so made their way in to cars

for re play ing DVD and vid eo films. More over, hands-free Blu e tooth

units with in te grat ed mi cro phones and iP od con trol are grad u al ly

turn ing the cock pit a mul ti me dia cen ter, in which all of the play

lists and di rect o ries of a dig i tal MP3 play er can be dis played and

start ed di rect ly on the in-ve hi cle dis play.

The al ready ex ten sive wir ing cost and ef fort are in creas ing due to

con tin u al growth in net work ing of con tin u al ly high er per form ance

in fo tain ment de vi ces of di men sions that can hard ly be man aged

any longer. For tu nate ly, some au to mo tive OEMs recog nized the ad -

van ta ges that bus net work ing would al so of fer in this ar ea ear ly on.

In the mid-1990s, BMW and Daim ler be gan to de vel op a uni form

com mu ni ca tion tech nol o gy for se ri al trans mis sion of au dio and

video sig nals in the ve hi cle based on the D2B bus (Dig i tal Da ta Bus)

de vel oped by Mat sush i ta and Phil ips.

MOST Co op er a tionIn 1998, BMW, Daim ler, Har man/Beck er and SMSC (for mer ly OA SIS

Sil i con Sys tems) found ed the MOST Co op er a tion [2]. Since that time,

MOST has es tab lished it self as a de-fac to stand ard for the trans mis -

sion of mul ti me dia da ta in the ve hi cle – the MOST Co op er a tion is

made up of 15 in ter na tion al au to mo tive OEMs and more than 70 de -

vice pro duc ers. The us er or gan i za tion laid the foun da tion for suc cess

of the tech nol o gy by de fin ing an ex ten sive spec i fi ca tion. Ver sion 2.5

of the MOST spec i fi ca tion has been in ex is tence since Oc to ber 2006.

It is or ga nized in to the ar e as of Ap pli ca tion, Net work and Hard ware.

Fig ure 1: Struc ture of a MOST de vice thatamong oth er things hosts the “Au dio Disk Play er” func tion alblock. For sys tem man age ment, the Net Block is man da to ry for each MOST de vice, and sys tem func tions are man da to ry for each func tion block.

A pre mi um class car is grow ing to re sem ble a mo bile of fice. In re sponse to cus tom er de mand, in creas ing num bers of en ter -tain ment and in for ma tion me dia that are mak ing their way in toau to mo biles. The most sig nif i cant chal len ges in this ar ea are,first, to keep wir ing ex pense as low as pos si ble, and sec ond, toful ly sat is fy the height en ed func tion al re quire ments of an in fo -tain ment sys tem in the car. As a re sult, the MOST (Me dia Ori ent edSys tem Trans port) bus sys tem is now used to trans mit au dio andvid eo sig nals in ap prox. 50 mod el se ries.

MOST for trans mis sion of mul ti me dia da taPart 5:

14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 1

Page 69: Vector Press Book

1/63

com mands are used for con trol com mu ni ca tion. Their core com po -

nents are the FBlock ID, FktID, Op er a tion Type and up to 65535 use ful

bytes.

Sys tem man age mentThe Ap pli ca tion sec tion de fines high er-lev el func tion blocks and

func tions for sys tem man age ment. Sys tem func tions in clude the

“FktIDs” func tion (FktID=0x000) that is used to que ry the func tions

sup port ed by a func tion block, for ex am ple. The “No ti fi ca tion” sys -

tem func tion (FktID=0x001), on the oth er hand, en a bles cre a tion of

the “no ti fi ca tion ma trix” for a func tion block. Emerg ing from the

“no ti fi ca tion ma trix” is in for ma tion on which MOST de vice should

be no ti fied if a cer tain prop er ty of a func tion block has changed.

This mech a nism pre vents an un nec es sary in crease in bus load in the

MOST sys tem.

To que ry its func tion blocks and ad dress es, each MOST de vice has

the “Net Block” (sys tem) func tion block with FBlock ID=0x01. The

func tion blocks can learn about the func tion blocks im ple ment ed

on a MOST de vice us ing the FBlock IDs func tion (FktID=0x000). The

FktIDs 0x002, 0x003 and 0x004 are used to find the phys i cal ad -

dress, log i cal ad dress and group ad dress of a MOST de vice.

The Net work Mas ter plays an im por tant role in the man age ment of a

MOST sys tem. It is re spon si ble for the sys tem start and man age -

ment of the “Cen tral Reg is try”. This reg is try con tains the log i cal

ad dress es of the MOST de vi ces im ple ment ed in a MOST sys tem and

the ad dress es of func tion blocks con tained in the MOST de vi ces.

The “Ap pli ca tion” ar ea de scribes a log i cal de vice mod el based pri -

ma ri ly on ob ject-ori ent ed meth ods, with the pur pose of trans par -

ent mod el ing and con trol of dis trib ut ed in fo tain ment sys tems. Fur -

ther more, it de fines a hi er arch i cal com mu ni ca tion mod el as well as

serv i ces for man a ging an in fo tain ment sys tem. The “Net work sec -

tion” de scribes the MOST Net work In ter face Con trol ler and its serv -

ices, net work man age ment, and han dling of da ta trans port in a

MOST sys tem. The “Hard ware sec tion” deals with as pects of the

hard ware struc ture of a MOST de vice.

Func tion al mod el ingA MOST de vice is sub di vid ed in to a func tion al lev el and a net work

lev el (MOST Net work In ter face). On the func tion al lev el, in fo tain -

ment func tion al i ties are em bod ied in so-called func tion blocks.

Each func tion block, e.g. the Au dio Disk Play er, pro vides the MOST

net work with a ded i cat ed set of func tions, e.g. “Track po si tion”,

that can be ac cessed by op er a tion types such as “Set” for set ting a

track or “Set Get” for set ting and read ing a track (Fig ure 1).

Func tion al ad dress es (FBlock ID, FktID) are as signed to both the

func tion blocks and to the func tions pro vid ed by a func tion block.

They can be tak en from the so-called “Func tion Cat a log”, as can the

iden ti fi ers of the op er a tion types. For ex am ple, the “Au dio Disk

Play er” FBlock has FBlock ID=0x31 and the “Track Po si tion” func tion

has FktID=0x202.

The sep a ra tion of func tion and net work and func tion al mod el ing

make it pos si ble to im ple ment a func tion al com mu ni ca tion mod el

that is ful ly in de pend ent of phys i cal com po nents (MOST de vi ces).

There fore, it does not mat ter which of the MOST de vi ces is used to

con tain a spe cif ic func tion.

Hi er arch i cal com mu ni ca tion mod elMOST sys tems are pat terned on a three-stage hi er arch i cal con trol

phi los o phy based on the “Mas ter-Slave prin ci ple” (Fig ure 2). Placed

at the up per most hi er arch i cal lev el is the HMI (Hu man Ma chine

Inter face), an ex posed con trol ler that pro vides the us er with over -

all func tion al i ty. On the mid dle hi er arch i cal lev el are the usu al con -

trol lers. They cov er part of the sys tem func tion al i ty, and they share

their par tial sys tem knowl edge with the HMI as the “Sys tem Mas ter”.

The low er most hi er arch i cal lev el is made up of the sys tem slaves,

whose func tions are used by one or more con trol lers. They are not

equipped with any sys tem knowl edge, and this sub stan tial ly en -

hances their flex i bil i ty with re gard to con fig u ra tion. It is easy to

add sys tem slaves or re move them from a MOST sys tem. MOST

Fig ure 2: Hi er archy of a MOST sys tem

14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 2

Page 70: Vector Press Book

1/64

MOST Net work In ter faceThe MOST Net work In ter face (Fig ure 3) en sures that the func tion

blocks housed on the var i ous MOST de vi ces are ca pa ble of re al com -

mu ni ca tion with one an oth er. The MOST Sys tem Serv i ces (Low Lev el

Sys tem and MOST Net work Serv i ces) pro vide the com mu ni ca tion

func tion al i ties need ed to trans port all mul ti me dia rel e vant da ta

(time-con tin u ous bit streams, pack et da ta and con trol da ta). Low

Lev el Sys tem Serv i ces (Lay er 2 serv i ces) are im ple ment ed in hard -

ware (Net work In ter face Con trol ler – NIC) and are placed over the

Phys i cal Lay er.

MOST Net work Serv i ces, which en com pass the Trans port Lay er in

the form of Ba sic Lay er Sys tem Serv i ces and high er man age ment in

the form of an ap pli ca tion sock et, are housed on an ex ter nal Host

Con trol ler (EHC) and con trol the NIC. It must be en sured that the

EHC can serve the time-crit i cal parts of the Net work In ter face. Over

time, with the pro gres sive de vel op ment of MOST tech nol o gy from

MOST 25 to MOST 50 and MOST 150, this ar chi tec ture has now en -

coun tered its lim its.

In new de vel op ments, IN IC (In tel li gent Net work In ter face Con trol -

ler) re pla ces NIC. While IN IC as sumes con trol of ex e cu tion of time-

crit i cal por tions of the net work driv er of the EHC, just a rel a tive ly

small part of the net work driv er still runs on the EHC, which es sen -

tial ly rep re sents a sock et for the ap pli ca tion. The IN IC ar chi tec ture

there by re lieves the load of the EHC. For con trol, the IN IC pro vides

the EHC or MOST API (MOST Net work Serv i ces) with a func tion al in -

ter face, the so-called IN IC-API. The func tions of the IN IC are en cap -

su lat ed in a func tion block (FBlock IN IC).

MOST Net work ingMOST tech nol o gy en a bles trans mis sion of con tin u ous bit streams

(bit stream ing) with out buff er ing or un nec es sary over head. This in -

volves hav ing a spe cial ly des ig nat ed MOST de vice (Tim ing Mas ter)

feed the MOST frame (Fig ure 4) at a fixed fre quen cy (44.1 KHz or 48

KHz) in to the trans mis sion me di um, which is typ i cal ly op ti cal.

In a MOST25 sys tem, the MOST frame pro vides 60 stream ing chan -

nels at 8 bits (or 15 quad lets of 4 bytes each) for trans mis sion of

con tin u ous bit streams (source da ta ar ea). The band width of a stre-

am ing chan nel yields ei ther 352.8 KBit/s (44.1 KHz) or 384 KBit/s

(48 KHz).

Since the MOST de vi ces are phys i cal ly in ter con nect ed in to a ring,

each MOST frame must pass through ev ery MOST de vice at the fre -

quen cy pre scribed by the Tim ing Mas ter. As soon as the rel e vant

com mu ni ca tion part ners (da ta source and sink) have con nect ed to

the same stream ing chan nel, bit stream ing be gins (Fig ure 5).

Con nec tion or dis con nec tion is usu al ly made by a que ry by the func -

tion block “Con nec tion Mas ter – CM” (Fblock ID=0x03). For this pur -

pose, the CM pro vides the two func tions “Build Sync Con nec tion”

and “Re mov e Sync Con nec tion”.

In the frame work of build ing a con nec tion, the CM re quests that the

rel e vant da ta source, e.g. the TV tun er, have the suit a ble num ber of

stream ing chan nels al lo cat ed by the Tim ing Mas ter. That is be cause

the Tim ing Mas ter is re spon si ble for man age ment of the “chan nel

re source al lo ca tion ta ble”. The CM pass es the ad dress es of the al lo -

cat ed stream ing chan nels to the da ta sink, e.g. to the dis play, so

that it can con nect to the stream ing chan nels. Fi nal ly, the CM up -

dates the “sync con nec tion ta ble”, which it us es to man age all syn -

chro nous con nec tions. Dis con nec tion is per formed ac cord ing to the

same scheme.

To en a ble trans mis sion of da ta pack ets, the us er has the op tion of

re duc ing the num ber of stream ing chan nels by up to 24 (six quad -

lets) us ing the “Bound a ry De scrip tor”. All those stream ing chan -

nels that are not re served for bit stream ing, are com bined to form

the pack et chan nel. While a max i mum trans mis sion rate of up to

12.7 MBit/s is pos si ble at a fre quen cy of 44.1 KHz, a max i mum rate

Fig ure 3: Dif fer ence be tween NIC and IN IC ar chi tec tures in aMOST de vice

14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 3

Page 71: Vector Press Book

1/65

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

Fi nal ly, the MOST sys tem must trans mit the MOST com mands need -

ed for man age ment and con trol. Con trol mes sa ges (Fig ure 6) are

used here, which are trans mit ted on the con trol chan nel (2 bytes).

There fore, 16 MOST frames (MOST block) are re quired to trans mit a

con trol mes sage. The band width at 44.1 KHz is 705.6 KBit/s, and at

48 KHz it is 768 KBit/s. Trans mis sion of con trol mes sa ges is al so

based on a Lay er 2 pro to col. Bus ac cess is im ple ment ed by the CSMA

meth od (Car ri er Sense Mul ti ple Ac cess).

of up to 13.8 MBit/s is at tained at 48 KHz. The bound a ry de scrip tor

is man aged by the Net work Mas ter func tion block (FBlock ID=0x02).

It can be set via the “Bound a ry” func tion (FktId=0xA03).

A Lay er 2 pro to col is used to trans mit da ta pack ets. The frame com -

pris es the ar bi tra tion field, source and tar get ad dress, da ta length

code, da ta field (ei ther 48 or 1014 byte) and da ta pro tec tion. A

token cir cu lat ing in the ring reg u lates bus ac cess. The MOST de vice

that takes the to ken from the ring may ac cess the pack et chan nel.

Fig ure 4: Lay out of the MOST frame: Sent inad min is tra tive byte 0 are syn chro -ni za tion in for ma tion and thebound a ry de scrip tor, and in ad min -is tra tive byte 63 the sta tus bits anda par i ty bit for pro tec tion of theMOST frame.

Fig ure 5: Prin ci ple of bit stream ing: The Tim ing Mas ter trans mits MOST frames at a fre quen cy of 48 KHz. 40 stream ing chan nels (10 quad lets)are avail a ble for al lo ca tion, each op er at ing at 384 KBit/s (bound a ryde scrip tor = 0xA). The pack et chan nel (20 bytes) pro vides a band -width of 7.68 MBit/s for the trans -mis sion of da ta pack ets.

14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 4

Page 72: Vector Press Book

1/66

Phys i cal Lay erTo day, op ti cal con duct ors of pol y mer fi bers (POF – pol y mer op ti cal

fi ber) are the state-of-the-art tech nol o gy for trans mit ting au dio

and vid eo sig nals in the MOST sys tem (Fig ure 7). Over all, the tech -

ni cal prop er ties of pol y mer fi bers are far su pe ri or to those of elec -

tri cal trans mis sion me dia. Es pe cial ly note wor thy are its ex cel lent

elec tro mag net ic im mu ni ty and rel a tive ly high sig nal trans mis sion

rate of up to 500 MBit/s. Fur ther more, the com bi na tion of POF, a

red light-emit ting di ode as the light source (wave length 650 nm)

and a sil i con PIN pho to di ode as the re ceiv er rep re sents a very eco -

nom i cal and com par a tive ly sim ple and man age a ble form of op ti cal

sig nal trans mis sion.

MOST 150, which fol lows MOST 50, is a MOST sys tem that is cur rent

ready to start. It is based on this send er and re ceiv er tech nol o gy

and of fers the us er a trans mis sion rate of 150 MBit/s. It can there -

fore han dle the rel a tive ly short paths in the car of up to 20 me ters

can with out any prob lems.

De vel op ment, test ing and anal y sis of MOST sys temsVec tor In for ma tik GmbH has been an as so ci ate mem ber of the MOST

Co op er a tion since 1999. Be sides its ex ten sive ac tiv i ties in the ar ea

of se ri al bus sys tems such as CAN, Flex Ray and LIN, the Stutt gart-

based net work ing spe cial ist has been sup port ing the de vel op ment

and anal y sis of in fo tain ment so lu tions in the au to mo bile since the

year 2000. It of fers a com pre hen sive prod uct line up of anal y sis, de -

vel op ment and test tools for ap pli ca tions such as high-end au dio

sys tems, mul ti me dia stream ing, tel e phone and nav i ga tion. Hard -

ware in ter fa ces for bus ac cess, a mul ti bus da ta log ger as well as

train ing cours es and en gi neer ing and de vel op ment serv i ces round

out its of fer ing [3]. The Vec tor Acad e my [4] sup plies the nec es sa ry

ba sic knowl edge re lat ed to ECU com mu ni ca tion in the au to mo bile

in the frame work of sem i nars on CAN, LIN, Flex Ray and MOST.

Fig ure 6: Con trol mes sage. A MOST block isre quired to trans mit a con trol mes -sage. The con trol mes sage is com -posed of: ar bi tra tion (a), tar getad dress (b), source ad dress (c),mes sage type (d), da ta field (e),da ta pro tec tion (f), ac knowl edg -ment (g), and res er va tion (h).

14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 5

Page 73: Vector Press Book

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

1/67

Fig ure 7: Back ground knowl edge on op ti cal sig nal trans mis sion in a MOST sys tem

Eu gen May er(Graduate engineer; technical teaching certificate); after vocational training as acommunication electronics technician, hestudied electrical engineering and technicaleducation at the Technical College of Ravens-burg/Weingarten and the University of Stuttgart. Since 1999 he has been employedat Vector Informatik where he works as aSenior Trainer.

tran si tion from the op ti cal ly denser to the op ti cal ly less

dense me di um, the beam is re fract ed away from the pri ma -

ry ax is. The an gle of re frac tion a can be cal cu lat ed if the

so-called in di ces of re frac tion n of the two me dia are kno-

wn (Snel li us Law). If the light beam ex ceeds an in ci dence

an gle a0 in the tran si tion from the op ti cal ly denser me di -

um to the op ti cal ly less dense me di um, then to tal re flec -

tion oc curs.

This prop er ty makes it pos si ble to trans port light in an op -

ti cal con duct or. In the MOST sys tem, pol y mer fi bers are

usu al ly im ple ment ed for op ti cal sig nal trans mis sion, where

a core of PMMA (pol ym eth yl meth a cryl ate) is en cased in a

thin sheath of flu or i nat ed acryl ate. PMMA has a larg er re -

fract ive in dex than the flu or i nat ed pol y mer. If the an gle of

the in ci dent light beam is great er than the lim it an gle,

then the light is con duct ed in the core due to to tal re flec tion.

The small est at ten u a tions for trans mis sion of light in a

so-called step-in dex PMMA fi ber are ob tained at 520 nm

(green), 560 nm (yel low) and 650 nm (red). Red LEDs are

gen er al ly used (at ten u a tion 0.14 dB/m), since they are

very in ex pen sive.

When a light beam pass es from one trans par ent me di um to an oth -

er, it is re fract ed. The great er the an gle of in ci dence, the great er

the re frac tion. The me di um in which the light beam forms a small er

an gle with the pri ma ry ax is is the op ti cal ly denser me di um. In the

Back ground knowl edge on sig nal trans mis sion in a MOST sys tem via POF

Lit er a ture and links:[1] www.diw.de[2] www.most co op er a tion.com[3] www.vec tor-group.net/most/en[4] www.vec tor-acad e my.com

14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 6

Page 74: Vector Press Book

Ef fi cient Test ing in Au to mo tive Elec tron ics

1 In tro duc tionOver the past ten years, the sta tus of au to mo tive elec tron ics has

changed fun da men tal ly. At the be gin ning, just a few ECUs were

used in the au to mo bile but now more than 60 ECUs are be ing

in stalled in some lux u ry class cars. Ad di tion al elec tron ic sys tems

offer im prove ments in the ar e as of safe ty, con ve nience and en er gy-

sav ing op er a tion. To day, more in no va tions are based on elec tron -

ics, and in creas ing ly, a large share of this func tion al i ty is based up -

on soft ware.

Grow ing com plex i ty has made ex ten sive and ef fect ive tests more

im por tant than ev er be fore. The wide spread use of nu mer ous elec -

tron ic com po nents has caused the num ber of po ten tial er ror sour -

ces to rise dis pro por tion ate ly. Tests are in dis pen sa ble in all phas es

of ECU de vel op ment to de tect and cor rect er rors ear ly, keep ing

costs as low as pos si ble. Some weak ness es of a to tal sys tem do not

man i fest them selves un til com po nents are in te grat ed un der ac tu al

and re al-time con di tions. This has turned test ing in to a cross-

de part men tal and cross-man u fac tur er dis ci pline.

The enor mous elec tron ic prob lems that oc curred in in i tial years

have shown what hap pens when these facts are not con sid ered and

sys tem at ic tests are ne glect ed. The lat er that prob lems are iden ti -

fied in the de vel op ment proc ess, the more se ri ous im pact there is

to the in crease in cost. This be comes clear in an ex treme way when

cor rec tion of er rors leads to cost ly re call ac tions aft er prod uct has

been shipped. Par tic i pants in the au to mo tive in dus try have learned

their les sons and now at tach great im por tance to the top ic, but it is

pos si ble to fur ther in crease ef fi cien cy by con sist ent ap pli ca tion of

avail a ble re sour ces.

Costs for tests rep re sent a con sid er a ble share of a project budg et,

but prop er func tion al i ty of the ECU must be as sured. There fore, it is

im por tant to achieve a max i mum of test qual i ty and test depth with

trans par ent con cepts, e.g. by re plac ing in suf fi cient ly au to mat ed

test steps by mod ern meth ods and tools.

2 Tool for anal y sis, sim u la tion and test ingThe net work ing of ECUs rep re sents the back bone of mo tor ve hi cle

elec tron ics. In this con text, the meth od of re main ing bus sim u la -

tion pro vides an im por tant foun da tion in per form ing ECU tests.

With out at least a ru di men ta ry sim u la tion of the ECU en vi ron ment,

most ECUs can not be put in to op er a tion mean ing ful ly. For ex am ple,

many ECUs on ly op er ate prop er ly if they serve net work man age -

ment func tions.

CA Noe from Vec tor In for ma tik is a wide ly used tool for an a lyz ing,

sim u lat ing and test ing dis trib ut ed, em bed ded sys tems (Fig ure 1).

It is used wide ly for re main ing bus sim u la tion and sup ports all

im por tant bus sys tems – in par tic u lar CAN, LIN, MOST and Flex Ray –

for which Vec tor In for ma tik al so sup plies suit a ble PC in ter fa ces.

Com mer cial ly avail a ble in ter face cards can be used to ad dress the

I/O lines of ECUs from CA Noe. More over, Vec tor has an nounced

an I/O hard ware prod uct that sup ple ments these gen er al ca pa bil i -

ties with test-spe cif ic func tions such as switch ing ad di tion al loads

and short cir cuits di rect ly to the ECU ter mi nals.

2/0

Test ing cer tain ly plays an im por tant rolein the au to mo tive elec tron ics de vel op -ment proc ess to day, but there is un ex -ploit ed po ten tial for more ef fi cient andau to mat ed test ing ex e cu tion in the fu ture by util iz ing the right strat e gies,ideas and tools. This ar ti cle an a ly zes the cur rent state of the tech nol o gy, clar -i fies prob lem at ic in ter ac tions oc cur ringin prac tice, and dem on strates that toolsare al ready avail a ble to day for solv ingcon crete project tasks re lat ed to test ingin an el e gant and ef fi cient way.

One test en vi ron ment from HIL sim u la tion to di ag nos tics

15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 1

Page 75: Vector Press Book

The var i ous anal y sis ca pa bil i ties, sim u la tion com po nents, and test

se quen ces re ly on mod els in te grat ed in the tool in the form of da ta -

bas es. These might be the com mu ni ca tion ma tri ces in DBC for mat

for CAN, FI BEX for Flex Ray, XML func tion cat a logs for MOST or LDF

files for LIN. Sim i lar ly, CDD and ODX de scrip tions may be used to

de scribe the di ag nos tic ca pa bil i ties of an ECU. Be sides con tain ing

es sen tial in for ma tion on the sys tem, test de scrip tions al so con tain

sym bol ic names for sig nals, mes sa ges, di ag nos tic serv i ces, etc. This

sim pli fies the work of the test us er and test de vel op er and cre ates an

ab strac tion lay er be tween the test and com mu ni ca tion de scrip tion.

Any sim ple work sta tion PC run ning un der Win dows can be used to

run CA Noe. More pow er ful test sta tions with im proved re al-time ca -

pa bil i ties can be set up in a re al-time con fig u ra tion. This is done by

ex e cut ing the re main ing bus sim u la tion and the ac tu al test

ex e cu tion on a ded i cat ed com put er run ning un der a re al-time

op er at ing sys tem (Win dows CE), while a sep a rate PC is used as the

graph i cal us er in ter face and for eval u a tion pur pos es (Fig ure 2).

In this set up, the sys tem can al so serve as a test ex e cu tion en vi ron -

ment for a com po nent HIL test er.

2/1

Fig ure 1: CA Noe in cludes anal y sis, sim u la tionand test ca pa bil i ties for net workedsys tems.

Fig ure 2: Du al-com put er op er a tion of CA Noe Re al time of fers im proved re al-time ca pa bil i ties.

15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/1

Page 76: Vector Press Book

3 In te gra tion of test ing and de vel op mentTo day’s de vel op ment mod els call for tests in var i ous phas es of de vel -

op ment (Fig ure 3). Gen er al ly, the in di vid u al tests are self-con tained,

sep a rate ac tiv i ties that are per formed by spe cial ized per son nel at

suit a bly equipped, ded i cat ed work sta tions us ing spe cial tools, lan -

guages and meth ods. In this con text, test cre a tion is of ten or ga nized

as an in de pend ent task, de tached from oth er de vel op ment ac tiv i ties.

This seg ment ed work ap proach re sults from dis tri bu tion of the

many dif fer ent tasks of the de vel op ment proc ess to spe cial ized

work ing groups. How e ver, if this sep a ra tion of tasks is fol lowed too

strict ly, the nu mer ous con tact points be tween var i ous de vel op ment

and test ing tasks will most like ly not be util ized op ti mal ly. For ex -

am ple, on ly good co or di na tion be tween com po nent test ing and

sys tem test ing can pre vent ex pen sive re dun dant de vel op ment of

test cas es that are iden ti cal in con tent. When com pat i ble tools are

used, test cas es that have al ready been de vel oped once can be used

as a ba sis for oth er de vel op ments in var i ous ar e as. This avoid ance

of re dun dant de vel op ments frees up re sour ces that could be used,

for ex am ple, to prof it a bly in vest in the val i da tion of ex ist ing test

cas es and their ad vanced de vel op ment. Com pre hen sive test man -

age ment sup plies a sol id foun da tion for co op er a tion and, ap ply ing

the same re sour ces, op ti miz es the depth and breadth of test ing.

Co or di na tion al so helps to de tect and fill gaps in test ing.

Be sides link ing the dif fer ent test phas es, de vel op ment and test ac -

tiv i ties must al so be in ter re lat ed and adapt ed to one an oth er. Test -

ing must be un der stood as an in te gral com po nent of de vel op ment

that re quires com pre hen sive sup port us ing prop er meth ods and

tools. This must be guar an teed in ad di tion to the pro ce dur al and

or gan i za tion al in te gra tion. What is im por tant here is to make tests

avail a ble in con junc tion with de vel op ment, not just in the re quired

for mal ver i fi ca tion phas es. Ide al ly, it is pos si ble to per form tests

di rect ly at the ECU de vel op er’s work sta tion with the re sour ces ex -

ist ing there.

For this pur pose, CA Noe of fers a run-time en vi ron ment for test

ex e cu tion that can be used in par al lel to the re main ing bus sim u la -

tion and anal y sis func tions. The proc ess is very easy to set up, es pe -

cial ly if de vel op ers are al ready us ing CA Noe for re main ing bus sim u -

la tion and anal y sis of bus com mu ni ca tion.

CA Noe’s test com po nent en a bles man u al, sem i au to mat ic, and ful ly

au to mat ic ex e cu tion of tests. The de vel op er can be gin with sim ple

tests and lat er ex pand and com plete them. In gen er al, the proc ess

of cre at ing com plex tests is a task of val i da tion de part ments that

build their tests up on the de vel op er’s tests.

An im por tant foun da tion for such tests is the re main ing bus sim u la -

tion, which ide al ly is not set up man u al ly, but rath er is au to mat i cal -

ly gen er at ed and pa ram e ter ized from the da ta bas es of the sys tem

2/2

Fig ure 3: Tests are in dis pen sa ble in all phas es of de vel op ment.

15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/2

Page 77: Vector Press Book

2/3

de scrip tion. The ac tu al work is per formed by so-called mod el ing

DLLs (e.g. In ter ac tion Lay er, Net work Man age ment, etc.), which

are sup plied with the tool or which Vec tor puts to geth er as OEM-

spe cif ic mod el ing pack ets. The sig nals that the re main ing bus sim -

u la tion sup plies to the sim u lat ed nodes may be ac quired di rect ly

from test scripts, or may be stim u lat ed or add ed man u al ly.

In con trast to the sys tem at i cal ly planned, ex e cut ed and doc u ment -

ed ac tiv i ties of the test phas es, for mal ex e cu tion and doc u men ta -

tion are gen er al ly omit ted in tests ac com pa ny ing de vel op ment.

Nev er the less, these tests make sub stan tial con tri bu tions to ward

over all qual i ty, be cause they give the de vel op er the abil i ty to de liv -

er a more sta ble prod uct to the sub se quent test ing phase.

4 Ma tur i ty lev el as sess ment and er ror anal y sisTo as sess the ma tur i ty lev el of an ECU dur ing de vel op ment, a

com pre hen sive eval u a tion of all ex e cut ed tests is nec es sa ry. The

qual i ty of in di vid u al test re sults with re gard to re li a bil i ty and rel e -

vance must be con sid ered, but more im por tant is broad cov er age

of the re quired prop er ties by suit a ble tests. There fore, the re sults

of less for mal ly ex e cut ed tests are al so help ful in ma tur i ty anal y sis.

A pre req ui site for this – be sides keep ing rec ords of test ex e cu tion –

is the con sist ent use of con fig u ra tion man age ment. This is al so

in dis pen sa ble from the per spec tive of achiev ing qual i ty-ori ent ed,

struc tured de vel op ment proc ess es.

A test record is pro duced when ev er a test is ex e cut ed us ing CA Noe,

wheth er in the test lab o ra to ry or at a de vel op ment work sta tion,

and is cre at ed with out in ter ven tion by the us er or test case de vel -

op er. It is then avail a ble for tests ac com pa ny ing de vel op ment

with out re quir ing ad di tion al ef fort. The XML for mat used for the

test rec ords is an open for mat thus oth er tools can be used for fur -

ther proc ess ing of the re sults. For ex am ple, a test man age ment

sys tem might be used to eval u ate the test rec ords in the con text of

a ma tur i ty lev el anal y sis.

Es sen tial in this ef fort is a map ping of test re sults to test cas es,

and of test cas es to re quire ments. This is easy to achieve by the use

of unique iden ti fi ers (e.g. a re quire ment ID), which the test case

de vel op er ref er en ces in in di vid u al test cas es. CA Noe au to mat i cal ly

cop ies this iden ti fi er to the test record so that all test cas es, test

re sults and re quire ments are clear ly in ter re lat ed (Fig ure 4).

At least as im por tant as re cord ing and eval u at ing test re sults, is

the anal y sis of the caus es of the er rors that ac tu al ly oc cur. Most

test tools do not pro vide any such ca pa bil i ties or pro vide just ru di -

men ta ry ca pa bil i ties. One im por tant rea son is that er ror anal y sis is

of ten con sid ered as a com plete ly in de pend ent task for de vel op ers.

Fig ure 4: Test cas es and test re sults are clear ly ref er enced by IDs.

EF FI CIENT TEST ING IN AU TO MO TIVE ELEC TRON ICS

15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/3

Page 78: Vector Press Book

First, they are faced with the prob lem of un der stand ing er rors de -

tect ed in the test and trac ing their caus es. In par tic u lar, when er -

rors are re port ed by test lab o ra to ries, the de vel op er usu al ly does

not even have ac cess to the sys tems used in test ing.

There fore, at the test bench it is man da to ry to pre cise ly record the

test pro ce dure and log ev ery in ter ac tion with the DUT, es pe cial ly

bus com mu ni ca tion. Dur ing the role of anal y sis, CA Noe en a bles

replay and anal y sis of any de sired re cord ings (log rec ords). It is

thus pos si ble and ben e fi cial to have the same type of test sys tem at

the de vel op ment work sta tion as that of the test bench, so that the

de vel op er can re pro duce er ror pro duc ing test cas es in de pend ent ly.

In many cas es it is pos si ble to ex e cute the rel e vant test cas es even

if many sim pli fi ca tions are nec es sa ry, e.g. to avoid ad dress ing non -

ex ist ent meas ure ment hard ware.

5 Sig nal ab strac tion and di ag nos ticsAb strac tion is a com mon ly used and im por tant meth od for han dling

com plex i ty in soft ware de vel op ment and sys tem de sign. This can al -

so be ap plied to the han dling of tests. Grow ing func tion al i ty in the

ECUs not on ly in creas es the com plex i ty of sys tems, but al so re quires

tests that are more ex ten sive and com plex. The choice of the cor -

rect ab strac tion lay er in com pos ing tests not on ly af fects the ef fort

re quired to cre ate test cas es, and there fore costs, but al so the qual -

i ty of test cas es. Like all oth er soft ware com po nents, the test cas es

them selves may con tain er rors as well and should be checked be -

fore use. An oth er as pect is the nec es sa ry main te nance tasks, e.g.

mak ing ad ap ta tions to mod i fied re quire ments and cor rect ing test

cas es.

Ab strac tion on the sig nal lev el is a com mon way to test ECU func -

tion al i ty, and this is why in the ECU the ac tu al ap pli ca tion is gen er -

al ly based on a sig nal ab strac tion (Fig ure 5). In a CAN sys tem, for

ex am ple, an In ter ac tion Lay er in the ECU pro vides the sig nal ab -

strac tion. That is ex act ly how CA Noe us es an In ter ac tion Lay er; it

pa ram e ter iz es it self from in for ma tion con tained in the net work

descrip tions, which al so serve to cre ate the ECU soft ware. This

ensures that ECU and test en vi ron ment util ize the same ab strac tion

lay er and are there fore op ti mal ly tuned to one an oth er.

Si mul ta ne ous ly, sig nal ab strac tion al so rep re sents – at least on the

pro to col lev el – the re main ing bus sim u la tion. For ex am ple, it en -

sures that pe ri od ic sig nals are ac tu al ly trans mit ted pe ri od i cal ly. In

test ing, the ECU is rep re sent ed in a re al is tic en vi ron ment re gard ing

bus com mu ni ca tion. More over, when a change is made to the sys -

tem’s com mu ni ca tion ma trix, it is usu al ly pos si ble to con tin ue to

use the test cas es un mod i fied. With the same ap pli ca tion, the ab -

strac tion en a bles re use of test cas es in sim i lar pro jects.

In test ing ECUs, it is not on ly the sig nal in ter face that is im por tant.

Many ECU func tions can on ly be test ed mean ing ful ly if deep er

access to the ECU is pos si ble. Such ac cess es are pro vid ed by the dia-

g nos tic and cal i bra tion in ter fa ces, which are ac cessed via an ECU’s

ex ist ing bus in ter fa ces. It does not make sense to ad dress these

inter fa ces by sim ple mes sage se quen ces, since de fined pro to cols

un der lie the com mu ni ca tion proc ess. It is more con ve nient and

relia ble to have ap pro pri ate ab strac tions for di ag nos tics and cali-

bra tion.

In CA Noe, ei ther de scrip tion files from the CAN dela tool or ODX de -

scrip tion files are re spon si ble for pa ram e ter iz ing the di ag nos tic ac -

cess lay er. If no de scrip tion is avail a ble for the ac tu al di ag nos tic ca -

pa bil i ties of an ECU, a ge ner ic de scrip tion for KWP2000 and for UDS

sup plied with CA Noe may be used. Ei ther the ge ner ic de scrip tion or

a di ag nos tic de scrip tion file cus tom ized for the ECU will of fer con -

ve nient ac cess to the di ag nos tic serv i ces de fined there. It is pos si -

ble to ob tain the same ab strac tions and ad van ta ges as in the sig nal

ab strac tion de scribed above.

2/4

Fig ure 5: Sig nals of fer an ab strac tion lev el be tween mes sa gesand I/O con nec tions on the one hand, and be tween testdef i ni tions and sim u la tion mod els on the oth er hand.

15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/4

Page 79: Vector Press Book

in te grat ed in the pat terns that are sup plied (Fig ure 6). Test case

gen er a tion is re duced to de fin ing the tar get be hav ior, in clud ing

any sup ple men tal da ta need ed, such as the set tling times to be tol -

er anced.

To the ex tent that it is sen si ble, the sup plied test pat terns them -

selves are placed on the sig nal ab strac tion de scribed above and en -

a ble sym bol ic ac cess to sig nals, mes sa ges, etc., via the as so ci at ed

da ta bas es. The use of di ag nos tic serv i ces or I/O sig nals is al so pos -

si ble. In short: The en tire test ing in fra struc ture of CA Noe can be

used with test pat terns. If there are re quire ments that ex tend

beyond these ca pa bil i ties, the op tion of pro gram ming the test

cases still ex ists.

Au to mat ic gen er a tion of test cas es is an oth er meth od for cre at ing

tests ef fi cient ly, if suit a ble sour ces of in for ma tion are avail a ble.

The con tents of gen er at ed tests are by ne ces si ty lim it ed to the de -

scrip tion lev els and depths of the sour ces. Nev er the less, gen er a -

tion of fers val u a ble sup port, pri ma ri ly when it comes to cov er ing

the for mal ly de fined ba sic prop er ties of an ECU by tests. The rel a -

tive ly low ef fort re quired to gen er ate test re sults in quick er avail a -

bil i ty there by mak ing it pos si ble for ear li er de tec tion of un de sir a ble

trends.

The tool chain from Vec tor util iz es such test gen er a tor ap proach es.

De scrip tion files such as the DBC da ta base or CAN dela def i ni tions

are used as the source for the gen er a tor (Fig ure 7). The gen er a tor

us es them to gen er ate test cas es, which CA Noe then ex e cutes. Sin-

ce test scripts may make use of the en tire tool in fra struc ture, the

test gen er a tors are of ten de signed to be quite sim ple. For ex am ple,

The CCP and XCP meas ure ment and cal i bra tion pro to cols can be

used to ac cess in ter nal ECU var i a bles via test scripts in CA Noe. The

meas ure ment and cal i bra tion tool CA Na pe han dles these pro to cols

and the ECU de scrip tion files (A2L) that are need ed. CA Noe con trols

CA Na pe via the COM in ter face. This ac com plish es the same goals as

in the sig nal and di ag nos tic ab strac tion de scribed above.

6 Ef fi cient test gen er a tionA pre cise study of an ECU’s test cas es will re veal that many of the

test cas es can be de rived from just a few re cur ring pat terns. This is

quite ev i dent in gate way ECUs: A ma jor i ty of the test cas es serve to

check the rout ing of sig nals and mes sa ges. Fi nal ly, the on ly rea son

for the large num ber of test cas es is the large num ber of pos si ble

in put and out put da ta. But the same types of pat terns are al so

found in oth er types of ECUs. Ex pressed ab stract ly, this means that

many func tions are test ed by first put ting the ECU in a spe cif ic sta-

te us ing a suit a ble stim u lus and then check ing the state that is rea-

ched. The re cur ring pat tern of these test cas es is: Set sig nals (stim -

u la tion), wait for the max i mum al low a ble re ac tion time, and then

check the sig nals of the new ECU state. With some ex pe ri ence in

the use of test pat terns, us ers will like ly recog nize a few ad di tion al

run-time pat terns from which many test cas es can be de rived.

These pat terns rep re sent an op por tu ni ty for fur ther op ti mi za tion of

test case gen er a tion. CA Noe, in ad di tion to of fer ing clas sic pro -

gram ming of test cas es, al so lets the us er de fine test cas es based

on test pat terns. It is no longer nec es sa ry to pro gram the pat tern

con tents, since the pro ce dures are al ready known and per ma nent ly

EF FI CIENT TEST ING IN AU TO MO TIVE ELEC TRON ICS

2/5

Fig ure 6: The use of pat terns ab stracts the ac tu al ex e cu tion of the test case and there by sim pli fies test de vel op ment.

15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/5

Page 80: Vector Press Book

with just a lit tle ef fort a gen er a tor can cre ate suit a ble test cas es

from a cus tom er-spe cif ic gate way de scrip tion (e.g. in the form of a

da ta base or Ex cel spread sheet). Thanks to the test pat terns de -

scribed above, this just re quires a sim ple trans for ma tion of the cus -

tom er-spe cif ic da ta in to the for mat of the test pat terns. Us ers can

cre ate such a gen er a tor in a straight for ward man ner. Vec tor of fers

fur ther sup port in the form of project-re lat ed serv i ces.

7 Sum ma ryThe on ly way for au to mo tive OEMs and sup pli ers to deal with the

grow ing re quire ments for ECU tests is by ef fi cient test cre a tion and

au to mat ic test ex e cu tion. The test ing tool pre sent ed of fers a prov -

en so lu tion for im ple ment ing test ing tasks with sig nal ab strac tion,

in te gra tion of di ag nos tic, cal i bra tion and I/O in ter fa ces, the con -

cept of test pat terns, and test case gen er a tors. CA Noe is a high-

per form ance run time en vi ron ment for test ing ECUs and net works.

The tool en a bles ear ly cre a tion and ex e cu tion of tests with lit tle ef -

fort, right at the de vel op er’s work sta tion. The open in ter fa ces of

CA Noe fa cil i tate seam less in te gra tion in a com pre hen sive test ing

strat e gy and tool-sup port ed test man age ment. Al though some us -

ers might still im ag ine it to be a fu tur is tic vi sion, with suit a ble in te -

gra tion of CA Noe it is al ready pos si ble to de ter mine ma tur i ty lev els

to day. Vec tor is con tin u ous ly de vel op ing CA Noe for use in these

are as, there by sup port ing us ers with a mod ern and ef fi cient test

plat form.

Fig ure 7:Test cas es can be cre at ed from very dif fer ent sour cesus ing gen er a tors.

Thom as Ri e graf (Grad u ate En gi neer) is Glob al Prod uct Line Man a ger and re spon si ble for the prod uct line “Tools forNet works and Dis trib ut ed Sys tems” at Vec tor In for ma tik GmbH in Stutt gart.

Sieg fried Beeh (Grad u ate En gi neer) is team lead er and re spon si ble for test tools,di ag nos tics and mod el ing in CA Noe at Vec tor In for ma tik GmbH in Stutt gart.

Dipl.-In form. Ste fan Krauß (Grad u ate in In for ma tics) works as prod uct man a ger for test tools at Vec tor In for ma tik GmbH inStutt gart.

2/6

15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/6

Page 81: Vector Press Book

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. +49 7 11 / 8 06 70-0

www.vector.com

Systemize your ECU test

with systematic and reproducible tests. Efficient test systems

accelerate your CAN, LIN, MOST and FlexRay development.

> Create real test environments during the early stages of

development using generated simulations of a remaining bus.

> Use automatically created test cases and test reports for

systematic component and system tests.

> Speed up your ECU test by using the same platform for both

development and testing.

> Take advantage of the calibration, diagnostic or I/O port

interfaces in your tests.

> Test the full range of ECU functions with the VT System that

can simulate or control the environment.

Vector tools and services help you achieve optimum test quality and test coverage within all development phases.

Information and Downloads: www.vector.com/ecu-test

ECU Testing

Vector VT System

The modular test hardware

www.vector.com/vt-system

Diagnostics

Calibration

ECU

Distr. Systems

Deve

lopm

ent

Software

ECU

Management

Proc

ess

ECU

15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/7

Page 82: Vector Press Book

Re li a ble En gi neer ing Test ing on a Wip er Mo tor Test Bench

Va leo Wip er Sys tem de vel ops wip er mod ules us ing elec tric con -

trolled re vers ing DC mo tors to re al ize com plex wip er move ments

based on the OEM cus tom er spec i fi ca tions. The wip er sys tem has to

re act flex i bly and “in tel li gent ly” to en vi ron men tal con di tions. This

can be re al ized with the use of a bus com mu ni ca tion sys tem. Ad di -

tion al fea tures of re vers ing wip er mo tors are:

> Soft ware-based wip er field con trol

> Al ter nat ing park po si tion to pre vent per ma nent set of the rub ber

el e ment

> Soft ware con trol of wip er move ment and oth er op er at ing states

> Serv ice po si tion for the ex change of wip er blades

> Load-de pend ent speed con trol

> Over load pro tec tion

Un like con ven tion al ful ly ro tat ing DC mo tors, the out put shaft of

this mo tor type re vers es at an an gle less than 180 de grees. The mo -

tor drives a link age that moves the wip ers across the wind shield.

In con form ance with the ve hi cle ar chi tec ture, Va leo us es a CAN or

LIN da ta bus to con trol the re vers ing wip er mo tor. This new wip er

sys tem tech nol o gy al so re quires new stand ards for test ing tech nol -

o gy, which needs to be de vel oped in ad di tion to the ac tu al prod uct.

There fore, Va leo has de rived the re quire ments for an en dur ance

test bench and test proc ess es based on cus tom er spec i fi ca tions:

> Test du ra tion of more than 1.5 mil lion wip ing cy cles which is

equal to a con tin u ing test time of more than 28days.

> Au to mat ed, soft ware-con trolled test se quen ces

> The hi ghest lev el of test sys tem sta bil i ty (soft ware and hard ware)

> The si mul ta ne ous test ing of up to 5 mo tors us ing in di vid u al

control (volt age, mo tor loads, cur rent lim i ta tion, etc.) in clud ing

the re main ing bus sim u la tion.

> Se quen tial meas ure ment of phys i cal mo tor pa ram e ters such as

an gle, cur rent, volt age, and tem per a ture; cal cu la tion of speed

and RMS val ues

> Con tin u ous mon i tor ing of bus com mu ni ca tion, mo tor out put

shaft move ment pro files as well as oth er phys i cal pa ram e ters and

their eval u a tion by com par ing ac tu al meas ure ments to en vel op

curves.

> Con trol of the cli mate cham ber ac cord ing to spec i fied cli mate

pro files

In or der to val i date the cor rect func tion of wip er mo tors con trolled

by bus mes sa ges, Va leo needs to record and eval u ate the phys i cal

pa ram e ters such as an gle, rev o lu tions, and cur rent on the test

bench. The de ter mi na tion and doc u men ta tion of vi o la tions to cus -

tom er spec i fi ca tions shall be rath er sim ple and con ve nient. Va leo

en gi neers worked with dif fer ent sup pli ers on var i ous pro pos als for

the re al i za tion of such a test bench. Fi nal ly the con cept of Vec tor

In for ma tik GmbH from Stutt gart, which is based on the flex i ble de -

vel op ment and test soft ware CA Noe, was most con vin cing. A de ci -

sive fac tor for choos ing Vec tor In for ma tik was Va le o’s ex pe ri ence in

the suc cess ful ap pli ca tion of Vec tor tools such as CAN a ly zer, CA Noe,

and CAN is ter.

The “CA Noe Ap pli ca tion De vel op ment” team of Vec tor man aged the

im ple men ta tion. Through nu mer ous test and sim u la tion pro jects,

2/8

Fig ure 1: Wip er test bench at Va leo

Syn chro niz ing the bus com mu ni ca tion with meas ured phys i cal pa ram e ters is one of the most dif fi cult re quire ments for re li -a ble tests of ECUs. The da ta from four da ta ac qui si tion boards was eval u at ed in re al-time and syn chro nized with the buscom mu ni ca tion of a con trol mod ule in re al-time. The spe cial ists of Vec tor In for ma tik de vel oped an in di vid u al so lu tion basedon the de vel op ment and test tool CA Noe for the re quire ments of Va leo Wip er Sys tems.

Time-syn chro nous re cord ing and eval u a tion of bus mes sa ges and phys i cal pa ram e ters dur ing en dur ance test ing

Re li a ble En gi neer ing Test ing on a Wip er Mo tor Test Bench

16 Press Book_Seite_2-08_2-13:Press Report 3 09.02.2010 13:13 Uhr Seite 1

Page 83: Vector Press Book

2/9

RE LI A BLE EN GI NEER ING TEST ING ON A WIP ER MO TOR TEST BENCH

the team has the nec es sa ry ex pe ri ence and know-how to cre ate cus -

tom er-spe cif ic test sys tems with CA Noe. The Va leo test en gi neers

and the Vec tor team worked joint ly to de ter mine re quire ments for

the con fig u ra tion in ter face of the test proc ess con trol. Both project

part ners cre at ed the re quire ments for re cord ing and eval u at ing

meas ure ment da ta col lect ive ly. The de vel op ment was ini tial ly based

on a sim u lat ed test en vi ron ment pri or to test ing and ad just ing the

CA Noe test sys tem on the ac tu al Va leo test bench (Fig ure 1).

Cus tom er-tai lored hard ware for re cord ing meas ure mentda taThe test bench hard ware was build by the Ge sell schaft für Mess-

und Sys tem tech nik (GMS) [As so ci a tion for meas ur ing and sys tem

tech nol o gy] in Spaich in gen, Ger ma ny. DAQ cards from Na tion al In -

stru ments were used for re cord ing an a log and dig i tal sig nals. The

pa ram e ters such as an gles, cur rents, volt a ges, and tor ques are re -

cord ed for each test sta tion in di vid u al ly. Vec tor in te grat ed the four

da ta ac qui si tion boards in to the CA Noe test sys tem (Fig ure 2). For

stand ard ap pli ca tions this in te gra tion is re al ized us ing the CA Noe

port link fea ture. At that time (be fore ver sion 6.0), CA Noe did not

sup port the sig nal block trans fer be tween da ta re cord ing board and

CA Noe. Thus Vec tor de vel oped a CAPL-DLL cus tom ized for the ap pli -

ca tion, which ex pand ed the CAPL pro gram ming lan guage in CA Noe

to in clude us er-de fined func tions and in ter fa ces.

This DLL is used to read and con di tion the meas ured sig nals di rect ly

from the in put buff er of the hard ware. This al lows near ly re al-time

sig nal proc ess ing with a high sam pling rate. Then these sig nals are

for ward ed to the da ta re cord ing with in CA Noe (Fig ure 3). Par al lel

to the da ta proc ess ing via the DAQ boards, the test bench con trol

ac ti vates the mo tors de pend ing up on the test sce nar i os us ing a

low-speed CAN bus or a LIN-1.3/2.0 bus.

In or der to achieve the re quired test cov er age, the test bench is

equipped with five in di vid u al sta tions, per mit ting in de pend ent op -

er a tion. Each sta tion is equipped with its own pow er sup ply, brake,

and bus in ter face. The brake pro vides the load of the wip er mo tor

with a max i mum torque of 15 Nm. The test en gi neer spec i fies the

in di vid u al load in the test set up.

The bus com mu ni ca tion be tween each test spec i men and the CA Noe

con trol is al so pro vid ed sep a rate ly in or der to sim u late the com mu -

ni ca tion char ac ter is tics be tween the elec tric mo tor and the ECU as

re al is ti cal ly as pos si ble. Vec tor cre at ed a re main ing bus sim u la tion

for the CAN or LIN bus com mu ni ca tion for ac ti vat ing the wip er mo -

tor. Since there was not a re al wip er ECU at the be gin ning of the

project, the re main ing bus sim u la tion was ex pand ed by an ad di -

tion al node that sim u lat ed the char ac ter is tics of the wip er mo tor.

Aft er the in te gra tion of the re al ECU, this node was sim ply de ac ti -

vat ed.

The test bench is equipped with a stand ard in dus tri al PC for the

sim u la tion and con trol func tions as well as for the eval u a tion of the

meas ured sig nals in par al lel for all five test sta tions. The PC is al so

re spon si ble for ac ti vat ing the wip er mo tors via the CAN or LIN bus -

es. A CAN cardXL and two CAN boardXL with the ap pro pri ate CAN cabs

or LIN cabs from Vec tor are used as in ter face for the bus in ter face.

Per ma nent set point/ac tu al com par i sons make the eval u a tion eas ierThe test se quen ces of an en dur ance test are cus tom er spe cif ic and

in clude all func tions of the wip er mo tor. For ex am ple, an en dur ance

test might last more than 1200 hours. The wip er mo tor is op er at ed

at dif fer ent loads and tem per a tures in all modes such as high and

low speed, in ter val mode, off and sleep mode.

Fig ure 3:Da ta eval u a tion in the CA Noe node lay er DLL

Fig ure 2:In te gra tion of CA Noe in the wip er test bench

16 Press Book_Seite_2-08_2-13:Press Report 3 09.02.2010 13:13 Uhr Seite 3/9

Page 84: Vector Press Book

Syn chro nous re cord ing of the bus com mu ni ca tion with the phys i cal

meas ure ment val ues al ready men tioned above is the crit i cal fac tor

in achiev ing the most use ful test re sults. It has shown to be es pe -

cial ly fa vor a ble that the re cord ing of the bus com mu ni ca tion, the

meas ure ment re cord ing and the con trol of the test bench be done

by a sin gle soft ware tool with a com mon time ba sis (CA Noe).

CA Noe is al so re spon si ble for com par ing the meas ured phys i cal pa -

ram e ters and the bus com mu ni ca tion with the spec i fied lim its. If

crit i cal events oc cur the re sults are re cord ed. I.e. if de fined lim its

are ex ceed ed or if switch-off cri te ria are reached. The lat ter is al so

used to switch off the test.

The clear op er at ing struc ture sim pli fies test con fig u ra tionAc cord ing to the spec i fi ca tion of Va leo the Vec tor team al so de vel -

oped a CA Noe us er in ter face to cre ate var i ous test se quen ces, vis u -

al i za tions (Fig ure 6) and for the test bench con trol. The op er a tor-

friend ly us er in ter face al lows the test en gi neers to cre ate com plex

test pro ce dures and test se quen ces, based on time, event, or cy cle.

The dif fer ent lev els of the us er in ter face sup port the test en gi neer

in spec i fy ing a log i cal struc ture of the in di vid u al test pa ram e ters

ac cord ing to the test spec i fi ca tions. The ac ti va tion of the cli mate

cham ber as a part of the test bench es is al so in te grat ed in the us er

in ter face. The sta tus dis play (Fig ure 7) shows the cur rent num ber

of op er at ing cy cles and er ror mes sa ges as well as the vi o la tions for

cur rent, speed, or an gle lim its for each of the five test mo tors.

The Au to mo bile man u fac tur ers on ly tol er ate ro ta tion an gles with in

spec i fied tol er an ces in the en dur ance test of the out put shaft from

a re vers ing wip er mo tor. Thus Va leo con tin u ous ly mon i tors this an -

gle. The CA Noe ap pli ca tion is able to dis tin guish dif fer ent lev els of

lim it vi o la tions.

Dur ing these tests, the mon i tored phys i cal pa ram e ters such as cur -

rent, ro ta tion an gle, the po si tion of the mo tor out put shaft, and

mo tor tem per a ture are al lowed to vary with in spe cif ic lim its on ly.

The lim its are spec i fied as en vel ope curves (Fig ure 4). In or der to

achieve the re quired ac cu ra cy for ex am ple of the RMS val ue of the

cur rent, the da ta is re cord ed with a sam pling rate of up to 20 kHz.

Post proc ess ing of the raw da ta re du ces the da ta to one sin gle val ue

with in 2 ms.

A part of the eval u a tion is the per ma nent com par i son be tween the

meas ured sig nals and the spec i fied en vel ope curve. The da ta is

tem po ra ri ly stored in a ring buff er. In case of de vi a tions, CA Noe

stores pre and post event da ta val ues (log ging). The da ta vol ume is

ad just a ble (Fig ure 5). The Vec tor soft ware ap pli ca tion is able to

record re al time bus com mu ni ca tion be tween the mo tor con trol and

the wip er mo tor in par al lel to the meas ured sig nals. If com mu ni ca -

tion er rors oc cur, the CA Noe log ging func tion rec ords the meas ured

phys i cal pa ram e ters as well as the cor re spond ing bus com mu ni ca -

tion, in clud ing the pre and post event da ta.

2/10

Fig ure 5:Con fig u ra tion of pre and post trig ger times. In case ofan er ror, all events which oc cur in this time win dow arestored.

Fig ure 4: Con fig u ra tion of lim it val ues

16 Press Book_Seite_2-08_2-13:Press Report 3 09.02.2010 13:13 Uhr Seite 3/10

Page 85: Vector Press Book

RE LI A BLE EN GI NEER ING TEST ING ON A WIP ER MO TOR TEST BENCH

2/11

In case of low-lev el vi o la tions the soft ware is sues an er ror mes sage

(Fig ure 4). If a high-lev el vi o la tion oc curs the soft ware in ter rupts

the test im me di ate ly. The dif fer ent lev els are ad just a ble in the set up.

The ap pli ca tion de vel op ers of Vec tor have pre pared sim i lar test pro -

ce dures for the pa ram e ters cur rent and tem per a ture. The Va leo test

en gi neer can pre-se lect how of ten the lim it may be ex ceed be fore

the soft ware will ter mi nate the test. In gen er al, each test ed wip er

mo tor can be start ed in di vid u al ly, i.e. it is pos si ble to in ter rupt and

con tin ue a test in di vid u al ly. Pa ram e ters such as load ing torque,

volt age, or cur rent can be ad just ed sep a rate ly.

Er ror log ging stores the da ta in small blocks, which al lows the test

en gi neers to per form anal y ses dur ing the test. The test bench soft -

ware in cludes sta tus log ging which stores the cur rent sig nals in fre-

e ly ad just a ble in ter vals.

Com pen sa tion of en vi ron men tal in flu en cesSome bound a ry con di tions made the de vel op ment of meas ure ment

and test al go rithms very chal leng ing. For ex am ple, the test bench

is at tached to a cli mate cham ber for tem per a ture test ing. The com -

press or of the cham ber trans mits vi bra tions to the test rig and the

test ed wip er mo tor. The high-res o lu tion an gle sen sor is able to re -

al ize the vi bra tions as move ments of the wip er mo tor even thought

the mo tor out put shaft is not mov ing. A damp ing or phys i cal dis -

con nec tion of the com press or from the test bench would be ex -

treme ly dif fi cult, and an an gle sen sor with a low er res o lu tion would

not ful fill the re quired meas ure ment ac cu ra cy.

In or der to com pen sate such er rors, the meas ured da ta are post

proc essed us ing dig i tal fil ter ing and com pared with spec i fied speed

lim its. In case the soft ware de tects a con tin u ous ly os cil lat ing move -

ment with in cer tain lim its, it is able to dif fer en ti ate these sig nals

from a true mo tor out put shaft move ment. The elim i na tion of false

da ta must oc cur rath er fast due to the re al-time sig nal com par i son

be tween the phys i cal an gel sig nals and the bus com mu ni ca tion.

Dif fer ent wip er test bench es – one so lu tionAft er the suc cess ful im ple men ta tion of the CA Noe test ap pli ca tion

in the du ra bil i ty test bench for re vers ing wip er mo tors, both de vel -

op ment part ners ex tend the ap pli ca tion to test con ven tion al ro ta ry

wip er mo tors. While oth er test bench es mon i tor the mo tor speed

and tem per a ture on ly, this ap pli ca tion im proves the da ta ac qui si -

tion, re al-time da ta mon i tor ing and da ta anal y sis.

Va leo has al ready planned an ad di tion al ex pan sion: the CA Noe test

sys tem should be en hanced to a mo bile op er at ing and da ta ac qui si -

tion sys tem for bus con trolled wip er mo tors for the use in con ven -

tion al test bench es and even on board test ve hi cles. This al lows sim -

ple anal y sis of wip er sys tems in a wind tun nel or road test ing.

With the planned ex ten sion of the ap pli ca tion Va leo ben e fits from

the large da ta ac qui si tion and anal y sis ca pa bil i ty of the CA Noe soft -

ware tool. The de vel op ment team just needs to spec i fy the op tions

that have to be im ple ment ed in the soft ware. The ex pense is rel a -

tive ly small: Va leo em ploy ees sup port ed the Vec tor team with their

spe cif ic prod uct know-how and the def i ni tion of the ap pli ca tion.

The “CA Noe ap pli ca tion team” from Vec tor start ed the de vel op ment

of the test reg i men, bus com mu ni ca tion and the da ta ac qui si tion as

well as the eval u a tion of the test da ta with two en gi neers. Sub se -

quent ex pan sions has been re al ized with one per son form both

part ners.

Fig ure 6:Con fig u ra tion of test pro ce dures

16 Press Book_Seite_2-08_2-13:Press Report 3 09.02.2010 13:13 Uhr Seite 3/11

Page 86: Vector Press Book

Fig ure 7:Cur rent sta tus of the five test spec i mens

Va leo and Vec tor clear ly ex ceed ed the ob jec tives set for this project

by re act ing flex i bly to un fore see a ble chal len ges along the de vel op -

ment and im ple men ta tion proc ess. Fur ther more they are plan ning

an ex ten sion of the ap pli ca tion as more ca pa bil i ties of the CA Noe

tool be come ap par ent dur ing the ap pli ca tion de vel op ment. Dur ing

the ex e cu tion of the project the spec i fi ca tion had to be re de fined in

or der to re al ize ad di tion al test fea tures. Us age of el e gant soft ware

so lu tions al lows op ti miz ing the ap pli ca tion. With the new wip er

mo tor test bench, Va leo will use the mul ti func tion al CA Noe tool as a

con tin u ous sys tem plat form from the start of the prod uct de vel op -

ment to the val i da tion, thus guar an ty ing its cus tom ers the de liv ery

of re li a ble pro ducts.

2/12

Dipl.-Ing. (FH) Di et mar Baum gärt nerstud ied pre ci sion me chan ics at FH Heil bronn.He is man a ger of sys tem and com po nenttest ing for wip er sys tems at Va leo Wis cher-sys teme GmbH in Bi e ti gheim.

Dipl.-Ing. (BA) Ben ja min Di etzstud ied Me chat ron ics at BA Stutt gart and at the Va leo Wis cher sys teme GmbH com pa ny.Aft er his stud ies, he changed over to thetest ing de part ment of re vers i ble wip er mo tors. Cur rent ly, he is the elec tron ics de vel op er for ad vance de vel op ment.

Dipl.-Ing. (FH) Mar co Rom melstud ied elec tron ics with an em pha sis in au to ma tion tech nol o gy at FH Heil bronn. He works for the Va leo Wis cher sys teme GmbHcom pa ny in the test ing de part ment and is re spon si ble for cre at ing and man a ging test -ing equip ment.

Dipl.-Ing. Kat ja Hah mannstud ied elec tri cal en gi neer ing at TU Chem -nitz. Aft er her stud ies, she be gan work ing for Vec tor In for ma tik GmbH in Stutt gart in1997 and is cur rent ly team lead er of the teamfor CANoe Application Development in thepro duc tion line Net works and Dis trib ut edSys tems.

Dipl.-Ing. (FH) Rain er Brän dle stud ied tel e com mu ni ca tion en gi neer ing atFH Es slin gen and be gan work ing for Vec torIn for ma tik GmbH in 2005. He is project lead er for var i ous Va leo wip er test bench es asSen ior Soft ware De vel op ment En gi neer in the ap pli ca tion de vel op ment team.

16 Press Book_Seite_2-08_2-13:Press Report 3 09.02.2010 13:13 Uhr Seite 3/12

Page 87: Vector Press Book

The CustomerFrom the time it was founded, Nippon Seiki has extended its business, focusing on the development and manufactur-ing in-vehicle instrumentation. Nippon Seiki’s technologi-cal competence in this field is highly rated, and as a leading manufacturer of instrument panels it supplies a large num-ber of automobile and motorcycle manufacturers.

The ChallengeReducing ECU testing man-hours while simultaneously im-proving quality of overall testingWith growing computerization in automobiles, instrument

panels are moving toward multifunctionality. That is why

manual ECU test execution, pass/fail detection, and creating

reports took a huge amount of time. This has resulted in in-

creased ECU testing man-hours, and their reduction has be-

come a major issue.

The SolutionAutomation of ECU Testing using the CANoe Test Feature SetCANoe, provided by Vector, is used by a large number of cus-

tomers who develop in-vehicle ECUs. The CANoe Test Feature

Set is designed to automate ECU stimulation, pass/failure

detection and test report generation. To solve the issue of

increased man-hours, the following proposal was made to

Nippon Seiki:

Test samples: Delivery of a total of five test samples, includ-

ing a CAN Message Synchronization Test, Diagnostic Test,

and Gateway Test.

Training of employees involved in testing.

Technical support: In the context of technical support for

customers with maintenance contracts.

The CANoe Test Feature Set can also support fault diagnostics

and serve as a diagnostic tester.

The AdvantagesTest Execution Time Dramatically ReducedAutomating ECU test execution, pass/fail detection and re-

port generation helped Nippon Seiki to successfully reduce

total ECU test time from more than 18 hours to just over 12

hours. In particular, test execution time, which previously

took 11 hours, has now been shortened to about 4 minutes!

The more frequently testing is executed, the greater the gains

in testing efficiency. Finally, use of the CANoe Test Feature

Set has dramatically reduced the man-hours needed to per-

form the tests (see table below).

A System Design Department Manager described the advan-

tages of automatic execution like this: “There is certainly

some test case implementation work to be done when auto-

mating. But once the test case is created, the ability to reuse

it again and again is a huge advantage. In turn, this improves

overall testing quality.”

In this project, 30% of all ECU test cases are automated using

the CANoe Test Feature Set. Nippon Seiki will be expanding its

automated testing coverage in the future and targeting even

greater efficiency in ECU testing.

Case StudyAutomating ECU Test Execution,

Pass/Fail Detection, and Report Generation

Nippon Seiki Co., Ltd.

Your contact at Vector:Katsuhiro Kinoshita [email protected]

(*) Test No. 2 is executed simultaneously with Test No. 1.

Table: Comparison, in relation to test case and manhours, between conven-tional test method and the use of the CANoe Test Feature Set

16 Press Book_Seite_2-08_2-13:Press Report 3 09.02.2010 13:13 Uhr Seite 3/13

Page 88: Vector Press Book

2/14

Comprehensive ECU Tests with Fault Simulation

Electronics and software have become indispensable components

in the automobile. Therefore, verification of development results

not only covers the mechanical systems, but to a large extent the

electronic ECUs and their software as well. The complexity of heavi-

ly networked systems places high requirements on the test process

and the test tools used. Systematic and comprehensive tests are

necessary in all development phases. Various test methods are

applied in development (Figure 1). Before the classic test runs of

integration tests in the lab or through comprehensive driving tri-

als, the ECUs are first individually tested thoroughly in functional

tests.

In testing ECUs, it is not just the so-called “good cases” that are

of interest, i.e. processes that represent normal operation. Also

important is broad coverage of potential fault cases. In testing

normal operating functions it is usually sufficient to connect the

ECUs to their original components, operate them and observe their

reactions. Additional devices are necessary to cover fault states;

they are placed in the circuit between the ECU’s ports and the origi-

nal or simulated sensors and actuators (Figure 2). Such test

Fault simulation capability is needed in early test phases for efficient functional tests

Besides testing actual functionality, a modern test system for ECUs must also permit testing of the most important fault cases. This applies to the ECU’s communication interfaces as well as to its I/O interfaces. Suitable test systems can be implemented early in the development process using special test strategies tailored to the needs of the automotive indus-try. The new compact test hardware VT System from Vector meets the various challenges that face such a test system.

Figure 1: Different test methods are used in the various development phases.

17 Press Book_Seite_2-14_2-19.indd 217 Press Book_Seite_2-14_2-19.indd 2 09.02.2010 13:24:23 Uhr09.02.2010 13:24:23 Uhr

Page 89: Vector Press Book

XXXXXXXX

2/15

system may make fault memory entries, deactivate certain func-

tions in the ECU or generate error messages. So the sensors and

actuators are even needed for tests in which the functionality of a

sensor or actuator is not really of importance.

A commonly used solution is to connect original sensors and

actuators directly to the ECU. Many developer test benches are

equipped with simple connection boxes for this purpose, which

take the necessary components and have suitable cable connec-

tions. Similarly, original sensors and actuators are also provided to

the ECUs under test on large test benches. However, automating

the test processes is often problematic, since original components

must be operated, e.g. by actuating robotics.

An alternative to connecting original sensors and actuators is to

use substitute components. For example, a suitable resistor may

serve as a practical substitute for a lamp. Since the ECUs are only

equipped with simple measurement circuits to monitor their con-

nected components, generally a simple sensor or actuator simula-

tion is sufficient. Compared to the use of original components, this

enables compact and simple test systems. Similarly, it is relative

easy to automate user inputs with suitable test setups, e.g. by

using relays or switches.

In so-called Hardware-in-the-Loop systems (HIL) the overall

environment is modeled – including physical and dynamic process-

es in the connected components. In this case, however, simulation

and test execution would require elaborate and cost-intensive test

systems, and they would not always be available where they are

needed. This also applies to the necessary knowledge of operators.

Simulation of fault situations

To test an ECU’s reactions to faults in the connected environment,

the test system must be able to produce various fault situations.

Extensive tests under these atypical conditions are especially

important, because they occur very seldom in driving trials or on

the test bench and are difficult to reproduce. In the development

of hardware and software, many fault situations are frequently

components are often referred to as fault simulators. They might

be used to disconnect lines to simulate line breaks, for example.

In testing an individual ECU, besides controlling the hardware’s

input and output interfaces, the communication interfaces of the

DUT also play an important role. This places high requirements on

the test software, since – besides providing pure bus access for

CAN, LIN, FlexRay or MOST – it must be possible to comprehensively

and reliably operate the ECU’s software or protocol interfaces, e.g.

diagnostics via UDS or calibration via CCP/XCP. So the layout of

hardware and software interfaces has an enormous effect on the

performance, flexibility and, last but not least, the costs of a com-

plete test system.

Challenge of functional testing

In verification of ECU functionality, the primary task is to represent

the ECU in an environment that mimics the real vehicle environ-

ment as closely as possible. The sensors connected to the ECU are

operated to activate the functions to be tested, and the ECU’s reac-

tions are evaluated. There are very different ways to produce a suit-

able ECU environment. What is important is that the ECU must not

be able to perceive any differences between the real environment

and the environment simulated by the test system. In the end, the

extent of efforts primarily depends on test objectives.

In the simplest case, an elaborate stimulation circuit is omitted

and the ECU’s inputs are operated directly by simple means, e.g. by

manual switches between specific ECU lines. The ECU’s outputs

remain unconnected for the most part. Testing the ECU’s reaction

might only involve measuring the voltage at an output, for exam-

ple. Such approaches usually do not lend themselves to automatic

test execution, but they are easy to perform – especially during

development.

Increasingly, many of today’s ECUs can no longer be operated in

this way. Since they automatically check the sensors and actuators

in many cases, it is essential to connect them during the test. If an

external component is faulty or is not even present, the associated

ECUunder Test

Automated Testsystem

Sensor

controlling, stimulating

observing reaction

CAN, LIN, FlexRay...

fault injection

fault injection

ActuatorIn Out

+ +

Figure 2: Fault simulators are inserted between the sensors/actuators and the ECU.

17 Press Book_Seite_2-14_2-19.indd 317 Press Book_Seite_2-14_2-19.indd 3 09.02.2010 13:24:24 Uhr09.02.2010 13:24:24 Uhr

Page 90: Vector Press Book

2/16

forgotten, because the primary focus of developers is on the

desired functions. To achieve reliability of systems, however, it is

critically important that the ECUs also react properly in response to

faults.

In conjunction with sensor and actuator connections, it is espe-

cially important to simulate the following fault situations:

The electrical wiring is damaged: open circuits, short circuits to >

ground or battery voltage, short circuits between certain

connected lines.

Sensors or actuators are damaged: sensors do not supply any >

values, values lie outside allowable value range, or a compo-

nent’s electrical properties, e.g. internal resistance or current

draw, do not conform to the specification.

Incorrect input values, especially incorrect sensor data: from the >

perspective of the ECU, the sensor is operating properly and

measured values also lie within the allowable ranges. Yet, the

values are implausible or contradict other sensor values, and the

ECU must recognize this.

In all cases, the ECU must continue to work in a defined way. Fur-

thermore, the faults must be detected correctly, and relevant fault

memory entries must be made. Therefore, besides fault simulation,

it is also necessary to access the ECU’s software interfaces – typi-

cally the diagnostics interface – to stimulate input signals and test

output signals.

Integrated solution for ECU testing

Vector supports the analysis, simulation and test automation of

ECUs with the high-performance development and test tool CANoe

[1, 2]. Meanwhile, Vector hardware interfaces offer a reliable bus

interface to CAN, LIN, FlexRay or MOST. Measurement and test

hardware is controlled or driven via GPIB or the serial port, and

integration of standard I/O cards from various manufacturers

enables setup of test benches with a wide variety of complexity.

In driving the ECU I/O lines during an ECU test, Vector offers a

compact solution with the VT System (Figure 3). The ECU’s I/O

Figure 3: The VT System consists of standard 19-inch housings with their own backplane into which the modules are inserted. This lets users implement individual and flexible test solutions depending on requirements.

Power SupplyCAN, LIN,FlexRay, ...

ActorsActors

SensorsSensors

VT SystemVT System

ECUECUunderunderTestTest

+ -

VectorBusinterface

CANoe

Figure 4: The VT System is placed in the I/O lines between the ECU and actua-tors or sensors.

17 Press Book_Seite_2-14_2-19.indd 417 Press Book_Seite_2-14_2-19.indd 4 09.02.2010 13:24:24 Uhr09.02.2010 13:24:24 Uhr

Page 91: Vector Press Book

XXXXXXXX

2/17

lines – and if necessary original sensors and actuators – are con-

nected to the modular system (Figure 4). The PC is connected to

CANoe via a fast Ethernet-based real-time network. This makes it

possible to assemble flexible test systems without great integra-

tion or wiring effort. The VT System is well-suited to both small test

setups at a developers’ desk as well as comprehensive test benches

in the test laboratory.

The VT System simplifies the process of setting up test benches

immensely, since it integrates all components needed for an I/O

channel’s switching circuit in one module (Figure 5). Examples of

such I/O channels might include an ECU’s output for driving a

headlight or an input to be connected to a temperature sensor.

Since two-wire connections are made for all channels, the system

supports all input and output types relevant to practice, e.g. driv-

ing motors via an H-bridge in the ECU.

The measurement and stimulation devices contained in the mod-

ules are – like all components – designed for voltage ranges up to

32 Volt that are typically used in the automotive industry. They

require units for signal conditioning, which are already integrated

in the module. The modules can also handle the high currents that

may occur when lamps and motors are driven. Relays on the mod-

ules serve to connect the ECU lines to the attached original sensors

and actuators.

It is relatively easy to set incorrect sensor data with original sen-

sors, since here the sensors just need to be operated to be implau-

sible. However, the number of conceivable value combinations is

large. For systematic testing, a high level of automation is there-

fore desirable; to make it possible to reproduce as many fault pat-

terns as possible within a short period of time. Therefore, one

approach is to replace the original sensors by electronic simula-

tions. They are present on the VT modules for each channel and can

be controlled in any desired way by CANoe as a test system.

The sensors are simulated by a resistor decade or a voltage out-

put with relevant signal conditioning. There are stimulation units

for each of the VT System’s I/O channels, so that all ECU inputs can

be operated simultaneously. This enables simulation of multiple

faults and more complex operating processes.

Additional relays are used to represent faults such as line breaks

and short circuits. In operation, such faults typically occur due to

damaged wiring and problems at the plug connectors. Even when

there are just a few connection lines on an ECU, the enormous num-

ber of resulting combinations can hardly be fully tested. However,

with their knowledge of physical conditions existing at the ECU,

persons creating test cases can limit the selection of test cases to

isolated faults and the most likely combinations. For example,

short circuits only occur at adjacent pins on the connector. In the

VT System, the necessary switching options are once again avail-

able for every connected ECU pin, so that test case selection is

unlimited, and multiple faults can be covered.

It is somewhat more difficult to simulate sensor and actuator

damage. In this case, it is not possible to revert to the original

components, since the effort required to prepare them is extremely

high. That is why simulated components are used when working on

the test bench. The simulation does not need to be “perfect”. In

general, it is sufficient if the properties of sensors and actuators

are simulated, and if they are detected and evaluated by the ECU.

In the VT System, an electronic load is available for every ECU out-

put for use in an actuator simulation or load simulation. In simulat-

ing faulty sensors, the sensor simulations described above are

implemented as a resistor decade or output voltage. If there are

not enough integrated components for a test, it is possible to con-

nect external load simulations, sensor simulations or measurement

and test instruments via bus bars.

Test case creation accounts for a significant share of overall test

costs. Therefore, for efficient work processes the developer not

only needs the right hardware support, but also an optimal inter-

face to the test automation tool. In CANoe, after a simple configu-

ration of the VT System, all relevant data is available as system

variables. The user selects them via a graphic user interface in the

Test Automation Editor and applies them in the test sequences

COMPREHENSIVE ECU TESTS WITH FAULT SIMULATION

Figure 5: All components needed to test an ECU’s I/O channel are contained in the VT modules.

17 Press Book_Seite_2-14_2-19.indd 517 Press Book_Seite_2-14_2-19.indd 5 09.02.2010 13:24:24 Uhr09.02.2010 13:24:24 Uhr

Page 92: Vector Press Book

2/18

Literature and links: [1] Riegraf; T., Beeh, S.; Krauß, S.: Effizientes Testen in der Automobilelek-

tronik [“Efficient Testing in Automotive Electronics”]. ATZ (Volume 108), Issue 7-8, 2007, pages 648-655

[2] http://www.vector.com/canoe

(Figure 6). This means that the input and output signals, as well as

most control signals, can be addressed as easily as the bus signals

of the communication interfaces. The VT System is thereby seam-

lessly integrated in the CANoe test environment.

Flexible test system for ECUs

Automatic testing of ECUs impose many different demands on the

test system for controlling the ECU interfaces and I/O channels. For

the most part, testing functionality in normal operation just

requires operating the ECU’s sensor inputs and evaluating the reac-

tions at the actuator outputs. To represent fault cases, additional

components are needed in the test systems to enable simulation of

implausible sensor data, wiring problems and sensor/actuator

failures.

The VT System from Vector gives the test engineer a compact and

at the same time powerful solution for connecting an ECU’s I/O

channels to a test system with CANoe. The modular system provides

– for each channel – all key components for load and sensor switch-

ing as well as their simulation. It also offers the equipment needed

to create the different fault situations. These functions and proper-

ties of the VT System make it easy to set up test systems – together

with CANoe – that can be used flexibly for ECUs in the automotive

field.

Dr. Stefan Krauß studied Computer Science at the University of Stuttgart from 1990 to 1995. After earning his degree he worked on the technical staff of the university’s Institute for Computer Science in the Software Engineering depart-ment until 2001. Since 2002 he has been employed at Vector Informatik GmbH in Stutt gart, and is currently Product Manager for the VT System.

Figure 6: The VT System’s measurement and output signals are directly accessible in CANoe – on the right side of the Test Automation Editor here.

17 Press Book_Seite_2-14_2-19.indd 617 Press Book_Seite_2-14_2-19.indd 6 09.02.2010 13:24:25 Uhr09.02.2010 13:24:25 Uhr

Page 93: Vector Press Book

2/19

17 Press Book_Seite_2-14_2-19.indd 717 Press Book_Seite_2-14_2-19.indd 7 09.02.2010 13:24:25 Uhr09.02.2010 13:24:25 Uhr

Page 94: Vector Press Book

2/20

Semi-Synthetic Regression Tests with Real-World Data

Now more extensive, time-consuming and therefore more cost-

intensive tests and simulations are necessary, especially when soft-

ware is used for safety-critical functions in the automobile. Their

goal is to find software errors that may pose a risk to the safety of

passengers and other vehicles in traffic. This applies to steering

systems, especially those assigned to the highest risk class ASIL D

(Automotive Safety Integrity Level). Starting in 2009, legislative

bodies – not only in the EU but also to the U.S. and Asia – will be

requiring risk assessments and actions in accordance with the IEC

61508 safety standard and its specific modification ISO CD 26262

for the automotive industry. The maturity levels reached must be

documented by appropriate safety verifications.

The advantages of electrical power steering (EPS) – compared to

conventional hydraulic power steering systems powered by the

vehicle’s engine – are related to its ability to provide power assist

for the driver according to the situation. The system (Figure 1)

only operates and only consumes energy when the driver turns the

Reducing time and hardware effort in software evaluations

It is generally impossible to fully test electronic ECUs with a large number of input values because of the enormous amount of time required. Despite these constraints, Daimler has achieved a high level of test coverage and good depth in its soft-ware testing of electrical power steering units by using the methods of limit value and effects analysis to reduce the num-ber of test cases. Its practical implementation involves simulating driving maneuvers from the real world that are used as a reference. This article describes how to reduce the set of all theoretically possible test cases and to implement tests with a development and testing tool.

Figure 1: Testing the Electrical Power Steering (EPS) system for power assist when needed is extremely complex due to the large number of input parameters.

18 Press Book_Seite_2-20_2-23.indd 218 Press Book_Seite_2-20_2-23.indd 2 09.02.2010 13:27:20 Uhr09.02.2010 13:27:20 Uhr

Page 95: Vector Press Book

2/21

steering wheel. An EPS offers better control and contributes to

improved fuel economy and reduced emissions. For the driver, it is

important for the EPS to exhibit continuity in its capabilities and

driving dynamics. Whenever updates are made to new software

revisions, there is always the risk that undesirable side effects

might be introduced along with the desired changes. In most cases,

they just irritate the driver; in other cases, unlikely input signals

might cause serious malfunctions, including complete failure of the

EPS, that would impair driving safety. Thus whenever the software

is changed, reevaluating it is essential by running regression tests

to reveal changes in steering behavior between different software

levels.

Embedded software requires black box tests

Since EPS is a supplied system, Daimler does not have access to any

detailed information on the embedded software – except for a few

parameters and characteristic curves. All tests and evaluations must

therefore be executed as black box tests. Another problem is the

large number of input parameters: There is not enough manpower or

time to run through all theoretically possible combinations in HIL

(Hardware in the Loop) simulations or even real driving maneuvers.

That is because, besides manual steering torque as a basic input

variable, there are 47 other signals that significantly influence the

system. The sheer number of possible combinations of input param-

eters yields an incredible number of test cases that would take

several years to test. Practical testing would therefore require that

the sum of all possible input combinations be reduced to just a few

representative test cases while achieving high test coverage.

This can be achieved by combining and applying several test

methods, such as the equivalency class method, limit analysis and

the pairwise method. Daimler uses the HIL test bench in effects

analysis to find those signals that have the greatest impact on sys-

tem behavior. In addition to the three test methods mentioned,

optimization by knowledge integration, i.e. focusing on frequently

occurring input combinations in the application, is indispensable.

Knowledge integration (Figure 2) produces meaningful test cases

and makes a valuable contribution toward increasing software

quality. After the reduction process, 704 relevant test cases

remained, requiring approx. 12 hours of testing.

Real-world data instead of high-cost HIL

In practical tests on the HIL test bench, semi-simulated driving

maneuvers (replaying and calibrating recorded real driving maneu-

vers) play a key role. The tests are based on a catalog of standard

driving maneuvers that define the desired EPS behavior in specific

situations. These include actions such as slalom driving, ISO lane

change, circular driving, braking in a curve, steering wheel pull,

Elk test, etc. Vehicle developers drive these standard maneuvers in

real vehicle tests. This involves logging the bus traffic in the vehi-

cle by laptop with CANoe, the test and simulation tool from Vector

Figure 2: Reducing the number of test cases by know-ledge integration

18 Press Book_Seite_2-20_2-23.indd 318 Press Book_Seite_2-20_2-23.indd 3 09.02.2010 13:27:21 Uhr09.02.2010 13:27:21 Uhr

Page 96: Vector Press Book

2/22

system developed by Daimler, the logged measurement data are

sent to a Replay block in CANoe for playback (Figure 4). In the first

branch, a blocking filter removes the CAN messages sent by the EPS

in the vehicle to avoid overlapping signals. In the second branch,

the system generates the calibrated signals and computes the ana-

log voltages. This is done with the help of the script language CAPL

integrated in CANoe, which is based on a simplified C-language

syntax. This makes it easy to calibrate real measured signal values

for the test cases, simulate different manual input torques, and

generate various target engine speeds and controller releases.

Digital and analog interfaces

The interface hardware between the laptop and HIL system is the

PCMCIA card CANcardXL, whose interface physics can be optimally

configured to application requirements via two interchangeable

connection cables. A so-called CANcab is used, first, to have the

system send the (calibrated) remaining-bus simulation, and, sec-

ond, it receives the CAN communication generated by the EPS in the

HIL environment. CANoe logs and saves all communication for later

evaluation. An IOcab is responsible for outputting the analog signal

voltages for simulated manual steering torque, target engine speed

and engine brake enable. The engine brake in the HIL simulates the

effective resisting moment due to friction and rolling resistance.

The HIL measurement data (Figure 5) can be conveniently ana-

lyzed offline with Matlab/Simulink. To do this, CANoe exports the

target and actual values in .mat format. So far, no online evalua-

tion has been necessary, but it would be possible by integrating the

Matlab/Simulink models directly in CANoe. The EPS is considered

functionally capable if deviations of the actual EPS torques from

the corresponding target EPS torques do not exceed a defined limit

(Figure 6). Only then does it make sense to conduct further tests

(Figure 3). This “real world data” can then be replayed 1:1 on a

test bench to recreate the EPS as a virtual environment.

However, it does not make sense to just test the original driving

maneuver; instead the EPS is tested in modified scenarios of the

tests cited above as well as in limit conditions, e.g. at higher vehi-

cle speeds, different engine speeds, friction values or modified

manual steering torques. To do this, it is necessary to set and

adjust certain parameters during the simulations. In the test

Figure 3: Test setup for logging real bus communication, driving the HIL and evaluating measured values.

Figure 4: Various internal processing blocks are used to log and replay the data in CANoe.

18 Press Book_Seite_2-20_2-23.indd 418 Press Book_Seite_2-20_2-23.indd 4 09.02.2010 13:27:22 Uhr09.02.2010 13:27:22 Uhr

Page 97: Vector Press Book

2/23

in the real vehicle, since unanticipated risks for driver and vehicle

have now been reduced to a minimum.

Summary

The testing approach for evaluating software levels and revisions

described here met Daimler’s expectations for the project. Suitable

test methods combined with intelligent knowledge integration reduce

the theoretically possible number of test cases to just a few conceiv-

able combinations of input signals. Daimler engineers were able to

obtain conclusive test results on the behavior of the EPS as a black

box with relatively little time and effort. Instead of computing driving

situations and effects analysis with a complex, exact vehicle model in

cost-intensive HIL systems, logged real-world data is used, which can

be modified in semi-simulated driving maneuvers. The simulation and

test system CANoe provides valuable services here; it runs on a lap-

top, so it is ideal for logging standard driving maneuvers in the real

vehicle and conducting tests. During these semi-simulated driving

maneuvers, the Vector system is responsible for key system functions

ranging from replaying, filtering and modifying the real world data in

real time to controlling the test flow with the CAPL script language.

Not only do its lower costs argue for using CANoe – so does the posi-

tive experience the department has had with the system. The test

platform, together with the HIL computer, is so compact that Daimler

can take the entire system on real test drives at any time.

SEMI-SYNTHETIC REGRESSION TESTS WITH REAL-WORLD DATA

Michael Herbert (Graduate Engineer), studied electrical engineering and informa-tion technology at the Technical University of Darmstadt. As part of his undergraduate thesis work at Daimler AG, he researched the topic of Effects and Limit Value Analysis of an EPS. Since October 2008, he has been working at Daimler AG as a computational engineer for handling simulations on the S-Class.

Andreas Herp (Graduate Engineer), studied electrical engineering at the Univer-sity of Karlsruhe. Since October 1998 he has been employed at Daimler AG, first as a development engineer, and since 2006 as E/E project leader for ECU and software develop-ment of electrical power steering, and he directed the thesis work by Mr. Herbert.

Oliver Falkner (Graduate Engineer), studied electrical engineering at the Univer-sity of Stuttgart. After graduating, he joined Vector Informatik GmbH in Stuttgart in 1999, where he is currently senior product manage-ment engineer in product management of the Networks and Distributed Systems prod-uct line.

Figure 5: Real measured target values are compared to HIL output values in Matlab.

and those that are smaller, with each performing a test in that

range. The equivalence class method is prescribed by IEC

61508/ISO 26262.

Limit AnalysisThis is based on the equivalence classes, where the primary

focus is on the limits or extremes of the value ranges, e.g.

maximum defined signal values, steering torques, etc. Experi-

ence has shown that the causes of errors can often be found

there. Besides limits, it also makes sense to test values 1

greater and 1 smaller to discover overruns, interpolation

errors, etc.

Pairwise MethodThis is the accepted and widely used practice for testing all

combinations of two signals. However, since blind application

of this method almost always leads to unlikely test combina-

tions, it makes sense to select combinations with knowledge

integration, to focus on typical input combinations of the

application in question.

Equivalence Class MethodEquivalence classes are made up of input or output values pre-

sumed to elicit an identical system reaction, i.e. instead of

testing all of them, only one or just a few representatives of

the equivalence class are tested. All valid values of a defined

input range might define one equivalence class, for example,

when values outside of the defined value range represent

another equivalence class. The latter class can itself be subdi-

vided into values that are larger than the valid value range

18 Press Book_Seite_2-20_2-23.indd 518 Press Book_Seite_2-20_2-23.indd 5 09.02.2010 13:27:23 Uhr09.02.2010 13:27:23 Uhr

Page 98: Vector Press Book

2/24

Model-Based Testing for Better Quality

Software engineering is a discipline of computer science that has

great innovative potential. Great software complexity and the over-

abundance of resulting information raise the quality assurance

issue of how to effectively guarantee consistency of the model and

code. Test strategies and processes used during the early stages of

development will reveal technical and design errors early, when

they can be corrected much more cost-effectively.

Model-based development is a software engineering method

which – in addition to documenting the system – also utilizes auto-

matic generation to produce a large share of the test documenta-

tion. In practice, most test cases are still created manually. In a

classic document-based approach, test cases are derived from

requirements and described in a test specification. From this speci-

fication, tests are implemented to verify proper software imple-

mentation in the ECU (Figure 1).

Over the past five years, automotive OEMs have been applying

more and more model-based methods to develop embedded soft-

ware. One possible approach that integrates these model-based

methods into the development process is one in which the software

is manually implemented in the ECU while functional models are

created in parallel (Figure 1). The development of executable func-

tional models represents a quality improvement in requirements

analysis and development. First, the functional models define func-

tions and then validate them with respect to the given

requirements. The test specification should be used again to verify

the functional model. This process reveals errors and inconsisten-

cies in early development phases, which can then be corrected at a

fraction of the cost of correcting them later, after system or accep-

tance testing. Broad tool support also promises minimal time to

develop the ECU software, e.g. by using automatically generated

production code (Figure 1).

Stepwise development and verification of complex functional

models assumes efficient test methods. A check must be made at

each step in the development process to verify that no errors have

been introduced. In a process known as model-based testing, test

case generators take functional models and automatically generate

test cases, which can then be automatically executed, evaluated

and documented.

Other issues involve where it makes sense to apply automatically

generated test cases and which advantages they offer in the devel-

opment of embedded vehicle systems. The new approach can be

used during iterative development of functional models to auto-

matically generate test cases for regression tests, for example.

Another possibility is to re-use the test cases generated from this

development phase in later testing phases of the development pro-

cess, such as in ECU acceptance tests (Figure 1).

Advantages of test case generators in model-based development processes

Test case generators that implement the concepts of model-based testing in functional model development have been com-mercially available since 2007. The automatically generated test cases simplify regression tests during iterative develop-ment of complex models. Transformations make it possible to re-use the test cases that are generated, e.g. in ECU accep-tance testing, so that test cases do not need to be recreated manually. This results in considerable savings in time and cost for functional developers.

Figure 1: Comparison of different approaches to developing ECU software

19 Press Book_Seite_2-24_2-27.indd 219 Press Book_Seite_2-24_2-27.indd 2 09.02.2010 13:27:06 Uhr09.02.2010 13:27:06 Uhr

Page 99: Vector Press Book

2/25

Test case generators simplify regression tests

Requirement definitions are often subject to change. Any errors

discovered in the requirement definitions are corrected, and new

functions may be added to extend the functionality of the system

being developed. Later in the development process, the implemen-

tation is often restructured or simplified – all while retaining its

functionality, of course. Functional models that have already been

developed are then adapted to the new conditions. During this pro-

cess, the developer must ensure that changing a functional model

does not introduce any new errors or undesirable effects on func-

tionality. This can be accomplished by using regression tests [1].

Three steps are necessary to attain this goal:

A suitable Model-in-the-Loop (MiL) test environment must be >

developed for the regression tests

Test cases must then be automatically executed in this MiL test >

environment

Regression tests will be automatically evaluated >

A key aspect of regression testing is the quality of the comparison

of a modified functional model with its previous version. One mea-

sure of this quality is code coverage, which is why comparing dif-

ferent versions of a functional model requires the greatest possible

coverage. In test cases related to requirements, greater code

coverage entails immense effort, because if there are coverage

gaps, the related code sections must be analyzed, and other

requirement-based test cases may need to be manually created

until the necessary code coverage is attained. Because of this

immense effort, it is no longer advisable to manually create test

cases for the regression test.

One answer lies in the use of new commercially available test

case generators, such as Simulink Design Verifier from The Math-

works or Telelogic Rhapsody ATG from IBM. Test cases are automati-

cally generated after specifying a specific code coverage to be

attained. The test cases then increase the quality of the compari-

son. In addition, the tools can often simultaneously generate an

MiL test environment, execute test cases and automatically gener-

ate a test report. This results in a working method that can be used

throughout the system which has quite short throughput times.

This in turn further simplifies the execution of regression tests for

functional models, which results in cost and time savings.

Figure 2 shows an implementation of a regression test in a Mod-

el-in-the-Loop test environment. Functions are modeled in Simu-

link/Stateflow, while the Simulink Design Verifier generates the

test cases. In principle, other modeling tools could also be used,

provided that they can be obtained with test case generators.

The “Test Cases” block shown in the diagram (Figure 2) contains

the automatically generated test cases and stimulates the “Test

Figure 2: Setup of a Model-in-the-Loop test environment for regression tests in MATLAB/Simu-link. A script generates test reports and auto-matically adapts their output format

19 Press Book_Seite_2-24_2-27.indd 319 Press Book_Seite_2-24_2-27.indd 3 09.02.2010 13:27:06 Uhr09.02.2010 13:27:06 Uhr

Page 100: Vector Press Book

2/26

Unit” system under test. This represents the modified functional

model. The “Expected Results” block contains the reference outputs

from the previous version of this functional model. In the “Regres-

sion Test Analyzer” block, the newly generated outputs of the modi-

fied functional model are compared to the reference outputs at

each step of the simulation. After the test run, a script automati-

cally creates the test report and adapts it to the desired output for-

mat. In this case, the output format matches a CANoe test report by

Vector. If the evaluation finds a difference in the outputs, checking

must indicate whether the difference is acceptable or whether it is

an error.

The iterative approach presented here is an efficient way to sup-

port continuous improvement and adapt the functional model to

new requirements. It also improves the quality of the functional

model. In addition, verification at each step in the development

process ensures that no new errors have been introduced, further

improving quality. Developing functions with this model-based

approach will make test cases available. The goal is to not only use

these test cases for regression testing of functional models, but

also for later test phases in the automotive software engineering

process, such as in ECU acceptance testing.

Re-using test cases in ECU acceptance tests

The goal of the acceptance test is to verify that software functions

that suppliers implement in ECUs behave as defined in the specifi-

cation. To perform an acceptance test, suitable test cases must be

created which test the specified functionality. Clearly, one poten-

tial way to reuse the test cases generated from model-based devel-

opment is in a Hardware-in-the-Loop test environment. The

advantage here is that the test cases do not need to be manually

re-created.

A tester wanting to re-use the test cases may find that changing

the test environment from Model-in-the-Loop (MiL) to Hardware-

in-the-Loop (HiL) also shifts test boundaries. Test cases in the MiL

test environment refer back to the logical input and output signals

of the functional model. Test cases in a HiL test environment, on

the other hand, require physical signals, e.g. CAN signals, to stimu-

late the system and evaluate system behavior. It is therefore neces-

sary to transform the test cases, which involves mapping logical

signals to associated CAN signals (Figure 3).

Also, when performing a transformation it must be remembered

that test cases in the modeling tool do not necessarily have the

same data structure or data format as test cases in a tool for HiL

tests, e.g. in CANoe.

In practice, XSLT Stylesheets might be used to perform such a

transformation, for example; this assumes that test cases can be

exported from the modeling tool in XML format. Before the test

cases may be transformed to suitable executable test scripts for the

given HiL test environment, an intermediate step is necessary:

mapping the signals, e.g., using an Excel table. Visual Basic for

Applications replaces the relevant items in the XSLT Stylesheet

where the mapping is implemented. Finally, the transformed test

cases are linked and automatically executed in CANoe. An automat-

ically generated test report helps in evaluating the test results. All

necessary steps in this tool chain can be automated, which yields

time and cost savings.

Acceptance testing with reusable test cases now tests both the

software integration and the hardware-software integration. Test-

ing verifies that the software components properly interact with

Figure 3: Procedure for re-using test cases in a Hardware-in-the-Loop test environment. A precondition is transformation of the test cases.

19 Press Book_Seite_2-24_2-27.indd 419 Press Book_Seite_2-24_2-27.indd 4 09.02.2010 13:27:07 Uhr09.02.2010 13:27:07 Uhr

Page 101: Vector Press Book

2/27

MODEL-BASED TESTING FOR BETTER QUALIT Y

one another via their specified interfaces [1]. Also, the interplay of

the complete software system with the ECU hardware is tested in

the HiL test environment. This verifies the entire implementation

in the ECU.

Summary and Outlook

Powerful new test case generators are now commercially available

which make it possible to conduct efficient regression tests during

model-based development of vehicle functions without any addi-

tional effort. Test cases generated can be re-used in later test

phases of the automotive software engineering process, such as in

ECU acceptance testing. This requires converting the test cases by

means of a suitable transformation to produce test scripts for the

specific HiL test environment.

A method-based approach to testing may be applied to model-

based function development with functional descriptions in

MATLAB/Simulink. Use of model-based test methods is being stud-

ied in ongoing research projects. For example, the goal of the

VitaS3 research project at the University of Applied Sciences in

Regensburg is to determine the extent to which formal and semi-

formal description languages such as the Object Constraint Lan-

guage (OCL) and temporal logic methods can be used to generate

test cases via model transformations [2]. The use of formal descrip-

tion techniques is prescribed in the primary industrial standard for

functional safety IEC-61508 for safety-critical systems. This

approach enables virtual integration of vehicle functions.

Literature references: [1] Liggesmeyer, P.: Software-Qualität, 2002[2] Laboratory for Safe and Secure Systems LaS3, VitaS3 research project,

(www.las3.de/englisch/forschung/forschungsprojekte.html)

Albert Habermann (Graduate Physicist), served as an advisor for the Masters thesis of Mr. Hartig as part of his work in Technical Consulting and Engineering Services at Vector (with a focus on model-based SW development and testing). Today, Mr. Haber-mann is project manager for the eASEE process tool in the Customer Service area at Vector.E-mail: [email protected]

Wolfgang Hartig (M. Eng.),obtained his Master of Engineering degree in Electrical and Microsystems at the University of Applied Sciences in Regensburg. He con-ducted his Master’s thesis work at Vector on the topic: “Study of the potential uses of automatically generated test cases starting from software models“. Today, he is employed in the area of Technical Consulting and Engineering Services at Vector. E-mail: [email protected]

Jürgen Mottok, (Prof. DSc.), teaches computer science at the University of Applied Sciences in Regensburg. His areas of teaching include: Software engineering, pro-gramming languages, operating systems and functional safety. He directs the Laboratory for Safe and Secure Systems (LaS3), is a mem-ber of the advisory board of the Bavarian Cluster of IT Security and Safety, and active in other working committees. E-mail: [email protected]

19 Press Book_Seite_2-24_2-27.indd 519 Press Book_Seite_2-24_2-27.indd 5 09.02.2010 13:27:07 Uhr09.02.2010 13:27:07 Uhr

Page 102: Vector Press Book

2/28

Efficient Airbag ECU Tests

The functional integrity of the safety system depends on the airbag

control unit. Airbag systems must operate absolutely error-free,

and so they are subject to the most stringent safety requirement

level: ASIL Level D. It requires continual monitoring of all of the

system components involved such as squibs, sensors, switches and

the airbag control unit itself. Fault conditions are stored in fault

memory and can be read out in the service garage.

The test system presented here focuses less on crash-triggering

tests, and more on validation of software requirements derived

from customer and internal requirements. In addition, the test

hardware is used to simulate the vehicle environment of the target

systems. The hardware makes it possible to automatically simulate

nearly all external system states that are relevant to functional

software tests (Figure 2). One of the test system’s capabilities is to

generate various error states of the airbag system to study the

ECU’s behavior in such situations. The desire to improve test quality

and automate test sequences in testing that supports development

motivated Bosch to subcontract the development of a compact,

mobile airbag test system. The goal was to obtain a flexible system

that implements the requirements of early test phases more cost-

effectively than powerful HIL systems (Figure 1), and which is

well-suited to worldwide use at all Bosch development sites for air-

bag systems.

Automated tests during development shorten project times, increase testing depth and make it possible to reproduce errors

In the automobile, airbags are among the safety-critical systems whose reliability can be a matter of life or death. The air-bag control unit is responsible for proper operation of the entire occupant restraint system, consisting of all sorts of air-bags, belt tensioners, sensors and switches. Even during product development, numerous validation tests are indispen-sable at all development stages. A new test system at the Robert Bosch company increases efficiency in early test phases in development; it shortens test times while simultaneously increasing testing depth. It also reduces the number of test iterations for system tests on existing HIL test benches.

20 Press Book_Seite_2-28_2-31.indd 220 Press Book_Seite_2-28_2-31.indd 2 09.02.2010 13:24:36 Uhr09.02.2010 13:24:36 Uhr

Page 103: Vector Press Book

2/29

generating short circuits between lines and to different voltages,

for example. Resistor decades simulate the operating ranges of

squibs and seatbelt switches in this application. The test system

must also simulate connection of the wrong lines as well as over-

voltages and undervoltages. This involves use of an integrated volt-

age supply to run through various individually programmable volt-

age curves. Afterwards, a check is made to determine whether the

airbag ECU’s internal monitoring correctly identifies the error

states.

Another important requirement is configurability of the test sys-

tem. The number, names and assignments of the pins used, as well

as the number and type of squibs and seat belt buckles vary with

each project. These aspects must be taken into consideration, so

that the test system can be conveniently used in different projects.

Automatable tests, easy operation and flexible test software

Vector’s CANoe test and simulation software and integrated Test

Feature Set (TFS) made a significant contribution toward quick and

successful implementation of the new test system. Basic properties

of TFS are automatic execution of ECU tests and parallel generation

of test reports. The test sequences themselves are created in CAPL,

a C-based script language. To conveniently support specific appli-

cation cases, project-specific extensions are made.

The test hardware from TBM, specially developed for this project,

is controlled via CAN. The interface to CANoe is made via a channel

of the Vector CAN hardware. To drive the TBM test hardware, Vector

developed a C++ DLL, which provides all of the necessary CAPL test

functions. This makes additional functions available to users,

including automatic reporting (Figure 2).

Requirements of the new test system

In the framework of project services, Vector Informatik developed

the test system software and integrated the test hardware. The

project-specific hardware was designed and built by TBM Software-

Entwicklung & Elektronik (TBM). In the joint planning phase, it was

determined that software and hardware requirements for the new

system would vary widely, because it would have to handle many

Bosch projects for different OEMs, vehicle lines and variants. The

goal here was to find a reasonable compromise that would allow a

majority of the software requirements to be validated for the ECUs.

A key requirement is simulation and monitoring of the ECU’s

immediate environment. This environment consists of squibs,

switches, peripheral acceleration sensors, warning lamps and the

CAN bus. To simulate line errors, the system must be capable of

Figure 1: Use of the new test system in the V-Model

Figure 2: Layout of the test system

20 Press Book_Seite_2-28_2-31.indd 320 Press Book_Seite_2-28_2-31.indd 3 09.02.2010 13:24:37 Uhr09.02.2010 13:24:37 Uhr

Page 104: Vector Press Book

2/30

In creating the test sequences, it is often very advantageous to

be able to address ECU pins by meaningful names. Mapping tables

handle the assignments between test hardware channels and pro-

ject-specific pin names.

CANoe, the central control unit, is responsible for core functions:

Test hardware drive control via CAN, CAN remaining bus simulation,

diagnostics and reporting (Figure 3). Extensive CAPL functions

allow Bosch to create complex test cases as well. These functions

are used to control switching of short circuits, setting of resistances

and setting of current sources. They are also used to send and

evaluate CAN messages, e.g. in testing the ECU’s error memory.

Additional CAPL convenience functions are used to search for a spe-

cific ECU pin name, or to query switch states and compare them.

There are also arithmetic functions for processing arrays. CANdela

files in CDD format or ODX files may be used as standard diagnostic

description files. Since diagnostic descriptions are not available in

these formats on all projects, Excel tables are also used. This makes

it possible to use symbolic descriptors for diagnostic services and

parameters in all projects. The Bosch airbag ECUs also support pro-

duction diagnostics – an internal company diagnostic protocol.

Production diagnostic services are already integrated in ECU imple-

mentations very early in development. These services have been

integrated in CANoe. XML/HTML reports generated from the CANoe

TFS can be modified to be project-specific, and test log depth of

detail is set separately for each test run.

At the Bosch company, the test system was systematically fur-

ther developed and a test control was implemented for individual,

manually executed tests, for example. The system offers a graphic

CANoe operating panel for this purpose, and this renders the previ-

ous manually operated test hardware unnecessary.

The results

The new test system – subcontracted by Bosch and implemented by

Vector and TBM – includes project-dependent squibs, seatbelt buck-

les and configurable warning lamps. It is universally applicable for

the airbag ECUs of most OEMs, vehicle lines and equipment vari-

ants, and it is well suited for automated software requirement tests

as well as error replication and analysis. In addition, it is already

being used for certain software integration tests and module tests.

The system lets users automatically test ECU functions, log the

observed behavior and recognize deviations from expected behav-

ior. In total, 42 systems are now in use in Germany, India, the USA

and Japan. The cost advantage compared to large HIL test benches

enables its use in low-cost countries.

The primary software and hardware developments were complet-

ed within the very short time of just half a year. For the time from

startup to in-house maintenance of the new system by Bosch,

Vector was the central contact partner for application support and

modifications to the overall test system.

Figure 3: Components of the CANoe configuration

20 Press Book_Seite_2-28_2-31.indd 420 Press Book_Seite_2-28_2-31.indd 4 09.02.2010 13:24:38 Uhr09.02.2010 13:24:38 Uhr

Page 105: Vector Press Book

2/31

Summary and outlook

The new airbag test system for software requirements testing

exceeded expectations in fulfilling project goals. After an initial

automation effort, the system enables significantly shorter test

times despite the much higher number of test cases. In addition,

early implementation of automated tests during software develop-

ment means that errors in the airbag ECUs can be detected and cor-

rected more quickly. Subsequent validation stages build upon a

high level of software quality. Global use of a uniform test system

for software validation levels at all Bosch sites for developing air-

bag ECUs makes it easy to reproduce faulty behavior independent

of the site. Excited about the many capabilities and potential of

CANoe, Bosch is already considering further extensions of its air-

bag test system.

VALIDATING SOFTWARE REQUIREMENTS BY EFFICIENT AIRBAG ECU TESTS

An airbag triggering process consists of a sequence of highly

precise, interrelated and coordinated individual actions. Sen-

sors supply information on the vehicle’s speed, transverse and

longitudinal acceleration values and rotational movements.

The airbag ECU applies other parameters in its computations –

such as weight distribution on seats, states of seatbelts, belt

tensioners and switches – to determine which airbags should

be ignited, at what times and with which strength. The air bags

are only activated for a short period of time, so precise igni-

tion time is a crucial parameter. Another important parameter

is the speed at which the bags fill, which can be influenced by

the use of different ignition pills. The ignition pills are pyro-

technical propellant charges that generate a lot of gas in a

short period of time.

Frank Böhm (Dipl.-Ing. (FH)) studied Automotive Engineering at the Uni-versity of Applied Sciences at Esslingen. He has been employed at Robert Bosch GmbH since 2002, where he works as a development engineer in the Airbag area, specializing in the areas of Test Automation and Test Tooling.Tel. +49-711/811-20939 E-mail: [email protected]

David Oberschmidt (Dipl.-Ing.) studied Physics at the KTH Stockholm. Since 2002 he has been employed at Robert Bosch GmbH (in the Airbags area until 2006, and since then as technical project leader for ESP application projects in France).E-mail: [email protected]

Dr. (rer. nat.) Martin C. Geisler studied Physics at the Ruhr University at Bochum, Germany, and at the University of Sussex, England. He has worked at the Riken Research Institute in Saitama, Japan, and he earned his doctorate degree at the Max-Planck-Institute for Solid State Research in Stuttgart. Since 2005, he has been employed at Robert Bosch GmbH as sub-project leader and later as team leader for software valida-tion in the Airbag area.Tel. +49-711/811-24324 E-mail: [email protected]

Katja Hahmann (Dipl.-Ing.) studied Electrical Engineering at the Techni-cal University of Chemnitz. Since 1997 she has been employed at Vector Informatik GmbH in Stuttgart where she is group man-ager for CANoe application development in the Networks and Distributed Systems product line.Tel. +49-711/80670-459E-mail: [email protected]

20 Press Book_Seite_2-28_2-31.indd 520 Press Book_Seite_2-28_2-31.indd 5 09.02.2010 13:24:38 Uhr09.02.2010 13:24:38 Uhr

Page 106: Vector Press Book

Ve hi cle Di ag nos tics – The whole Sto ry

3/0

20 years of au to mo tive net work ing and di ag nos ticsThe fast growth of elec tron ic func tions in ve hi cles dur ing the sec -

ond half of the 1980s at first led to many in su lar so lu tions that pre -

vent ed com pre hen sive con cepts from tak ing hold in the ar ea of

elec tri cal/elec tron ic ar chi tec tures. At the be gin ning of the 1990s a

con sol i da tion phase be gan that was marked by de vel op ment of

elec tri cal/elec tron ic struc tures and as so ci at ed net work ing to pol o -

gy from a com pre hen sive per spec tive. This meant that elec tri -

cal/elec tron ic con tent and its net work ing could claim an un dis put -

ed po si tion in the ve hi cle. The rec og ni tion that many func tions

could on ly be im ple ment ed sen si bly with the help of elec tron ics al -

so pre vailed. So the im age of elec tron ics trans formed from be ing a

nec es sa ry evil to be ing a key to new, in ter est ing and in no va tive

func tions. The three bus nodes in com mer cial ve hi cles in 1989 have

be come more than 70 to day in sim i lar ly equipped ve hi cles; see Fig -

ure 1. The un der ly ing soft ware amounts to about 10 mil lion lines of

pro gram ming code.

This trend has not been with out con se quen ces for di ag nos tics ei -

ther. Twen ty years ago the di ag nos tic ca pa bil i ty of a func tion was

not even con sid ered un til short ly be fore pro duc tion star tup. To day

ba sic di ag nos tic func tions usu al ly ex ist as ear ly as in the B-Sam ple.

Han dling of di ag nos tics has im proved sig nif i cant ly. In the times of

flash codes the proc ess re quired that us ers te di ous ly count the

num ber of flash es and con vert them to er ror codes based on print -

ed-out ta bles. To day test ers out put in struc tions in clear text.

In the past it was pos si ble to do with out tool sup port en tire ly. To -

day pow er ful di ag nos tic tools are an ev ery day re al i ty. It is pos si ble

to cre ate the di ag nos tic spec i fi ca tion, gen er ate ECU-spe cif ic code

and pa ram e ter ize the di ag nos tic test er util iz ing the “sin gle source

prin ci ple”. A pre con di tion is that spec i fi ca tion of di ag nos tics must

be shift ed to the be gin ning of the de vel op ment proc ess (Front load -

ing); see Fig ure 2. The ODX for mat al so en a bles cross-OEM ex change

of di ag nos tic da ta.

The de vel op ment and in tro duc tion of new di ag nos tic con -cepts and di ag nos tic so lu tions of fer sig nif i cant po ten tialto au to mo tive OEMs and sup pli ers for re al iz ing ef fi cien cygains and qual i ty im prove ment. Grow ing com plex i ty in au to mo tive elec tron ics can on ly be mas tered – tech ni cal lyand eco nom i cal ly – by use of non pro pri e tary stand ardssuch as ODX, close co op er a tion and pow er ful tools. Thisar ti cle of fers an over view of top ics rel e vant to the past,present and fu ture of au to mo tive di ag nos tics as pre sent -ed and dis cussed in Oc to ber 2006 be fore an au di ence of350 par tic i pants at the Vec tor Con gress in Stutt gart.

Ef fi cien cy gains by stand ard i za tion and the use of tool-sup port ed proc ess es indi ag nos tic de vel op ment

Fig ure 1:De vel op ment of elec tron ic net -work ing based on the ex am ple ofthe E-Class mod el se ries W210(1995) and W211 (2002).

21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 1

Page 107: Vector Press Book

3/1

From pro pri e tary di ag nos tic tool to stand ard tool chainThe de vel op ing trend of di ag nos tic tools is sim i lar to the trend of

elec tron ics in the ve hi cle. Back in 1990 au to mo tive OEMs cre at ed

their own tools in-house. Spe cial ists in dif fer ent de part ments cus -

tom ized their tools pre cise ly to their re quire ments and spe cif ic ap -

pli ca tions. This pro duced in di vid u al in-house so lu tions with in each

OEM and even for dif fer ent proc ess steps.

About 1995 au to mo tive OEMs came around to a new way of think -

ing, i.e. that they want ed to once again fo cus more on their core

busi ness. Ac cord ing ly, tool de vel op ment was out sourced to ex ter -

nal serv ice pro vid ers. In i tial ly, these out sour cers pro duced spe cial

in-house so lu tions as well, but they suc ceed ed in re duc ing the dif -

fer en ces be tween tools and stand ard iz ing ex ist ing so lu tions with in

cer tain lim its. This trend con tin ued un til open, non pro pri e tary di -

ag nos tic tools be came avail a ble on the mar ket in the year 2000. For

us ers, the route of prod uct li cens es is no tice a bly more cost-ef fect -

ive than as sum ing re spon si bil i ty for de vel op ing and main tain ing

pro pri e tary tools in-house. More over, there are shared ben e fits due

to syn er gis tic ef fects of the com bined ex pe ri ence of oth er mar ket

par tic i pants. In 2005 the tools be gan to sup port gen er al stand ards.

Con tem po ra ry tools of fer stand ard ized in ter fa ces that can be

seam less ly in te grat ed in to ex ist ing tool chains.

Old and new stand ards for di ag nos ticsStand ards cur rent ly in the spot light in clude the di ag nos tic da ta

mod el per ISO 22901-1 ODX (Open Di ag nos tic Da ta Ex change, AS AM

MCD-2D), the hard ware in ter face per ISO 22900-2 (D-PDU API) and

the in ter face be tween the run time sys tem and the test ap pli ca tion

per ISO 22900-3 (AS AM MCD-3D, D-Serv er API). Each of the pro -

gram ming in ter fa ces men tioned are avail a ble to the us er as soft -

ware li brar ies. Al so wor thy of men tion are the di ag nos tic-rel e vant

stand ards per SAE J2534 and in the con text of AU TO SAR stand ard i -

za tion AU TO SAR WP4.2.2.1.4 (DCM, DEM). Fur ther more, the UDS di -

ag nos tic pro to col per ISO 14229-1 (Uni fied Di ag nos tic Serv i ces on

CAN) will grad u al ly re place old er pro to cols such as the K-Line per

ISO 9141-2 and “KWP2000” as well as “KWP2000 on CAN”; see Fig -

ure 3.

Char ac ter is tics of mod ern di ag nos tic so lu tionsThe de vel op ment of com pre hen sive, ho mo ge ne ous di ag nos tic so lu -

tions is a chal lenge. It re quires stud ies and ef forts on many dif fer -

ent lev els, in or der to sat is fy all re quire ments un der one roof. On

the one hand, this in volves ra tion al ly cre at ing pow er ful di ag nos tic

sys tems and on the oth er hand de vel op ing a us er-friend ly ap -

proach. It is on ly pos si ble to re al ize these two goals with a uni ver -

sal, com plete and prac ti cal di ag nos tic tool chain. So lu tions must be

spec i fied, im ple ment ed and doc u ment ed for both the over all ve hi -

cle di ag nos tic sys tem and di ag nos tics for spe cif ic ECUs. Fur ther -

more, con sist ent man age ment and dis tri bu tion of di ag nos tic da ta

must be as sured. That is be cause the ap pli ca tions of di ag nos tic so -

lu tions range from the de vel op ment proc ess with its many dif fer ent

ar e as of fo cus, to qual i ty as sur ance in pro duc tion and fi nal ly di ag -

nos tics in the serv ice ga rage.

Fig ure 2:Di ag nos tic tool chain based onsin gle-source prin ci ple util iz ingstand ard ized ex change for mats.

21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 2

Page 108: Vector Press Book

the stand ard i za tion com mit tee. For sup pli ers, for ex am ple, it is cru -

cial that they be ca pa ble of han dling pro jects for dif fer ent au to mo -

tive OEMs with one and the same di ag nos tic tool. And to ac com plish

a gen tle mi gra tion from the ex ist ing so lu tion to the stand ard ized

di ag nos tic sys tem, spe cial tem po rary meas ures are of ten nec es sa ry

dur ing a tran si tion time. In the in tro duc to ry phase for new stand -

ards it is im por tant to sup port mul ti ple par al lel ver sions in a con -

sist ent way.

Open ness for progress and in no va tionEven if stand ard i za tion and in no va tion seem to be two ir rec on cil a -

ble goals at first glance, au to mo tive elec tron ics is char ac ter ized by

con tin u al de vel op ment. Progress is one of the most im por tant key

per form ance in di ca tors for au to mo tive OEMs and sup pli ers. There -

fore ex pand a bil i ty of cur rent ly used tool chains is al ways in de -

mand, so that in no va tions and func tion al i ties of fu ture stand ards

can be util ized or test ed in ad vance.

Enough ideas and tasks still re main to en sure that in the fu ture au -

to mo tive elec tron ics, net work ing and di ag nos tics will con tin ue to

im prove on the achieve ments of the last 20 years and adapt them to

new re quire ments. It must be as sumed that the pace of in no va tion

will ac cel er ate even more, and even clos er col lab o ra tion will be

nec es sa ry be tween au to mo tive OEMs, sup pli ers and tool pro duc ers.

This al so per tains to a com mon ap proach in deal ings with leg is la -

tive bod ies.

The above-named stand ards serve as a foun da tion and build ing

blocks for im ple men ta tion of such com pre hen sive di ag nos tic sys -

tems. They ben e fit in di vid u al mar ket par tic i pants with out re strain -

ing nat u ral com pe ti tion. Be sides achiev ing cost re duc tion, stand -

ard i za tion brings the us er ad di tion al ad van ta ges such as in ter -

change a bil i ty of pro ducts, com po nents and da ta. It can be ex pect -

ed that even more stand ards will be cre at ed in the fu ture, which in

turn will af fect the tools used.

Prac ti cal ca pa bil i ties are trumpIn in tro duc ing mod ern di ag nos tic tools, fo cus on the needs of us ers

is of fun da men tal im por tance for their ac cept ance. The us er should

not be con front ed with the full com plex i ty of the stand ards. Rath er

it makes sense to present a di ag nos ti cal ly-driv en per spec tive of the

da ta to the us er. Spe cial knowl edge of the un der ly ing da ta for mat

should not be nec es sa ry. It is al so im por tant to op ti mize typ i cal re -

cur ring work steps by guid ing the us er in per form ing the nec es sa ry

tasks cor rect ly, con sist ent ly and with time sav ings. In par tic u lar

this in cludes avoid ing re dun dant proc ess es and wher ev er pos si ble

re us ing al ready ex ist ing da ta ma te ri al.

Flex i bil i ty in han dling cus tom er-spe cif ic fea turesIn all of the ef forts to achieve uni form i ty and stand ard i za tion in

cre at ing pow er ful tools, it is im por tant not to lose sight of flex i bil i -

ty. Cur rent di ag nos tic stand ards of fer a cer tain de gree of lat i tude

that can be ex ploit ed to ad dress sup ple men tal re quire ments not

cov ered by the stand ard. These in clude cus tom er-spe cif ic fea tures

and con ven tions or spe cial wish es not sup port ed by the ma jor i ty of

3/2

Fig ure 3:The most im por tant ap plied net -work ing and di ag nos tic tech nol -o gies over the past 15 years.

21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 3

Page 109: Vector Press Book

VE HI CLE DI AG NOS TICS – THE WHOLE STO RY

3/3

Uni ver sal and au to mat ic tool chainSim i lar ly, there is much fu ture po ten tial for di ag nos tics, now that it

has suc ceed ed in qua si evolv ing from a “mi nor ap pend age to func -

tions” to a “func tion in its own right”. This sig ni fies the step from

si mul ta ne ous de vel op ment to in te grat ed de vel op ment, which re -

sults in even clos er co op er a tion be tween di ag nos tic and func tion al

de vel op ers. For the di ag nos tic sys tem a mod el-based ap proach al so

came to fru i tion, which ap plies knowl edge ac quired from FMEA

(Fail ure Mode and Ef fects Anal y sis) for ex am ple. Tools like Da Vin ci

and CAN de laS tu dio from the Vec tor In for ma tik com pa ny, IQ-FMEA

and Mat lab/Sim u link en a ble di ag nos tic de sign strat e gies util iz ing a

uni ver sal and au to mat ed tool chain, from mod el ing tool to au thor -

ing sys tem.

Di ag nos tic de vel op ments at Daim ler Chrys lerDaim ler Chrys ler AG and Vec tor In for ma tik GmbH have ex pand ed

their close co op er a tion over the past sev er al years, in clud ing in the

ar ea of di ag nos tic tools. Easy and con ve nient use of tools and de -

scrip tion of all di ag nos ti cal ly-rel e vant da ta in a uni form for mat are

im por tant prin ci ples of their joint pro jects. Da ta and di ag nos tic

func tions are on ly for mal ly spec i fied once in the so lu tions, which

are based on the “sin gle-source prin ci ple”. There fore they are uni -

ver sal ly avail a ble to all project par tic i pants and sup pli ers in ma -

chine-read a ble XML de scrip tion files; see Fig ure 2.

In CAN dela (CAN di ag nos tic en vi ron ment for lean ap pli ca tions)

Vec tor In for ma tik struc tured its di ag nos tic prod uct line-up with

suf fi cient flex i bil i ty so that OEM-spe cif ic ex port for mats could be

in te grat ed. DI O GENES, the Daim ler Chrys ler-spe cif ic de scrip tion da -

ta for mat, is al so au to mat i cal ly gen er at ed and is then proc essed by

the uni form di ag nos tic run time sys tem. The re quire ments and ex -

pe ri en ces of oth er co op er a tion part ners such as OPEL/GM and ag ri -

cul tur al ma chine pro duc er CLAAS have had sig nif i cant in flu en ces

on the CAN dela ap proach too. In the mean time Vec tor has al so been

work ing to geth er with com pa nies such as Fi at, Ford and nu mer ous

au to mo tive sup pli ers world wide.

Han dling spe cial project-spe cif ic fea tures with tem platesIn for mal di ag nos tic de scrip tion tem plates, or just tem plates, are

im por tant serv i ces for tak ing in to con sid er a tion spe cif ic re quire -

ments of the man u fac tur er, project and ve hi cle mod el. Ful ly spec i fy -

ing di ag nos tics at a very ear ly time pre vents most mis un der stand -

ings, er rors and it er a tive op ti mi za tion loops in the di ag nos tic de -

vel op ment proc ess. The use of CAN dela is firm ly es tab lished in the

de vel op ment proc ess at Daim ler Chrys ler. ECU sup pli ers not on ly de -

vel op the di ag nos tic func tions in the ECU; they al so sup ply the as -

so ci at ed for mal de scrip tions. Of ten stand ard soft ware com po nents

are used to im ple ment di ag nos tics in the ECU. The di ag nos tic com -

po nent CAN desc (CAN di ag nos tic em bed ded soft ware com po nent)

can be au to mat i cal ly gen er at ed from the CAN dela da ta; see Fig ure

2. This gives ECU and ve hi cle pro duc ers a way to achieve uni form

im ple men ta tion of the di ag nos tic pro to col across all pro ducts.

ODX ex change for mat and UDS di ag nos tic pro to colThe in ter na tion al stand ard ODX (Open Di ag nos tic Da ta Ex change)

serves as the stand ard for ex chang ing da ta and near ly all di ag nos -

Fig ure 4:Com plex bus net work ing in the LEX IONcom bine har vest er.

21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 4

Page 110: Vector Press Book

In its di ag nos tic de vel op ment proc ess CLAAS runs through the V-

Mod el with the CAN dela tool chain. CAN de laS tu dio is used to cre ate

the spec i fi ca tion of di ag nos tic func tion al i ty con sist ent ly. The cap -

tured da ta are used di rect ly to gen er ate the ECU-spe cif ic di ag nos tic

soft ware com po nent with CAN desc. To pa ram e ter ize the test er

CLAAS util iz es ODX da ta ex port ed by CAN de laS tu dio, Fig ure 5.

For a half year now CLAAS has al so been us ing CA Noe Op tion Di Va

(Di ag nos tic In te gra tion and Val i da tion As sist ant). Di Va makes it

pos si ble to au to mat i cal ly gen er ate and ex e cute re pro duc i ble test

cas es for im ple men ta tion and in te gra tion of the di ag nos tic pro to -

col. Serv ing as re quire ments are in ter nal CLAAS test spec i fi ca tions

and the di ag nos tic da ta base. Suit a bly con fig ured, Di Va per mits test

sce nar i os of var y ing depth and in ten si ty, e.g. com pre hen sive tests

or just tests of spe cif ic serv i ces. The pro gram out puts de tailed

HTML test re ports for er ror anal y sis pur pos es. In the fu ture, au to -

mat ed test ing with CA Noe Op tion Di Va will be used for all CLAAS

ECUs.

Joint di ag nos tic project by Daim ler Chrys ler and Volk swag enA joint project point ing the way to the fu ture and si mul ta ne ous ly

serv ing as a test case for new di ag nos tic stand ards and ex change

for mats was the joint de vel op ment of the new trans port er gen er a -

tion “Sprint er” and “Craft er” by Daim ler Chrys ler AG and Volk swag en

AG. The project ex e cut ed un der the name “Phoe nix” start ed in the

year 2003 and reached its in ter im con clu sion in mid-2006. Tech ni -

cal ly, the Sprint er and Craft er ve hi cles are for the most part iden ti -

cal and will be pro duced in var i ous body con fig u ra tions, weight

class es and equip ment var i ants at Daim ler Chrys ler plants in Lud -

tic in for ma tion be tween in di vid u al tools, as well as be tween au to -

mo tive OEMs and sup pli ers. It is be ing de vel oped with in the AS AM

stand ard i za tion body (As so ci a tion for Stand ard i za tion of Au to ma -

tion and Meas ur ing Sys tems) and is ex pect ed to be re leased as ISO

stand ard 22901-1 in 2007. Daim ler Chrys ler plans to re place its own

DI O GENES for mat by ODX on fu ture pro jects.

The CAN dela ap proach han dles im port and ex port of ODX da ta and

en a bles a smooth tran si tion from pro pri e tary for mats to the stand -

ard ized ex change for mat for sup pli ers. More over, the Vec tor Tools

CA Noe, CA Na pe, CAN di to and CAN de laS tu dio sup port the new UDS

di ag nos tic pro to col (ISO 14229), which Daim ler Chrys ler is in tro duc -

ing in all of its cor po rate di vi sions on each suc ces sive mod el change

be gin ning with the cur rent C-Class where it will re place the pre vi ous

KWP2000 pro to col. Daim ler Chrys ler is re ly ing on the stand ard ODX-F

for mat for de scrib ing the flash da ta too. This is done with the flash

da ta man age ment tool CAN de la Flash from the CAN dela prod uct line.

Au to mat ing tests at har vest ing ma chine pro duc er CLAASAt Eu ro pe’s lead ing pro duc er of har vest ing ma chines, CLAAS, ef fi -

cient de vel op ment of di ag nos tic sys tems plays a key role. In a com -

bine har vest er there are up to four high ly com plex bus sys tems op -

ti mized for ag ri cul tur al tasks; see Fig ure 4.

The chal len ges fac ing the ag ri cul tur al ve hi cle di ag nos tic sys tem are

enor mous: 350 con nect ors with 3,000 elec tri cal con tacts, 3,000 m

of cop per lines, up to 25 ECUs or CAN nodes and nu mer ous op to-

elec tron ic ma chine guards, po ten ti om e ters, valves, ser vo-drives

and speed sen sors must all op er ate prop er ly and work to geth er.

3/4

Fig ure 5:Di ag nos tic de vel op ment at CLAAS by theV-Mod el us ing the CAN dela tool chain.

21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 5

Page 111: Vector Press Book

VE HI CLE DI AG NOS TICS – THE WHOLE STO RY

3/5

wigs fel de and Düs sel dorf. Be sides dif fer en ces in body de sign, oth er

key dif fer en ces lie in each ve hi cle’s brand-spe cif ic pow er train.

The in i tial idea for a di ag nos tic con cept was to “trans late”, so to

speak, the Sprint er di ag nos tic da ta from Daim ler Chrys ler to VW via

a cen tral ECU in the Craft er. This would have made it pos si ble to

omit ad ap ta tion to the VW serv ice test er, since to a cer tain ex tent it

speaks a dif fer ent lan guage due to in com pat i ble di ag nos tic phil os -

o phies. How e ver, this strat e gy was re ject ed in fa vor of mod i fy ing

the serv ice test er and ex chang ing di ag nos tic da ta by ODX. Stat ed in

some what sim pli fied form, an ODX con vert er now proc ess es the ODX

di ag nos tic da ta gen er at ed by CAN dela and us es them to pre pare the

ODX da ta for VW, Fig ure 6. Ex ist ing com po nents of the VW serv ice

test er are not re placed, rath er they are sup ple ment ed by oth er

func tions need ed for a mi gra tion.

ODX: Trials passed suc cess ful lyIn this first joint di ag nos tic project the par tic i pat ing au to mo tive

OEMs were able to ac quire val u a ble ex pe ri ence, even though they

were con front ed with dif fi cult con straints. It was nec es sa ry to deal

with fun da men tal ly dif fer ent di ag nos tic phil os o phies in volv ing dif -

fer ent lan gua ges for cod ing, pa ram e ter i za tion and con trol. Fur -

ther more, all com po nents con tained in the di ag nos tic de vel op ment

proc ess, such as ex port to ODX and the ODX stand ard, were still just

in the de vel op ment stage. Nu mer ous in ter nal de part ments and ex -

ter nal sup pli ers were in volved, there was as yet no prac ti cal ex pe ri -

ence with the new ODX stand ard, and a tight sched ule had to be

main tained. In the Phoe nix project the per form ance of the ODX

stand ard was put to the test in a chal leng ing large project and it

passed suc cess ful ly.

Fu ture vi sions: Where does the road lead?With re lent less progress in stand ard i za tion many things are sim pli -

fied, and it is pos si ble to come to grips with new chal len ges. As ev -

er, nat u ral com pe ti tion will gen er ate a great deal of dy na mism in

fu ture de vel op ment. Of course, it is im pos si ble to pre dict ex act ly

what ef fects this will have on ve hi cle elec tron ics and di ag nos tic

sys tems of the fu ture. How e ver it can be stat ed with cer tain ty that

the sig nif i cance of In ter net tech nol o gies will con tin ue to grow, as

is al so the case in many oth er tech no log i cal ar e as. For ex am ple,

“Di ag nos tics-over-IP” is con ceiv a ble. In i tial stud ies with Ether net

and TCP/IP are al ready un der way in con junc tion with Flex Ray gate -

ways. If ve hi cles take on the po si tion and func tion al i ty of a HTTP

serv er from an in for ma tion tech nol o gy per spec tive, gen er al iden ti -

fi ca tion via IP ad dress es might make sense, for ex am ple, and this

would make Ve hi cle Iden ti fi ca tion Num bers su per flu ous. Stand ard i -

za tion will con tin ue to ad vance in test mod ules and test pro ce -

dures, and re-use in de vel op ment, pro duc tion and the serv ice ga -

rage will be come com mon place. Sim i lar ly, er ror mes sa ges in clear

text will be come avail a ble on PCs and Web Brows ers. Pre req ui sites

Fig ure 6: Cross-OEM ex change of di ag nos tic da tabe tween Daim ler Chrys ler and VW basedon ODX.

21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 6

Page 112: Vector Press Book

for this are di ag nos tic de sign con cepts with uni ver sal and au to mat -

ic tool chains that can gen er ate di ag nos tic da ta for all com po nents,

from the mod el ing tool to the au thor ing sys tem. Vec tor will help to

drive sus tained de vel op ment of these in no va tive con cepts.

Lit er a ture: [1] Kühn er, T.: “20 years of ve hi cle net work ing and di ag nos tics – What do we

an tic i pate in the fu ture?”, Vec tor Con gress 2006[2] Schling mann, N.: “Spec i fi ca tion – Cod ing – Test: De vel op ment of di ag -

nos tic soft ware”, Vec tor Con gress 2006[3] Jo han son, D.: “In tro duc ing ODX di ag nos tics in a OEM joint ven ture pro-

ject”, Vec tor Con gress 2006[4] Rätz, C.: “What is the mar ket de mand for di ag nos tic so lu tions?”, Vec tor

Con gress 2006[5] Stimm ler, S. and Rätz, C.: “On a sol id ba sis – Ef fi cient de vel op ment of di -

ag nos tic func tions in the au to mo bile”, Au to mo tive Elec tron ics 2/2005

3/6

Hel mut Frank (Grad u ate En gi neer)is a Busi ness De vel op -ment Man a ger at Vec tor In for ma tik re spon si -ble for the Di ag nos tics prod uct line.

Uwe Schmidts (Grad u ate En gi neer) is a Mar ket ing Co or di na -tor at Vec tor In for ma tik whose re spon si bil i -ties in clude the Di ag nos tics prod uct line.

21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 7

Page 113: Vector Press Book

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. 07 11 / 8 06 70-0

www.vector.com

Vehicle Diagnostics

Diagnostics

Calibration

ECU

Distr. Systems

Deve

lopm

ent

Software

ECU

Management

Proc

ess

Increase your Development

In diagnostic development, benefit from solutions that span the

entire development process. Increase your efficiency and improve

your quality by using optimally tuned and coordinated tools.

The CANdela product family supports you by:

> Frontloading – early high-quality specification of diagnostic

requirements at the beginning of the development process

> Single source principle – Re-use of created diagnostic data in

all process steps

> Automated code generation, validation and test

> Diagnostic tester ideally configured for your area of application

> Open interfaces and data exchange, e.g. via ODX

Vector diagnostic tools help you to reduce the effort required in specification and data supply tasks by a factor of up to 7*. In automated validation, improvements by a factor of 4 to 20* are possible – depending on the project phase. The bottom line is that you realize a maximum level of quality with a maximum level of economic efficiency.

For more information: www.car-diagnostics.com/efficiency/

*Sources: Leading automotive OEMs and suppliers

ECU

21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 8

Page 114: Vector Press Book

3/8

Automatic validation of diagnostic services by use of a diagnostic integration and validation assistant

Introduction

One consequence of strong competition in the global automotive

market is that it is forcing a shortening of development cycles.

Another is that the complexity of the electronic networking archi-

tecture is continually increasing. Key goals in replacing conven-

tional systems by electronically controlled systems relate to cost

reductions, a high level of safety and reliability as well as better

manageability. Despite all of the benefits, it must not be forgotten

that increased numbers of electronic components in vehicles can

increase the probability of electronics-related faults. Since reliabil-

ity is an important criterion for customers when purchasing a new

vehicle, it is essential to introduce new methods that enable

mastery of this complexity, accelerate the development process

and guarantee proper operation of the installed ECUs. Particularly

in the area of diagnostic functionality provided by the ECU, it is

crucial that diagnostic services are correct. They transport informa-

tion that helps mechanics in the service garage to quickly deter-

mine the cause of a fault and correct it. This information must make

it possible for the mechanic to decide which component is the

source of the problem and what needs to be replaced to restore full

operational readiness. If this is not assured, the result may be erro-

neous replacement of properly operating units [1], which causes a

rise in warranty costs and a decline in customer satisfaction.

The E/E architecture of the Opel Insignia consists of several Con-

troller Area Network (CAN) and Local Interconnect Network (LIN)

For the first time, a fully automated test case generator has been introduced in diagnostics validation at General Motors Europe (GME) Development. This article describes the introduction of this automated testing of diagnostic implementa-tions based on the example of the new Opel Insignia. An electronically readable diagnostic specification forms the basis for test generation. The article describes how the tool used – CANoe.DiVa (Diagnostic Integration and Validation Assistant) from Vector Informatik – was integrated in the existing tool environment, and it addresses cost and time savings as well as improvements to technical processes that were realized compared to conventional, manual validation at the Opel Corsa.

22 Press Book_Seite_3-08_3-15.indd 222 Press Book_Seite_3-08_3-15.indd 2 09.02.2010 13:26:37 Uhr09.02.2010 13:26:37 Uhr

Page 115: Vector Press Book

3/9

Validation process and tool environment at General Motors Europe

In development of the Opel Insignia, GME introduced the DiVa tool

from Vector Informatik for the first time. DiVa automates genera-

tion and execution of diagnostic tests.

Figure 2 shows the tool environments for the Opel Corsa and

Opel Insignia. In both cases, CANoe [5] is used as a test tool. While

validation is largely performed manually in development of the

Corsa, in development of the Insignia the vast majority of testing is

covered by fully automated tests.

Figure 3 shows a typical diagnostic validation process for an ECU

performed by a test engineer at GME. Development of the ECU soft-

ware is subdivided into several phases. At the beginning of an ECU

development, the focus is more on implementation of ECU func-

tionality than on diagnostic services. The latter are then elaborated

and developed in subsequent software versions. As shown in Fig-ure 3, with introduction of the Phase 1 (SWR 1) software version,

only a small number of diagnostic services are implemented. The

use of diagnostic software components at GME (CANdesc) has made

it possible to implement a portion of the diagnostic content early

at the start of development, and as a result it is integrated in the

ECU earlier (Figure 3).

The number of diagnostic functions to be tested grows with each

development cycle. Once all diagnostic services have been imple-

mented, regression tests are performed (SWR 7). If no more faults

are reported in diagnostic services at that development stage, the

ECU is production mature in the execution of diagnostic services.

bus systems [2, 3]. All bus systems are accessed via a central diag-

nostic port (DLC), see Figure 1. Communication is defined by a GM-

specific protocol. This GM diagnostic specification is based on

KWP2000 [4] and the CAN 2.0A standard. It contains all diagnostic

services allowed for addressing an ECU’s diagnostic system to

obtain diagnostic information. These services are then output by

the diagnostic tester to establish diagnostic communication. As

soon as a request is sent, the addressed ECU(s) react with either a

positive or negative response:

Positive responses contain the diagnostic information requested >

by the diagnostic device. If there is a lot of diagnostic informa-

tion, the response may include multiple message frames.

Negative responses contain a clearly defined Negative Response >

Code, which gives information indicating the reason for the neg-

ative response. Negative Response Codes are given in accordance

with the GM Diagnostic Specification.

The received responses must enable technicians to determine the

cause for a fault, so that they can perform the right tasks to solve

the problem.

Therefore, the success of a fault correction in the service garage

depends considerably on the accuracy and precision of the data

output by the diagnostic system. Proper implementation of diag-

nostic services is essential in performing quick and professional

service or maintenance to the satisfaction of customers. Diagnos-

tics also plays an important role in end-of-line testing: it is used to

program ECUs and assure product quality. That is why comprehen-

sive validation of diagnostic functionality is absolutely necessary.

Figure 1: E/E architecture and diagnostic communication on the Opel Insignia

22 Press Book_Seite_3-08_3-15.indd 322 Press Book_Seite_3-08_3-15.indd 3 09.02.2010 13:26:37 Uhr09.02.2010 13:26:37 Uhr

Page 116: Vector Press Book

3/10

From specification to test execution and report evaluation

As shown in Figure 2, DiVa represents the link between

CANdelaStudio (diagnostic specification) and the proven validation

tool (CANoe). DiVa can be seamlessly integrated in the existing and

established GME tool chain. Test cases for checking the individual

services are automatically derived from the CANdela diagnostic

specification (CDD file). The generated code is based on the CANoe

programming language CAPL (Communication Access Programming

Language) and can therefore be examined at any time. If problems

occur, the test engineer can intervene in the automated test

sequence and troubleshoot their causes (transparency). Further-

more, CANoe’s logging functions enable traceability and evaluation

of the diagnostic data flow on the CAN communication level.

The following steps are necessary to conduct a test with DiVa:

Select the ECU and its variant >

Configure the test >

Generate the test >

Add the generated test module to the CANoe test environment >

Execute the tests >

Evaluate the test report >

The user can modify test constraints in DiVa at any time. Among

other things, the “Intensity” parameter is used to configure the

test contents, e.g. “full test”, “quick test” or “good case test”. In

addition, under “Supported services” the user can exclude certain

services from the test or modify data contents of the services under

“Data customization” (see Figure 4).

Since a test engineer normally tests a number of different ECUs

simultaneously, without adequate tool support it is impossible for

the engineer to perform the large number of tests necessary to

cover all of the implemented diagnostic services of the individual

software versions. As a result, only newly implemented diagnostic

services are tested in-depth, and test engineers perform represen-

tative regression tests for previously integrated individual services

based on their experience. By using a suitable automation tool,

more tests may be performed in validation while simultaneously

reducing effort.

Requirements for the validation tool

A tool for automated diagnostic validation must satisfy the follow-

ing requirements:

Seamless integration in the existing tool chain >

Transparency and reproducibility: The test engineer must be able >

to track the executed tests and repeat them.

Conformity to existing testing methods at General Motors: The >

tool must support existing test methods. In the diagnostic area,

the GM Diagnostic Specification already defines mandatory test

procedures for GMLAN Diagnostic Services of the ECUs.

Expandability by the test engineer >

Automatic generation of test cases: The specification must exist >

in a machine-readable format to enable this.

Figure 2: Comparison of diagnostic validation and tool environment on the Opel Corsa and Opel Insignia

22 Press Book_Seite_3-08_3-15.indd 422 Press Book_Seite_3-08_3-15.indd 4 09.02.2010 13:26:38 Uhr09.02.2010 13:26:38 Uhr

Page 117: Vector Press Book

3/11

Test coverage

Automating the tests extends test coverage and simultaneously

shortens the time needed for test execution. The extent to which

DiVa covers the test procedures described in the GM Diagnostic

Specification is described below. The quality and number of gener-

ated test cases depend in large part on the completeness of the

machine-readable diagnostic specification (CDD file). All generated

tests are derived from it.

A total of about 350 test sequences are defined in the GM Diag-

nostic Specification. The test sequences cover both “good case” and

“bad case” tests. A large share (approx. 80 %) of the test procedures

are covered by fully automated tests in DiVa. An application-specific

user input is required for 45 (15 %) of the test procedures defined in

the GM Diagnostic Specification. In such cases, DiVa pauses test

execution and asks the user to put the ECU in the required state.

The remaining 5 % of test procedures are not supported by DiVa and

must be tested either manually or by other means. This includes

tests that would put the rest of the test procedure at risk (e.g. gen-

erate EEPROM errors and detect them) or would cause long-term

changes to the ECU (e.g. an ECU without calibration data).

Testing depth is further enhanced by including execution of

additional non-GM-specific test cases.

In updating the diagnostic specification, i.e. the CDD file, DiVa

enables synchronization to the new specification while preserving

previously defined settings. From a technical perspective, DiVa gen-

erates CAPL code for the CANoe test module in order to test all diag-

nostic services supported by the ECU. To assure conformity to the GM

diagnostic specification, the DiVa extension maps the test proce-

dures of the GM standard. The test generation process produces a

detailed description of the generated test cases, CAPL test codes for

the CANoe test module and the associated CANoe test environment.

Test execution and report evaluation

After the test has been generated, the user opens the generated

test environment in CANoe and starts the test. The test duration

depends on the complexity of the diagnostic specification and the

user-defined test scope that is selected, and it may vary from just a

few minutes to several hours (Table 1). At General Motors, the

CANoe test environment serves as a joint platform for test automa-

tion and simplifies reuse of existing GM test programs. For exam-

ple, end-of-line flash test procedures are also programmed in the

CANoe programming language CAPL. To simplify analysis by the test

engineer, test reports are structured according to the GM diagnos-

tic specification. Figure 5 shows a typical test report.

AUTOMATIC VALIDATION OF DIAGNOSTIC SERVICES BY USE OF A DIAGNOSTIC INTEGRATION AND VALIDATION ASSISTANT

Figure 3: Scope of diagnos-tic functions in various phases of ECU development at GME

Table 1: Test execution times for Opel Insignia ECUs

22 Press Book_Seite_3-08_3-15.indd 522 Press Book_Seite_3-08_3-15.indd 5 09.02.2010 13:26:38 Uhr09.02.2010 13:26:38 Uhr

Page 118: Vector Press Book

3/12

By using DiVa, execution and evaluation times were shortened

considerably on the Opel Insignia compared to the Corsa. In the

studied case, 3- to 5-fold improvement was attained (Figure 6). In

particular, the time savings was enormous for ECUs with a large

number of diagnostic services. If one considers later development

phases such as SWR 6 or SWR 7, the time needed for evaluating test

results is reduced even further. This can be traced back to the

smaller number of failed test cases in the more mature implemen-

tation. This trend continues in each new phase up to the production

launch. The production ready ECU must not exhibit any defects;

consequently, the evaluation time is equal to the execution time.

In this stage of Opel Insignia development, depending on the com-

plexity of the ECU, efficiency might be increased by a factor of

20–40.

The cost of the new solution is low, since all that is needed are

licenses for DiVa. A user at GME who is familiar with CANoe can per-

form DiVa tests – without prior training. Additional hardware is not

required for test execution, since DiVa utilizes the available CAN

infrastructure via CANoe.

Limitations on automatic of test case generation and test execution

Even if automated tools are better than manual test strategies in

terms of test scope and time effort, automatic test generation does

run into limitations:

Quality of the specification: Since the specification represents >

the basis for generating test cases, completeness and accuracy

of the specifications are essential, i.e. a test is only as good as

its specification. Furthermore, there must be conformity to the

Comparisons made at GME between validation for the Opel Corsa

and for the Insignia conclude that DiVa shortens test execution

time enormously by predominantly automated execution of all gen-

erated test cases, Figure 6. Table 1 shows a summary of execution

times and the number of generated test cases for ECUs in the Opel

Insignia. Often, manual tests can only be performed sporadically

due to time demands. Therefore, test results largely depend on the

experience of the test engineer and the amount of time available.

At GME, DiVa enables both complete testing of ECUs per diagnostic

specifications and greater test coverage in all development stages.

Economic aspects and efficiency increases

When a tool is introduced, its economic benefit is a primary consid-

eration. The new Opel Corsa is very successful on the market, and

there are no negative reports of diagnostically-related electronic

problems. That is why the manually performed validation process

on the Opel Corsa was selected as a reference project. In contrast,

on the new Opel Insignia, DiVa was being used as the primary tool

for validation of diagnostic services. It was used to automate a

large share of validation tests for the first time. For comparison

purposes, the study evaluated the time required for test execution

and evaluation in the validation phase, based on representative

ECUs. The values given are based on implementation level SWR 5,

Figure 3. Most services have already been implemented at that

point, and a large number of failed test cases had already been

captured. Figure 6 shows validation effort in hours for manual

testing on the Opel Corsa and automated testing on the Opel

Insignia.

Figure 4: Setting test con-straints in DiVa (here: configura-tion of services)

22 Press Book_Seite_3-08_3-15.indd 622 Press Book_Seite_3-08_3-15.indd 6 09.02.2010 13:26:38 Uhr09.02.2010 13:26:38 Uhr

Page 119: Vector Press Book

3/13

AUTOMATIC VALIDATION OF DIAGNOSTIC SERVICES BY USE OF A DIAGNOSTIC INTEGRATION AND VALIDATION ASSISTANT

Figure 5: Automatically generated test report in DiVa

Figure 6: Test effort per ECU on the Opel Corsa with manual vali-dation, compared to automated vali-dation of diagnos-tic services on the Opel Insignia (execution and evaluation time)

22 Press Book_Seite_3-08_3-15.indd 722 Press Book_Seite_3-08_3-15.indd 7 09.02.2010 13:26:39 Uhr09.02.2010 13:26:39 Uhr

Page 120: Vector Press Book

3/14

requirements of the General Motors diagnostic infrastructure

(GGSE-I) [6]

Reproducibility: Due to the non-deterministic properties of CAN >

communication in a vehicle, certain error situations are very

difficult to reproduce in testing.

Secondary fault: In case of error, the automated test tool – in >

contrast to a test engineer – cannot distinguish between an

initial fault and a secondary fault.

User interaction: In application-specific tests it may be neces- >

sary to put the ECU in a state where additional hardware is

necessary. These cases cannot be handled fully automatically in

the approach described.

Summary

Without the use of test automation tools, it is hardly possible to

achieve the desired coverage in validation of the diagnostic func-

tionality of modern vehicles any longer. CANoe.DiVa from Vector

Informatik has been adapted to GM requirements to support all

established test processes, and it fits seamlessly in General Motors

Europe’s existing tool chain. It is used as an automated test tool

for validation of diagnostic services on the new Opel Insignia.

With DiVa, GME is not only shortening test duration, but is simul-

taneously increasing intensity of testing by its ability to perform

regression tests more frequently. Furthermore, the scope of test

coverage is extended by executing additional non-GM-specific test

cases. In direct comparison to manual validation on prior success-

ful projects, both technical and economical efficiency have been

increased significantly. Depending on the development phase and

quality of implementation, efficiency increases by a factor of 4 to

20 are realistic. At the same time, it is possible to satisfy the high

expectations of customers in terms of quality.

Literature references:[1] Thomas, D.; Ayers, K.; Pecht, M.: The “trouble not identified” phenome-

non in automotive electronics. In: Microelectronics reliability, Vol. 42, P. 641-651, 2002

[2] LIN Consortium: LIN Specification Package Revision 2.1, OV. 2006[3] Robert Bosch GmbH: CAN-Spezifikation 2.0, 1991[4] International Organization for Standardization: Keyword Protocol 2000,

ISO 14230, 1999 [5] Krauss, S.: Testing with CANoe, Application Note AN-IND-1-002. Vector

Informatik, 2005 [6] General Motors. GGSE ECU Diagnostic Infrastructure Requirements,

Version 1.07, 2007

Armin Timmerberg studied Electrical Engineering at the University of Applied Sciences at Wiesbaden. After his stud-ies, he was first employed as a systems engineer in the aftersales area at General Motors Europe. His primary job was to implement ECU diagnos-tics in the GM Service Tester TECH2. Since 2004, Mr. Timmerberg has been working as a develop-ment engineer in the “Global Systems Engineer-ing” group at General Motors Europe, where he is responsible for diagnostic validation.

Dr. Philipp Peti studied Computer Science at the Vienna Uni-versity of Technology. He earned his doctor-ate degree in Computer Science, also at TU Vienna. Dr. Peti is a development engineer in the “Global Systems Engineering” group at General Motors Europe, located in Rüsselsheim, Germany.

Thomas Pfeffer studied Electrical Engineering at the Darm-stadt University of Technology. Mr. Pfeffer is group manager for Diagnostics and Test Automation in the “Global Systems Engineer-ing” group at General Motors Europe, located in Rüsselsheim, Germany.

Simon Müller studied Software Technology at the Universi-ty of Stuttgart. As a product manager he is responsible for CANoe.DiVa on the Vehicle Diagnostics product line division at Vector Informatik GmbH in Stuttgart.

Christoph Rätz studied Computer Engineering at the Univer-sity of Cooperative Education at Stuttgart. He works at Vector Informatik GmbH in Stuttgart as a global product line manager for the Vehicle Diagnostics product line division.

22 Press Book_Seite_3-08_3-15.indd 822 Press Book_Seite_3-08_3-15.indd 8 09.02.2010 13:26:39 Uhr09.02.2010 13:26:39 Uhr

Page 121: Vector Press Book

Take advantage of automated test sequences in your integration tests.

Option DiVa for CANoe lets you automatically generate reproducible test

cases for various regression and release tests and then execute them.

You benefit from:

> Comprehensive test coverage in implementing diagnostics for an ECU

> Quick execution of test cases and generation of a clearly structured

test report

> Easy configuration of test contents

> Full integration in the Vector tool chain.

These features help you attain maximum efficiency and quality in integrating the diagnostic protocol in your ECUs.

More information: www.car-diagnostics.de/diva

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. 07 11 / 8 06 70-0

www.vector.com

Vehicle Diagnostics

Diagnostics

Calibration

ECU

Test

ECU

Distr. Systems

Deve

lopm

ent

Software

ECU

Management

Proc

ess

Automate Your Test Sequences in

Diagnostic Integration

22 Press Book_Seite_3-08_3-15.indd 922 Press Book_Seite_3-08_3-15.indd 9 09.02.2010 13:26:41 Uhr09.02.2010 13:26:41 Uhr

Page 122: Vector Press Book

3/16

A source code generator approach to implementing diagnostics in Vehicle ECUs

Introduction

It is common knowledge that the electronic content of automobiles

is increasing year by year. In order to take advantage of reusable

diagnostic software components, it is necessary to examine the

diagnostic software structure and identify the parts that are ECU-

independent and the parts that are ECU-specific. The ECU-indepen-

dent parts are reusable across different ECUs and can be written

once up front and deployed over multiple ECUs in multiple vehicle

programs that share common high-level diagnostic requirements.

The ECU-specific parts are not reusable across different ECUs in a

vehicle. This ECU-specific software will not fit the write-once-use-

many model of the ECU independent software, but it can still be

done in a more efficient way through a source code generation pro-

cess that automates as much of the ECU-specific software as

possible.

Conventional diagnostic development process

Most OEMs and suppliers work together in a common diagnostic

development process. This conventional diagnostic development

process is laden with inefficiencies that drive costs up and require

large efforts over several months to complete (Figure 1).

The process starts by setting up the requirements documents.

The diagnostic requirements are captured in a word-processor spec-

ification document. This authoring process requires a great deal of

time and effort and produces a document which is difficult to verify

as either complete or correct.

Once this document is completed, it is delivered to the supplier.

The supplier engineers must read and interpret the document. Less

experienced suppliers will not fully understand the requirements

on their own and will require significant support from the OEM

in getting up the learning curve. Opportunities for misinterpreta -

Implementing diagnostic functionality in automotive ECUs is usually an expensive, time-consuming and inefficient pro-cess. Computer-generated source code based on ECU-specific diagnostic data can dramatically decrease costs and develop-ment time and increase quality and efficiency. By considering the weaknesses in the typical ECU diagnostic development process, a clear set of objectives emerges. Defining a source code generation system that addresses these weaknesses lays the groundwork for implementing a successful solution.

23 Press Book_Seite_3-16_3-19.indd 223 Press Book_Seite_3-16_3-19.indd 2 09.02.2010 13:26:52 Uhr09.02.2010 13:26:52 Uhr

Page 123: Vector Press Book

3/17

In addition, suppliers must also deal with the possibility of

changes in diagnostic requirements from the OEM. These new docu-

ments not only mean reworks, but also further increase the oppor-

tunity for misinterpretation of requirements that can lead to

reworks of the reworks.

Diagnostic source code generator

From office productivity software to web applications, most mod-

ern software packages profit from including pre-built components.

This enables the engineer to focus on the core tasks of the specific

application and to reduce the overall complexity. This also appeals

to the project manager as the development proceeds faster and

risks are reduced. The diagnostic component approach has another

significant advantage. Different diagnostic specifications from dif-

ferent OEMs can share a common application-programming inter-

face. This interface not only hides the complexity of the extensive

ECU-independent diagnostic specifications from the programmer,

but also keeps ECU application software design OEM-independent.

The OEM defines ECU-specific requirements as input data to the

source code generator. These formal requirements replace the cur-

rent word-processing based documents used today as a basis for

software development. The source code generator creates an ECU-

specific diagnostic software component according to the OEM’s

diagnostic requirements. Next, the supplier develops the ECU-spe-

cific parts of the diagnostic software. The complexity of the diag-

nostic protocol is hidden by the application-programming interface

that connects the communication to the diagnostic functions in the

ECU.

tion are everywhere and almost always lead to non-compliant

implementations. In this situation, not only non-compliant imple-

mentations are likely, but also come in the form of multiple suppli-

ers having the same misunderstandings and producing the same

issues across multiple ECUs.

Once the ECU software is implemented and delivered to the OEM,

the OEM must test each ECU for compliance to requirements. Given

the process, the OEM has no choice other than to test each and

every requirement on each and every ECU. This means redundant

and parallel testing of all ECUs. These tests are likely to identify

failures that are shared by multiple ECUs. In the end, many engi-

neers are all working to find and resolve similar issues across multi-

ple ECUs.

Frequently, diagnostic functions are the last implemented in an

ECU. Without diagnostics, many basic ECU functional requirements

are difficult or impossible to test. As a result, the late availability

of diagnostics forces many tests to wait until the last minute, even

for functional requirements implemented early in the development

cycle. Postponing important testing dramatically increases the risk

of identifying significant issues very late in the development cycle

and putting program timing at risk.

Development engineers are left to learn and apply requirements

spanning numerous documents, from different organizations and

different authors; each with their own points of view, sets of termi-

nology and levels of completeness. Incomplete definitions, ambig-

uous wording, inconsistent terminology and requirements that are

just plain assumed and not specified make the job nearly impossi-

ble to execute right the first time.

Figure 1: Conventional diagnostic development process with breaks in the data flow. The late implementation results in a short integration and test phase.

Figure 2: The diagnostic development process with the Vector CANdela approach. Diagnostic data is stored in one database and then reused in all subsequent process steps.

23 Press Book_Seite_3-16_3-19.indd 323 Press Book_Seite_3-16_3-19.indd 3 09.02.2010 13:26:53 Uhr09.02.2010 13:26:53 Uhr

Page 124: Vector Press Book

3/18

The diagnostic component is typically available at the beginning of

the project. Because the component’s interface mirrors the function-

al requirements, any ECU-specific requirements are insulated from

OEM specifications. This means that ECU-specific source code can be

reused for other vehicle programs with other OEMs without signifi-

cant modifications. This structure produces ECU application code that

is highly portable and not tied to a specific vehicle program.

Solution – the CANdela approach with CANdesc

There is already a working implementation of this approach to imple-

menting diagnostics in an ECU. CANdesc, a part of the Vector CANdela

product family, implements exactly this approach (Figure 2).

CANdesc works with FNOS, GMLAN, FIATLAN. and many more OEM

specifications CANdesc is applied in many ECUs in many real-world

vehicles.

CANdelaStudio is the authoring tool to define the ECU-specific

data. A use-case-oriented user interface provides an intuitive view

on diagnostic information and allows easy and comfortable edit-

ing. The CANdelaStudio data model covers all requirements neces-

sary for effective source code generation as described in this docu-

ment (Figure 3).

The source code generation tool outputs the ECU diagnostic soft-

ware component source code (Figure 4).

Resource requirements are a very sensitive point in automotive

embedded software. CANdesc was designed with this point in mind.

Exact resource consumption depends on microcontroller and com-

piler selection and so does the optimal generation configuration,

but typical values according to real-world experiences are shown

here. Please note that these numbers represent a replacement for

the resources consumed in a typical diagnostic implementation,

not an addition to them.

Advantages from the OEM perspectives

The component developer manually develops a framework that cov-

ers all ECU-independent requirements. This is the same process

done today by any supplier and the OEM. The main difference is

that parallel and redundant efforts for implementation and testing

are eliminated. Redundant implementation errors are simply avoided.

This also eliminates common and parallel misunderstandings of the

diagnostic specifications. When the work is done and the compo-

nent is ready for use, the same framework is shared by all suppliers.

The OEM must define ECU-specific requirements as input to the

source code generator. This formal specification of requirements

can be used for much more than just tailoring embedded software

components. It can be reused to generate a word-processor specifi-

cation document and to generate input data to test systems. If an

appropriate tool supports the data entry process, the entire diag-

nostic process will be more efficient than it is today.

Another advantage of software components is their availability.

As the software component is typically ready for use at the begin-

ning of product development, the very first implementation of the

ECU already contains diagnostics. This improves the quality of the

complete diagnostic implementation as late changes are reduced

or avoided completely.

Advantages from the supplier perspective

The supplier generates source code for all OEM-specific require-

ments. He does not need to interpret the OEM’s diagnostic protocol

specification at all. Inconsistent interpretations and implementa-

tions of the protocol are left out of the process, which leads to a

significant reduction of development iterations.

Figure 3: Generation of an ECU diagnostic software component

23 Press Book_Seite_3-16_3-19.indd 423 Press Book_Seite_3-16_3-19.indd 4 09.02.2010 13:26:54 Uhr09.02.2010 13:26:54 Uhr

Page 125: Vector Press Book

3/19

A SOURCE CODE GENERATOR APPROACH TO IMPLEMENTING DIAGNOSTICS IN VEHICLE ECUS

The Vector CANdela approach shows that the concept of comput-

er generated diagnostic software components not only works in

real world applications, but also delivers on the promises made by

such an approach.

ROM: about 8 k for an ECU of moderate complexity (like a climate >

control or transmission unit), about 5 k for even the smallest

ECUs

RAM: about 128 bytes >

The experiences with CANdesc are impressive. From the start of the

component generation and integration, all diagnostic services are

working in a few hours. Most of the features work right on the first

try and many features are running by the end of the first day. This

rapid development allows for a complete diagnostic implementa-

tion before the first bench delivery. The total diagnostic develop-

ment time is reduced by up to 80 %, which corresponds to a savings

in effort of about 4 man months (Figure 5).

Conclusion

Diagnostic implementation is a significant part of the ECU develop-

ment process. There are opportunities for significant gains in both

efficiency and quality. The malfunction detection strategies and

operational diagnostics strongly depend on an individual ECU –

these tasks continue to be part of the ECU application. But the

ECU-independent part is a perfect candidate to be implemented as

a diagnostic framework.

To optimize the implementation, this framework must consider

ECU-specific data. The framework source code is to be generated by

a computer based generation tool, processing a formal description

of all diagnostic requirements. Moreover, this formal description of

diagnostic data has significant potential to simplify the complete

diagnostic development process. Generated specifications, docu-

mentation and tester data replace their hand-made counterparts of

the conventional diagnostic development process.

Christoph RätzDipl-Ing. Christoph Rätz (BA) studied Computer Engineering at the University of Cooperative Education at Stuttgart. He is the global product line manager for the Vehicle Diagnostics at Vector Informatik in Stuttgart/Germany.

Figure 4: From diagnostic specification to C-Code

Figure 5: Effort savings with the CANdela approach

23 Press Book_Seite_3-16_3-19.indd 523 Press Book_Seite_3-16_3-19.indd 5 09.02.2010 13:26:54 Uhr09.02.2010 13:26:54 Uhr

Page 126: Vector Press Book

ECU Soft ware for Dry Du al Clutch has Strin gent Re quire ments

Au to mat ed trans mis sions com bine the con ve nience of an au to mat ic

trans mis sion with the cost ad van ta ges of man u al trans mis sions. In

con junc tion with ECM (Elec tron ic Clutch Man age ment), du al clutch

trans mis sions form the ba sis for mod ern drive con cepts. While the

ECM sys tem han dles elec tric mo tor ac tu a tion of the du al clutch,

trans mis sion con trol en sures that two gears are al ways en gaged si -

mul ta ne ous ly. Usu al ly gears 1, 3 and 5 are served by one trans mis -

sion sec tion, while the oth er sec tion is re spon si ble for gears R, 2, 4

and 6. Dis en gage ment of one clutch and si mul ta ne ous en gage ment

of the oth er clutch en a bles a near ly jolt-free gear shift – with out an

in ter rup tion in the pro pul sive force – to the next high er or next

low er gear. The op ti mized shift ing meth od re quires just a few hun -

dredths of a sec ond to shift gears and of fers bet ter fu el econ o my

than man u al shift ing.

Great est Ef fi cien cy with Dry Du al ClutchThe first ‘dry’ du al clutch was de vel oped at the fa cil i ties of au to mo -

tive sup pli er LuK in Bühl (Fig ure 1). This com pa ny, part of the Scha-

ef fler Group and a spe cial ist in clutch and trans mis sion com po nent

so lu tions, has con trib ut ed to the ad vance ment of au to mo tive tech -

nol o gy with all sorts of in no va tive de vel op ments. In 1965 it was the

first com pa ny in Eu rope to in tro duce the di a phragm spring clutch

to the mar ket, and in 1985 the first du al-mass fly wheel. This was

lat er fol lowed by CVT (Con tin u ous Var i a ble Trans mis sion) com po -

nents for tor ques great er than 300 Nm and the world’s first elec tro-

me chan i cal au to mat ic trans mis sion. Mean while, ev ery fourth car in

the world is driv en with a LuK clutch. To day, the fo cus of the com -

pa ny’s de vel op ment is on al ter na tive drive con cepts too, such as

com po nents for du al-clutch trans mis sions and hy brid drives.

Un til now, du al-clutch trans mis sions were on ly avail a ble in wet

tech nol o gy, i.e. with com po nents run ning in oil. Al though they of -

fer the ad van tage of great er pow er loss ab sorp tion by oil cool ing,

this is con trast ed by the dis ad van ta ges of a low er fric tion fac tor

and a larg er drag torque when idling. Since LuK us es elec tric mo -

tors to ac tu ate the dry du al clutch, this of fers even great er po ten -

tial for re duc ing fu el con sump tion and CO2 emis sions.

3/20

Du al-clutch trans mis sion tech nol o gy noton ly of fers sig nif i cant im prove ment indriv er con ve nience and ride com fort atmod er ate add ed cost. At the same time,it al so de liv ers ex cel lent fu el econ o my.The de sign of a pro duc tion ver sion of theworld’s first ‘dry sys tem’ du al-clutchtrans mis sion rep re sent ed a spe cial chal -lenge for the ECU’s elec tron ics. Fre quentflash ing of the ECU is nec es sa ry in thede vel op ment proc ess, and this re quiresthe use of ra tion al flash meth ods andhigh-per form ance tools that are up tothe task.

In te grat ed Di ag nos tic and Flash So lu tion with Script Con trol

Fig ure 1: The core of the mod ern du al-clutch trans mis sion: Dry(left) or wet (right) du al clutch es en sure gear shiftswith out in ter rup tion of trac tive force. Soft ware de vel -op ment for these drive con cepts by LuK re quired fre -quent flash ing.

24 Press Book_Seite_3-20_3-23:Press Report 4 09.02.2010 13:14 Uhr Seite 1

Page 127: Vector Press Book

From in-house Flash Tool De vel op ment to uni ver sal FlashSo lu tionAt first, LuK han dled the flash ing that is fre quent ly need ed in soft -

ware de vel op ment (up dat ing of pro gram code or da ta in the ECUs)

with an in-house de vel op ment that was even used to flash pro duc -

tion ECUs. In de pend ent ly, the clutch spe cial ist con duct ed a search

for a di ag nos tic tool for CAN. Aft er find ing, dur ing a test phase,

that oth er pro ducts were lack ing in var i ous ar e as – ran ging from

the graph ic us er in ter face to prod uct sup port – LuK de cid ed on

CAN di to from the Stutt gart-based com pa ny Vec tor In for ma tik. Vec -

tor im pressed them with a so lu tion that can im ple ment all of the

var i ous flash meth ods and can al so serve as a full di ag nos tic test er

(Fig ure 2).

In the di ag nos tic test er CAN di to, the LuK em ploy ees found pre cise -

ly what they had been look ing for, and more. The tool en a bles sym -

bol ic ac cess to all da ta and func tions that are ac ces si ble via the

di ag nos tic pro to col. It reads in ODX-2.0 de scrip tion files and sup -

ports scripts for au to mat ing di ag nos tic and op er at ing se quen ces.

ECU var i ants are au to mat i cal ly de tect ed. The au thor ing tool

CAN de laS tu dio is used to de scribe the di ag nos tic da ta in CDD and

ODX for mats. Each ECU is de scribed in a sep a rate doc u ment that is

based on a doc u ment tem plate. A var i ants con cept makes it pos si -

ble to de fine the com mon al i ties and dif fer en ces of an ECU’s var i -

ants, large ly with out re dun dan cies. Full pa ram e ter i za tion sim ply

In tel li gent Soft ware pro tects the Clutch Sys temA prob lem spe cif ic to the dry clutch be comes ap par ent when stop -

ping on a hill, when the driv er ap plies the brak ing torque via the

gas ped al and clutch in stead of the brakes. Due to poor er cool ing,

the clutch gets hot much quick er than in a wet sys tem. To pro tect

against pre ma ture wear and fail ure, in tel li gent driv er warn ing

strat e gies are re quired, which sup port the driv er in op ti mal ly util iz -

ing the clutch. The soft ware might achieve this, for ex am ple, by al -

low ing the ve hi cle to slow ly roll free aft er a short pe ri od of time,

which in du ces the driv er to au to mat i cal ly step on the brake ped al.

Dur ing the drive, the elec tron ics must ad just the clutch en gage -

ment to be quick er or slow er de pend ing on ve hi cle speed, gas ped al

po si tion, etc.

Over all, nu mer ous con straints and pa ram e ters need to be con sid -

ered in au to mat ic clutch op er a tion, and they change dy nam i cal ly

dur ing op er a tion. The clutch heats up, cools down again and is the-

re fore con tin u al ly chang ing its char ac ter is tics. The elec tron ics must

con tin u al ly adapt the be hav ior of the au to mat ic du al clutch to the-

se chang ing pa ram e ters. LuK util iz es an ad vanced com pu ta tion al

mod el that yields a clutch me chan i cal de sign that is less com plex

and is there fore more eco nom i cal for the au to mo tive OEM.

3/21

Fig ure 2:By us ing the right tooland ODX, a smooth tran -si tion of flash proc ess esis pos si ble – from de vel -op ment to pro duc tion.

24 Press Book_Seite_3-20_3-23:Press Report 4 09.02.2010 13:14 Uhr Seite 2

Page 128: Vector Press Book

in volves read ing in the ECU de scrip tion file. All com mu ni ca tion pa -

ram e ters and all ex ist ing serv i ces and da ta are im me di ate ly avail a -

ble. In a sep a rate work step, the em bed ded soft ware can al so be

gen er at ed from the de scrip tion file. This en sures that the di ag nos -

tic de scrip tion, the soft ware in the ECU and pa ram e ter i za tion of

the di ag nos tic test er are al ways co or di nat ed.

Di ag nos tics and flash ing with one ToolA key ba sic re quire ment for LuK is that it must be pos si ble to read

out the soft ware cur rent ly in the ECU be fore flash ing. This is nec es -

sa ry to en sure that the cor rect soft ware ver sion is be ing flashed in

the rel e vant ECU. Fur ther more, this ca pa bil i ty is im por tant for

read ing out sys tem pa ram e ters and the er ror mem o ry or for mak ing

be fore/aft er com par i sons. In the old so lu tion, the di ag nos tic test er

was need ed to ac cess these da ta. Aft er the us er had read out the

nec es sa ry da ta, the us er would stop the test er, start the flash tool

and se lect the ap pro pri ate files – an in tri cate pro ce dure.

A rem e dy to this sit u a tion was found in use of the script lan guage

in te grat ed in CAN di to (Fig ure 3). Aft er com mu ni ca tion has been es -

tab lished, the tool reads out the iden ti fi ca tion of the soft ware cur -

rent ly in the ECU. Based on a ta ble, the tool au ton o mous ly de cides

wheth er an up date is even nec es sa ry. Scripts en sure that the tool

al ways us es the right soft ware for the par tic u lar hard ware var i ant,

even when the same ECU hard ware is used on nu mer ous dif fer ent

ve hi cle mod els. Use of CAN di to as a di ag nos tic test er and flash tool

– in clud ing script func tions to sim pli fy the job – goes a long way

to ward im prov ing proc ess re li a bil i ty.

Out lookCur rent trends in re pro gram ming mem o ry chips in clude: ODX-F, par -

al lel flash ing and flash ing with in creased band width via Flex Ray. In

light of these wide-ran ging trends, ques tions re lat ed to pro tec tion

of in vest ment and as sur ance of fu ture cov er age are thor ough ly jus -

ti fied. Us ers of Vec tor pro ducts ben e fit here, not on ly be cause they

rep re sent a scal a ble tool chain with mul ti ple flash so lu tions, but al -

so be cause they of fer time ly pro gram ver sions that meet cur rent

stand ards. While ODX-F sup port and par al lel flash ing are al ready

avail a ble, Flex Ray sup port is al ready com ing with the next re lease.

Ex ist ing au thor ing tools for the de vel op ment of di ag nos tic pa ram e -

ter i za tion or the ODX-F flash con tain ers round out this ar ea.

3/22

Fig ure 3:LuK de vel ops flash jobs us ing the script ed i tor in te -grat ed in CAN di to. In the scripts, di ag nos tic func tionsare ex e cut ed, and the nec es sa ry in for ma tion and da taare read-in from an ODX flash con tain er.

Wern er SchmittElec tri cal tech ni cian, works on de vel op ingelec tron ic sys tems in the trans mis sion au to -ma tion ar ea at LuK GmbH & Co. oHG. He isrespon si ble for di ag nos tics as well as start-up and serv ice of these sys tems.

An dre as Pat zer (Grad u ate en gi neer) works at Vec tor In for -ma tik GmbH where he is Busi ness De vel op -ment Man a ger in the “Meas ure ment and Cal i -bra tion” prod uct line.

24 Press Book_Seite_3-20_3-23:Press Report 4 09.02.2010 13:14 Uhr Seite 3

Page 129: Vector Press Book

3/23

24 Press Book_Seite_3-20_3-23:Press Report 4 09.02.2010 13:14 Uhr Seite 4

Page 130: Vector Press Book

3/24

Flex i ble Flash So lu tion for ev ery Job

Re pro gram ming of mod ern flash chips has be come acom mon place proc ess in de vel op ment and pro duc tion. In prac tice, the jobs are ex cep tion al ly di verse – de pend ingon the ECU, de part ment, man u fac tur er and sup pli er – soprep a ra tion, man age ment and the flash proc ess it self allin volve con sid er a ble ef fort. There fore, this ar ti cle firstsur veys the pure ly tech ni cal ter rain in which flash so lu -tions oc cur. Aft er wards, the per spec tive is ex pand ed tocov er proc ess-ori ent ed jobs and ra tion al ap proach es tosolu tions.

Open stand ards en a ble use of ge ner ic tool chains

Mem o ry fun da men talsWher ev er in for ma tion needs to be saved for a cer tain pe ri od of

time, one finds re writ a ble flash mem o ry in use to day, e.g. in USB

sticks, dig i tal cam er as and mo bile tel e phones. Long-term stor age

of the firm ware of mi cro con trol ler-based ECUs in the au to mo bile is

a fre quent ap pli ca tion ar ea for flash mem o ry. The mar ket of fers

var i ous flash ar chi tec tures as NAND or NOR flash, which dif fer in

terms of con trol log ic, ac cess speed, cur rent con sump tion and life.

Com mon to all types is that the mem o ry needs to be erased be fore

re writ ing. Al though da ta can be read-out byte-by-byte, the eras ing

proc ess – in con trast to con ven tion al EE PROM mem o ry – can on ly be

per formed block-wise. In ECUs, NOR flash is used al most ex clu sive ly.

Tech ni cal flash ing“Tech ni cal flash ing” es sen tial ly re fers to a proc ess for up dat ing

pro gram code and/or da ta in ECUs. This may be done, for ex am ple,

us ing a PC or lap top with spe cial soft ware – the so-called flash tool

– via the ex ist ing net work in fra struc ture, e.g. the CAN se ri al bus

sys tem (Fig ure 1). Re quire ments dif fer, some times sig nif i cant ly, for

flash ing dur ing the de vel op ment phase, end-of-line pro gram ming

or soft ware up dates at serv ice cen ters. While soft ware chan ges in

the de vel op ment phase al ways in volve pro vid ing new code or new

da ta to the same ECU, what mat ters in pro duc tion-re lat ed flash ing

is to use – from a wide va ri e ty of re leased soft ware lev els – those

that are cor rect for the spe cif ic ve hi cle and its fea tures. In this

case, it is es sen tial to con sid er the ve hi cle var i ant, in stalled fea -

tures, coun try code, se ri al num ber, safe ty as pects, etc.

At a min i mum, the fol low ing com po nents are need ed for flash ing:

> Flash da ta,

> Flash tool,

> Flash boot load er, which is in te grat ed in the ECU and ex e cutes the

ac tu al erase/write proc ess es

> The nec es sa ry me ta in for ma tion.

The flash da ta con tain the pro gram code and spe cif ic pa ram e ter

sets in tend ed for the ECU. The flash tool im ple ments the flash rou -

tine on the PC side. If the tool on ly sup ports a spe cial flash rou tine,

Fig ure 1: Mem o ry struc ture in ECU with Flash Boot Load er from Vec tor.

25 Press Book_Seite_3-24_3-27:Press Report 3 09.02.2010 13:14 Uhr Seite 1

Page 131: Vector Press Book

3/25

CAN driv ers, CCP/XCP pro to cols, etc. A gen er a tor tool is re spon si ble

for da ta con fig u ra tion and gen er a tion of the head er files.

If one util iz es a suit a ble au thor ing tool to con ve nient ly gen er ate

di ag nos tic da ta and serv i ces, the tool can be used to di rect ly pa -

ram e ter ize the di ag nos tic test er and gen er ate the rel e vant di ag -

nos tic code for the ECU. An ODX-D da ta con tain er stores the di ag -

nos tic da ta and flash job to geth er. There is an ODX-F man age ment

and au thor ing tool for link ing flash da ta, jobs and me ta-da ta. The

as so ci at ed com mu ni ca tion pa ram e ters are not con tained in the

ODX-D con tain er, rath er in a ded i cat ed ODX-C con tain er ('C' stands

for “Com mu ni ca tion”), Fig ure 2.

then ded i cat ed flash tools may be need ed for dif fer ent flash jobs.

Da ta-driv en, mul ti pur pose flash tools are ef fi cient and more mod -

ern. Flash job con trol en a bles their use for dif fer ent ECUs and flash

rou tines, e.g. if the same ECU is to be used at dif fer ent OEMs. A sin -

gle ded i cat ed tool is all that is need ed to man age flash jobs and as -

so ci at ed flash da ta in con tain ers, and it al ways has the same us er

in ter face.

Re spon si ble for the rou tine on the ECU side is the flash boot load er

(FBL) that is in te grat ed in the ECU and is al ways ac tive. The FBL is

par ti tioned in to the per ma nent boot load er ex ist ing in the ECU and

the flash driv er. For se cu ri ty rea sons, the flash driv er is on ly tem -

po ra ri ly load ed in the ECU’s RAM, since among oth er things it con -

tains the serv ice for in i tial era sure of the flash mem o ry, ac cept ance

of da ta from the flash tool and ex e cu tion of the sub se quent re set.

The boot load er con sists of the CAN driv er, trans port pro to col and di a g-

nos tic lay er and there by en sures that the ECU al ways re mains ad -

dress a ble, even if the flash proc ess could not be com plet ed prop er ly.

Proc ess-ori ent ed flash ingA spe cial chal lenge in flash ing is to al ways load the right ap pli ca -

tion in an ECU. That is the on ly way to en sure com plete and er ror-

free func tion al i ty in the ve hi cle. In pro duc tion-re lat ed flash ing,

me ta-da ta are re quired for this, such as ECU and ve hi cle var i ant,

soft ware se ri al num ber, name of the flash job and much more. Da ta

con tain er files, which are re ferred to here as flash con tain ers, are

ap pro pri ate for con sist ent man age ment of this in for ma tion to -

gether with the flash da ta and flash jobs. ODX (Open Di ag nos tic

data eX change) is avail a ble as a stand ard ized for mat, where in a

dis tinc tion is made be tween ODX-D for di ag nos tic-rel e vant in for ma -

tion and ODX-F for flash-spe cif ic da ta.

Since me ta in for ma tion is gen er al ly un a vail a ble in de vel op ment,

flash ing is of ten very dif fer ent dur ing de vel op ment and dur ing pro -

duc tion. So ECU de vel op ers some times flash – not via the di ag nos -

tic pro to col, but via CCP (CAN Cal i bra tion Pro to col) or XCP (Uni ver -

sal Meas ure ment and Cal i bra tion Pro to col).

Ra tion al gen er a tion and man age ment by toolsTo gen er ate the ex e cu ta ble flash a ble bi na ry files via com pi ler/link -

er, one needs the source code for the ap pli ca tion, di ag nos tic code

and em bed ded code el e ments, which are sup ple ment ed by check -

sum in for ma tion, fin ger prints and oth er da ta. Use of a com pre hen -

sive prod uct so lu tion quick ly leads to the de sired re sults – e.g. one

from Vec tor In for ma tik with source code for the em bed ded por tion

in the ECU, con sist ing of op er at ing sys tem, net work man age ment,

Fig ure 2: Based on the ODX-F con tain er, the flash rou tine is executed ful ly au to mat i cal ly with CA Na pe, CAN di to and CAN dit o Flash. The con tain er con tains all nec es sa ryda ta and in for ma tion such as ref er ence to the flashfile, flash job and me ta in for ma tion.

25 Press Book_Seite_3-24_3-27:Press Report 3 09.02.2010 13:14 Uhr Seite 2

Page 132: Vector Press Book

3/26

the us er by of fer ing en hanced flex i bil i ty with the goal of cov er ing a

wide va ri e ty of re quire ments and job tasks re lat ed to flash ing.

Flash rou tines can not be im ple ment ed with out suit a ble tool chains.

From Vec tor the ECU de vel op er gets uni ver sal tool sup port in all

aspects of flash ing: CAN de laS tu dio for spec i fy ing di ag nos tic

require ments and gen er at ing the CDD, ODX-D and ODX-C files,

CAN de la Flash for gen er at ing the ODX-F flash con tain ers and the

flash boot load er for a wide range of con trol lers. As au thor ing and

de vel op ment tools, CA Na pe and CAN di to are used to gen er ate

script-based flash rou tines, and they al so form the ac tu al run time

en vi ron ment for the flash proc ess. CAN dit o Flash serves as a pure

run time en vi ron ment for flash proc ess es gen er at ed with CA Na pe

and CAN di to.

Get ting “a grip” on ref er en cesLat er in the flash proc ess the sys tem reads from the ODX-F file the

flash files, me ta in for ma tion and ref er ence to the flash job be ing

used. The lat ter is found in the di ag nos tic de scrip tion, from which

it is load ed and ex e cut ed. Ref er en ces are used to pro duce the re la -

tion ships be tween the ODX-F, ODX-D and ODX-C con tain ers.

On the one hand, ref er en ces to flash da ta and flash jobs are easy to

re place with out re quir ing re gen er a tion of the ODX files, but they

are al so as so ci at ed with the risk that the proc ess will no longer

func tion if a ref er enced doc u ment is miss ing. One so lu tion to this

prob lem was to cre ate “me ta” con tain ers that save all as so ci at ed

da ta in a sin gle, com pressed file. By def i ni tion, the con tain ers –

with the 'PDX' (Pack aged ODX) ex ten sion – do not per mit any ref er -

en ces to files out side of the con tain er.

This con cept en sures that one al ways loads the right flash da ta with

as so ci at ed me ta in for ma tion in to the ECU by the prop er flash rou -

tine. Fur ther more, it per mits both ful ly-auto mat ic and sem i-auto -

mat ic flash ing. Ful ly au to mat ic means that the us er does not per -

form any con fig u ra tion or se lec tion ac tiv i ties. In sem i-auto mat ic

flash ing the us er can in flu ence the flash proc ess.

Sum ma ryThe use of stand ards such as ODX en a bles the use of tool chains that

en sure re li a ble and proc ess-con form ant flash proc ess es in ev ery de -

vel op ment phase (Fig ure 3). Ge ner ic and da ta-driv en tools ben e fit

Fig ure 3: Use of the ODX-Stand ards en a bles asmooth tran si tion in flash proc ess -es from de vel op ment to pro duc tion.

An dre as Pat zer (Grad u ate en gi neer) is em ployed at Vec torIn for ma tik GmbH as Busi ness De vel op mentMan a ger for the “Meas ure ment and Cal i bra -tion” prod uct line.

25 Press Book_Seite_3-24_3-27:Press Report 3 09.02.2010 13:14 Uhr Seite 3

Page 133: Vector Press Book

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. +49 711 8 06 70-0

www.vector.com

Vehicle Diagnostics

Diagnostics

Calibration

ECU

Test

ECU

Distr. Systems

Deve

lopm

ent

Software

ECU

Management

Proc

ess

In your ODX development, you can benefit from the know-how

of our employees and our comprehensive experience acquired

in production projects and ODX standards committee work. Take

advantage of Vector’s universal ODX products and services:

> Create diagnostic data easily and exchange this data with

your process partners

> Diagnose individual ECUs or the total vehicle

> Flash ECUs based on ODX-F data

> Migrate master data to ODX

> Benefit from our consultation in implementing and

integrating ODX

Add ODX to your diagnostic development reliably and quickly. Vector tools and services will support you in all phases.

Press the button! www.odx-solutions.com

New: Indigo

Easy vehicle diagnostics

based on ODX

ODX at the press of a button! Rely on

proved and tested ODX solutions

25 Press Book_Seite_3-24_3-27:Press Report 3 09.02.2010 13:14 Uhr Seite 4

Page 134: Vector Press Book

22 Source: CAN Newsletter, CAN in Automation

Tool

A lot of flexibility is de-manded of automotive

suppliers in the develop-ment of electronic compo-nents. This also applies to the area of Flash program-ming. Constraints in the various phases of the prod-uct life cycle, which in some cases may vary widely, each require differentiated handling. Besides realizing new optimization potential by their own inventiveness, suppliers now also have more powerful tools avail-able to them.

ECUs need to be re-programmed and analyzed more or less frequently over the various phases of a ve-hicle ranging from develop-ment to production to op-eration in the target vehicle to diagnostic analysis of re-turned product. Once the ECU has been installed in the vehicle, CAN is the only means of accessing it. In the development phase too the CAN bus is utilized as an in-terface for exchanging soft-ware. For suppliers the ba-sic challenge is to achieve the most rational flow in their own development and production phases and sat-isfy the (strict) requirements of the vehicle OEM.

The solution approach of the company Continental Automotive Systems (www.conti-online.com), for exam-ple, involves creating their own OEM-specific Flash-loader for development and production phases and a customer-specific Flash-loader for the product oper-ation phase. The production boot-loader is optimized for standardized in-house flash processes and is decomis-

sioned at the end of the pro-duction process, so that in normal operation only the

still active. For the suppli-er this eliminates potential compatibility problems be-tween the production boot-

flashing process.Since the topic of secu-

rity plays an important role in Flash programming in the vehicle operation phase, all security mechanisms for in-tegrity, authenticity, copy protection, etc. come into play here. These aspects are gaining in importance, because Continental has the capability of reactivating the production boot-loader to analyze returned prod-uct. Therefore, in reactiva-tion precautions are taken to ensure that unauthorized persons cannot exploit this

indirect path to manipulate or spy data.

A specific application at Continental involves re-programming a multiproces-sor system with master and slave controllers and ex-ternal sensors. The master controller can be flashed di-rectly by CAN; however the slave and sensors can only be addressed indirectly in flashing. To gain control over the entire Flash process given the described con-straints, the Stuttgart-based company Vector Informatik, a specialist in developing automotive electronics, was hired to implement a special extension. This extension is capable of utilizing the seri-al IPC (Interprocessor Com-munication) connection be-tween the master and slave in Flash programming. In this project a Flash tool with

Flash programming via CAN requires supplier’s flexibility

By Peter Liebscher (Vector Informatik)

a hard-coded Flash proce-dure is still employed, but the future belongs to flexible standard tools with which the numerous challenges of the Flash process can be managed much more ratio-nally at the supplier. The ad-vantage of parameterization using tools such as CANape and CANdito from Vector is that all information relevant to the Flash process can be saved in standardized flash data containers. Use of the ODX Flash format as a fu-ture de-facto standard en-ables data exchange with other tools. At the same time required diagnostic data are stored in the container that might be generated with the CANdelaStudio program of the same producer.

[email protected]

3/28

26 Press Book_Seite_3-28_3-29:Press Report 2 09.02.2010 13:04 Uhr Seite 1

Page 135: Vector Press Book

3/29

26 Press Book_Seite_3-28_3-29:Press Report 2 09.02.2010 13:04 Uhr Seite 2

Page 136: Vector Press Book

Mr. Peteratzinger, why FlexRay and why now?

Peteratzinger: That was a strategic decision. We have alre-ady reached the limits of reasonable bus loads with CAN,and would otherwise need to install multiple CAN buses,and not just for high-end products. Our analyses indicatedthat up to eight CAN buses would be needed for just thepowertrain and chassis areas in the next 7-series car. Butwe do not want to implement even more sub-buses; atsome point they become unmanageable. Therefore, someyears ago BMW decided to build up its development expe-rience with FlexRay. We now have a foundation for futureelectrical systems and will expand them to include additio-nal vehicle systems in upcoming car models. If we did notstart on this now, we would have had to utilize a large num-ber of CAN systems and sub-buses to carry us through, andthis would last for many years due to the developmentcycles for car models.

Steiner: Another criterion of course is transmission rate. Inthe current application sensor signals are acquired and pro-cessed both by the central ECU and by the satellites. Onthe one hand, this decentralized approach leads to an incre-ased demand for communication, and on the other handshorter cycle times are needed on this and future architec-tures due to their separation of sensors, control system andactuator. In addition, many of the new functions and archi-tectures place stricter requirements on real-time capabilityand communication availability. This can only succeed witha bus system like FlexRay.

Why did BMW chose suspension control as a pilot

application?

Peteratzinger FlexRay is a completely new development,and we had no knowledge base from other production pro-jects. In this case, the first step was to build up this know-ledge. It was therefore important for BMW to be able to quik-kly apply this acquired knowledge and implement necessa-ry changes during development. In a system such as an engi-ne controller the adaptation effort would be considerable dueto the large number of interfaces. This new suspensionsystem has a well-defined and limited functionality. In a smallteam, together with our ECU suppliers and developmentpartners such as Vector, we wereable to make decisions and intro-duce modifications over shortdecision-making paths. Further-more, aspects of this applicationmade it possible to implementmany new FlexRay featuresmeaningfully.

When did you decide to elimi-

nate CAN entirely as a fall-back

solution in this project?

Peteratzinger: That was done in arelatively early phase of the pro-ject in the summer of 2004. Afterwe had successfully started upFlexRay as a bus system to net-work the five ECUs in a stablemanner and had all identified andassessed unresolved risk issues,

1 lA U T O M O T I V E 9. 2 0 0 6

Martin Peteratzinger, Graduate

Engineer (University of Applied

Sciences), develops electronics

in the vehicle dynamics area of

the BMW Group and has func-

tional responsibility for the

FlexRay application.

Use of XCP on FlexRayat BMW

This fall the first FlexRay production

application wil l hit the streets. The

Munich-based automotive manufacturer

BMW is introducing the innovative bus

system for the first time on its new X5

vehicle. From December 2004 to Janua-

ry 2006 tool producer Vector Informatik

worked together with BMW on the

FlexRay solution. FlexRay experts Mar-

tin Peteratzinger and Florian Steiner of

BMW and Roel Schuermans of develop-

ment partner and software provider

Vector discussed their experiences in

HANSER automotive.

INTERVIEW

AdaptiveDrive in the new X5 utilizes sensors and per-

forms computations to acquire data on vehicle speed,

steering angle, longitudinal and lateral acceleration,

body and wheel accelerations as well as their heights.

The swivel motors of the stabilizer bars and electro-

magnetic valves of the shock absorbers are controlled

based on this information.This provides full-time con-

trol of body roll and damping based on the given dri-

ving situation.The new BMW X5 is the first vehicle in

the world to utilize FlexRay technology.

Translated by Vector Informatik

4/0

27 Press Book_Seite_4-00_4-03:Press Report 2 09.02.2010 13:17 Uhr Seite 1

Page 137: Vector Press Book

the decision was made to eliminate CAN altogether begin-ning with the next hardware level. In the process this rai-sed the question: How would we calibrate the application?Initially calibration was still performed via CAN, but in theend this fall-back level was dropped. Therefore we firstdeveloped a CCP-CAN-FlexRay gateway that converts CCPmessages to FlexRay and in the reverse direction too. Inthe ECUs we also “restructured” the CCP module for Flex-Ray. This made it easier to continue utilizing CANape withCCP (CAN Calibration Protocol). But that too was just a tran-sitional solution, since first it is necessary to create suchgateways, and then they need to be maintained for a num-ber of years. Therefore it was important to find a productthat would not just work exclusively in one project, butwould be available to the entire market. In the ASAM wor-king committee XCP on FlexRay was driven by Vector withthe support of BMW and attained specification status inFebruary 2006.

Schuermans: Technically we had gotten a handle on the“measurement & calibration via XCP on FlexRay” conceptrelatively quickly. For Vector though it was clear that we hadto turn XCP on FlexRay into a standard as quickly as possi-ble. ASAM has been working on XCP for quite a long timenow. XCP itself was finalized in 2003. The aim of the stan-dard is to only require adaptation of the underlying trans-port protocol. The specific solution needs at BMW allowedus to implement both the XCP stack in the ECU and on thetool side CANape as the XCP Master very quickly.

XCP on FlexRay was standardized in February. What

was involved in this process?

Schuermans: Of course the work in ASAM requires a cer-tain amount of time: First a project application is submitted,then a working committee is formed, and finally a draft isdeveloped. XCP is split up into several subdocuments. Part1 is an overview of the protocol family, XCP features and

basic definitions. Part 2 of the document des-cribes the XCP command set as a bus-indepen-dent protocol layer. Whenever a new TransportLayer is added, as is being done now with Flex-Ray, a Part 3 document is created.

What does all this discussion about dynamic

bandwidth control really mean?

Schuermans: A part of the XCP on FlexRay spe-cification defines dynamic bandwidth control.Since the XCP protocol is essentially a Master-Slave communication protocol, the XCP Mastercan distribute XCP Slots to individual Slavesdepending on how much bandwidth the Slaveneeds. Dynamic bandwidth management requi-res that the Master knows which slots are avai-lable for this purpose. That must be a part of theFIBEX file.

Why is that good?

Steiner: Compared to the potential bandwidthof FlexRay the current bus load is still very small.

We therefore had the luxury of making three XCP slots avai-lable to each ECU: One to communicate fromCANape in the direction of the ECU, and two tosend measurement data from the ECU in thedirection of CANape. That means that 15 slotsare used just for XCP. In the next car models thebus will be utilized more intensively with moreECUs. Then we will no lon-ger have this freedom. AllECUs must then share oneslot or just a few slots forXCP. The only limitation here isthat it will no longer be pos-sible to calibrate all ECUssimultaneously. However,this is of no consequence inpractice, because devel-opers generally only calibratetheir “own” ECU. With dyna-mic bandwidth allocation thiscan be done very quickly.

That is XCP will remain in the ECU?

Steiner: Yes! Although there is no need for direct measu-rement on the FlexRay bus while it is in service, the XCPmodule will be retained in production versions of the ECU.Diagnostics of the FlexRay ECUs is performed via OBD, thestandard diagnostic interface in the vehicle. XCP plays acentral role in testing and validating ECU functions and istherefore a component of the production software.

Doesn’t that pose a risk? Certainly there are people

who might want to reprogram the chassis.

Schuermans: XCP, and I am not just referring to XCP onFlexRay here, has a so-called Seed&Key security mecha-nism. XCP is of course based on a Master-Slave principle.

INTERVIEW lA U T O M O T I V E 9. 2 0 0 6 l2

Florian Steiner,

Graduate Engi-

neer (University

of Applied Scien-

ces), develops

electronics in the

vehicle dynamics

area of the BMW

Group and as a FlexRay deve-

lopment expert he is respon-

sible for production-level ECU

development.

Optimization of ECU parameters with CANape

V E C T O R ' S C A N A P E

4/1

27 Press Book_Seite_4-00_4-03:Press Report 2 09.02.2010 13:17 Uhr Seite 2

Page 138: Vector Press Book

INTERVIEW3 lA U T O M O T I V E 9. 2 0 0 6

The Master must ask the Slave for a "Seed",and this is used to compute an associatedkey. The Master does not grant the Slaveaccess until the correct key is obtained.

Peteratzinger: Our hardware supplier hasalso installed another software protectionmechanism. So protection is twofold.

What did Vector bring to the table as apartner with FlexRay?Peteratzinger: Important was this We needto measure and calibrate signals internal tothe ECU. It might have been possible to turn to other sup-pliers for a solution. In this context there were many open

issues. During HANSER automotive’s FlexRay roduct Dayin 2004 we met with experts from Vector, discussed theseissues and formulated our requirements. Although no stan-dard existed yet at that time, Vector showed great interestin working with us, and wanted to implement a solution forus based on XC on FlexRay and then make it an official stan-dard in the ASAM working committee. It was also a good fit,because Vector’s CANape product was already being usedin the existing BMW tool environment, and this meant thatour developers already had experience with this tool.

Mr. Peteratzinger, in retrospect what is your assess-ment of this joint effort?From our perspective the collaboration with Vector wasvery good. Vector handled most of the standardi ation workand the first implementation. So I would like to express mysincere thanks to Vector Informatik. Calibration of ECUswith CANape and the XC Stack performed flawlessly fromthe start, requiring just minimal modifications.

Roel Schuermans, Graduate Engineer, is

Senior Product Management Engineer at

Vector Informatik for the “Measurement &

Calibration” product line. As an expert in

the FlexRay protocol he has been involved

in the development of XCP on FlexRay in

the ASAM working committee up to its

standardization and worked on its imple-

mentation in CANape.

The application is an active suspension control system. Each of

the four shock absorbers has a valve with dedicated electronics

to control it. The valve is able to generate different damping

properties, since its continuously variable aperture determines

how much and how quickly shock absorber oil is pushed from

the upper oil chamber to the lower one. The central control

module is interconnected with the damper modules, the so-cal-

led satellites, via FlexRay. Different than in previously imple-

mented suspension systems, while driving the vehicle the

shock absorber characteristics can be independently adapted

to the specific driving situation at all wheel suspensions. The

satellite electronics controls excitations at the individual

wheels, while the central ECU with its higher-level algorithms

monitors the overall effect on the chassis, and its control

system intervenes when pitching or rolling movements occur.

Direct access to internal ECU parameters is necessary to tune

the suspension system in driving trials and to assure system

functions in system integration.

A special measurement and calibration protocol is needed for this

XC on FlexRay. In efforts toward the standardi ation of XC on

FlexRay in February 2006, Vector helped to give shape to its fun-

damental principles on the ASAM working committee and imple-

mented an application concept in the Vector measurement, cali-

bration and diagnostic tool CANape. This solution provides access

to all relevant ECU parameters over the FlexRay bus.

The ECUs of the suspension system transport all functional con-

trol data in the static area of the FlexRay protocol. Although XC

communication is by definition allowed in both the static and

dynamic areas, BMW only utili es the dynamic area of the Flex-

Ray protocol for XC . It is also used for non-time-critical network

management messages and the Transport Layer mapping of

FlexRay (i.e. diagnostics, coding, flashing). Due to strict time

requirements of the control functions, the cycle time is 5 ms.

Scheduling is not just set for the currently implemented applica-

tion, it will also be applied in precisely the same form in the next

planned vehicle startups at BMW.

F I R S T F L E X R AY A P P L I C AT I O N AT B M W

Application of suspension control system with CANape

as the XCP on FlexRay Master

© automotive

4/2

27 Press Book_Seite_4-00_4-03:Press Report 2 09.02.2010 13:17 Uhr Seite 3

Page 139: Vector Press Book

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. +49 7 11 8 06 70-0

www.vector.com

Universal tool support simplifies your calibration of ECUs. The

versatile CANape tool lets you cover all application cases effort-

lessly:

> Quickly and reliably capture measured data from various

sources – synchronous and time-precise. Whether via CCP,

XCP-on-CAN/FlexRay/Ethernet or from external test

equipment

> Conveniently calibrate the parameters of your ECU algo-

rithms, either online in the ECU or offline in the Hex file

> Easily manage large amounts of calibration data – with full

traceability at all times – even on large project teams

> Simplify your tool environment by seamlessly integrated

diagnostic services and flash solutions

> Benefit from a universal tool chain with extensive rapid

prototyping capabilities and MATLAB/Simulink integration

Vector supports you from functional development to produc-tion-ready ECU, in the laboratory, on the test bench and du-ring driving trials.

Information and downloads: www.ecu-calibration.com

Diagnostics

Calibration

ECU

Distr. Systems

Deve

lopm

ent

Software

ECU

Management

Proc

ess

ECUCalibration

ECU

27 Press Book_Seite_4-00_4-03:Press Report 2 09.02.2010 13:17 Uhr Seite 4

Page 140: Vector Press Book

4/4

XCP-on-FlexRay at Audi

Starting in 2009, Audi will be implementing the FlexRay communi-

cation bus on its next generation of sporty luxury limousines. Since

FlexRay – compared to CAN – offers a significantly greater band-

width of 10 MBit/s. Many electronic chassis and driver assistance

systems are connected to this deterministic and time-triggered bus

system. For Audi developers, this decision meant that several thou-

sand parameters needed to be directly parameterized via an

AUTOSAR FlexRay stack. Compared to CAN, more than twice as many

measured values can be acquired simultaneously using XCP-on-

FlexRay. Furthermore, it is possible to transmit large quantities of

data with a higher throughput.

XCP on FlexRay

A laboratory model by itself is of limited use in determining the

parameters of a control algorithm. Although the algorithms of the

functions are permanently stored in the ECU-specific software

program, parameter values such as characteristic maps, curves and

values need to be recorded and optimized in measurements made

on the test bench and in driving trials. Audi engineers tune their

chassis and assistance systems in the framework of ECU calibration,

and they then load the parameter set files into the ECUs’ applica-

tion memory.

To calibrate ECUs centrally from a single master and via a uniform

interface – over the entire course of development – a standardized

measurement and calibration protocol is necessary. In 2003, ASAM

(Association for Standardization of Automation and Measuring Sys-

tems) defined the universal measurement and calibration protocol,

XCP, to serve this purpose. It is a logical advancement of CCP (CAN

Calibration Protocol) [1]. Communication via XCP is executed by the

Master-Slave principle. An XCP software module integrated in each

ECU serves as a slave. The greatest advantage of the XCP protocol is

that it offers separation of the transport and protocol layers. The

protocol layer is the same on all bus systems, regardless of whether

AUTOSAR-compatible XCP software modules for FlexRay ECUs

To adjust parameter values in FlexRay ECUs, Audi calibrates them via XCP-on-FlexRay. One of Audi’s requirements was AUTOSAR compatibility of the XCP embedded software modules in the ECUs. For this purpose Vector modified both the XCP master and slave software so that Audi’s electronic developers could perform efficient measurements and calibrations. This was possible thanks to dynamic allocation of the XCP bandwidth for FlexRay.

28 Press Book_Seite_4-04_4-09.indd 228 Press Book_Seite_4-04_4-09.indd 2 09.02.2010 13:25:46 Uhr09.02.2010 13:25:46 Uhr

Page 141: Vector Press Book

4/5

transport layer software modules for the slaves using XCP-on-

FlexRay from a single supplier.

XCP integration in the AUTOSAR model

Audi integrated the XCP software modules in the ECUs of various

suppliers. Even after the ECUs calibration is over, the XCP software

modules shall remain available. This makes efficient memory

they are CAN, FlexRay, Ethernet or SPI/SCI. In February 2006, ASAM

officially released Version 1.0 of the Transport Layer specification

for “XCP on FlexRay”.

On earlier CAN projects, the Audi development team had already

worked with XCP and CANape, the all-round tool from Vector for ECU

measurement, calibration and diagnostics (Figure 1). CANape has

supported an XCP-on-FlexRay interface since 2005. Audi decided to

source both the XCP master (CANape) and the protocol and

Figure 1: As the XCP-on-FlexRay master, CANape measures and calibrates individual nodes directly via FlexRay

Figure 2:Integration of Vector XCP soft-ware modules in an AUTOSAR 3.0 compatible application.

28 Press Book_Seite_4-04_4-09.indd 328 Press Book_Seite_4-04_4-09.indd 3 09.02.2010 13:25:47 Uhr09.02.2010 13:25:47 Uhr

Page 142: Vector Press Book

4/6

utilization and minimal execution time essential. In addition, the

XCP software modules have to be AUTOSAR-compatible. Vector

implemented this requirement on the XCP transport layer such that

it is placed above the AUTOSAR communication stack (FlexRay or

CAN) using the PDU router (Figure 2). In the integration phase,

the two XCP software modules are configured with the help of the

GENy configuration tool and a network description file in FIBEX

format.

Dynamic management of FlexRay bandwidth

Since AUTOSAR compatibility is required for the XCP-on-FlexRay

software modules, this means that the PC-supported master must

perform special tasks. During ECU calibration, the XCP master and

slaves exchange FlexRay messages. These frames contain either

Command Transfer Objects (CTO) with control commands or Data

Transfer Objects (DTO) with measured or stimuli data. When such an

XCP object is transmitted to the master (Figure 3), the “XCP trans-

port layer” transfers the data to the PDU router and thereby to the

“FlexRay interface”.

Because of the requirement for AUTOSAR compatibility, this

transfer must be made in the form of an AUTOSAR-conformant PDU

(Protocol Data Unit). Since the PDU originates from the XCP mod-

ule, it is called the XCP-PDU. The FlexRay interface completes the

received XCP-PDU by adding its own specific information in the

form of a PCI header (Protocol Control Information), thereby form-

ing an L-PDU (Data Link Layer PDU), which in turn is routed to the

“FlexRay driver”. That is how each participating software module

completes data received with module-specific information, making

it possible to reconstruct the data at the receiver. At the end of the

chain, the FlexRay controller transmits the XCP data as a frame

within a FlexRay slot (time window). Per the XCP specification these

frames must exclusively contain XCP data. Therefore, in the cross-

system FIBEX network description file, some slots in the FlexRay

schedule are exclusively to be reserved for XCP-PDUs and cannot

not be combined with PDUs issued from the application.

For the control commands (CTOs), two individual XCP slots are

sufficient for all ECUs thanks to the slave-referenced node address

(node address for XCP: NAX). The exact number of DTOs needed for

the measured data or stimuli data depends on the specific mea-

surement being executed and may vary widely over the course of a

calibration. So the need for XCP slots also varies for each ECU.

To ensure that Audi engineers can efficiently transmit XCP data

from multiple ECUs with a limited number of available XCP slots, it

is necessary to dynamically allocate the available bandwidth at

runtime to all participating ECUs. However, AUTOSAR does not allow

reconfiguration of the “FlexRay driver” at runtime. Therefore, in

the integration phase the “FlexRay drivers” are configured so that

all XCP slots are allocated to all of the ECUs. At the same time, the

XCP-PDU/L-PDU/XCP slot allocation is set in each slave (Figure 3).

Figure 3: XCP data are transmitted via various software modules.

28 Press Book_Seite_4-04_4-09.indd 428 Press Book_Seite_4-04_4-09.indd 4 09.02.2010 13:25:47 Uhr09.02.2010 13:25:47 Uhr

Page 143: Vector Press Book

payload, offers XCP frames that are many times longer than those

of CAN (8 bytes). The “Short Download” function simultaneously

encodes the address and contents in a single L-PDU, so that memo-

ry areas can be exchanged between the master and slave much

more quickly than with CAN.

Furthermore, XCP enables oversampling, which is independent

of the FlexRay cycle, in order to measure very dynamic signals

(Figure 5). CANape uses the so-called “In cycle multiple DAQ list

transmission” to acquire measured signals of a predefined DAQ list

and their time stamps multiple times per FlexRay base cycle (gener-

ally 5 ms long).

To significantly accelerate the start procedure before each mea-

surement, the necessary initialization also had to be optimized

thanks to the extension of the previous single “WRITE-DAQ” com-

mand. The new command “WRITE-DAQ-MULTIPLE” from the not yet

released XCP Protocol Layer 1.1 has been already used to configure

multiple signals by a single command.

4/7

XCP-ON-FLEXRAY AT AUDI

As a result, at the end of the configuration process of an ECU, a

unique XCP slot in the FlexRay schedule is available for each indi-

vidual XCP buffer. To attain the necessary flexibility over all ECUs,

the XCP transport layer command “FLX_ASSIGN” is used to modify –

on the XCP level – the allocation of XCP buffers to the different

L-PDUs (or FlexRay slots) before each measurement (Figure 4).

What is important here is to configure all participating ECUs with

the maximum available XCP slots, during software integration. This

results in the identical allocation of XCP slots on each ECU. Before

each measurement, only those XCP buffers that are actually needed

are selected. A central “dynamic bandwidth management” ensures

unique ECU slot allocations for XCP among all slaves. CANape han-

dles this task with the help of the ECU-specific A2L description files

that provide information about the internal ECU buffers.

XCP use is optimized thanks to FlexRay

The new dynamic bandwidth management is only one of the

FlexRay-specific CANape functions that support efficient ECU cali-

bration at Audi. In three additional functions, Vector specifically

exploits the fact that FlexRay, with it’s up to 254 bytes of data

Figure 4: Before each measurement, the XCP objects are dynamically configured in the dynamic segment.

28 Press Book_Seite_4-04_4-09.indd 528 Press Book_Seite_4-04_4-09.indd 5 09.02.2010 13:25:48 Uhr09.02.2010 13:25:48 Uhr

Page 144: Vector Press Book

4/8

Summary

Audi engineers rely on the MCD tool CANape to develop new models

in the context of test trials and calibration drives, in order to mea-

sure and calibrate internal ECU parameters with XCP-on-FlexRay.

Vector has extended its CANape and XCP software modules for this

purpose. Besides extending the XCP software modules for AUTOSAR

compatibility, a major task was to implement dynamic bandwidth

management for FlexRay. Choosing Vector as software supplier and

development partner was easy for Audi, since both the XCP soft-

ware modules for the slaves and the XCP master, CANape, come

from a single source – Vector – and are perfectly tuned to one

another. All extensions can be obtained for the current version of

CANape and the XCP-on-FlexRay software modules.

Translation of a German publication in Hanser Automotive, 7-8/2008

Literature:[1] www.asam.net

Links:Homepage Audi AG: www.audi.comHomepage Vector: www.vector.comProduct Information CANape: www.vector.com/canapeProduct Information XCP on FlexRay: www.vector.com/canape_flexray

Christian Braun, Audi studied Electrical Engineering at the Techni-cal College of Munich, specializing in Data Technology. After graduating in 1996, he joined Audi AG where he was responsible for electronic development of various ESP systems. Since 2006, he has been working in the area of Chassis Electronics Development at Audi where he is responsible for measure-ment tools and system networking.

Pascale Morizur, Vector studied Physics-Electronics at the Grande École ICPI in Lyon (France). After graduating in 1986, she worked for 10 years at MAN Commercial Vehicles in advanced develop-ment for the area of CAN, J1939 and Diagno-stics. Since 2005, she has been employed as a product management engineer at Vector Informatik GmbH in the area of Embedded Software Components.

Figure 5: The slave uses “Incycle multiple DAQ list transmis-sion” to measure very dynamic signals from a DAQ list. The signal is measured several times per FlexRay base cycle.

28 Press Book_Seite_4-04_4-09.indd 628 Press Book_Seite_4-04_4-09.indd 6 09.02.2010 13:25:48 Uhr09.02.2010 13:25:48 Uhr

Page 145: Vector Press Book

4/9

28 Press Book_Seite_4-04_4-09.indd 728 Press Book_Seite_4-04_4-09.indd 7 09.02.2010 13:25:49 Uhr09.02.2010 13:25:49 Uhr

Page 146: Vector Press Book

4/10

XCP at the Focal Point of Measurement and Calibration Applications

Today, control modules with more than 10,000 parameters are no

longer uncommon. Since numerous dynamic processes need to be

controlled in a vehicle, the typical tasks of ECU calibration include

optimization of control algorithms.

In the case of a PID controller, there are almost limitless possible

variations in calibrating the proportional, integral and derivative

components. Therefore, it usually takes some effort until a suffi-

ciently good compromise is found between stability, speed and

transient behavior. This can be accomplished by reading and modi-

fying parameters during runtime (Figure 1).

To keep the time and cost requirements for ECU calibration low,

engineers and technicians depend on powerful tools and standards

that enable flexible read and write access to variables or memory

contents. For this purpose, the CAN Calibration Protocol (CCP) was

created in the 1990s, a time in which CAN was the only dominant

networking system in the automobile. CCP was slated to become a

cross-OEM standard. However, additional bus systems such as

FlexRay, LIN, MOST, etc. came into play with the continued devel-

opment of automotive electronics. Since CCP’s use was restricted to

CAN-networked applications, it increasingly encountered limita-

tions in terms of its potential areas of use. This led to the develop-

ment of its successor, XCP.

Universal standardized protocol

The “Universal Measurement and Calibration Protocol” (XCP), like

CCP, also has its origins in the Association for Standardization of

Automation and Measuring Systems (ASAM) [1] and was standard-

ized in the year 2003. The “X” stands for the variable and inter-

changeable transport layer. XCP separates the protocol and trans-

port layers completely by means of a two-layer protocol, and it

takes a Single-Master/Multi-Slave approach. Depending on the

More and more electronic functions for safety and convenience are finding their way into the modern automobile. Since the number of ECUs is being held in check, however, this means that the complexity of individual devices must grow to compen-sate. Making an important contribution toward rationalization of the development process for these distributed systems is the XCP communication protocol, whose main tasks include measurement and calibration of ECU-internal variables at run-time. A tremendous advantage of this successor protocol to CCP is its independence of the physical transport layer.

29 Press Book_Seite_4-10_4-15.indd 229 Press Book_Seite_4-10_4-15.indd 2 09.02.2010 13:28:05 Uhr09.02.2010 13:28:05 Uhr

Page 147: Vector Press Book

4/11

identifies the amount of bandwidth still available and dynamically

allocates it to the current application data traffic very efficiently.

The available bandwidth is thereby optimally exploited in XCP com-

munication and hardly affects normal FlexRay communication at all.

Other options being considered for the future include XCP-on-

LIN; also possible would be XCP-on-K-Line or XCP-on-MOST, if there

is sufficient demand for them from user groups. The broad range of

supported transport layers enables simple migration from broad-

band solutions such as Ethernet or USB in the development phase

to a final CAN interface in series production.

Single-Master/Multi-Slave concept

The measurement and calibration system assumes the role of the

XCP Master, while the ECU acts as a Slave. Master and Slave each

communicate via the XCP drivers integrated in them. For each Slave

there is an ECU description file; information specified in this file

includes: Allocations between (symbolic) variable names and their

address ranges, physical meanings of the data, and the checksum

method being used. The XCP Master can read out all of the informa-

tion it needs from these A2L description files.

In communication via XCP a distinction is made between the

“Command Transfer Object” (CTO) and the “Data Transfer Object”

(DTO). The Master might send a command via a Command Transfer

Object over the bus to the ECU that acknowledges it over the same

path after executing the requested service. CTOs provided are: CMD

(Command), RES (Response), ERR (Error), EV (Event) and SERV

(Service Request Processor). The DAQ (Data Acquisition) and STIM

(Stimulation) Data Transfer Objects are used for event-driven read-

ing of measurement variables from memory, or for writing of values

to the memory of the XCP Slave (Figure 3).

transport layer in question, the protocol might be referred to as

XCP-on-CAN, XCP-on-Ethernet, XCP-on-UART/SPI or XCP-on-LIN, for

example (Figure 2).

A XCP Master is capable of communicating with different XCP Slaves

simultaneously. These include:

ECUs or ECU prototypes >

Measurement and calibration hardware such as debugging >

interfaces or memory emulators

Rapid prototyping hardware >

HIL/SIL systems >

To meet the challenge of serving as a universal communication

solution for a large variety of applications, the ASAM Working

Group emphasized the following criteria in the design of XCP: Mini-

mal resource usage in the ECU for RAM, ROM and required runtime,

efficient communication, easy implementation of the XCP Slave,

plug-and-play capability with low configuration effort, small num-

ber of parameters and scalability.

Interchangeable transport layer

XCP is capable of utilizing the same protocol layer on different

transport layers. This protocol is a universal measurement and cali-

bration protocol that operates independent of the network type

used. Currently, ASAM has defined these transport layers in stand-

ards: XCP-on-CAN, XCP-on-SxI (SPI, SCI), XCP-on-Ethernet (TCP/IP

and UDP/IP), XCP-on-USB and XCP-on-FlexRay. The last named

variant is the latest member of the protocol line-up, and it has

been specified since early 2006. One special technical feature of

XCP-on-FlexRay is its dynamic bandwidth control. A measurement,

calibration and diagnostic tool (MCD tool) such as CANape [2]

Figure 1: Optimization of a PID controller algorithm with the measurement, calibration and diagnostic tool CANape.

29 Press Book_Seite_4-10_4-15.indd 329 Press Book_Seite_4-10_4-15.indd 3 09.02.2010 13:28:06 Uhr09.02.2010 13:28:06 Uhr

Page 148: Vector Press Book

4/12

megabyte-size data volumes with 32-bit processors over high-

speed networks such as Ethernet. Since an XCP driver is made up of

mandatory and optional functions, driver size can be scaled to

match the available ROM/Flash size. In the ECU, resource usage is

characterized by whether the focus is on high data throughput or

on low processor load and RAM size. With regard to bus load, the

basic consideration is: Number of signal transmissions vs. bus

bandwidth. Overall, the XCP drivers are easy to implement and

require just a few parameters.

Event-driven periodic data acquisition

ECUs operate in discrete time intervals. The length of such a time

interval can be defined in a fixed way (e.g. 10 milliseconds) or the

length of a time interval may be event-dependent (e.g. one engine

revolution). In the case of fixed defined time intervals, the end of

the time slice is marked by the expiration of a timer. Expressed in

generalized terms, such expiration of a timer is also an event. The

task of the ECU is to complete all computational and control tasks

within the specific time slice. To obtain correlated data from the

XCP Slave, the DAQ mechanism of the XCP protocol is now used. In

this mechanism, the XCP-Master informs the Slave, before the

beginning of the measurement, which signals are to be measured

when certain events elapse. If the event now occurs (e.g. the 10

millisecond timer expires), the XCP Slave reads the previously

defined data from the memory, copies them to a protected RAM

area and sends them to the Master in the form of messages. This

assures that the values originate from the same event cycle and

correlate.

The Master receives the data provided with a time stamp and saves

them to a measurement file. The time stamp is either sent out by the

From automotive bus to standard PC interface

PC platforms are used almost exclusively as the Master for measure-

ment and calibration tasks. For direct connections to automotive

bus systems such as CAN, LIN, FlexRay, MOST or K-Line, the PC is

generally equipped with one or more hardware interfaces. Further-

more, the XCP Master is capable of utilizing standard PC interfaces

such as Ethernet, USB and RS232. Of course, in such solutions no

other costs are incurred for interface hardware. Measurement and

calibration systems with debugging interfaces (JTAG, TRACE, etc.)

and memory emulators can be implemented in this way. In princi-

ple, the standard PC interfaces are also well-suited for connecting

gateways between different bus systems; FlexRay-on-Ethernet

could handle this, for example. And finally, there are the conven-

tional analog and digital I/O channels that are utilized in many

development and test layouts involving especially time-critical

measurements.

A significant advantage in the use of XCP lies in the fact that a

single standardized protocol suffices for all of these applications.

Without XCP it would be necessary to implement a proprietary driv-

er for each communication channel. However, performance losses

need to be taken into account when multiple drivers are used in

parallel. Moreover, the risk of undesirable interactions and insta-

bilities increases.

Versatile, scalable and resource-economizing

One and the same XCP driver code is used for all communication

processes. It can serve to send just a few bytes that come from

small controllers and interfaces, e.g. 8-Bit processors with inte-

grated serial interface. Or the same code might be used to send

Figure 2: Separation of transport and protocol layers lets XCP utilize a large number of hardware interfaces.

29 Press Book_Seite_4-10_4-15.indd 429 Press Book_Seite_4-10_4-15.indd 4 09.02.2010 13:28:06 Uhr09.02.2010 13:28:06 Uhr

Page 149: Vector Press Book

4/13

storage schemes for characteristic maps, and much more. High-

performance calibration tools such as CANape from the Vector dis-

play the characteristic curves and maps clearly on the screen in

graphic diagrams or as numeric values in tables.

Rapid prototyping with CANape and XCP

During ECU development important functions are frequently swapped

out to external simulation systems, so that they can be computed

with less effort. It is not until the algorithms in the simulation model

have reached a certain maturity level that the developer generates

from them a source code that is compiled together with other ECU-

relevant codes and flashed in the ECU. However, even before this

occurs so-called “bypassing”, a coupling between a real ECU and its

model, is desirable so that tests and optimizations can be made inde-

pendent of the hardware at an early point in development.

In bypassing with XCP, the Master reads data from the ECU by

DAQ, passes the values to the model as input values and sends the

model’s results back to the ECU by STIM. Noteworthy in this context

is that normal PC platforms running the MCD tool CANape are suffi-

cient for bypassing and modeling. This is good news, since solu-

tions based on special real-time hardware would be many times

more expensive and would only be available in limited numbers in

development departments. CANape, as a highly optimized XCP Mas-

ter, simultaneously handles communication with the real ECU and

with the model running on the PC (Figure 4). The ECU parameters

and model parameters can both be calibrated via CANape and XCP.

XCP AT THE FOCAL POINT OF MEASUREMENT AND CALIBRATION APPLICATIONS

XCP Slave as a datum, or it is assigned to messages by the interface

hardware being used, e.g. CANcardXL. In the measurement file, all

data are synchronized in reference to the Master time base and are

then further processed, e.g. by visualizing the measurement values

on a global time axis. This allows multiple data channels of different

XCP Slaves to be displayed consistently in one diagram.

Besides the advantages of XCP compared to CCP already been

mentioned, XCP also offers support of so-called cold-start meas-

urements and internal ECU time stamps for tasks in cyclic data

acquisition. In cold-start measurement the ECU can be configured

so that it begins to periodically send out data immediately after

being activated, i.e. the Master does not need to initiate this

explicitly. If an internal ECU time stamp is being used, it is not the

time of receipt that is relevant for later evaluation in the measure-

ment and calibration system, rather it is the time at which the data

were created in the XCP Slave. This eliminates uncertainties attrib-

utable to possible delays in the transmission process, e.g. under

conditions of insufficient bus bandwidth or high load.

Optimizing characteristic curves and maps

Besides control algorithms based on mathematical models, ECUs

also utilize characteristic curves and maps composed of discrete

interpolation points. To achieve desired system behavior, such

characteristic value tables are usually set up and optimized experi-

mentally, e.g. at the test bench. A2L files serve to describe the

measurement variables and calibration parameters. The descrip-

tion options in the A2L files range from simple scalar parameters to

complex tables. Among other things, the descriptions encompass

the data types, conversion rules between raw and physical values,

Figure 3: Communication between Master and Slave. CTO = Command Transfer Object DTO = Data Transfer Object

29 Press Book_Seite_4-10_4-15.indd 529 Press Book_Seite_4-10_4-15.indd 5 09.02.2010 13:28:07 Uhr09.02.2010 13:28:07 Uhr

Page 150: Vector Press Book

4/14

Vector provides a free driver for setting up a XCP Slave that can

be downloaded at its web site [3]. The MCD tool CANape, in use as

an ECU calibration tool since 1996, is continuously updated as an

XCP Master to the latest level of XCP standardization based on

Vector’s active participation in ASAM working committees. CANape

is the first tool on the market to have an XCP-on-FlexRay interface.

In the development of the first production vehicle with FlexRay,

the BMW X5, this was a crucial factor in the decision by BMW engi-

neers to rely on Vector’s XCP stack and CANape for calibrating the

damper control system.

Translation of a German publication in Elektronik automotive, 4/2007

Literature and Links:[1] www.asam.net[2] www.vector.com/canape[3] www.vector.com/downloads/drivers/xcp.exe

Flashing via XCP

XCP also offers benefits to the user in programming ECUs. The data

in the ECU’s flash memory are only reprogrammable using specially

prepared flash routines, which must also reside in the ECU. In prin-

ciple, two approaches are conceivable: In solution 1, the flash rou-

tines are stored permanently in flash; first, this wastes memory,

and second, it presents a security issue for delivered vehicles. In

solution 2, a PC tool only loads a flash kernel to the microcon-

troller’s RAM via XCP if it is needed for reprogramming. Besides con-

taining the flash routines for erasing the flash memory and rewrit-

ing data, the flash kernel also contains its own bus and SCP drivers

for communicating with the PC tool over the bus interface.

Summary

XCP is a standardized and universally applicable protocol with much

rationalization potential. It is not only used in ECU development,

calibration and programming; it is also used to integrate any

desired measurement equipment for prototype development, func-

tional development with bypassing and at SIL and HIL test stands.

For quick access to internal data via microcontroller debugging

interfaces such as NEXUS, communication occurs over dedicated

hardware, trouble-free. This hardware converts communication

from NEXUS to XCP-on-Ethernet. The benefits to the user are inde-

pendence from tool producers with proprietary solutions, and reus-

ability of components.

Figure 4: Bypassing: Use of a standard PC with CANape as a test system.

29 Press Book_Seite_4-10_4-15.indd 629 Press Book_Seite_4-10_4-15.indd 6 09.02.2010 13:28:07 Uhr09.02.2010 13:28:07 Uhr

Page 151: Vector Press Book

4/15

XCP AT THE FOCAL POINT OF MEASUREMENT AND CALIBRATION APPLICATIONS

Andreas PatzerAfter a practical education to become an IT technician, Andreas Patzer studied Electrical Engineering at the Technical University of Karlsruhe between 1986 and 1993. He spe-cialized in measurement and control engi-neering as well as information and automati-on engineering. After receiving his degree, Mr. Patzer worked in the communications industry. In 2003 he joined Vector Informatik GmbH in Stuttgart where he handles the interface between customers, development and sales as Business Development Manager for the “Measurement and Calibration” pro-duct line.

29 Press Book_Seite_4-10_4-15.indd 729 Press Book_Seite_4-10_4-15.indd 7 09.02.2010 13:28:07 Uhr09.02.2010 13:28:07 Uhr

Page 152: Vector Press Book

4/16

Quantum Leap in Microcontroller Measurement Technology

The long-range radar sensor LRR3 (Long-Range Radar) from Bosch

operating at 77 GHz is the “sensory input“ for many safety-related

and driver assistance systems. They include various versions of Pre-

dictive Safety Systems (PSS) and Adaptive Cruise Control (ACC).

These smallest radar sensors in automotive industry, used in pro-

duction vehicles since the beginning of 2009, are distinguished by

their long acquisition range of 250 m and their wide aperture angle

of up to 45°. Together with a favorable price the application area is

broadened from luxury class to mid-class vehicles and commercial

vehicles. This development posed enormous challenges for Bosch

engineers when it came to performing measurement and calibra-

tion tasks. Along with options for measuring and logging data, it

was essential to have efficient methods for calibrating and flashing

as well as bypassing. All of these applications require extremely

high transmission rates with low latency times.

From a technical perspective, it made sense to implement a mod-

ular layout of the measurement system and to make use of a stan-

dardized PC interface. Development of a near-production ECU

enabled a simple transition from development to production later

on. To acquire the large number of measurement signals, up to

100,000, without errors, a data rate of at least 4 MB/s is necessary

while affecting the processor as little as possible.

Existing solutions: Low data rates and high CPU load

In solutions that utilize the standardized measurement and cali-

bration protocols [1] CCP or XCP-on-CAN, FlexRay, JTAG or SPI, a

driver integrated in the ECU is responsible for periodically reading,

copying and sending out the desired signal values. Due to the large

volume of data to be measured, the driver requires RAM memory

Innovative ECU measurement concept for maximum data rates with minimal effects on execution time

In the development of complex ECU applications, there are greater and greater quantities of data to be processed, more signals to be measured, and a growing number of parameters to be optimized. Previous methods for measuring, calibrating and flashing are increasingly encountering limits with regard to the necessary data throughput. It was in this context that Robert Bosch GmbH initiated a search for a more powerful and future-robust measurement concept for the next generation of its ECUs, in particular for the development of a new long-range radar sensor.

30 Press Book_Seite_4-16_4-19.indd 230 Press Book_Seite_4-16_4-19.indd 2 09.02.2010 13:26:12 Uhr09.02.2010 13:26:12 Uhr

Page 153: Vector Press Book

4/17

modular VX1000 system developed by Vector (Figure 1). The base

module primarily consists of a FIFO buffer, Dual-Port RAM (DPRAM)

and XCP Engine that also has dedicated RAM. Write accesses to data

within the two user-definable memory areas are transferred to the

FIFO buffer in the base module via the HSSL connection and the

debug interface. The data are further processed and written to the

DPRAM there. From a logical perspective, since this data is identical

to the data stored in the ECU, the DPRAM always contains a current

mapping of the data, mirroring memory areas in the ECU. The cru-

cial aspect of this approach is that all measurement processes occur

via the mirror memory. To initiate a measurement and thereby initi-

ate data transfer, it is sufficient to have the ECU write an event

number to a predefined memory address that is allocated to the

measurement data. At precisely this time point, the connection

between the FIFO and DPRAM is disconnected, “freezing” the mem-

ory map at the trigger time. This keeps the data to be measured

constant over the measurement period. The XCP Engine now pro-

cesses the data according to the protocol.

A transmission rate of up to 5 MB/s was achieved for the XCP-on-

Ethernet connection between the VX1100 measurement adapter

and processor resources that have limited availability. In addition,

there is increased loading of the data bus, which impacts the ECU

software in a negative way. Measurement data rates range from

50 KB/s for CAN up to maximum values of 400 KB/s for FlexRay,

JTAG and SPI (Table 1).

A high-performance debug interface on the micro-controller opens up new possibilities.

Bosch decided to join together with specialists at Vector to concep-

tualize an entirely new measurement and calibration system. As a

measurement interface it utilizes the Data Trace Interface, which

an increasing number of modern microprocessors are equipped

with for debugging purposes. More specifically, this is a standard-

ized Nexus Class 3 Interface, which can communicate every change

in the ECU’s memory to the outside world with minimal processor

load.

The fundamental idea of this approach is to acquire data from

the ECU via the debug interface and route it to an external meas-

urement adapter via a special high-speed cable. The data are trans-

mitted serially by a dedicated protocol. The external measurement

adapter is able to transmit the actual measurement data to the

application on the PC – independent of the ECU – via the standard-

ized XCP-on-Ethernet protocol.

In the project, the interface on the ECU was implemented by a

Plug-on-Device (POD). This POD is especially compact, and it is easy

to mount it on the ECU. The POD contains all of the electronics

needed to acquire and send out measurement data. To assure error-

free operation, the POD fulfills the same mechanical and electronic

environmental requirements as the relevant ECU. This allows the

POD to be installed in critical locations in the engine compartment,

for example, which was a key requirement in the development pro-

ject at Bosch.

Measurement adapter with mirror memory

A HSSL (High Speed Serial Link) cable up to 5 m in length connects

the POD to the VX1110 base module (measurement adapter) of the

ECU interface ECU software- ECU RAM- Measurement ECU execution Bypass latency modification reqmt. data rate time effects time

CCP/XCP on CAN CCP/XCP driver 1–2 KB 50 KB/s Moderate High software

XCP on FlexRay XCP driver software 2–16 KB 50–400 KB/s Large Moderate

XCP on JTAG/SPI Tables for DAQ transfer 4–16 KB 200–400 KB/s Large Moderate via software

Data trace VX1000 Low None 5,000 KB/s Very low Low

Table 1: Comparison of different methods of measurement data acquisition

Figure 1: The VX1000 system is distinguished by very high meas-urement data rates and very low software modification requirements and effects on ECU execution time.

30 Press Book_Seite_4-16_4-19.indd 330 Press Book_Seite_4-16_4-19.indd 3 09.02.2010 13:26:13 Uhr09.02.2010 13:26:13 Uhr

Page 154: Vector Press Book

4/18

and the measurement and calibration tool on the PC. A highly

robust, temperature-resistant HSSL cable was used to ensure abso-

lutely error-free data transmission in the engine compartment. In

case of transmission errors, a retransmission protocol provides for

quick repetition of data packets.

A look at the system’s performance demonstrates that the effort

was very worthwhile. The VX1000 measurement system impresses

with a measurement data rate of up to 5 MB/s, it enables a write

rate of about 1 MB/s and handles the 100,000 signals of the Bosch

application effortlessly. The precision of the time stamps is 1

microsecond, while bypass turnaround times of 300 microseconds

were attained.

From laboratory simulations to rapid prototyping

These properties make the system ideally suited for the two primary

applications at Bosch. The first application is bit-precise simulation

of real scenarios in the laboratory. This involved feeding certain

scenarios into the simulation without requiring real vehicle drives.

The second application, bypassing, is used to execute and test

functions outside of the ECU.

The described measurement system fulfills all requirements nec-

essary for the LRR development, and it is now being used in other

projects at the Bosch company. Compared to classic measurement

principles, the VX1000 solution offers performance increases by a

factor of 10 to 100 in all disciplines. The effect of measurements on

the ECU, with CPU loading of less than 1%, lies significantly below

usual values. The modular layout of the VX1000 system assures

cost-effective re-use as a measurement technology solution in sub-

sequent projects, even with different microcontrollers.

The right solution for any required measurement data rate

The VX1000 system completes Vector’s product line of measurement

and calibration tools at the top end of performance. Because it

could reach previously unattainable measurement data rates, it

fulfilled all expectations set in the Bosch project. Last but not

least, along with good cooperation between the two companies,

the CANape tool for measurement, calibration and diagnostics

made an important contribution to successful project completion.

CANape is primarily used to optimally parameterize ECUs. In the

development and optimization of driver assistance systems like

ACC, the CANape Option Advanced Multimedia offers specialized

capabilities. Among other things, it lets users display objects

detected by the system in a perspective view in time-synchronously

logged video images, which gives them a reliable means for verify-

ing object detection algorithms.

Other application options and outlook

The standardized XCP-on-Ethernet protocol can be used with both

the VX1000 product line and other measurement and calibration

tools. In the case of measurement and calibration tasks in the

engine compartment, the VX1000 is not really an off-the-shelf

product, since the harsh environmental conditions and limited

installation space generally require custom modification of the ECU

connection. In the framework of project work, Vector can work out

individual solutions in close dialog with its customers. Devices cur-

rently supported, besides the Freescale PowerPC, are the TMS570

from Texas Instruments and the Infineon TriCore processors with

DAP interface which are widely used in engine controllers

(Figure 2). DAP enables a cost-effective solution via a plug con-

nector on the mini-PC-board connected to the ECU. Cycle times of

50 microseconds are possible with the measurement and calibra-

tion system. These requirements are relevant in the development of

vehicles with electric/hybrid drives, for example.

Based on acceptance of the VX1000 system among automotive

OEMs and suppliers, all sorts of extensions and new features will be

offered in the near future. They include plans to support additional

processors. Well-known semi-conductor manufacturers have

approached Vector seeking recommendations on how to adapt their

processor architectures in the direction of optimal measurement

functionality.

Figure 2: High flexibility in measurement and calibration tasks is achieved by modular layout with base module, ECU interface, cables and POD.

30 Press Book_Seite_4-16_4-19.indd 430 Press Book_Seite_4-16_4-19.indd 4 09.02.2010 13:26:13 Uhr09.02.2010 13:26:13 Uhr

Page 155: Vector Press Book

4/19

QUANTUM LEAP IN MICROCONTROLLER MEASUREMENT TECHNOLOGY

Literature references: [1] XCP protocol: www.asam.net[2] Presentations by Riedl, A. and Kless, A. at the Vector Congress 2008.

Download at www.vector.com/veco08

Andreas Riedl (Dipl.-Ing. (FH))is Project Leader for engine controllers in the international field at Robert Bosch GmbH.E-mail: [email protected]

Alfred Kless (Dipl.-Ing. (FH)), a Business Development Manager at Vector Informatik GmbH since 2004, is responsible for the “Network Interfaces” and “Measure-ment and Calibration” product lines.E-mail: [email protected]

30 Press Book_Seite_4-16_4-19.indd 530 Press Book_Seite_4-16_4-19.indd 5 09.02.2010 13:26:14 Uhr09.02.2010 13:26:14 Uhr

Page 156: Vector Press Book

4/20

In the framework of model-based software development, applica-

tion functions are checked in an iterative process. This involves

repeated runs of the model in Simulink from The Mathworks.

Depending on the results, the developer may add function blocks

by drag-and-drop operation from libraries. These blocks are

parameterized either directly in the function block with a numeric

value or by defining a parameter and its value on the MATLAB con-

sole. To modify an existing parameterization, the same steps are

executed again, either by looking for a block in the model and

changing its value, setting the parameter and its new value on the

MATLAB console, or modifying an M-script and running it. To visu-

alize the signal responses that occur when the model runs in Simu-

link, the user instruments the model by attaching scope blocks to

each of the desired signals.

Use of the standardized XCP measurement and calibration pro-

tocol gives the developer a considerably more user-friendly way to

efficiently manage parameters and measure signals from the Simu-

link model without instrumentation.

The focus in ECU function development is always on finding the best possible control algorithms and parameter combina-tions. A new solution now offers users a single measurement and calibration tool with universal application – from initial model design to the production level ECU.

Efficient Analysis of Model Behavior in ECU Function Development

31 Press Book_Seite_4-20_4-23.indd 231 Press Book_Seite_4-20_4-23.indd 2 09.02.2010 13:23:35 Uhr09.02.2010 13:23:35 Uhr

Page 157: Vector Press Book

4/21

identification because the application’s data objects do not yet

have a real ECU memory address. After instrumenting the model,

using it with CANape is easy and efficient because it is possible to

generate a CANape project directly from the configuration of the

block’s dialog in Simulink and start CANape with the created

project.

Numerous measurement and calibration functions accelerate model optimization

The user visualizes the desired measurement parameters in the

measurement and calibration tool CANape – independent of the

hierarchical organization and without further instrumentation of

the model. It is possible to display any of the input or output vari-

ables of the model blocks and have their time responses displayed

in graphic form. Parameters and signals can also be conveniently

displayed and calibrated right in the visualization of the model

(Figure 2). Simulink users will feel right at home in the familiar

model representation that does not require conversion. In the

model, a modified parameter is passed directly to the XCP Server

via XCP. It adjusts values in the Simulink blocks and in the base or

model workspace; this is equivalent to manually setting the values

via the MATLAB console.

The function developer can change parameters of a full Simulink

model, or those of one or more subsystems, easily and convenient-

ly. This provides a way to test and optimize a Simulink model with

different parameter sets. CANape supports different file formats

here. Once the model has attained the desired maturity level, the

relevant parameters are saved to a parameter set file. The parame-

ter set management feature of CANape’s CDM Studio (Calibration

Data Management) is used to compare individual versions created

during model optimization and merge parameter subsets or work

packets to obtain optimal settings for the entire model. These set-

tings may be exported in the form of a MATLAB M-script so that

they can be used directly as a new version level in the MATLAB/

Simulink development environment (Figure 3).

Communication via XCP-on-Ethernet

The ASAM protocol XCP (Universal Measurement and Calibration Pro-

tocol) has become established as the preferred solution for measur-

ing and calibrating applications in ECUs. This approach gives appli-

cation engineers convenient access to measurement data and

parameters in the ECU via standard bus systems at runtime.

An ASAM standard A2L database (ECU description file) provides

all the information needed to access parameters and signals in the

ECU. It contains descriptions of relevant data objects within the

ECU’s software, such as characteristic values (parameters, charac-

teristic curves, maps) and measurement variables. The database

also connects the object names to their memory addresses in the

ECU and provides conversion rules for physical interpretation of the

raw data. Using such a database, measurement and calibration

tools can be used to acquire signal data or tune parameters as

desired by the user. Only a protocol driver is needed in the ECU; it

enables memory access at the ECU’s runtime.

In the “Simulink XCP Server” option for the CANape measurement

and calibration tool from Vector Informatik GmbH, an XCP driver is

integrated into the Simulink model. As a result, the model is

treated like a virtual ECU. The effort required to integrate the XCP

driver is minimal: a single block from the Simulink CANape library

is dragged and dropped into the model. Settings of the XCP trans-

port layer – such as the host name and server port – can be config-

ured in the block’s dialog. They are necessary, since the “XCP-on-

Ethernet” protocol is used to interconnect the measurement and

calibration tool with the Simulink model (Figure 1).

After this parameterization step, the XCP Server is ready to use.

The model’s A2L description file is generated from the block’s dia-

log. A virtual address is assigned to each Simulink object there.

This is how the Simulink XCP Server explicitly implements address-

oriented XCP operation for the Simulink objects. The user then

selects objects in CANape in the usual way – by their names. An

object’s address is read-in from the A2L and is sent as information

to the XCP Server in the model. This means that for data objects in

the XCP Server, the address in the A2L file is only leveraged for

Figure 1: Model objects can be measured and calibrated conveniently and with high performance using an XCP Server integrated in the Simulink model and an automatically gener-ated A2L file.

31 Press Book_Seite_4-20_4-23.indd 331 Press Book_Seite_4-20_4-23.indd 3 09.02.2010 13:23:37 Uhr09.02.2010 13:23:37 Uhr

Page 158: Vector Press Book

4/22

Summary

The implemented access to MATLAB/Simulink models via XCP in a

measurement and calibration tool simplifies the work of function

developers considerably. For example, the model is automatically

instrumented via XCP, and this replaces the very tedious process of

manual instrumentation. As a universal front-end for measurement

and calibration tasks, CANape offers added convenience in the test

phase of models in Simulink. When XCP is used as a universal proto-

col over the entire development process, this reduces overall pro-

cess complexity. The function development process is simplified

and accelerated, since just one protocol, one description file, and

one tool are used for all measurement, calibration, and stimulation

tasks.

MATLAB/Simulink as Time Master

Simulink models may run either slower or faster than real time,

depending on their complexity and computer performance. This

makes time stamps from Simulink indispensable. With each simula-

tion step in Simulink, the associated time stamp is sent via XCP.

Consequently, variations in the amount of the time needed for the

simulation steps are irrelevant. Each simulation step corresponds

to one time unit, regardless of how much real time is needed for it.

In the process, Simulink acts as a time master, and the measured

data sent out by the model can be visualized in CANape at simula-

tion speed. Depending on the complexity of the model, sensor data

from a one or two hour real test drive may be computed in just a

few seconds or in minutes. If a user wishes to simulate especially

large and complex models, standardized communication with XCP-

on-Ethernet enables better computing performance, since two sep-

arate computers are used.

The simulation results may be analyzed either manually or

through automation. In this process, an instance checks the

received results and makes a parameterization decision. Serving as

an instance is the CANape script language or an external software

program that CANape controls via one of the existing automation

interfaces.

Data from logged test drives may be fed into the model as an

input vector at runtime to stimulate the model with real data. The

function developer analyzes and optimizes system behavior under

comparable constraints. This eliminates the need for real, cost-

intensive test hardware entirely.

Figure 2: Efficient analysis of model behavior by convenient navigation and quick access to objects of the Simulink model in CANape.

31 Press Book_Seite_4-20_4-23.indd 431 Press Book_Seite_4-20_4-23.indd 4 09.02.2010 13:23:37 Uhr09.02.2010 13:23:37 Uhr

Page 159: Vector Press Book

4/23

EFFICIENT ANALYSIS OF MODEL BEHAVIOR IN ECU FUNCTION DEVELOPMENT

Figure 3: Overview of actions in CANape and their effects on the model in Simulink

André Ebner is employed at Vector Informatik GmbH as Technical Team Leader for the “Measurement and Calibration” product line.

Andreas Patzer is employed at Vector Informatik GmbH as Business Development Manager for the “Measurement and Calibration” product line.

Wojciech Przystas is employed at Vector Informatik GmbH as a Software Development Engineer for the “Measurement and Calibration” product line.

31 Press Book_Seite_4-20_4-23.indd 531 Press Book_Seite_4-20_4-23.indd 5 09.02.2010 13:23:37 Uhr09.02.2010 13:23:37 Uhr

Page 160: Vector Press Book

4/24

Accelerated Turbocharger Development

“Charging” of combustion engines is a core technology when it

comes to fulfilling requirements for low fuel consumption, low haz-

ardous emissions and quality over long service life, while simulta-

neously improving driving dynamics. Today, 98% of diesel vehicles

are equipped with turbochargers in the passenger car area, and on

trucks approx. 80%. With the introduction of direct injection, tur-

bocharging is also being used more frequently to improve the effi-

ciency of gasoline engines, although the considerably higher

exhaust temperatures make it essential to use higher grade materi-

als that are more expensive.

Development competence and innovative force in demand

When a gasoline engine is driven at high power output, the turbine

can become white-hot at exhaust temperatures of up to 1050°C.

Simultaneously, charger speeds typically reach 220,000 rpm, and

on smaller turbochargers, e.g. on the Smart car, they may even

reach 300,000 rpm. Accordingly, the challenges in the develop-

ment of turbochargers lie in the areas of materials engineering,

cooling, bearings and high-precision manufacturing/balancing of

the rotating components.

The company BorgWarner Turbo Systems with headquarters in

Kirchheimbolanden, in the German state of Rheinland-Pfalz, is one

of the leading producers of turbochargers; it manufactures about

3.5 million charging systems annually in Germany and about 6 mil-

lion worldwide. According to company information, BorgWarner in

Kirchheimbolanden currently has the most advanced development

center for turbochargers in the world. Besides various standard

products for diesel and gasoline engines, its product line also

includes advanced developments with multi-stage control of charg-

ing systems as well as the eBooster concept.

Efficiently developing control concepts with a cost-effective rapid prototyping solution

Turbochargers help engines, especially those with comparatively small displacements, to develop considerable torque and a high level of driving dynamics. Today’s engine charging systems must flexibly adapt to engine speed and momentary power requirements; therefore, turbocharger control requires careful optimization. For the automotive supplier BorgWarner Turbo Systems, use of the CANape software tool has produced enormous streamlining potential in developing demo vehicles and hardware equipment for road durability tests.

32 Press Book_Seite_4-24_4-27.indd 232 Press Book_Seite_4-24_4-27.indd 2 09.02.2010 13:24:51 Uhr09.02.2010 13:24:51 Uhr

Page 161: Vector Press Book

4/25

control concepts that are provided to the customer for use on test

benches or in test vehicles.

Working efficiently on the visualized model

In calibrating prototypes in the engine or vehicle, Vector’s CANape

measurement, calibration and diagnostic tool performs valuable ser-

vice. CANape is a powerful ASAM-conformant tool for all tasks relat-

ed to ECU calibration. Via physical interfaces such as CAN, FlexRay or

LIN and the standardized measurement and calibration protocols

CCP (CAN Calibration Protocol) and XCP (Universal Measurement and

Calibration Protocol), parameters can be measured from a PC at run-

time, and they can also be calibrated at runtime. At BorgWarner the

capability of visualizing the Matlab/Simulink models in CANape is

particularly beneficial. Without requiring tedious searches through

documentation, the user can recognize – directly from the visualized

model – which parameters need to be adapted for the desired modi-

fications. Search functions quickly lead to the desired parameters

and support convenient navigation through levels of the model.

In the production vehicle, the turbocharger application is run in

the engine controller. The sensor and actuator systems are also

connected here. During development, the turbocharger application

is swapped out to rapid prototyping hardware to enable flexible

testing of different software levels. This hardware consists of eval-

uation boards with integrated power electronics for driving the

actuators. This may involve use of an actuator/sensor combination

that differs from the one in the production vehicle (Figure 1).

CANape’s tasks here include calibration of the engine controller

and the rapid prototyping hardware as well as visualization of the

Simulink model. This is precisely how CANape closes the gap

between the graphic representation of the model, which lets the

user visualize the interrelationships between variables, and the

A2L-based calibration of the application. The parameter files

From the “turbo hole” to controlled charging

Due to its operating principle, high startup torque and high maxi-

mum power are mutually exclusive in simple turbocharger designs.

That is, either a compact system is constructed for high charge

pressure at low engine speeds or a large system optimized for high

speeds is constructed that neglects the desired dynamics in the

lower speed, which is then called a turbo hole.

Over the course of time, extended charging concepts have been

developed to overcome this handicap, e.g. the wastegate charger

equipped with bypass valve or the variable turbine geometry (VTG)

that has become a standard today. Its adjustable vanes can be flex-

ibly adapted to the exhaust gas flow. The latest developments

include two-stage controlled charging with two charger systems in

series and the eBooster, in which an electrically driven flow com-

pressor supports the turbocharger.

Turbochargers increase complexity of engine control

The more refined the designs for charge pressure control, the

greater the requirements for turbocharger control. In addition, it

was necessary to acquire turbocharger speeds, exhaust gas back-

pressures and underlying parameters such as angles or positions of

actuator elements by sensors and process them in the ECU. Actua-

tors on the turbocharger consist of electrically or pneumatically

actuated components for adjusting the vanes or actuating flaps

and valves.

Control of the turbocharger is an integral component of engine

control, and it therefore falls under the area of responsibility of the

automotive OEM. In view of rising complexity, however, OEMs are

relying on the support of turbocharger producers in implementing

charge system control. In the development phase, BorgWarner uses

the Matlab/Simulink program package to design the relevant

Figure 1: CANape is used to visualize the Simulink model and serve as a measurement and calibration tool for the engine controller and rapid prototyping hardware

32 Press Book_Seite_4-24_4-27.indd 332 Press Book_Seite_4-24_4-27.indd 3 09.02.2010 13:24:52 Uhr09.02.2010 13:24:52 Uhr

Page 162: Vector Press Book

4/26

created in optimization of the turbocharger application may of

course be exported from CANape and read back into Matlab/Simu-

link. Since this layout is well-suited to both test stands and test

vehicles, BorgWarner also implements it in road durability tests.

Outlook for the future

To achieve an even more efficient solution, BorgWarner is now test-

ing CANape in conjunction with a PC as a rapid prototyping plat-

form. In this case, the system makes use of a DLL generated from

the Simulink model, which runs in the CANape context. The Matlab

integration package supplied with CANape provides a CANape tar-

get with which the user generates CANape-specific code in the real-

time workshop. The generation provides the DLL with an XCP inter-

face, so that the user can access the DLL in measuring and cali-

brating as if it were running on a rapid prototyping platform

(Figure 2).

Together with the PC that is present anyways, CANape replaces

the prototyping hardware. If the XCP protocol is used in communi-

cation with the ECU, CANape can simultaneously be used as a

bypassing coordinator. The ECU data is measured in real time via

the tool, is passed to the compiled DLL model of the turbocharger

control system, is processed there and written back to the engine

controller ECU. The big advantage of this bypassing method is that

the DLL can be calibrated exactly like a real ECU. Parameter

changes take effect immediately, without requiring the detour of

making a modification in Simulink and then regenerating the code.

These applications point out the capabilities of high-perfor-

mance development and diagnostic software in practice. CANape

makes part of the hardware equipment superfluous, saves on

licenses for modeling software and noticeably accelerates develop-

ment progress due to fewer compiler runs. Calibration engineers at

BorgWarner benefit from visualization of the Simulink model,

including all of its key parameters. Even heightened real-time

requirements do not pose any problem here, since bypassing cycle

times as short as 2 ms are possible on PC platforms.

Translation of a German publication in Hanser Automotive, 11/2007

Links:Homepage BorgWarner Inc.: www.borgwarner.comHomepage Vector: www.vector.comProduct Information CANape: www.vector.com/canape

Figure 2: PC and CANape used as rapid prototy-ping environment with supplemental bypassing capability.

32 Press Book_Seite_4-24_4-27.indd 432 Press Book_Seite_4-24_4-27.indd 4 09.02.2010 13:24:52 Uhr09.02.2010 13:24:52 Uhr

Page 163: Vector Press Book

4/27

ACCELERATED TURBOCHARGER DEVELOPMENT

Gerd Spinner, BorgWarner Turbo Systemsis employed in the Product Development area at BorgWarner Turbo Systems Engineering GmbH.

Andreas Patzer, Vector Informatik is employed at Vector Informatik GmbH as Business Development Manager for the “Measurement and Calibration“ product line.

32 Press Book_Seite_4-24_4-27.indd 532 Press Book_Seite_4-24_4-27.indd 5 09.02.2010 13:24:53 Uhr09.02.2010 13:24:53 Uhr

Page 164: Vector Press Book

4/28

Optimizing Driver Assistance Systems

ACC (Adaptive Cruise Control) systems monitor the corridor in front

of a vehicle, detecting vehicles ahead and maintaining the distance

to these vehicles desired by the driver. ACC systems also adjust the

car’s current speed to the traffic situation by automatically reduc-

ing engine torque, braking, and accelerating again, if necessary. To

maintain the correct distance to the vehicle ahead at any speed,

ACC systems require very complex and precise computing algorithms.

What sounds relatively simple is in reality a great challenge for

the development engineers, because a driving situation that a

human driver is able to evaluate effortlessly is a nearly endless

array of numbers in an ACC ECU. A forward-looking radar unit sup-

plies coordinates of objects in cartesian form, i.e. in the X direction

(car’s longitudinal axis) and Y direction (car’s transverse axis), or

as polar coordinates with vehicle distance and azimuth angle. From

these, the ACC ECU concludes whether the distance to the car ahead

is sufficient, whether braking needs to be initiated or whether it is

possible to accelerate.

The evaluation electronics must also decide whether the acquired

object should even be considered as a relevant control object,

because the aperture angle of the radar sensors also detects any

objects adjacent to the roadway. While radar scanning initially

finds many objects, only the data of vehicles in one’s own lane may

be utilized for adaptive distance control.

This is not a trivial task, since information from the radar sensor

system is not always clear and unambiguous. Some of the radar

reflections are bumps in the road or simply false reports. This indi-

cates just how important it is to conduct a check of the acquired

data (signals) based on visible evidence (the video image). The

reliability and operating safety of this system, with its acceleration

and braking maneuvers, is in the truest sense a matter of life or

death. Faulty behavior could lead to vehicle reactions that are

incomprehensible to the driver.

For this reason, additional data are utilized at BMW to determine

the exact distance between vehicles and exclude irrelevant objects.

Verification of Object Recognition Algorithms by Driver Assistance Systems

Driver assistance systems address the issue of growing traffic volume by offering significant relief to drivers. To obtain an objective assessment of control algorithms in the development of such systems, BMW is relying on the support of the CANape measurement and calibration tool. Many suggestions by Munich’s leading car producer also flowed into the design of an extension that effectively handles the special requirements involved in calibrating driver assistance systems.

33 Press Book_Seite_4-28_4-31.indd 233 Press Book_Seite_4-28_4-31.indd 2 09.02.2010 13:28:19 Uhr09.02.2010 13:28:19 Uhr

Page 165: Vector Press Book

4/29

To achieve optimal control functionality in the ECU, it is necessary

to make numerous parameter modifications in an iterative process

that can be performed online or offline with CANape. BMW utilizes

the CANape Option “Advanced Multimedia”, an extension especially

designed for developing driver assistance systems. A core element

here is the Multimedia Engine, which displays ECU signals and

information computed from them in 3D perspective in the video

display. The relevant ACC coordinates can then be placed over the

video image as defined bitmap information in 3D perspective (Fig-ure 2). Only by means of such visual “matching” is it possible to

objectively assess the original mass of numbers. The BMW develop-

ers no longer just get coordinate information on the positions of

objects ahead of the driver; they can also immediately observe and

verify them in a video image – from a bird’s eye perspective or side

view. Thanks to the saved information, it is possible to study real

driving situations – which are normally never one-hundred percent

reproducible – in the laboratory and efficiently adapt the control

algorithms.

Environment detection with the camera

A coordinate transformation is necessary to represent object data

from the ECU as geometric objects in the Video Window. To cali-

brate the connected camera, all the BMW developers need to do is

click eight reference points whose coordinates are known. Based on

stored information, the tool automatically computes a coordinate

transformation for each detected object – from global coordinates

to image coordinates – and then displays the objects accordingly in

the video image.

Besides dynamic driving data, data from GPS navigation are also

used, for example.

Since there were no suitable products on the market, BMW ini-

tially supported the ACC development process by a tool it had writ-

ten in-house, which helped engineers reach an objective assess-

ment of the control algorithms. For production development, how-

ever, BMW is now increasingly relying on standard products that

can also be used by its suppliers.

Tool-supported evaluation of sensor data and driving impressions

Ever since the CANape Option “Advanced Multimedia” (AM) became

available, BMW has been using this tool more intensively on pro-

jects and in production development. The tool’s standardized cali-

bration protocols and flexible interfaces enable simple integration

into an existing tool environment, leave room for engineering

extensions and offer maximum future compatibility, e.g. for obtain-

ing objective test results to evaluate the assistance systems of

suppliers.

Even the base version of the measurement, calibration and diag-

nostic tool CANape from Vector is able to record all ECU-internal

data time synchronously (Figure 1):

Signals from CAN, LIN and FlexRay bus with the CCP/XCP calibra- >

tion protocols

Peripheral measurement technology >

Video and audio signals, and >

GPS signals (optional). >

Figure 1: Time-synchronous real-time acqui-sition and visualization of internal ECU signals via CCP/XCP, and of sig-nals from CAN, LIN and FlexRay bus-es and external measurement equipment via CANape.

33 Press Book_Seite_4-28_4-31.indd 333 Press Book_Seite_4-28_4-31.indd 3 09.02.2010 13:28:20 Uhr09.02.2010 13:28:20 Uhr

Page 166: Vector Press Book

4/30

ional extensions. For example, today – at the request of BMW

developers – a so-called “driving tube” is generated with data from

the ACC ECU; it is then represented in the video image as either a

bird’s eye view or a 3D perspective. This driving tube corresponds

to a virtual driving lane that demarcates the presumed future path.

This defines the corridor ahead of the vehicle that is relevant for

distance computation. Objects detected by the ACC system lying

outside the driving tube do not need to be considered in distance

control, and they are therefore represented by a different frame

color. Also part of the evaluation is highlighting traffic signs and

traffic lights. Theoretically, the tool can be used to represent up to

50 different objects simultaneously.

Similarly high requirements are placed on the hardware. The

volume of accumulating data and enormous computational

demands on the computing platform are still a great challenge.

Previously, two PCs were needed to assure the specified perfor-

mance. But this required manual data synchronization, since only

one of the computers could access the internal ECU signals. Today,

a dual-core computer platform is used for the ACC computations.

Since parallel recording of multiple video sequences and processing

of FlexRay data place increased demands on the CPU, BMW experts

are seeking more balanced utilization of the two computing cores.

Outlook

By visually comparing those objects detected by the ECU with the

real environment, BMW developers now have an easy and efficient

way to verify the object recognition algorithms of their ACC ECU.

Cooperation between BMW and Vector is bearing further fruit, e.g.

improved processor loading of dual-core and quad-core computing

platforms in future CANape versions and functional extensions for

Vector also offers a suitable camera for the system, since BMW is

not the only customer who values a universal and tested solution.

ECU developers using CANape AM can use practically any desired

camera, from a webcam to a professional high-tech device, pro-

vided that it has a USB or Firewire port and a DirectX interface.

Optimal results are obtained with a camera that has a logarithmic

characteristic and 120 dB dynamic range that further enhances

image quality – both in tunnels and in direct sunlight. It is also

possible to connect analog cameras via a Frame Grabber interface.

Depending on the camera resolution, image refresh rate and num-

ber of cameras used, data might accumulate at rates of 20MByte/

sec or more. That is why developers work with reduced image reso-

lution; data compression units are also used to reduce the data

volume.

A number of standard pixel graphics are provided for object rep-

resentation in the video image. For example, a detected vehicle

is represented by a rectangular frame, and other objects might

be shown as an “X” or a line. In the process, it does not matter

whether the ACC information is obtained from radar, infrared or

ultrasonic sensors. It is also easy to assign signals to an object with

the user-friendly GFX Editor for graphics (Figure 3). In another

dialog of the GFX Editor, the user defines the type of visualization

for the specific object type. This involves defining any objects

desired and linking them to the desired graphic symbols. In addi-

tion, users can also integrate their own graphics.

Joint advanced development work

For BMW, cooperative teamwork with the tool producer is a prereq-

uisite for developing intelligent high-end systems. In this project,

good cooperation has led to ideas that have spawned real funct-

Figure 2: Objective evaluation of sensor data and subjective impressions during driving trials: object display from bird’s eye perspective and overlay on video image in the Multimedia Window

33 Press Book_Seite_4-28_4-31.indd 433 Press Book_Seite_4-28_4-31.indd 4 09.02.2010 13:28:20 Uhr09.02.2010 13:28:20 Uhr

Page 167: Vector Press Book

4/31

developing parking assistance systems. In the next few years, safe-

ty systems will also be implemented based on environmental data

acquisition. They require even higher levels of computing perfor-

mance due to the need for comprehensive detection of the sur-

roundings and networking of active safety systems to Adaptive

Cruise Control sensors. CANape AM will also let BMW developers

focus entirely on their core tasks in the future: considerable

increases in driving convenience and further safety improvements

in highway transportation.

OPTIMIZING DRIVER ASSISTANCE SYSTEMS

Lorenz Eisenknappl, Vehicle Dynamics Development: Team Leader for Control System Measurement Technology, BMW AG

Walter Kagerer, Vehicle Dynamics Development, Driver Assistance and Active Safety, ACCSnG, ACC and DCC Calibration, BMW AG

Harald Koppe, Vehicle Dynamics Development: Measurement Technology for In-Vehicle Control Systems, BMW AG

Martin Lamprecht, Vehicle Dynamics Development: Measurement Technology for In-Vehicle Control Systems, BMW AG

Alexander Meske, Vehicle Dynamics Development: Driver Assistance and Active Safety, ACCSnG, ACC and DCC Calibration, BMW AG

Alfred Kless is Business Development Manager for the “Measurement & Calibra-tion” product line at Vector Informatik GmbH.

Figure 3: Use of the GFX Editor for convenient object-signal mapping and grouping in displaying objects

33 Press Book_Seite_4-28_4-31.indd 533 Press Book_Seite_4-28_4-31.indd 5 09.02.2010 13:28:20 Uhr09.02.2010 13:28:20 Uhr

Page 168: Vector Press Book

Trends in Em bed ded De vel op ment

With out fur ther ad van ces in stand ard i za tion it no longer bepos si ble to mas ter the grow ing com plex i ty of au to mo tiveelec tron ics. In the 1990s au to mo tive OEMs such as Daim ler -Chrys ler went to great ef forts to es tab lish the OSEK[1] em bed -ded op er at ing sys tem as a bind ing stand ard for in-house de -vel op ments and sup pli er com po nents. To day the re al-timeand mul ti task ing ca pa ble op er at ing sys tem is used by au to -mo tive OEMs and sup pli ers as the ba sis for im proved codequal i ty, good struc tur ing and in te gra tion of the com po nentsof dif fer ent sup pli ers. In “Her stel ler In i ti a tive Soft ware”(HIS)[2] too the large au to mo tive OEMs have come to anagree ment on uni form stand ards. Work ing com mit tees haveal so been es tab lished in the ar e as of soft ware, soft waretest ing, proc ess as sess ment, sim u la tion and tools as well asflash pro gram ming. The AU TO SAR (Au to mo tive Open Sys temAr chi tec ture) Con sor ti um is re spon si ble for the stand ards offu ture ve hi cle gen er a tions.

OSEK: Flex i ble and cal cu la bleA num ber of OEMs have cer ti fied OSEK im ple men ta tions. Ap -pli ca tions of the “os CAN” OSEK im ple men ta tion, for ex am -ple, range from nor mal ECUs to mul ti-bus gate ways and in -ter face hard ware. In the Vec tor In ter face for MOST VN2600the per form ance ca pa bil i ties of os CAN were put to the testun der a 133 MHz Al tera Ex cal i bur con trol ler proc ess ing up to35,000 Events/s, which cor re sponds to a da ta through put of1.7 MByte/s. At gate way pro duc er K2L os CAN-based so lu -tions have dem on strat ed fast re ac tion times and pre cise tim -ing.

An ECU for mul ti ple ap pli ca tionsA clear trend in au to mo tive net work ing is re duc tion in thenum ber of ECUs in a ve hi cle. To day up to 40 ECUs op er ate in alux u ry au to mo bile. To per mit im ple men ta tion of even morefunc tions, in the fu ture con sist ent ef forts must be made to -ward run ning as many ap pli ca tions as pos si ble with in thesame con trol mod ule. The OSEK mul ti task ing op er at ing sys -tem was spec i fied for this pur pose. How e ver, oth er prop er -ties are re quired of the op er at ing sys tem for use in safe ty-crit i cal sys tems and to in te grate the soft ware of dif fer entpro duc ers. For ex am ple, an ap pli ca tion must not dis turb oth -er ap pli ca tions run ning in par al lel.

Al ways in de mand: The right tim ingOne of the fo cal points in ad vanced de vel op ment of em -bed ded op er at ing sys tems, for fu ture OSEK ver sions and AU TO SAR, is the abil i ty to mon i tor soft ware be hav ior re lat ingto tim ing and mem o ry ac cess es. The most ad vanced meth odsfor mon i tor ing tim ing are pro vid ed by AU TO SAR-con form antim ple men ta tions. Meth ods such as “Ex e cu tion Time En force -ment” and “Ar riv al Rate En force ment” pro vide a man da to rymin i mum time budg et for low-pri or i ty tasks too; thesemeth ods not on ly de tect er rors, they can al so clear ly iden ti fytheir sour ces.

Re li a ble bound a ries for mem o ry pro tec tionIn the fu ture mem o ry pro tec tion func tions will re strict a task’s ac cess to the mem o ry space as signed to it. This is es -pe cial ly im por tant to pre vent write ac cess es to oth er da taseg ments, de tect stack over runs, and pro hib it ex e cu tion of

5/0

In the fu ture con tin u al ad van ces in the de -vel op ment of au to mo tive elec tron ics will pla-ce sig nif i cant new de mands on un der ly ingbase tech nol o gies. In spite of grow ing func -tion al i ty au to mo tive OEMs must keep costsun der con trol; one way to achieve this is bylim it ing the num ber of ECUs in a car. At thesame time ex tend ed safe ty and re li a bil i tycon cepts will be key ar e as of in ter est. In lightof the chal len ges and mul ti tude of elec tron ic com po nents, pow er ful tools for de vel op -ment, da ta man age ment and trans fer of soft ware mod ules in to a con trol mod ule’s flashmem o ry will con tin ue to gain in im por tance.

Re quire ments and fu ture con cepts in hard ware, soft ware and tools

34 Press Book_Seite_5-00_5-03:Press Report 1 09.02.2010 13:11 Uhr Seite 1

Page 169: Vector Press Book

ap pli ca tions and of fer a max i mum lev el of re li a bil i ty. A re lat -ed pro pos al for han dling this is sue in AU TO SAR is cur rent lybe ing dis cussed in a work ing sub com mit tee.

Bet ter hard ware sup port in the fu ture?The cit ed tim ing and mem o ry mon i tor ing func tions can on lybe im ple ment ed ef fi cient ly with suit a ble hard ware sup port.What are need ed for mem o ry pro tec tion are Mem o ry Pro tec -tion Units (MPUs) that are tai lored to the needs of au to mo -tive ap pli ca tions in terms of op tions of fered for num ber andsiz es of mem o ry blocks. In many cas es to day the small estunits that can be man aged are blocks 16 kByte in size. In theau to mo tive em bed ded field, how e ver, sub stan tial ly small ermem o ry units are need ed.

in cor rect code. On the oth er hand, tasks be long ing to thesame ap pli ca tion need to be able to ac cess the same mem o ryar e as, and spe cial sys tem func tions such as driv ers could re -quire un re strict ed mem o ry ac cess. A dis tinc tion is made herebe tween so-called “Trust ed Ap pli ca tions” with full ac cessrights and “Non-Trust ed Ap pli ca tions” with re strict ed ac cessrights. These names can lead to some con fu sion: Non-trust -ed Ap pli ca tions are stored pro grams that can not re al ly causeany dam age.

It is good de sign prac tice to place func tion al i ties in Non-Tru-st ed Ap pli ca tions when ev er pos si ble. Vec tor In for ma tikthere fore of fers im ple men ta tions that al so per mit call ing ofNon-Trust ed Func tions. They are in tend ed for safe ty-crit i cal

5/1

Fig ure 2: os CAN Tim in gA na ly zer en a bles sim u la tion of sched ul ing ta bles (sched ules) and com pu ta tion of sched u la bil i ty

34 Press Book_Seite_5-00_5-03:Press Report 1 09.02.2010 13:11 Uhr Seite 2

Page 170: Vector Press Book

Es sen tial ly the hard ware re quire ments of cur rent and fu tureOSEK re al-time sys tems can on ly be ful filled by a com pletere de sign of to day’s proc ess or cores. De sired fea tures are cur -rent ly be ing ne go ti at ed with sem i con duct or pro duc ers.Among the most im por tant re quire ments, be sides the namedmon i tor ing func tions, are an In ter rupt Con trol ler for dif fer -ent in ter rupt lev els with low la ten cy times, hard ware sup portin task switch ing, and proc ess or cores with as few reg is tersas pos si ble.

Can er ror-free em bed ded sys tems be de vel oped?In ter est ing pos si bil i ties for mas ter ing in dus tri al com plex i tyare be ing re searched in on go ing pro jects in volv ing the in -ten sive ap pli ca tion of math e mat ics to the en gi neer ing sci en -ces. Sys tem at ic an a lyt i cal meth ods en a ble de tec tion of er -rors in re al-time sys tems that would oth er wise not even bere vealed in ex ten sive test ing. Sci en tists on the Ver i soft pro-ject have tak en this one step fur ther in con clud ing that it ispos si ble to de vel op er ror-free em bed ded sys tems and elec -tron ic com po nents. En tire sys tems con sist ing of hard ware,soft ware, op er at ing sys tem com mu ni ca tion, ap pli ca tions,etc., might be uni ver sal ly ver i fied by meth ods of for mal ver i -fi ca tion.

Re pro gram ming ECUsRe pro gram ming of ECUs by flex i ble flash pro gram ming iscon tin u ing to draw great er in ter est. The is sues here do notre late to the ac tu al flash pro gram ming tech nol o gy as muchas they do to the or gan i za tion and han dling of the over allproc ess. Con straints vary from project to project, where by inad di tion to OEM and mod el spe cif ic re quire ments, oth er re -quire ments must be con sid ered such as hard ware prop er ties(boot load er, flash in i ti a tion), flash for mats, trans port anddi ag nos tic pro to cols. If flash da ta pass through var i ousgate ways, for ex am ple, it must be as sured that no da ta canbe lost there. These and sim i lar ques tions must be an sweredin di vid u al ly for each par tic u lar sit u a tion. In prac tice it is notre al ly pos si ble to im ple ment a sim ple au to mat ic ap proachhere. Giv en these con straints, the ra tion al han dling of flashproc ess es con tin ues to gain in im por tance. There fore, onetrend leads in the di rec tion of uni form man age ment of flashproc ess es in stand ard ized for mats. For this pur pose, tools

from Vec tor In for ma tik save the flash da ta to geth er with ref -er en ces to the flash jobs in a ODX flash da ta con tain er.In some cas es it may be nec es sa ry to en a ble mod i fi ca tion offlash da ta in the field by means of a post-build proc ess. Inthis con text it is im por tant to re cal cu late check sums andsig na tures, in ad di tion to oth er pa ram e ters, and to sendthem to the flash boot load er dur ing a flash up date. The CA Na pe Graph and CAN di to tools, both on line and off linepost-build proc ess es can be han dled in an el e gant way, whe-re by a script lan guage op ti mized for flash and di ag nos tictasks is very help ful.

Man a ging dif fer ent mem o ries in the ECUAn im por tant top ic in re pro gram ming is the man age ment ofdif fer ent mem o ry types in an ECU. Ris ing com plex i ty, e.g. inmul ti proc ess or or dis trib ut ed sys tems, goes hand in handwith great er mem o ry re quire ments and the use of dif fer enttypes of mem o ry. Some con ven tion al non vol a tile mem o ryde vi ces have very dif fer ent phys i cal char ac ter is tics. Amongthe im por tant dif fer en ti at ing char ac ter is tics of non vol a tile

5/2

Fig ure 4: Flash pro gram ming

34 Press Book_Seite_5-00_5-03:Press Report 1 09.02.2010 13:11 Uhr Seite 3

Page 171: Vector Press Book

mem o ry types are: Size of the write seg ment, size of the era-se seg ment, max i mum num ber of pro gram ming cy cles, andtimes re quired to pro gram and erase.The lat est flash mem o ry is based on NOR Stacked Gate andMON OS (Met al Ox ide Ni tride Ox ide Sil i con) tech nol o gies. Be -gin ning about 2008 new mem o ry pro ducts are ex pect ed thatare based on Fe RAM (fer ro-elec tric), MRAM (mag ne to-re sist -ive) and oth er tech nol o gies, which could per mit un lim it ednum bers of write/erase cy cles.

HIS-stand ard ized Mem o ry Driv er In ter faceWith the goal of achiev ing uni form mem o ry man age ment,the HIS Au to mo tive Group de fined a stand ard for the Mem o -ry Driv er In ter face that is ex pe ri enc ing grow ing sup portfrom sem i con duct or pro duc ers. The in ter face pro vides func -tions for in i tial iz ing, de-in i tial iz ing, eras ing, pro gram mingand read ing da ta. In an im ple men ta tion based on the HIS in -ter face a Mul ti ple Mem o ry Type I/O Man a ger used to ac cessvar i ous types of mem o ry. The mem o ry con fig u ra tion can bede fined con ve nient ly with the Ge ny tool from Vec tor. The us -er ben e fits from max i mum flex i bil i ty in ac cess ing dif fer entmem o ry types, in clud ing ac cess by SPI (Se ri al Pe riph er al In -ter face).

Time is mon ey: Ac cel er at ing flash proc ess esDe pend ing on the num ber of ECUs, it may take a full hour ormore to trans fer da ta in the pro duc tion en vi ron ment. There -fore au to mo tive OEMs and tool sup pli ers are con sid er ingadd ing great er band width to the trans port me dia as well asda ta com pres sion. Sci en tif ic stud ies in di cate that for com -pres sion pur pos es a com bi na tion of the LZ77 meth od and anarith metic cod ing meth od would be ide al and might re duceda ta vol ume by up to one half.

TRENDS IN EMBEDDED DEVELOPMENT

5/3

[1] OSEK stands for “Of fe ne Sys teme und der en Schnitt stel len für die El ek -tron ik im Kraft fahrzeug” (Open Sys tems and their In ter fa ces for Elec -tron ics in Mo tor Ve hi cles).

[2] “Her stel ler” = Pro duc er or OEM

Au thor:

Pe ter Lieb scher (Grad u ate En gi neer) stud iedtel e com mu ni ca tions en gi neer ing at the Tech ni cal Col lege in Es slin gen, Ger ma ny. Since 2002 he has been em ployed as Busi ness De vel op ment Man a ger at Vec tor In for ma tikGmbH where he is re spon si ble for the Em bed -ded Soft ware Com po nents prod uct line.Tel. +49-711/80670-413,Fax +49-711/80670-111,

E-mail: pe ter.lieb scher@vec tor-in for ma tik.de

34 Press Book_Seite_5-00_5-03:Press Report 1 09.02.2010 13:11 Uhr Seite 4

Page 172: Vector Press Book

DEVELOPMENT TOOLS

41 June 2006

Timing, memory protection and errordetection in OSEK systems

� The real-time and multitasking operating sys-tem OSEK is the standard in automotive em-bedded developments today. Its most importantproperties include low consumption of proces-sor resources and memory, and event-driventask management that effectively handles bothcyclic and non-cyclic program blocks. Contin-uing advances in automotive electronics andthe new HIS and AUTOSAR standardizationinitiatives also place new demands on theoperating system. Areas of emphasis in futureoperating system versions will be timing andmemory protection.

In the 1990s the large automotive OEMs intro-duced the OSEK/VDX operating system spec-ification with the goal of establishing a uniformstandard for software in electronic controlunits. The wide variety of proprietary embed-ded operating systems at numerous suppliershad proved to be an obstacle to smooth integra-tion in light of the growing significance ofautomotive electronics. Besides defining theactual operating system core, OSEK also definescommunication services and functions fornetwork management.

Since most automotive suppliers had alreadycommitted to a preferred operating system be-forehand, automotive OEMs had to introduceOSEK persuasively in some cases. Daimler-Chrysler, for example, made OSEK mandatory

as a standard for new developments, both forin-house developments and those at suppliers.The company organized OSEK training cours-es, created OSEK design guides and supportedoperating system producers. It also financedone OSEK licence per supplier, whereby onlycertified OSEK operating systems were permit-ted. The costs of introduction reached a highpoint in 2002 and then dropped significantly. Inthe meantime OSEK has generated its own suc-cess, and now most ECUs in the automotivefield run on OSEK operating systems.

Efforts have paid off: applications based onOSEK have fulfilled expectations by their im-proved code quality, structuring and the abili-ty to integrate components from different sup-pliers. At gateway producer K2L solutions withosCAN, the OSEK/VDX-conformant operatingsystem from Vector Informatik, have demon-strated fast reaction times and precise timing.Last but not least, what has proven to be deci-sive for OSEK in conjunction with a table-driv-en interpreter concept are flexibility gainsleading to shorter development times, higherquality and functionality and ease in creatingvariants. Leading the way here were compar-isons between OSEK with its preemptivescheduling and a fixed coded static approachwith cooperative scheduling. The “osCAN”OSEK implementation has proven itself, notonly in ECUs but also in the interface hardware

of the same company. In the MOST InterfaceVN2600 osCAN’s capabilities were put to thetest under a 133 MHz Altera Excalibur con-troller: its processing of up to 35,000 Events/scorresponds to a data throughput of 1.7 MB/s.

Requirements of an operating system grow inparallel with the continuing penetration of elec-tronic technologies. In particular the advance ofsafety-relevant applications in the vehicle, suchas fully electronically controlled steering andbraking systems (X-by-wire), make determin-istic behaviour essential under peak loads andfault conditions. For example, the specificationof OSEKtime will supplement the event-driv-en OSEK with a time-triggered variant.

Fault tolerance, error detection mechanismsand memory protection also play an importantrole in achieving system reliability. This has ac-quired special relevance, because in the futurean ECU will handle multiple applications run-ning simultaneously. In “Hersteller InitiativeSoftware” (HIS; Hersteller = producer or OEM)the large German automotive OEMs havecome to an agreement on the standards need-ed to implement the named functions. Workingcommittees have been established in the areasof software, software testing, process assess-ment, simulation and tools as well as flash pro-gramming. The AUTOSAR (automotive opensystem architecture) consortium is responsible

by Peter Liebscher, Vector Informatik

A powerful certified OSEK implementation or

AUTOSAR-conformantembedded operating

system, together with a universal tool-chain,

will make it possible tomaster the complexity

of future electronicdevelopment.

Figure 1. Representation ofgateway, system and bus APIs

5/4

35 Press Book_Seite_5-04_5-07:Press Report 1 09.02.2010 13:06 Uhr Seite 1

Page 173: Vector Press Book

June 2006 42

DEVELOPMENT TOOLS

for the latest standards for future vehicle gen-erations, whereby the HIS group is integratingits results into AUTOSAR and is representinguniformity interests there. When one considersthat over 50 ECUs operate on a luxury automo-bile today and that there appears to be no endto potential new automotive electronic applica-

tions in the foreseeable future, it becomesclear why limiting the number of control mod-ules in the vehicle has become a pressing topic.This objective can only be achieved if multipleapplications run on the same control module.The multitasking OSEK operating system wasspecified for this purpose. However, other

properties are required of the operating systemfor use in safety-critical systems and to integratethe software of different producers. For exam-ple, an application must not disturb other ap-plications running in parallel. To prevent thisfrom happening, new operating system featuresare aimed at optimal monitoring of the timebehaviour of individual tasks and universalmemory protection.

Progress has varied considerably in the variousdevelopment levels as a result of these efforts.OSEKtime, specified since 2001 for time-trig-gered tasks, with its deadline monitoring, onlybegins to cover functions that will be necessaryin the future. Deadline monitoring detectswhether a task has ended by a prescribedpoint in time. Unfortunately, the method can-not discern the causes for deadline violations.For example, if the monitored task was inter-rupted by a higher-priority task, then themonitored task is not really responsible forbeing unable to satisfy the prescribed time win-dow. In HIS-conformant OSEK extensionsmemory protective functions are defined in ad-dition to deadline monitoring. The most ad-vanced is AUTOSAR with its “execution timeenforcement” and “arrival rate enforcement”methods, which give low-priority tasks amandatory minimum time budget, too. Thesemethods are able to clearly identify errorsources. Furthermore, in the various operatingsystem versions, Vector Informatik has integrat-ed options for run-time measurements.

Memory protection functions restrict a task’saccess to the memory space assigned to it. Thisapplies especially to preventing write accesses toother data segments, detecting stack overruns,and detecting execution of incorrect code.Tasks belonging to the same application, on theother hand, must be able to jointly access thesame memory areas. However, special systemfunctions such as drivers could require full un-restricted memory access.

A distinction is made here between so-called“trusted applications” with full access rights and“non-trusted applications” with restricted ac-cess rights. These names can lead to some con-fusion: non-trusted applications are programsthat, due to restricted memory access, cannotcause any damage. The trusted applications, onthe other hand, are given quasi blind trust. Thelatter are easy to use but represent risks to sys-tem security and cannot provide identificationof errors or error sources. It is good designpractice to place functionalities in non-trustedapplications whenever possible. Vector Infor-matik therefore offers implementations thatalso permit calling of non-trusted functions.They are intended for safety-critical applica-tions and offer a maximum level of monitoring.A related proposal for handling this issue in

Figure 2. Function block diagram with MOST interface VN2600 and an Altera Excalibur controller

Figure 3. Deadline monitoring to detect deadline violations. The error source of Task 2 is not foundin Task 1.

Figure 4. Tasks belonging to the same application must be able to access the same memory areas.

5/5

35 Press Book_Seite_5-04_5-07:Press Report 1 09.02.2010 13:06 Uhr Seite 2

Page 174: Vector Press Book

DEVELOPMENT TOOLS

AUTOSAR is currently being discussed in aworking sub-committee. The cited timing andmemory monitoring functions can only be im-plemented efficiently with suitable hardwaresupport. What are needed for memory protec-tion are memory protection units (MPUs)that are tailored to the needs of automotive ap-plications in terms of options offered for num-ber and sizes of memory blocks. In manycases today the smallest units that can bemanaged are blocks 16 KB in size. In the auto-motive embedded field, however, substantiallysmaller memory units are needed. Essentially,

the hardware requirements of current and fu-ture OSEK real-time systems can only be ful-filled by a complete redesign of today’s proces-sor cores. Desired features are currently beingdesigned together with semiconductor produc-ers. Among the most important requirements,besides the named monitoring functions, are aninterrupt controller for different interrupt lev-els with low latency times, hardware support intask switching, and processor cores with as fewregisters as possible. For hardware-related andtime-critical automotive applications whatcounts is the ability to react as quickly as pos-

sible. Many of these applications consist ofdrivers and interrupt service routines (ISRs)which in contrast to the workstation fieldbelong to the application here. It is problemat-ic that on today’s controllers the ISRs often canonly be disabled completely. In general,disabling mechanisms must be made moreefficient in implementations, since this basic

Figure 5. Phases of a task switch

Interested in more information?

Visit our specific website with links to:

�Real-time operating system for automotivecontrol units

�Protocols and drivers for CAN communication

�Flash programming via CAN and LIN

�Solutions for AUTOSAR by Vector

Simply type-in Reader Service #: 783 atEmbedded-Control-Europe.com/know-how

5/6

35 Press Book_Seite_5-04_5-07:Press Report 1 09.02.2010 13:06 Uhr Seite 3

Page 175: Vector Press Book

June 2006 44

DEVELOPMENT TOOLS

function is executed very frequently. The quicktask switches by which real-time embedded sys-tems “thrive” are currently given just rudimen-tary support in hardware. The majority of re-sources is consumed in saving and restoring thecontext. The context is made up of core regis-ters, register banks, memory access registers,floating point and arithmetic registers of thestack pointers, special peripheral units and anumber of operating system variables. A fullyhardware-supported context switch would beideal here.

Furthermore, it has been shown that processorswith a low number of registers offer better per-formance. Many registers can only be usedmeaningfully in typical workstation environ-ments, because that is where individual pro-gram sequences run for a relatively long timewithout interruption. A potential trend herecould lead in the direction of so-called softcoreprocessors and to compilers that permit con-figuration of the registers used. Interesting pos-sibilities for mastering industrial complexityare being researched in ongoing projects in-volving the intensive application of mathemat-ics to the engineering sciences. Systematic an-alytical methods can be used to reveal criticalsituations in the time behaviour of an OSEKsystem that would otherwise not be found evenby extensive testing. In this context, toolsfrom the SympTAVision company enable tar-geted searches for “bottlenecks” and “hotspots”, informing users of worst-case situations.The advantages of systematic analysis lie in

reduced testing effort, productivity gains,quality improvement and comprehensive sys-tem optimization. Scientists on the Verisoftproject have taken this one step further in con-cluding that it is possible to develop absolute-ly error-free embedded systems and electron-ic components. They turn to the methods offormal verification to verify entire systems con-sisting of hardware, software, operating systemcommunication, applications, etc. In coopera-tion with project partner Infineon, the TriCore2 processor, the future flagship of the compa-ny’s 32-bit microcontroller device line, offeredthe first evidence that this innovative technol-ogy could be applied to highly complex de-signs. The long-term Verisoft project set upunder the project leadership of Prof. Dr. Wolf-gang J. Paul, of the University of Saarbrücken,is being supported by the German FederalMinistry for Education and Research.

Foundations and base technologies have beencreated for achieving reliable electronic systemsin the automobile. Specific challenges must stillbe overcome by controller producers. Apartfrom that it is the responsibility of automotiveOEMs and suppliers to utilize the availableresources optimally. A powerful certified OSEKimplementation or AUTOSAR-conformantembedded operating system, together with auniversal tool-chain, will make it possible torationally master the complexity of futureelectronic development. �

5/7

35 Press Book_Seite_5-04_5-07:Press Report 1 09.02.2010 13:06 Uhr Seite 4

Page 176: Vector Press Book

Cur rent Chal len ges in Au to mo tive Net work ing

The top ic of AU TO SAR was a com mon thread through out the two-

day event spon sored by the spe cial ist in de vel op ing au to mo tive

elec tron ics, Vec tor. For the over 350 par tic i pants meet ing in Stutt -

gart, the themes of di ag nos tics, test ing, qual i ty and dis trib ut ed

sys tems were of pri ma ry im por tance. There was gen er al agree ment

that the cit ed vi sions and fu ture goals could on ly be achieved by

com pre hen sive stand ard i za tion. The well-worn road will con tin ue

to be trav eled, where the rel a tive im por tance of soft ware will con -

tin ue to grow com pared to me chat ron ics and hard ware. That is be -

cause in the fu ture cru cial in no va tions, spe cif ic func tions and

brand-typ i cal prop er ties will be firm ly based in the soft ware ar ea.

Me chat ron ic sys tems on the oth er hand will be re spon si ble for ba sic

func tions and emer gen cy back-up sys tems for ex am ple.

This con tin ued growth of elec tron ic sys tems in the au to mo bile must

how e ver be achieved with out in creas ing the num ber of con trol

mod ules. That as sures sta ble net works and com po nents es sen tial to

achiev ing re us a bil i ty of to tal sys tem so lu tions across ve hi cle lines

that have dif fer ent Elec tri cal/Elec tron ic in fra struc tures. The glob al

chal len ges lie in at tain ing qual i ty im prove ments with si mul ta ne ous

cost re duc tion, cre at ing new busi ness mod els for han dling soft ware

as an in de pend ent prod uct with re gard to is sues of util i za tion

rights, pric ing, prod uct li a bil i ty, etc., and re al iz ing a pro fes sion al

or gan i za tion with a high lev el of proc ess ma tur i ty.

Ac tiv i ties at Volk swag en and AudiThe cur rent net work ar chi tec ture in Volk swag en ve hi cles is based on

a to tal of sev en CAN bus es plus LIN sub-net works and the K-line.

Cur rent ly the fo cus in stand ard i za tion work and de vel op ment ef -

forts at VW is on stand ard iz ing the di ag nos tic ex change for mat per

AS AM/ODX, work ing to geth er with oth er lead ing au to mo tive OEMs

6/0

Fig ure 1: Cur rent net work ar chi tec ture at Volk swag en.

The vi sion of cross-plat form use of ECUs,uni ver sal com mu ni ca tion ca pa bil i ty, in -ter change a bil i ty and re us a bil i ty of soft -ware mod ules be yond ve hi cle and OEMbound a ries is fast ap proach ing re al i ty.Un til pro duc tion ma tur i ty is reached,how e ver, au to mo tive OEMs and sup pli ersstill need to over come a num ber of chal len ges. Two pres en ta tions, one by Volk swag en and the oth er by Bosch, giv enat the Vec tor Con gress in Oc to ber 2006serve to ex plain this.

36 Press Book_Seite_6-00_6-03:Press Report 2 09.02.2010 13:05 Uhr Seite 1

Page 177: Vector Press Book

plac ing CAN-B. With re gard to ac cept a ble bus load, the CAN bus has

al ready reached its max i mum in some in stan ces. There fore, be gin -

ning in 2008, time-trig gered Flex Ray will as sume cer tain chal leng -

ing net work ing tasks in dis trib ut ed sys tems. In 2009 Flex Ray will

be used in an ex tend ed ap pli ca tion with more than three bus

nodes. MOST has been trans port ing da ta in mul ti me dia ap pli ca tions

since 2003 on the Audi A8, and since 2006 on Volk swag en mod els

too. Ad di tion al im ple men ta tions are planned [1].

Sup pli ers: Gen er at ing cus tom er util i ty in stead of main -tain ing va ri e tyAU TO SAR al so si mul ta ne ous ly rep re sents an op por tu ni ty and a chal -

lenge for Tier-1 sup pli ers such as Bosch [2]. For sup pli ers the ben e -

fits of a glob al de-fac to AU TO SAR stand ard lie in the use of stand -

ard plat forms; this lim its the num ber of ver sions and fa cil i tates

cost-ef fect ive mass pro duc tion. Sup pli ers can de vote their en er gies

en tire ly to gen er at ing cus tom er util i ty and do not need to em ploy

their de vel op ment re sour ces in nu mer ous in ter face mod i fi ca tions.

In im ple men ta tion seem ing ly con tra ry re quire ments some times

need to be sat is fied. For ex am ple, on the one hand prod uct lines

should dem on strate unique com pet i tive ad van ta ges, but at the

same time they should fit troub le-free in to dif fer ent sys tem en vi -

ron ments. Sys tem mod el ing and sys tem de sign must be kept sep a -

rate in in te grat ing the de vi ces in a net work of ECUs and bus sys -

tems. This can on ly be achieved by very close co op er a tion with

in the HIS (Her stel ler i ni ti a tive Soft ware) in ter est group, de vel op -

ing and in tro duc ing AU TO SAR-con form ant soft ware com po nents

and util iz ing the Flex Ray and MOST bus sys tems.

ODX has al ready prov en its ca pa bil i ties in a fu ture-ori ent ed joint

project. The new gen er a tions of the Sprint er and Craft er vans from

Daim ler Chrys ler and Volk swag en are sim i lar from the net work ing

ar chi tec ture per spec tive. An ODX con vert er proc ess es the ODX di ag -

nos tic da ta gen er at ed by the Vec tor Tool CAN dela by DC and us es it

to pre pare the di ag nos tic da ta for VW.

In in tro duc ing AU TO SAR, VW and Audi are tak ing the ap proach of

gen tle mi gra tion and are con vert ing ECUs grad u al ly, ECU by ECU.

In i tial ly there will be dif fer ent “next gen er a tion” de vel op ment lev -

els of the stand ard soft ware core, in which both AU TO SAR and VW

mod ules are im ple ment ed si mul ta ne ous ly. Ad ap ta tion work is fo -

cus ing on hard ware-re lat ed ar e as such as the com mu ni ca tion driv -

er, I/O driv er and mem o ry driv er as well as as so ci at ed ab strac tion

mod ules. Aft er the last mi gra tion step, steps will be tak en to thor -

ough ly sep a rate the ap pli ca tion lay er from the un der ly ing lay ers,

such that it on ly ac cess es oth er sys tem com po nents via the AU TO -

SAR Run time En vi ron ment (RTE).

Cost and per form ance con sid er a tions play a key role in de ci sion-

mak ing proc ess es for fu ture net work tech nol o gies. Volk swag en is

trim ming its large num ber of CAN net works: LIN and CAN-C are re -

6/1

Fig ure 2:Fu ture net work tech nol o gies at Volk swag en.

36 Press Book_Seite_6-00_6-03:Press Report 2 09.02.2010 13:05 Uhr Seite 2

Page 178: Vector Press Book

OEMs in de sign and eval u a tion of E/E in fra struc tures. Mi gra tion of

to day’s soft ware ar chi tec ture to AU TO SAR de mands much in no va -

tive work by the sup pli er in adapt ing de vel op ment proc ess es, meth -

ods, tools and ways of think ing.

In the de vel op ment proc ess ef forts must be di rect ed to ward cre at -

ing un am big u ous def i ni tions of in ter fa ces, com plet ing un fin ished

work and de liv er ing re sults; pre cise soft ware spec i fi ca tions that

pre scribe the depth of de tail and de vel op ment lev els are es sen tial.

All in all what is re quired are pro fes sion al tech niques of project and

qual i ty man age ment, project risk as sess ment and a high ma tur i ty

lev el among all part ners.

Sum ma ry and out lookKey goals of cross-OEM stand ard i za tion ef forts are qual i ty im prove -

ment, cost re duc tion and ef fi cient man age ment of the con tin u ous ly

grow ing soft ware share in the val ue-cre at ing proc ess. The path to -

ward at tain ing these goals at OEMs and sup pli ers nec es sa ri ly in -

volves de vel op ing and in tro duc ing sys tem com po nents that con -

form to AU TO SAR, HIS, etc. and fa cil i tate re us a bil i ty across OEM

bound a ries. Si mul ta ne ous ly, pow er ful bus sys tems such as Flex Ray

will re duce the ap pli ca tion field of CAN.

At the Vec tor Con gress it was made clear that to mas ter the ris ing

com plex i ties in volved in de vel op ment, ad min is tra tion, da ta ex -

change and proc ess man age ment, it is in creas ing ly be com ing nec -

es sa ry to turn to mas sive soft ware sup port. Vec tor sup ports ve hi cle

OEMs and sup pli ers in net work ing the de scribed sys tems with a uni -

ver sal tool chain and soft ware com po nents, where in con tin u ous ad -

vanced de vel op ment of the tools is al ways ori ent ed to ward the lat -

est spec i fi ca tions of stand ards.

Lit er a ture ref er en ces: [1] Lange, K. (Volkswagen AG): “The chal lenge of net work ing and soft ware

– Im ple men ta tion of new stand ards“, Vec tor Con gress 2006.[2] Schnelle, Dr. K.-P. (Robert Bosch GmbH): “AU TO SAR – Ex am ples of a sys -

tem ar chi tec ture from the per spec tive of an au to mo tive sup pli er”, Vec tor Con gress 2006.

6/2

36 Press Book_Seite_6-00_6-03:Press Report 2 09.02.2010 13:05 Uhr Seite 3

Page 179: Vector Press Book

Accelerate Your Embedded

Software Developmentwith standardized basic software. Benefit from scalable soft-

ware modules for CAN, LIN, FlexRay, J1939 and CANopen used

successfully by many OEMs worldwide.

> Build upon OSEK- or AUTOSAR-conformant operating systems

which serve as the foundation for a stable implementation.

> Create functionally reliable networks with the communica-

tion stacks that most developers rely on.

> Use the Flash Bootloader to update your ECU software in a

controlled process and protect it from third party access.

> Focus on your application development tasks by using

AUTOSAR-conformant basic software modules.

> Improve your efficiency with Vector‘s tailored consultation

and development services.

Vector supports you with embedded software, configura-tion tools and services throughout the ECU development process.

More Informationen: www.ecu-software.com

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. +49 7 11 8 06 70-0

www.vector.com

Test

ECU

Diag

nost

ics

Distr. Systems

Deve

lopm

ent

Management

Proc

ess

Calibration

ECU

Software

ECU

ECU Software

36 Press Book_Seite_6-00_6-03:Press Report 2 09.02.2010 13:05 Uhr Seite 4

Page 180: Vector Press Book

6/4

Em bed ded sys tems can be con fig ured at dif fer ent points in time:

Be fore the source code runs through the build proc ess, the so-

called pre-com pile con fig u ra tion oc curs. This en a bles ef fi cient im -

ple men ta tion of con fig u ra tions, e.g. var i ants, by mac ros or C pre -

proc ess or switch es. The link-time con fig u ra tion is typ i cal ly used to

gen er ate a li brary and to link it with ROM con stants. Fur ther more,

there is the op tion of con fig u ra tion dur ing the run-time of the ECU

(run-time con fig u ra tion), e.g. by cal i bra tion or di ag nos tic com -

mands. In such cas es, the con fig u ra tion pa ram e ters must be stored

in RAM. In con trast to the con fig u ra tion types al ready named, post-

build con fig u ra tion is per formed on ECUs that have al ready been

built by load ing the con fig u ra tion da ta in to the ECU via a flash

boot load er (Fig ure 1).

The AU TO SAR stand ard [1] de fines three so-called Con fig u ra tion

Con form ance Class es (CCC), which cov er these dif fer ent con fig u ra -

tion times:

> CCC0 re fers to a Pre-Com pile Con fig u ra tion

> CCC1 Link-Time Con fig u ra tion

> CCC2 Post-Build Con fig u ra tion.

Just which of these con fig u ra tion op tions is in prin ci ple avail a ble

for a spe cif ic ba sic soft ware mod ule de pends on the char ac ter of

the mod ule. The RTE (Run time En vi ron ment) sup ports on ly CCC0,

be cause it is close ly linked to the ap pli ca tions and con sists of ful ly

gen er at ed code. The op er at ing sys tem is al so con fig ured on ly at

pre-com pile time. Fig ure 2 shows – in the con text of the AU TO SAR

lay er mod el – which con fig u ra tion op tions ex ist for CAN com mu ni -

ca tion mod ules.

High flex i bil i ty of gate way ECUs is achieved by the post-build prin ci ple, since it per mits a lat er con fig u ra tion at any time –even in late de vel op ment phas es dur ing ECU in te gra tion or even in the field. This re sults in uni ver sal ly de ploy a ble ECUs.Based on the AU TO SAR stand ard, a meth od is pre sent ed here that de scribes how the gate way func tion al i ty in the fin ishedECU can be adapt ed to new re quire ments.

Flex i ble post-build con fig u ra tion of AU TO SAR gate ways

Fig ure 1:Con fig u ra tion con cepts in ECU de vel op ment

Fig ure 2: Con fig u ra tion class es in the lay er mod el of an AU TO SAR ECU

The Uni ver sal Gate way ECU

37 Press Book_Seite_6-04_6-09:Press Report 3 09.02.2010 13:07 Uhr Seite 1

Page 181: Vector Press Book

6/5

For the most part, the mod ules be long ing to the com mu ni ca tion

stack be neath the RTE sup port the post-build con fig u ra tion per

CCC2. None the less, these mod ules have some pre-com pile pa ram e -

ters such as the num ber of chan nels, use of da ta buff ers (queues)

and ac ti va tion of de bug modes. These set tings must be known at

the time the li brary is gen er at ed. In de sign ing an ECU, a sen si ble

strat e gy must be de vel oped for us ing the post-build ca pa bil i ties of

neigh bor ing mod ules. For ex am ple, it would make lit tle sense to

pro vide post-build ca pa bil i ty to an in di vid u al mod ule such as the

PDU Rout er (PDU-R), while on ly grant ing pre-com pile con fig u ra tion

to all oth er mod ules.

When is a post-build im ple ment ed for gate ways?If the func tion al i ty of in di vid u al ECUs chan ges, e.g. dur ing a ve hi cle

fa cel ift, of ten chan ges must al so be made to the com mu ni ca tion

ma trix of one or more net works. This is where post-build comes in to

play and en a bles sim ple ad ap ta tion of the ba sic soft ware re spon si -

ble for com mu ni ca tion be tween all ECUs of the af fect ed net work.

This elim i nates the need for re com pil ing and link ing the code. If a

gate way ECU is de signed to be post-build ca pa ble, it is eas ier to fit

it in as a stand ard ECU in dif fer ent ve hi cle mod els. Gate way ECUs

per form a ma jor i ty of their tasks via the com mu ni ca tions ba sic

soft ware. A ve hi cle fa cel ift for such ECUs of ten con sists of just new

or mod i fied rout ing re la tion ships, for which all that is need ed is a

re con fig u ra tion of the ba sic soft ware.

The pri ma ry mo ti va tion for us ing a post-build con fig u ra tion is the

fact that it avoids the need for a new build proc ess, and the con fig -

u ra tion can be per formed in late de vel op ment phas es dur ing ECU

in te gra tion or even in the field. This ap proach is of spe cial in ter est

for gate way ECUs.

The gate way ECU as flex i ble switch boardThe main pur pose of a gate way ECU is to dis trib ute com mu ni ca tion

da ta among the in di vid u al net works in a ve hi cle. Ac cord ing to the

AU TO SAR stand ard, var i ous ba sic soft ware mod ules of the ECU per -

form this task. Which mod ules are used de pends on the spe cif ic

gate way func tion al i ty that is need ed:

PDU gate wayThe PDU gate way is a part of the PDU rout er (Fig ure 3). It routes en -

tire da ta pack ets, known as Pro to col Da ta Units (PDUs), from one

net work to an oth er. This prin ci ple as sumes that the PDUs are de -

fined iden ti cal ly on both the source and tar get net works, i.e. they

must agree in length and con tents. This means that da ta can al so

be ex changed be tween dif fer ent bus sys tems such as CAN, LIN or

Flex Ray.

None the less, it should be not ed that in ac cord ance with the

AU TO SAR spec i fi ca tion the PDUs must be rout ed im me di ate ly aft er

they are re ceived. Con se quent ly, the PDU rout er can not per form

send type or cy cle time con ver sions. In some cas es, how e ver, such a

con ver sion is nec es sa ry. An ex am ple of this might be a Flex Ray-CAN

gate way that routes a PDU from a Flex Ray clus ter to a CAN net work

as a CAN mes sage. In this case, the gate way ECU must for ex am ple

con form to min i mum trans mis sion de lay re quire ments (de bounce

time) for the CAN mes sage. In such cas es, the PDUs are there fore

rout ed di rect ly to the COM lay er, which then as sumes this task.

TP gate way An oth er task of the PDU rout er is to route trans port pro to col da ta.

This comes in to play, for ex am ple, if the ex ten sive di ag nos tic da ta

of an ECU need to be au to mat i cal ly trans ferred from one net work to

an oth er. This in volves re ceiv ing the da ta via the Trans port Pro to col

(TP) and re send ing it. At first, the trans mis sion oc curs above the TP

(Lay er 4 in the ISO/OSI lay ers mod el), and this en a bles a con ver -

sion to dif fer ent ad dress ing meth ods and var i ous bus sys tems. To

keep de lays and RAM re quire ments in the gate way as low as pos si ble,

Fig ure 3: AU TO SAR ba sic soft ware mod ules with gate way func tion al i ty

37 Press Book_Seite_6-04_6-09:Press Report 3 09.02.2010 13:07 Uhr Seite 2

Page 182: Vector Press Book

6/6

avail a ble for oth er pur pos es. How e ver, the ba sic soft ware mod ules

are high ly de pend ent with re spect to their im ple men ta tion. If the ba -

sic soft ware orig i nates from dif fer ent soft ware sup pli ers, this var i ant

gen er ates a high co or di na tion needs and is there fore im prac ti cal.

In the frag ment ed var i ant 2, the da ta struc tures are al ways placed

at a stat ic po si tion in mem o ry. Here, at the time of de sign, an as -

sump tion is made con cern ing the larg est pos si ble mem o ry us age of

in di vid u al da ta struc tures. In prac tice, some un used mem o ry be -

tween the da ta struc tures re mains. With re gard to run time be hav -

ior, var i ant 2 is more ef fi cient, since no in di rec tion is need ed in

data ac cess. De spite the frag men ta tion, this var i ant al so of fers

advan ta ges in terms of mem o ry ef fi cien cy, since an in di rec tion

table is un nec es sary.

The use of post-build da ta struc tures has an enor mous ef fect on the

de sign of the ba sic soft ware mod ules. In the case of the pre-com -

pile con fig u ra tion, for ex am ple, the sep a ra tion of code and da ta is

not re quired. This makes it eas ier to im ple ment con fig u ra tion set -

tings very ef fi cient ly with mac ros or pre proc ess or switch es and to

gen er ate op ti mized C func tions with the help of code gen er a tors.

The prin ci ple of the post-build con fig u ra tion, on the oth er hand,

re quires strict sep a ra tion of code and da ta for post-build pa ram e -

ters. A gen er a tor is on ly avail a ble for gen er at ing con stants ta bles.

The C func tions are stat ic. Fig ure 5 shows how the dif fer ent con fig -

u ra tion con cepts ap pear based on code ex am ples.

the TP gate way sup ports so-called “on-the-fly rout ing“: The gate -

way does not wait un til all TP da ta have been re ceived, rath er it al -

ready be gins to re send the da ta at an ear li er time point. Con se -

quent ly, it re ceives and sends si mul ta ne ous ly.

Sig nal gate wayOf ten just in di vid u al sig nals are need ed on the oth er net work. In

this case, the gate way does not trans fer the en tire PDU, but on ly

sends in di vid u al sig nals to the oth er bus. To do this, it first dis as -

sem bles a re ceived PDU in to in di vid u al sig nals, so that it can then

as sem ble them in to one or more send PDUs. Be sides mod i fy ing the

sig nal com po si tion and sig nal po si tions with in a PDU, the send type

and cy cle time can al so be changed. This meth od is al so used when

a PDU should con tain both rout ed sig nals and sig nals gen er at ed di -

rect ly in the gate way ECU.

Tech ni cal as pects of post-build con fig u ra tionDa ta struc tures for the post-build con fig ur a ble da ta es sen tial ly

have two dif fer ent types of lay outs (Fig ure 4). In the non-frag ment ed

var i ant 1, the da ta struc tures are ar ranged one di rect ly aft er an oth -

er in mem o ry. The in di vid u al da ta struc tures are ac cessed via an in -

di rec tion ta ble lo cat ed at a stat ic po si tion. The da ta struc tures on

the oth er hand may vary in size de pend ing on the post-build con -

fig u ra tion. The re main ing mem o ry is a con tig u ous block that is

Fig ure 4:Da ta struc tures for post-build con fig u ra tion

37 Press Book_Seite_6-04_6-09:Press Report 3 09.02.2010 13:07 Uhr Seite 3

Page 183: Vector Press Book

6/7

THE UNIVERSAL GATEWAY ECU

A gate way ECU re quires knowl edge of large num bers of sig nals or

mes sa ges. This in for ma tion ex ists in the form of da ta struc tures in

the ECU’s mem o ry. As a re sult, in gate way ECUs the com mu ni ca tion

lay ers in the soft ware ar chi tec ture take up a con sid er a ble share of

mem o ry and run time re sour ces. Even when the more ef fi cient var i -

ant 2 is se lect ed, the post-build ca pa ble lay out of the ECU typ i cal ly

caus es in creased re source re quire ments.

A tool chain for post-build con fig u ra tion of gate way ECUsBe sides the as pects of mem o ry and run time re sour ces in the ECU,

the post-build prin ci ple al so re quires new proc ess es to co or di nate

con fig u ra tion pa ram e ters be tween par tic i pat ing de vel op ment part -

ners and ex change them re li a bly. One im por tant source of sup port

here is a well-func tion ing tool chain. Fig ure 6 shows the tool chain

from Vec tor In for ma tik, which can al so be used for post-build con -

fig u ra tion of gate way ECUs.

Fig ure 6:Vec tor tool chain for the post-build con fig u ra tion

Fig ure 5:Code ex am ples for dif fer ent con fig u ra tion con cepts

37 Press Book_Seite_6-04_6-09:Press Report 3 09.02.2010 13:07 Uhr Seite 4

Page 184: Vector Press Book

6/8

Sum ma ryThe post-build proc ess pro vides flex i bil i ty when chan ges are made

in the com mu ni ca tion de scrip tion. Con fig u ra tion is even pos si ble in

late de vel op ment phas es dur ing ECU in te gra tion or in the field. This

ap proach is es pe cial ly use ful for gate way ECUs, since it is pos si ble

to adapt them to mod i fied net work con di tions with out hav ing to

change the com plete ap pli ca tion code. How e ver, the in creased re -

source re quire ments must be tak en in to ac count. In any event, a

gate way ECU is an in ter est ing can di date for the post-build proc ess,

at least dur ing the de vel op ment phase.

Reference:[1] AU TO SAR spec i fi ca tions: www.au to sar.org

At the be gin ning of a de vel op ment project, the ECU sup pli er sets

up the project based on the Pre-Con fig1 pa ram e ter set. Vec tor pro -

vides this pa ram e ter set along with the base soft ware de liv ery for

the ECU, and it con tains pre-com pile pa ram e ters that do not have

any ef fect on the post-build con fig u ra tion. Ex am ples of this are

gen er al set tings and use of the De vel op ment Er ror Trac er (DET).

In co or di na tion with the ECU sup pli er, the au to mo tive OEM pro vides

the Pre-Con fig2 pa ram e ter set and an in i tial net work de scrip tion

(da ta base). The Pre-Con fig2 pa ram e ter set con tains those pre-com -

pile and link-time pa ram e ters that have an ef fect on the post-build

proc ess and need to be de fined in ad vance. Ex am ples of this are the

ad dress es of post-build da ta in the ECU, com pi ler op tions and max i -

mum mem o ry size (Flash and RAM). The in i tial net work de scrip tion,

which the au to mo tive OEM might cre ate with the Da Vin ci Net work

De sign er tool, for ex am ple, con tains all sig nals rel e vant to the ECU.

In the case of a gate way ECU, the rout ing re la tion ships be tween the

net works are al so de scribed there.

The ECU sup pli er us es the GE Ny tool to con fig ure and gen er ate the

ba sic soft ware us ing this in put in for ma tion. The rout ing in for ma -

tion is pre pared in the form of gen er at ed da ta struc tures (ta bles)

for the in di vid u al ba sic soft ware mod ules. This pro vides a foun da -

tion for de vel op ing the ECU based on the in i tial net work de scrip -

tion.

Dur ing the ac tu al post-build proc ess, these ta bles must be re gen er -

at ed and ex changed in the ECU. The ba sis for this is a mod i fied net -

work de scrip tion by the au to mo tive OEM. If the up dat ed ta bles now

ex ist in bi na ry for mat – and in deed in pre cise ly the same form as

the com pi ler would have cre at ed them – then an oth er com pil ing

and link ing run is ob so lete. The knowl edge about the com pi ler be -

hav ior when gen er at ing the bi na ry for mat is stored in GE Ny. This

bina ry file is now con vert ed to a stand ard hex for mat and is load ed

in to the ECU via the CANfbl flash boot load er. If the pre-con fig in -

for ma tion is known to the au to mo tive OEM, the OEM it self can al so

per form the post-build proc ess di rect ly.

Hart mut Hörn erstud ied Elec tri cal En gi neer ing at the Uni ver si ty of Stutt gart from 1987 to 1992.Aft er wards, he worked as a soft ware de vel -op er for ATM Test Sys tems. In 1998, Mr. Hörn er came to Vec tor where he is theteam lead er re spon si ble for the de vel op mentof em bed ded soft ware com po nents. Hart mutHörn er rep re sents Vec tor on var i ous stand ardswork ing com mit tees (OSEK, ISO, AU TO SAR).

37 Press Book_Seite_6-04_6-09:Press Report 3 09.02.2010 13:07 Uhr Seite 5

Page 185: Vector Press Book

Enjoy the benefits of field-tested modules that can be used right away:

> Efficiency through reusability and time savings

> Quality through tried-and tested use in serial projects

> Openness through the option of optimally integrating

third-party components

> Flexibility to convert to AUTOSAR step-by-step

> Focus on application development

We create your AUTOSAR solution using expertise and commitment. Base software and high-performance tools — integrated in their own software architecture.

For more information, please visit: www.autosar-solutions.com

Start your Series Development

with AUTOSAR

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. +49 (0) 7 11 / 8 06 70-0

www.vector-informatik.com

37 Press Book_Seite_6-04_6-09:Press Report 3 09.02.2010 13:07 Uhr Seite 6

Page 186: Vector Press Book

Ear ly Mi gra tion cre ates Op por tu ni ties for In no va tions

6/10

At the be gin ning of 2007, the AU TO SAR de vel op ment part ner ship

de fined, in its Re lease 2.1, a prac tice-test ed soft ware ar chi tec ture

that is used as a foun da tion for de vel op ing re us a ble ap pli ca tions.

With pub li ca tion of these spec i fi ca tions, in the fu ture it will be pos -

si ble for all com pa nies be long ing to the AU TO SAR de vel op ment

part ner ship to de vel op AU TO SAR-con form ant com po nents. How e -

ver, its prac ti cal im ple men ta tion is not triv i al. The tran si tion from

in di vid u al soft ware to stand ard soft ware has to be well-planned

and is cer tain ly on ly con ceiv a ble if a step wise ap proach is tak en.

The AU TO SAR phi los o phy and de scrip tion lan guage cre ate a di verse

en vi ron ment for us ing stand ard ized soft ware. In prac tice, this may

be a mixed in stal la tion of AU TO SAR and non-AUTO SAR com po nents

or an in te gra tion of ba sic soft ware for spe cif ic plat forms by a num -

ber of dif fer ent soft ware sup pli ers. For both types of im ple men ta -

tion, it is nec es sa ry to clar i fy and de fine the rel e vant con straints

from var i ous per spec tives.

Ve hi cle per spec tiveFrom the OEM per spec tive, ba sic plat forms, tech no log i cal plat -

forms, etc. are be ing de vel oped, from which the next gen er a tions

of cars will be de rived. The un der ly ing goal here is to in te grate one

and the same ECU in many ve hi cles and there by re duce costs. At the

same time, the qual i ty and the sta bil i ty of the ve hi cle elec tron ics

should be im proved. This re sults in a di lem ma be tween the im pon -

der a bles of a new ly in tro duced tech nol o gy and the sta bil i ty of the

prod uct.

Ar chi tec tur al per spec tivFrom the point of view of an ECU in di vid u al soft ware com po nents

are dis cern i ble. At the same time, two con tra dict o ry ap proach es are

be ing fol lowed with re gard to the base soft ware of to day’s ECUs. On

the one hand, many OEMs re quire spe cif ic soft ware com po nents or

at least they spec i fy them. On the oth er hand, con trol mod ule pro -

duc ers are striv ing in ter nal ly to al ways use the same ar chi tec ture

for a con trol mod ule plat form. Add ed to this is the fact that the de -

gree of stand ard i za tion of the soft ware is not as com pre hen sive as

Fig ure 1:Ear ly in tro duc tion ofa uni form in ter faceand RTE sim pli fiesmi gra tion.

ECU de vel op ment in the mo tor ve hi cle is evolv ing rap id ly.This ar ti cle sheds light on one im por tant as pect: The in tro duc tion of stand ard ized ba sic soft ware de finedby the AU TO SAR de vel op ment part ner ship. If AU TO SARsoft ware com po nents are add ed to the over all ar chi tec turein a step wise and dif fer en ti at ed man ner, this as suresqual i ty en hance ments.

Mix of In di vid u al Soft ware and AU TO SAR Com po nentsin Ve hi cle Elec tron ics

38 Press Book_Seite_6-10_6-13:Press Report 2 09.02.2010 13:10 Uhr Seite 1

Page 187: Vector Press Book

6/11

Stage II - Re place:

Non-AUTO SAR com po nents can now be re placed grad u al ly by AU TO -

SAR com po nents with out put ting the over all ar chi tec ture at risk or

re quir ing re pro gram ming of oth er mod ules. The goal here is to set

up an AU TO SAR ar chi tec ture and use the ap pro pri ate tools. In i ti at -

ed in in di vid u al ECUs, in the end the en tire ve hi cle is con cep tu al -

ized with AU TO SAR soft ware, start ing with sys tem de sign and end -

ing with in te gra tion.

Us ing the AU TO SAR ar chi tec ture in de sign ing new ECUs As im plied in Fig ure 2, es sen tial parts of the in di vid u al soft ware can

al so be re used in the frame work of an AU TO SAR ar chi tec ture. They

are then linked to the ap pli ca tion via an ad ap ta tion lay er as a com -

plex de vice driv er.

An over lap ma trix shows the por tions in which AU TO SAR soft ware

can be in tro duced with out great risk. Pri ma ri ly, the mem o ry sec tion

and the IO hard ware ab strac tion can be mi grat ed smooth ly. Clus ter

mem o ry man age ment in par tic u lar has very clear and eas y-to-use

in ter fa ces that en a ble its ear ly mi gra tion to new ECUs.

In com mu ni ca tion and di ag nos tics, on the oth er hand, there are

con sid er a ble over laps be tween pro pri e tary ve hi cle soft ware and

the stand ard mod ules of the AU TO SAR ba sic soft ware. In the in ter -

est of sta bil i ty in the ve hi cle, a more con serv a tive ap proach is re -

quired here. Many OEMs util ize plat form ECUs, in which ex ist ing

soft ware mod ules are trans ferred to new ve hi cle mod els. One im pli -

ca tion is that the net work and com mu ni ca tions strat e gy can not be

changed over the short term. In the case of an im me di ate mi gra -

tion, ECU cal i bra tion and off-board di ag nos tics would al so need to

be adapt ed, which in prac tice would lead to sig nif i cant prob lems.

There fore, the sim plest path is to use the ex ist ing com mu ni ca tion

stack in the AU TO SAR en vi ron ment too. This stack can be linked to

the RTE via an ad ap ta tion lay er.

Vec tor has the nec es sa ry ex pert ise in this ar ea and can pro pose the

right so lu tions for cre at ing such mixed ar chi tec tures or sup ply them

to the cus tom er. For ex am ple, the fa mil iar XCP pro to col can be in te -

grat ed in a mi gra tion ar chi tec ture so that ex ist ing meas ure ment

and cal i bra tion tools such as CA Na pe can be used.

The de scribed ap proach is not a pure top-down ap proach, since at

many points AU TO SAR soft ware can even be in te grat ed on low er

hard ware-re lat ed lay ers. Its mod u lar struc ture and de fined in ter fa -

ces help in im ple ment ing the stand ard soft ware on the SPAL lev el

with out af fect ing the up per lay ers. This of fers an enor mous ad van -

tage with re gard to re use.

Vec tor In for ma tik util iz es the con cept of Prod uct Clus ter ing here.

Based on AU TO SAR spec i fi ca tions, the pro ducts of fered range over

a num ber of lay ers and pro vide to tal so lu tions for mem o ry, com mu -

de scribed by AU TO SAR. The goal here is to ap ply a stand ard to soft -

ware that does not serve the pur pose of com pet i tive dif fer en ti a -

tion, there by cre at ing space for new in no va tions. Op ti mal ly, low in -

vest ment costs would be in curred by new tools, since those tools al -

ready in serv ice can for the most part be re used.

Clear mi gra tion strat e gy as fac tor in suc cessWhen these two per spec tives are ap plied to a de ci sion on in tro duc -

ing AU TO SAR, it makes sense to se lect a mul ti stage ap proach.

Stage I – Set up the ar chi tec ture and ex pand:

The first step is to com pare the ex ist ing cus tom soft ware and the

AU TO SAR ar chi tec ture. Aft er an a lyz ing over laps and in te gra tion po -

ten tials, a de ci sion is made re gard ing which mod ules will be pre -

served and which ones can be re placed by stand ard soft ware. At

this stage it is rec om mend ed that a sep a rat ing lay er be in tro duced

be tween ap pli ca tion soft ware and base soft ware as well as a stand -

ard ized in ter face. The so-called Run time En vi ron ment (RTE) serves

as the link for the nec es sa ry da ta ex change, and as a buff er with

de fined in ter face it en a bles mod u lar pro gram ming with out de pend -

en cies. This is how AU TO SAR com po nents can be in te grat ed with out

mak ing ad di tion al chan ges to the cus tom and ap pli ca tion soft ware.

The cus tom soft ware is linked to the sys tem ar chi tec ture via an Ad -

ap ta tion Lay er to en a ble da ta ex change with the AU TO SAR com po -

nents via the RTE; see Fig ure 1.

To min i mize cost and ef fort and ar rive at an op ti mal over all so lu -

tion, it is help ful at this point to in te grate the cus tom soft ware in

the con fig u ra tion tools.

Fig ure 2:In te gra tion of cus tom soft ware in the AU TO SAR ar chi tec ture.

38 Press Book_Seite_6-10_6-13:Press Report 2 09.02.2010 13:10 Uhr Seite 2

Page 188: Vector Press Book

6/12

ni ca tion, di ag nos tic and sys tem ar e as. These are in de pend ent ly

func tion ing ar e as, some of which can al so be im ple ment ed with out

AU TO SAR ar chi tec ture. Clus ter mem o ry for ex am ple can be in te grat -

ed quick ly and eas i ly in many ECU ap pli ca tions; see Fig ure 3.

Sup port by toolsAn im por tant pil lar in the in tro duc tion of AU TO SAR re lates to the

tools. They must be able to op er ate the AU TO SAR in ter fa ces, yet

they must re main open to in te gra tion of third-par ty com po nents.

Above all, con fig u ra tion tools should be able to mas ter this chal -

lenge and al so sup port the us er in val i da tion of the sys tem con fig u -

ra tion.

The tool world serv ic ing AU TO SAR can be sub di vid ed in to three cat -

e go ries: De sign, con fig u ra tion and test/sim u la tion. Above all, suit -

a ble test in stru ments are an es sen tial com po nent for suc cess ful de -

vel op ment. An ECU op er ates as a part of a whole. Check ing for and

as sur ing con sist en cy in the over all sys tem re quires a high-per form -

ance sim u la tion tool. Vec tor In for ma tik GmbH has come to grips

with these re quire ments and can make a con tri bu tion to the suc -

cess of AU TO SAR with its com pre hen sive tool so lu tions such as the

Da Vin ci Tool Suite, MIC RO SAR Con fig u ra tion Suite and CA Noe. Sup -

port in the con text of project work and con sul ta tion com ple ment

the pro ducts of fered.

Sum ma ryWhen con sid ered from dif fer ent points of view, a step wise in tro duc -

tion of the stand ard com po nents de fined by the AU TO SAR de vel op -

ment part ner ship in to an in di vid u al com pa ny’s soft ware ar chi tec -

ture ap pears to be the cor rect path. This ap proach guar an tees qual -

i ty and con sist en cy. Prop er tools sup port this proc ess. Grad u al mi -

gra tion in stead of an im me di ate to tal con ver sion leads to an over all

AU TO SAR so lu tion in the ve hi cle that min i miz es risks. Vec tor’s ex -

pert ise and many years of ex pe ri ence lend sup port to this proc ess.

Fig ure 3:Vec tor of fers MIC RO SAR, whichcon tains the en tire range of AU TO SAR-BSW in clud ing RTE.

Pe ter Schi ek o fer (Grad u ate En gi neer) has been em ployed atVec tor since May 2006. He man a ges Vec tor’sRe gens burg sub sid i ary and is re spon si ble forad vanced tech ni cal de vel op ment of AU TO SARso lu tions. As an ac tive work ing par tic i panton Work ing Pack a ges WP 1.1.2 and WP 20 ofthe AU TO SAR De vel op ment Part ner ship he isdi rect ly in volved with the new tech nol o gy. Tel. +49-941/20865-101,Fax +49-941/20865-111,E-mail:pe ter.schi ek o fer@vec tor-in for ma tik.de

38 Press Book_Seite_6-10_6-13:Press Report 2 09.02.2010 13:10 Uhr Seite 3

Page 189: Vector Press Book

6/13

38 Press Book_Seite_6-10_6-13:Press Report 2 09.02.2010 13:10 Uhr Seite 4

Page 190: Vector Press Book

6/14

The auto mo tive indus try is being con front ed with new times.

Growth in the num ber of com plex vehi cle func tions is mak ing the

devel op ment of auto mo tive elec tron ics increas ing ly more exten sive

and com pli cat ed. Cus tom er wish es, e.g. for more var i ants and

equip ment vari e ty in the vehi cle, as well as non-func tion al require -

ments such as diag nos tic capa bil i ty and avail a bil i ty, are requir ing

more inten sive ECU devel op ment proc ess es. Vehi cles, in par tic u lar

lux u ry vehi cles, may have more than approx. 1,000 soft ware func -

tions, sev er al vehi cle elec tri cal net works and more than 70 ECUs.

Due to the vari e ty of hard ware plat forms used in this field, ECU

soft ware depend en cies on the hard ware and sys tem con fig u ra tions

being used has become prob lem at ic. Each change to one of these

con straints requires repro gram ming or at least mod i fi ca tion of the

soft ware.

To make the com plex i ty of ECU soft ware devel op ment man age a ble,

the AUTO SAR devel op ment part ner ship has defined a prac tice-test -

ed soft ware archi tec ture that serves as a foun da tion for devel op ing

reus a ble appli ca tions. This open stand ard for sys tem archi tec ture –

cre at ed by auto mo tive OEMs, sup pli ers and oth er com pa nies in the

glob al soft ware, sem i con duct or and elec tron ics indus tries – lets

users avoid pro pri e tary solu tions that would result in increas ing ly

high devel op ment cost and effort.

AUTO SAR sub di vides the elec tron ics archi tec ture into a num ber of

lay ers and mod ules. With the simul ta ne ous def i ni tion of inter fa ces,

AUTO SAR cre ates stand ards for easy exchange of soft ware com po -

nents or hard ware plat forms. The devel op ment part ner ship not only

pro vides spec i fi ca tions for the base soft ware mod ules. It also offers

a meth od ol o gy for devel op ing appli ca tions and dis trib ut ed sys -

tems. This meth od ol o gy begins with a mod el-based descrip tion of

the soft ware appli ca tions and the dis trib ut ed sys tem, and ide al ly

ends in an auto mat i cal ly gen er at ed and repro duc i ble test. This for -

mal approach sim pli fies the use of a uni ver sal tool chain.

A full three years aft er its start, the AUTO SAR devel op ment part ner -

ship pub lished Release 2.1 at the begin ning of 2007. A sta ble lev el

was reached with this release, and it has been test ed in sev er al val i -

da tion pro jects for its prac ti cal util i ty. At many busi ness es, the

action item of “AUTO SAR eval u a tion” has been suc cess ful ly com -

plet ed. Now it is ready to be imple ment ed in con crete pro duc tion

ECUs.

AUTO SAR Archi tec tureTo real ize the objec tives of AUTO SAR – sep a ra tion of the appli ca tion

soft ware from basic mod ules and func tions – the vehi cle elec tron ics

is abstract ed and sub di vid ed into sev er al lay ers (Fig ure 1). The con -

nec tion to the actu al micro con trol ler, i.e. the phys i cal foun da tion,

is rep re sent ed by the Micro con trol ler Abstrac tion Lay er, which maps

the micro con trol ler’s func tions and periph ery. It defines inter fa ces

for mem o ry, the I/O driv er and its com mu ni ca tion con nec tions. In

this lay er, fea tures that the micro con trol ler does not offer may also

be emu lat ed in soft ware. The sec ond lay er that lies above this is the

ECU Abstrac tion Lay er. It estab lish es die ECU-spe cif ic hard ware lay -

out and pro vides driv ers for the periph ery exter nal to the ECU, for

exam ple. In anoth er lay er, the Serv i ces Lay er, var i ous basic serv i ces

are rep re sent ed such as net work serv i ces, mem o ry man age ment,

bus com mu ni ca tion serv i ces and the oper at ing sys tem. This lay er is

already large ly inde pend ent of the hard ware. The RTE rep re sents

the fourth lay er. This is where the actu al sep a ra tion of appli ca tion

and basic soft ware (BSW) is made. The RTE han dles inte gra tion of

the appli ca tion soft ware and reg u lates the exchange of data bet-

ween the appli ca tion and the BSW. It is only at this lay er that reuse

of already writ ten appli ca tion soft ware is pos si ble, because the

defined inter fa ces make it pos si ble to devel op the appli ca tion soft -

ware with out spe cial knowl edge of the hard ware to be used at a

lat er time, and the soft ware can be used for any oth er AUTO SAR-

con form ant ECUs.

The so-called Vir tu al Func tion al Bus (VFB) forms the basis for con -

fig u ra tion of the lay ers. All com po nents of the vehi cle’s elec tron ics

com mu ni cate in an abstract ed view via this bus. The soft ware com -

po nents use ports for this, whose inter fa ces can be defined as port

inter fa ces. Con nect ors con nect the ports. It is irrel e vant to the VFB

wheth er this is a con nec tion with in an ECU or a con nec tion via an

exter nal bus. This is not decid ed until the final sys tem lay out is

made and spe cif ic func tions are assigned to a spe cif ic ECU.

AUTOSAR on its Way to Production

To master the growing complexity of software in modern vehicles, automotive OEMs are increasingly developing their elec-tronic systems based on AUTOSAR. The standards created by this development partnership simplify development processesand make ECU software reusable. Since its introduction in 2004, this innovative and pioneering technology has been testedin many evaluation projects and is now entering an implementation phase in production ECUs. AUTOSAR standard softwarecovers the current state of technology and is undergoing continual advanced development in new releases.

Fig ure 1:AU TO SAR lay er mod el for ECU soft ware.

39 Press Book_Seite_6-14_6-17:Press Report 4 09.02.2010 13:10 Uhr Seite 1

Page 191: Vector Press Book

6/15

The soft ware com po nent itself does not require any knowl edge of

this lat er dis tri bu tion, and it can there fore be devel oped inde pend -

ent of it. The com po nent is sub di vid ed into exe cu ta ble units, so-

called Run na ble Enti ties, which are exe cut ed like pro ce dures when

a spe cif ic event occurs. Such an event might be the arriv al of a new

sen sor val ue or a peri od ic acti va tion, for exam ple. The descrip tion

of the elec tron ic sys tem for mu lat ed from the per spec tive of the VFB

defines the inter fa ces of the spe cif ic soft ware com po nents. As a

result, the appli ca tion com po nents can be devel oped inde pend ent

of the spe cif ic ECU.

The “coun ter part” on the ECU is the RTE. It guar an tees access to

I/Os, mem o ry and oth er basic serv i ces. Using the mod el-based

descrip tion, the RTE is gen er at ed ECU-spe cif i cal ly, which means

that it can be adapt ed to dif fer ent require ments while econ o miz ing

on resour ces.

Meth od ol o gyBesides defin ing the ECU’s soft ware archi tec ture, the AUTO SAR

stand ard also defines a meth od ol o gy to help in the devel op ment of

AUTO SAR sys tems. Con form ance to a struc tured cre a tion proc ess is

recog nized as an impor tant pre con di tion in cre at ing error-free

soft ware. Defi cien cies in the require ments list are detect ed ear ly,

reuse and port ing of soft ware com po nents is sim pli fied, and the

over all sys tem is more reli a ble. None the less, this meth od ol o gy also

allows cer tain freed oms: for exam ple, users can decide wheth er to

use a top-down approach or a bot tom-up devel op ment.

The AUTO SAR Ini ti a tive pro vides uni ver sal sup port for the soft ware

devel op ment proc ess by tools. Mature tools are used for struc tured

imple men ta tion of require ments and their con sist ent man age ment;

con fig u ra tions are sys tem at i cal ly cre at ed, and com plex depend en -

cies are auto mat i cal ly tak en into account.

The first step involves for mal descrip tion of the three pri ma ry con -

stit u ents: Soft ware (SW Com po nents), ECUs (ECU Resour ces) and

Sys tem Con straints.

Suit a ble edi tors are used to cre ate a con fig u ra tion descrip tion of

the com plete sys tem (Fig ure 2). This sys tem con fig u ra tion serves

as the basis for the ECU Con fig u ra tions that the user cre ates for the

indi vid u al basic soft ware mod ules with the help of con fig u ra tion

tools. At the end of the proc ess, mul ti ple gen er a tors sup ply the

ECU-spe cif ic imple men ta tion of the RTE and basic soft ware.

All design and con fig u ra tion data pro duced in the devel op ment

proc ess are described in a uni form for mat. AUTO SAR has defined an

XML-based for mat for this pur pose. On the one hand, it guar an tees

uni ver sal i ty of the devel op ment proc ess, and on the oth er it also

sim pli fies seam less inte gra tion of nec es sa ry and aux il ia ry tools.

Migra tionThe soft ware archi tec ture of an AUTO SAR ECU is not mon o lith ic,

rath er it con sists of a num ber of stand ard mod ules with well-de -

fined inter fa ces. This ena bles imple men ta tion of migra tion solu -

tions that offer a risk-free tran si tion to AUTO SAR. Such a migra tion

solu tion must typ i cal ly be worked out project-spe cif i cal ly. In prac -

Fig ure 2:Struc tur al descrip -tion of the soft warecom po nents. The cre a tion proc ess forAUTO SAR-con form antsoft ware com po nentsis orga nized in clear -ly pre scribed devel -op ment steps.

39 Press Book_Seite_6-14_6-17:Press Report 4 09.02.2010 13:10 Uhr Seite 2

Page 192: Vector Press Book

here, which are flex i ble enough to be used to con fig ure pro pri e tary

basic soft ware too. Non-AUTO SAR mod ules can now be replaced by

AUTO SAR mod ules in suc ces sive steps, with out put ting the over all

archi tec ture at risk or requir ing repro gram ming to oth er mod ules.

Out lookThe cur rent AUTO SAR Release 3.0 rep re sents anoth er step tak en to

enhance the qual i ty of the AUTO SAR stand ard. The con tin u ing invol-

ve ment of par tic i pat ing com pa nies clear ly dem on strates com mit -

ment to the goals of the AUTO SAR devel op ment part ner ship. Ideas

are cur rent ly being intro duced that should become a real i ty in the

frame work of the future Ver sion 4.0 of the AUTO SAR stand ard.

New ideas relat ed to AUTO SAR are also being gen er at ed by tool sup -

pli ers. Cur rent devel op ments at Vec tor are aimed at mak ing AUTO SAR-

based ECU devel op ment as con ve nient and effi cient as pos si ble. One

exam ple is a PC-based test tool for AUTO SAR appli ca tion com po -

nents, which serves as an emu la tor for the AUTO SAR ECU envi ron -

ment on the lev el of the VFB. This makes it easy to test the imple -

men ta tion code of the AUTO SAR soft ware com po nents on a devel op -

ment PC. Wide ly used stand ard tools such as Vec tor’s CANoe may be

used for test exe cu tion, vis u al i za tion dur ing or aft er test ing, and

gen er a tion of test reports. Vec tor sup ports all phas es of the ECU

devel op ment proc ess with its full set of AUTO SAR basic soft ware and

a uni ver sal tool chain of design and devel op ment tools (Fig ure 4).

The avail a ble Vec tor solu tion has been test ed in prac tice through its

use in eval u a tion pro jects, and it is pro duc tion-ma ture for AUTO SAR

Release 2.0 or 2.1 (3.0 too start ing in the 2nd quar ter of 2008).

Sum ma ryAUTO SAR is becom ing a real i ty. Var i ous OEMs have con crete plans

for imple ment ing AUTO SAR in upcom ing vehi cle pro duc tion pro -

grams. Vec tor offers a com pre hen sive prod uct line up for this, as

well as basic soft ware and tools relat ed to AUTO SAR. Not only does

this ena ble the devel op ment of pure AUTO SAR sys tems; it can also

sup port a step wise migra tion toward AUTO SAR.

tice, this may involve a mixed con fig u ra tion of stand ard AUTO SAR

mod ules and pro pri e tary soft ware.

To work out a migra tion solu tion, one begins by com par ing the

exist ing cus tom soft ware and the AUTO SAR archi tec ture. Aft er an

anal y sis of over lap ping func tion al i ties and inte gra tion options, a

deci sion is made regard ing which mod ules will remain and which

ones can be replaced by stand ard soft ware.

So, it is advis a ble, for exam ple, to intro duce a sep a ra tion lay er be -

tween the appli ca tion and basic soft ware. A poten tial sce nar io in

this case is to pre pare the appli ca tions as AUTO SAR soft ware com -

po nents already in ear ly migra tion phase, and to inte grate them via

an RTE. Beneath the RTE, a spe cif ic adap ta tion lay er is used for

inter fac ing to the exist ing basic soft ware (Fig ure 3).

If parts of the exist ing basic soft ware are to be replaced by AUTO SAR

basic soft ware, the empha sis should lie on the use of a uni form

con fig u ra tion tool for both worlds. Vec tor offers suit a ble tools

6/16

Matthias Wernicke(Graduate engineer) is responsible for product management of the DaVinci Tool Suite and is also actively engaged in AUTOSAR standardization work.

Fig ure 3:Ear ly in tro duc tion of a uni form in ter face and RTEsim pli fies mi gra tion.

Fig ure 4:The Vector AUTOSAR solution: From system descrip-tion to standardized ECU software.

39 Press Book_Seite_6-14_6-17:Press Report 4 09.02.2010 13:10 Uhr Seite 3

Page 193: Vector Press Book

6/17

39 Press Book_Seite_6-14_6-17:Press Report 4 09.02.2010 13:10 Uhr Seite 4

Page 194: Vector Press Book

6/18

AUTOSAR: New Paths to ECU Software – Part 1

Each OEM has its own functional requirements for the ECUs in its

vehicles, especially when it comes to communication and diagnos-

tics. These requirements are implemented in OEM-specific software.

If a TIER1 supplies an ECU to several OEMs, it must manually modify

the ECU software for each project. Even if the functional software is

already decoupled quite well from the software, so that it can be

adapted to the OEM-specific requirements, this modification effort

is still work intensive and prone to errors. Figure 1 shows how

unmodified functional software is adapted to different vehicle

projects without AUTOSAR.

One goal of AUTOSAR is to minimize these adaptation efforts in

software integration. Therefore, AUTOSAR focuses on consistent

abstraction of the software from the hardware and partitioning of

the software into modules with defined functional scope and

precise interfaces. These modules may be combined and, most sig-

nificantly, they can be substantially configured to cover the

requirements of different OEMs. This eliminates manual modifica-

tion of the software and facilitates its reuse. Defined interfaces

make it possible to replace OEM-specific software components (e.g.

for diagnostics) with just minimal effort.

AUTOSAR reference architecture

The AUTOSAR reference architecture is described in the document

AUTOSAR Layered Software Architecture [1]. In this document, the

ECU software is organized into the three parts shown in Figure 2:

The functional software consists of software components (SWCs). >

The SWCs are created, independent of the ECUs, based on a

Virtual Function Bus (VFB), and they communicate with one

another via interfaces.

The Runtime Environment (RTE) is used for executing the SWCs and >

it includes the technical implementation of the VFB in a real ECU.

Iterative collaboration between OEM, TIER1 and software supplier

A primary reason for introducing AUTOSAR, besides standardizing the basic software, is to increase reusability of the functional software. This affects the cooperation between the partners involved as well: OEM, TIER1, semiconductor manufacturer and software supplier. This first part of a two-part series describes a foundation for successful collaboration: AUTOSAR-specific exchange formats and tools. In the second part, you will learn about the significance of AUTOSAR for everyday work in developing ECU software for production projects.

40 Press Book_Seite_6-18_6-23.indd 240 Press Book_Seite_6-18_6-23.indd 2 09.02.2010 13:27:53 Uhr09.02.2010 13:27:53 Uhr

Page 195: Vector Press Book

6/19

majority contains functions that were already usually present in

previous software architectures, but now they are more precisely

distinguished from one another. Consistent partitioning of func-

tions into individual software modules is what assures the desired

hardware abstraction and scalability for different types of ECUs.

The use of such standard modules increases the quality of the ECU

software. In most cases, this standardization covers the interfaces

as well as functions of the BSW modules. Representing an excep-

tion here are the BSW modules for diagnostics. Since diagnostic

processes are very dependent on manufacturing and after-sales

processes at the OEMs, AUTOSAR only defines the interfaces of the

diagnostic modules. This allows OEM-specific implementations of

the diagnostic modules. Vector provides these modules for many

OEMs, and it is the task of the TIER1 supplier to configure and inte-

grate the specific variant.

Both the BSW modules and the RTE are available as software

products from various software suppliers (TIER2), such as the

MICROSAR products from Vector, which offer coverage of all BSW

modules and the RTE per AUTOSAR Release 3.0. Although they are

standard software products, the BSW modules and the RTE must be

adapted to project-specific constraints (OEM, vehicle model, ECU

variant). This involves use of relevant PC-based tools during the

configuration process. For example, the RTE may be configured

with DaVinci Developer and the BSW modules with DaVinci Configu-

rator Pro from Vector.

The basic software (BSW) modules handle the basic functions of >

an ECU. They also offer higher-end standard services such as

management of ECU states and diagnostic services.

The RTE is the layer between the functional software and the basic

software modules. It provides all interfaces the SWCs need to

access data and services of the BSW modules. Examples are signal

values from the communication network (CAN, LIN or FlexRay), I/O

signals and standard services of the BSW modules. The interfaces

originate from the “SWC Description” files. Moreover, the RTE han-

dles execution of the SWCs and communication among the SWCs

with the help of the operating system.

The BSW modules are subdivided into three layers per the

AUTOSAR architecture [1]:

Service Layer >

ECU Abstraction Layer >

Microcontroller Abstraction Layer (MCAL) >

The BSW modules of the Service Layer play a special role here,

because they contain standard services for the functional software

that are accessed via special interfaces within the RTE. The second

part of this article, in the next issue, will describe the configura-

tion of these services in greater detail.

The AUTOSAR Release 3.0 defines approx. 50 different configu-

rable basic software modules; some of them are very complex. The

Figure 1: Creating ECU soft-ware without AUTOSAR

40 Press Book_Seite_6-18_6-23.indd 340 Press Book_Seite_6-18_6-23.indd 3 09.02.2010 13:27:54 Uhr09.02.2010 13:27:54 Uhr

Page 196: Vector Press Book

6/20

Activity: “ECU design and configuration” >

Starting with the “ECU Extract of System Descrip-

tion”, the TIER1 integrates its own SWCs. This

results in a complete and up-to-date “ECU Extract

of System Description”, which now contains the

description of all SWCs (from OEM and TIER1) of

an ECU.

Another prerequisite for ECU configuration is the

existence of the “BSW Module Description” files,

which contain the definition of the data struc-

tures and all configurable parameters of a BSW

module. These files are implementation-specific

and – along with the generators and the static

code – are part of the BSW modules.

Afterwards, the TIER1 creates the initial “ECU

Configuration Description” (activity 2 in Figure 3)

based on the current “ECU Extract of System

Descrip tion”and the “BSW Module Description”

files. Then the TIER1 begins to configure the ECU

and documents it in the “ECU Configuration

Description”. The TIER1 uses suitable tools for

configuring and checking parameters of the BSW

modules and the RTE for this purpose (activities 3

and 4 in Figure 3). The “ECU Configuration

Description” is the foundation for ECU-specific

generation of the RTE and the BSW modules by

the relevant generators.

AUTOSAR Methodology

The AUTOSAR Consortium has defined a method for developing ECU

software, the AUTOSAR Methodology [2]. This document essentially

subdivides the development process into three activities and stan-

dardizes data exchange between development partners with a set

of XML files:

Activity: “Component implementation” >

The TIER1 or OEM defines the SWCs. For this pur-

pose, it creates an XML file for each SWC, the so-

called “SWC Description”. This file describes the

SWC’s interfaces and resource requirements.

Afterwards, the TIER1 or OEM creates the related

C files for the implementation of the SWC.

Activity: “System configuration“ >

The OEM first defines the functional scope of the

entire vehicle based on the SWCs, independent of

the ECUs. The next step is to design the communi-

cation networks and distribute SWCs to the avail-

able ECUs. The result is saved in the “System

Description”.

For each ECU, the OEM reduces the “System

Description” to an “ECU Extract of System

Description” which the OEM can pass to the sup-

plier (TIER1) of the relevant ECU. This file repla-

ces the DBC, FIBEX or LDF files previously used to

configure the BSW modules.

Fig ure 2: AUTOSAR architecture of an ECU

40 Press Book_Seite_6-18_6-23.indd 440 Press Book_Seite_6-18_6-23.indd 4 09.02.2010 13:27:54 Uhr09.02.2010 13:27:54 Uhr

Page 197: Vector Press Book

6/21

For configuration of the BSW modules, the TIER1 needs the sup-

port of a universal tool with user-friendly functions. That is why

Vector developed DaVinci Configurator Pro. It supports three use

cases:

Configuration of MICROSAR BSW modules from Vector >

Configuration of AUTOSAR BSW modules from third-party >

manufacturers

Configuration of software modules you have created yoursel >

MICROSAR BSW modules are configured by using a graphical user

interface that shows the complex interrelationships of the configu-

ration parameters in simplified form. Furthermore, parameter

selection is limited to valid input values, and this prevents setting

implausible values.

The Generic Configuration Editor (GCE) defined in AUTOSAR is

included with DaVinci Configurator Pro to configure the BSW mod-

ules from third-party producers. As an alternative, the TIER1 sup-

plier may choose to develop a user-friendly and integrated configu-

ration user interface for these modules itself. This may also be done

with the newly developed DaVinci Configurator Kit. It is used to

create “BSW Module Description” files for the software modules,

define user-friendly user interfaces, establish validation rules and

create code generators for generating the executable code. The

TIER1 can also use this approach to configure its own BSW modules,

e.g. complex device drivers.

Both DaVinci Configurator Pro and DaVinci Developer contain vali-

dation rules that supplement the AUTOSAR method. They ensure that

individual parameters as well as complex parameter groups and their

interdependencies are validated and that the “ECU Configuration

Description” is generated consistently. This consistency is essential

for subsequent generation of the RTE and the BSW modules.

The AUTOSAR method is flexible and suitable for satisfying the

practical requirements of different projects or different OEMs. For

example, use of SWCs in the “System Description” is optional.

Figure 3 shows – based on the example of the tools DaVinci

Developer and DaVinci Configurator Pro from Vector – how the “ECU

design and configuration” activity can be implemented with tool

support.

Configuring and integrating all software components

During the configuration process defined in AUTOSAR, the TIER1

selects – from its component collection – those SWCs it needs for

the ECU’s functionality. Afterwards the TIER1 integrates them in its

ECU, together with the BSW modules and RTE. This shifts the pri-

mary work of integrating the ECU software from manual code adap-

tation to tool supported configuration of the BSW modules and the

RTE.

Since the current level of the AUTOSAR specifications still has

some room for interpretation, from today’s perspective it is advis-

able to procure either the entire BSW package, or at least defined

BSW clusters, from a single source. The advantage is that the soft-

ware supplier (TIER2) can already perform an integration test on

these modules. However, it is also possible to procure individual

modules from different TIER2 suppliers or use modified BSW mod-

ules. This increases integration effort, however, since both func-

tional integration and integration in the configuration tools need

to be performed.

Essentially, all MICROSAR BSW modules are tested within system-

atic integration tests. As an integration partner, Vector can extend

its integration services to software modules from thirdparty

producers, such as MCAL drivers, upon request.

AUTOSAR: NEW PATHS TO ECU SOFTWARE

Fig ure 3: Tool-supported integration of SWCs and configu-ration of RTE and BSW modules per AUTOSAR methodology

40 Press Book_Seite_6-18_6-23.indd 540 Press Book_Seite_6-18_6-23.indd 5 09.02.2010 13:27:54 Uhr09.02.2010 13:27:54 Uhr

Page 198: Vector Press Book

6/22

>> Your Contact:

Germany and all countries, not named belowVector Informatik GmbH, Stuttgart, Germany, www.vector.com

France, Belgium, LuxembourgVector France, Paris, France, www.vector-france.com

Sweden, Denmark, Norway, Finland, IcelandVecScan AB, Göteborg, Sweden, www.vector-scandinavia.com

Great BritainVector GB Ltd., Birmingham, United Kingdom, www.vector-gb.co.uk

USA, Canada, MexicoVector CANtech, Inc., Detroit, USA, www.vector-cantech.com

JapanVector Japan Co., Ltd., Tokyo, Japan, www.vector-japan.co.jp

KoreaVector Korea IT Inc., Seoul, Republic of Korea, www.vector.kr

IndiaVector Informatik India Prv. Ltd., Pune, India, www.vector.in

E-Mail [email protected]

Pascale Morizur (Dipl.-Ing.) studied Physics-Electronics at the Grande Ecole ICPI in Lyon (France). After graduating in 1986, she worked for 10 years in advanced development for CAN, J1939 and diagnostics at MAN Commercial Vehicles. Since 2005, she has been employed at Vector as Product Manager in the area of Embedded Software Components.Tel. +49 (0)711/80670-2211, Fax +49 (0)711/80670-111,E-mail: [email protected]

Matthias Wernicke (Dipl.-Ing. (FH))upon graduating in Industrial Electronics at the Polytechnical College at Ulm, was employed for four years at the Daimler Research Center in Ulm, Germany. Since early 2000 he has been working at Vector Informa-tik in Stuttgart, developing methods and tools for the design of distributed electronic functions in motor vehicles. Today he is responsible for product management of DaVinci AUTOSAR tools.

Justus Maier (Dipl.-Inf. (FH))studied Computer Science in Regensburg. He began his professional career as a developer of standardized software in the insurance industry. For 8 years he was involved in design and advanced development of tools for ECU configuration in the AUTOSAR field. He has been employed at Vector since 2006 as technical Product Manager for DaVinci Configurator Pro.Tel. +49 (0)941/20865-451,Fax +49 (0)941/20865-111E-mail: [email protected]

In the second part of this article, you will learn – based on exam-

ples of selected use cases – how the exchange files and configura-

tion tools are used in practice. The process of creating a complete

set of AUTOSAR-conformant ECU software for a specific OEM is

explained, and the article describes how to maintain the software

over time or modify it for a different OEM.

Translation of a German publication in Elektronik automotive, 11/2009

All Figures:Vector Informatik GmbH

Literature:[1] Layered Software Architecture: http://www.autosar.org/download/specs_aktuell/AUTOSAR_LayeredSoft-wareArchitecture.pdf

[2] AUTOSAR Methodology: http://www.autosar.org/download/specs_aktuell/AUTOSAR_Methodology.pdf

Links:Homepage Vector: www.vector.comProduct information about AUTOSAR: www.autosar-solutions.com

40 Press Book_Seite_6-18_6-23.indd 640 Press Book_Seite_6-18_6-23.indd 6 09.02.2010 13:27:55 Uhr09.02.2010 13:27:55 Uhr

Page 199: Vector Press Book

6/23

40 Press Book_Seite_6-18_6-23.indd 740 Press Book_Seite_6-18_6-23.indd 7 09.02.2010 13:27:56 Uhr09.02.2010 13:27:56 Uhr

Page 200: Vector Press Book

6/24

AUTOSAR: New Paths to ECU Software – Part 2

During the development of an AUTOSAR ECU, code generators are

used to adapt the basic software (BSW) and runtime environment

(RTE) to specific ECU requirements. Generation is based on the fol-

lowing extensive description files mentioned in the first part of the

article:

The “ECU Extract of System Description” contains the ECU- >

specific section of the overall system.

The “SWC Description” describes the interfaces and structure of >

the AUTOSAR software components (SWCs), and it may already

be included in the “ECU Extract of System Description”.

The “ECU Configuration Description” contains the configuration >

of the BSW modules and RTE.

The “BSW Module Description” describes the configurable >

parameters of a BSW module.

The challenge for the developer is to keep these description files

consistent while avoiding the need to recreate the whole configu-

ration whenever a change is made. In performing this task, it is

helpful to use configuration tools that support iterative work pro-

cesses during an ECU development project. Typical scenarios and

change cases are described as well as having work steps explained

based on the Vector tools DaVinci Developer and DaVinci Configura-

tor Pro.

New development of software components (SWCs)

Depending on the OEM, the “ECU Extract of System Description”

might already contain the interfaces of SWCs. In some cases, these

SWCs are still incomplete. For example, OEM-specified application

interfaces may be included, but not the implementation descrip-

tion (runnable entities) or interfaces to the standard services of

the BSW modules. The Tier1 developer can add this missing specifi-

cation with the help of a tool such as DaVinci Developer. The Tier1

may also create its own SWCs (Step D1 in Figure 4).

There are two different ways to implement the SWCs: either man-

ually based on a generated code template or with the help of mod-

el-based development (MBD) tools such as MATLAB®/Simulink®

EmbeddedCoder® or TargetLink. The “SWC Description” is imported

into the MBD tool where it serves as a basis for modeling the SWC.

Code generators are used to automatically generate SWC

implementations.

If SWCs are already available at the Tier1, they can also be inte-

grated in the ECU. This involves importing the relevant “SWC

Description” and linking the SWC to the other SWCs of the ECU

(Step D2).

AUTOSAR in Practice – Life Cycle of AUTOSAR ECU Software

The first part of the article covers the structure of AUTOSAR-conformant ECU software, the AUTOSAR development method and helpful auxiliary tool support. The second part of the article presents realistic scenarios illustrating how AUTOSAR ECU software is maintained over its life cycle.

Figure 4: Development of functional soft-ware consisting of multiple SWCs

41 Press Book_Seite_6-24_6-27.indd 241 Press Book_Seite_6-24_6-27.indd 2 09.02.2010 13:27:36 Uhr09.02.2010 13:27:36 Uhr

Page 201: Vector Press Book

6/25

Component. This SWC can also be created by a “top-down” or “bot-

tom-up” approach.

At the end of the integration process, the Tier1 gets an updated

“ECU Extract of System Description”. Besides the OEM’s original

version, the file now also contains content defined by the Tier1 and

is fully validated.

Modification of the RTE after changing SWCs

If only the implementation of a SWC changes without affecting the

SWC’s interfaces or structure, neither the RTE nor the basic soft-

ware would need to be reconfigured. However, if the structure of a

SWC changes, e.g. due to the addition of a new runnable entity, the

RTE configuration must be modified. This involves assigning the

newly added runnable entity to a task. After this modification has

been made (Step D4 in Figure 5), the RTE configuration is validated

(Step D5).

The DaVinci Developer supports this process with detailed error

messages and recommended corrections. For example, inconsisten-

cies are reported so that the Tier1 can correct the “SWC Descrip-

tion” or RTE configuration.

Incorporating changed communication data from the OEM

A typical change scenario is updating the communication data of

an ECU, e.g. because the distribution of signals to messages has

changed. Such a change is only relevant to those BSW modules

related to communication and does not require any changes to the

RTE or SWCs.

Figure 6 shows the work steps that are performed to accept the

changed communication data. The BSW modules can be adapted

automatically: First, a new “ECU Configuration Description” is gen-

erated, and the contents of the old “ECU Configuration Description”

In a separate integration step, data elements of the SWC inter-

faces are assigned to bus signals (data mapping) – provided that

the OEM has not already defined such a mapping in the “ECU Extract

of System Description”.

Typically, the “ECU Extract of System Description” will change a

number of times over the course of a project. When the Tier1

receives a new version, the SWCs it contains might also be modi-

fied. A special Update function makes it possible to accept changes

in DaVinci Developer without losing any extensions previously

made by the Tier1, such as implementation descriptions or inter-

faces to standard services.

Configuration of standard AUTOSAR services

One challenge arising in the configuration of AUTOSAR ECUs is how

to configure the standard services of the BSW modules. Within the

“ECU Extract of System Configuration”, the services are represent-

ed by special SWCs, the so-called service components. These service

components are created and integrated with the SWCs by what is

referred to as Service Mapping, which can be performed automati-

cally with tool support (Step D3).

In the “top-down” approach, the need for services is determined

from the entire functional software, and the services of the BSW

modules are configured accordingly. This approach makes sense for

those services that are not typically specified by the OEM in detail.

Examples are services of the NVM (Non-Volatile Memory Manager)

or the ECUM (ECU Manager).

In the “bottom-up” method, the service is first configured in the

BSW module, e.g. based on OEM requirements. The SWCs are then

extended to match the service configuration. An example of this is

the DCM (Diagnostic Communication Manager).

Just like the services, the ECU’s I/O interfaces are also repre-

sented by a special SWC – the I/O Hardware Abstraction

Figure 5: Work steps in con-figuring the RTE

41 Press Book_Seite_6-24_6-27.indd 341 Press Book_Seite_6-24_6-27.indd 3 09.02.2010 13:27:36 Uhr09.02.2010 13:27:36 Uhr

Page 202: Vector Press Book

6/26

are converted to the new “ECU Configuration Description” (Step

C1-2). All parameter values unaffected by the change are automati-

cally accepted. Only the parameters of the new or modified signals

or messages are then configured in Step C3. Finally, to ensure that

all parameter values are consistent, the new “ECU Configuration

Description” is validated in Step C4.

As a supplement to the AUTOSAR standard, Vector has imple-

mented an “Update” function and validation in DaVinci Configura-

tor Pro. If the OEM does not provide an AUTOSAR-conformant ECU

Extract of the System Description, the Tier1 can instead use the

familiar network description formats (DBC, LDF or FIBEX) as inputs

to the DaVinci tools.

Switching over to a different processor or processor type Thanks to the systematic hardware abstraction offered by AUTOSAR

the TIER1 only needs to replace the affected MCAL modules when

switching over to a different processor device or processor type.

This transition is performed with tool support: The old MCAL mod-

ules are removed and the new MCAL modules are added to the pro-

ject by selecting the new BSWMD files. The new platform-depen-

dent parameter values that were added are checked in DaVinci Con-

figurator Pro and reconfigured by the Tier1 as necessary (Step C3

for each changed MCAL module). Consistency of the “ECU Configu-

ration Description” is restored by final validation (Step C4).

Especially useful to the Tier1 is the ability to extend the tool

environment, e.g. to support the MCAL modules of future

processors or own BSW modules. This is enabled by the DaVinci

Configurator Kit, which is used to create the Tier1 BSWMD files and

module interface files. They contain definitions of specific configu-

ration interfaces, validation rules or generators for the BSW mod-

ules (Steps C5 and C6).

Replacing OEM-specific diagnostics

If an existing ECU configuration is to be used for a different OEM,

the ECU’s diagnostic basic software must be replaced, because it is

OEM-specific. This affects the DCM and DEM (Diagnostic Event Man-

ager) BSW modules.

Figure 7 shows how this replacement is made. The Tier1 obtains

the new CDD or ODX file from the OEM. These widely used formats

contain the diagnostic description data for the ECU. They can be

generated with tools such as CANdelaStudio from Vector. DaVinci

Configurator Pro utilizes information from these files to automati-

cally configure diagnostic BSW modules for the ECU (Step C7).

Analogous to the modified diagnostic BSW modules, the DCM and

DEM service components must also be modified and made known to

the application SWCs in a “bottom-up” process. For this purpose,

DaVinci Configurator Pro takes the “ECU Configuration Description”

and generates the “SWC description” files which include service

components for DCM and DEM (Step C8).

The Tier1 can now use DaVinci Developer to generate the service

mapping for all diagnostic services of the new OEM. Validation of

the SWCs ensures that no service is forgotten in the change

Figure 6: Work steps in configuring the basic software

41 Press Book_Seite_6-24_6-27.indd 441 Press Book_Seite_6-24_6-27.indd 4 09.02.2010 13:27:37 Uhr09.02.2010 13:27:37 Uhr

Page 203: Vector Press Book

6/27

AUTOSAR: NEW PATHS TO ECU SOFTWARE

process. If the application SWCs does not yet offer the diagnostic

services required by the OEM, they must be extended (Step D1-3),

which in turn requires modification of the RTE (Step D4-5).

Changing I/O signals

In case a new sensor needs to be connected to the ECU the new I/O

signal that it uses must be added to the “ECU Configuration

Description”. Therefore the Tier1 extends the configuration of the

I/O hardware abstraction in DaVinci Configurator Pro by adding the

new signal (Step C3 in Figure 6) and modifies the pin mapping in

the I/O drivers in the MCAL layer. After successfully validating this

configuration change, an updated SWC is generated for representa-

tion of the I/O Hardware Abstraction. By importing this SWC into

DaVinci Developer, the Tier1 can extend the SWCs of the functional

software so that they can access the new sensor.

Advantages of the AUTOSAR configuration process

The AUTOSAR principle “configuring instead of programming”

enables early validation of the ECU software architecture. This pre-

vents errors from occurring in a late phase. Nonetheless, the

AUTOSAR formats are extraordinarily complex. Good tool support is

essential to handle the changes that are typically required over the

course of a development project.

Figure 7: Work steps in modifying the diagnostic-specific software parts of an ECU

41 Press Book_Seite_6-24_6-27.indd 541 Press Book_Seite_6-24_6-27.indd 5 09.02.2010 13:27:37 Uhr09.02.2010 13:27:37 Uhr

Page 204: Vector Press Book

7/0

Networking Heavy-Duty Vehicles Based on SAE J1939

The J1939 protocol – founded in the USA and defined by the Soci-

ety of Automotive Engineers (SAE) – serves above all to preserve a

uniform perspective and uniform handling of the most common

vehicle components of various vehicle types and manufacturers. In

this context, it is interesting to note certain distinct differences

between the European and North-American heavy-duty vehicle

markets. For example, heavy-duty vehicle buyers in the USA have

prescribed to OEMs which components they need to install in spe-

cific vehicles. In Europe, on the other hand, it is the OEMs who fully

define the design of the entire vehicle, including the components

and their configuration.

Besides using uniformly defined signals and data formats to

communicate, it is of course important that receivers know how to

interpret the information. Ideally, it should be possible to inter-

connect individual J1939 components based on a plug-and-play

scheme. Despite all of its standardization aspects, J1939 gives

OEMs sufficient freedom for customized extension of communica-

tion. This is especially important in promoting innovations,

because no OEM wants to announce or discuss plans in working

committees before their implementation.

ISO Layers Model decouples the Application from Transmission Physics

From the perspective of the ISO/OSI network model, J1939 is

essentially based on the Application Layer (Layer 7), Network Layer

(Layer 3), Data Link Layer (Layer 2) and Physical Layer (Layer 1)

(Figure 1). This lets developers work with signals without needing

to be concerned about communication details on the Application

Level, such as details of the transport protocols. J1939

From Parameter Group to plug-and-play Application

In networking ECUs in heavy-duty vehicles, it is the J1939 protocol that plays a key role. J1939 networks are based on the CAN bus (high-speed CAN per ISO11898); they are primarily used in powertrain and chassis components. The protocol creates a uniform basis for communication between electronic control units, and it supports the plug-and-play principle. Special J1939 tools and software components spare developers from needing to train in the details of the J1939 protocol, and they improve the quality of the development process.

42 Press Book_Seite_7-00_7-05.indd 242 Press Book_Seite_7-00_7-05.indd 2 09.02.2010 13:25:30 Uhr09.02.2010 13:25:30 Uhr

Page 205: Vector Press Book

7/1

(PGN) – also contains the J1939 ECU address of the sender and if

applicable the address of the receiver too. In addition, the three

most significant bits of the CAN identifier are reserved for the pri-

ority field; although these bits do not replace the implicit priority

established by the CAN protocol, they make it possible to organize

the Parameter Groups into up to eight J1939-specific priority lev-

els. These priorities are used to adjust the priority to momentary

application requirements at the time the Parameter Group is trans-

mitted – or during an optional ECU configuration phase. This makes

it possible to fine-tune communication to the application without

the SAE protocol permanently setting the priority when the Param-

eter Group is defined.

documentation and definition is oriented toward individual layers,

and this is expressed in the names of the total of 14 documents of

the standard. For example, documents of the 7 series such as

“J1939/71” refer to the Applications Layer, document J1939/21

the Data Link Layer, etc.

CAN Message Format in J1939

Although J1939 utilizes normal 29-bit CAN messages with up to 8

bytes of data, here the CAN identifier quasi defines the mask of a

uniform J1939 scheme (Figure 2). This is necessary to assure plug-

and-play properties. The CAN identifier – besides identifying the

useful data with the help of the Parameter Group Number

Figure 2: The J1939 message format – which is based on normal 29-bit CAN messages – requires some supple-mentation to achieve plug-and-play capability. The CAN identifier quasi defines the mask of a uniform J1939 scheme.

Figure 1: The J1939 protocol essentially cov-ers the Application Layer (Layer 7), Network Layer (Layer 3), Data Link Layer (Layer 2) and Physical Layer (Layer 1), so that it is no longer necessary to be concerned about communication details when work-ing on the application level.

42 Press Book_Seite_7-00_7-05.indd 342 Press Book_Seite_7-00_7-05.indd 3 09.02.2010 13:25:31 Uhr09.02.2010 13:25:31 Uhr

Page 206: Vector Press Book

7/2

The Name says it all: J1939 Device Names

J1939 defines device names that are each represented by a 64-bit

number. When an ECU is switched to active in the plug-and-play

network, the device name serves to identify the device and its func-

tionality. The device name is subdivided into different elements,

between which certain dependencies exist. The independent fields

include the Industry Group and Manufacturer Code. The Industry

Group is used to establish the functions required in the network,

since the J1939 protocol is not only used in conventional heavy-

duty vehicles but also in vehicles in the agricultural and marine

industries. Each ECU carries one of the SAE assigned Manufacturer

Codes that can be requested from that organization. Since each

device also has a serial number, the complete name over all fields is

unique worldwide, and there are no overlaps.

Since addressability of the devices is inefficient in practice when

64 bit long device names are used, the SAE defines 8-bit addresses

for the individual vehicle components in the heavy-duty vehicle

field; practically these addresses never change over the life of the

components. This does not apply to the agricultural and marine

industries; there the addresses are dynamically negotiated at the

start, based on the device name. The addresses 0 to 127 are

assigned to the most commonly used ECUs such as engine, trans-

mission, retarder, brakes, etc., while the range from 128 to 247 is

reserved for agricultural, marine, construction equipment, etc.

Service tools, OBD scanners, etc. occupy addresses from 248 to

253. Finally, there are the special addresses: 254 to identify devices

that do not have their own address and 255 that is used as a global

address for addressing broadcast messages.

Types of Communication: Point-to-Point or Broadcast

The J1939 protocol supports two communication types: point-to-

point transmissions (1:1) are directed to precisely one target

address; they are used for device configuration or ECU commands,

for example. Broadcast messages (1:n), on the other hand, are

simultaneously addressed to all bus nodes, which is practical when

it comes to sending out measured values, error handling and diag-

nostic purposes.

Flexible Network Topology

J1939 works with a passive bus that is terminated at each of its two

ends with 120 Ohm impedance. The advantage here is that individ-

ual ECUs can be connected to the bus via branch lines with a length

of 1 to 3 m. This enables flexible wire harness design, provided that

a total bus length of 40 m is not exceeded. Depending on the physi-

cal transmission layer, between 10 and a maximum of 30 nodes may

be connected to the network. J1939 provides uniform diagnostic

access for service testers and on-board diagnostics. Legal require-

ments specify that a branch line with a length of up to 5 m must be

possible here, e.g. for road tests of the emissions control system.

Bridges can be used to extend J1939 networks to include trailers/

implements, enabling implementation of a separate network there

(Figure 3). In the EU, ISO 11992 has prevailed for this purpose,

while in the USA the “Power Line Carrier” is state-of-the-art

technology.

Timing Requirements in ECU Design

In designing J1939 ECUs, care should be taken to ensure that no

messages are lost due to hardware or design limitations. At a

baudrate of 250 Kbps, transmission of one bit takes 4 microsec-

onds. With 8 data bytes, a typical message length of about 128 bits

is obtained, yielding a transmission time of about 500 microsec-

onds per CAN message. The shortest message length, however, is

64 bits, i.e. it must be possible to receive messages at intervals of

250 microseconds and process them sufficiently fast. In practice,

Figure 3: With regard to network topology, J1939 enables flexible design of wire harnesses. Individual ECUs can be connected via branch lines up to 3 m in length. Bridges make it possible to realize separate networks on implements and trailers.

42 Press Book_Seite_7-00_7-05.indd 442 Press Book_Seite_7-00_7-05.indd 4 09.02.2010 13:25:32 Uhr09.02.2010 13:25:32 Uhr

Page 207: Vector Press Book

7/3

A J1939 extension is available for the widely used CANoe devel-

opment and test tool; it spares heavy-duty vehicle developers from

needing to train in the details of the J1939 protocol. The package

from Vector extends basic software functionality to cover all neces-

sary protocol-specific features. When CANoe.J1939 is used consis-

tently, the models and databases created in the design phase not

only serve as a foundation for simulation during development, but

also for all tests accompanying development up to and including

later diagnostic tasks (Figure 4). With the help of simulated nodes,

it is possible to set up and execute tests for the ECU to be devel-

oped. The tests are further refined during development and are

used in verification of the total system.

Extensive J1939 Test Library

The CANoe Test Feature Set is made up of CAPL test modules, XML

test modules and .NET test modules. They are able to cover all chal-

lenges arising in testing tasks of varying complexity, from simple

to difficult test cases. While the C-like script language CAPL is ideal

for creating extensive test scenarios, the primary focus of XML is

on simple parameterization of test patterns and simple generation

of test procedures. That makes it possible to implement applica-

tion-specific test modules (function libraries) in CAPL and then

generate test control that is individually adapted to the ECU con-

figuration. The J1939-specific extensions in the Test Service

Libraries allow the system react to Parameter Groups (PG) instead

of typical CAN identifiers. They also offer test patterns for J1939

protocol functionality and checks (background monitoring) for

protocol violations. For example, it is possible to test whether the

ECU is able to send all Parameter Groups at the configured cycle

this leads to a high interrupt load due to the CAN controller’s often

limited CAN identifier filtering capabilities. Filtering also usually

needs to be implemented in software.

Testing and Diagnostics of J1939 Components and Systems

In view of the rising number of J1939 ECUs and the fact that soft-

ware solutions in heavy-duty vehicles are becoming increasingly

complex, a systematic strategy for testing and diagnostics also

continues to gain in importance in the J1939 field. Tests are indis-

pensable in all development phases, from functional tests to inte-

gration tests to driving trials in the total vehicle. It is well known

that the later that errors are detected, the more complicated and

expensive it is to correct them. However, it is generally only possi-

ble to test ECUs comprehensively after they have been integrated

in the network structure. Consequently, weak points are often not

revealed until very late, unless one relies on the support of proven

software tools right from the start.

Given this situation, the use of specialized tools offers develop-

ers substantial simplifications in testing and diagnostic tasks. For

many years now, Vector has been actively involved in SAE J1939

subcommittees and regularly participates in working sessions. With

a universal tool chain for all J1939 projects, it is possible to effi-

ciently solve the most challenging tasks in networking and commu-

nication in the heavy-duty vehicle field [1]. Besides development,

testing and analysis tools, embedded software components tai-

lored to the special requirements of J1939-based applications are

available, and customized project work and training events round

out Vector’s products and services.

NETWORKING HEAVY-DUT Y VEHICLES BASED ON SAE J1939

Figure 4: Tests conducted with the help of simulations during development make it possible to detect and cor-rect errors early on in all develop-ment phases. The CANoe Test Feature Set offers extensive testing and analysis capabilities.

42 Press Book_Seite_7-00_7-05.indd 542 Press Book_Seite_7-00_7-05.indd 5 09.02.2010 13:25:32 Uhr09.02.2010 13:25:32 Uhr

Page 208: Vector Press Book

7/4

and are implemented step-by-step on the final target hardware

platform. CANoe.J1939 can also integrate Matlab/Simulink models

in ECU and network simulations (Figure 5). With the Real-Time

Workshop from Mathworks the user generates a *.DLL for CANoe so

that variable names and units are compatible.

Progressing through the various stages of the V development

model, individual tests and subsystem tests are possible through

final verification of the overall system. This enables early detection

and correction of errors. If an error is found, the automated tests

can be restarted at any time; they minimize the risk of side effects

in error correction. As a result, development is characterized by

short verification cycles, enabling a seamless transition from MIL

(Model in the loop) to SIL (Software in the loop) and then to the

real ECU (HIL – Hardware in the loop). If there are exceptional real-

time requirements of the simulation platform, a special real-time

version is available with CANoe RT.

Realizing Goals quickly with standardized Embedded Software Components

Use of CANbedded J1939 software components leads to quick

development results. These components largely relieve developers

of the need to handle all of the details of the J1939 standard, and

they avoid duplicated developments. A key aspect is a central OEM-

managed database containing all elementary information related

to ECU communication. Depending on requirements, this informa-

tion might be distributed to other working partners, producing

flexible distribution of tasks between the OEM, network specialists

from Vector and suppliers (Figure 6). The latter can use the GENy

configuration tool for specific settings and parameterizations. The

time under high bus load. Furthermore, it is possible to send faulty

transmissions via the BAM (Broadcast Announce Message) and

CMDT (Connection Mode Data Transfer) transport protocols for test

purposes.

To create the test modules – besides the J1939 Test Module Man-

ager and the convenient Test Automation Editor – the Option DiVa

is useful. DiVa creates a connection between CANoe and the diag-

nostic specification tool CANdelaStudio, so that specifications cre-

ated there can be ideally used in further ECU-specific diagnostic

tests.

Other functions of the Test Feature Set relate to test flow control

and automatic report generation, including statistical information

in XML or HTML format based to individual requirements. Further

options for automating test processes are enabled by the COM

interface, e.g. options relating to flow control, parameter changes

or status queries. CANoe Option J1939 provides a trace window,

J1939 diagnostic monitor and J1939 diagnostic memory access for

diagnostic purposes. The diagnostic monitor supports various

J1939 diagnostic messages, such as DM1 and DM2, and it serves to

display and clear active errors. Also possible is access to memory

areas, objects and parameters as well as periodic object updating

for monitoring purposes.

Integrating Matlab/Simulink Models in J1939 Network Simulations

Generally, various function models are created for mechanical com-

ponents such as transmission, powertrain or even the entire vehicle

during the different heavy-duty vehicle development phases. ECU

architectures are initially saved in virtual CANoe function models

Figure 5: Not only is CANoe able to simulate functional models of ECUs during the development process and inte-grate models created with Matlab/Simulink in the scenarios; at the same time it also serves as a convenient user-interface. (Source: Renault Trucks)

42 Press Book_Seite_7-00_7-05.indd 642 Press Book_Seite_7-00_7-05.indd 6 09.02.2010 13:25:32 Uhr09.02.2010 13:25:32 Uhr

Page 209: Vector Press Book

7/5

results are reduced cost and timing for implementation and test-

ing, compatibility on the CAN bus based on unambiguous signal

interpretation and maximum quality and flexibility in the J1939

communication stack. CANbedded J1939 supports all relevant

microcontrollers and is characterized by low ROM and RAM memory

requirements as well as high runtime efficiency.

Internet links: [1] J1939 solutions from Vector – www.j1939-solutions.com[2] Download of presentations from J1939 User Day – www.vector-worldwide.com/ud [most of them are German]

NETWORKING HEAVY-DUT Y VEHICLES BASED ON SAE J1939

Peter Fellmeth studied at the University of Applied Sciences in Esslingen, Germany, majoring in Computer Engineering and specializing in Automation Technology. He is team leader and product manager at Vector Informatik GmbH, where he is responsible for the development of products and customer-specific projects related to J1939, ISOBUS, Ethernet and DeviceNet.

Thomas Löffler studied Automation Technology at the Uni-versity of Applied Sciences in Reutlingen, Germany. He has been employed at Vector Informatik GmbH since 2000, initially in the DeviceNet area, and since 2002 in the J1939 and ISOBus area. His areas of specialization are configuration and generation tools for embedded software, support of customer projects and product and protocol training programs.

Figure 6: Standard software components of the CANbedded J1939 package lead to quick development results without developers needing to be concerned with all details of the J1939 standard. A centrally managed database avoids duplicated develop-ments and enables optimal work distribution.

42 Press Book_Seite_7-00_7-05.indd 742 Press Book_Seite_7-00_7-05.indd 7 09.02.2010 13:25:32 Uhr09.02.2010 13:25:32 Uhr

Page 210: Vector Press Book

CAN and J1939 un der Ex treme Du ty Con di tions

In con trast to con ven tion al off-road ve hi cles, the tech ni calchal lenge for the Pis ten Bul ly is to mas ter the nu mer ous ex -treme sit u a tions en coun tered in cold, snow and night timeop er a tion. The ma chine, ca pa ble of mov ing in any di rec tionon in clines up to 45°, cov ers an ar ea of 96,000 m2/h with itsmul ti flex till er. This tech nol o gy is stand ard equip ment fordu ties up to 4,000 m above mean sea lev el and ex treme out -side tem per a tures; the el e va tion ca pa bil i ty of the po lar ver -sion even reach es up to 6,000 m.

Great est Safe ty un der Ex treme Con di tionsSlope groom ing is of ten sched uled for even ing and night -time hours, while there are no reg u lar win ter sports ac tiv i -ties. If ve hi cle driv ers are un der way alone in a snow storm orfog at high el e va tions or in Arc tic re gions, the re li a bil i ty andavail a bil i ty of the ve hi cles can be life pre serv ing fac tors.Safe ty as well as com fort a ble and fa tigue-free steer ing andcon trols were there fore key as pects of the ve hi cle con cept.In tel li gent au to mat ic func tions sup port the driv er and re -duce the num ber of con trol in ter ven tions need ed, so thatthe driv er can con cen trate on what is im por tant.Im pact and punc ture re sist ant wind shield glass pro tects thedriv er from rock im pacts, and a light ing sys tem with a widear ray of run ning lights, search lights and work ing lights turnnight in to day. Au to mat ic in te gra tion of a rear cam era im age

in the cock pit dis play al so pro vides op ti mal vis i bil i ty whendriv ing in re verse. To sup port groom ing on steep in clines theve hi cles can be op tion al ly equipped with elec tro-hy drau licca ble drums that car ry 1,000 m of ca ble. A spe cial fea ture isfree ro ta tion of the drum, al low ing the ve hi cle to turn 360°as of ten as de sired. Be sides mod els for use on moun tainsand snow, there are al so Pis ten Bul ly ver sions with out a load -

7/6

Ve hi cle elec tron ics guar an tees func tion al i ty in cold, ice and snowAny one who has par tic i pat -ed in win ter sports at onetime or an oth er is fa mil iarwith them: The slopegroom ers that tire less lypre pare the ski slopes andtrans port goods to moun -tain sta tions or in jured per -sons safe ly down to the val -ley. They not on ly em body aspe cial spe cies of all-ter -rain track ve hi cle, they al sode liv er the ex pe ri ence of true high per form ance. Ve hi cle elec tron ics play a de ci sive rolein the in cred i ble ca pa bil i ties of these ma chines. With out elec tron ics nei ther func tion al i -ty nor safe ty nor any oth er sig nif i cant in no va tions would be con ceiv a ble. This tech ni calar ti cle of fers in sights in to the ve hi cle tech nol o gy, de vel op ment proc ess and de vel op -ment tools of the lat est gen er a tion of Pis ten Bul ly ve hi cles from the Käss boh rer Com pa ny.

Fig ure 1:Up to 620 Pis ten Bul lys are pro duced in Lau pheim ev eryyear

43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 1

Page 211: Vector Press Book

start ing up from a stop and pre vents ad verse events such asstall ing. Si mul ta ne ous ly, load lim it con trol of fers pro tec tionagainst over load ing and over rev ving of the die sel en gine.

A sin gle gas ped al is used to ac cel er ate and de cel er ate (brak -ing), i.e. there is no work ing brake, on ly a park ing brake.Chan ges in driv ing di rec tion are achieved by dif fer en tialtrack speeds. Each drive has in fi nite ly var i a ble out put speedad just ment and its di rec tion of ro ta tion can be re versed. As are sult, the ful ly elec tron ic steer ing can sup port turn ing inplace, pre-se lec tion of driv ing di rec tion and speed re duc -tion. The “steer ing ag gres sive ness” va ries with driv ingspeed; the driv er can ad just it to his or hers spe cif ic needs.This means that the driv ing speed can be changed by gas

ing plat form, ver sions ex clu sive ly used to trans port per son -nel, ex ca vat ing ver sions and even ver sions that can swim.Käss boh rer pro du ces about 600 to 620 units per year, andthe cost per ve hi cle lies be tween 80,000 and 340,000 eu ros.

Pow er for Driv ing, For Ski Lifts and Emer gen cyElec tri cal Gen er a torsThe ve hi cles are driv en by en gines from Mer cedes-Benz withpow er rat ings be tween 90 HP and 460 HP. The lat est Pis ten -Bul ly 600 has a stand ard 12.8 Li ter en gine de liv er ing 295 kW(400 HP) and tor ques of up to 1,900 Nm. Two in de pend enthy dro stat ic drive cir cuits with out sep a rate clutch es are re -spon si ble for trac tive pow er to the right and left sides. Theen gine con trol ler de liv ers the re quired en gine torque when

7/7

Fig ure 2: Over view of CAN net works in the cur rent Pis ten Bul ly

43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/7

Page 212: Vector Press Book

ped al or load lim it con trol with out af fect ing the turn ing ra -di us. Wheel sen sors en a ble straight-line and uni form curvecon trol or asym met ri cal steer ing char ac ter is tics for spe cialap pli ca tions.

Noth ing runs with out ve hi cle elec tron icsElec tron ics is or at least was of ten con sid ered a nec es sa ryevil by con ven tion al ma chine build ing com pa nies. The Käss -boh rer Com pa ny, whose or i gins are in the steel build ing in -dus try, has come full cir cle in its per spec tive here. With outelec tron ics any mean ing ful in ter play be tween com plex ve hi -cle com po nents would be in con ceiv a ble. Ve hi cle elec tron icsis ev er present, from steer ing, con trol of the en gine and hy -drau lic sys tem, con ve nien ces of ve hi cle nav i ga tion and thecon trol of im ple ments, to func tions for op er a tion al da ta ac -qui si tion, tel em at ics and GPS.Con sist ent and thor ough net work ing of the ve hi cle by CAN(Con trol ler Ar ea Net work) was a pre req ui site for achiev ing ade cen tral ized con trol struc ture. This made it pos si ble to ra -tion al ly com bine elec tron ic and me chan i cal com po nents tomake one con trol mod ule. In com par i son to ear li er Pis ten -Bul ly gen er a tions, de cen tral i za tion has en a bled sig nif i cantre duc tions in wir ing costs. Near ly all com mu ni ca tion is rout -ed over the two pri ma ry bus es CAN1 and CAN2 (of a to tal offive CAN bus lines). While CAN3 is used for ex ter nal com mu -ni ca tions in fleet man age ment, the CAN4 and CAN5 sys tems

are re served for fu ture func tions not cur rent ly need ed, andthey are tech ni cal ly ready to im ple ment them. Ad di tion al ly,CAN is util ized for soft ware up dates, pa ram e ter con fig u ra -tion and in meas ure ment sys tems. Since all func tions cancur rent ly be im ple ment ed with CAN, the use of new er com -mu ni ca tion sys tems such as Flex Ray, LIN or MOST is not cur -rent ly un der dis cus sion. The elec tri cal sys tem is set up to beful ly mod u lar and is uni form across all ve hi cle var i ants. Sincethe ba sic wir ing al ready con sid ers all cur rent and fu ture op -tions, it is easy to ac com plish ex pan sions and re trof its bymeans of adapt er wire har ness es.

Lots of pow er elec tron ics, just a few fus es andno re laysThe Pis ten Bul ly uni ver sal PSX con trol mod ule is re spon si blefor cen tral con trol of all func tions such as per form ance andpow er man age ment, en gine con trol, hy drau lics of the driveand till ing pumps, oil flow dis tri bu tion of the work ing hy -drau lics, front and rear, as well as mon i tor ing of all sen sorsand ac tu a tors. It is sup ple ment ed by the “cen tral elec tron -ics” unit, which be sides of fer ing nu mer ous di ag nos ti cal ly ca -pa ble and short-cir cuit pro tect ed in puts/out puts, al so hous -es oth er func tion al i ty such as cen tral lock ing, RF re motecon trol, light ing con trol and volt age con vert ers for 12 V. Thefull load ca pa ble unit sup plies a summed con tin u ous cur rentof 640 A at 24 V and there by achieves a switch ing ca pac i ty ofup to 15 kW. The “Cen tral elec tron ics” unit has con nec tionsto all five CAN bus es. In to tal there is need for just eight “ac -tu al” fus es; ev ery thing else has been im ple ment ed to beshort-cir cuit pro tect ed and “self-heal ing” with out re lays.

Ma neu ver ing is easy and in tu i tiveCon nect ed to the in ter nal ve hi cle bus (CAN1) are the con -trols and dis play el e ments of the cock pit. In ad di tion to theer go nom ic sem i-cir cu lar steer ing wheel, al so in cludes a mul -ti func tion dis play with touch screen, round CAN in stru ments,a Ter mi nal Con trol Cen ter (TCC) in te grat ed in the arm restand a joy stick with pro gram ma ble func tion but tons.

The mul ti func tion dis play gives mo men tary in for ma tion at aglance on the most im por tant op er at ing states and on driv -ing speed, ca ble drum ten sion, en gine da ta, etc. It of fers in -

7/8

Fig ure 3:Con trols and dis play com po nents in the Pis ten Bul ly cock pit

43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/8

Page 213: Vector Press Book

CAN AND J1939 UN DER EX TREME DU T Y CON DI TIONS

7/9

Fig ure 5:CA Noe in flash mode

Fig ure 4: CA Noe as joy sticksim u la tor for test inghy drau lic valves

43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/9

Page 214: Vector Press Book

tu i tive con trol, on the touch screen or via the TCC. The op er -at ing pan el mount ed to the right of the driv er with its filmkey pad lets the us er se lect nu mer ous Pis ten bul ly func tionsdi rect ly. A joy stick is used to con trol the var i ous move mentsof the snow blade and of the rear im ple ment car ri er as wellas used to set the till ing pres sure, ca ble drum ten sion, etc.The joy stick is an in-house de vel op ment, since none of thecom mer cial ly avail a ble mod els could sat is fy the ex pec ta tionsof Pis ten bul ly de vel op ers.

CAN con trols hy drau lic mod uleCAN2 serves as a sen sor-ac tu a tor bus for en gine con trol andvalve con trol and an in ter face for sen sors. The hy drau lic val-ves are driv en en tire ly via CAN, i.e. with out sup ple men talan a log or dig i tal I/O sig nals. On the part of the sen sor/ac tu -a tor bus, so-called mul ti-mod ules pro vide in put chan nels,dig i tal out puts, PWM out puts and bridge out puts that are di -ag nos ti cal ly ca pa ble, short-cir cuit pro tect ed and self-heal -ing. The sen sors con nect ed here are all equipped with 4 to

20 mA cur rent in ter fa ces to au to mat i cal ly com pen sate forcon tact re sist an ces when elec tri cal con nec tions cor rode. While Käss boh rer util iz es its in ter nal KGF pro to col for theCAN1 func tion al bus, the J1939 pro to col is used on CAN2 forthe drive sys tem. The ad van tage of stand ard ized drive man -age ment based on SAE J1939 is that the drive sys tem can bebuilt with com po nents from out side sup pli ers, in de pend entof the ve hi cle pro duc er, in clud ing a suit a ble di ag nos tic sys -tem. On the func tion al side, the pro pri e tary pro to col wasused in ten tion al ly to pre vent un au thor ized ma nip u la tionsand si mul ta ne ous ly to pro tect know-how. That is why it wasal so de cid ed not to use the CCP (CAN Cal i bra tion Pro to col)stand ard for the ECU ap pli ca tion. The CAN bus sys tems canbe pa ram e ter ized and di ag nosed from a lap top.

Safe re turn to the val ley even if the bus failsIt is in ter est ing that X-by-wire sys tems have al ready beenused in Pis ten Bul ly pro duc tion ve hi cles since the 1970s, whi-le its im ple men ta tion in gen er al road ve hi cles was not even a

7/10

Fig ure 6:CA Noe in meas ure -ment da ta ac qui si -tion dur ing ve hi cletrials

43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/10

Page 215: Vector Press Book

de vel op ers on a project like the Pis ten Bul ly must re ly onpow er ful tools for soft ware de vel op ment too. Over the cour-se of the de vel op ment proc ess it is es sen tial to per form de sign func tions, tests and sim u la tions of sub sys tems andover all sys tems. This is where CA Noe with the J1939 Op tionfrom Vec tor comes in to play. CA Noe’s ca pa bil i ties as a de vel op ment and sim u la tion toolrange from sim u la tion of a sin gle net work node, to test ingand di ag nos tics, to rep re sen ta tion of com plete CAN net -works. Be gin ning with in i tial stud ies on the pure ly vir tu almod el, the vir tu al nodes can grad u al ly be re placed by re alhard ware step-by-step over the fur ther course of de vel op -ment. In this case, ve hi cle func tions are ex e cut ed by a vir tu -al ECU in an OSEK em u la tion. Among oth er things, thismakes it pos si ble to con trol and dis play the states of vir tu alsen sors and ac tu a tors. It is al so pos si ble to gen er ate as so ci -at ed con trol pan els au to mat i cal ly.

Short de vel op ment timesAt Käss boh rer some of the us es of CA Noe are to sim u late busloads, func tion as a meas ure ment tool and pa ram e ter izeECUs by the pro pri e tary KGF Pro to col. The de vel op ers usethis pro to col to gen er ate di ag nos tic and set up in for ma tionin tem per a ture tests, EMC tests and re ac tion tests of valvecon trols, for ex am ple, and this helps them to keep so lu tionsfor pro duc tion ve hi cles lean.

CAN AND J1939 UN DER EX TREME DU T Y CON DI TIONS

7/11

top ic of dis cus sion un til dec ades lat er. En tire ly dif fer ent le gal reg u la tions ap ply to the op er a tion and safe ty of pureoff-road ve hi cles not sub ject to high way ve hi cle reg is tra tion,since the ve hi cles are used ex clu sive ly on pri vate land. Ifthere is fail ure of the steer ing po ten ti om e ter, driv ing di rec -tion push but tons and/or the re dun dant gas ped al with acon tact less sen sor, driv ing ca pa bil i ty is pre served as long aspos si ble. The ve hi cle, weigh ing in at be tween 7 and 10 met -ric tons and ca pa ble of a max i mum speed of 23 km/h, canthen be driv en safe ly back to the val ley with emer gen cy run -ning char ac ter is tics at a throt tled-down speed of 5 km/h.Even if both CAN bus es fail the Pis ten Bul ly re mains ma neu -ver a ble with con trol via PWM sig nals.For the elec tron ics, be sides sat is fy ing re quire ments for harshtem per a ture and hu mid i ty con di tions and me chan i cal stress -es, oth er spe cial re quire ments al so ap ply, e.g. with re gard toelec tro mag net ic com pat i bil i ty. This en sures that the highfield strengths of ra dio trans mit ters on moun tain peaks willnev er im pair ve hi cle func tions.

From sim u la tion to re al Pis ten Bul ly elec tron icsSoft ware de vel op ment and ve hi cle cal i bra tion cov er ing allcon trol mod ules are all per formed at the Käss boh rer Com pa -ny. This lets the pro duc er from Lau pheim adapt flex i bly tonew op er at ing sit u a tions. Since the com plex i ty of the soft -ware and the elec tron ic func tions is con stant ly grow ing,

Fig ure 7: Easy fault lo cal i za tion for the driv er with OBD

43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/11

Page 216: Vector Press Book

The de vel op ment of du al-chan nel fan con trol in the Pis ten -Bul ly was com plet ed in an ex cep tion al ly short time with oututil iz ing re al hy drau lic pumps, valves or mo tors. In such cas -es CA Noe re al is ti cal ly sim u lates all nec es sa ry CAN nodes,sen sor sig nals and ECU in for ma tion. In ECU set up CA Noe en -a bles ac cess to EE PROM con tents via an in-house flash pro to -col. This is easy to re pro gram with the in te grat ed pro gram -ming lan guage CAPL (Com mu ni ca tion Ac cess Pro gram mingLan guage). The EE PROM da ta stored on the hard drive can beload ed in to the con trol ler at any time.

In dis pen sa ble: Re al-time ca pa bil i ty of de vel op -ment toolsAn em ploy ee ex plains: “As de vel op ers we re ly on good tools,and CA Noe’s re li a bil i ty is ex cel lent! Re al-time ca pa bil i ty ises pe cial ly im por tant to us. We have al ready had neg a tive ex -pe ri en ces with sim i lar soft ware on an oth er project. It tookdays of troub le shoot ing to fi nal ly find out that the tool sim -ply could not keep pace with our sam pling rate re quire ments,and this led to er ro ne ous re sults.”In-house us er in ter fa ces, pan els and oth er tools that are fre -quent ly need ed are gen er al ly pro grammed in-house at Käss -boh rer us ing Bor land C++. Even in such cus tom de vel op -ments CA Noe da ta bas es al ways serve as the foun da tion.More over, CA Noe fa cil i tates op ti mal co op er a tion with sup pli -ers since the be hav ior of as sem blies can be test ed in ad -vance. The Pis ten Bul ly de vel op ers on ly re gret that not allsys tem sup pli ers pro vide CA Noe sim u la tions of their pro -ducts or make them avail a ble ear ly on.

Mo bil i ty for fine tun ing on the slopesAn oth er im por tant as pect is tool mo bil i ty. Since snow con di -tions are con stant ly chang ing, fine tun ing of the drive sys -tem is of ten per formed lo cal ly in the moun tains. When it isim por tant to per fect con trol loops for the var i ous types ofslope prep a ra tions and adapt them to lo cal con di tions, CA Noe op er at ed on a lap top proves to be an ef fi cient mo biledi ag nos tic and meas ure ment lab o ra to ry.

Com pre hen sive ve hi cle di ag nos tics on a dis playscreenThe ve hi cle can be ful ly pa ram e ter ized at any time via a pro -

gram ming PC that is con nect ed to the CAN di ag nos tic con -nect or. For ev ery Pis ten Bul ly there is an elec tron ic ve hi clerecord that seam less ly doc u ments soft ware up dates, the lifeof in di vid u al com po nents, cur rent soft ware lev els, etc. It ispos si ble to re store the de liv ered state at any time. If prob -lems oc cur at the cus tom er, On-Board Di ag nos tics of fers fastand con ve nient fault lo cal i za tion over the cock pit dis play. Allhy drau lic func tions, sen sors and ac tu a tors are de signed tobe elec tron i cal ly di ag nos a ble. All that is need ed for in-ve hi -cle troub le shoot ing is a cir cuit di a gram and the dis play; nooth er equip ment is need ed. Stored in the fault mem o ry arethe er ror his to ry and er ror fre quen cies.

All fig ures: Käss boh rer Gel än de fahrzeug AG

7/12

Au thors:

Thom as Böck (Grad u ate En gi neer) stud ied gen er alelec tri cal en gi neer ing at the tech ni cal col lege inKempt en, Ger ma ny. He man a ges de vel op ment inthe elec tron ics/hy drau lics ar ea.Tel. 07392/900-254, Fax 07392/900-259,E-mail: thom as.boeck@pis ten bul ly.com

Pe ter Betz (Grad u ate En gi neer) stud ied tel e com -mu ni ca tion en gi neer ing at the tech ni cal col lege inUlm, Ger ma ny. He is re spon si ble for sys tem de vel -op ment in the elec tron ics de vel op ment ar ea.Tel. 07392/900-262, Fax 07392/900-259,E-mail: pe ter.betz@pis ten bul ly.com

Mark us Hör mann (Grad u ate En gi neer) stud ied tel -e com mu ni ca tion en gi neer ing at the tech ni cal col -lege in Kempt en, Ger ma ny. He man a ges test equip -ment con struc tion in the elec tron ics test ing ar ea.Tel. 07392/900-250, Fax 07392/900-249,E-mail: mark us.ho er mann@pis ten bul ly.com

Lo thar Fel bing er (Grad u ate En gi neer) stud ied au to ma tion en gi neer ing at the tech ni cal col lege in Re u tlin gen. Since then he has been work ing asKey Ac count and Busi ness De vel op ment Man a ger atVec tor In for ma tik GmbH for the Open Net work ingprod uct line. Tel. 0711/80670-505, Fax 0711/80670-555,E-mail: lo thar.fel bing er@vec tor-in for ma tik.de

43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/12

Page 217: Vector Press Book

7/13

43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/13

Page 218: Vector Press Book

7/14

Current Trends in Network Development for Heavy-Duty Vehicles

The number of ECUs, and hence the amount of software, has multi-

plied since electronification began in the early 1990s. While this

primarily related to the engine controller at the beginning, a large

number of electronic “helpers” are being implemented today.

Examples include ABS, ESP, ACC and other driver assistance systems

that make highway traffic safer and driving more pleasant. Analy-

ses [1] assume that their implementation will increase further, and

that electronic control modules will account for 90% of all innova-

tions by the year 2010. A key aspect is that 80% of these innova-

tions will exclusively involve software or the functions implemented

in software. In this context, it is clear that software development

methods play a crucial role in the development process for the total

vehicle, and they have a significant influence on a vehicle’s success

or failure on the market.

Compared to automobiles, heavy-duty vehicle manufacturers are

confronted by the special challenges of the relatively large number

of variants with significantly lower volumes. Although simultane-

ous use of electronic ECUs over different brands and integration of

standardized components can reduce cost pressure, they make the

design of electronics and software more complex.

Flexible solutions are in demand

When one considers the variety of strategies used by different

heavy-duty vehicle manufacturers, it quickly becomes clear that

there is no universal solution. However, from a bird’s eye perspec-

tive clear trends can be seen, such as the use of standards, code

generators and a universal tool chain. The number of ECUs is

Factors of success in electronic development

ECU networking in heavy-duty vehicles is characterized by the same challenges as in the automobile. Added difficulties are caused by the large numbers of variants with low production volumes and longer product life cycles, requiring a suitable architecture layout. Specially modified development methods are indispensable in handling cost pressure and sending reli-able vehicles onto the street.

44 Press Book_Seite_7-14_7-17.indd 244 Press Book_Seite_7-14_7-17.indd 2 09.02.2010 13:26:23 Uhr09.02.2010 13:26:23 Uhr

Page 219: Vector Press Book

7/15

the available signals, but also the use of communication protocols.

In Europe, for example, proprietary communication protocols are

often used, which is similar to the situation in the automotive

industry there. In the North American market, however, the SAE

J1939 protocol dominates for heavy trucks. There are also differ-

ences in the area of in-vehicle diagnostics: In Europe, OBD diag-

nostics is implemented per UDS (ISO15765), and in the USA per SAE

J1939-73.

Attaining the goal by different approaches

The approach at MAN Nutzfahrzeuge AG is based on use of an inte-

grated development database known as the “Common Engineering

Data Backbone”. All vehicle-specific functions are developed from

this platform, and all vehicle-specific information is stored there.

The eASEE Tool Suite from Vector – with its 8 domains – serves as a

universal development database, and it was specially adapted to

requirements at MAN in the framework of a configuration process

(Figure 1). It serves the needs of functional development and as a

description of the communication matrix. Since MAN relies on the

SAE J1939 standard as much as possible in communication, eASEE

was adapted to the requirements of the J1939 protocol.

A special module that was developed for MAN and adapted to the

Data Backbone serves as a bridge between modeling in eASEE and

automatic code generation for the ECUs (Figure 2). In code gener-

ation, the Munich-based heavy-duty vehicle producer relies on

proven CANbedded.J1939 standard software components from

Vector. CANbedded.J1939 gets all of the information it needs for

configuration and code generation directly from the database, and

it can generate the embedded code without manual interventions.

This enables immediate transfer of changes made in modeling to

the ECU code. This process prevents errors such as incorrect config-

uration of the code generating tool and guarantees error-free and

complete code generation. This process also simplifies verification

increasing at a rather moderate rate, while the number of functions

implemented purely in software continues to grow rapidly.

Common to solution strategies is the use of a comprehensive and

universal tool chain – from requirements to validation. The use of

individual, non-coordinated tools proved to be impractical in the

past. The configuration processes and work results of individual

tools are too different. This makes it difficult to achieve universali-

ty of change requirements during development. Thus, a change

would need to be made in different tool configurations without any

automatic, inter-tool consistency check. This causes organizational

friction losses, especially in inter-departmental or inter-site devel-

opment projects.

Therefore, a database with authoring tools should stand at the

center of the tool chain. Both the database and authoring tools

need to be specifically adapted to the requirements of the specific

vehicle manufacturer. Besides purely technical aspects, the tools

also take the individual development process of the companies into

account. Variants management, configuration management and

even the maintenance of workflows are represented in the tools. If

external suppliers need to be integrated in processes, the data

exchange formats that are used may be standards or de-facto

industry standards such as the CANdb++ data format by Vector

Informatik. In some cases, the vehicle manufacturer also prescribes

the use of certain tools to its suppliers. They are then tightly cou-

pled to the database and support the supplier especially in such

aspects as compatibility to requirements, quality and efficiency.

Examples would be code generators for embedded systems or test

tools such as the CANoe.J1939 development and test tool from

Vector.

System design is becoming increasingly complex due to growing

requirements for networking. Individual ECUs are being installed

on different platforms and different countries, which increases the

number of variants. This requires flexibility in communication

structures and in mapping functions to ECUs. This not only affects

Figure 1: The MAN Common Engineering Data Backbone

44 Press Book_Seite_7-14_7-17.indd 344 Press Book_Seite_7-14_7-17.indd 3 09.02.2010 13:26:24 Uhr09.02.2010 13:26:24 Uhr

Page 220: Vector Press Book

7/16

AUTOSAR integration of J1939 makes it possible to achieve funda-

mental independence in tool selection. Volvo chose Vector as its

supplier of tools and embedded software components, since Vector

already offers solutions in all areas, and it was possible to adapt

them to Volvo-specific requirements very flexibly.

Literature references: [1] J. Svensson, “The Use of AUTOSAR in Volvo Group”, presentation at

Vector J1939 User Day; slides may be downloaded at: www.vector-informatik.de/j1939ud [most of them are German]

of the total system, since sections of the software have already

been checked. It is possible to reuse the communication data for

analysis tools like CANalyzer.J1939 or test tools like CANoe.J1939

from Vector, supporting the development of application layers.

The Volvo Truck Corporation chose a strategy for software devel-

opment that has now become established in the automotive indus-

try too: the use of AUTOSAR and its overlying tools (Figure 3). The

benefits of this approach lie in the use of standardized and proven

tools. They offer benefits in a development used intensively across

brands that is distributed among many business sites. Common

understanding of the underlying software structures and architec-

ture is quickly achieved. It is easier to integrate suppliers, and it is

not absolutely necessary to specify tools. This reduces dependen-

cies on individual tool producers and suppliers.

Problematic in this approach is the use of communication meth-

ods that are either incompatible with AUTOSAR properties or can

only be used with it in a proprietary way. The use of J1939, in par-

ticular, should be mentioned in this context. While AUTOSAR essen-

tially assumes a network of known nodes – and therefore a commu-

nication matrix that is known at the time of integration – this is

decidedly not the case for J1939 with its plug-and-play concept.

Volvo Trucks confronted this challenge with a two-prong approach.

The first step was to identify which parts of J1939 were used in

Volvo vehicles and integrate them in the existing Vector AUTOSAR

tool chain. Secondly, Volvo – together with Vector and other Euro-

pean heavy-duty vehicle manufacturers – adopted portions of the

J1939 protocol in AUTOSAR. This strategy lets Volvo exploit the

advantages of AUTOSAR directly and universally. On the other hand,

Peter Fellmeth is a team leader and product manager at Vector Informatik GmbH, where he is respon-sible for the development of products and customer-specific projects related to J1939, ISOBUS, Ethernet and DeviceNet.

Figure 2: Code for the ECUs is generated based on the description of the electronic structure in eASEE’s functional data management.

Figure 3: When standard-ized data formats are chosen, standard products can be used to describe and create the ECU-specific software.

44 Press Book_Seite_7-14_7-17.indd 444 Press Book_Seite_7-14_7-17.indd 4 09.02.2010 13:26:24 Uhr09.02.2010 13:26:24 Uhr

Page 221: Vector Press Book

The reliable, effi cient way

to design and test networks

Development processes for open networks in commercial vehicles

can be implemented in the most cost-effective approach with

minimal time using specialized assistance:

> Develop your network design in a systematic approach using

reliable tools

> Successfully implement software components for both

proprietary and standardized J1939, CANopen and

AUTOSAR protocols

> Benefit from efficient configuration and extensive

diagnostic, testing and analysis solutions

The seamless interaction of Vector tools and Vector’s com-prehensive services will improve the efficiency of your entire development process, from design to analysis.

Information and Downloads: www.j1939-solutions.com

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel. +49 7 11 8 06 70-0

www.vector.com

SOLUTIONS FOR

Commercial Vehicles

.J1939

.J1587

.CANopen

Conformance Testing

CANoe.J1939 supports SAE

J1939-82 Compliance Tests

44 Press Book_Seite_7-14_7-17.indd 544 Press Book_Seite_7-14_7-17.indd 5 09.02.2010 13:26:25 Uhr09.02.2010 13:26:25 Uhr

Page 222: Vector Press Book

7/18

Automatic Interoperability Tests for ISO11783 Systems

In the agricultural machinery field, the information age has long

taken hold, and system thinking has replaced insular solutions. As

a result, a uniform data interface for interconnecting the tractor,

implements and on-board computer has become indispensable in

agricultural equipment. In this context, the internationally coordi-

nated bus system ISOBUS was developed and introduced for the

first time at the 2001 Agritechnica fair. ISOBUS standardizes data

communication between tractor, implements and farm manage-

ment computers and enables system-wide data exchange. The

ISO11783 series of standards consists of 14 sub-standards; they

each address different aspects of the technology, ranging from Sys-

tem Description (Part 1), Physical Layer (Part 2), Data Link Layer

(Part 3), Network Layer (Part 4) and Virtual Terminal (Part 6), Diag-

nostics (Part 12) and File Server (Part 13).

“One person’s pleasure is another’s pain” is common folk wis-

dom. The situation is similar with the requirement for unlimited

compatibility (system and manufacturer independent) of ISO11783-

compatible products [1]. For the customer this is not only very easy

to handle, it also opens up the possibility of purchasing flexibility

and independence from the manufacturer. That in itself is a large

motivational factor in procuring such machinery. For manufactur-

ers, however, this promise represents a great challenge in terms of

development, operation and maintenance of the machines. CANoe.

ISO11783 from Vector offers a universal development and testing

solution here. Option ISO11783 for the CANoe tool provides the

necessary domain knowledge and supports conformity to the

ISO11783 standard (Figure 1).

Experience over the past two years in the ISOBUS field has shown

that despite a sharply rising number of devices certified by confor-

mity tests [2], different components, such as the Task Controller

and implement, do not always harmonize in their interaction with-

out problems. There is the potential for surprises in operation of an

Universal test solution assures compatibility

The required “unlimited compatibility” of components on the ISOBUS cannot be attained by performing conformity tests at the end of device development alone. Rather, sound and continual tests over the entire development phase are necessary. Efficient use of such tests can only be achieved by using tools with domain knowledge that cover a large number of tasks ranging from simulation to analysis tests as well as conformity tests. Developers of implements and tractors need a tool that covers conformity testing, cycles through the tests independently, yet offer the freedom to only test certain sections and can be extended to test the application.

45 Press Book_Seite_7-18_7-21.indd 245 Press Book_Seite_7-18_7-21.indd 2 09.02.2010 13:28:34 Uhr09.02.2010 13:28:34 Uhr

Page 223: Vector Press Book

7/19

ISO11783-12 compatible diagnostic tool to detect problems related

to an implement from a different manufacturer. The technician

might not be able to correct the problem, but can clearly identify

its cause. If the cause lies in the implement, the tractor manufac-

turer’s service technician – who was summoned by mistake – can

call up valuable information such as error codes or part numbers of

the affected components to give the implement manufacturer’s

service technician advance information on the problem. This keeps

downtimes to a minimum and leads to a higher level of customer

acceptance of ISOBUS-equipped machinery.

Ongoing efforts to extend Part 12 of the ISO11783 draft stand-

ard are taking the direction of a standardized description format

for diagnostics. This would let each manufacturer describe diag-

nostic contents individually for each ECU. A prepared diagnostic

application could use this description to diagnose the ECU regard-

less of which company manufactured it. The diagnostic description

file might be downloaded from the ECU itself or over the Internet.

Manufacturers with their own company-specific diagnostic tool

would integrate ISO11783 diagnostics into their existing tool. Man-

ufacturers without their own custom tools could use future stand-

ardized diagnostic tools. One practical benefit is that a service

technician would have system-wide diagnostic capability with just

one tool. This enables efficient and reliable localization of the real

causes of errors and ideally to correct them right away.

implement when the Virtual Terminal is used too. As well as for ser-

vice technicians, in such a heterogeneous environment as the

ISOBUS it is difficult to definitively localize the cause of a problem

and correct it if necessary. Frequently, the technician is confronted

with unfamiliar devices or combinations of devices. In view of these

problems, and to assure customer satisfaction, the manufacturer’s

initiative AEF (Agricultural Industry Electronics Foundation) set up

a project group tasked with conducting activities to improve the

interoperability of ISOBUS devices [3].

Uniform diagnostic access for the worst case

In the framework of standardization tasks, along with continual

efforts to refine and extend test cases of the conformity test, Part

12 of the ISO11783 draft standard [4] was written to create a com-

mon diagnostic interface. It is based on SAE J1939-73 diagnostics

[5]. The section of Part 12 of the ISO standard that has already

been published, what is referred to as basic diagnostics, defines

open diagnostic access. It provides basic functionalities and is

intended to enable a system overview. This includes unique identi-

fication of the ECUs on the bus as well as information on the soft-

ware version, manufacturer’s part number and the conformity test

performed. Each ECU can report momentary errors, and when

requested by the diagnostic tool it can also report previous errors.

This information is intended to enable quick and reliable localiza-

tion of the error causes. This is especially advantageous if a net-

work consists of components from different manufacturers. For

example, the tractor manufacturer’s service technician can use an

Figure 1: CANoe.ISO11783 can be used to uti-lize, analyze and simulate the complex communication structures of the ISOBUS standard easily and efficiently. Shown here is simulation of the File Server, two implements and the Virtual Terminal.

45 Press Book_Seite_7-18_7-21.indd 345 Press Book_Seite_7-18_7-21.indd 3 09.02.2010 13:28:34 Uhr09.02.2010 13:28:34 Uhr

Page 224: Vector Press Book

7/20

certain aspect are desired, e.g. a check of the Transport Protocol.

Such tests conducted over the course of development are generally

performed very frequently, they have many alternative test

sequences, and they must be flexible in their configuration. There-

fore, such tests should be designed for automation. If problems

occur during the test, extensive analytical capabilities are needed

as well.

One tool for all cases

CANoe.ISO11783 from Vector is a universal development and test

solution that is used to verify conformity to the ISO11783 standard,

providing the necessary domain knowledge [6]. The Virtual Termi-

nal, for example, is a fixed component of CANoe (Figure 1). Diag-

nostic messages can be visualized using the Diagnostic Trouble

Code Monitor and Scanner. The integrated Test Feature Set makes it

possible to define frequently recurring tests and entire test

sequences. The test sequences can be easily defined by XML, for

Automated tests during the development phase

Introduction of uniform diagnostic access helps to quickly identify

a problem on-site and possibly replace the defective part. If there

is some incompatibility, however, the situation is generally very

different. Replacing the electronics does not offer any help, since

this does not correct the cause of the problem. In such a case, cor-

rected ECU software would be necessary. However, it would take

time to produce and test this software. In addition, distribution of

the modified software is often costly, since devices must be

recalled from the field. Suitable preventive actions can be taken to

avoid such compatibility problems. One option is the conformity

test mentioned in the introduction. However, a disadvantage here

is that the application itself is not part of the test. The focus in

conformity testing is to test conformity to the standard. In addi-

tion, it is difficult or impossible to use the conformity test during

development, since 100 percent compatibility cannot be assumed

at the beginning of development. Often just point checks of a

Figure 2: Phases of Test creation and inter-faces with the CANoe.ISO11783 Test Feature Set: from creating the test sequence to evaluating the results.

Figure 3: Used in tandem, CANoe.ISO11783 and the Vector VT System form a “Midsize HIL”.

45 Press Book_Seite_7-18_7-21.indd 445 Press Book_Seite_7-18_7-21.indd 4 09.02.2010 13:28:35 Uhr09.02.2010 13:28:35 Uhr

Page 225: Vector Press Book

7/21

example. Figure 2 shows a schematic representation of the Test

Feature Set. In such an environment, CANoe.ISO11783 may assume

the role of the test master and link to or drive other tools over vari-

ous interfaces such as COM or .NET. It is also possible to integrate

CANoe.ISO11783 in an existing test environment via the same

interfaces. Because of its extensive simulation and analysis capa-

bilities, its use is not limited to just testing or simulation of indi-

vidual ECUs. The tool can simulate entire networks (simulation of

the remaining bus). For example, operation of an implement could

be simulated via a Task Controller or the Virtual Terminal. With the

help of Vector test hardware VT System, CANoe.ISO11783 also

directly drives real consumers such as actuator motors and an ECU’s

outputs, or reads in sensors (Figure 3). CANoe.ISO11783 can be

used to utilize, analyze and simulate the complex communication

structures of the ISOBUS standard easily and efficiently. It is a

comprehensive, universal tool for verifying conformity over all

product phases: from development to operation and service of the

working machinery.

Literature and links: [1] VDMA Professional Society for Agricultural Engineering: ISOBUS speaks

all languages. Just speak along with it.2005, pg. 2[2] VDMA Professional Society for Agricultural Engineering: ISOBUS-con-

formant devices per the ISO 11783 standard, www.isobus.net/isobus_E[3] www.aef-online.org/[4] Society of Automotive Engineers: J1939[5] International Organisation for Standardization: ISO/FDIS 11783-12,

ISO11898[6] www.vector.com/isobus

AUTOMATIC INTEROPERABILIT Y TESTS FOR ISO11783 SYSTEMS

Peter Fellmeth studied Computer Engineering at the Univer-sity of Applied Sciences at Esslingen, Germa-ny, specializing in Automation Technology. He is a team leader and product manager at Vector Informatik GmbH, where he is respon-sible for development of products and customer-specific projects related to ISOBUS, SAE J1939, Ethernet and DeviceNet.

45 Press Book_Seite_7-18_7-21.indd 545 Press Book_Seite_7-18_7-21.indd 5 09.02.2010 13:28:35 Uhr09.02.2010 13:28:35 Uhr

Page 226: Vector Press Book

In developing electron-ics for modern construc-

tion equipment, a large share can even be tested and simulated meaningful-ly on test benches. In lat-er development stages, on the other hand, it is prefer-able to perform tests and trial runs under real condi-tions at construction sites or outdoor test sites. To avoid distracting the operator in the driver’s cabin with test equipment, a wireless in-terface has now been re-alized for the first time with the CANoe and CANalyz-er development and analy-sis tools from Vector Infor-matik. Electronics develop-ers at Bomag GmbH now use this interface to log the communication on various vehicle buses at a distance and analyze it. Quality re-quirements in earthmoving work and highway construc-tion are continually growing with a simultaneous rise in cost and time pressure. Soil compaction and cost-, raw material- and energy-sav-ing methods of road pres-ervation and reconstruction are often only possible with intensive use of high-tech electronic functions. Bomag is the global market leader in the field of compaction technology. At its lead-plant in Boppard, this company – part of the Fayat Group – produces about 30 000 ma-chines annually for soil, as-phalt and garbage compac-tion as well as stabilizers/recyclers. Today, a large share of the company’s ex-pertise has its foundation in electronics.

When it comes to net-working technology, Bomag

bases its work on the CAN bus standards of the auto-motive industry. Initially, the electronics concept was es-tablished on the large 10-t to 15-t machines, and it was then ported to the small-er machines. Since Bomag would like to have hardware and software components be reused as often as pos-sible within the overall cor-porate group, the focus was on a modular concept. This also required standardiza-tion of development and test equipment across their business sites.

Nothing works without electronicsHigh-tech equipment and electronics can be found ev-erywhere in the machines, from remote controls to drive-by-wire steering sys-tems to the use of GPS. Sensors continually acquire the soil composition, and the display graphically in-dicates to the driver where compacting work is still needed. The GPS option

enables satellite-support-ed, large-scale compaction monitoring with seamless documentation of all pa-rameters. In the future, ra-dio networks will provide for data exchange between the machines driving in a group. The new type MPH 125 sta-bilizer/recycler – with an op-erating weight of 24.5 t and a power of 440 kW – is the

machine with the most ex-tensive electronics system and the most CAN nodes. First, it is used to improve and reinforce existing soil materials by mixing in lime, fly ash or cement, and sec-ondly for milling, pulverizing and recycling existing mate-rials in-place and locally.

Network cluster with multiple CAN busesAll Bomag machines of a given product line have the same control system, and they acquire their specif-ic control functionality in end-of-line parameteriza-tion. Therefore, electron-ic developers mapped the machine’s modular product concept to a modular CAN-based network cluster. CAN 1 – as the central Body-CAN bus – is connected to the most bus nodes. Its operation is based on the CANopen protocol, which enables the use of standard

Wireless analysis in a multi-protocol CAN environment

Timo Löw and Andreas Nacke (both Bomag), Holger Heit and Hans-Werner Schaal (both Vector Informatik)

Fig. 1: The electronics on the MPH 125 support efficient implementation in soil stabilization and recycling

Fig. 2: The electronics concept reflects the modular lay-out of the machines

66 CAN Newsletter 2/2008

Dev

ice

7/22

46 Press Book_Seite_7-22_7-25:Press Report 4 09.02.2010 13:13 Uhr Seite 1

Page 227: Vector Press Book

automation components. Besides the vehicle’s main computer, the data acquisi-tion unit of the front frame and I/O module of the rear frame, CAN 1 nodes also include control and display components in the cockpit. Conventional analog and digital sensors are inter-faced to the data acquisition unit, e.g. hydraulic pressure sensors and fill level sen-sors. The I/O module on the rear frame is responsible for control of the variable-height rotor, lateral tilt angle and lowering cabin feature for transport purposes. It was possible to significant-ly reduce wiring cost and ef-fort by interfacing controls to the bus; these include the CAN-bus-capable joy-sticks, LC displays and ex-ternal switches. Bomag cre-ated an in-house develop-ment of a CANopen driving lever with friction brake.

The powertrain bus is defined as CAN 2, and it in-terconnects the vehicle’s main computer, engine con-troller, steering and driving levers, including operator consoles on the right and left. Interesting here is that the J1939 and CANopen protocols are implement-ed in parallel on CAN 2. A special feature of the drive control system is load-lim-it control of the Deutz die-sel drive, which provides for dynamic power distri-bution between higher mill-ing power at low speed and lower milling power at high working speed as a function of soil composition.

Besides CAN 1 and CAN 2 there may be a third

CAN 3 data bus, depen-ding on how the MPH 125 is equipped. It incorporates an optional metering comput-er with auxiliary display and the necessary actuators for water injection. Similarly, CAN 3 is needed to inter-face to the metering system for bitumen emulsion and foamed bitumen.

Multi-protocol capable toolsIn electronics develop-ment, Bomag implements a number of software tools from Vector Informatik. The Stuttgart-based networking specialist offers tailor-made tools for all electronic devel-opment tasks, such as CA-Noe for network develop-ment and ECU tests, CANa-lyzer for analysis of bus data and CANape for calibrating ECUs. At the beginning of development, CANoe sim-ulates the behavior of indi-vidual bus nodes or entire sub-networks (rest-of-bus simulation). Over the fur-ther course of ECU devel-opment, the models serve as a foundation for analy-sis, testing and integration of bus systems and ECUs. The C-like programming language CAPL and user-defined interfaces simpli-fies the user’s work. A spe-cial real-time configuration significantly improved real-time capabilities even fur-ther, first by using separate PCs for rest-of-bus simula-tion and test execution, and second by graphic control/evaluation; this yielded the high performance of a com-ponent HIL tester.

Fig. 3: J1939-specific interpretation of data in the Trace Win-dow is performed with CANalyzer.J1939

67CAN Newsletter 2/20087/23

46 Press Book_Seite_7-22_7-25:Press Report 4 09.02.2010 13:13 Uhr Seite 2

Page 228: Vector Press Book

The CANalyzer anal-ysis tool offers numerous functions for bus analysis. They range from tracing the bus data traffic to display-ing signal values, perform-ing statistical evaluations of messages, busloads and disturbances, and finally targeted generation of spe-cific bus disturbances.

CANape is used in the calibration of electron-ic ECUs. All important vari-ables and parameter sets can be modified and visu-alized in real time. Helpful in conjunction with the de-

velopment of GPS appli-cations is CANape Option GPS, which supplements the system with visualiza-tion of the momentary ve-hicle positions on an elec-tronic map.

The universality of Vector tools is paying off at Bomag by helping it to master the complex chal-lenges of working with mul-tiple buses, and in partic-ular the J1939/CANopen multi-protocol environment. The consistently applied database concept is an im-portant pillar for the effi-ciency of the development tools. All members of the tool chain access the same data set, so that it is possi-ble to save all data consis-tently without unnecessary redundancies or sources of error. Fitting for the bus sys-tems used, the relevant da-tabases of the network de-scription are either already integrated or automatically generated to match the net-work configuration.

Besides supporting CAN, the tools also support the LIN, FlexRay and MOST buses as well as the higher level protocols J1939, J1587, NMEA2000, ISO11783 and CANopen. In the case of Bomag, CANape and the CANalyzer/CANoe options for J1939 and CANopen are used. Protocol-specific ex-tensions of the tools relieve the user of the need for de-tailed training in the J1939 or CANopen protocol; this avoids faulty interpretations of CAN frames. Last but not least, another important re-

quirement in the analysis of muli-bus/multi-protocol en-vironments is that a uniform time base must always be present as a foundation for analyses.

No need for an ‘umbilical cord’What has been difficult for Bomag electronics devel-opers to achieve until now is time-synchronous anal-ysis of the measurement data during the field tests mentioned in the introduc-tion without having to be passengers in the machine. They were only able to ex-amine the logged data after-wards, but not during a test. For these and similar cas-es, there is now a techni-cally mature WLAN solution from Vector: While previ-ously it was absolutely nec-essary to maintain physical contact to the bus system being analyzed when work-ing with the tools, the spe-cialists from Stuttgart have

now made it possible to es-tablish contact with the DUT by an extension via a mod-ified WLAN system. So the transceiver cable between PC and CAN bus is quasi removed and replaced by the radio pathway. Notewor-thy here is the fact there are no significant compromis-es with regard to accura-cy or measurement require-ments. In implementing the extension, special attention was given to satisfying re-quirements for correct tim-ing in data transmission, low latency times and time-syn-

chronous display of the data on the PC. The CAN mes-sages – together with their time stamps – are tunneled via a TCP/IP connection, so that the time stamps provid-ed with the messages can serve as reference times for CANoe and CANalyzer.

‘Drilled out’ WLAN solutionThis solution offers some key advantages compared to the capabilities of a sim-ple CAN/WLAN bridge.

Only a bridge head-er is necessary for this set-up. Sufficient as a host is a WLAN-capable laptop/notebook, which maintains the connection via stan-dard on-board resources and WLAN. The “probe” on the DUT that is responsible for converting from CAN to WLAN sends the messages in strict and chronologically-correct order by considering the time stamps originally

logged on the bus, which would not be possible via a CAN-WLAN-CAN bridge. During machine operation at the construction site, the Bomag electronics develop-ers can measure, observe and evaluate without a hard wire connection to the ma-chine.

Summary and outlookThis example from the com-mercial vehicle sector shows that there are interesting and demanding challenges outside of the realm of auto-motive electronics for luxu-ry cars, challenges that can only be handled by com-plex network clusters and high-performance devel-opment and analysis tools. The universality of Vector solutions pays off here. The tools enable analyses and simulations directly on the higher layers of J1939 and CANopen. The use of mul-tiple buses or simultaneous use of different protocols on the same bus do not pres-ent any problems. The tools always ensure correct tim-ing with the same time base in data acquisition and eval-uation – even in the case of wireless communication. The Bomag developers al-ready have their sights set on the next WLAN project involving automatic, multi-day durability tests. Thanks to a WLAN connection, the electronics developers are able to continually observe events on the relevant bus systems with the mentioned tools. That can be done from the office or via the In-ternet, e.g. from home dur-ing the weekend.

Sources: Fig.1 and 2: Bomag GmbH, Fig. 3 and 4: Vector In-formatik GmbH

holger.heit@ vector-informatik.de

[email protected]@

bomag.comhans-werner.schaal@

vector-informatik.de

Fig. 4: The extended WLAN tunnels the CAN messages, including time stamp, via a TCP/IP interface, thereby enabling time-conformant representation of the data

68 CAN Newsletter 2/20087/24

46 Press Book_Seite_7-22_7-25:Press Report 4 09.02.2010 13:13 Uhr Seite 3

Page 229: Vector Press Book

7/25

46 Press Book_Seite_7-22_7-25:Press Report 4 09.02.2010 13:13 Uhr Seite 4

Page 230: Vector Press Book

7/26

Moving Communication

Modern driver assistance systems are indeed capable of looking

into the distance, but only with sensors (Radar, Lidar, ultrasonic,

cameras, infrared, etc.) installed on-board the vehicle. Their rang-

es, and consequently their prediction abilities, are limited. In

efforts to prevent hazardous driving situations and optimize traffic

flow, it is considerably more promising to evaluate information

from other traffic participants as well. Communication with the

external environment is necessary to utilize measured values from

external sensors. This takes other vehicles into consideration (Car-

2Car communication) as well as stationary systems known as “road-

side units”, e.g. at traffic lights or tunnel entrances (Car2Infra-

structure communication). The applications are extremely diverse,

ranging from warnings of traffic jams around a curve with restricted

visibility to the transport of current information related to driving

route optimization or parking situations. The required transmission

technologies such as WLAN and pWLAN are already available.

Wireless Analysis of In-Vehicle Networks

In the future, data communications in the automobile will also take place beyond the vehicle’s boundaries. New require-ments are evolving, especially in the development of applications such as Car2x and remote diagnostics. These challenges are best solved with relevant tool support, where CAN messages are tunneled via the wireless air interface.

Figure 1: The electronics in the MPH 125 sup-port its efficient use in soil stabili-zation and recycling.

47 Press Book_Seite_7-26_7-29.indd 247 Press Book_Seite_7-26_7-29.indd 2 09.02.2010 13:28:47 Uhr09.02.2010 13:28:47 Uhr

Page 231: Vector Press Book

7/27

Wireless analysis of modern construction equipment

In the electronic development of modern construction equipment,

it makes sense to conduct a large share of testing and simulation

on test benches. In the advanced development stage, however, it is

preferable to conduct testing and trial runs under real conditions

at construction or test sites. In a joint project with Vector, elec-

tronic developers at BOMAG GmbH implemented a wireless inter-

face to the development and analysis tools CANoe and CANalyzer.

This allowed developers to log communications of the various vehi-

cle buses remotely and analyze them.

BOMAG, the global market leader in the field of compaction tech-

nology, bases its networking technology on the CAN bus standards

of the automotive industry. High-tech equipment and electronics

can be found everywhere in the machines, from remote controls to

drive-by-wire steering systems and the use of GPS. The new stabi-

lizer/recycler model MPH 125, with an operating weight of 24.5

metric tons and power output of 440 kW, is the machine with the

most extensive electronic systems and the most CAN nodes. On the

one hand the machine serves to improve and stabilize existing soil

materials by mixing in lime, fly ash or cement. On the other hand it

is used to mill, shred and recycle existing local and on-site materi-

als (Figure 1).

While the advantages sound promising for all traffic partici-

pants, the challenges for developers are great too. Although the

developer had extensive capabilities for analyzing a vehicle’s vari-

ous data networks and their interactions with one another, today

the developer is faced with the dilemma of not being able to sit in

two or more vehicles simultaneously.

Wide-ranging applications

Besides its use in the development of future driver assistance sys-

tems, there are many other application areas for wireless analysis

of bus systems. A typical example would be the testing of agricul-

tural and construction equipment. With the enormous growth in

functionality and automation, CAN-based bus systems have already

made in-roads in these fields for a long time now. The problem

often encountered here is that the developer cannot ride aboard

the equipment during field trials under real operating conditions.

In stationary networked systems as well, especially in the area of

factory automation, there are bus systems that are difficult to

access (due to heat, gases, etc.) and whose analysis is simplified –

or even made possible – by a wireless interface.

The following example, a real application in the development of

construction machines, shows that today there are already solu-

tions that can fulfill current Car2x and remote diagnostic

requirements.

Figure 2: The electronics concept addresses the modular structure of the machines to integrate customer-requested options: metering com-puters, water injection, bitumen emulsion or foamed bitumen.

47 Press Book_Seite_7-26_7-29.indd 347 Press Book_Seite_7-26_7-29.indd 3 09.02.2010 13:28:48 Uhr09.02.2010 13:28:48 Uhr

Page 232: Vector Press Book

7/28

Without “umbilical cord”: Wireless field tests now possible

Previously, it was difficult for BOMAG electronic developers to con-

duct time-synchronous analysis of measurement data during the

field tests mentioned in the introduction, without having to ride

along in the machine. They were only able to examine the logged

data afterwards, but not during a test. For these and similar cases,

there is now a technically mature WLAN solution from Vector. While

previously it was absolutely necessary to maintain physical contact

between the tools and the bus system being analyzed for this work,

the specialists from Stuttgart have now made it possible to estab-

lish contact with the device under test (DUT) via WLAN by adding a

tool extension.

In implementing the extension, special attention was given to

satisfying requirements for correct timing in data transmission, low

latency times and time-synchronous display of the data on the PC.

The CAN messages – together with their time stamps – are tunneled

Network cluster with multiple CAN buses

Electronic developers have modeled the product concept as a mod-

ular CAN-based network cluster (Figure 2). CAN 1 – as the central

CAN Body Bus – is connected to the most bus nodes and operates

under the CANopen protocol, which enables the use of standard

automation components. The Powertrain Bus is defined as CAN 2

and combines the main vehicle computer, engine controller, steer-

ing and driving control levers, including user control consoles on

the left and right. In CAN 2, the J1939 and CANopen protocols are

used in parallel. Depending on how the MPH 125 is configured,

there may be a third CAN 3 data bus as well (Figure 2).

Figure 3: The WLAN extension tunnels the CAN messages along with their time stamps via a TCP/IP connection, which enables time-conformant display of the data on a PC. As a result, the user experiences hardly any of the limitations of hard-wire communication.

Figure 4: Panels in CANoe.IP helps to visualize signals. Signals are dis-played in the Data and Graphic win-dows, while analy-sis of the Ethernet protocol and signal decoding appear in the Trace Window.

47 Press Book_Seite_7-26_7-29.indd 447 Press Book_Seite_7-26_7-29.indd 4 09.02.2010 13:28:48 Uhr09.02.2010 13:28:48 Uhr

Page 233: Vector Press Book

7/29

via a TCP/IP connection, so that the time stamps provided with the

messages can serve as reference times for CANoe and CANalyzer

(Figure 3).

Extended WLAN solution has advantages

This solution offers some key advantages compared to the capabili-

ties of a simple CAN/WLAN bridge. Only one bridge head is neces-

sary in this setup. Sufficient as a host is a WLAN-capable laptop/

notebook, which maintains the connection via standard on-board

resources and WLAN. The “probe” on the DUT responsible for the

CAN-on-WLAN conversion sends the messages in strict and correct

chronologically order by evaluating the time stamp originally

logged on the bus; this would not be possible via a CAN-WLAN-CAN

bridge. During machine operation at the construction site, BOMAG

electronic developers can measure, observe and evaluate without a

hard-wire connection to the machine.

Development, simulation and testing of embedded systems

Vector now offers Option IP for the simulation, testing and analysis

tools CANoe and CANalyzer to provide a wireless interface to a CAN

bus system (Figure 4). As in the example described above, it is now

possible to analyze CAN bus systems with the help of a CAN-WLAN

gateway and a test computer connected via WLAN. CAN-based

J1939 and CANopen protocol extensions to CANoe and CANalyzer

are supported as are extensions for ISO11783, NMEA2000 and

DeviceNet. It is also possible to analyze CAN bus systems on spa-

tially separated vehicles, which is necessary for the development of

future driver assistance systems in the framework of Car2x. In this

case a common time base is established by CANoe/CANalyzer.IP to

synchronize the probes on the different vehicles. If an overabun-

dance of data makes the bandwidth of the WLAN connection too

narrow, the CAN-WLAN gateway can be replaced by a second test

computer with CANoe.IP. It is then possible to perform filtering or

preprocessing of the data on that computer to limit the actually

transmitted information to what is essential.

Besides facilitating wireless transmission of CAN messages,

CANoe.IP and CANalyzer.IP also enable the analysis of Ethernet-

based networks, sending of Ethernet packets and simulation of

gateways between Ethernet and CAN.

MOVING COMMUNICATION

Frank Weber is Product Management Engineer for the Open Networking product line at Vector Informatik GmbH.

Hans-Werner Schaal is Business Development Manager for the Open Networking product line at Vector Informatik GmbH.

47 Press Book_Seite_7-26_7-29.indd 547 Press Book_Seite_7-26_7-29.indd 5 09.02.2010 13:28:49 Uhr09.02.2010 13:28:49 Uhr

Page 234: Vector Press Book

7/30

Prototyping and Testing CANopen Systems

The bandwidth of tasks in the development of CANopen systems

ranges from developing individual ECUs to configuring and starting

up total systems. For system producers, the initial use of a system

such as CANopen is associated with an incalculable startup effort.

In the framework of the V-model, a large share of development

tasks involves verification and validation. The risk of detecting

errors too late is minimized by comprehensive tests at the earliest

possible time (Figure 1).

System verification with test setups

Systematic tests accompanying the development of a total system

are indispensible in all development steps. Often it is possible to

test, but not until a very late time, when actual system components

are available. Then, the system completion date is at risk if prob-

lems occur.

In practice, tests are not performed on the real system at the

customer’s facilities, rather test setups are used for this purpose.

Besides special measurement or diagnostic setups, in testing they

also include actuators for simulating system environments as real-

istically as possible. Depending on the project size, such a test set-

up could incur much cost and effort. Bottlenecks are built into the

process during the test phase, since generally only one test setup

is available.

A way out of this dilemma might be offered by a software tool

that could be used to create a prototype of the future total system

in a simple way. Optimally, this tool would also offer extensive test

functions.

Creating a prototype environment with tool support

Above all, prototypes of total systems networked by CAN should

support testing and validation activities. In addition, it is impor-

tant to represent the individual components by real or simulated

ECUs. This makes it relatively easy to test the functional capabilities

of real ECUs over the course of system development.

Creating a prototype for a complex total system is a complicated

endeavor in which it pays to use suitable tools. CANoe.CANopen

from Vector offers valuable assistance in creating communication

for the prototype system. In just a few configuration steps, it lets

the user create a prototype whose communication properties match

those of the later real system.

The behavior of the CANopen ECUs is defined in description files

(EDS – Electronic Data Sheet) that are selected or created

Reaching goals rapidly with minimal effort

CANopen established itself as a standard for cost-effective and flexible networking of components in numerous application fields ranging from industrial automation to commercial vehicles. Standardized device profiles simplify communication between bus nodes and facilitate smooth interplay between the ECUs, sensors and actuators from different manufacturers. A specialized prototyping and test tool not only performs valuable services in developing complex CANopen projects, but also in providing a fundamental introduction to the subject area.

Figure 1: Representation of the V-model

48 Press Book_Seite_7-30_7-33.indd 248 Press Book_Seite_7-30_7-33.indd 2 09.02.2010 13:25:05 Uhr09.02.2010 13:25:05 Uhr

Page 235: Vector Press Book

7/31

Test functionality

After the prototype system has been completed, the necessary

tests for the total project follow. CANoe supports the user here,

both in creating tests and in logging and evaluation. The test func-

tionality required for a CANopen system comprises several stages

(Figure 4):

Protocol level: >

Tests on this level ensure that CANopen-specific communication

protocols of the individual devices are implemented within the

total system according to specification.

Communication level: >

What is important here is not the correctness of the protocol, but >

the correct logical order of (independent) protocol sequences,

e.g. in configuring PDOs. Description of the PDO-relevant entries

in the object directory must conform to a specific sequence.

Application level: >

Application tests check the relationships between process

variables. The following preconditions must be met to even

determine such relationships: First, the process variables must

be exchanged via PDOs, and the system must be fully configured.

This means, for example, that the state of a valve can be checked

as a function of a temperature or a pressure. Clearly, the user

must have the relevant know-how to formulate the test.

beforehand. This next step is to define the interrelationships

between calibration data that will later be exchanged over the bus,

e.g. the “PressureValve” input of the device with address 5 (pres-

sure transducer) is linked to the “Gas pressure” variable of the

device with address 10 (control module). This is how all PDO (Pro-

cess Data Object) interrelationships are defined in the prototype

system.

The tool automatically computes the resulting mapping, which

can be modified later if necessary. From this configuration infor-

mation (DCF – Device Configuration File) the user now generates

the prototyping environment, i.e. CANoe generates a counterpart

for each real ECU with identical communication properties. When

CANoe is started, the communications portion of the prototyping

environment is already available (Figure 2).

Defining application behavior

The application behavior of individual ECU nodes cannot be derived

directly from the EDS files, since they only map the structure of an

object directory. Therefore, formulation of application behavior

always involves additional programming effort. The CAPL program-

ming language integrated in CANoe makes it possible to program

ECU behavior quickly. As an alternative it is possible to code ECU

behavior in a DLL that is linked in the prototyping environment

under CANoe. It is also easy to integrate Matlab/Simulink models

(Figure 3).

Figure 2: Sample configuration of a simple, simulated CANopen network with central control and I/O node

48 Press Book_Seite_7-30_7-33.indd 348 Press Book_Seite_7-30_7-33.indd 3 09.02.2010 13:25:05 Uhr09.02.2010 13:25:05 Uhr

Page 236: Vector Press Book

7/32

Summary

When prototypes are created in CANopen networked systems, this

process always involves considerable effort. Yet the process is often

essential to prevent findings on functionality from being delayed

until a later project phase. Special tools such as CANoe.CANopen

offer the user efficient support in creating prototypes. The require-

ments for technical aspects of communication, in particular, are

very easy to cover in this way. In every phase of a project, this gives

the system developer the test functionality needed to check and

verify components completed up to that point in time.

Creating and executing test procedures with CANoe

Test sequences are formulated under CANoe with the help of the

integrated CAPL programming language. Each CAPL test module

represents a separate test consisting of individual test cases, which

in turn contain a number of test steps. During the test run, CANoe

processes the individual test cases sequentially. Suitable test flow

control makes it possible to skip or repeat individual tests. Simulta-

neously, it is possible to monitor conformance to other conditions

and restrictions – quasi in background. This might be done, for

example, to determine – while waiting for a specific message of

interest – whether a specific other message is sent periodically on

the bus.

Especially in automated tests, it is important to record the

results of individual test steps in detail. Other CAPL functions han-

dle writing of test results to an XML file for later post-processing.

Test sequences for CANoe can also be specified under XML. This is

advantageous when a large number of test flows need to be gener-

ated with a single tool. So CANoe utilizes a number of test patterns

specified in XML and processes them accordingly.

Figure 3: Representation of the CANoe. CANopen environment

48 Press Book_Seite_7-30_7-33.indd 448 Press Book_Seite_7-30_7-33.indd 4 09.02.2010 13:25:05 Uhr09.02.2010 13:25:05 Uhr

Page 237: Vector Press Book

7/33

PROTOT YPING AND TESTING CANOPEN SYSTEMS

Mirko Tischer, Product Manager for CANopen.

Figure 4: Test levels in CANopen

48 Press Book_Seite_7-30_7-33.indd 548 Press Book_Seite_7-30_7-33.indd 5 09.02.2010 13:25:06 Uhr09.02.2010 13:25:06 Uhr

Page 238: Vector Press Book

The growing complexity of today’s system archi-

tectures is associated with an increase in the effort that must be invested in test specification, test creation and test execution during the development of such systems and system com-ponents. Test specifications should be available in early phases of the development process, e.g. after the sys-tem architecture has been created or during compo-nent design. This makes it possible to detect errors early and correct them cost-effectively.

The development pro-cess for a CANopen system can be described based on the V-model. In the first phase, system requirements are defined, which for the most part contain the defini-tions of individual “use cas-es”. This information repre-sents the input for the next step, where initial assess-ments can already be made of the system architecture. Functions are assigned to

the individual ECUs, and device descriptions can be created for all devices in the form of EDS files (the for-mat of the EDS files was standardized by CiA and is being further developed by this organization in cooper-ation with industry). In ad-dition, communication re-lationships between the ECUs can be configured, as network management and error detection mech-anisms. EDS files describe

significant parts of the function-al scope of a CANopen de-vice. These de-vice descriptions form the founda-tion for execut-ing the simula-tion and creating test specifica-tions. Commu-nication-specific tests can be de-rived directly from the device descriptions. An example of this would be a test that checks all

objects in the object diction-ary by SDO accesses and records the results. Besides communicat ion-speci f ic tests, application-related tests can also be specified. An example of such a test would be to stimulate the transmission of the digital input of an I/O device. Af-terwards, a check is made to verify that the signal val-ue exists at the output. Both tests could be used early in the simulated overall sys-tem. As soon as the sta-bility of the overall system has been achieved, devel-opment of the individual components can be sub-contracted. The EDS files can – with the exception of application-related behav-ior – be considered as a re-quirements specification for the supplier. Parallel devel-opment of the ECUs at the suppliers is accompanied by the simulated overall system. Application-related tests can also be utilized at the supplier to test the be-havior of the device to be developed within the over-all system. This can signifi-

cantly reduce the number of cost-intensive changes de-sired by the OEMs – which generally occur within the integration phase. Commu-nication-specific tests can be created at the supplier in a similar way as at the OEM.

After completion and acceptance of the compo-nents, they are successive-ly integrated into the simu-lated overall system. The previously created commu-nication and application-related tests can now be applied to the system, con-sisting of the physical com-ponents and the rest-of-bus simulation. As soon as all of the components have been delivered the concluding test of the real overall sys-tem follows.

EDS files as the basis for tests

The development process should include the creation of an EDS file appropriate to the device. Unfortunate-ly, practice shows that de-vice producers often ne-

Automatic testing of CANopen devices

Kai Schmidt (Vector Informatik)

Fig. 1: Development process of a CANopen system

Fig. 2: Device functionality

8 CAN Newsletter 2/2008

Tool

s

27/34

49 Press Book_Seite_7-34_7-37.indd 249 Press Book_Seite_7-34_7-37.indd 2 09.02.2010 13:25:18 Uhr09.02.2010 13:25:18 Uhr

Page 239: Vector Press Book

glect this work step. Faulty or incomplete EDS files are the result; in the worst case there is no EDS file at all for a device. The development process described above shows that it is not just de-vice producers who need to be concerned with creation of EDS files, but system de-signers too.

The task of the system designer here is to distrib-ute functionalities to the in-dividual components. These could be standardized func-tionalities such as mech-anisms for process data communication, but they might also be manufactur-er-specific functionalities. Both of these are mapped via objects in the object dic-tionary. CiA specifications describe standardized func-tions. Standardized param-eters (process data, config-uration and diagnostic data) as well as manufacturer-specific data can be stored in a database format that is also standardized. The nec-essary objects can be se-lected from the object pool that is created in this way, and be assembled into an object dictionary.

The device descrip-tions contain all of the in-formation necessary for simulation of the CANopen device. The overall system, consisting of the individual device descriptions, is pa-rameterized utilizing a suit-

able configuration tool, and an initial system descrip-tion is obtained in the form of device configuration files (DCF), whose format has also been standardized by CiA. Based on this config-uration, simulation models can be generated and exe-cuted in a suitable runtime environment. At an early point in the project, this al-ready enables conclusions about the time behavior of the overall system. If exces-sive bus loads occur, for ex-ample, actions can immedi-ately be initiated to correct the problem, since suppli-ers have not been involved in the development process yet. Accordingly, the simu-lated overall system offers a high degree of flexibility. It can be refined iteratively until it satisfies the defined requirements. Changes to the simulated system can be implemented cost-effec-tively and be checked im-mediately.

Derivation of test sequences

Besides the simulation, it is also possible to derive initial tests on the proto-col and communication lev-els from the device descrip-tions. The protocol test in-cludes checking of the SDO protocol, for example. The communication tests do not check for correctness of the

protocol, but instead for cor-rect flow of message se-quences. For example, it is possible to test whether the configuration sequence for process data objects conforms to the sequence specified in CiA 301. The following test templates with general application can be defined for a CANopen device:

SDO download testSDO upload testHeartbeat producer testHeartbeat consumer testTransmit PDO testEMCY test

Test functions are created for each object contained in the object dictionary here. The test functions are pa-rameterized based on the data contained in the con-figuration files for the devic-es. Among other things, test sequences can be generat-ed to check the:

PDO configurationDefault valuesObject dictionaryNMT state machine, andSDO protocol

The generated tests may be executed right away in a suitable runtime environ-ment. In the framework of integration work, it is pre-cisely such tests that are used to check the delivered components. In turn, sup-pliers can generate similar test sequences to assist in development. They can im-mediately be applied to the

prototypes. Essentially, this is a way to generate test se-quences of the conformance test (CiA 310) device-specif-ically. However, the goal of the system should not be to replace the CiA confor-mance test altogether. The system should accompany the development and give developers a way to test de-vices in advance of the ac-tual tests. The final certifi-cation is only performed by CiA.

Generation template for each version

Generation templates must be created for each test, but they are applied to each de-vice to be tested. A gen-eration template that de-scribes the creation of a test for checking the object dic-tionary would appear as fol-lows:

for all objects

{

get access type

if(access == read

only){

add test function

SDO Upload

to test sequence

} // if

else if (access ==

read write){

add test function

SDO Upload

to test sequence

add test function

SDO Download

to test sequence

} // else if

.

.

}

The generated test se-quence created based on this test template contains a number of parameterized (by entry of object index, etc.) write and read rou-tines. They are processed sequentially in test execu-tion.

Iterative development process

Since iterative processes are applied throughout a device’s development, the Fig. 3: Test sequences of a CANopen system

10 CAN Newsletter 2/2008

Tool

s

7/35

49 Press Book_Seite_7-34_7-37.indd 349 Press Book_Seite_7-34_7-37.indd 3 09.02.2010 13:25:19 Uhr09.02.2010 13:25:19 Uhr

Page 240: Vector Press Book

process for generating test sequences must be repeat-able as often as needed. Changes to the device de-sign can affect the device

descriptions. The test that was originally generated would then likely fail. None-theless, it is still necessary to be able to manually ex-tend test sequences after generation, e.g. to incor-porate application-specif-ic supplements. These ex-tensions must be read back when the sequence is re-generated.

Application-related tests

The application-related be-havior of the devices can not be represented in the device descriptions. Fur-thermore, the tester does not want to have to deal with the CANopen-specific con-ceptual world and its def-initions on the application level. On this level, it is en-tirely unimportant to know which signal is mapped to which object at which po-sition. More important is in-formation about which sig-nals exist and which devic-

es receive or send them. Among other things, pre-cisely these aspects must be tested. This subject mat-ter can be explained by the

example of the CiA 447 ap-plication profile (application profile for special-purpose car add-on devices):

The standard de-fines an object “GPS date”. Mapped to this object are the signals “GPS date year”, “GPS date month” and “GPS date day”.

The CiA 447 profile, besides defining signal allo-cations in the objects, also defines the transmission type. The standard speci-fies that the object value “GPS data” is transmitted by SDO protocol. The fol-lowing information is need-ed to transmit a signal as part of a test:

Index + Sub-Index of the objectSignal lengthStart position of signal within the object

The format of today’s EDS files is unable to describe the signal allocations of ob-ject values. Accordingly, in-formation such as the signal length and start position of

Fig. 4: “GPS date” object description

7/36

49 Press Book_Seite_7-34_7-37.indd 449 Press Book_Seite_7-34_7-37.indd 4 09.02.2010 13:25:19 Uhr09.02.2010 13:25:19 Uhr

Page 241: Vector Press Book

the signal is also unsupport-ed. Even if these require-ments could be implement-ed, it is not possible to au-tomate generation of appli-cation-related test sequenc-es, since the behavior of the system is not described.

Generated test environment

Nonetheless, the developer can be supported by gener-

ation of an “interaction lay-er” in test creation. If this ex-tension can be integrated in the simulated overall sys-tem, then it is easy to cre-ate application-related test cases.

The test system con-sists of the simulated nodes that are extended to in-clude an “interaction layer”. One or more physical de-vices are tested. The simu-lated devices are stimulat-

Fig. 5: Generated test environment

kai.schmidt@ vector-informatik.de

ed via generated interface functions. Signal values are mapped to object val-ues and the CAN messag-es are sent. In the example depicted, the signal value “GPS date month” would be mapped to the relevant position in the object value (startbit 16, length 4 bit).

Parameterization of the test functions assumes that the positions and length of the signals are

known. Moreover, the trans-mission type must be con-sidered. This information is described exclusively in the standard and must be considered in test creation. Use of an “interaction lay-er” enables signal-oriented test creation. It will be pos-sible to define the function “Send_GPS_month” and generate its implementa-tion based on the CiA 447 specification, if it exists in XML format in the future. Today’s format of the speci-fication requires converting the specification to a read-able format (XML or Excel).

This conversion task can be assumed by a gen-erator. The generated func-tions contain a mapping of the signal to the object val-ue and a routine for sending the CAN messages. During test creation, the test engi-neer need not be concerned about signal positions, indi-ces or transmission types. All the test engineer is in-terested in are the signal name, sender, receiver and signal value.

The Codix 538 display by Kübler provides a CAN/

CANopen interface in or-der to display locally any user-defined value. Numer-ical values can be directly scaled using a factor or off-set from the display device. The display has a floating decimal point that can be inserted in any position. Via the CAN network encod-ers can be read out direct-ly, thanks to the Automatic Operational Mode. The dis-play is provides automat-ic bit-rate detection and up to 16 node-IDs that can be set via rotary switches. The CAN port supports base and extended frame for-mats with maximum data-rate of 1 Mbit/s. The dis-play comes equipped with a 6-digit, 8-mm high-red 7-segment LED. Each seg-ment can be directly writ-ten to, allowing not only val-

ues to be displayed but text messages also. There will always be room for the dis-play, thanks to its DIN hous-ing that measures 48 mm x 24 mm, with an installa-tion depth of just 59 mm. Reverse polarity protection likewise facilitates installa-tion. On account of its high IP65 protection rating the display can be easily used in industrial environments without the need for an ad-ditional protective housing. The company offers sever-al encoders with CANopen connectivity since many years. The Sendix absolute encoder features now an additional incremental track. Parallel to the CANopen output this encoder outputs an additional TTL compati-ble signal with 2048 puls-

es per revolution. As well as the CANopen output, the encoder is also fitted with an RS-422 interface, which outputs the signals A,/A, B,/ B. “This means it is pos-sible to implement simulta-neously both positioning via the CAN network and di-rect feedback of the speed – all in just one encoder,” said Pierre Brucker, Market-ing Director at Kübler. “This saves on the costs and in-stallation space that a sec-ond encoder would have entailed.” Using the variable PDO Mapping in the mem-ory the user can decide, which information is to be available in real-time. Func-tions, such as the transmis-sion of speed, acceleration or exiting the work area, ensure fast data availabil-

ity while reducing the load on the bus and controller. The real-time position ac-quisition of the expand-ed CANopen Sync function enables genuine time-syn-chronous position detection of several axes. Kübler is also lunching slip rings (IST-SR085 and IST-SR060) that can be used to transmit bus signals between a sta-tionary and rotating plat-form. Typical applications include cranes, rotary ta-bles, etc. The transmission between stator and rotor units takes place via slid-ing contacts (for current up to 40 A). Thanks to their ful-ly encapsulated housing (in high-grade glass-reinforced plastic), high protection rat-ing (up to IP 64) and resis-tance to vibration, these rugged products are suited to industrial use.

www.kuebler.com

Display communicates with encoder

12 CAN Newsletter 2/2008

Tool

s

7/37

49 Press Book_Seite_7-34_7-37.indd 549 Press Book_Seite_7-34_7-37.indd 5 09.02.2010 13:25:20 Uhr09.02.2010 13:25:20 Uhr

Page 242: Vector Press Book

Be fore con sid er ing tools it is es sen tial to have a han dle on t

ATZ el ek tron ik: Dr. Beck, what are the typ i cal is sues that ari-se in the de vel op ment proc ess for au to mo tive elec tron ics?Beck: First a dis tinc tion should be made be tween two sub jectar e as here. They are the en gi neer ing proc ess on the onehand, and the man age ment proc ess on the oth er.The en gi neer ing proc ess is con cerned with mas ter ing tech ni -cal com plex i ty, i.e. the in ter ac tion of elec tron ic com po nentsthat are evolv ing in to in creas ing ly com pre hen sive sys tems,e.g. driv er as sist ance sys tems, ACC, lane keep ing sys tems,etc. These sys tems of fer great chal len ges to au to mo tiveman u fac tur ers.In the con text of man age ment proc ess es the pri ma ry con -cern is with plan ning and con trol of en gi neer ing, such as inproject plan ning and track ing. How e ver, im proved com mu ni -ca tion be tween pro duc ers and sup pli ers and the chal lenge ofcon tin u al ly bring ing new pro ducts to mar ket fast er and moreef fi cient ly are al so re quire ments of the man age ment proc -ess. When one ex am ines the meth ods, proc ess es and or gan i -za tion al forms with which the au to mo tive in dus try has typ i -cal ly op er at ed, the writ ing was al ready on the wall sev er alyears ago: Man u fac tur ers and sup pli ers had to im prove theirsys tem de vel op ment ca pa bil i ties enor mous ly to even be ableto de vel op com plex net worked elec tron ic sys tems and tothere by re main com pet i tive. If you look in to large cor po ra -tions to day, you will see that ex ten sive pro grams are be ingstart ed ev ery where to im prove de vel op ment proc ess es anden hance qual i ty.

ATZ el ek tron ik: What does eAS EE con trib ute in this con text,and how are de vel op ment tools linked to it?Beck: Vec tor has set up a team that works in ten sive ly in con -sul ta tion serv i ces re lat ed to de vel op ment proc ess es. Theseare spe cial ists who to geth er with cus tom ers, i.e. OEMs andTier-1 sup pli ers, an a lyze and op ti mize their de vel op mentproc ess es. Be fore con sid er ing the tools to be used, it is nec -es sa ry to have a han dle on the proc ess lev el first – i.e. to un -der stand and doc u ment it.A tool like eAS EE can help to firm ly em bed proc ess es in theor gan i za tion in a last ing way. This pro tects in vest mentsmade in proc ess im prove ment pro jects. eAS EE sup ports alltech ni cal proc ess es in an or gan i za tion, such as con fig u ra -tion man age ment, change re quest man age ment, projectman age ment and prod uct life cy cle man age ment. Our toolhan dles all of an or gan i za tion’s da ta stor age needs. To someex tent this makes eAS EE a back bone that of fers cer tain func -tion al i ties, and en gi neer ing tools dock to this sys tem. Ex am -ples of such tools are: Doors, our Da Vin ci tool, As cet SD andMat lab Sim u link.

ATZ el ek tron ik: What does the in tel li gence look like for link -ing these use ful da ta that orig i nate from very dif fer ent sour ces?Beck: eAS EE has var i ous mod ules: En gi neer ing Da ta, Work -flows, Proc ess and Project Man age ment and Stra te gic ProjectPlan ning. This means that we al so of fer En gi neer ing-Da taMan age ment. This mod ule pro vides the nec es sa ry log ic forlink ing dif fer ent doc u ments and da ta. The doc u ments areem bed ded in a co her ent cor po rate da ta struc ture, and re la -

8/0

Vec tor Con sult ing, with its eAS EE prod uct, is of -fer ing a com plete tool en vi ron ment for man a -ging and con trol ling en gi neer ing busi ness proc -ess es. The soft ware is ca pa ble of or gan iz ing allof the proc ess es and prod uct da ta for soft wareand elec tron ic sys tems over their en tire prod uctlife cy cle. ATZ el ek tron ik mag a zine spoke withDr. Thom as Beck, CEO of Vec tor In for ma tik andVec tor Con sult ing GmbH, about de vel op mentproc ess es in de vel op ing au to mo tive elec tron icsand about the ad van ta ges of eAS EE (pro -nounced: “easy”).

Dr. Thom as Beck, CEO of Vec tor In for ma tik GmbH and Vec tor Con sult ing GmbH

50 Press Book_Seite_8-00_8-01:Press Report 1 09.02.2010 13:13 Uhr Seite 1

Page 243: Vector Press Book

sta tus of the proc ess. Aft er all, the pur pose of such a sys temis to pro duce trans par en cy. To use an ex am ple: eAS EE is likea cor set that should be sup por tive but not re strict ive.

ATZ el ek tron ik: Let’s take a re cent ex am ple like AU TO SAR:What role does eAS EE play here?Beck: AU TO SAR de fines a great deal of in for ma tion. Es sen -tial ly you must dif fer en ti ate two lev els: The base soft ware,CAN net work ing, LIN net work ing, etc. on the one hand, andabove these the so-called AU TO SAR soft ware com po nentsthat spec i fy how a func tion such as ex te ri or light ing con trolor in te ri or light ing con trol must be de scribed. It is pre cise lythis in for ma tion that must be man aged. The AU TO SAR da taback bone ac com plish es this, in this case eAS EE. By the way,one of our next de vel op ment goals is to of fer a stand ard en -vi ron ment that mir rors the AU TO SAR da ta mod el and de vel -op ment proc ess. AU TO SAR takes the com plex i ty of the de vel -op ment proc ess to a yet high er lev el, mak ing eAS EE thatmuch more ben e fi cial.

tion ships are es tab lished be tween them – ac cord ing to pre-de fined proc ess es. The ques tions ad dressed here are al waysproc ess-re lat ed. Sup ple men tal log ic is re quired for da ta thatare rel e vant to me chan i cal de sign. Such da ta are in te grat edin to the sys tem in the form of cus tom iz ing.A da ta struc ture might rep re sent a ve hi cle con fig u ra tion fora pas sen ger car or heavy truck, for ex am ple. Da ta it con tainsmight be long to the En gine Man age ment Sys tem, Gate way,or Trans mis sion Sys tem; in the spe cif ic con trol mod ule theseda ta ex tend deep er in to the soft ware, in to func tion al i ty, tothe CAN mes sage lev el or to the mod el lev el, for ex am ple aMat lab Sim u link mod el. As an anal o gy, one might pic ture awell-or ga nized draw ing cab i net con tain ing all of the el e -ments that make up the ve hi cle.

ATZ el ek tron ik: How is eAS EE im ple ment ed at your cus tom -ers?Beck: The pre req ui site for mean ing ful use of such a prod uctis that the cus tom er must have al ready de fined its proc ess esin ter nal ly. If that is not the case, the cus tom er can not evenstart to use eAS EE. In in tro duc ing the prod uct to a com pa nyit is un im por tant wheth er we per form the serv ice or an oth ercon sul ta tion firm han dles it. In prin ci ple, po ten tial col lab o -ra tive part ners not on ly in clude large cor po ra tions like IBM,but al so small com pa nies who are spe cial ists in this ar ea.Once proc ess es have been clear ly de fined, the prod uct mustbe “cus tom ized” to the proc ess es. Vec tor al ready of fers pre -pared so lu tions here that can be adapt ed to a cus tom er’sneeds.

ATZ el ek tron ik: Some times it is not so sim ple to in tro ducenew proc ess es. What has your ex pe ri ence been in this ar ea?Beck: In pro jects that we per formed re cent ly, man age mentstood clear ly be hind proc ess de vel op ment. The bot tom lineis that en gi neers too are up set when they can not find doc u -ments or when co op er a tive work ef forts do not suc ceed. Thecli mate for proc ess es has been trans formed in re cent yearsbased on this fact. Good or gan i za tion al de vel op ment meansad dress ing both sides. It must be a Win-Win sit u a tion forman age ment and en gi neers. To cite an oth er ex am ple: At alltimes the en gi neer has the op por tu ni ty to ob serve in eAS EE,the work flow proc ess has tak en to date as well as the cur rent

8/1

n the proc ess es first

Au thor:

Dr. Thom as Beck finished his studies on Electrical Engineering in1986; doc tor ate de gree in 1992; be gan busi ness ca reer in var i ouspo si tions at Bosch and ETAS; 1997–2000 CEO of the ETAS Group; andsince 2001 part ner and CEO of Vec tor In for ma tik GmbH and Vec torCon sult ing GmbH

50 Press Book_Seite_8-00_8-01:Press Report 1 09.02.2010 13:13 Uhr Seite 2

Page 244: Vector Press Book

8/2

1 Mo ti va tion and GoalsThe de vel op ment of ve hi cle func tions, ECUs and ECU net works is be -

com ing more and more com plex. It is be com ing in creas ing ly im por -

tant for MAN Nutz fahrzeuge AG to be able to mas ter this com plex i ty

in to the fu ture. The pri ma ry ob jec tive is to in crease de vel op ment

ef fi cien cy while fur ther im prov ing prod uct qual i ty.

2 Ba sic IdeasTwo fac tors led to the de vel op ment of the MAN Com mon En gi neer -

ing Da ta Back bone: First, it was clear to man age ment very ear ly on

that qual i ty could not sim ply be achieved aft er wards by an ex ten -

sive test ing proc ess. Rath er a uni ver sal, well lived-out de vel op ment

proc ess is nec es sa ry, which en com pass es all ar e as of de vel op ment.

Sec ond, man age ment at MAN fa vored an in te grat ed da ta base so lu -

tion that saves all da ta of the de vel op ment proc ess in a me ta mod el

(sin gle source) [Fig ure 1] and there by en a bles very ef fi cient da ta

us age and da ta uni ver sal i ty. The abil i ty to set re la tion ships be -

tween da ta fur ther in creas es ef fi cien cy. This da ta base so lu tion is

re ferred to at MAN as the Com mon En gi neer ing Da ta Back bone.

3 Im ple men ta tionThe com pa ny was look ing for a tech ni cal plat form that lets us ers

con cen trate on the ac tu al con tents: The da ta struc tures and func -

tion al i ties. The sys tem al ready pro vides ba sic mech a nisms such as

us er ad min is tra tion, ver sion man age ment and cli ent-serv er ar chi -

tec tures. That is why the choice was made to go with the eAS EE Tool

Suite from Vec tor.

3.1 eAS EE as Tech nol o gy Plat formeAS EE is a proc ess tool whose core con sists of a hi er arch i cal con fig -

u ra tion man age ment sys tem for any de sired da ta. This ba sic sys tem

in cludes:

> Func tions for ver sion ing and var i ant for ma tion

> A us er-con fig ur a ble da ta mod el for us er da ta and me ta da ta

> A work flow en gine

> Mul ti-site op er a tion, and

> A dif fer en ti at ed roles and rights con cept.

Over laid on this ba sic sys tem are mod ules spe cif i cal ly de signed for

var i ous proc ess ar e as. These mod ules cov er the ma jor i ty of key

proc ess func tion al i ties that are need ed in the au to mo tive in dus try

[Fig ure 2]. Pro gram ming in ter fa ces are pro vid ed to al low for in di -

vid u al ex ten sions. Be sides be ing used at MAN, eAS EE is al so used at

Bosch, Gen er al Mo tors, Daim ler, ZF, Vol vo, Porsche, VW, Audi and

Get rag.

3.2 The MAN Com mon En gi neer ing Da ta Back boneTo day, the MAN Com mon En gi neer ing Da ta Back bone con sists of

eight do mains. Its foun da tion is an Or a cle da ta base up on which the

eAS EE Tool Suite is placed [Fig ure 3].

The proc ess mod el dis tin guish es be tween the ac tu al de vel op ment

proc ess (“Do it”) [Fig ure 1] and the man age ment proc ess (“Con trol

it”) [Fig ure 4]. Anal o gous ly, in the MAN Com mon En gi neer ing Da ta

At MAN Nutz fahrzeuge AG an in te grat ed ap proachwas ap plied to man a ging all en gi neer ing da tagen er at ed in the E/E de vel op ment proc ess and itssub proc ess es. The goal is to fur ther im prove theef fi cien cy and qual i ty of de vel op ment, de spitethe grow ing com plex i ty of elec tron ic sys tems.MAN Nutz fahrzeuge AG de vel oped and in tro ducedan in te grat ed de vel op ment da ta base for this pur -pose, which is based on the eAS EE Tool Suite fromthe Vec tor com pa ny: The MAN Com mon En gi neer ing Da ta Back bone.

Fig ure 1:Sin gle-source prin ci ple for the de vel op ment proc ess

Tool-sup port ed Da ta and Proc ess Man age ment at MAN Nutz fahrzeuge AG

51 Press Book_Seite_8-02_8-05:Press Report 3 09.02.2010 13:06 Uhr Seite 1

Page 245: Vector Press Book

8/3

> Sig nals (e.g. CAN)

> Ve hi cle func tions

> Func tions

> Soft ware ar chi tec tures.

In ad di tion, a clas sic re quire ments man age ment sys tem is rep re -

sent ed.

Based on these da ta struc tures, the FDM of fers many func tion al i ties

for the dai ly tasks of the en gi neer. These in clude:

> Var i ous in ter fa ces to ex pert tools, e.g. Mat lab/Sim u link/Tar get -

Link as a de vel op ment en vi ron ment and XMet aL as an XML-based

au thor ing en vi ron ment for de tailed spec i fi ca tions [Fig ure 5]

> The op tion of a vir tu al ve hi cle de sign/check,

> Sig nal path anal y sis

> Abil i ty to gen er ate DBC files to de scribe bus sys tems for anal y sis

and test tools such as Vec tor’s CAN a ly zer and CA Noe.

Back bone there are “Do it” da ta do mains (FDM, TDM, CDM, etc.),

and a “Con trol it” project man age ment do main (PPM) [Fig ure 3].

The two ar e as are in ter linked across all do mains. Project sched ules

(Gantt Charts), for ex am ple, are au to mat i cal ly up dat ed based on

the states of the el e ments in the da ta do mains. Thus, the project

lead er no longer needs to per form main te nance work on the states

of work pack ets.

Func tion Da ta Man age ment – FDMThe in di vid u al da ta do mains are ori ent ed di rect ly to ward the pro cess.

Func tion Da ta Man age ment (FDM), for ex am ple, rep re sents the left

side of the V-Mod el. This do main con tains a com plete me ta mod el

used to de scribe all of the da ta of an elec tron ic struc ture, in clud ing:

> Ve hi cle con fig u ra tions

> ECUs

> Hard ware (con nect ors/pins)

Fig ure 2: The eAS EE proc ess tool suite

Fig ure 3: MAN Com mon En gi neer ing Da ta Back bone

51 Press Book_Seite_8-02_8-05:Press Report 3 09.02.2010 13:06 Uhr Seite 2

Page 246: Vector Press Book

8/4

Test Da ta Man age ment – TDMThe right side of the V-Mod el is cov ered ed by Test Da ta Man age ment

(TDM). In this do main it is pos si ble to map en tire test pro jects.

Among oth er things, TDM man a ges the test spec i fi ca tions, test ex e -

cu tion in for ma tion for each test, test re sults, test en vi ron ments

and test meth ods. Test da ta in the TDM are di rect ly linked to de vel -

op ment da ta in the FDM. Since the sys tem is used cross-de part men -

tal and over all test lev els, it is pos si ble and very easy to draw con-

clu sions about test cov er age – from com po nent test ing to val i da -

tion test ing.

Fault and Re quire ment Man age ment – FRMFault and Re quire ment Man age ment (FRM) con tains a com plete

change man age ment. This sys tem can be used to in put is sues in to

the de vel op ment proc ess. The in di vid u al is sues may be clas si fied as

er rors or new re quire ments.

Er rors are linked to both the test cy cle in which the er ror was found,

in the TDM, as well as to the func tion in which the er ror oc curred.

This makes it very easy for func tion de vel op ers to look in the FDM to

see which is sues are still open for them. The test en gi neer, in turn,

sees very quick ly which er rors were cor rect ed in a new func tion ver -

sion, and what form of post-test ing is nec es sa ry.

Cal i bra tion Da ta Man age ment – CDMCal i bra tion Da ta Man age ment (CDM) maps the da ta of the cal i bra -

tion proc ess. Based on the da ta of the FDM, in cal i bra tion pro jects

this sys tem makes it pos si ble to man age da ta rec ords of ECUs via

the AS AM MCD-2MC file. Da ta rec ords from es tab lished cal i bra tion

tools such as CA Na pe, IN CA or Cald esk – which have an AS AM

MCD2MC in ter face and which sup port the CDF or DCM ex change for -

mat – may be read di rect ly in to the CDM. Com plet ed and re leased

pa ram e ter sets may be ref er enced in the FDM as in i tial da ta sets.

Serv ice Da ta Man age ment – SDMServ ice Da ta Man age ment (SDM) makes it pos si ble to pro vide serv ice-

rel e vant da ta to the serv ice ar ea from the de vel op ment ar ea. Al so rep -

re sent ed in this sys tem is a work flow mech a nism that tracks the path

from the re leased ECU to its pro duc tion and use in se ries ve hi cles.

Trace a bil i tyTo day, al most all da ta gen er at ed in the de vel op ment proc ess is

saved in a me ta mod el in the MAN Com mon En gi neer ing Da ta Back -

bone. In te grat ed da ta stor age in a da ta base en a bles near ly per fect

trace a bil i ty of the da ta. For ex am ple, start ing from a test cy cle it is

pos si ble to de ter mine which er ror was found with this test cy cle

and which re quire ment the test cy cle cov ered.

An oth er po ten tial use is to start with a CAN sig nal and have the sys -

tem in di cate which func tions in an elec tron ic struc ture util ize this

sig nal. For ex am ple, it is pos si ble to de duce wheth er a cer tain sen -

sor can be omit ted in the sys tem.

3.3 Sta tus of the MAN Com mon En gi neer ing Da ta Back boneThe MAN Com mon En gi neer ing Da ta Back bone has been in pro duc -

tive op er a tion for sev er al years and is cur rent ly util ized by about

one hun dred de vel op ers. To day it con sists of the eight do mains

Fig ure 5: FDM in ter face to Mat lab/Sim u link

Fig ure 4: Plan ning and con trol of the de vel op ment proc ess

51 Press Book_Seite_8-02_8-05:Press Report 3 09.02.2010 13:06 Uhr Seite 3

Page 247: Vector Press Book

8/5

TOOL-SUPPORTED DATA AND PROCESS MANAGEMENT AT MAN NUTZFAHRZEUGE AG

de scribed and var i ous in ter fa ces [Fig ure 6]. Since de vel op ers are

ac tive ly sup port ed by the back bone in their dai ly work, from the

first re quire ment to the last test, the Com mon En gi neer ing Da ta

Back bone is very well ac cept ed by de vel op ers. It has been shown

that it is very im por tant for de vel op ers to work with in the sys tem

from the very first minute, and to sin gle-source their da ta here.

This elim i nates an ad di tion al main te nance ef fort that would oth er -

wise be per ceived as rath er dis rupt ive.

4 Util i tyAft er about three years of pro duc tive use by the Com mon En gi neer -

ing Da ta Back bone, the in i tial ob jec tives were re al ized. Ef fi cien cy

gains were achieved due to re dun dan cy-free da ta in put and da ta

stor age and due to the many dif fer ent op tions for sup ply ing in for -

ma tion and pre par ing da ta. Pre vi ous ly, an en gi neer would have to

work through doz ens of doc u ments to pre dict the con se quen ces of

trans fer ring a cer tain func tion from ECU A to ECU B. To day, it takes

just a few mouse clicks and the rel e vant in for ma tion is avail a ble at

the lat est re vi sion lev el. An oth er ad van tage is re us a bil i ty of en gi -

neer ing ar ti facts and da ta, which is made pos si ble by Var i ant Man -

age ment. Oth er pos i tive ef fects are the con sid er a bly im proved

trans par en cy for en gi neers in volved in the de vel op ment proc ess

and the abil i ty to es tab lish role-spe cif ic views for one and the same

da ta con tent. Thus, the MAN Com mon En gi neer ing Da ta Back bone

of fers very spe cif ic views of de vel op ment sta tus, e.g. for the pro-

ject lead er, sys tem ar chi tect, func tion de vel op er, in te gra tion man -

ager and test en gi neer.

5 The Road AheadIn im ple ment ing the MAN Com mon En gi neer ing Da ta Back bone,

spe cial at ten tion was giv en to ex change for mats to en sure that

Fig ure 6: FDM in ter fa ces to au thor ing toolsand ex ter nal da ta bas es

Ste fan Teuch ert (Grad u ate En gi neer) man a ges the Soft wareDe vel op ment and Ba sic Tech nol o gies de part -ment at MAN Nutz fahrzeuge AG

Ge org Zim mer mann (Grad u ate En gi neer) man a ges the “Prod uctLine Proc ess Tools” de part ment at Vec tor In for ma tik GmbH

es tab lished stand ards such as MSRSW and AS AM were used. To day,

this is very ben e fi cial es pe cial ly at sup pli er in ter fa ces. There fore,

MAN is fol low ing the de vel op ment of the AU TO SAR stand ard very

close ly. If the ad van ta ges of the stand ard ap pear suf fi cient ly great,

the MAN Com mon En gi neer ing Da ta Back bone would be adapt ed to

the AU TO SAR stand ard and brought to a lev el of AU TO SAR com pat i -

bil i ty. The in ter ests of MAN and Vec tor over lap here too: The Stutt -

gart-based tool pro duc er has set the goal of de vel op ing an eAS EE

mod ule for AU TO SAR-com pat i ble sys tem da ta man age ment, which

com bines the ad van ta ges of the stand ard with key func tion al i ties

of the Com mon En gi neer ing Da ta Back bone.

51 Press Book_Seite_8-02_8-05:Press Report 3 09.02.2010 13:07 Uhr Seite 4

Page 248: Vector Press Book

From Pi lot Stud ies to Pro duc tion De vel op ment

To be suc cess ful as a glo bal ly-ac tive au to mo tive sup pli er in a mar -

ket char ac ter ized by in no va tion, com pe ti tion and cost pres sure, it

is nec es sa ry to have pro ducts that meet the strin gent tech ni cal and

eco nom i cal re quire ments of au to mo tive OEMs.

Based on its com pre hen sive ex pert ise, con tin u ous ly op ti mized pro -

c ess es and proc ess tools, ZF is able to po si tion its pro ducts for pow er -

train and chas sis sys tems very suc cess ful ly in the mar ket. In the

pow er train ar ea, ZF sup plies trans mis sions for pas sen ger cars, com -

mer cial ve hi cles, bus es, rail ve hi cles, ships and hel i cop ters. These

ar e as are marked by a very high lev el of mod el di ver si ty. This di ver si ty

in mod els and var i ants can be achieved by ve hi cle-spe cif ic pa ram e -

ter i za tion (cal i bra tion) of the trans mis sion. For ex am ple, ZF sup plies

the 6HP26 6-speed au to mat ic trans mis sion, which en a bles ef fi cient

gear shift ing in dif fer ent ve hi cles with ve hi cle-spe cif ic torque curves

ran ging from 300Nm to 800Nm; this is ac com plished by in di vid u al

pa ram e ter i za tion (Fig ure 1). Short shift times, smooth gear shifts,

re duced fu el con sump tion and low emis sions are oth er ob jec tives

that can be met by op ti mal ly adapt ing pa ram eters to the ve hi cle.

Re quire ments of ZF Fried richs haf en AGEven the first mi cro con trol ler-based trans mis sion con trol elec tron -

ics in clud ed pa ram e ters for adapt ing the elec tron ics to the en vi ron -

ment (e.g. trans mis sion hard ware, ve hi cle). Start ing with just a few

cal i bra tion pa ram e ters, the num ber of pa ram e ters con tin u al ly rose

in re sponse to in creas ing func tion al i ty. A grow ing mod el di ver si ty

in trans mis sion and pow er train sys tems – as well as a ris ing num ber

of par al lel pro jects – re quired func tions for cen tral, ef fi cient and

proc ess-con form ant man age ment of the cal i bra tion da ta. The ex ist -

ing sys tem for da ta man age ment de vel oped in-house at ZF had

been stretched to its lim its by the com plex i ty of pro jects.

Ob jec tives for the new cal i bra tion da ta man age ment sys tem were:

> Uni form and cor po rate-wide sys tem for cen tral man age ment of

all ZF drive and chas sis pro jects

> In tro duc tion of a mod ern, mar ket-es tab lished En gi neer ing Da ta

Man age ment sys tem (EDM sys tem) with a da ta base ori en ta tion

> Sup port and stand ard i za tion of de fined cal i bra tion proc ess es

> In te grat ed check ing and test rou tines for qual i ty as sur ance

> Mass op er a tions to im prove ef fi cien cy

> Flex i bil i ty of da ta stor age – from sim ple ad dress ing via var i ant-

en cod ed groups for mul ti ple sys tems or ve hi cles to com plex da ta

stor age for many ve hi cles

8/6

To sound ly man age growth in the num -ber of com plex trans mis sion cal i bra tionpro jects and their da ta at ZF Fried richs -haf en AG, the com pa ny need ed to in tro -duce a new cal i bra tion da ta man age -ment sys tem. De cid ing fac tors for in tro -duc ing the cal i bra tion da ta man age mentsys tem eAS EE.cdm from Vec tor were thetool’s high func tion al i ty, flex i bil i ty andpo ten tial. An oth er cru cial fac tor was thecom pa nies’ de vel op ment part ner shipover many years with the goal of joint lymeet ing ZF tar gets for qual i ty as sur anceand im proved ef fi cien cy.

Ef fi cien cy and Qual i ty in cal i brat ing Trans mis sions

Fig ure 1: The 6HP26 trans mis sion from ZF

52 Press Book_Seite_8-06_8-09:Press Report 4 09.02.2010 13:12 Uhr Seite 1

Page 249: Vector Press Book

Cal i bra tion-spe cif ic func tions sup port project lead ers, da ta in te -

gra tors and cal i bra tors in all phas es of a project. From project def i -

ni tion to da ta prep a ra tion to re lease of the in te grat ed over all

pa ram e ter sets, us ers ben e fit from cal i bra tion da ta man age ment

sys tem func tion al i ty:

Project lead ers at ZF are able to clear ly struc ture com plex cal i bra -

tion pro jects that have many var i ants by prop er ty-sup port ed var i -

ants man age ment. Da ta set var i ants are formed by com bi na tions of

var i ant-rel e vant at trib utes. Var i ant cri te ria are al so util ized as

fil ter cri te ria in re leas ing pa ram e ters (Fig ure 3).

ECU sup pli ers of ten per form cal i bra tion pro jects joint ly with the

OEM, and this re quires flex i ble han dling of da ta. Cal i bra tors at ZF

proc ess and man age ECU pa ram e ters – ei ther pa ram e ter-ori ent ed,

func tion-ori ent ed, com po nent-ori ent ed or var i ant-cod ed, de pend -

ing on the spe cif ic cal i bra tion proc ess. The CA Na pe and IN CA cal i -

bra tion tools that are used gen er ate mar ket-rel e vant da ta for mats:

both phys i cal char ac ter is tic da ta for mats (CDF, CSV, DCM, Pa Co,

PAR) and pro gram for mats (In tel Hex, Mo tor o la-S) are sup port ed.

The cal i bra tion ar ea at ZF im ple ments the graph ic Pa ram e ter Ed i tor

for check ing, ad just ment and da ta in te gra tion (Fig ure 4). It of fers

ex ten sive op tions for vis u al i za tion (ta ble-for mat, 2D and 3D) and

off line ed it ing of ECU pro grams and pa ram e ters. Chan ges are saved

di rect ly in the eAS EE da ta back bone.

Da ta in te gra tors make ex ten sive use of al go rithms to im prove da ta

con sist en cy and in teg ri ty by check ing for com plete ness, un am bi gu -

Vec tor’s eAS EE.cdm So lu tion To ful fill the re quire ments out lined by ZF, a tool was need ed that

in te grates the func tions of EDM sys tems, proc ess tools and cal i bra -

tion tools in a com pre hen sive sys tem so lu tion. In de cid ing on

eAS EE.cdm from Vec tor, ZF chose a ma ture and mar ket-es tab lished

sys tem.

The eAS EE.cdm cal i bra tion da ta man age ment sys tem con sists of a

da ta man age ment sys tem for en gi neer ing ar ti facts and a graph ic

Pa ram e ter Ed i tor; it al so con tains cal i bra tion-spe cif ic func tions and

au to mat ed se quen ces for man a ging all pro gram and da ta sets oc -

cur ring in the cal i bra tion proc ess. As a mod u lar com po nent of the

eAS EE tool suite, it is al so easy to in te grate it with oth er proc ess

do mains (Fig ure 2).

Func tions of the eAS EE base sys tem in clude:

> Func tions for ver sion ing, and for form ing var i ants and

con fig u ra tions

> Flex i bly con fig ur a ble da ta mod el for pro duc tive da ta and the

me ta-da ta that de scribes it

> A work flow en gine for proc ess-con form ant flow con trol

> Mul ti-site op er a tion for co op er a tion be tween dis trib ut ed

work teams

> A dif fer en ti at ed roles and rights con cept

Flex i ble con fig ur a bil i ty of the da ta mod el makes it easy to im ple -

ment ap pli ca tion-spe cif ic ex ten sions – eAS EE.cdm be comes the da -

ta back bone of cal i bra tion proc ess es.

8/7

Fig ure 2:The eAS EE proc ess tool suite

52 Press Book_Seite_8-06_8-09:Press Report 4 09.02.2010 13:12 Uhr Seite 2

Page 250: Vector Press Book

i ty and phys i cal lim its. Project lead ers at ZF ap pre ci ate the add ed

se cu ri ty of fered by la bel-based rights man age ment, which pre vents

par al lel re leas es of over lap ping da ta. Oth er im por tant func tions

have been in te grat ed in the cal i bra tion da ta man age ment sys tem,

such as check sum gen er a tion and the abil i ty to in ter face to sig na -

ture tools for pro tect ing ECU soft ware.

In tro duc tion of the Sys temThe de ci sion to im ple ment eAS EE.cdm as a cor po rate-wide so lu tion

at ZF was made in 2003. Be fore roll-out in the in di vid u al busi ness

ar e as, eAS EE.cdm was first in tro duced and eval u at ed in two pi lot

pro jects. Aft er suc cess ful ly com plet ing the pi lot phase, the sys tem

was in tro duced to dai ly busi ness op er a tions in 2004. The first pro -

duc tion pro jects were the ECO MAT (au to mat ic trans mis sion for city

bus es) and AS TRON IC (au to mat ic trans mis sion for trucks and bus es)

pro jects. To day, ap prox. 150 cal i bra tion en gi neers man age project

and cal i bra tion da ta for 20 pro jects in dif fer ent do mains. This en a -

bles cus tom er-spe cif ic sep a ra tion of project da ta.

Im ple men ta tion of ZF re quire ments was based on a mul ti-year de -

vel op ment part ner ship. Close co op er a tion made it pos si ble to meet

tar gets in a time ly way. The fo cus in im ple ment ing re quire ments

was on gen er al us a bil i ty of the joint ly de vel oped func tions.

Util i tyPro duc tion cal i bra tion pro jects at ZF are per formed us ing cal i bra -

tion proc ess es that are de fined ar ea-wide. The proc ess es are struc -

tured so that many proc ess steps can be run in par al lel and ex e cut -

ed by an au to mat ed tool. All as pects of this cal i bra tion proc ess at

ZF are ful ly sup port ed by eAS EE.cdm. It en sures proc ess-con form -

ant ex e cu tion of cal i bra tion pro jects in prac tice, and it sup ports of

cal i bra tors, de vel op ers and project lead ers.

In their dai ly work, us ers ben e fit from the fol low ing func tion al i ties:

> Im proved co op er a tion of cal i bra tion teams due to uni form and

cor po rate-wide sys tem

> Da ta freeze time is re duced from one week to one day by

au to mat ed check ing and safe guard ing func tions

> Re duced man u al ef fort by au to mat ed gen er a tion of the da ta

ex change con tain ers

> Re pro duc i bil i ty of da ta re vi sion lev els by au to mat ic stor age of

test and sig na ture con fig u ra tions

> Ef fect ive var i ants man age ment re du ces num ber of time-wast ing

and er ror-prone ac tions

> Col li sion-free da ta in te gra tion by la bel-based rights

man age ment

> Full trace a bil i ty of the cal i bra tion proc ess by thor ough

ver sion ing of all rel e vant da ta and pro to cols

> Re us a bil i ty of cal i bra tion da ta by com po nent li brary

8/8

Fig ure 3: Prop er ty sup port ed var i ants man age ment

52 Press Book_Seite_8-06_8-09:Press Report 4 09.02.2010 13:12 Uhr Seite 3

Page 251: Vector Press Book

FROM PI LOT STUD IES TO PRO DUC TION DE VEL OP MENT

8/9

Sum ma ryThe eAS EE.cdm cal i bra tion da ta man age ment sys tem has been

in tro duced cor po rate-wide at ZF, fa cil i tat ing ef fi cient, proc ess-con -

form ant da ta man age ment while en sur ing high da ta qual i ty.

Be sides be ing used to sup port the busi ness op er a tions, the tool

al so serves as an im por tant foun da tion in con duct ing (SPICE)

as sess ments of ZF busi ness proc ess es in soft ware de vel op ment and

cal i bra tion.

All of the ob jec tives ZF sought to achieve were ful ly at tained.

Sig nif i cant in creas es in ef fi cien cy of up to 90% were at tained in

safe guard ing and sign ing-off da ta sets. Over all, eAS EE.cdm is mak -

ing an im por tant con tri bu tion to ward re duc ing costs in cal i bra tion.

Rain er Röhrle stud ied Phys i cal Tech nol o gy and Com put erEn gi neer ing and has been em ployed at ZFsince 1997. He is re spon si ble for tool de vel -op ment in the Elec tron ics/Soft ware ar ea.Since 2003 he has been project lead er for thecor po rate-wide in tro duc tion of eAS EE.cdm.

Chri stoph Hel ler stud ied Elec tri cal En gi neer ing at the Uni ver -si ty of Stutt gart. He works at Vec tor In for ma -tik GmbH as Busi ness De vel op ment Man a gerin the Proc ess Tools prod uct line ar ea.

Fig ure 4:Pa ram e ter ed i tor

52 Press Book_Seite_8-06_8-09:Press Report 4 09.02.2010 13:12 Uhr Seite 4

Page 252: Vector Press Book

Your Con tact

www.vec tor.com

Ger ma ny and all coun tries not named below

Vec tor Infor ma tik GmbHVec tor Con sult ing Serv i ces GmbHInger sheim er Str. 24 70499 Stutt gartGER MA NYTel.: +49 711 80670-0Fax: +49 711 8067-111

France, Bel gi um, Lux em bourg

Vec tor France 168, Bou le vard Cam él in at92240 Mal ak offFRANCETel.: +33 1 4231 4000Fax: +33 1 4231 4009

Swed en, Den mark, Nor way, Fin land, Ice land

Vec Scan ABTheres Svens sons Gata 941755 Göte borgSWED ENTel.: +46 31 764 7600 Fax: +46 31 764 7619

Unit ed King dom, Ire land

Vec tor GB Lim it edRho di um, Cen tral Bou le vardBlythe Val ley ParkSol i hull, Bir ming hamWest Mid lands, B90 8AS UNIT ED KING DOMTel.: +44 121 50681-50Fax: +44 121 50681-69

Chi na

Vec tor Infor ma tik GmbHShang hai Rep re sent a tive OfficeSuite 605, Tow er C,Ever bright Con ven tion Cen terNo. 70 Cao bao Road, Xuhui Dis trictShang hai 200235P.R. CHI NATel.: +86 21 6432 53530Fax: +86 21 6432 5308

USA, Cana da, Mex i co

Vec tor CAN tech, Inc.Suite 55039500 Orchard Hill Place Novi, Mi 48375USATel.: +1 248 449 9290Fax: +1 248 449 9704

Japan

Vec tor Japan Co., Ltd.Sea fort Square Cen ter Bld. 18F2-3-12 Higa shi-shin a gawa,Shin a gaw a-kuTok yo 140-0002 JAPANTel.: +81 3 5769 7800Fax: +81 3 5769 6975

Korea

Vec tor Korea IT Inc.1406 Mar io Tow er222-12 Guro-dong, Guro-guSeoul 152-848REP. OF SOUTH KOREATel.: +82 2 8070 600Fax: +82 2 8070 601

India

Vec tor Infor ma tik India Prv. Ltd.4/1/1/1, 3rd floor, Sutar IconSus RoadPash anPune 411021INDIATel.: +91 20 2587 2023Fax: +91 20 2587 2025

Press Book_Rueckseite:Press Book_Ru ̈ckseite 09.02.2010 13:11 Uhr Seite 3