vector press book
DESCRIPTION
Selection of articles published by Vector and covering topics like FlexRay, AUTOSAR, ECU Testing etc.TRANSCRIPT
Press Book1st Edition
Press Book_Einleitungsseiten:Einleitungsseiten 09.02.2010 14:27 Uhr Seite 1
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1/17
03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 6
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1/49
10 Press Book_Seite_1-46_1-49:Press Report 1 09.02.2010 13:12 Uhr Seite 4
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
3/23
24 Press Book_Seite_3-20_3-23:Press Report 4 09.02.2010 13:14 Uhr Seite 4
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
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
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
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
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.
3/28
26 Press Book_Seite_3-28_3-29:Press Report 2 09.02.2010 13:04 Uhr Seite 1
3/29
26 Press Book_Seite_3-28_3-29:Press Report 2 09.02.2010 13:04 Uhr Seite 2
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
6/13
38 Press Book_Seite_6-10_6-13:Press Report 2 09.02.2010 13:10 Uhr Seite 4
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
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
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
6/17
39 Press Book_Seite_6-14_6-17:Press Report 4 09.02.2010 13:10 Uhr Seite 4
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
7/13
43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/13
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
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
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
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
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
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
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
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
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
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
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
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
7/25
46 Press Book_Seite_7-22_7-25:Press Report 4 09.02.2010 13:13 Uhr Seite 4
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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