Press Book 1 st Edition
Date: February February 2010 · Respo Responn si sible ble for the contents: contents: Vector Vector Informa Informatik tik GmbH, Stutt gart, gart, Germa Germany ny All mentioned mentioned product product names are either regis registered tered or unregis unregistered tered trademarks trademarks of their respective respective owners. owners. The constant constant worldwide worldwide avail abil ity of all products pro ducts or servi services is not warrant war rant ed. ed. No informa infor mation tion contained contained in this cat alog may be reproduced repro duced without without expressed permis per mission, sion, in writ ing, ing, from Vector Vector Informa Informatik tik GmbH. Errors and omissions omissions except ed. ed. Illustra Illus tration tion & Design: SATZTEAM SATZTEAM Fotosatz Fotosatz & Neue Medien GmbH, Eberdin Eberd ingen, gen, Germa Germany ny
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 f ind this book both useful and informative.
En joy reading. reading. Sincere Sin cerely, ly,
Dr. Thomas Thomas Beck
Presiident Pres
Contents Serial Bus Systems
Serial Bus Systems in the Automobile: Introduction Motivation, advantages, tasks and architecture of serial bus systems in the automobile
1/0
Serial Bus Systems Systems – CAN
Serial Bus Systems in the Automobile: CAN Reliable data exchange in the automobile with C AN
1/6
Serial Bus Systems Systems – LIN
Serial Bus Systems in the Automobile: LIN Simple and cost-effective data exchange in the automobile with LIN
1/12
Network Development across LIN Bus Systems Tools for efficient network design and conformance testing
1/18
Assuring the Quality of LIN ECUs Current and future strategies for LIN Master conformance tests
1/22
Serial Bus Systems in the Automobile: FlexRay FlexRay for data exchange in highly critical safety applications
1/26
The Optimal Operating System for FlexRay-Based Applications
1/32
Embedded Software for FlexRay Systems Special aspects and benefits of implementing modularized software
1/38
FlexRay becomes daily Routine Analyzing, simulating, and testing FlexRay ECUs and networks using C ANoe.FlexRay
1/42
Case Study: Bertrandt
1/45
FlexRay Sets the Pace Real-time simulation of FlexRay systems
1/46
Efficient Access to the FlexRay Bus High-performance FlexRay hardware for analysis and simulation
1/50
AUTOSAR PDUs Conquer FlexRay Audi benefits from C ANoe.FlexRay in developing FlexRay networks with PDU communication communication
1/54
Beyond FlexRay Requirements on a modern development environment
1/58
Serial Bus Systems Systems – MOST
Serial Bus Systems in the Automobile: MOST MOST for transmission of multimedia data
1/62
ECU Testing
Efficient Testing in Automotive Electronics One test environment from HIL simulation to diagnostics
2/0
Reliable Engineering Testing on a Wiper Motor Test Bench Time-synchronous recording and evaluation of bus messages and physical parameters
2/8
Case Study: Nippon Seiki Co., Ltd.
2/13
Comprehensive ECU Tests with Fault Simulation Fault simulation capability is needed needed in early test phases for ef ficient functional tests
2/14
Semi-Synthetic Regression Tests with Real-World Data Reducing time and hardware effort in software evaluations
2/20
Model-Based Testing for Better Quality Advantages of test case generators in model-based development processes
2/24
Efficient Airbag ECU Tests Increase efficiency by automated tests during development
2/28
Vehicle Diagnostics - The whole Story Efficiency gains by standardization and the use of tool-supported processes
3/0
Automatic Validation of Diagnostic Services by Use of a Diagnostic Integration and Validation Assistant
3/8
A Source Code Generator Approach to Implementing Diagnostics in Vehicle ECUs
3/16
ECU Software for Dry Dual Clutch has Str ingent Requirements Integrated diagnostic and flash solution with script control
3/20
Flexible Flash Solution for every Job Open standards enable use of generic tool chains
3/24
Flash Programming via CAN requires Supplier’s Flexibility Satisfying strict requirements of Vehicle OEMs
3/28
Serial Bus Systems Systems – FlexR FlexRay ay
Vehicle Diagnostics
ECU Calibration
Use of XCP on FlexRay at BMW
4/0
XCP-on-FlexRay at Audi XCP-on-FlexRay AUTOSAR-compatible AUTOSAR-com patible XCP software modules for FlexRay ECUs
4/4
XCP at the Focal Point of Measurement and Calibration Applications
4/10
Quantum Leap in Microcontroller Measurement Technology Innovative ECU measurement concept for maximum data rates with minimal effects on e xecution time
4/16
Efficient Analysis of Model Behavior in ECU Function Development Visualize and parameterize Simulink models easily and efficiently
4/20
Accelerated Turbocharger Turbocharger Development with CANape Efficiently developing control concepts with a cost-effective rapid prototyping solution
4/24
Optimizing Driver Assistance Systems Verification of object recognition algorithms by driver assistance systems
4/28
Trends in Embedded Development Requirements and future concepts in hardware, software and tools
5/0
Timing, Memory Protection and Error Detection in OSEK Systems Requirements on a real-time and multitasking operating system
5/4
Current Challenges in Automotive Networking Reusability of software modules at Volkswagen and Bosch
6/0
The Universal Gateway ECU Flexible post-build configuration of AUTOSAR gateways
6/4
Early Migration creates Opportunitites for Innovations Mix of individual sof tware and AUTOSAR components in vehicle electronics
6/10
AUTOSAR on its Way to Production
6/14
AUTOSAR: New Paths to ECU Software – Part 1 Iterative collaboration between OEM, TIER1 and software supplier
6/18
AUTOSAR: New Paths to ECU Software – Part 2 AUTOSAR in practice practice – Life cycle of AUTOSAR ECU software
6/24
Networking Heavy-Duty Vehicles Based on SAE J1939 From parameter group to plug-and-play application
7/0
CAN and J1939 under Extreme Duty Conditions Vehicle electronics guarantees functionality in cold, ice and snow
7/6
Current Trends in Network Development for Heavy-Duty Vehicles Factors of success in electronic development
7/14
Open Networks - ISOBUS
Automatic Interoperability Tests for ISO11783 ISO11783 Systems Universal test solution assures compatibility
7/18
Open Networks - IP
Wireless Analysis in a Multi-Protocol CAN Environment
7/22
Moving Communication Wireless analysis of in-vehicle networks
7/26
Prototyping and Testing CANopen Systems Reaching goals rapidly with minimal effort
7/30
Automatic Testing of CANopen Devices
7/34
Before considering Tools it is easy to have a Handle on the Process first Interview about the management of engineering and management processes in the E/E development
8/0
Tool-supported Data and Process Management at MAN Nutzfahrzeuge AG An integrated development database manages all engineering data in the E/E development process
8/2
From Pilot Studies to Production Development Efficiency and quality in calibrating transmissions
8/6
ECU Software
AUTOSAR
Open Networks - SAE J1939
Open Networks - CANopen
Process Management
Serr ial Bus Systems Se Systems in the Auto Automo mobile bile Part 1:
Motiva Moti vation, tion, advan advanta tages, ges, tasks and archi ar chitec tecture ture of ser ser ial bus systems systems in the auto automo mobile bile The share of electron electronic ic compo components nents in the auto auto-mobile mo bile is growing growing from year to year. Electron Electronics ics plays a deci decisive sive role, not only only in satis satisfy fy ing ing prima prima-ry custom customer er wishes wishes for better better driving driving safety safety and comfort, com fort, but at the same time to achieve better better fuel fu el econo economy and reduced reduced exhaust exhaust emissions. emissions. Anoth Another er aspect as pect that should not be under under esti estimat mated ed is the concontribu tri bution tion by numer numer ous ous seri serial al bus systems systems in the auto auto-mobile. mo bile. Many functions functions would not even be possi possible ble without with out data data exchange exchange between between electron electronic ic compo compo-nents. This ar ticle ticle of fers fers some ini initial insights insights into into the world of seri serial al bus systems systems in the auto automo mobile. bile. Moti vation Moti vation and ad van ad vanta tages ges of seri se rial al bus systems systems in the auto automo mobile bile Recent histo Recent history ry of the auto automo mobile bile is charac char acter terized ized by inten in ten-sive electron electroniifi fica cation. tion. The driving driving force for this origi orig inates prima pri mari rily ly from custom customer er expec expecta tations tions of a modern modern auto automo mo-bile which are becom be coming ing increas increasing ingly ly demand demanding. ing. Moreover, Moreover, legis leg isla lators tors are contin continu ual ly ly placing placing strict er er require requirements ments on exhaust ex haust emissions. emissions. The rising rising compet compet itive and cost pressures pressures of global global iza zation tion al so so produce produce constant constant inno innova vative tive pressure. pressure. Auto Au tomo motive tive OEMs have found electron elec tronics ics to be a way to meet this mul tiple tiple chal lenge. lenge. Partic Par ticu ular larly ly this is reflect reflect ed ed in the migra mi gration tion of electron electronic ic control control units (ECUs) into into the auto auto-mobile mo bile which began be gan at the end of the 1970s.
communi commu nica cation tion channel channel inte integrates grates all indi individ vidu ual commu communi ni-cation ca tion channels channels and is referred referred to as a bus. Using Us ing this bus and asso associ ciat at ed ed seri serial al inter interfa faces ces it is possi pos sible ble to join all ECUs togeth to gether er into into a net work work refer refer to as a seri serial al bus system system (Fig(Figure 1). In this context, context, ECUs are referred referred to as bus nodes. Since the intro introduc duction tion of seri serial al bus systems, systems, the complex complex and of ten ten diver divergent gent types of wire harness harnesses es in the auto automo mo-bile have become become a thing of the past. Bus systems systems not only only simpli sim plify fy project design de sign and instal instal lation, lation, but al so so reduce reduce the weight and space required required for wiring. wir ing. Moreover, Moreover, the lower lower
At that time, the first embed em bedded ded electron electronic ic systems systems still perper formed their tasks ful ly ly auton autono omous mously. ly. Howe However, very early early it was recognized recognized that by coor coordi dinat nat ing ing appli applica cations tions placed in dif ferent ferent ECUs, it would be possi pos sible ble to increase in crease vehi vehicle cle funcfunctional tion al ity immense immensely. ly. This was the moti motiva vation tion for inte integrat grat ing ing commu com muni nica cation tion systems systems in the auto automo mobile. bile. Ahead of every everything thing else, at that time it was electron elec tronic ic drivdriving dynam dynamics ics control control that domi dominat ed ed advanced advanced devel devel opopment. Howe However the inten intensive sive wiring wir ing ef fort fort util izing izing indi individ vidu ual dedi dedicat ed ed lines only only permit permit ted ted limit limit ed ed data data exchange. exchange. As a way out of this dilem di lemma, ma, bit-seri bit-serial al data data exchange exchange via a sinsingle commu communi nica cation tion channel channel came into in to question. question. This single single
1/0
Fig ure 1: Figure Bus network networking: ing: All electron electronic ic control control units (Black: Bus nodes) are joined into into a system system network, network, the seri serial al bus system, system, by means of a bus and relat re lated ed seri serial al inter inter -faces. fa ces.
number of connect number connect ors ors redu reduces ces the suscep suscepti tibil bil ity to fail ure ure signif sig nif icant ly. ly. These many advan advanta tages ges face numer numerous ous comcommuni mu nica cation tion tasks that must be mastered mas tered by the seri se rial al bus system. sys tem. The most impor important tant commu communi nica cation tion tasks are disdiscussed in the fol lowing. lowing.
Commu Com muni nica cation tion tasks A precon precondi dition tion for trouble trouble free seri serial al data data exchange exchange is the unique al loca location tion of the data da ta to be sent to the bus nodes. EsEssential sen tial ly ly a distinc distinction tion is made between be tween sender-se sender-select lect ive ive and receiv re ceiver-se er-select lect ive ive al loca location tion (address (addressing). ing). In case of sendersenderselect se lect ive ive address addressing ing the sender sender identi identifies fies the desired desired receiv receiv-er by a unique bus node address. ad dress. In contrast, contrast, in case of rere ceiver-se ceiv er-select lect ive ive address addressing ing the data data to be sent are adaddressed. This means in princi principle ple that all data data are avail able for any node to receive receive (Broadcast). (Broadcast). Therefore Therefore all bus nodes have the task of fil tering ter ing out data data that are rel evant to them. This is accom accomplished plished with the help of the address ad dress referred referred to here as identi identifi fier. er. In order order that the receiv receiver er acquire acquire the data data and address address as one unit, the sender sender packs both of them togeth to gether er as a frame. A typi typical frame encom encompass passes es the address address and data data with a start and end recog recogni nition, tion, which are prima primari rily ly used to synsynchronize chro nize senders senders and receiv receivers. ers. A “frame” is al so so referred referred to as a “message”. “message”.
The most pressing pressing tasks of a seri se rial al bus system system include include realrealtime commu communi nica cation tion and data data integ integri rity. ty. A distrib dis tribut ut ed ed system system can only only ful fill fill its intend in tended ed purpose pur pose if all data data reach the desdestina ti nation tion node in time and without with out errors. errors. A seri serial al bus syssystem’s perform per formance ance and field of appli ap plica cation tion in the auto au tomo mobile bile substan sub stantial tial ly ly depend depend on the degree de gree with which it can avoid, re ject, detect detect and correct cor rect errors, errors, and can guaran guar antee tee timely timely data da ta transport. transport.
Data Da ta integ integri rity ty Quantita Quanti tative tively ly data data integ integri rity ty can be described described as the resid residu ual error er ror proba probabil ity. This is a statis statisti tical cal measure measure of data data integ integri ri-ty vio viola lation. tion. Resid Residu ual error error proba probabil ity is under understood stood as the product prod uct of proba probabil ity A that the transmit transmit ted ted data data are corcor rupt ed ed and proba probabil ity B that the corrupt corrupt ed ed data data remain remain unundetect de tect ed. ed. The data data integ integri rity ty of a seri serial al bus system sys tem therefore therefore depends de pends first on the extent extent to which it avoids the corrup corruption tion of data, data, and second second on the degree degree to which it can detect de tect corcorrupt ed ed data. data. Various inter Vari interac actions tions relat relat ed ed to electri electrical, cal, capac capaciitive or ininductive duc tive coupling, coupling, as well as electro electromag magnet net ic ic fields, come inin to consid consider eraation as poten potential tial causes causes of data data corrup corruption tion in the auto automo mobile. bile. Specif Specif ic ic sources sources respon responsi sible ble for corrup cor ruption tion might be actu actuaators, fan motors, motors, high-frequen high-frequency cy signals signals gengenerat er at ed ed by the commu commuta tation tion process process in DC motors motors and fast dada-
Fig ure 2: Figure Controlled Con trolled and random ran dom bus access. ac cess.
1/1
ta transmis transmissions sions or reflec reflections tions at the ends of buses. buses. The more success successful ful ly ly these causes causes can be elimi elim inat ed, ed, the great er the noise immu immuni nity ty and more reli reliaable the data data transmis transmission. sion. To enhance enhance the noise immu immuni nity ty of a seri serial al bus system, sys tem, cercer tain impor important tant measures measures are neces necessa sary. ry. Besides Besides shielding shielding the transmis transmission sion medi medium, um, as well as all electri elec trical cal and elecelec tronic tron ic compo components, nents, it is impor important tant to provide provide suf ficient fi cient ly ly large distan distances ces between between data data and power power transmis transmission sion lines and between between electri electrical cal and electron elec tronic ic compo components. nents. Further Further-more, it is impor important tant to limit limit the data data transmis transmission sion frequen frequen-cy and number number of data data signal signal edges edges and their steepness, steepness, to apply ap ply the princi principle ple of dif feren ferential tial signal signal transmis transmission sion and fifinal ly ly to termi ter minate nate bus ends with the charac char acter teris istic tic impe impe-dance of the transmis transmission sion medi medium. um. Even with opti optimal mal physi physical system system design design transmis transmission sion errors errors cannot cannot be elimi eliminat ed ed entire en tirely. ly. Error Error detec detection tion mecha mechanisms are therefore therefore essen essential. tial. Among the most frequent fre quent ly ly util ized ized methods methods is the checksum check sum method, meth od, wherein wherein the sender sender computes computes a checksum check sum from the data da ta block to be sent by a defined de fined al gorithm. gorithm. It then sends this checksum checksum at the end of the data data block. Using Using this checkcheck sum the receiv receiver er is able to ver ify the received received data data block.
The more clever clever the al gorithm, gorithm, the short er er the data data block to be protect protect ed ed and the longer the checksum, check sum, the bet ter ter the al gorithm’s go rithm’s error error detec detection tion abil ity. Howe However, due to limit lim it ed ed bandwidth band width and time require re quirements, ments, a compro compromise mise must be reached between between error error detec detection tion abil ity and the ratio ratio bebetween data data block and checksum check sum size (transmis (transmission sion ef ficien fi cien-cy). Further Fur thermore more one must consid con sider er that the checksum check sum it self self is not immune immune to disturb dis turban ances ces during dur ing transmis transmission. sion. As a rule, aft er er detect detect ing ing a transmis transmission sion error, error, error error correc correc-tion is needful, needful, e.g. by means of an error-cor er ror-correct rect ing ing checkcheck sum. Howe However, unlike unlike simple simple error er ror detec detection tion that would require re quire an explicit explicit longer checksum. check sum. For ef ficien fi ciency cy reasons reasons error-cor er ror-correct rect ing ing checksums checksums are not imple implement ment ed ed in the auautomo to mobile. bile. The error er ror correc correction tion happens happens by repeat repeat ing ing the message: mes sage: caused either either by an error error flag set by the bus node detect de tect ing ing the error, error, or auto automat mat ical ly ly in the case of peri pe riod odic ic message mes sage transmis transmission. sion.
Real-time Re al-time capa capabil bil ity A system system with real-time real-time capa capabil bil ity must be able to guaran guar antee tee transmis trans mission sion of all data data to be exchanged exchanged between between the vari var ious bus nodes within within a defined defined time window. window. Key factors factors
Fig ure 3: Figure Simpli Sim plified fied ar chitec chi tec-ture of seri serial al bus systems. sys tems.
1/2
SERI SE RIAL AL BUS SYSTEMS SYS TEMS IN THE AUTO AU TOMO MO BILE
here are the number number and sizes sizes of messa messages, ges, the avail able bandwidth, band width, and espe especial cial ly ly the type of bus access. access. In the lat ter case a funda fundamen mental tal distinc dis tinction tion is made between be tween concontrolled and random random bus access access (Figure (Figure 2). In seri serial al bus systems sys tems with controlled controlled bus access, ac cess, bus access access rights are al ready ready clearly clearly defined defined before before the bus access. access. Such systems sys tems of fer fer deter determin minis istic tic message message traf fic fic as an impor important tant precon pre condi dition tion for at taining taining real-time real-time capa capable ble seri serial al bus syssys tems. Howe However, since the entire entire commu communi nica cation tion sequence sequence is exeecut ed ex ed accord according ing to a schedule sched ule and cannot cannot be influ influenced, enced, seri se rial al bus systems systems with controlled controlled bus access access are charac character ter-ized by poor dynam dy namic ic behav behavior. ior. This disad disadvan vantage tage does not apply ap ply to bus systems systems with uncon uncon-trolled bus access. ac cess. Each bus node has the right to occu oc cupy py the bus at any time, e.g. in response re sponse to an event that just ococ curred. This produ produces ces very fast bus access; access; howe however there is the inher inherent ent risk of more or less acute col lisions, lisions, depend depending ing on the event densi den sity, ty, message message sizes sizes and the avail able data data rate. These are not good condi con ditions tions for achieving achieving real-time real-time capa ca pable ble data data transmis transmission. sion. Monitor Moni toring ing of the bus by bus nodes wishing wish ing to send signif signif icant ly ly redu reduces ces the risk of col lision. lision. It can be prevent pre vent ed ed enentirely tire ly by intro introduc duction tion of message message prior prioriities. Howe However, these bus access access methods methods based on bus moni monitor toring ing and message message prior pri oriities cannot cannot guaran guarantee tee timeli timeliness. ness. It is possi possible, ble, that low-prior low-pri oriity messa messages ges will be delayed de layed unrea unreason sonaably long.
Ar chitec chitecture ture of seri se rial al bus systems systems and bus nodes in the auto automo mobile bile Based on the ref erence erence model model for data data commu communi nica cation tion speci specified by ISO (Inter (Interna nation tional al Standard Standardiiza zation tion Organ Organiiza zation), tion), the seri serial al inter interface face of a bus node in the auto au tomo mobile bile is typi typ ical ly ly subdi subdivid vided ed into into two (commu (communi nica cation) tion) layers: layers: A lower lower layer lay er (Physi (Physical Layer) Layer) and a layer lay er above it (Data (Da ta Link Layer). Layer). Some of the tasks handled handled by the Data Da ta Link Layer Layer are adaddressing, dress ing, framing, framing, bus access, access, synchro synchroni niza zation tion and error er ror dedetection tec tion and correc correction. tion. These tasks are defined defined by a commu commu-nica ni cation tion proto protocol. col. The Physi Physical Layer Layer speci specifi fica cation, tion, on the
other hand, covers other covers all aspects aspects of the Physi Physical Layer, Layer, from the physiical bus inter phys interface face to physi physical signal signal transmis transmission sion over the bus. General Gener al ly ly the physi physical bus inter in terface face is imple implement ment ed ed with the help of a transceiv transceiver. er. A commu communi nica cation tion control control ler ler covers covers the Data Da ta Link Layer. Lay er. If all of the bus nodes within with in the system sys tem fol low the same commu communi nica cation tion proto protocol col and the same Physi Physical Layer Lay er speci specifi fica cation, tion, then the funda fundamen mental tal precon precondi ditions tions for trouble-free troub le-free data data exchange exchange between between the bus nodes are sat isfied. isfied. In seri serial al commu communi nica cation tion the sender’s sender’s appli applica cation tion passes passes to the commu communi nica cation tion control control ler ler the data data block to be sent. The commu com muni nica cation tion control control ler ler in turn adds the address address and checking check ing and synchro synchroni niza zation tion infor informa mation tion to the data da ta block, thereby there by creat creat ing ing a frame. The transceiv transceiver er now transmits transmits the frame over the bus. In the auto automo mobile bile the physi physical inter intercon con-nection nec tion structure structure is gener general al ly ly the line topol to pol ogy, which is very easy to manage manage due to the passive pas sive bus inter interface. face. On the rereceiver ceiv er side the transceiv tran sceiver er accepts accepts the frame and passes passes it to the commu communi nica cation tion control control ler, ler, which eval uates the infor informa ma-tion transmit transmit ted ted to it and in case of cor rect data data recep reception tion routes the data data block to the appli ap plica cation. tion. This results results in a hier hierarch archiical and therefore therefore transpar transparent ent comcommuni mu nica cation tion flow. This is guaran guar anteed teed by comple completion tion of the commu com muni nica cation tion tasks assigned assigned to the layers, lay ers, and by the comcommuni mu nica cation tion proto protocol col and def ini nition tion of the Physi Physical Layer Layer (Figure (Fig ure 3). For some tasks such as bus manage man agement ment (includ (including ing Sleep and Wake-Up function functional al ity) or diag diagnos nostics tics and config configu ura ration tion of bus nodes, the commu com muni nica cation tion function functional al ity provid provided ed by the Data Data Link Layer Layer is insuf insuf ficient. fi cient. By def ini nition tion higher higher laylayers respec respective tively ly higher higher commu communi nica cation tion proto protocols cols the comcommuni mu nica cation tion function functional al ity can be expand expanded. ed.
CAN, LIN, MOST and FlexRay Flex Ray Intensi Inten sified fied compe competi tition tion is contrib con tribut ut ing ing toward toward more and more safety safety and conve convenience nience functions functions in the auto automo mobile. bile. This not only only results results in a perma per manent nent increase increase in the number number of electron electronic ic compo components nents in vehi vehicles, cles, but al so so a substan substantial tial ly ly great er er degree degree of net working working with rapid rapidly ly esca escalat lat ing ing data data
1/3
vol umes, umes, since most new auto automo mobile bile functions functions cannot cannot do without with out data data exchange exchange any longer. To keep the grow growing ing comcomplexiity of auto plex automo motive tive electron electronics ics manage manageaable, auto automo motive tive OEMs create create dif ferent ferent standards standards on the system, system, function functional al and commu communi nica cations tions levels. levels. On the system sys tem or function functional al levlevel, “AUTO “AUTOSAR” SAR” (Auto (Automo motive tive Open System System Archi Architec tecture) ture) is exexpect ed ed to provide provide the neces necessa sary ry transpar transparen ency cy in the future. future. Non-propri Non-pro prieetary commu communi nica cation tion standards standards such as CAN, LIN, MOST and FlexRay FlexRay provide provide great er er transpar transparen ency cy on the comcommuni mu nica cations tions level. level.
CAN was devel devel oped oped in the early ear ly 1980s by Robert Robert Bosch GmbH, and in 1994 it became be came an inter interna nation tional al standard standard (ISO 11898). Three of Vector’s Vec tor’s exec execu utive direct direct ors ors played key roles in its devel de vel opment, opment, and in 1988 they founded founded Vector Vec tor Infor Informa matik tik GmbH. LIN, MOST and FlexRay Flex Ray ema emanat ed ed from non-propri non-proprieetary organ organiiza zations: tions: The LIN Consor Con sorti tium um (www.lin-subbus.org), (www.lin-sub bus.org), MOST Coop Cooper eraation (www.most coop cooper er-ation.com) and FlexRay FlexRay Group (www.flexray.com). (www.flexray.com). Al though though they have not been of ficial fi cial ly ly standard standardized, ized, they can be concon sidered sid ered de-facto de-facto standards. standards.
CAN (Control (Control ler ler Area Area Net work) work) is used prima pri mari rily ly in the powpow ertrain, er train, chassis chassis and conve convenience nience are areas. LIN (Local (Local Inter Intercon con-nect ed ed Net work) work) serves to achieve simple simple and cost-ef fect fect ive ive data da ta transmis transmission sion in the sensor/ac sensor/actu tuaator area. area. MOST (Media (Media Orient Ori ent ed ed System System Transport) Transport) is imple implement ment ed ed in info infotain tainment ment to transmit transmit video video and audio audio signals. signals. Final Final ly, ly, FlexRay FlexRay ena enables the most chal lenging lenging commu communi nica cation tion in safety-crit safety-crit ical disdis tribut trib ut ed ed appli applica cations. tions. Figure Figure 4 shows an exam example ple of ECU net working work ing with seri serial al bus systems systems in a modern modern auto automo mobile. bile. In contrast con trast to CAN, LIN and MOST, howe how ever, FlexRay FlexRay must first become be come estab established lished in the auto automo mobile. bile. This fall the first FlexRay Flex Ray produc production tion appli applica cation tion will hit the streets. The MuMu nich auto automo motive tive produc producer er BMW is intro introduc ducing ing the inno innova vative tive bus system system in an active active suspen suspension sion control control system system on its new X5 auto automo mobile. bile.
Reliaable partner Reli partner for ECU network networking ing and data data exchange ex change
Author: Au thor: Eugen May er Eugen er (Grad (Gradu uate Engi Engineer neer with TechTechnical ni cal Teaching Teaching Certif Cer tif icate), aft er er complet complet ing ing his voca vocation tional al training training to become be come a commu commu-nica ni cations tions techni technician, cian, studied studied electron electronics ics at the Techni Technical cal Col lege lege in Ravens Ravensburg/We burg/Weiningar arten, ten, Germa Germany, ny, and studied studied electri electrical cal engi en gineer neering ing and voca voc ation tional al teaching teaching at the Univer Uni versi sity ty of Stutt gart. gart. Since 1999 he has been working working at Vector Vector Infor Informa matik tik where he is employed employed as a Senior Senior Trainer. Trainer. Tel. +49-711/80670-57 +49 -711/80670-574, 4, Fax +49-711/80670-11 +49-711/80670-111, 1, E-Mail: eugen.may eugen.mayer@vec er@vector-in tor-infor forma matik.de tik.de
1/4
The special special ists ists at Vector Vector support support auto automo motive tive OEMs and supsup pliers pli ers in CAN, LIN, FlexRay Flex Ray and MOST net working working with a uniuni versal ver sal tool chain of design de sign and devel de vel opment opment tools as well as soft ware ware compo components nents and base soft ware ware for AUTO AUTOSAR SAR ECUs. Advis Ad vising, ing, consult consult ing ing servi services and tools for process process manage manage-ment supple supplement ment the appli applica cation tion are areas. Its servi services are comcomplement ple ment ed ed by a broad-based training train ing program program on Vector Vector tools, soft ware ware compo components nents and seri serial al bus systems. systems. For entry-lev entry-level el work in auto au tomo motive tive ECU net working working or data data exchange ex change the Stutt gart-based gart-based compa company ny of fers fers the one-day semiinar “Seri sem “Serial al bus systems systems in the auto au tomo mobile”. bile”. Funda Fundamen men-tals semi seminars on CAN, LIN, FlexRay FlexRay and MOST are best suit ed ed as intro in troduc ductions tions to the vari var ious devel devel opment opment activ activiities relat re lat ed ed to auto automo motive tive electron electronics. ics. Addi Addition tional al infor informa mation tion and schedules schedules one can find on the Inter In ternet: net: www.vector-in www.vec tor-infor forma matik.com tik.com
Outlook Out look Parts 2-5 of this series series address address the seri serial al bus systems systems CAN, LIN, FlexRay FlexRay and MOST in detail. de tail.
Developing automotive
once you have learned how to do it. Whether you are new to the field of automotive electronics electronics or are an experienced pro, at the Vector Academy Academy you will certainly 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 trainers. This is the most effective way to acquire knowledge knowledge and skills. We guide you through practice-oriented exercises. And you have the opportunity to share your experiences with colleagues 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. Te l. 0711 / 8 06700670-0 0 www.vector-academy.com
w ? n g n e h i n t e m s o g e t o t r y f c h a r W a n t o u r f r e e o a l : t r t s i t V i s n g P o g. c n m i n r a n c o n i n E - L e r a e l - e r v e c t o v w w w.
Serr ial Bus Systems Se Systems in the Auto Automo mobile bile Part 2:
Reli Re liaable data data exchange exchange in the auto automo mobile bile with CAN The relent relentless less pace of global global iza zation tion has brought growing growing compet competiitive pressure pressure to bear on auto automo motive tive OEMs and suppli suppliers, ers, which in turn leads to one inno inno va vative tive of fensive fensive after after anoth an other. er. Electron Electronics ics plays a deci decisive sive role here: Increas Increasing ingly ly complex complex electron electronic ic systems systems pro vide for a high level level of safety safety and comfort comfort in car driving. driving. The CAN (Control (Control ler ler Ar ea ea Network) Net work) seri serial al bus system system makes a crucial crucial contri contribu bution tion here with to its specif specif ic ic proper proper ties. It assures assures reli reliaable data data exchange exchange even under under harsh en vi viron ronmen mental tal condi conditions tions for exam ex ample. ple. This techni technical cal ar ticle ticle is intend intended ed to serve as an intro introduc duction tion to CAN technol technol ogy.
CAN standard, standard, imple implemen menta tation tion and inter inter face face The CAN technol tech nol ogy devel devel oped oped by Bosch [1] has been standstandardized ard ized since 1993 and exists exists as ISO Standard Stand ard 11898 which is orga or ganized nized in sever several al parts (Figure (Figure 1). The first part contains con tains the CAN proto protocol col and covers covers the entire entire data data link layer lay er (framing, address addressing, ing, bus access, access, data data assur assurance) ance) and part of the physiical layer phys layer (physi (physical signal signal ing) ing) of the standard standardized ized ref ererence model model for data data commu communi nica cation tion (ISO 7498). In the meantime mean time a large number num ber of cost-ef fect fect ive ive CAN control control lers lers have become become avail able which imple implement ment the CAN proto protocol col in hardware. hard ware. The second second part describes describes the CAN High-Speed physi phys ical laylayer, and the third part the CAN Low-Speed physi phys ical layer. layer. These two parts cover cover the Physi Physical Layer Layer of ISO 7498 (includ (in cluding ing
physical bus inter physi in terface, face, data data rates and volt age age levels). levels). The CAN High-Speed physi physical layer layer is used prima primari rily ly in power power-train and chassis chassis appli applica cations. tions. It is essen essential tial ly ly imple implement ment ed ed by the CAN High-Speed transceiv tran sceiver, er, which supports supports a maxi maximum data data rate of 1 MBit/s. The CAN Low-Speed tran sceiv sceiver er with a maxi maximum data data rate of 125 KBit/s is gener gen eral al ly ly used for the CAN Low-Speed physi phys ical layer layer that is prima primari rily ly used in the body/conve body/convenience nience area. area. According Accord ingly ly the CAN inter interface face (Figure (Figure 2) consists consists of a CAN control con trol ler ler and a CAN transceiv tran sceiver. er. While the CAN control control ler ler handles han dles the CAN proto protocol, col, the CAN transceiv tran sceiver er assumes assumes the task of physi physical ly ly coupling coupling the CAN control control ler ler to the CAN bus oper op erat at ed ed in dif feren ferential tial signal signal mode. Dif feren ferential tial signal signal transmis trans mission sion enhan enhances ces noise immu immuni nity ty and requires requires two
Fig ure 1: Figure CAN in the ref er er ence ence model mod el for data da ta comcommuni mu nica cation tion (ISO 7498), CAN standard standard and imple implemen menta tation. tion.
1/6
communi commu nica cation tion lines (CAN-High and CAN-Low line), which are termi terminat nat ed ed with the charac char acter teris istic tic line impe impedance dance to avoid reflec reflections tions at the ends.
hardware or soft ware hardware ware of exist exist ing ing bus nodes. Howe However this is only on ly true if the added added bus node is exclu exclusive sively ly a receiv receiver. er.
Event control control Message Mes sage distri distribu bution tion Message address Message addresses es and message message fil ters ters are used in a CAN net work work to orga organize nize nodes and messa messages. ges. Message Message address address-es, common commonly ly referred referred to as Identi Identifi fiers ers (ID) do not identi iden tify fy the CAN target target nodes, rather rather they identi identify fy the messa messages ges themselves, them selves, so that in princi principle ple all CAN messa mes sages ges are avail able to be received received by all CAN nodes (message (mes sage distri distribu bution). tion). By means of a fil ter ter each CAN node selects se lects those CAN messa mes sa-ges from the message message stream that are rel evant to it (receiv (receiv-er-select er-se lect ive ive system). system). The 11 bit wide ID permits per mits speci specifi fica cation tion of up to 2048 CAN messa mes sages ges in a CAN net work. work.
The messa messages ges that are transmit transmit ted ted in a CAN net work work and their sequence sequence do not depend de pend on a time progres progression, sion, rather rather they depend depend on the occur occurrence rence of special special events. Each CAN node is in princi principle ple author authorized ized to access access the CAN bus imme im me-diate di ately ly aft er er an event occurs. occurs. Given Given its rel ative tively ly short mesmessage length of max. 130 bits in standard stand ard format format and its high data da ta transfer transfer rate of up to 1 MBit/s, this method method ena enables quick reac reactions tions to asynchro asynchronous nous events. This is an impor im portant tant precon pre condi dition tion for real-time real-time capa capable ble data data transmis transmission sion in the mil lisec lisecond ond range (1 to 10 ms), which is pri ma mari rily ly a require require-ment of power powertrain train and chassis chassis appli applica cations. tions.
Message distri Message distribu bution tion of fers fers the fol lowing lowing advan advanta tages: ges: > Cost savings savings by shared use of sensors, sensors, > Easy imple implemen menta tation tion and synchro synchroni niza zation tion of distrib dis tribut ut ed ed process proc esses, es, and above all: > High flexi flexibil ity with regard regard to the config configu ura ration. tion. This is because because omit ting ting node address addresses es makes it possi pos sible ble to inte in tegrate grate other other bus nodes without without having having to modi modify the
Since CAN commu com muni nica cation tion is not based on any time schedule sched ule the message message traf fic fic is not deter determined mined until until runtime, runtime, and this implies im plies that it carries car ries the inher inherent ent risk of col lisions. lisions. This risk increas in creases es with increas increasing ing bus load, and it calls the real-time re al-time capa ca pabil bil ity of the system system into into question. question. To assure as sure real-time real-time data da ta transmis transmission sion in spite of random random bus access, access, the CSMA/CA bus access ac cess method method is util ized ized in the CAN net work. work.
Fig ure 2: Figure CAN inter inter face face and CAN network. network.
1/7
CSMA/CA bus access access method method Bus access access begins begins when a CAN node wishing wish ing to send first lislistens to the CAN bus (Carri (Carrier er Sense – CS). If the CAN bus is avail able the CAN node may begin be gin to transmit transmit its message mes sage imme im medi diate ately. ly. On the other other hand, if it detects de tects bus activ activiity it must post pone pone its send request request until until the CAN bus is avail able and the current current ly ly running running message message transmis transmission sion has been complet com plet ed; ed; in addi addition tion it must wait a dura du ration tion of three bit times (ITM Inter Intermis mission). sion). An ongo ongoing ing message message transmis transmission sion is not inter interrupt rupt ed ed in this method method – bus access access is nonde nondestruc structive. tive. If there are mul tiple tiple CAN nodes wishing wish ing to send, bit wise wise ararbitra bi tration tion (Figure (Figure 3) prevents prevents col lisions lisions from occur occurring ring in spite of simul simul tane taneous ous bus access access (Mul tiple tiple Access Access – MA). In the framework framework of bit wise wise arbi arbitra tration tion all CAN nodes wishing wish ing to send place the IDs of the CAN messa mes sages ges they wish to send bit wise wise on the bus, from the highest hi ghest to the lowest lowest signif signif icant bit. The wired-AND bus logic log ic (0=domi (0=dominant) that forms the basis ba sis of the CAN net work work ensures ensures that there is al ways ways an ununambig am bigu uous bus level. level. Aft er er adding adding on an ID bit, each CAN node compares compares the bus level level with the level level it sent. The arbi ar bi-tration tra tion logic logic decides decides whether whether a CAN node may contin con tinue ue to send or whether whether it must stop sending. sending. At the end of the arbi ar bi--
tration phase the CAN node that gets send author tration au thoriiza zation tion is the node transmit transmit ting ting the CAN message mes sage with the least signif signif icant identi identifi fier. er. Lower Lower prior prioriity CAN nodes first switch to the Rx state and access access the CAN bus for a renewed re newed send at tempt tempt as soon as the bus is free again. Not only only do the bus and arbi ar bitra tration tion logic logic prevent prevent col lisions lisions (Col lision lision Avoidance Avoidance – CA), they al so so provide provide prior prioriity-con ty-con-trolled bus access: access: The lower lower the signif signif icance of the identi iden tifi fi-er, the higher higher the prior prioriity of the CAN message, message, and this reresults in fast er er bus access. access. The CAN message message with the small est est identi iden tifi fier er (ID=0) will therefore therefore be transmit transmit ted ted without without delay. delay. If the bus load is not too high, this type of ran dom, nonde nonde-structive, struc tive, prior prioriity-driv ty-driven en bus access access facil facil itates correct correct and very fast bus access. access. On the one hand, it should be not ed ed that delays delays grow with increas in creasing ing bus load, above all delays de lays of low prior prioriity CAN messa messages. ges. In the worst case a sit uation may arise in which CAN messa mes sages ges arrive arrive too late at receiv receivers ers or are suppressed suppressed entire entirely. ly. On the other other hand, the CSMA/CA bus access ac cess method method produ produces ces a recip recipro rocal cal rela relation tionship ship between between net work work exten extension sion and maxi maximum data data rate. During Dur ing bit wise wise arbi ar bitra tration tion a reces recessive sively ly sending sending CAN node must be able to
Fig ure 3: Figure Wired-AND bus logic, logic, ar bitra bi tration tion logic logic and bitwise bit wise ar bitra bi tration tion based on exam ex ample ple of two CAN nodes.
1/8
SERI SE RIAL AL BUS SYSTEMS SYS TEMS IN THE AUTO AU TOMO MO BILE
reliaably detect reli detect a domi dominant level. level. The bit time inter in terval val should therefore there fore be sized such that signal sig nal propa propaga gation tion times on the CAN bus are ful ly ly compen compensat sat ed. ed. A length exten extension sion to a net work therefore therefore neces necessi sitates tates a longer bit time inter in terval, val, which in turn defines defines a maxi maximum usa usable data data rate.
Data Da ta transmis transmission sion It is prima primari rily ly Data Data frames that are respon responsi sible ble for data data transmis trans mission sion in the auto automo mobile bile (Figure (Figure 4). While in fact ReRe mote frames al so so exist exist for request request ing ing data, data, they are hardly hardly ever ev er used since data data transmis transmission sion in the auto automo mobile bile is not typiical ly typ ly request-based, request-based, rather rather it is prima primari rily ly provid provided ed on the infor informa mation tion gener generaator’s own ini initi tiaative. The two types of frames have identi identical cal layouts; layouts; the only only dif ference ference is that the data da ta f ield is omit ted ted in the Remote Remote frame. A ba basic sic prereq prerequi uisite site for transmit transmit ting ting Data Data and Remote Remote frames is synchro synchronism nism between between sender sender and receiv receiver. er. Since a clock line has been omit ted ted for reasons reasons of cost and ef fort, fort, synchro syn chronism nism is achieved by signal sig nal edges edges and a well-defined well-de fined resyn re synchro chroni niza zation tion mecha mechanism. Each message message transmis transmission sion begins be gins with transmis transmission sion of the domi dominant synchro synchroni niza zation tion bit (SOF – Start of Frame) and this gen er erates ates the first signal signal edge (Bus-Idle exhib exhibits its a reces recessive sive bus level). level). The receiv receiver er ensures en sures synchro synchroni niza zation tion over the entire en tire transmis transmission sion by eval uat ing ing each arriv arriving ing signal signal edge and adapt ing ing its own bit timing timing as neces necessa sary. ry. The bit stuff ing ing method method ensures ensures that a comple complemen menta tary ry bit (stuff bit) appears ap pears at the lat est est aft er er five homo homoge gene neous ous bits, thereby thereby provid providing ing a signal signal edge.
Fol lowing lowing the SOF is the ID, which may be either ei ther 11 bits (Standard-ID) (Stand ard-ID) or 29 bits (Extend (Ex tended-ID) ed-ID) in length. The standstandard format format domi dominates in the auto automo motive tive field. The extend ex tended ed format for mat typi typical ly ly plays a role in con junc con junction tion with higher higher level level proto pro tocols cols such as SAE J1939. The ID format for mat being being used is inin dicat di cat ed ed by the IDE (Identi (Iden tifi fier er Exten Extension) sion) bit. Anoth An other er bit switch (RTR bit – Remote Re mote Transmis Transmission sion Request) Request) indi indicates cates whether wheth er the frame is a Data Da ta or Remote Remote frame. The 64 bit wide data da ta f ield is avail avail able for transmit transmit ting ting useful useful infor in forma mation, tion, in which the exact exact number number of useful useful bytes is inindicat di cat ed ed by a DLC (Data (Da ta Length Code). Fol lowing lowing the data data field is the so-called CRC sequence se quence (CRC – Cyclic Cy clic Redun Redundan dancy cy Check). The sender sender gener generates ates the CRC sequence sequence based on all bits to be transmit transmit ted, ted, a gener generaator pol y yno nomi mial al and a welldefined de fined al gorithm. gorithm. Inde Independ pendent ent of the message message fil tering ter ing the same process process occurs occurs at the receiv receiving ing end with the arriv ar riving ing bits. The two sequen sequences ces are compared, compared, and the acknowl acknowl edgedgment is made aft er er the reces recessive sive CRC delim delimit it er er in the AcAc knowl edge edge slot (ACK slot). At the end of a Data Da ta frame, aft er er the reces recessive sive ACK delim delimit it er, er, comes the seven seven bit long and rere cessive ces sive EOF (End of Frame).
Data Da ta protec protection tion The proba probabil ity that corrupt cor rupt ed ed CAN messa messages ges will remain remain unde un detect tect ed ed is extraor extraordi dina nari rily ly low. It is esti es timat mat ed ed to be 4.7 x 10-11 [2]. Respon Responsi sible ble for this are error er ror detec detection tion mecha mechanisms defined defined in the CAN proto pro tocol. col. On the receiv receiver er side, bebesides the message-fil message-fil tering-in ter ing-inde depend pendent ent CRC that is capa ca pable ble
Figure Fig ure 4: Structure of the Data frame.
1/9
of detect detect ing ing up to five errors er rors within within a CAN message, mes sage, checks are al so so made of the format for mat (Form Check) and bit stuff ing stuff ing rule (Stuff Check). The sender sender performs per forms bit moni monitor toring ing and eval uates the ACK slot. If one assumes assumes an error error rate of 10 -3 in a CAN net work, work, then given giv en an annu annual al oper operat at ing ing time of 1000 hours, a data da ta rate of 500 KBit/s, a mean bus load of 25 percent per cent and a mean mesmes sage length of 80 bits, statis sta tisti tical cal ly ly speaking speaking a corrupt cor rupt ed ed CAN message mes sage will remain remain unde undetect tect ed ed by the CAN proto pro tocol col just once every every 4000 years. What is under un derstood stood as the error er ror rate is the ratio ratio of corrupt cor rupt ed ed CAN messa mes sages ges to the number num ber of all transmit trans mit ted ted CAN messa messages. ges. As soon as an error er ror detec detection tion mecha mechanism signals signals a transmis transmis-sion error, error, the CAN node detect de tect ing ing the error er ror termi terminates nates mesmessage transmis transmission sion by placing placing an error error flag (six domi dom inant bits) on the CAN bus. The error er ror flag inten intention tional al ly ly vio violates the bit stuff ing ing rule so that net work-wide work-wide each CAN node perperceives what until until then was a local lo cal error er ror and responds responds by terterminat mi nat ing ing the message message transmis transmission, sion, i.e. by append appending ing an erer ror flag. This method method assures assures net work-wide work-wide data data consist consist ency ency which is so impor im portant tant in distrib dis tribut ut ed ed appli applica cations. tions.
Error correc Error correction tion consists consists of repe repeti tition tion of the abort ed ed CAN message mes sage by the same sender send er as soon as the CAN bus is free again (aft er er the error er ror delim delimit it er er and ITM). In design designing ing the system sys tem it must be consid con sidered ered that the CSMA/CA bus access access method meth od does not guaran guar antee tee imme immedi diate ate repe repeti tition. tion. The error error recov re covery ery time depends depends on the prior prioriity of the message message and the bus load.
Node moni monitor ing ing Error signal Error signal ing ing by error error flag gives each CAN node the capa ca pa-bil ity of termi terminat nat ing ing ongo ongoing ing message message transmis transmissions. sions. Since this al so so applies applies to defective defective CAN nodes, such nodes are caca pable pa ble of bringing bringing the entire entire CAN commu com muni nica cation tion to a standstand still. To prevent pre vent this each CAN node has net work work node moni monitoring tor ing (Figure (Figure 5) that can discon dis connect nect (Bus off) a node found to be defective defective based on error er ror counters counters and rules for control control ling the error er ror counters. counters.
Acknowl Ac knowl edgment edgment of received received CAN messa messages ges In a CAN net work work each message message transmis transmission sion is acknowl acknowl edged simul simul tane taneous ously ly by all receiv receivers ers in the ACK slot (in-frame acknowl acknowl edgement), edgement), inde independ pendent ent of message message fil tering. ter ing. A domiinant level dom level signi signifies fies to a posi positive acknowl acknowl edgment, edgment, and a reces re cessive sive level level signi signifies fies a nega negative acknowl acknowl edgment. edgment. Since the sender sender places places a reces recessive sive level level in the ACK slot, just one posiitive acknowl pos acknowl edgment edgment is suf ficient fi cient to confirm confirm a correct correct message mes sage transmis transmission. sion. Because Because of this node-neutral node-neutral posi positive acknowl ac knowl edgement, edgement, nega negative tively ly acknowl acknowl edging edging CAN nodes are overwrit over writ ten ten and remain remain unheard. unheard. Therefore Therefore they send an erer ror flag aft er er the ACK delim de limit it er. er. If not a single sin gle posi positive acknowl acknowl edgment edgment is received, received, that is the ACK slot is not overwrit over writ ten ten by any receiv receiver, er, the sender sender detects de tects an ACK error error and aborts the ongo on going ing message message transtransmission mis sion by sending sending an error er ror flag.
Outlook Out look
Fig ure 5: Figure Network Net work node moni monitor tor ing ing using using two er ror ror counters counters and three node states.
1/10
Until just a few years ago CAN was the most sought aft er Until er bus technol tech nol ogy in the auto automo motive tive indus industry. try. The relent relent less less elecelectroniifi tron fica cation tion of the vehi vehicle cle has caused CAN to encoun en counter ter limlimits. Vehi Vehicle cle devel devel opers opers are question questioning ing the suit abil ity of the CAN bus espe es pecial cial ly ly in bandwidth-in bandwidth-inten tensive, sive, real-time, real-time, crit ical and highly highly safety-crit safety-crit ical motor motor vehi vehicle cle appli applica cations tions such as
SERI SE RIAL AL BUS SYSTEMS SYS TEMS IN THE AUTO AU TOMO MO BILE
the “Lane Keeping Keeping Assist Assist ance” ance” driver driver assist assist ance ance system, system, but al so so in cost-sensi cost-sensitive tive conve convenience nience appli applica cations. tions. Therefore There fore besides besides CAN two other oth er bus technol technol ogies have bebecome estab established lished over the course of time for use in the auto au to-mobile mo bile or they are on an ideal ide al course in that direc direction. tion. We are talking talking about LIN and FlexRay Flex Ray here. LIN (Local (Local Inter Intercon con-nect ed ed Net work) work) is al ready ready being being used for cost-ef fect fect ive ive net working work ing of sensors sensors and actu actuaators in the conve convenience nience area. area. FlexRay Flex Ray is on the verge of being be ing imple implement ment ed ed in real-time real-time and safety-crit safety-crit ical auto automo motive tive appli applica cations tions due to its timetriggered trig gered commu communi nica cation tion method, method, a data da ta rate of up to 20 MBit/sec and the possi possibil bil ity of sending sending over two commu communi nica ca-tion channels. channels. In its first produc production tion appli applica cation tion worldwide worldwide FlexRay Flex Ray will be imple im plement ment ed ed in an active active suspen suspension sion control control system sys tem on the new BMW X5.
ready been published published at the Inter Internet net site of the Vector Vec tor AcadAcademy [4]. Liter ature and Inter Liter In ter net net links: [1] www www.bos .bosch.co ch.com m [2] Un Unruh, ruh, J., Mat hony, hony, H.J., Kaiser, Kaiser, K.H.: Error Error Detec Detection tion Anal y ysis sis of Auto Auto-motive mo tive Commu Communi nica cation tion Proto Protocols, cols, SAE Inter Interna nation tional al Congress Congress 1990. [3] www www.ve .vecctor-in tor-infor forma matik.de tik.de [4] www www.ve .vecctor-acad tor-acadeemy.de [5]] Ma [5 Mayyer, E.: Seri Seriel le le Buss ys ysteme teme im Auto Automob mobil il – Archi Architek tektur, tur, Auf gaben gaben und Vortei Vor teile le [“Seri [“Serial al bus systems systems in the auto automo mobile bile – Archi Architec tecture, ture, tasks and advan advanta tages”]. ges”]. El ektron ektronik ik Auto Automo motive tive 7/2006, pp. 70ff.
Reli Re liaable ECU network networking ing and data data exchange exchange The special special ists ists at Vector Vector Infor Informa matik tik [3] support support auto automo motive tive OEMs and suppli suppliers, ers, not only only in CAN net working working but al so so in the LIN, FlexRay FlexRay and MOST bus systems. sys tems. For custom customer er propro jects we of fer fer univer universal sal tool chains of design de sign and devel devel opopment tools, option optional al ly ly with soft ware ware compo components nents and base soft ware ware for AUTO AUTOSAR SAR control control modules. modules. These products products are supple sup plement ment ed ed by custom customer er support, support, consult consult ing ing servi services and tools for process process manage management ment in vari var ious appli applica cation tion are areas that ena enable custom cus tomized ized adap adapta tations tions to specif specif ic ic require require-ments. These servi services are rounded rounded out by a compre com prehen hensive sive training train ing program program cover covering ing Vector Vector tools, soft ware ware compo compo-nents and seri serial al bus systems. sys tems. For an intro introduc duction tion to ECU net working working or data data exchange exchange in the auto automo mobile bile the Stutt gart-based gart-based compa company ny of fers fers the oneday semi seminar “Seri “Serial al bus systems systems in the auto automo mobile”. bile”. Funda Funda-mentals men tals semi seminars on CAN, LIN, FlexRay Flex Ray and MOST convey con vey the basic ba sic knowl edge edge needed needed to quickly quickly gain famil famil iar ariity with the many dif ferent ferent devel devel opment opment activ activiities relat relat ed ed to auto automo motive tive electron elec tronics ics [4]. The first part of this series series of arti ar ticles cles [5] addressed addressed seri serial al bus systems systems in the auto automo mobile bile in gener gen eral al terms. Upcom Upcoming ing arti ar ticles cles three through five will discuss dis cuss the LIN, FlexRay FlexRay and MOST seri serial al bus systems. systems. Inter Interest est ed ed readers readers will find supple sup ple-mental men tal and in-depth infor in forma mation tion on these topics topics that has al -
Author: Au thor: Eugen May er Eugen er (Grad (Gradu uate Engi Engineer neer with TechTechnical ni cal Teaching Teaching Certif Cer tif icate), aft er er complet complet ing ing his voca vocation tional al training training to become become a commu commu-nica ni cations tions techni technician, cian, studied studied electron electronics ics at the Techni Technical cal Col lege lege in Ravens Ravensburg/We burg/Weiningar arten, ten, Germa Germany, ny, and studied studied electri electrical cal engi en gineer neering ing and voca vocation tional al teaching teaching at the Univer Uni versi sity ty of Stutt gart. gart. Since 1999 he has been working working at Vector Vector Infor Informa matik tik where he is employed employed as a Senior Senior Trainer. Trainer. Tel. +49-711/80670-57 +4 9-711/80670-574, 4, Fax F ax +49-711/80670-11 +49-711/80670-111, 1, E-Mail: eugen.may eugen.mayer@vec er@vector-in tor-infor forma matik.de tik.de
1/11
Serr ial Bus Systems Se Systems in the Auto Automo mobile bile Part 3:
Simple and cost-ef fect Simple fect ive ive data data exchange exchange in the auto au tomo mobile bile with LIN In just a very short time the LIN bus has estab es tablished lished itself itself as the technol tech nol ogy of choice for simple simple and cost-ef fective fective data data exchange exchange in the auto automo mobile. bile. Today, Today, many auto automo motive tive OEMs are rely rely ing ing on LIN to transmit transmit non-criti non-critical signals signals in the body/con ve body/con venience nience ar ea. ea. The fol lowing lowing ar ticle ticle points out the reasons reasons for the victo vic tory ry of LIN (Local (Lo cal Inter Inter connect connect Network) Network) in the auto automo mobile bile and explains explains the under un der ly ly ing ing technol technol ogy.
Why anoth another er data data bus in the auto au tomo mobile? bile? Growing demands Growing demands of car users users for driving driving conve convenien niences ces have led to wide-ranging wide-ran ging electron electroniifi fica cation tion in this area ar ea of vehi vehicle cle technol technol ogy. This is reflect reflect ed ed in the migra mi gration tion of numer numerous ous electron electronic ic compo compo-nents into into the conve convenience nience area. area. For a long time it was usual usual pracpractice to inter intercon connect nect the contin con tinu uous ously ly increas increasing ing number number of sensors, sensors, actu ac tuaators, stepper stepper motors motors and DC motors motors direct direct ly ly to a central central concontrol module. module. This trend gradu grad ual ly ly met with crit icism: It led to a rapid rap id increase increase in wiring wir ing costs, along with great er er space require re quirements, ments, increas increasing ing weight and signif signif icant ly ly great er er suscep suscepti tibil bil ity to faults. In addi ad di-tion, growing growing indi individ vidu ual iza zation tion required required many dif ferent ferent wire harhar ness and connect connect or or vari var iants, which in turn made produc pro duction, tion, ininstal lation lation and mainte main tenance nance consid consider eraably more dif ficult. fi cult.
standard for the sensor/ac standard sensor/actu tuaator area. area. With def ini nition tion of a simple simple and cost-ef fect fect ive ive Physi Physical Layer Layer based on ISO standard standard 9141, as well as a simple sim ple and lean commu communi nica cation tion proto protocol, col, the LIN Consor Consor-tium ti um has laid the founda foundation tion for success. success. It set the stage for imple im ple-menta men tation tion of simple simple and cost-ef fect fect ive ive bus nodes. The LIN Consor Consorti tium um not only only focused focused on LIN commu communi nica cation tion it self, self, but al so so provid provided ed a devel devel opment opment method methodol ol ogy (LIN Work Flow), and this further fur thered ed accept accept ance ance of the bus system sys tem in the auto au tomo motive tive inindustry dus try signif signif icant ly. ly. LIN Work Flow makes it is possi pos sible ble to auto automate mate the devel devel opment opment of a LIN net work work (LIN Cluster), Cluster), with result result ing ing time and cost savings. savings. The corner cornerstones stones of the devel de vel opment opment method meth odol ol ogy are two data data exchange exchange formats formats used to describe describe the entire en tire LIN Cluster Clus ter and indi individ vidu ual LIN nodes uniform uniformly ly (Figure (Figure 1).
Devel opers Devel opers quickly quickly recognized recognized that net working working of compo components nents over a bus system system would be an ideal ide al solu solution tion in this auto au tomo motive tive appli applica ca-tion domain domain too. Howe However, since the CAN bus was not a can di didate date for use in the cost-sensi cost-sen sitive tive sensor/ac sensor/actu tuaator area, area, many auto automo motive tive OEMs and suppli suppliers ers began began to devel devel op op their own sensor/ac sen sor/actu tuaator bus systems sys tems as early ear ly as the mid-1990s. This gradu gradual ly ly result result ed ed in the crea creation of numer numerous ous cost-ef fect fect ive ive and simple simple yet propri proprieetary sensor/ac sensor/actu tuaator buses. buses. In the year 2000 LIN arrived arrived on the “net working working market” market” as anoth another er seri serial al bus syssystem for the sensor/ac sen sor/actu tuaator area. area. This technol tech nol ogy has prevailed prevailed on a broad front, and LIN can now be found in nearly near ly all vehi vehicles, cles, typi typical ly ly in conve convenience nience appli applica cations tions such as climate cli mate control, control, seat adad just ment, ment, door controls controls and mirror mir ror ad just ment. ment.
LIN Consor Consor tium tium assists assists in breakthrough break through An impor important tant reason reason for the quick estab establish lishment ment of LIN was the founding found ing of the LIN Consor Consorti tium um [1], which promi prominent auto automo motive tive OEMs and suppli suppliers ers as well as semi sem icon conduct duct or or and tool manu manufac factur tur-ers had joined. Its goal was to create cre ate a cross-OEM commu com muni nica cation tion
1/12
Fig ure 1: Figure LIN Work Flow: The standard stand ardized ized and quick path to the LIN Cluster. Cluster.
Serving to describe Serving describe an entire entire LIN Cluster Clus ter are the uniform uni form syntax syntax (LIN Config Configu ura ration tion Language) Language) and the standard stand ardized ized LIN Descrip Descrip-tion File (LDF). Defined Defined in the LDF are all of a LIN Cluster’s Clus ter’s proper proper-ties, in partic par ticu ular commu communi nica cation tion rela relation tionships. ships. Gener Generaator tools util ize ize the LDF to gener generate ate the soft ware ware compo components nents needed need ed for LIN commu com muni nica cation. tion. Addi Addition tional al ly, ly, the LDF provides provides neces necessa sary ry infor informa ma-tion to anal y ysis, sis, measure measurement ment and test ing ing tools and rest-of-bus emu em ula lators. tors. Similar Simi larly, ly, the descrip description tion of indi individ vidu ual LIN nodes (LIN Slaves) is given giv en structure structure by the uniform uniform syntax syntax of the Node Capa Capabil bil ity LanLanguage and standard standardized ized Node Capa Capabil bil ity Files (NCF). The NCF dedescribes the perform per formance ance charac char acter teris istics tics of a LIN Slave (includ (in cluding ing frame and signal sig nal def ini nitions, tions, bit rates, diag diagnos nostics) tics) and in the framework me work of system system design design it repre rep resents sents the founda foun dation tion for auto automat mat ed gener generaation of the LDF. The two date exchange exchange formats formats and the config con figu ura ration tion process process dedefined in the LIN speci spec ifi fica cation tion let users us ers imple implement ment a LIN Slave type (e.g. stepper stepper motor) motor) mul tiple tiple times in a LIN Cluster Clus ter or use a LIN Slave in dif ferent ferent LIN Clusters Clus ters (reus (reusaabil ity of LIN Slaves). Making Mak ing just as impor important tant a contri contribu bution tion to the success suc cess of LIN is dede tailed docu documen menta tation tion of the speci specifi fica cation. tion. LIN speci specifi fica cation tion 2.1 [2], in exis existence tence since Novem November ber 2006, defines defines the Physi Phys ical Layer, Layer, commu com muni nica cation tion proto protocol, col, LIN Work Flow, LIN API as well as di diag agnos nos-tics and config configu ura ration tion of the LIN nodes.
Single-wire Sin gle-wire commu communi nica cation tion at rates up to 20 KBit/sec The goal of creat creat ing ing a low-cost commu communi nica cation tion proto protocol col for seri serial al data da ta exchange exchange in the non-safety-crit non-safe ty-crit ical sensor/ac sensor/actu tuaator area area priprimari ma rily ly af fect fect ed ed the design design of the Physi Phys ical Layer. Layer. Physi Physical signal signal transmis trans mission sion in a LIN Cluster Clus ter does not involve in volve use of the dif feren ferential tial signal sig nal transmis transmission sion famil famil iar iar from CAN, rather rath er a conven convention tional al singlesingle-
wire line is used. To assure as sure suf ficient fi cient noise immu immuni nity ty in spite of this method, meth od, the supply supply volt age age and ground of the ECU electron elec tronics ics are used as ref erence erence volt ages for the bus level. level. A LIN transceiv transceiver er serves as the physi phys ical bus inter interface. face. A level level at least 40 % below be low the supply sup ply volt age age is inter interpret pret ed ed by the receiv receiver er as a logi log ical “0”. ReReceivers ceiv ers inter interpret pret a level level at least 60 % above the sup ply volt age age as a logiical “1”. log The maxi maximum data data rate is limit limit ed ed to 20 KBit/sec to keep noise emisemis sions within within limits. limits. For line lengths up to 40 meters me ters the maxi maximum recom rec ommend mended ed node count is 16. This takes into in to account account the node and line capac capaciitan tances ces as well as the maxi max imum al lowa lowable time conconstant of the LIN Cluster Clus ter prescribed prescribed in the LIN speci spec ifi fica cation. tion. In terms of circuit cir cuit technol technol ogy a LIN Cluster Clus ter is equiva equivalent to an Open Col lect lect or or circuit. circuit. A pull-up resis resistor tor ensures ensures that the bus level lev el reremains nearly near ly at the level level of the supply supply volt age age (High level) level) while the Tx transis tran sistors tors of all LIN nodes are inhib in hibit it ed. ed. The bus level lev el is pulled to nearly nearly ground level level (Low level) level) as soon as one of the Tx trantran sistors sis tors is ena enabled. Accord According ingly, ly, the Low state is referred re ferred to as the domiinant level dom level and the High state as the re ces cessive sive level. level.
Master-Slave Mas ter-Slave commu communi nica cation tion Communi Commu nica cation tion in a LIN Cluster Clus ter is based on a Master-Slave Mas ter-Slave archi architec tec-ture. A cluster cluster consists consists of a Master Mas ter node (LIN Master) Master) and at least one Slave node (LIN Slaves). For cost reasons, rea sons, explicit explicit commu communi nica ca-tion control control lers lers are not used. Instead In stead LIN commu communi nica cation tion is imple imple-ment ed ed by soft ware ware tasks in every every node, the so-called Slave tasks. The LIN Master Mas ter al so so has a Master Mas ter task that is used to coor co ordi dinate nate cluster clus ter commu communi nica cation tion (Figure (Figure 2). Coordi Coor dina nation tion is achieved by means of peri pe riod odic ic exe execu cution tion of the LIN Schedule Sched ule that is orga or ganized nized in frame slots (Figure (Fig ure 3). At the begin begin--
Fig ure 2: Figure Master-Slave Mas ter-Slave commu com mu-nica ni cation tion ar chitec chi tecture: ture: All LIN nodes have a Slave Task to par tici tic ipate in commu communi nica ca-tion in a LIN Cluster. Cluster. One LIN node al so so has a Master Master Task for control con trol ling ling the LIN commu com muni nica cation. tion.
1/13
ning of each frame slot the Mas ter Task transmits transmits a frame header head er with a Frame Identi Iden tifi fier er (ID), which all LIN Slaves eval u eval uate in their Slave Task. Imme Immedi diate ately ly aft er er the frame header head er a LIN Slave transtrans mits the frame response re sponse asso associ ciat at ed ed with the ID. The LIN Frame, consist con sist ing ing of the frame header head er and frame response, re sponse, is avail able to be received received by every every LIN node (Broadcast (Broadcast ing) ing) due to ID-based mesmessage address addressing. ing.
Data Da ta transmis transmission sion by LIN frames Due to the lack of a commu com muni nica cation tion control control ler, ler, seri serial al data data transmis transmis-sion in a LIN Cluster Clus ter is handled han dled over the micro mi crocon control trol ler’s ler’s seri serial al ininterface ter face (Seri (Serial al Commu Communi nica cation tion Inter Interface face - SCI) and is performed per formed byte-by-byte. The SCI transmits transmits each byte with the LSB (Least Sig nif icant 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 combi combina nation tion of a number number of SCI frames distrib dis tribut ut ed ed between between the frame header head er and frame response response (Figure (Figure 4). In transmit transmit ting ting the frame header head er the LIN Master Mas ter performs per forms two key commu com muni nica cation tion tasks: It synchro syn chroni nizes zes the LIN Slaves and del egates commu com muni nica cation tion by assign assigning ing a sender send er and one or more receiv re ceivers ers to the frame response. response. Due to cost sensi sensitiv tiviity issues, issues, the LIN Slaves may use on-chip reso res onators na tors with a frequen frequency cy tol erance erance of up to 14 percent. percent. Therefore Therefore the LIN Master Master transmits transmits a Sync Break first to let all LIN Slaves know that transmis trans mission sion of a LIN Frame is begin be ginning. ning. The Sync Break is made up of at least 13 consec con secu utive domi dominant bits, and it elicits elic its a SCI error er ror from all LIN Slaves. It is ter mi minat nat ed ed by the Sync Break Delim Delimit it er (at least one reces re cessive sive bit). The LIN Master Mas ter transmits transmits the commu com mu-nica ni cation tion clock pulse with the subse sub sequent quent Sync Byte (SCI Frame with the val ue ue 0x55).
An ID serves to del egate commu communi nica cation; tion; it is six bits in length and is protect protect ed ed by two pari par ity bits with even par ity and odd pari par ity. The ID and two pari par ity bits togeth together er are referred re ferred to as the PID (Protect (Pro tect ed ed Identi Iden tifi fier). er). The first 60 IDs are avail able for useful useful data data commu communi ni-cation. ca tion. The last four identi iden tifi fiers, ers, ID 60 through 63, are reserved reserved (of which ID 60 and ID 61 are used for diag diagnos nostic tic purpos purposes). es). The frame response response is composed composed of up to eight data data bytes and a checksum check sum for error error detec detection. tion. A distinc distinction tion is made between be tween the classic clas sic and extend ex tended ed checksum. check sum. The classic classic checksum check sum is the invert in vert ed modu modulo-256 sum of all data data bytes. There is a transmis trans mission sion error error if result re sult of adding adding the modu modulo-256 sum to the arriv ar riving ing data data bytes does not equal “0xFF”. The extend ex tended ed checksum check sum al so so consid considers ers the PID in forming forming the invert invert ed ed modu modulo-256 sum. Since the LIN Slaves are usual usu al ly ly equipped with very simple simple and lowcost micro microcon control trol lers, lers, not only only are they al lowed lowed to delay delay transmis transmis-sion of the frame response response a lit tle tle (Response (Response Space), but they may al so so insert insert sending sending pause (Inter (Interbyte byte Spaces) Spaces) between between transmis transmis-sions of SCI frames. Overall, Over all, this may lengthen length en the frame response re sponse by 40 percent. percent. The same applies ap plies to the frame header, head er, prima primari rily ly bebecause there are dif fer dif ferent ent methods methods for gener generat at ing ing the Sync Break. It is abso absolute lutely ly essen essential tial to consid consider er the 40 percent percent time reserve reserve in design de signing ing the LIN Schedule. Sched ule.
Sporad Spo radic, ic, Event Triggered Triggered and Diag Diagnos nostic tic Frames The LIN speci specifi fica cation tion contains contains provi provisions sions for making making the commu communi ni-cation ca tion cycle cycle that is rigid rig idly ly defined defined by the LIN Schedule Sched ule more flexi flexible and econom economiical. The two frame types “Sporad “Spo radic ic Frame” and “Event Triggered Triggered Frame” are provid provided ed for this purpose. purpose. In intro introduc duc-ing these supple sup plemen mental tal frame types it has become be come common common practice practice to refer refer to the conven convention tional al LIN frame as an Uncon Un condi dition tional al Frame.
Fig ure 3: Figure Central Cen tral message mes sage distr distriibu bution tion system: sys tem: The LIN Master Mas ter controls controls sending send ing and receiv re ceiving ing of all LIN frames by the Master Mas ter Task and LIN Schedule. Sched ule. A frame slot must be long enough to trans mit the asso as soci ciat ated ed LIN frame. The length of the IFS depends, de pends, among other oth er things, on the exe ex ecu cution tion cy cle cle (time base) of the Master Mas ter Task.
1/14
SERI SE RIAL AL BUS SYSTEMS SYS TEMS IN THE AUTO AU TOMO MO BILE
A Sporad Sporadic ic Frame is under un derstood stood as an Uncon Un condi dition tional al Frame that shares the same frame slot with oth er Uncon Uncondi dition tional al Frames. SpoSporadic rad ic Frames are transmit trans mit ted ted entire entirely ly by the LIN Master Mas ter as neces nec essa sa-ry, so col lisions lisions are impos impossi sible. ble. If the LIN Master Mas ter has no need for any of the frames, the asso as soci ciat at ed ed frame slot simply simply remains remains empty. empty. The Event Triggered Trig gered Frame was intro in troduced duced to commu communi nicate cate sporad sporadic ic changes chan ges or events on the par t of the LIN Slaves. It essen es sential tial ly ly corre corre-sponds to an Uncon Uncondi dition tional al Frame, but with the dif fer dif ference ence that mul tiple tiple frame respons responses es from dif ferent ferent LIN Slaves are al locat locat ed ed to the frame header. header. The frame response response that is used to complete com plete the Event Triggered Triggered frame header header depends depends on the needs of the relat re lat ed ed LIN Slaves. There is a need when there are new da ta to be transtransport ed. ed. The frame response response of the Event Triggered Trig gered Frame is identi identi-fied by the PID of the asso as soci ciat at ed ed Uncon Uncondi dition tional al Frame in the first byte. In contrast contrast to the Sporad Sporadic ic Frame, howe however, col lisions lisions cannot cannot be exclud ex cluded ed in the Event Triggered Trig gered Frame. In case of a col lision lision the LIN Master Mas ter is respon responsi sible ble for transmis transmission sion of all Uncon Un condi dition tional al Frames assigned as signed to the Event Triggered Trig gered Frame. It does this by acti ac tivat vat ing ing and process processing ing a “Col lision lision Resolv Resolving ing Schedule”. Schedule”. Both conven convention tional al Uncon Uncondi dition tional al Frames and special special Diag Diagnos nostic tic Frames are suit able for diag diagnos nosing ing the LIN Slaves. Uncon Un condi dition tional al Frames are used for simple sim ple signal-based signal-based diag diagnos nostics, tics, while Diag Diag-nostic nos tic Frames are used either ei ther for user-de user-defined fined diag diagnos nostics tics or diag diag-nostics nos tics based on a standard stand ardized ized transport transport proto protocol col [3] and uniform uniform diag di agnos nostic tic servi services [4] [5]. The LIN speci specifi fica cation tion defines defines two Diag Diagnos nostic tic Frames: The “Master “Mas ter
Request Frame” and “Slave Response Request Re sponse Frame”. The Master Mas ter Request Request Frame (ID=0x60) repre represents sents the Diag Di agnos nostic tic Request. Request. In this case the LIN Master Mas ter transmits transmits both the frame header head er and the frame reresponse. For exam example, ple, a Master Mas ter Request Request Frame is transmit trans mit ted ted if there is a Diag Diagnos nostic tic Request Request via CAN. The Slave Response Re sponse Frame (ID=0x61) corre corresponds sponds to the Diag Diagnos nostic tic Response. Response. In this case the LIN Master Master transmits transmits the header, head er, and the specif specif ic ic LIN Slave transtrans mits the response. re sponse.
Manage Man agement ment functions functions The LIN speci spec ifi fica cation tion defines defines Status Status Manage Management ment and Net work work Manage Man agement. ment. Status Status Manage Management ment speci specifies that LIN Slaves must inin form the LIN Master Mas ter of transmis transmission sion errors er rors that are detect de tect ed ed such as pari par ity or checksum check sum errors. errors. This is done by a “Response “Re sponse Error Er ror SigSignal” in an Uncon Un condi dition tional al Frame (“Status (“Status Frame”); howe however this frame does not contain contain any further fur ther infor informa mation tion on the type of error. er ror. The LIN speci specifi fica cation tion does not define define error error handling handling rather rather it leaves this task to the user. us er. The prima primary ry task of LIN Net work work Manage Management ment is to regu reg ulate the transi tran sition tion of all Slaves in a LIN Clus Cluster ter from the normal nor mal commu communi nica ca-tion state (Oper (Operaation tional) al) to the Sleep state and in the other oth er direc direc-tion (Figure (Figure 5). If the LIN Slaves do not detect de tect any bus activ activiity for four seconds, seconds, they switch from the Oper Operaation tional al state to the Sleep state. The same condi con dition tion elicits elicits a Sleep command command from the LIN Master, Mas ter, which is real re al ly ly a special special Master Master Request Request Frame. Conversely, Converse ly, when a LIN Slave detects de tects a “Wake Up Signal” Sig nal” fol lowed lowed by a val id id header header it switches switches from the Sleep state via the In itial iza za-tion state to the Oper Op eraation tional al state. The Wake Up Signal Sig nal consists consists of a
Fig ure 4: Figure Each LIN frame is composed composed of a frame header header and a frame response. re sponse. The frame header head er is al ways ways sent by the LIN Master. Master. The frame response response may be sent by one LIN Slave or by the LIN Master. Mas ter.
1/15
dominant pulse mini domi min imum 250 micros microsec econds onds and maxi maximum 5 mil liliseconds sec onds in length, and it may be sent by any LIN node. The LIN speciifi spec fica cation tion prescribes prescribes a maxi max imum Ini Initial iza zation tion phase of 100 mil lisec li seconds, onds, i.e. the LIN Master Mas ter must begin begin to exe execute the LIN SchedSchedule at the lat est est aft er er this time span. If it remains re mains passive passive the rel evant LIN Slave sends anoth an other er Wake Up Signal. Signal. The number number of repe repeti ti-tions and the inter in terval val between between repe repeti titions, tions, as well as timeouts time outs are defined de fined in the speci spec ifi fica cation. tion.
In case of network net working ing issues: issues: Quick reso res olu lution tion with exter exter nal expert expertise ise In net working working with LIN, CAN, FlexRay Flex Ray and MOST, Vector Vector Infor Informa matik tik [6] supports supports auto automo motive tive OEMs and suppli suppliers ers with a univer universal sal tool chain, embed embedded ded soft ware ware compo components, nents, base soft ware ware for AUTO AUTOSAR SAR control con trol modules modules and hardware hard ware inter interfa faces. ces. Users Users of the CANoe.LIN CA Noe.LIN tool for exam example ple bene benefit over the entire entire devel devel opment opment process process from practice-prov prac tice-proven en functions functions for model model gener generaation, simu simula lation, tion, funcfunctional tion al test ing, ing, conform conformiity test ing, ing, diag diagnos nostics tics and anal y ysis. sis. Mul titibus design design and mainte main tenance nance of the commu com muni nica cation tion data data of a net worked system system is support support ed ed by DaVin DaVinci ci Net work work Design Designer er for LIN, CAN and FlexRay FlexRay for exam ex ample. ple. Devel Devel opment, opment, cal ibra bration tion and diag diag-nostic nos tic tools for in-vehi in-vehicle cle ECUs complete complete Vector’s Vector’s exten extensive sive product product line-up. Besides Besides consul consul tation tation the Stutt gart-based gart-based compa company ny al so so of fers a tool envi environ ronment ment for the electron elec tronic ic systems systems devel devel opment opment process. proc ess. These servi serv ices are rounded rounded out by a compre comprehen hensive sive traintraining program program cover covering ing Vector Vector tools, soft ware ware compo components nents and seri se rial al bus systems. systems. For an entry-lev entry-level el intro introduc duction tion to seri serial al data data exchange exchange in the auto au to-mobile mo bile the Vector Vector Acade Academy [7] of fers fers the one-day training train ing course “Seri “Se rial al bus systems systems in the auto au tomo mobile”. bile”. Training Training courses courses on CAN,
Fig ure 5: Figure Commu Com muni nica cation tion state model model of a LIN Slave.
1/16
LIN, FlexRay FlexRay and MOST funda fun damen mentals tals convey convey the neces nec essa sary ry basic basic knowl edge edge needed needed to quickly quickly become become famil famil iar iar with the wide vari varieety of devel devel opment opment activ activiities relat relat ed ed to auto automo motive tive electron electronics. ics. The first two parts of this series se ries of arti ar ticles cles addressed addressed the topics topics of seri se rial al data data exchange exchange in the auto au tomo mobile bile and CAN. The next two ar ti ti-cles will discuss dis cuss the seri serial al bus systems systems FlexRay FlexRay and MOST. Liter ature and links: Liter [1] www www.lin.lin-sub subbus.org bus.org [2] LIN Spe Speccifi fica cation tion Package Package Revi Revision sion 2.1 [3] Ro Road ad ve vehi hicles cles – Diag Diagnos nostics tics on Control Con trol ler ler Area Area Net work work (CAN) – Part 2: Net work work layer layer servi services, Inter Interna nation tional al Standard Standard ISO 15765-2.4, Issue Is sue 4, 2002-06-21 [4] Ro Road ad ve vehi hicles cles – Diag Diagnos nostics tics on control control ler ler area area net work work (CAN) – Part 3: Imple Im plemen menta tation tion of diag diagnos nostic tic servi services, Inter Interna nation tional al Standard Standard ISO 15765-3.5, Issue Is sue 5, 2002-12-12 [5] Ro Road ad ve vehi hicles cles – Diag Di agnos nostic tic systems systems – Part 1: Diag Di agnos nostic tic servi services, Inter Inter-nation na tional al Standard Standard ISO 14229-1.6, Issue Is sue 6, 2001-02-22 [6] ww www. w.vec vector-in tor-infor forma matik.com tik.com [7] ww www. w.vec vector-acad tor-acadeemy.com
Eugen May er Eugen er (Gradu (Grad uate Engi Engineer neer with Techni Technical cal Teaching Teaching Certif Cer tif icate), aft er er complet complet ing ing his voca vocation tional al training train ing to become be come a commu communi nica cations tions techtechnician, ni cian, studied studied electron electronics ics at the Techni Technical cal Col lege lege in Ravens Ravensburg/We burg/Weing ingar arten, ten, Germa Germa-ny, and studied studied electri electrical cal engi engineer neering ing and vocaation voc tional al teaching teaching at the Univer Uni versi sity ty of Stutt gart. gart. Since 1999 he has been working work ing at Vector Vec tor Infor Informa matik tik where he is employed employed as a Senior Sen ior Trainer. Trainer. Tel. +49-711/80670-57 +49-711/80670-574, 4, Fax +49-711/80670-11 +49-711/80670-111, 1, E-Mail: eugen.may eugen.mayer@vec er@vector-in tor-infor forma matik.de tik.de
1/17
Net work work Devel Devel opment opment across LIN Bus Systems Sys tems Tools for Ef f icient Net work Tools work Design Design and Conform Conformance ance Test ing ing The transi tran sition tion from the cur rent rent LIN Version 2.0 to LIN 2.1, consist con sistent ent LIN network net work design de sign and ef ficient fi cient test strategies were key topics top ics at the 3rd LIN Sympo Sym posi sium um hosted host ed by Vector Vector Infor Infor matik matik GmbH in Febru Feb rua ary 2008 in Stuttgart. Stutt gart. Over 150 par tici ticipants from Ger many many and across the globe learned about the latest lat est de vel opments opments and trends relat re lated ed to the LIN bus, and shared s hared their expe ex peri rien ences ces on ef ficient fi cient use of simu sim ula lation, tion, design de sign and test tools.
Apart from minor minor changes changes and clari clar ifi fica cations, tions, signif signif icant function functional al improve im provements ments were made with the LIN 2.1 proto pro tocol col version version released released in Novem November ber 2006 for event-triggered event-trig gered frames, Slave identi iden tifi fica cation tion and Slave config configu ura ration tion as well as for diag diagnos nostics tics over LIN users us ers are now await ing ing the LIN consor con sorti tium’s um’s release release of LIN 2.1 conform conformance ance test speci specifi fica cation tion in the second sec ond quarter quar ter of 2008. This docu document speciifies tests for val idat ing spec ing the conform conformance ance of LIN devi de vices ces acaccording cord ing to the dif ferent ferent parts of the LIN 2.1 speci specifi fica cation. tion.
LIN Network Network Design Design Pri or to the devel Prior devel opment opment and test phases, phas es, many net work work design design chal lenges lenges must first be mastered. mas tered. These range from defin de fining ing the system sys tem topol topol ogy and cycle cycle times to creat cre at ing ing LIN frames and schedsched ule tables tables as well as rout ing ing rela relation tionships ships with other oth er bus systems. systems. LIN commu communi nica cation tion design design needs to be complete com pletely ly error-free error-free and consist con sist ent, ent, since the result re sult ing ing LIN Descrip Description tion File (LDF) is used for all subse subsequent quent devel devel opment opment steps: embed em bedded ded soft ware ware gener generaation, net work work anal y ysis, sis, conform conformance ance test ing, ing, system system and inte in tegra gration tion tests, etc. (Figure (Figure 1).
sideraably simpli sider simplifies fies the code devel devel opment opment process. process. Since LIN supsup ports only only “unsigned “unsigned signals”, signals”, global global ly ly defined defined signals signals must also be unsigned. un signed. This limi limita tation tion can usual usu al ly ly be accept accept ed ed by the CAN net works. Without the appro Without appropri priate ate tool support support for net work work design, design, it is very dif ficult fi cult to consid consider er all design design and qual ity require requirements. ments. Exten Extensive sive expe ex peri rience ence acquired acquired during dur ing series series pro jects for vari various OEMs has contrib con tribut ut ed ed to the success success of version version 2.0 of the DaVin DaVinci ci Net work work Design De signer er LIN (Figure (Figure 2). For exam example, ple, ini initial schedule schedule tables tables can be auto au tomat mat ical ly ly gener generat at ed ed by simply simply defin defining ing the frame cycle cycle times. The schedule schedule timings timings can then be easi eas ily opti optimized mized and refined re fined dedepending pend ing on, for exam ex ample, ple, the perform per formance ance of each LIN Slave. The design de sign tool from Vector Vector al so so helps the user us er to imple implement ment design design rules such as naming nam ing conven conventions tions for meaning mean ingful ful identi identifi fiers ers and signal sig nal types as well as for uniform uniform encod encoding ing of physi physical param parameeters.
The choice of net work work topol topol ogy depends depends on vari var ious factors. factors. For exexample, am ple, it may be possi pos sible ble to define define a single single LIN net work work rather rather than sepaarate net works sep works for left and right door systems. sys tems. In some cases, cas es, a function-ori func tion-orient ent ed ed approach approach is more appro ap propri priate, ate, e.g. a dedi dedicat ed ed LIN net work work for climate climate control. control. It may al so so be neces necessa sary ry to make a distinc dis tinction tion between between net works works designed designed by the OEM and subsys sub systems tems devel de vel oped oped complete completely ly by the OEM’s suppli sup plier. er.
Ef ficient fi cient Design Design across Networks Networks Net work work design design can be signif sig nif icant ly ly simpli simplified fied by direct direct ly ly rout ing ing signals sig nals between between net works. works. This requires requires defin defining ing unique signal signal names for both CAN and LIN signals. sig nals. Using Using this rout ing ing method, method, the ECU’s appli applica cation tion code is relieved relieved of rout ing ing tasks, which al so so con-
1/18
Figure Fig ure 1: Typiical workflow Typ workflow for LIN network net work design de sign
Design el ements can be easi Design eas ily reused, reused, and consist consist ency ency checks are auto au tomat mat ical ly ly performed. per formed. Espe Especial cial ly ly impor important tant for the ef fi ef ficient cient net work work design design across bus systems sys tems is the uniform uni form manage management ment of all signals signals in a global global signal signal pool. DaVin DaVinci ci Net work work Design Designer er is capa capa-ble of import import ing ing exist exist ing ing net work work descrip descriptions tions via standard standardized ized data da ta exchange exchange formats formats such as LDF, NCF, DBC or FIBEX. FIBEX. This avoids in many cases cases the re-enter re-entering ing of signal signal and encod encoding ing def ini nitions. tions.
From Mul tibus tibus Tool to Data Da ta Backbone Backbone A fu future ture trend is the increas in creasing ing movement movement towards towards global global net work work design de sign across CAN, LIN, MOST and FlexRay Flex Ray bus systems. systems. The central cen tral manage man agement ment of all data da ta and infor in forma mation tion at the vehi vehicle cle or model mod el level lev el is becom becoming ing indis indispen pensa sable. ble. Mul tibus tibus design design tools not only only rerequire access access to a common, com mon, global global signal signal pool, but must al so so support support mul tiple tiple user user access access and rights. The eASEE eAS EE Tool Suite from Vector Vec tor provides pro vides a data data backbone backbone that not only only mana manages all engi engineer neering ing data da ta for net work work designs, designs, but can al so so support support the manage management ment of project plans, storage storage of test data, data, coor coordi dinat nat ed ed data data mainte maintenance nance or archiv archiving ing of defined defined version version states before before deliv delivery ery to part ner ner compa com panies. nies.
Test Strate Strategies
used for simu simula lation tion and veri ver ifi fica cation tion are exclu exclusive sively ly ECU exter external nal ininterfa ter faces. ces. White or gray box tests, on the oth er hand, al ways ways require require access ac cess to inter internal nal ECU inter in terfa faces. ces. The Slave conform conformance ance test propro vided vid ed with the devel de vel opment opment and test tool CANoe.LIN CA Noe.LIN (Figure (Figure 3) is imple im plement ment ed ed al most most entire entirely ly as a black box test. The Master Mas ter conformance form ance test, on the other oth er hand, is imple implement ment ed ed a gray box test i.e. as a combi combina nation tion of black and white box test. A spe cial test-LDF and test appli ap plica cation tion is required required to stimu stimulate the Master. Mas ter. The LIN bus is used for veri ver ifi fica cation. tion.
Proto Pro totype type of a Black Box Mas ter Conform Conformance ance Test Al though though a gray box imple implemen menta tation tion al lows lows the Master Mas ter conform conform-ance test to be ful ly ly auto automat mat ed, ed, it can only on ly be applied applied a the start of the V-model V-model devel devel opment opment process. process. This is mainly main ly because because the rere quired test LDF and test appli ap plica cation tion are not identi identical cal to real real LDF and appli applica cation tion of the Master Mas ter ECU. On request re quest of an OEM, the LIN special spe cial ists ists from Vector Vec tor have speci specified a proto prototype type black box Master Master conform con formance ance test. By extend extending ing the Master Mas ter driver driver to provide provide eleveleven test servi serv ices, it was proved possi pos sible ble to perform per form the current cur rent LIN2.0 Master Master conform conformance ance test during dur ing all phases phas es of devel devel opment opment using us ing the real real LDF and appli applica cation. tion. The Vector Vector concept concept is not only only funda fun damen mental tal ly ly extend extendaable; it can al so so be easi easily standard standardized. ized.
The prima primary ry method method for guaran guarantee teeing ing the qual ity of LIN net works works is to apply apply the LIN conform con formance ance tests to each ECU. A black test imple im ple-menta men tation tion of such tests has the key advan ad vantage tage that the inter in terfa faces ces
Figure Fig ure 2: Design De sign of the LIN Schedule Sched ule with Da Vin Da Vinci ci Network Net work Design Designer er LIN
1/19
OEM-standard OEM-stand ardized ized LIN-Portfo LIN-Portfolio lio Last year, Audi, BMW, Daimler, Daim ler, Porsche and VW creat cre at ed ed a docu document for suppli suppliers, ers, which describes de scribes the require requirements ments for the devel devel opopment of OEM-inde OEM-in depend pendent ent “LIN port folio”. folio”. This docu document was first present pre sent ed ed to LIN consor consorti tium um members members at the All-Members All-Mem bers Meet ing ing in Octo October ber 2007 and in Febru Februaary this year to the rest of the LIN commu com muni nity ty at Vector’s Vector’s LIN Sympo Symposi sium. um. The main ob jec ob jective tive of this iniiti in tiaative is to reduce re duce devel devel opment opment and produc production tion costs through maxiimum reus max reusaabil ity. The standard stand ardiiza zation tion of the physi phys ical layer layer rerequirements quire ments across dif fer dif ferent ent OEMs does not end with the choice of transceiv tran sceiver, er, but must al so so include include speci specifi fica cations tions for connect connect ors, ors, fil ter circuits, circuits, oper operat at ing ing and instal instal lation lation condi conditions. tions. A current current exam exam-ple for such a LIN device, de vice, is an intel intel ligent ligent bat tery tery sensor sensor devel devel oped oped for sever several al OEMs. A wiper wip er motor motor and mirror mirror ad just er er are al so so in dedevel opment. opment. In order order to increase increase the size of the “LIN port folio”, folio”, each OEM devel devel oping oping a LIN device de vice in coop cooper eraation with a suppli sup plier, er, harmo harmo-nizes niz es the speci specifi fica cations tions with other oth er OEMs in techni tech nical cal commit commit tees. tees.
Ga vin C. Rogers Rog ers (B.Eng M.Sc.) is team leader leader and product product manaager for LIN devel man devel opment opment and test tools.
Hans Quecke (Infor (In forma mation tion Technol Technol ogy degree) degree) is team leader lead er and product product mana manager for tools used to design design net work work archi architec tectures tures and commu commu-nica ni cation tion data. data.
Figure Fig ure 3: Using Us ing the Slave Conform Con formance ance Test Module, Mod ule, LIN conform con formance ance tests can be easi eas ily inte integrat grated ed into in to your own CANoe CA Noe test confi config gura rations. tions.
1/20
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 sys tematically > Simulate, analyze and test ECUs and entire networks efficiently with CANoe and the XL-Interfaces > Use our reliable LIN sof tware 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. Te l. 0711 / 8 06700670-0 0 www.vector-informatik.com
L I N f t h e o y p o w ! v e a c r t n o a h R e s e r C e n c e c o m o n s. c o i R e f e r t u l n - s o l i n . l w w w
Assur As suring ing the Qual ity of LIN ECUs Current and Future Current Future Strat egies for LIN Master Master Conform Conformance ance Tests High qual ity and reli reliaabil ity are essen essential tial precon precondi ditions tions for the success successful ful appli applica cation tion of bus systems sys tems to modern modern auto au tomo mobiles. biles. Due to the signif sig nif icant increase increase in the number num ber of LIN (Local (Lo cal Inter Inter connect connect Network) Network) compo compo-nents used in auto au tomo motive tive de vel de vel opments, opments, ef ficient ficient test strateegies for this cost-ef ficient strat fi cient bus system sys tem are gaingaining in impor impor tance. tance. This ar ticle ticle describes describes the cur rent rent possi pos sibil bil ities for testing testing LIN nodes accord according ing to the latest lat est LIN conform conformance ance test speci specifi fica cation. tion. For Master Mas ter nodes a new and ef ficient ficient black box test strateegy is present strat presented ed based on the wellknown de vel de vel opment opment and simu sim ula lation tion tool CANoe.LIN. CA Noe.LIN.
Intro In troduc duction tion The LIN consor consorti tium um provides provides in addi addition tion to the speci spec ifi fica cations tions for each the proto pro tocol col version version corre correspond sponding ing conform conformance ance test speci specifi fi-cations. ca tions. The LIN conform conformance ance tests are used to ver ify whether whether a LIN device de vice is conform conform to a specif specif ic ic proto protocol col version version and al so so serve as a basis ba sis for the LIN accred ac crediita tation. tion. Since LIN net works works oper operate ate accord accord-ing to the Master-Slave Mas ter-Slave princi principle, ple, the proto protocol col conform conformiity of a MasMaster node is of ut most most impor importance. tance. The LIN conform conformance ance tests are speciified sepa spec separate rately ly for each OSI layer: layer: physi physical layer, layer, data data link laylayer, net work work manage management ment and node config configu ura ration. tion. Only Only appli applica cation tion layer lay er tests need to be speci spec ified by the OEM or suppli supplier. er. Black box tests are best suit ed ed for the method me thodiical imple implemen menta tation tion of conform conformance ance tests, since they exclu ex clusive sively ly use a devi device’s ce’s exter external nal inter in terfa faces ces (e.g. LIN inter interface) face) to stimu stimulate and veri ver ify each test
case. White box tests on the other oth er hand al ways ways require require access access to a de devi vice’s ce’s inter internal nal inter interfa faces ces (e.g. the LIN driver’s driver’s standard stand ardized ized inter in terface). face). A LIN Master Mas ter ECU of fers fers a very limit limit ed ed number number of stimu stimulation la tion options options via its exter ex ternal nal inter interfa faces ces such as CAN. Gray box tests that combine combine the two test methods meth ods are therefore therefore the most comcommonly mon ly used method method use to real real ize ize a LIN Master Mas ter conform conformance ance test, Figure Fig ure 1.
Test En vi viron ronment ment for LIN Conform Conformance ance Tests A typi typical ECU test case requires re quires config configu ura ration tion and ini initial iza zation tion of the test system sys tem and ECU under un der test, as well as subse sub sequent quent stim sti mula lation tion and veri ver ifi fica cation. tion. The Slave conform con formance ance tests provid provided ed with CANoe.LIN CANoe.LIN from Vector Vector are imple implement ment ed ed al most most entire entirely ly as black box tests. The test er er in its role as LIN Master Mas ter can usual usual ly ly perfo per forrm the stimu stim ula lation tion and veri ver ifi fica cation tion direct direct ly ly via the LIN bus.
Fig ure 1: Figure The LIN Master Master conform conformance ance test is usual ly ly imple implement mented ed as a gray box test. A black box test would, howe howe ver, be pref er er able.
1/22
Only a few tests require Only require manu manual stimu stimula lation tion or veri ver ifi fica cation tion e.g. in order or der to stimu stimulate a wakeup wakeup signal. signal. The Master Mas ter conform conformance ance test, on the other other hand, is imple implement ment ed ed by the Stutt gart-based gart-based tool provid pro vider er as a gray box. A special special test LIN Descrip De scription tion File (LDF) is provid pro vided ed to ensure ensure the correct cor rect config configu ura ration tion of the Master Mas ter driver. driver. Togeth To gether er the gener generat at ed ed driver driver code a special special test appli applica cation tion must be download downloaded ed to the Master Mas ter under under test. In this way, the LIN bus can be used for both stimu stim ula lation tion and veri ver ifi fica cation tion purpos purposes, es, despite despite the test er’s er’s role as LIN Slave. The Del phi phi Techni Technical cal Center Center in Krakau, Krak au, Poland, Poland, has gained consid consider er-able expe experi rience ence with CANoe.LIN CA Noe.LIN in the field of test ing ing for both LIN2.0 and J2602, the U.S. version ver sion of LIN. Since the LIN conform con form-ance tests do not cover cov er the OSI appli applica cation tion layer, layer, Del phi phi TCK has extend ex tended ed their test activ ac tiviities to cover cover vari var ious appli applica cation tion tests. The main focus focus of these tests is to test: signals, sig nals, schedule schedule tables, tables, gategateway rout ings, ings, and diag diagnos nostics. tics. The CAPL test functions func tions provid provided ed with CANoe.LIN CANoe.LIN have proved to be indis indispen pensa sable ble in imple implement ment ing ing and auto automat mat ing ing such tests. Accord According ing to Del phi phi TCK even very comcom plex test cases cases were easy to imple im plement ment and extend ex tend using using the C-like CAPL syntax. syntax.
Disad Dis ad van vanta tages ges of Gray Box Master Mas ter Tests With respect respect to usa usabil ity, a gray box imple implemen menta tation tion of the Master Mas ter conform con formance ance test has sever sev eral al disad disadvan vanta tages. ges. For exam example ple it is not possi pos sible ble to perform per form this test during dur ing all phases phases of devel devel opment. opment. Further Fur thermore, more, some prepa prepara ration tion ef fort fort is involved, in volved, e.g. config con figu uration
and gener generaation of the Master Mas ter driver driver code accord according ing to the test LDF, before be fore the Master-ECU Mas ter-ECU can be test ed. ed. The gray box Master Mas ter conform conformance ance test al lows lows the Master Mas ter driver driver ininterface ter face to be indi indirect rect ly ly accessed accessed by the LIN-bus via a test appli ap plica ca-tion. Al though though full test cover coverage age can be achieved in this way, this approach ap proach means that the usual usu al V-model V-model devel devel opment opment process process cancannot be strict ly ly fol lowed. lowed. For exam example, ple, it is only on ly possi possible ble to veri ver ify the Master’s Master’s conform conformiity at the begin beginning ning of the devel de vel opment opment process. As soon as the produc productive tive data database base (LDF) and appli applica cation tion are running run ning on the Master Mas ter ECU, further fur ther veri ver ifi fica cations tions can no longer be easiily performed. eas per formed. Further Fur thermore, more, the OEM can not repeat re peat the Master Mas ter conform con formance ance test without without assist assist ance ance from suppli supplier. er.
The Way to a Black Box Master Master Test Consequent Conse quent ly, ly, many auto automo motive tive OEMs and suppli suppliers ers of ten ten ask whether wheth er the Master Mas ter conform conformance ance test can be imple implement ment ed ed as a black box test. This would have the big ad van vantage tage that OEMs and suppli sup pliers ers could inde independ pendent ent ly ly perform per form tests during dur ing the entire entire dedevel opment opment process process with mini min imal config configu ura ration tion ef fort. fort. However, in order Howe order for a black box Master Master conform conformance ance test to have genu gen uine advan advanta tages ges over a gray box test, cer tain require requirements ments must be first met. Proba Prob ably the most impor important tant one is that the same driver driver soft ware ware used for devel devel opment opment must al so so be used for tests. One way of achieving achiev ing this is to extend ex tend the LIN Master Mas ter driver driver with a special special test inter in terface. face.
Fig ure 2: Figure The test commu com muni nica cation tion required required to real real ize ize a Master Mas ter conform conformance ance test as a black box test.
1/23
This driver driver exten extension sion must permit per mit the direct direct stimu stimula lation tion and veri ver ifi fi-cation ca tion of the Master Mas ter under under test via the LIN bus by provid pro viding ing the test er er with special special test servi serv ices, e.g. to change the schedule sched ule table table or read the driver’s driver’s status status word. The test commu communi nica cation tion over the LIN bus between between Master Master and test er er can use a special special diag diagnos nostic tic service, serv ice, compa compara rable ble to those used for recon re config figu ura ration tion servi services. A further further require requirement ment on such a driver driv er exten extension sion is of course the miniimal increase min increase in ECU resour re sources. ces. The test inter in terface face should al so so be remov re movaable from the produc productive tive code, e.g. via a preproc preprocess essor or define. define.
Proto Pro totype type of a Black Box Test for LIN 2.x The LIN special spe cial ists ists at Vector Vec tor were request request ed ed by an OEM to design de sign and speci specify a black box Master Master conform conformance ance test. During Dur ing speci specifi fica ca-tion of the proto pro totype, type, it became became quickly quickly clear that the test commu com mu-nica ni cation tion must not nega neg ative tively ly af fect fect the normal normal oper operaation of the Master-ECU. Mas ter-ECU. This can be only on ly achieved by apply applying ing the standard stand ard LIN diag di agnos nostics tics consist consist ing ing of Master Master Requests Requests and Slave Respons Responses es ususing a new special special diag diagnos nostic tic service. service. Only Only in this case, it is the test test er as Slave and not the Mas ter who ini in iti tiates ates commu communi nica cation. tion. The test er er sends a test command command to the Master-ECU, Mas ter-ECU, which can respond re spond either ei ther posi positive tively ly or nega negative tively, ly, Figure Figure 2. Before sending Before sending each test command com mand it is neces nec essa sary ry to exe execute a test log-in and a test ini initial iza zation. tion. This raises rais es the question question to which exex tent a conform conformance ance test can be imple im plement ment ed ed inde independ pendent ent ly ly of the
Master’s normal Master’s normal appli applica cation. tion. A complete completely ly inde independ pendent ent and paral par al lel lel oper op eraation of both test and appli ap plica cation tion proved to be impos impossi sible. ble. The appli ap plica cation tion must therefore there fore be involved involved in the real re al iza zation. tion. There are basi basical ly ly two possi possible ble strat egies for handling handling the inter interac ac-tion between between the appli ap plica cation tion and the driver’s driv er’s test mode, Figure Fig ure 3. One way is clearly clear ly inform inform the appli applica cation tion that a test is being be ing exe execut ed. An al terna ternative tive method method is to hide the test exe ex ecu cution tion from the apap plica pli cation tion as far as possi possible. ble. Both strat egies have their advan ad vanta tages ges and disad disadvan vanta tages. ges. The final final choice of strat egy may depend depend on the feedback feed back and wishes wishes of Master-ECU Master-ECU suppli suppliers. ers. In both cases cas es exist exist ing ing drivers driv ers need to be extend extended ed to support support the required required test servi serv ices. The addi addition tional al code required required for the test-server test-serv er function functional al ity has been esti es timat mat ed ed to be 20–30 % of current current LIN2.x drivers drivers and can be consid con sidered ered unprob unproblem lemat at ic ic for most Master Mas ter ECU pro jects. pro jects. The current current proto prototype type imple implemen menta tation tion provides provides eleven eleven servi services, which is more than suf fi suf ficient cient to sat isfy isfy the LIN 2.0 Master Mas ter conform conform-ance test, Figure Fig ure 4. The proposed proposed concept concept from Vector Vector is not only only extend ex tendaable, but can al so so be easi easily standard standardized, ized, since it is based on the exist exist ing ing LIN devel devel opment opment process process and proto pro tocol col speci specifi fica cations. tions. Apart from these activ ac tiviities, Vector Vector plans to further fur ther devel devel op op CANoe.LIN. CA Noe.LIN. For exam example, ple, support support of LIN 2.1 Slave tests is planned for SP4/5 of Release Release 7.0 in the third quar ter of 2008, assum assuming ing that
Fig ure 3: Figure Two possi pos sible ble strate strategies for the har monic mon ic inter inter action ac tion of Master Mas ter appli applica cation tion and test exeecu ex cution. tion.
1/24
AS SU SUR R ING THE QUALI QUAL I TY OF LIN ECUS
the LIN 2.1 conform conformance ance test speci spec ifi fica cations tions are published published in the second sec ond quarter quar ter of 2008. Support Support of the LIN 2.1 Master Master tests can be expect ex pect ed ed with Release Release 7.1 of CANoe.LIN CANoe.LIN in the fourth quarter quar ter of 2008. In addi addition tion to its devel de vel opment, opment, anal y ysis sis and simu simula lations tions tools, the Stutt gart-based gart-based compa company ny al so so provides provides training training and workshops work shops relat relat ed ed to all aspects aspects of net working working with CAN, LIN, MOST and FlexRay. FlexRay. Through numer numerous ous custom customer er pro jects, both OEMs and suppli sup pliers ers al so so prof it it direct direct ly ly from 20 years of net working working expe experi ri-ence and expert expert ise ise at Vector. Vector.
Ga vin C. Rogers Rog ers B.Eng M.Sc., is team leader leader and product product manaager for LIN development and test t ools. man
Fig ure 4: Figure An over view of the 11 test commands, com mands, which al low low a comcomplete cover cover age age of the cur rent rent LIN2.0 Master Master conform conformance ance test.
1/25
Serr ial Bus Systems Se Systems in the Auto Automo mobile bile Part 4:
FlexRay for data FlexRay data exchange exchange in highly highly crit ical safety safety appli ap plica cations tions FlexRay is going FlexRay going into into produc production tion for the first time. It will ap pear on the BMW X5, which was pre sent sented ed to the public pub lic at the Par is Par is Auto Au to Salon Salon in August August 2006, and it can be pur chased chased in Ger many many begin be ginning ning in March of this year. Within With in its active active chassis chassis system, system, FlexRay Flex Ray pro vides for secure se cure and reli re lia able data data transmis transmission sion bebetween the central cen tral control control module module and the four satel sat el lite lite ECUs, one locat lo cated ed at each shock absorb ab sorber. er. This ar ticle ticle traces traces FlexRay’s FlexRay’s path into in to the auto au tomo mobile bile and explains ex plains the key princi prin ciples ples of FlexRay Flex Ray bus technol tech nol ogy.
According Accord ing to the German Ger man Feder Federal al Statis Statistics tics Of fice fice [1] driving driving on Germa Ger many’s ny’s roads was never nev er so safe as in the year 2005. Al though though vehi ve hicle cle regis registra trations tions grew consid consider eraably, there was a nearly near ly one perpercent reduc reduction tion in acci accidents dents involv involving ing person personal al in ju jury ry (336619) comcompared to the prior prior year. There were al so so signif signif icant reduc reductions tions in the number number of traf fic fic deaths (5361, -8.2%), seri serious ous in ju juries ries (76952, -4.6%) and minor minor in ju in juries ries (356491, -1 %). This trend was contin con tinued ued in 2006: Between Between Janu January and August, August, 3260 traf fic fic parpar ticiipants were killed, and this rep re tic resents sents a 7.8 percent percent reduc reduction tion compared com pared to the prior pri or year. The number number of in jured dropped by 5.8 percent per cent over the same time peri pe riod. od. Decisive Deci sive in lower low ering ing the number num ber of acci accidents dents and reduc reducing ing the seseveriity of acci ver accident dent out comes comes are active active safety safety systems systems and assist assist ance systems systems that support sup port drivers drivers in their task of driving driv ing the vehi vehi-cle. One study by a number num ber of well-known auto automo motive tive OEMs showed, for exam example, ple, that ESP reduced re duced the number number of skidding skidding acci acci-dents by up to 80 % [2]. Making Making just as impor important tant a contri contribu bution tion to reduc re ducing ing the sever se veriity of acci accident dent out comes comes are increas increasing ingly ly saf er er passen pas senger ger cells and opti optimized mized restraint restraint systems. sys tems. In light of the goal of halving halv ing traf fic fic fatal fatal ities by the year 2010, the auto au tomo motive tive indus industry try is focus focusing ing on further fur ther devel devel oping oping exist exist ing ing acactive safety safety systems systems and driver driv er assist assist ance ance systems sys tems and devel de vel oping oping new inno innova vative tive systems. systems. Since these systems sys tems not only only provide provide ininforma for mation tion and instruc instructions, tions, but of ten ten al so so make correct correct ive ive inter inter-ventions ven tions and assume assume driving driving tasks, it is no longer possi pos sible ble to do without with out electron electronic ic inter interfa faces ces to the chassis chas sis and drivet drivet rain. rain. The combi com bina nation tion of brake-by-wire and steer-by-wire systems sys tems is thought to have great poten po tential. tial.
1/26
mentations menta tions require require very high data da ta rates to transmit transmit the increas in creasing ing number num ber of control control and status sta tus signals. signals. They are signals sig nals that not only on ly need to be transmit trans mit ted ted extreme extremely ly quickly; quickly; their transmis trans mission sion al so so needs to be abso absolute lutely ly deter determin minis istic. tic. That is the reason rea son for the growing growing impor importance tance of commu communi nica cation tion systems sys tems that guaran guar antee tee fast and deter de termin minis istic tic data data transmis transmission sion in the auto automo mobile. bile. Poten Potential tial use of by-wire systems sys tems further fur ther requires requires the design design of fault-tol erant erant structures structures and mecha mechanisms. Al though though by-wire systems systems may of fer fer wide-ranging wide-ranging capa capabil bil ities and the bene ben efits of increased increased design design freedom, freedom, simpli simplified fied assem assembly, bly, person personal al iza za-tion of the vehi vehicle, cle, etc., data data transmis transmission sion require requirements ments in the auau tomo to mobile bile are el evat ed ed consid consider eraably, because because these systems sys tems belong belong to the class of fail-oper fail-op eraation tional al systems. systems. They must contin con tinue ue to opoperate er ate accept accept ably even when an error er ror occurs. occurs. CAN cannot cannot sat isfy isfy these requires requires due to its event-driven event-driv en and prior prior-ity-driv ty-driven en bus access, access, its limit lim it ed ed bandwidth bandwidth of 500 KBit/sec based on physi physical constraints constraints in the auto au tomo mobile, bile, and lack of fault-tol ererant structures structures and mecha mechanisms [3].
FlexRay – The answer FlexRay an swer to heighten height ened ed data data transmis transmission sion rerequirements quire ments in the auto au tomo mobile bile
Require Re quirements ments of future future data data transmis transmission sion in the auto automo mobile bile
The certain cer tainty ty that CAN could hardly hard ly be expect expect ed ed to sat isfy isfy growing growing data da ta transmis transmission sion require requirements ments in the auto au tomo mobile bile over the midterm, led to the devel de vel opment opment of a number num ber of deter determin minis istic tic and fault-tol erant erant seri serial al bus systems systems with far great er er data data rates than CAN. Exam Examples ples include: include: TTP (Time Triggered Trig gered Proto Protocol) col) [4], ByteByteflight [5] and TTCAN (Time Triggered Triggered CAN) [6]. Al though though a devel devel opopment part nership nership was creat cre at ed ed as early ear ly as 2001 between between Audi and the TTP promot promot ing ing compa company ny TTTech, and al though though Byteflight Byteflight was success suc cessful ful ly ly applied applied to BMW 7-series 7-series cars in 2001, it is FlexRay Flex Ray that has prevailed prevailed in the auto au tomo motive tive indus industry. try.
Implemen Imple menta tations tions of ever ever more chal lenging lenging safety safety and driver-as driver-assist sist ance functions functions go hand in hand with the increas in creasing ingly ly more inten inten-sive inte integra gration tion of electron electronic ic ECUs in the auto au tomo mobile. bile. These imple im ple--
An impor important tant reason reason for the success suc cess of FlexRay FlexRay was the founding found ing of the FlexRay FlexRay Consor Consorti tium um [7], under under whose auspi auspices ces the two motor mo tor
vehicle vehi cle manu manufac factur turers ers Daimler DaimlerChrys Chrysler ler and BMW and the two chip produc pro ducers ers Motor Motoro ola and Phil ips ips joined forces forces in the year 2000. Based on Byteflight Byteflight bus technol technol ogy origi original ly ly devel devel oped oped by BMW, the FlexRay FlexRay Consor Consorti tium um creat creat ed ed the cross-OEM, deter determin minis istic tic and fault-tol erant erant FlexRay FlexRay commu communi nica cation tion standard standard with a data data rate of 10 MBit/sec for extreme extremely ly safetysafety- and time-crit ical appli applica cations tions in the auto automo mobile. bile.
communi commu nica cation tion structure. structure. Howe However, the FlexRay FlexRay nodes are not al lowed uncon uncontrolled trolled bus access access in response re sponse to appli applica cation-re tion-relat lat ed ed events, as is the case in CAN. Rath er they must conform con form to a preprecisely cise ly defined defined commu communi nica cation tion cycle cycle that al locates locates a specif specif ic ic time slot to each FlexRay FlexRay message message (Time Divi Division sion Mul tiple tiple Access Access - TDMA) and thereby thereby prescribes prescribes the send times of all FlexRay Flex Ray messa messages ges (Fig(Figure 1).
Today the FlexRay Today FlexRay Consor Consorti tium um is made up of seven sev en “core part ners”: ners”: BMW, Bosch, Daimler DaimlerChrys Chrysler, ler, Freescale, Freescale, Gener General al Motors, Motors, Phil ips ips and Volkswag Volkswagen. en. Gradu Gradual ly, ly, a number number of Premi Premium um Asso Associ ciate ate MemMembers (includ (including ing Vector Vector Infor Informa matik tik [8]) and Asso Associ ciate ate Members Members joined the organ organiiza zation. tion.
Time-trig gered commu Time-triggered communi nica cation tion not only only ensures ensures deter determin minis istic tic data data commu com muni nica cation; tion; it al so so ensures ensures that all nodes of a FlexRay Flex Ray cluster cluster can be devel devel oped oped and test ed ed inde independ pendent ent of one anoth another. er. In addi addi-tion, remov removal al or addi addition tion of FlexRay FlexRay nodes in an exist ex ist ing ing cluster cluster must not impact impact the commu com muni nica cation tion process; process; this is consist con sist ent ent with the goal of re-use that is of ten of ten pursued pursued in auto automo motive tive devel devel opopment.
Making a signif Making signif icant contri contribu bution tion to the success success of FlexRay FlexRay was the detailed de tailed docu documen menta tation tion of the FlexRay Flex Ray speci specifi fica cation. tion. The two most impor im portant tant speci specifi fica cations, tions, the commu communi nica cation tion proto protocol col and the physiical layer, phys layer, are current current ly ly in Version Version 2.1. These and other other FlexRay FlexRay bus technol technol ogy speci specifi fica cations tions can be download down loaded ed from the homehome page of the FlexRay FlexRay Consor Consorti tium um [7].
FlexRay commu FlexRay communi nica cation tion ar chitec chitecture ture – Time-triggered, Time-trig gered, fault tol er er ant ant and flexi flex ible Just as in the case of data data commu communi nica cation tion in a CAN cluster, clus ter, data data commu com muni nica cation tion in a FlexRay FlexRay cluster cluster is al so so based on a mul ti-master ti-master
Fol lowing lowing the para par adigms of time-triggered time-trig gered commu communi nica cation tion archi archi-tectures, tec tures, the under underly lying ing logic logic of FlexRay FlexRay commu communi nica cation tion consists consists of trigger trig gering ing all system sys tem activ activiities when specif spe cif ic ic points are reached in the time cycle. cycle. The net work-wide work-wide synchro synchronism nism of FlexRay FlexRay nodes that is neces nec essa sary ry here, is assured as sured by a distrib distribut ut ed, ed, fault-tol erant erant clock synchro synchroni niza zation tion mecha mechanism: All FlexRay FlexRay nodes not only on ly concontinu tin uous ously ly correct correct for the begin beginning ning times (off set set correc correction) tion) of regu regularly lar ly transmit transmit ted ted synchro synchroni niza zation tion messa messages; ges; they al so so correct correct for the dura du ration tion (slope correc cor rection) tion) of the commu communi nica cation tion cycles cycles (Figure (Figure 2).
Fig ure 1: Figure Princi Prin ciple ple of FlexRay Flex Ray commu com muni nica cation. tion.
1/27
This increas increases es both the bandwidth band width ef ficien fi ciency cy and robust robust ness ness of the synchro syn chroni niza zation. tion. FlexRay commu FlexRay communi nica cation tion can be based on either ei ther an electri elec trical cal or opti opti-cal physi physical layer. layer. Speaking Speaking in favor favor of electri electrical cal signal signal transmis trans mis-sion is its simplic sim pliciity, which brings cost advan ad vanta tages. ges. The compar comparaatively tive ly cost-inten cost-intensive sive opti optical cal signal signal transmis transmission sion is charac char acter terized ized by substan sub stantial tial ly ly bet ter ter electro electromag magnet net ic ic compat compat ibil ity (EMC) compared compared to electri electrical cal signal signal transmis trans mission. sion. FlexRay commu FlexRay communi nica cation tion is not bound by a specif specif ic ic topol topol ogy. A simsimple, passive passive bus structure structure is just as feasi feasible ble as an active ac tive star topol to pol ogy or a combi combina nation tion of the two (Figure (Fig ure 3). The prima primary ry advan advanta tages ges of the active active star topol to pol ogy lie in possi pos sibil bil ity of discon disconnect nect ing ing faulty commu com muni nica cation tion branches branches or FlexRay FlexRay nodes and - in design designing ing larger larger clusters clus ters - the abil ity to termi ter minate nate with ideal ide al bus termi termina nations tions when physiical signal phys signal transmis transmission sion is electri electrical. cal. To mini minimize fail ure ure risk, FlexRay FlexRay of fers fers redun redundant dant layout layout of the commu com muni nica cation tion channel channel (Figure (Figure 4). This redun redundant dant commu communi nica cation tion channel chan nel could, on the other oth er hand, be used to increase in crease the data data rate to 20 Mbit/sec. The choice between be tween fault tol erance erance and addi addition tional al bandwidth band width can be made indi individ vidu ual ly ly for each FlexRay Flex Ray message. message. Final ly, Final ly, an inde independ pendent ent control control mecha mechanism (Bus Guardi Guardian) ensures ensures that a FlexRay Flex Ray node only only gets access access to the bus during dur ing its turn in the commu communi nica cation tion cycle. cycle. This prevents pre vents bus monop monopo oli liza zation tion by a defective de fective FlexRay FlexRay node (babbling (babbling idi idiot).
Fig ure 2: Clock synchro synchroni niza zation. tion.
1/28
FlexRay Flex Ray commu communi nica cation: tion: Deter Deter minis ministic tic and dy namic namic Each commu communi nica cation tion cycle cycle is equal in length and is es sen sential tial ly ly orga orga-nized into into a stat ic ic time segment seg ment and a dynam dynamic ic time segment segment (Fig(Figure 1). Of central central impor importance tance here is the stat ic ic segment segment that begins begins each commu communi nica cation tion cycle. cycle. It is subdi subdivid vided ed into into a user-de user-defin finaable number num ber (maxi (maximum 1023) of equal ly ly long stat ic ic slots. Each stat ic ic slot is assigned as signed to a FlexRay FlexRay message message to be sent by a FlexRay Flex Ray node. Assign Assignments ments of stat ic ic slots, FlexRay FlexRay messa messages ges and FlexRay Flex Ray nodes are made by slot number, num ber, message message identi identifi fier er (ID), and the val ue ue of the slot counter counter imple implement ment ed ed on each FlexRay FlexRay node. To ensure ensure that all FlexRay FlexRay messa messages ges are transmit trans mit ted ted at the right time and in the correct cor rect sequence sequence in each cycle, cy cle, the slot councoun ters on all FlexRay Flex Ray nodes are incre in crement ment ed ed synchro synchronous nously ly at the bebeginning gin ning of each stat ic ic slot. Because Because of its guaran guar anteed teed equidis equidistant tant and therefore therefore deter determin minis istic tic data data transmis transmission, sion, the stat ic ic segment segment is predes predestined tined for the transmis trans mission sion of real-time real-time rel evant messa messages. ges. Fol lowing lowing the stat ic ic segment segment is an option op tional al dynam dynamic ic segment segment that has the same length in every ev ery commu communi nica cation tion cycle. cycle. This segment seg ment is al so so orga organized nized into into slots, but not stat ic ic slots, rather rather so-called minminislots (Figure (Figure 1). Commu Communi nica cation tion in the dynam dy namic ic segment segment (mini(minislot ting) ting) is al so so based on al loca locations tions and synchro synchronous nous incre increment ment ing of the slot counters coun ters on the FlexRay Flex Ray nodes. However, it is not manda Howe man dato tory ry to transmit trans mit the FlexRay Flex Ray messa messages ges asassoci so ciat at ed ed to the minislots min islots with each commu communi nica cation tion cycle, cycle, rather rather they are only only sent as needed. need ed. If messa messages ges are not needed, need ed, the slot
Fig ure 3: Figure Combined Com bined topol topol ogy of passive pas sive bus and active active star.
SERI SE RIAL AL BUS SYSTEMS SYS TEMS IN THE AUTO AU TOMO MO BILE
counter of a minislot counter min islot is incre in crement ment ed ed aft er er the defined defined time peri period. od. While a (dynam (dynamic) ic) FlexRay FlexRay message message is being being transmit transmit ted, ted, incre incre-ment ing ing of the slot counter counter is delayed delayed by the message message transmis transmission sion time (Figure (Figure 5). The al loca location tion of a dynam dynamic ic FlexRay FlexRay message message to a minislot minislot implic implicit it ly ly defines de fines the prior prioriity of the FlexRay FlexRay message: message: The lower lower the number number of the minislot, min islot, the higher higher the prior prioriity of the dynam dynamic ic FlexRay FlexRay mesmessage, the earli ear lier er it will be transmit trans mit ted, ted, and the higher high er the proba probabil ity of transmis transmission sion given given a limit limit ed ed dynam dynamic ic time segment seg ment length. The dynam dynamic ic FlexRay FlexRay message message assigned assigned to the first minislot min islot is al ways transmit transmit ted ted as neces necessa sary, ry, provid provided ed that there is a suf fi suf ficient cient ly ly long dynam dynamic ic time segment. seg ment. In the commu communi nica cation tion design design it must be ensured en sured that the lowest low est prior pri oriity dynam dynamic ic FlexRay FlexRay message message can be transmit trans mit ted ted too – at least provid pro vided ed that there are no other, oth er, higher higher prior prioriity needs. The design design-er of a FlexRay FlexRay cluster cluster must al so so ensure ensure that transmis trans mission sion of the longest long est dynam dynamic ic FlexRay FlexRay message message is even possi pos sible. ble. Other Otherwise, wise, the commu com muni nica cation tion design design would not make any sense. The commu communi nica cation tion cycle cycle is complet complet ed ed by two addi addition tional al time segsegments (Figure (Figure 1). The “Symbol “Symbol Window” Window” segment segment serves to check the function functional al ity of the Bus Guardi Guardian, and the “Net work work Idle Time – NIT” time segment seg ment closes closes the commu communi nica cation tion cycle. cycle. During Dur ing the NIT the FlexRay FlexRay nodes cal culate culate the correc cor rection tion factors factors needed needed to synsynchronize chro nize their local lo cal clocks. At the end of the NIT, an off set set correc correc-tion is made if neces nec essa sary ry (the slope correc cor rection tion is al ways ways distrib distribut ut ed ed over the entire entire commu communi nica cation tion cycle). cycle). There is no data da ta transmis transmission sion during dur ing the NIT.
Fig ure 4: Figure Passive Pas sive bus structure struc ture with two commu communi nica cation tion chanchannels mini minimiz mizes es fail ure ure risk.
CRC-protect CRC-pro tected ed data data transmis transmission sion The signals signals in a FlexRay Flex Ray cluster cluster are transmit trans mit ted ted by the well-defined well-defined FlexRay Flex Ray message, message, wherein wherein there is essen es sential tial ly ly no dif ference ference in the formats for mats of the FlexRay Flex Ray messa messages ges transmit transmit ted ted in the stat ic ic segment segment and those transmit trans mit ted ted in the dynam dy namic ic segment. segment. They are each comcomposed of a header, header, payload payload and trail er er (Figure (Figure 6). The header header compris comprises es the five-bit wide status sta tus field, ID, payload payload length and cycle cycle counter. counter. The header-CRC head er-CRC (11 bits) protects pro tects parts of the status status field, ID and payload payload length with a Hamming Ham ming distance dis tance of 6. The ID identi identifies fies the FlexRay FlexRay message message and repre represents sents a slot in the stat ic ic or dynam dynamic ic segment. segment. In the dynam dynamic ic segment segment the ID corcorresponds re sponds to the prior prioriity of the FlexRay Flex Ray message. message. The indi in divid vidu ual bits of the status status field speci specify the FlexRay FlexRay message message more precise precisely. ly. For exam ex ample, ple, the “sync frame indi in dica cator tor bit” indi indicates cates whether whether the FlexFlexRay message message may be used for clock synchro synchroni niza zation. tion. Aft er er the header head er comes the so-called payload. pay load. A total total of up to 254 useful use ful bytes may be transport trans port ed ed by one FlexRay FlexRay message. message. The trail er encom encompass passes es the header head er and payload-pro payload-protect tect ing ing CRC (24 bit). Given Giv en a payload payload of up to 248 useful useful bytes, the CRC guaran guarantees tees a Hamming Ham ming distance dis tance of 6. For a larger larg er payload payload the Hamming Hamming distance dis tance is 4 [8].
In network networking ing issues: issues: Achieving Achieving ob jec jectives tives rapid rapidly ly with exter ex ter nal nal expert ex pertise ise In the year 2001, Vector Vector Infor Informa matik tik was al ready ready of fering fer ing the first product prod uct solu solution tion for the devel devel opment opment of FlexRay FlexRay systems. systems. In the meantime, mean time, devel devel opers opers can now obtain obtain a compre comprehen hensive sive port folio folio of products pro ducts [9]. These include include tools for design designing, ing, devel devel oping, oping, simu simulat ing, ing, ana analyz lyzing, ing, test ing ing and cal ibrat ing ing ECUs and distrib dis tribut ut ed ed net works. DaVin DaVinci ci Net work work Design Designer er FlexRay FlexRay gives the devel de vel oper oper an envi en viron ronment ment for ef ficient fi cient ly ly design designing ing net work work archi architec tecture ture and commu com muni nica cation tion rela relation tionships. ships. Simu Simula lation, tion, anal y ysis sis and test ing ing of FlexRay Flex Ray systems systems are performed per formed with CANoe.Flex CANoe.FlexRay, Ray, whose mul titibus concept concept ena enables simul simul tane taneous ous oper operaation of FlexRay, FlexRay, CAN, LIN and MOST bus systems. systems. For precise precise study of the FlexRay FlexRay net work’s work’s system sys tem behav behavior ior in response response to errors er rors and disturb disturban ances, ces, FRstress gener gen erates ates them on a channel chan nel in the FlexRay Flex Ray cluster. cluster. For direct direct acaccess to inter internal nal ECU vari var iables, the devel de vel oper oper needs a special special measmeasurement ure ment and cal ibra bration tion proto protocol: col: XCP on FlexRay. FlexRay. In the context con text of the devel devel opment opment of the active ac tive chassis chassis system sys tem on the new BMW X5, BMW engi engineers neers imple implement ment ed ed Vector’s Vector’s measure measurement, ment, cal ibra bration tion and diag diagnos nostic tic tool CANa CANape. pe. As the XCP-on-FlexRay XCP-on-Flex Ray Master, Mas ter, CANa CANape pe measures meas ures and cal ibrates indi individ vidu ual ECU param parameeters direct direct ly ly via FlexRay. Flex Ray. Besides Besides soft ware, ware, Vector Vector al so so devel devel ops ops stacks for ECUs.
1/29
FlexRay soft ware FlexRay ware compo components nents make it possi pos sible ble to inter intercon connect nect apapplica pli cations tions with dif ferent ferent bus or oper operat at ing ing systems systems in an uncom un compli pli-cat ed ed way. For hardware hard ware access access to FlexRay FlexRay buses, buses, suit able bus ininterfa ter faces ces connect connect to the USB, PCI and PCMCIA ports of a PC or note book comput comput er. er. The Vector Vector Acade Academy [10] can teach the basic ba sic knowl edge edge needed needed to quickly quick ly become become famil famil iar iar with the diverse di verse devel devel opment opment activ activiities rerelat ed ed to ECU commu communi nica cation tion in the auto au tomo mobile. bile. This knowl edge edge is shared in the context con text of semi seminars on CAN, LIN, FlexRay FlexRay and MOST. Liter ature and links: Liter [1]] ww [1 www. w.des desta tatis.de tis.de [2] www.b www.bosch.com osch.com [3]] Ma [3 Mayyer, E.: Dat enkom enkommun muniikat ion ion im Auto Automob mobil il – Teil 2: Siche Sicherer rer Dat enenaustausch aus tausch mit CAN im Auto Automob mobil il [“Data [“Data commu communi nica cation tion in the auto au tomo mo-bile – Part 2: Reli Re liaable data data exchange exchange with CAN in the auto au tomo mobile”]. bile”]. In: El ektron ektronik ik Auto Automo motive tive 8/2006, pp. 34-37 [4] www www.tttec .tttech.com h.com [5] www www.byte .byteflight.com flight.com [6] www.canwww.can-cia.org/can/ttcan cia.org/can/ttcan [7] www.vec www.vector-in tor-infor forma matik.com tik.com [8]] ww [8 www. w.flex flexray.c ray.com om [9] www www.flex .flexray-so ray-solu lutions.com tions.com [10]www.vector-acad [10]www.vec tor-acadeemy.com
Eugen May er Eugen er (Gradu (Grad uate Engi Engineer neer with Techni Technical cal Teaching Teaching Certif Cer tif icate), aft er er complet complet ing ing his voca vocation tional al training train ing to become be come a commu communi nica cations tions techtechnician, ni cian, studied studied electron electronics ics at the Techni Technical cal Col lege lege in Ravens Ravensburg/We burg/Weing ingar arten, ten, Germa Germa-ny, and studied studied electri electrical cal engi engineer neering ing and vocaation voc tional al teaching teaching at the Univer Uni versi sity ty of Stutt gart. gart. Since 1999 he has been working work ing at Vector Vec tor Infor Informa matik tik where he is employed employed as a Senior Sen ior Trainer. Trainer. Tel. +49-711/80670-57 +49-711/80670-574, 4, Fax +49-711/80670-11 +49-711/80670-111, 1, E-Mail: eugen.may eugen.mayer@vec er@vector-in tor-infor forma matik.de tik.de
Fig ure 5: Figure Exam Ex ample ple of commu com muni ni-ca tion flow in the dy cation namic nam ic time segment. seg ment.
Fig ure 6: Figure Structure Struc ture of the FlexRay Flex Ray message message with head er, pay load header, load and trail er. er.
1/30
ECU Calibration
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 conf igured 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) 711/80670-0 www.vector-informatik.com
c e f e r e n e R y e x R a h e F l t t e n o w ! G c o m C h a r t o n s. c o i t u l a y - s o f l e x r . f w w w
The Optimal Operating System for FlexRay-Based Applications 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. Cr iteria to be considered in the decision of which operating system to use together with FlexRay, besides deterministic behavior and per formance, 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. As a scalable high-speed communication system with deterministic
> Interrupt Services Routines (ISRs) are hardware-specific and
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 C AN communication, all messages are assigned to fixed communication intervals. This offers to each participating ECU a cleary timed availability 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 scheduling of communication processes is mapped in the communication-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-
are triggered by the hardware per iphery. 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 properties of the AUTOSAR OS [2] are provided in four expansion stages,
ticipating software components. Both event-triggered and timetriggered operating systems are commercially available, each one
the so-called Scalability Classes (SC). Table 1 shows a summary of the relationship between these properties and the Scalability
having different services. Another available option is operating systems with memory protection.
Classes. Only properties relevant to a FlexRay-based application are listed. These properties are explained in the following.
Which operating system is best suited to a FlexRay-based application, 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
n o i t / a e z i m n i T o l r h a b c n o l y G S
n o i t c e t o r P y r o m e M
Comment
SC1
Event-triggered
SC2
Advanced development of OSEKtime
SC3
Advanced development of HIS-Protected OS
SC4
provide, under optimal utilization of the hardware used, a supplemental run-time environment for managing functional units.
Table 1: FlexRay-relevant properties of the AUTOSAR OS
Defined operating system services offer this functionality. In designing an application, at first time-independent, concurrent
The currently available specifications of BSW (Basic Software) and
subtasks are defined. The outcome of this are tasks or interrupts compete for run-time assignment according to the operating sys-
RTE (Runtime Environment) do not cover memory protection yet. This will be addressed in future versions of the BSW and RTE
tem’s scheduling algorithm: > Tasks are triggered by alarms or events. A distinction is made
specifications.
between Extended Tasks and Basic Tasks. Extended Tasks are distinguished by their ability to wait for events.
1/32
Scalabilty Class
s e l b a T e l u d e h c S
g n i r o t i n o M e m i T
Figure 1: Case A – Without error handling
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.
budget, time monitoring guarantees lower-priority tasks or interrupts access to the processor to execute their tasks. If an interrupt lasts too long, as in Case C of Figure 3, it is cancelled so that the extended task can continue to execute.
For each task:
For each interrupt:
> Timeframe: Monitoring time
> Timeframe: See Task
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
period (greater than the execution time; it is not
> Worst case execution time per execution
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 interrupt. OSEKtime [3] provides classic deadline monitoring for this
absolutely essential that the task be completed within the monitoring time period; cf. Figure 1 Case A).
> Max. number of interrupts per Timeframe
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 budget: Worst case execution time per monitoring time period.
execution time monitoring for each individual task and each interrupt. This monitoring is defined by various parameters in the configurator. When a monitoring parameter is violated, depending on the con-
If multiple activation of a Basic Task should be allowed in the operating system’s configurator, the execution budget con-
figuration the t he operating system initiates a “Reset_OS”, “Kill_Application”, “Kill_Task” “Kill_Task” or “Kill_Interrupt” as a reaction to the error.
tains the total execution time The effect of an additional of all activations of the affect- interrupt per Timeframe is
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
Multiple interrupts may be allowed per Timeframe. However the worst case execution time only refers to a single loop pass.
ed task. In principle multiple shown in cases B and C of figactivations are not possible for ures 2 and 3. extended tasks.
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 Figure 2. This exclusively affects the originator. According to the
1/33
Figure 2: Case B – With error handling caused by excessively long execution time of the task
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 synchronize 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”).
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
Mechanisms for memory protection are necessary for early detec-
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 consideration must be given to the OS for optimal support of the synchroni-
tion and prevention of disturbances by other modules. When
zation of the data exchange between FlexRay and the application.
Memory Protection
Figure 3: Case C – With error handling caused by excessively long execution time of an interrupt
1/34
THE OPTIMAL OPERATING SYSTEM FOR FLEXRAY-BASED APPLICATIONS
In the FlexRay protocol up to 64 base cycles are combined to form a continuously repeating round. Each base cycle contains
the application needs and the availability of the operating system properties. In principle, communication tasks should be triggered
frames with different process data or signals for different application 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
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
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 tasks. At the beginning of each base cycle the “FlexRay Cycle Start Interrupt” is triggered by the FlexRay controller. The communication task is activated immediately. Independently, the operating
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 signal 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 minimize imprecision with regard to the signal propagation time of a FlexRay-based application.
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 oscillator,, results in delayed processing of the transported FlexRay data (e.g. from frame 2) of max. ∆t OS = 1 ms. If the application does not expect a quicker reaction 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
For synchronizing the exchange of data in a FlexRay-based application various methods of resolution are possible, depending on
application tasks. FlexRay-independent tasks can continue to be attached to the OS System T imer.
Figure 4: Solution A – Data exchange between FlexRay and an application task with OSEK-OS
1/35
In startup behavior it should be noted that the FlexRay timer, and consequently also the tasks that it activates, are unavailable
offers the developer the optimal operating system for all FlexRay applications: osCAN certified to the OSEK/VDX standard with or
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-
without High Resolution Timer or osCAN AUTOSAR that covers Scalability 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-
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.
ulability of tasks from a worst-case perspective. Vector supports the user with sof tware components and individualized service for universal development of FlexRay systems up to series production. Development is simplified by mature tools that
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.
are tuned to one another another,, like for instance DaVinci Network Designer for all FlexRay-typical design tasks or CANoe.FlexRay 6.0 for simulation and stimulation of a network, integration tests and rest-ofbus 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 st andardized measurement and XCP-on-FlexRay XCP-on-FlexRay calibration protocol. The FlexRay Evaluation Bundle provides for quick and flexible implementation of a FlexRay network. This integrated environment of software components and tools also includes a sample application for a FlexRay system with two nodes.
Summary A FlexRay-based application does not absolutely require a timetriggered operating system. The choice of a suitable operating system 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
Figure 5: Solution C – Data exchange between FlexRay hardware and an application task with AUTOSAR SC1 OS
1/36
THE OPTIMAL OPERATING SYSTEM FOR FLEXRAY-BASED APPLICATIONS
Literature references: [1] OSEK/VDX Operating System, Version 2.2.2, www.osek-vdx.org www.osek-vdx.org [2] AUTOSAR - Specification Specification of Module Operating System V2.0, www.autosar.org [3 OSEKtime – OSEK/VDX OSEK/VDX Time-Triggered Time-Triggered Operating System, Version 1.0, 1.0, www.osek-vdx.org
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 commercial vehicles in advanced development for CAN, J1939 and diagnostics. She is employed at Vector as a product management engineer in the area of Fle xRay embedded software components. Tel. +49-711/80670-2211 +49-711/80670-2211,, Fax +49-711/80670-11 +49-711/80670-111, 1, E-mail:
[email protected]
Dirk Grossmann (Graduate Engineer) studied Electrical Engineering at the University of Stuttgart. Af ter 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-11 +49-711/80670-111, 1, E-mail:
[email protected]
Winfried Janz (Graduate Engineer) studied Electrical Engineering at the University of Stuttgart. After working for 4 years developing software for embedded controllers in control and automation engineering he came to Vector in 1995. Since 1997 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 committees he helped to give shape to the Operating System and Configuration specifications. Tel. +49-711/80670-367 +49-711/80670-367,, Fax +49-711/80670-11 +49-711/80670-111, 1, E-mail: winfr ied.janz@vector
[email protected] -informatik.de
1/37
Embedded Sof Sof tware for FlexRay Systems Special aspects and benefits of implementing modularized software
Standardized software components will help in mastering the growing complexity of the interplay of all software components 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.
1/38
The FlexRay bus protocol is an in-vehicle network on its way to the starting line providing large transmission bandwidth for fast control systems. FlexRay enables 20 times greater bandwidth than C AN
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
and reduces complexity by using fewer gateways. Because of its time-triggered control, it is especially well suited as a communication system for distributed, fault-tolerant systems and safety-relevant applications. There is also the hope that the growing complex-
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 def ines which exchange formats can be used and how the interfaces
ity of vehicle electronics can be kept in check by standardization of the software sof tware system architecture with AUTOSAR.
between individual modules need to operate. This modularity makes it easier to scale software features to the
What does FlexRay ECU software sof tware need to look like?
specific requirements of a vehicle variant or generation, e.g. ECUs without network management. Development effort for the basic
To fully exploit the advantages of FlexRay-based communication, it
software can be reduced for both OEMs and ECU suppliers because the individual software modules can be delivered fully preconfig-
makes sense to fundamentally develop the associated basic software according to the AUTOSAR specification. AUTOSAR specifies a
ured by the software supplier. This lets developers place greater focus on innovations and the actual development of functions than
new development methodology, software architecture and basic software. OEMs may gradually introduce it step-by-step on new
was previously possible in development.
Embedded Architecture for FlexRay
Network management handles the coordination of all ECUs in the cluster with regard to communication needs for the bus system. If
The schematic schematic layout of FlexRay basic basic software from Vector is depicted in Figure 2. FlexRay-specific components such as the interface, driver, network management (NM), and transport protocol (TP) are all contained in the FlexRay stack. The driver abstracts
all of the bus nodes no longer have communication needs, the synchronous 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-
the hardware, making it possible to service different communication controllers (CC). The driver initializes the controller, sends and receives frames and detects controller errors. The interf ace communicates with the layers lying above it, processes PDUs (Protocol Data
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
Units) into frames and works in the reverse direction too. Moreover, it issues send and receive acknowledgments to the affected layers.
Freescale and from NEC. The driver is optimally adapted to the specific hardware used and utilizes its existing features while still
Figure 1: AUTOSAR layer model of ECU software with modular structure.
Figure 2: Schematic layout of FlexRay basic software from Vector.
1/39
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 systemRAM. 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
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 extension for transmission of measurement and calibration data. This
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 system parameters of an ECU. Due to the separation of protocol layer and transport layer, XCP can be operated in various types of communication 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
“load distribution” is per formed 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 different ECU in each send cycle. The measurement data are provided with a timestamp making it
turn enables signal exchange with the FlexRay interface (Figure 3). Due to dynamic bandwidth allocation, the driver must handle the
bandwidth is sufficient to transmit the data within a required time.
additional task of buffer configuration during measurement or calibration. Therefore, this module is replaced by an extended version
and reception buffers by allocating RAM for this communication. The RAM may be located in the controller or it may be necessary to
of the standard st andard AUTOSAR driver. XCP is an address-oriented protocol. Communication takes place between a controller component and a similarly structured software component in the XCP Master. Generally, the XCP Master is a
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
measurement and calibration tool (such as CANape from Vector)
reserved for XCP. Various scenarios are possible here:
possible to query measurement values at shorter intervals than the cycle time. For example, a measurement may occur ever y 2.5 ms, even if a system has a 5 ms cycle. It is only necessary to ensure that the
The ECU must reserve and dynamically configure transmission
Figure 3: Integration of XCP in the FlexRay stack with clear separation of protocol layer (XCP) and transport layer (FrXCP).
1/40
EMBEDDED SOFTWARE FOR FLEXRAY SYSTEMS
> 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 variables. The calibration tool uses the ECU description file to come up
Dirk Großmann (Graduate Engineer) studied electrical engineering at the University 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-11 +49-711/80670-111, 1, E-mail:
[email protected]
Oliver Kitt (Graduate Engineer) studied physics at the University of Stuttgart. As team leader he is responsible for the development of measurement and calibration protocols in CANape. Tel. +49-711/80670-327 +49-711/80670-327,, Fax +49-711/80670-11 +49-711/80670-111, 1, E-mail: oliver.kitt@v
[email protected] ector-informatik.de
with the link between the name and the physical address (Figure 4).
Universal support in all development phases The FlexRay developer gets universal universal support from the Vector company: From system description to implementation of the base software 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, calibration 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 t o be universal with AUTOSAR conformance, and can thereby be flexibly implemented.
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.
1/41
1
l
AUTOMOTIVE
2007
l
S P E C I AL
E D I T I O N
CANOE.FLEXRAY TO
FlexRay
SO LVE
BOTH
CHALLENGING
F L E X R AY
ENABLES R OUTINE
FLEXRAY
ENGINEERS AND
TASKS
Becomes Daily Routine More 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 article shows how engineers successfully meet the challenges of analyzing, simulating, and testing FlexRay ECUs and networks using CANoe.FlexRay from Vector.
D
uring the development of FlexRay ECUs and systems, engineers commonly encounter challenging 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 synchronize d their FlexRay clocks and provide sync frames
1/42
so that other ECUs can integrate into the TDMA (Time Division Multiple Access) schedule. If the FlexRay communication of a single non-startup/sync ECU is being tested, then the analysis tool needs to be able to simulate a FlexRay bus that has already started. CANoe.FlexRay can generate two startup/sync frames in order to provide this type of startup of a FlexRay bus. The startup phase of a cluster can be obser ved using the asynchronous mode of Vector’s Vector’s FlexRay interfaces VN3300 (PCI), VN3600 (USB) or VN7600 VN7600 (USB with CAN interfaces). It is possible for example to receive wakeup pattern, symbols, startup and normal frames before the cluster is in synchronous mode. The bus can also be analyzed in this mode without using a FIBEX
SPECIAL
database. Only the baud rate is required in order to initialize the bus interface. To startup a sleeping cluster, wakeup wakeup pattern and symbols can be sent. The synchronous mode is the default mode, in which frames can be sent. The asynchronous and synchronous modes can also be combined so that the interface changes its mode automatically according to the clock synchronisynchronization state giving FlexRay engineers full analysis and simulation features at all times.
EDITION
F LEXRAY
l
AUTOMOTIVE
2007
l2
Figure 1: The FlexRay Frame Panel makes it easy to interactively send FlexRay frames © automotive
ECU Test by Stimulation The easiest way of testing an ECU is to send frames interactively using CANoe’s FlexRay Frame Panel. Using this integrat ed panel a FlexRay frame’s frame’s payload (i.e. its signals) can be interactively modified during runtime. Signals for all bus systems can be modified via userdefined 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. arbitrary 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 Test by Observation During the development of any real ECU it is crucial to guarantee that the ECU communicates in conformance with FlexRay’s FlexRay’ s schedule table. Especially for fr ames in the st atic 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: Monitor 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 implemented in the programming language CAPL (also for the offline analysis). ECU Test by Simulation In 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-theLoop) 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 Matlab/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 controllers 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 environment or remaining bus simulation the execution platform must be deterministic. CANoe RT, RT, along with its hardware extensions RT Box and RT Rack, provides such a high performance 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 interfaces. For both CANoe and CANoe RT the same (simulation) models can be used.
Figure 2: The Cluster Monitor for displaying the send conformity of FlexRay nodes and their messages © automotive
Cluster Simulation In the early design phases of a FlexRay system it is important to test whether the timings are correct and/or the performance of an ECU matches the communication schedule. In other words, to check whether all frames can be received and transmitted in the reserved time. The FlexRay engineer therefore typically creates a (par1/43
3
l
AUTOMOTIVE
2007
l
S P E C I AL
E D I T I O N
F L E X R AY
Figure 3: CANoe RT is a real-time capable and deterministic deterministic execution platform © automotive
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 cluster FlexRay schedule schedule in the FIBEX database are used to configure the simulation of all required ECUs. All frames are automatically sent on the bus with default values. With VecVector’s 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 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, CANoe.FlexRay, any simulated node can participate at the network management layer according to the AUTOSAR-NM protocol. Gateway Simulation Gateways 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 simulating and analyzing gateway applications. A virtual gateway 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. Optionally the two FlexRay clusters can be synchronized. Syn1/44
chronously running clusters guarantee minimal delays between the signal occurrences on both buses. Summary All these application scenarios occur during the routine work of engineers developing FlexRay products. CANoe.FlexRay CANoe.FlexRa y is a powerful tool to help engineers in their everyday work when handling the new technical challenges of FlexRay buses. CANoe is the flagship of Vector’s comprehensive portfolio of tools and embedded softwar software e components which are ready for both current and future FlexRay applications.
Team Gavin C. Roge Rogers rs B.Eng. B.Eng. M.Sc. is Team Manager in the “Tools for Networks and Distributed Systems” product line.
Dr. rer Dr. rer.. nat. Carst Carsten en Böke is Senior Software Development Engineer for the “Tools “T ools for Networks and Distributed Systems” product line.
© Carl Hanser Verlag, München 2007. All rights including including reprinting, photographic reproduction reproduction and translation reserved by the publishers.
Case Study Testing Testing FlexRay ECUs effectively and reproducibly
The Customer
The Advantages
Bertrandt AG is one of Europe’s leading development part-
A high-performance and flexible environment for complex
ners in the automotive and aerospace industries. About
ECU tests over the FlexRay bus
5500 employees at 30 business sites in Europe and in the
For conducting the simulation, Bertrandt uses CANoe.FlexRay
USA work on customized solutions ranging from indivi-
together with CANoe RT and the Real Time Rack to implement
dual components and modules to complete systems and
a high-performance test system for FlexRay:
vehicles.
Testing an ECU with remaining bus simulation Testing is already possible in early development phases without
The Challenge Testing FlexRay ECUs effectively and reproducibly Proper 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 Solution
requiring availability of real ECUs. Using OEM-specific modules such as the t he Interaction Layer, Transport Protocol, checksum calculation, etc. in the remaining bus simulation Quick and easy implementation of the remaining bus simulation and st andardized 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 e xclusively on the Real Time Rack No disturbance of the simulation by the PC’s operating system.
ECU tests within a remaining bus simulation on a FlexRay
Real Time Rack is scalable Flexibly adaptable to future
test bench
test system requirements, e.g. number of FlexRay channels
Bertrandt created a special test system to conduct reproduc-
or modification for other bus systems.
ible testing of FlexRay ECUs. It contains a simulated vehicle environment that is implemented with an extensive and realtime 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 r un on the host computer of the test bench. The two computers are interconnected via Ethernet.
We would be glad to provide you with an individual quotation:
[email protected] www.vector.com
SPECIAL
EDITION
FLEXRAY
l
AUTO MO TIVE
FlexRay
2006
l1
To detect errors in the design of a FlexRay system
Sets the Pace
or schedule it is important to simulate the system early
in the development process. In choosing a simulation environment t h e F l e x R a y d e v e l o p e r s e t s d e m a n d i n g r e q u i r e m e n t s on s y s t e m c o m p o n e n t s t o p e r m i t r e a l - t i m e s i m u l a t i o n . T h i s a r t i c le s h o w s h o w t h e s e requirements are satisfied by a simulation platform based on the bus analysis, testing and simulation tool CANoe.FlexRay.
1/46
o support the time-critical data transfer a FlexRay simulation platform must be capable of generating periodic signals and messages at a high cycle rate. Additional requirements include: I the support of multi-rate systems with different cycle periods (Cycle Multiplexing) I constant and least possible jitter when activating and/or executing application code I short response times between receiving and sending of frames I permission of in-cycle responses.
T
communication controller should be automatically programmed 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 Figu gure re 1). (Fi
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 runtime 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 database format is essential so that users can utilize symbolic signal and message names from a relevant database. The
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
2
l
AUTO MO TIVE
2006
l
SPECIA L
Figure 1. 1. Example of undersampling and oversampling oversampling
EDITIO N
F L E X R AY
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 generated by the CANoe internal Realtime Workshop and a spe3). cial extension (Figure (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 transactionbased updating of multiple TX requests, in which either all or none of the send updates of a cycle are executed.
in an unsynchronized application © automotive
are missing. Any of the notifications may be limited to specific 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 enables detection of errors in the model or simulation platform in very early modeling phases. Support of the model To 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 implemented to enable reading and modification of signal values at any time. CANoe.FlexRay automatically receives and sends the associated FlexRay frames in background, whereby the send times are prescribed by the schedule in the database.
Dedicated simulation environment In simulating a model on hardware that is not real-time capable and on a nondeterministic operating system, interruptions and delays may occur in notification and execution under certain circumstances. This results in large and nondeterministic 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 requirements, CANoe benefits from its dual-PC architecture (Figu(Figure 4). 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 RealTime Client handles user interactions and the analysis section, while the Real-Time Server is responsible for executing 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 hardware, e.g. VN3300 from Vector Informatik. This combination is capable of task switching times less than 10 microseconds and response times of approx. 600 microseconds.
Figure 2. Examples of notification and activation time points in relation to the FlexRay schedule
© automotive
1/47
SPECIAL
EDITION
FLEXRAY
l
AUTO MO TIVE
2006
l3
Summary The presented real-time simulation system CANoe.FlexRay 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 adaptation effort is necessary. Its special simulation mechanisms and dual-PC architecture also make CANoe a convincing solution in projects with higher real-time requirements. All FlexRay solutions from Vector offer dedicated and special features that support the special properties of FlexRay systems optimally. (All Figures: Vector Informatik GmbH)
Figure 3. MA MATLAB/Simulink TLAB/Simulink support in CANoe © automotive
Dr. rer. nat. Carsten
is Senior Software Development Engineer for the “Tools for Networks and Distributed Systems” product line. Böke
© Carl Hanser Verlag, München 2007. All rights including reprinting, photographic reproduction and translation reserved by the publishers. Figure 4. Dual-PC architecture architecture of CANoe © automotive
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 optimized run-time environment is that the Real-Time Server is responsible for 100 % of the bus load of the FlexRay cluster.. Such a system is characterized by high update rates, ster short response times and constantly small delays and jitter. It enables simultaneous simulation of multiple ECU nodes, executes the models precisely synchronous to the communication cycle and handles in-cycle responses. Of course, in simulations with lower real-time requirements CANoe can also deliver excellent results on single-PC configurations under Windows 2000 or Windows XP. XP. Bus interfaces For bus access the simulation systems need high-performance interfaces that can be obtained from Vector. The VN3300 is a FlexRay interface for the PCI bus that i s especially 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. 1/48
1/49
Ef f icient Access Access to the FlexRay FlexRay Bus High-performance High-perform ance FlexRay FlexRay Hardware Hard ware for Anal y ysis sis and Simu Sim ula lation tion PC inter inter faces faces for var ious standards standards are indis in dispen pensa sable ble tools in all de vel de vel opment opment phases phas es of auto automo motive tive electron electronics, ics, wher ever ev er access access is needed needed to what is happen happen-ing on the bus. OEMs and suppli sup pliers ers are being be ing confront confronted ed with espe especial cial ly ly complex com plex chal lenges lenges with the cur rent rent intro in troduc duction tion of the FlexRay Flex Ray bus in first produc pro duction tion vehi vehicles. cles. Much more than on the CAN bus, high per formance formance hardware hard ware is a prereq prerequi uisite site for expe experi rienc encing ing reli re liaable oper oper ation in all situ situations and ful ly ly exploit exploiting ing the poten potential tial of software software tools for simu simula lation tion and anal y sis. sis.
The vari var ious tasks of FlexRay FlexRay devel devel opment opment and asso as soci ciat at ed ed tests rere quire inter interfa faces ces for both station stationary ary PCs and mobile mobile notebooks notebooks (Fig(Figure 1). In both cases, cas es, they need to sat isfy isfy special special require requirements ments for simu sim ula lation, tion, anal y ysis, sis, cal ibra bration tion and test ing. ing. For exam example, ple, an ECU’s standard stand ard control control ler ler recog recogniz nizes es when errors er rors occur, occur, but does not proprovide any infor informa mation tion what soev soever er on their causes. caus es. For a qual ified anal y ysis, sis, the devel devel oper oper needs – besides besides the FlexRay Flex Ray messa messages ges and signals sig nals themselves themselves – precise precise time stamps, compre com prehen hensive sive infor informa ma-tion and detailed de tailed itemi itemiza zation tion of all states on the bus and in the in terfa ter faces. ces. Compared Compared to previ previous ous auto automo motive tive bus systems, systems, techni technical cal require re quirements ments for FlexRay FlexRay are signif sig nif icant ly ly more stringent. stringent. Since
FlexRay’s oper FlexRay’s operaation is not event-driven, event-driv en, but instead instead is time-trigtime-trig gered, it is neces necessa sary ry to synchro synchronize nize all bus nodes. Send times are precise pre cisely ly speci specified by the cyclic cyclic and synchro synchronous nous time-divi time-division sion mul tiplex tiplexing ing TDMA (Time Divi Division sion Mul tiple tiple Access) Access) bus arbi arbitra tration. tion.
FlexRay Flex Ray Inter Inter faces faces for all Require Re quirements ments A new gener generaation of FlexRay FlexRay inter interfa faces ces deliv delivers ers the right solu so lutions tions for all sit uations occur occurring ring in practice. prac tice. In partic par ticu ular, one focus focus in their devel devel opment opment was a high level lev el of assur assurance ance of future future util ity. For exam example, ple, updates updates to the FlexRay FlexRay standard standard due to FPGA (Field Program Pro gramma mable ble Gate Array) Ar ray) technol technol ogy are fed-in by custom customers ers themselves them selves with driver driv er updates. updates. On the one hand, behav behavior ior of the FlexRay Flex Ray inter interfa faces ces from Vector Vector conforms con forms to the standard; standard; on the other, other, they are able to log all concon ceivaable bus events due to their supple ceiv sup plemen mental tal FPGA logic. logic. They record 100% of the bus traf fic fic of both FlexRay FlexRay channels. channels. The cencen terpiece ter piece – an Intel In tel PXA270 micro microcon control trol ler ler togeth together er with 8 MByte RAM – is support sup port ed ed by the Bosch E-Ray and Fu jit Fu jit su su MB88121B FlexRay Flex Ray commu communi nica cation tion control control lers. lers. Inter Interchange changeaable as plug-in modules, mod ules, electri electrical cal ly ly isolat isolat ed ed bus transceiv transceivers ers lend flexi flexibil ity to physiical bus access phys access with regard re gard to future future require requirements. ments.
Opti Op timized mized for Anal y sis sis
Fig ure 1: Figure Hardware Hard ware inter inter faces fa ces must al so so be imple implemen menta table ble in mobile mo bile FlexRay FlexRay appli applica cations. tions.
1/50
Overall, the inter Overall, interfa faces ces were opti op timized mized for the best possi pos sible ble inter interac ac-tion with the simu sim ula lation tion and anal y ysis sis tools CANoe CA Noe and CANa CANaly lyzer, zer, and the measure meas urement ment and cal ibra bration tion tool CANa CANape pe (Figure (Figure 2). The inter in terfa faces ces not only only recognize recognize all bus activ activiities and buff er er them as neces nec essa sary; ry; rather rather they al so so pass all infor in forma mation tion to the host. Dif ferferent than on control control lers lers for ECUs, the control con trol ler ler host inter interface face is dede-
signed to record all data, data, null and erro er rone neous ous frames as well as symsym bols, includ including ing the asso associ ciat at ed ed timestamps timestamps and pass them on to the soft ware ware tools. This is the only on ly way for devel devel opers opers to ana analyze, meaning mean ingful ful ly ly inter interpret pret and thereby there by system systemat at ical ly ly trouble troubleshoot shoot sources sour ces of errors. errors. If no FlexRay FlexRay synchro synchroni niza zation tion is estab es tablished lished or no FIBEX FI BEX data database base is avail able with TDMA param pa rameeters, an asynchro asynchro-nous bus anal y ysis sis is possi possible, ble, in which it is only only possi possible ble to fol low low events and log them in read ing oper operaation. In this mode, it is al so so possi pos sible ble to observe observe the startup star tup phase of a FlexRay FlexRay net work. work. The measure meas urement ment and cal ibra bration tion tool CANa CANape pe gives devel devel opers opers the abil ity to access access inter internal nal ECU param parameeters via the standard stand ardized ized XCP-on-FlexRay XCP-on-Flex Ray proto protocol. col. In this case, the FlexRay Flex Ray hardware hardware supsupports resyn resynchro chroni niza zation tion of the FlexRay FlexRay inter interface face if bus traf fic fic has been inter interrupt rupt ed. ed.
Maxiimum send Throughput Max Through put for Simu Simula lations tions The require requirements ments demand demanded ed by ECU simu simula lations tions on the PC, e.g. with CANoe, CA Noe, are signif signif icant ly ly great er er than those for anal y ysis sis mode. Since mul tiple tiple ECUs can be simu sim ulat ed ed simul simul tane taneous ously ly on a suf ficient fi cient ly ly fast comput comput er, er, the inter interface face must al so so be able to handle handle the higher higher data da ta throughput throughput while taking taking all timing timing require requirements ments into in to account. account. Paral Par al lel lel simu simula lation tion of ten or more ECUs is entire en tirely ly real real istic. istic. It is notewor note worthy thy that it only only takes one of the new FlexRay Flex Ray inter interfa faces ces to
achieve this. This perform per formance ance is ena en abled by the TX buff er er that has been extend extended ed to 2 MByte that can store over 1000 inde in depend pendent ent send messa messages. ges. Previ Previous ous solu solutions tions typi typical ly ly only only had an 8 KByte TX buff er. er. The CANoe CANoe RT plat form form is espe especial cial ly ly well-suit ed ed to small to mid-size pro jects with real-time real-time require requirements, ments, such as hardware-in-the-loop hard ware-in-the-loop simu sim ula lations. tions. It isolates iso lates visu visual iza zation tion and control control functions functions from the real-time re al-time simu simula lation. tion. The simu simula lation tion is exe execut ed ed trouble troublefree free on a sepaarate comput sep comput er er under under Windows Windows XP Embed Embedded, ded, and this guaran guar an-tees reli reliaable updates updates of send time points. The on ly inter interface face that comes into into consid consider eraation for this comput comput er, er, called a RT Box or RT Rack, is a fast PCI inter interface face such as the VN3300 (Figure (Figure 3). For mini minimal response response times and deter de termin minis istic tic timing timing behav behavior ior of the appli applica cation, tion, short laten la tency cy times and mini minimal jit ters ters are absolute ab solutely ly essen essential. tial. Besides Besides the time required re quired for the actu ac tual al comcomputa pu tations tions of the appli applica cation, tion, it is neces nec essa sary ry to add the times for transport trans port process processes es through the dif ferent ferent commu communi nica cation tion layers. layers. To achieve low PC loading load ing despite despite this sit uation, DMA (Direct (Direct Memo Memory Access) Access) was imple implement ment ed ed in the FlexRay FlexRay hardware. hardware. DMA ena enables high transmis trans mission sion rates r ates and simul tane ta neous ously ly relieves relieves the main propro cessor cess or and gives it more time for compu com puta tations. tions. Laten Latency cy times were
Fig ure 2: Figure Hardware Hard ware inter inter faces fa ces for the entire entire FlexRay FlexRay tool chain: Anal y sis, sis, simu simula la-tion, testing testing and softsoft ware modules modules as well as physiical gener phys gener ation of bus disturb disturban ances. ces.
1/51
optimized opti mized – as was al ready ready done on CAN inter interfa faces ces from Vector. Vector. The short est est laten latency cy times are system-de sys tem-depend pendent ent and can be at tained tained with PCI inter interfa faces. ces.
Intel ligent Intel ligent auxil auxil iary iary Functions Functions for every every day day Work of Developers Develop ers Experi Expe rience ence and custom cus tomer er require requirements ments on numer numerous ous FlexRay FlexRay propro jects moti mo tivat vat ed ed devel devel opers opers at Vector Vector to inte integrate grate a number number of other other impor im portant tant functions functions in the FlexRay Flex Ray inter interfa faces: ces: hardware hardware support support for PDUs, auto automat mat ical ly ly incre increment ment ing ing message message counters, counters, simu simula lation tion of inac in active tive ECUs, group updates updates and auton autono omous bus start capa capabil bil ity. To decou decouple ple the transport transport layer layer from the appli applica cations, tions, in the lat est est FlexRay Flex Ray net works works PDUs (Proto (Protocol col Data Data Units) have been intro in troduced, duced, instead in stead of working working direct direct ly ly with the rel evant bus-specif bus-specif ic ic data data concontainers. tain ers. Sever Several al such logi logical PDUs may lie within with in a FlexRay FlexRay frame. In this case, an addi ad dition tional al piece of infor informa mation tion is needed needed for each PDU, indi indicat cat ing ing whether whether or not the contents contents are val id id for the curcur rent cycle. cycle. One and the same PDU may al so al so be defined defined in mul tiple tiple frames. The PDU concept concept enhan enhances ces flexi flexibil ity and ena enables easy reuse re use of the appli ap plica cation, tion, but its disad disadvan vantage tage is that consid consider eraably more ef fort fort is required re quired to gener generate ate and decode decode the FlexRay FlexRay frames. Power Powerful ful FlexRay inter interfa faces ces compen compensate sate for this disad disadvan vantage tage by handling handling
Fig ure 3: Figure Stringent Strin gent require requirements ments are satis satisfied fied by the real-time re al-time capa ca pable ble and deter deter minis min istic tic CANoe CANoe RT runtime runtime platform. platform.
1/52
the mul tiplex tiplexing ing and demul demul tiplex tiplexing ing of the PDUs into in to and out of the frames on the hardware hard ware side. Hardware-based incre Hardware-based increment ment ing ing of a payload pay load area area serves to reli re liaably simu sim ulate a sender’s send er’s heart beat. beat. That is because, because, if it is not possi pos sible ble to guaran guarantee tee this gener gen eraation in a soft ware-based ware-based simu simula lation, tion, the receiv re ceiver er might re ject re ject the signal sig nal or even switch it self self off. The intel intel liligent hardware hardware prevents prevents this by repeat re peat edly edly sending sending the old signal signal val ues ues with counter counter incre increment ment ing, ing, thereby thereby reli reliaably signal signal ing ing that the sending sending device device is still “alive”. Simula Simu lation tion of inac inactive tive ECUs ena enables lat er er dele deletion tion and supple supplement ment ing of frames to be sent, even if the user us er has not yet defined de fined them at startup. star tup. The bus transceiv transceivers ers can be switched to inac in active tive (Sleep mode), aft er er which wakeup wake up pat terns terns are still detect de tect ed, ed, howe however. The bus transceiv transceivers ers can al so so active actively ly exe execute a wakeup. wakeup. If data data that belong belong togeth together er do not fit in a FlexRay Flex Ray slot, there is a risk that it might not be possi pos sible ble to consist consist ent ent ly ly transmit transmit the data data in two frames of the same cycle. cy cle. This is reme rem edied by a “group upupdate”, wherein wherein the inter in terre relat lat ed ed frames are al ways ways sent togeth to gether. er. To start up a FlexRay FlexRay cluster, cluster, it is neces nec essa sary ry to have at least two
Fig ure 4: Figure VN inter inter fa faces ces from Vector Vector ful fill fill the strict bus inter inter face require requirements ments imposed imposed by the FlexRay Flex Ray bus. The USB var iants VN3600/VN7600 are suita suitable for mobile mo bile appli appli-cations, ca tions, anal y ses ses and simple simple simu simula lations. tions. The PCI var iant VN3300 supports supports complex complex simu simula lations tions of mul tiple ti ple ECUs with real-time real-time require requirements. ments.
EF FI FI CIENT ACCESS AC CESS TO THE FLEX RAY BUS
ECUs that can exe ex ecute a startup. star tup. Some ECUs are not startup-ca star tup-capa pa-ble; they al ways ways inte integrate grate themselves themselves in the commu com muni nica cation tion aft er er a success suc cessful ful exter external nal startup. star tup. If a net work work line only only has these kinds of devi devices ces for the measure meas urement ment or simu sim ula lation, tion, the bus system sys tem cancannot be start ed ed up due to the lack of startup-ca star tup-capa pable ble nodes. ThereTherefore, a second second commu communi nica cation tion control control ler ler or startup star tup control control ler ler has been inte integrat grat ed ed in all FlexRay Flex Ray inter interfa faces. ces.
In the area ar ea of FlexRay FlexRay net working, working, Vector Vector of fers fers a univer universal sal tool chain, modu modular soft ware ware modules modules as well as inter in terface face hardware hardware and support sup port for specif specif ic ic pro jects and a training training program. program. The Stutt gartgartbased special special ist’s ist’s activ activiities as a Premi Premium um Asso Associ ciate ate Member Member of the FlexRay Flex Ray Consor Consorti tium um ensure ensure that advanced ad vanced devel devel opments opments and the lat est est proto protocol col speci specifi fica cations tions are al ways ways consid considered ered in the design design of tools and hardware hardware inter interfa faces. ces.
Inter In ter facing facing dedi dedicat cated ed Appli Applica cations tions with the Hardware Hard ware The new gener generaation of FlexRay FlexRay inter interfa faces ces from Vector Vector of fers fers highperform per formance ance hardware hardware solu solutions tions for the most signif sig nif icant PC plat forms and inter in terface face types. These inter in terfa faces ces are special special ly ly tailored tailored to the require requirements ments in simu sim ula lation, tion, anal y ysis, sis, cal ibra bration tion and test ing ing (Figure (Fig ure 4). The strengths of the USB vari var iants VN3600 and VN7600 lie in the mobile mo bile area. area. They are ideal ide al ly ly suit ed ed to anal y ysis sis and simple simple simu sim ula lations, tions, while the VN3300 PCI card is intend in tended ed for complex complex simu sim ula lations tions involv involving ing mul tiple tiple ECUs under under real-time real-time constraints. constraints. Current Cur rent ly, ly, FlexRay FlexRay buses buses are prima primari rily ly used togeth together er with exist ex ist ing ing CAN net works. works. The VN7600 FlexRay/CAN-USB FlexRay/CAN-USB inter interface face address addresses es this sit uation appro appropri priate ately ly with two FlexRay FlexRay channels channels and three CAN channels channels in one device. de vice. Devel Devel opers opers of FlexRay/CAN FlexRay/CAN appli applica ca-tions bene benefit from simul simul tane ta neous ous access access to both bus systems systems in anal yses y ses and simu sim ula lations tions with just one hardware hard ware module. module. The combined combined hardware hard ware solu solution tion for FlexRay FlexRay and CAN espe especial cial ly ly simpli simplifies fies precise precise synchro syn chroni niza zation tion of the dif ferent ferent bus systems sys tems with highly high ly precise precise time stamps and a common com mon time base. In this regard, re gard, a signif signif icant ly ly higher high er level level of qual ity is achieved compared compared to mul tiple tiple sepa separate solu so lutions, tions, since laten latencies cies must al ways ways be expect expect ed ed when USB is used for inter interfac facing. ing. A program programming ming library library of basic basic functions functions is supplied supplied with the FlexRay hardware. hardware. This makes it possi pos sible ble for dedi dedicat ed ed appli applica cations tions to access access the Vector Vector FlexRay FlexRay hardware. hardware. The “Advanced “Advanced FlexRay FlexRay Driver Driver Library” Li brary” is avail able for extend extended ed functions. functions. The devel devel oper oper uses uses this library li brary to access access extend extended ed functions functions of the inter interfa faces, ces, such as the second sec ond commu communi nica cation tion control control ler, ler, extend extended ed TX buff er er and auto automat mat ic payload payload incre increment. ment.
Summa Sum mary ry FlexRay places FlexRay places dispro dispropor portion tionate ately ly great er er demands demands on hardware hard ware and soft ware ware than CAN or LIN net works, works, for exam example, ple, due to its time-triggered time-trig gered transmis transmission sion method method and consid consider eraably higher higher transtransmission mis sion rates. Here, the timing tim ing behav behavior ior of the hardware hardware has a deci deci-sive influ influence ence on the qual ity of soft ware ware servi services that can be propro vided. vid ed. Signif Signif icant perform per formance ance increas increases es are real real ized ized by transfer transfer-ring soft ware ware functions functions to the hardware. hardware.
Dr. Car sten sten Böke studied stud ied Infor Informa mation tion Technol Technol ogy at the UniUniversi ver sity ty of Pader Paderborn. born. From 1995 to 2004, he was employed employed as a scien sci entif tif ic ic assist assist ant ant at the Heinz Nixdorf Nixdorf Insti Institute tute in the area area of Paral Paral lel lel Systems Sys tems Design. Design. While there he was prima primari rily ly involved in volved with auto automat mat ic ic config configu ura ration tion of emembedded bed ded commu communi nica cation tion systems. systems. Since 2004 he has been employed employed as a Senior Senior Soft ware ware Devel De vel opment opment Engi Engineer neer at Vector Vector Infor Informa matik tik GmbH, where he devel devel ops ops tools for bus anal ysis y sis and bus simu sim ula lation tion of FlexRay FlexRay systems. systems. Al fred fred Kless studied stud ied Electri Electrical cal Engi Engineer neering ing at the Techni Techni-cal Col lege lege of Esslin Esslingen. gen. From 1991 to 2004, he worked in the area ar ea of Test System Sys tem Devel Devel opment op ment at the compa company ny ALCA ALCATEL. TEL. Since 2004, he has held the posi po sition tion of Business Busi ness Devel De vel opment opment Mana Manager at Vector Vector Infor Informa matik tik where he is respon responsi sible ble for the product product lines “Net work work Inter Interfa faces” ces” and “Measure “Measurement ment and Cal ibra bration”. tion”.
Mar tin tin Goßner studied stud ied Comput Comput er er Engi Engineer neering ing at the Techni Techni-cal Col lege lege of Ulm. Since 1998, he has been employed em ployed in the “Net work work Inter Interfa faces” ces” area area at Vector Vec tor Infor Informa matik tik GmbH. Since 2000, he has been team leader leader for driver driver and firmware firmware devel opment. opment. As a product product mana manager, he is responsi respon sible ble for Vector Vector FlexRay FlexRay inter interfa faces. ces.
1/53
24
l
A U T O MO T I V E
FLEXRAY
2008
l
SPECIAL
EDITI ON
F L E X R AY
TOOLS
SUCCESS FULLY SUPPORT DEVELOPMENTS BASED
WITH
PDU-
COMMUNICATIONS
AUTOSAR PDUs
Conquer FlexRay A u d i i s u s i n g F l e x R a y i n t h e i r n e w e s t v e h i c l e s . T h e d e v e l o p e d F l ex Ray network communication uses PDUs (Protocol Data Units) that are fully AUTOSAR compatible. PDUs are logical data containers for exchanging signals between applications and all owing greater d e c o u p l i n g f r o m t h e u n d e r l y i n g c o m m u n i c a t i o n s y s t e m. A u d i b e n e f i t e d i m m e d i a t e l y f r o m Ve Ve c t o r ’ s C A N o e a s a b u s a n a l y s i s a n d s i m u lation tool which can natively handle PDUs.
W
ith the release of the frame-oriented FIBEX 2.x database format, a new description semantic was needed to define PDU communications between network nodes. To overcome this gap, Audi successfully developed the FIBEX+ description semantic. Vector was able to immediately support FIBEX+ in its tools. Profiting from their experiences with FIBEX+, Audi introduced PDUs into the new FIBEX 3.0 standard from ASAM (Association for Standardisation of Automation and Measuring Systems [1]). Continuous feedback from Audi enabled Vector engineers to integrate important PDU features during the early phases
1/54
of tool development. Service Packs were delivered regularly to Audi, thus, allowing early testing of ECUs with PDU communication stacks. Audi delivered their latest FIBEX+ database versions to Vector in order to ensure CANoe’s continuous compatibility. Close collaboration between Audi and Vector accelerated the tool development and led to a professional analysis and development platform for FIBEX+ and the new FIBEX 3.0 based FlexRay networks. This article illustrates the impact PDUs have on the internal structure and features of a FlexRay development tool CANoe.FlexRay and how Audi engineers benefit from appropriate tool support.
SPECIAL
PDU Layer for Network Analysis PDUs are managed by tools for analysis, simulation, and test as high-level communication data containers (e.g. messages) containing signals. A FlexRay frame can contain several PDUs. Since the layout of a frame can also change from cycle to cycle, the same PDU can be mapped to multiple frames. PDUs are uniquely identifiable by their position in a FlexRay frame in a specific slot during a specific cycle. Vector identifies PDUs in CANoe 1). The PDU via the PDU Layer (Figure (Figure 1). Layer introduces PDU objects and is located between the bus and the user interfaces, respectively. The layer is enabled or disabled according to the assignment of an appropriate database (FIBEX+ or FIBEX 3.0) to CANoe. If the layer is enabled, then the complete symbolic database interpretation (PDU names, signals, timings, etc.) of the network communication is performed at PDU level. The PDU’s main property, which is defined by the Update Bit, is decoupled from the frame’s occurrence on the network. Thus, frames on the network may contain updated and non-updated PDUs at the same time. Update Bit values can be visualized as pre-defined signals or can be evaluated (e.g. in the graphics window, 2). As a default for simple anasee Figure 2). lysis or simulation received PDUs, which have not been updated, are ignored. For a detailed analysis, however, non-updated PDUs can optionally be displayed and passed on to the simulated nodes. In addition, FlexRay frames including their payload can be displayed and received as socalled Raw Frames. Such PDU-based analysis features were heavily used by Audi during their integration tests.
EDITION
F L E X R AY AY
l
A U T O MO T I V E
2008
l 25
Figure 1: CANoe’s Architecture with Abstraction Layers for Signal and PDU Handling and Sending Behaviour (IL).
© automotive
Figure 2: CANoe’s visualization of PDU’s Update Bits in Graphics and Trace. © automotive
PDU Layer for Network Simulation Although the FlexRay protocol defines frames to be transmitted cyclically (even without any update), native PDUs do not have this property. If a PDU is not updated, the receiver will normally not recognize the PDU. In order to trigger the receiver cyclically, PDUs must be updated periodically. If the automatic transmission of PDUs with the Update Bit set (i.e. without any explicit data update) is required, then the network designer can define these PDUs to have cyclic 3) timings. For this reason an Interaction Layer (see Figure 3) on top of the PDU Layer was developed to handle those constraints. As an extension to the FlexRay protocol, PDUs may also be sent cyclically with (nearly) arbitrary periods with set Update Bit (without being updated).
Message counters and check sums were defined by Audi as additional but optional validity attributes of a PDU. In fact, the Update Bits, message counters, and check sums of a PDU are set independently from the application in CANoe by the Interaction Layer in order to simplify the remaining bus simulation. Thus, the engineer can concentrate on setting appropriate signal values. A further use case is the insertion of explicit failures into the remaining bus simulation in order to test an ECU’ ECU’s s reaction. Therefore every automatic feature in CANoe can be disabled and the Interaction Layer can be used for fault injection. A simulation of communications with an ECU depends on the occurrence of specific events (event-based simula1/55
26
l
A U T O MO T I V E
2008
l
SPECIAL
EDITI ON
F L E X R AY
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
tion). One of the most important events is the reception of messages or changes in signal values from the bus. As such, notification handlers for PDU reception and signal changes are triggered by the PDU Layer.
Performance Aspects The additional (but mandatory) PDU Layer does create some overhead. When receiving FlexRay frames, PDUs have to be extracted from the frame and then forwarded to their notification handlers in the application. The same PDU can be contained in different frames. Thus, a sort of de-multiplexing of PDUs from frames is implemented by the PDU Layer. These procedures are highly optimized. On transmitting PDUs, they must be stored in the appropriate frame. The PDU can be located in different frames according to the current (cycle) time or a different set of PDUs may be contained in the frame. This results in a highly time-dependent multiplexed mapping of PDUs to FlexRay frames. If this is not fast enough, then frame slot misses should be expected. For maximum performance, Vector has implemented those functions to run on the hardware for the FlexRay bus interfaces of the VN series.
in CANoe’s Test Test Feature Set for PDUs. Additionally, for stimulus and response observations, PDUs can be sent interactively (PDU Panel) by implicitly manipulating signals (Input Panels), higher level protocols (transport, diagnostics), or by a remaining bus simulation (CAPL, MATLAB models, etc.).
Conclusion PDU-based communications will not only be used in migration scenarios, e.g. when porting applications from CAN to FlexRay networks, but also for new FlexRay developments. Audi has strongly influenced the development of FIBEX 3.0 based on lessons learned with FIBEX+. Vector’s experience with FIBEX+ allowed the quick support of the new FIBEX 3.0 standard with CANoe. As communications become more complex and extensive, appropriate modelling standards (i.e. FIBEX 3.0 and/or AUTOSAR), as well as their professional tool support, are essential requirements for an efficient FlexRay development. Literature: [1] www.asam.org
Testing PDU-based Networks Audi and its Tier1 suppliers also benefited from CANoe’s AUTOSAR features. This includes a check for communication conformance in order to test the AUTOSAR communication stacks (especially the PDU Router) of the ECUs. Here it is of great importance to be able to compare the real bus entities (Raw Frames) with the symbolic interpretation (PDU abstraction level). This helped the Audi engineers to identify in early phases an incorrect PDU or Update Bit position in the raw FlexRay frames. Tests can be split into two categories: First the application’s transmission behaviour can be checked with respect to updated PDUs and secondly, a signal’s integrity can be verified according to the application. Audi‘s engineers have successfully detected incorrect PDU update timings in early development phases. These tests are fully supported
1/56
© Carl Hanser Verlag, München 2009. All rights including reprinting, reprinting, photographic reproduction reproduction and translation reserved by the publishers.
Dipl.-Ing. (FH) Wolfgang Brandstätter is Hardware and Protocol Engineer for FlexRay; AUDI AG, 85045 Ingolstadt, Germany
Dr. rer. rer. nat. Carsten Böke is Senior Software Development Engineer for the “Tools for Networks and Distributed Systems” product line; Vector Informati Informatik k GmbH, 70499 Stuttgar Stuttgart, t, Germany
1/57
22
l
A U T O MO T I V E
2 0 0 9
l
SPECIAL
EDITIO N
F L E X R AY AY
Beyond FlexRay REQUIREMENTS ON A MODERN DEVELOPMENT ENVIRONMENT
The FlexRay communication bus and the FIBEX database exchang e format represent the current state-of-the-art of in-vehicle networking. In this context, the FlexRay bus must fulfil requirements related to remaining bus simulation, diagnostics and high er protocols, testing and AUTOSAR development methodology, over the entire development process.
T
hese requirements are fulfilled by FlexRay development tools quickly and extensively, sometimes in completely new ways. This article discusses the requirements that need to be met for an effective development platform. It addresses special requirements of the FlexRay bus for remaining bus simulations, higher-level protocols, diagnostics, highly specialized tests and AUTOSAR development methodology.
Quick and reliable simulation of ECUs In the development process of an ECU, it is essential to be able to operate the ECU before it i s integrated in the total system. The other ECUs of the FlexRay network must therefore be simulated as communication partners. This is referred to as a remaining bus simulation. The strict time requirements associated with FlexRay are very difficult to maintain; often simulations on the FlexRay bus are non-deterministic in their execution. The resulting slot misses result in oversampling or undersampling of data on the bus. Therefore, it is often urgently recommended that these simulations be executed on a dedicated, jitter-free and deterministic (real-time capable) platform. Available solutions include expensive HiL systems and difficult
1/58
Figure 1: CANoe RT RT is used to simulate simulate or test ECUs in real time. ©
auto motive
SPECIAL
EDITI ON
FLEXRAY
l
AUTOMOTIVE
2009
l 23
to implement rapid prototyping platforms. Nevertheless, there is an effective and cost-saving solution specifically designed for remaining bus simulations in testing: execution of the simulation on the hardware interfaces of the bus simulation or analysis tools being used. For example, in the case of CANoe RT (figure (figure 1), available on the high-end interface VN89xx (mid 2010), the user can run a simulation of the total system in real-time, or he uses a FlexRay interface from Vector to execute the simulation for one ECU. These solutions are seamlessly integrated in the simulation and test tool CANoe. This means that developers can always use the same platform and the same code, regardless of whether Figure 2: A powerful module concept is available for CANoe.FlexRay that lets they are implementing a pure users integrate additional protocols as well as application-specific and communisimulation or remaining bus cative control of simulation behavior. © auto motive simulation, or whether they are testing real ECUs on the bus. The tools and platforms offer additional functions for a used in dedicated programs or scripts via internal interfaremaining bus simulation as well. For example, the send ces. This allows developers to influence and have an behavior of ECUs is automatically modified (Interaction access to communications by program control. Layer) based on global system states (e.g. ignition on/off). Alive counters are incremented and supplemental checkTesting by diagnostics sums are already computed autonomously. This allows deAccess to an ECU’s diagnostic functionality is very imporvelopers to focus fully on development or testing of the tant, especially in early phases of the development proapplications applica tions of their ECUs. Naturally, Naturally, in the case of testing it cess, e.g. for reading out fault memory or for flashing. Since is also possible to inject errors error s on the communication level. diagnostics normally access an ECU via a CAN bus, a CANFlexRay gateway is needed for a FlexRay ECU. However, Protocols on higher layers such a gateway is generally unavailable in early developECUs not only exchange signals such as vehicle speed and ment phases. That is i s why CANoe’s Diagnostic Feature Set oil temperature, they also communicate via protocols on and the measurement and calibration tool CAN-ape support higher layers of the ISO OSI model – such as transport prodirect access to the diagnostic data over the FlexRay bus 3). Special transport protocols for FlexRay (AUTOtocols, network management protocols, in flashing or cali(figure 3). brating. During normal operation of the ECU, such protoSAR, ISO and OEM-specific variants) are supported in this cols are needed to coordinate bus communication. In sercontext. vice phases, the protocols are used to evaluate or update After loading the diagnostic di agnostic description databases in CANthe ECUs. The ECUs of a specific OEM each have their own dela or ODX format, diagnostic dialogs and functions are characteristics, e.g. of a transport protocol i ncluding OEMavailable in CANoe and CANape. For example, this allows specific modifications. Modern development tools must reading out the fault memory and displaying it including not only be able to analyze or represent the basic data on symbolic interpretation of the trouble codes. In addition, the FlexRay bus based on the FIBEX description but also the diagnostics console is used to symbolically send and evaluate the mentioned protocols and transmitting inforevaluate all diagnostic requests, including their responses mation through them. These functionalities are provided i n and parameters. Diagnostics communication is displayed 2). the form of add-ons or plug-ins (figure (figure 2). in its domain-specific notation in traces. A dedicated diaA modern modular approach to development tools enables gnostics-API is also available, which enables easy access re-use of plug-ins in different tools and seamless integrain programming, testing and tool control. tion in the tool itself. itself . Ideally, extensions are integrated as if they were a native component of the tool. Protocol extenA simpler way to create ECU tests sions provide special dialogs for setting and querying paraFrequently used standard tests often run according to the meters of the protocols. The functions of plug-ins can be same scheme. Therefore, a test tool should support fre-
1/59
24
l
AUTOMOTIVE
2009
l
SPECIAL
quently recurring test patterns. For CANoe, it is very easy to create sequential tests and test steps using the Test Automation Editor . Prepared or user-specific libraries are linked 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 algorithmically. This makes it possible to execute loops or branching based on the results of prior tests. Static and algorithmic tests may be combined. Along with stimulation tests, the bus communication can simultaneously be monitored regarding the FlexRay protocol. This includes detection of null frames and erroneous frames as well as monitoring of the frame period, response time behavior etc. Monitoring activities are performed by so-called observational checks, which are already contained in CANoe and only need to be activated and parameterized before use. For Hardware-in-the-Loop or environment simulations, it is frequently necessary to connect the ECU to its real sensors and actuators. The digital and analogue input and output variables must be provided or read-in. The “VT System” by Vector was developed for this purpose and for open-loop simulations and tests. It provides automotive-capable I/O ports that can be integrated easily in tests. Unlike general digital or analog I/O cards, the system can selectively switch between connection of an original load or original sensor or else a suitable simulation of the input or output. At the same time, large voltage ranges and currents can be handled by suitable signal conditioning. This also makes it possible to simulate faulty behavior of a sensor or actuator or a short circuit.
Testing AUTOSAR-functionality in FlexRay systems In the AUTOSAR design methodology, communication as a basic service for the application is transparent. In the framework of the overall system, communication is defined in the t he “AUTOSAR System Description”. If an AUTOSAR-ECU needs to be tested simply and quickly, the test tool has to know the communication description for the ECU. It is more user-friendly to directly read in t he “AUTOSAR System Description” rather than the FIBEX databases. This will be supported by CANoe.FlexRay. Key concepts in the AUTOSAR context are: “Software Components” (SWCs), “Runtime Environment” (RTE) and “Virtual Functional Bus” (VFB). Even if the ECU does not physically exist yet, it must still be possible t o test its “Software Components”. For this purpose, the “DaVinci Component Tester“ is able to integrate t he real ECUs code of a SWC in the test environment. CANoe provides the RTE, VFB and basic software. The test is executed with the wellknown functions of CANoe, including the automatic creation of a test report.
EDITION
Figure 3: CANoe.FlexRay directly accesses the ECU’s diagnostic functions over the FlexRay bus. © auto motive
systems require a powerful analyzing capability to test the internal communication between the SWCs. Therefore, the test tool needs access to the communication on the VFB. This is usually done via XCP-on-FlexRay. XCP-on-FlexRay. But especially extensive testing needs a higher performance. Therefore, the coupling of the control unit with the test environment CANoe is done via a JTAG or Nexus debug port. Only in this way parameters of the VFB, RTE or basic software (BSW) of a real AUTOSAR ECU can be read-in and calibrated quickly. This will be done by connecting the VFB of the real ECU to the test environment CANoe. Thus, the testing and analyzing at the ECU-internal interfaces of the SWCs can be done quite similarly in future, as today at the external control connections of an ECU. If the requirements described are realized in a sophisticated way in the development tools and in the implementation of FlexRay systems, FlexRay networks can be developed more efficiently than CAN networks.
Outlook In future, the number of AUTOSAR ECUs and the number of included SWCs will grow rapidly. These complex © Carl Hanser Verlag, München 2009. All rights including reprinting, photographic reproduction and translation reserved by the publishers.
1/60
FLE XRAY
is Senior Software Development Engineer for the Tools for Net- works and Distributed Systems product line at Vector Informatik GmbH. Dr. rer. nat. Carsten Böke
@
Vector Informatik GmbH www.vector.com
1/61
Serr ial Bus Systems Se Systems in the Auto Automo mobile bile Part 5:
MOST for transmis transmission sion of mul time timedia dia data data A premi premium um class car is growing grow ing to resem resemble ble a mobile mobile of fice. fice. In response response to custom customer er demand, demand, increas increasing ing numbers numbers of enter enter tainment tain ment and infor infor mation mation media media that are making mak ing their way into in to auto au tomo mobiles. biles. The most signif sig nif icant chal lenges lenges in this ar ea ea are, first, to keep wir ing ing expense expense as low as possi pos sible, ble, and second, sec ond, to ful ly ly satis satisfy fy the heighten heightened ed function functional al require requirements ments of an info info-tainment tain ment system system in the car. As a result, re sult, the MOST (Media (Media Orient Oriented ed System Sys tem Transport) Transport) bus system system is now used to transmit trans mit audio audio and video vid eo signals signals in approx. approx. 50 model model series. series.
Electronics Electron ics is respon responsi sible ble for a large number num ber of inno innova vative tive safety safety and conve convenience nience functions functions in auto au tomo motive tive technol technol ogy. Experts Experts prepredict that in just a few years elec tron tronics ics will repre rep resent sent a share of up to 30 percent percent of vehi vehicle cle val ue, ue, and the worldwide worldwide market market for elecelectronics tron ics in cars will grow by approx. ap prox. 6 percent percent annu annual al ly ly to 230 bil lion lion euros eu ros by the year 2015. The auto automo motive tive indus industry try is forecast forecast to exexhibit hib it rapid rapid growth rates, above all in the info in fotain tainment ment area, area, given given the contin continu ual ly ly increas increasing ing vehi vehicle-kil cle-kil ome meters ters on Germa Ger many’s ny’s roads (accord (ac cording ing to DIW [1] approx. approx. 700 bil lion). lion). The aver average age cit izen spends about 270 hours in a car annu an nual al ly, ly, whether whether it is on the way to work, shopping shopping or vaca vacation. tion. Over the course of time, the car ra dio was supple supplement ment ed ed by the CD and MP3 player. player. This came to include in clude CD changers chan gers and navi nav iga gation tion devi de vices, ces, and final final ly ly display display screens al so so made their way into in to cars for replay replaying ing DVD and video video films. Moreover, Moreover, hands-free Blue Bluetooth units with inte in tegrat grat ed ed micro microphones phones and iPod iPod control control are gradu gradual ly ly turning turn ing the cockpit cockpit a mul time timedia dia center, center, in which all of the play lists and direct di rect ories of a digi digital MP3 player player can be displayed dis played and start ed ed direct direct ly ly on the in-vehi in-vehicle cle display. display.
The al ready ready exten extensive sive wiring wir ing cost and ef fort fort are increas increasing ing due to contin con tinu ual growth in net working working of contin continu ual ly ly higher higher perform per formance ance info in fotain tainment ment devi devices ces of dimen dimensions sions that can hardly hard ly be managed managed any longer. Fortu For tunate nately, ly, some auto automo motive tive OEMs recognized recognized the adad vanta van tages ges that bus net working working would al so so of fer fer in this area ar ea early early on. In the mid-1990s, BMW and Daimler Daim ler began began to devel devel op op a uniform uniform commu com muni nica cation tion technol technol ogy for seri serial al transmis transmission sion of audio audio and video signals signals in the vehi ve hicle cle based on the D2B bus (Digi (Digital Data Data Bus) devel de vel oped oped by Mat sushi sushita and Phil ips. ips.
MOST Coop Cooper er ation In 1998, BMW, Daimler, Daim ler, Harman/Beck Harman/Becker er and SMSC (former (for merly ly OASIS OASIS Sil icon conSys Systems) tems) founded founded the MOST Coop Cooper eraation [2]. Since that time, MOST has estab established lished it self self as a de-facto de-facto standard standard for the transmis transmis-sion of mul time timedia dia data data in the vehi vehicle cle – the MOST Coop Cooper eraation is made up of 15 inter in terna nation tional al auto automo motive tive OEMs and more than 70 dedevice produc producers. ers. The user user organ organiiza zation tion laid the founda foun dation tion for success success of the technol technol ogy by defin de fining ing an exten extensive sive speci specifi fica cation. tion. Version Version 2.5 of the MOST speci specifi fica cation tion has been in exis existence tence since Octo October ber 2006. It is orga organized nized into into the are areas of Appli Applica cation, tion, Net work work and Hardware. Hardware.
Fig ure 1: Figure Structure Struc ture of a MOST de vice de vice that among other other things hosts the “Audio “Au dio Disk Play er” er” function functional al block. For system system manage management, ment, the Net Block is manda mandato tory ry for each MOST de vice, de vice, and system system functions func tions are manda mandato tory ry for each function function block.
1/62
The “Appli “Applica cation” tion” area area describes describes a logi logical device device model model based priprimari ma rily ly on ob ject-ori ject-orient ent ed ed methods, methods, with the purpose purpose of transpar transpar-ent model model ing ing and control control of distrib distribut ut ed ed info infotain tainment ment systems. sys tems. FurFur thermore, ther more, it defines defines a hier hi erarch archiical commu communi nica cation tion model model as well as serviices for mana serv managing an info infotain tainment ment system. sys tem. The “Net work work secsection” describes describes the MOST Net work work Inter Interface face Control Control ler ler and its servserv ices, net work work manage management, ment, and handling handling of data data transport transport in a MOST system. system. The “Hardware “Hardware section” section” deals with aspects as pects of the hardware hard ware structure structure of a MOST device. de vice.
Function Func tional al model model ing ing A MOST device device is subdi subdivid vided ed into into a function functional al level level and a net work work level lev el (MOST Net work work Inter Interface). face). On the function functional al level, level, info infotain tain-ment function functional al ities are embod em bodied ied in so-called function func tion blocks. Each function function block, e.g. the Audio Audio Disk Player, Player, provides provides the MOST net work work with a dedi ded icat ed ed set of functions, functions, e.g. “Track posi position”, tion”, that can be accessed accessed by oper operaation types such as “Set” for set ting ting a track or “Set Get” Get” for set ting ting and reading read ing a track (Figure (Figure 1). Functional Function al address addresses es (FBlockID, (FBlockID, FktID) are assigned assigned to both the function func tion blocks and to the functions func tions provid provided ed by a function function block. They can be taken tak en from the so-called “Function “Func tion Cat alog”, as can the identi iden tifi fiers ers of the oper operaation types. For exam ex ample, ple, the “Audio “Audio Disk Player” Play er” FBlock has FBlockID=0x31 FBlockID=0x31 and the “Track Posi Position” tion” function function has FktID=0x202. The sepa separa ration tion of function function and net work work and function functional al model model ing ing make it possi possible ble to imple implement ment a function func tional al commu communi nica cation tion model model that is ful ly ly inde independ pendent ent of physi physical compo components nents (MOST devi de vices). ces). Therefore, There fore, it does not mat ter ter which of the MOST devi devices ces is used to contain con tain a specif specif ic ic function. function.
commands are used for control commands con trol commu communi nica cation. tion. Their core compo compo-nents are the FBlockID, FBlockID, FktID, Oper Operaation Type and up to 65535 useful use ful bytes.
System Sys tem manage management ment The Appli Applica cation tion section section defines defines higher-lev higher-level el function function blocks and functions func tions for system system manage management. ment. System System functions functions include include the “FktIDs” function function (FktID=0x000) that is used to query que ry the functions functions support sup port ed ed by a function function block, for exam example. ple. The “Noti “Notifi fica cation” tion” syssystem function function (FktID=0x001), on the other other hand, ena enables crea creation of the “noti “notifi fica cation tion matrix” matrix” for a function function block. Emerging Emerging from the “noti “no tifi fica cation tion matrix” matrix” is infor in forma mation tion on which MOST device de vice should be noti notified fied if a certain cer tain proper property ty of a function function block has changed. This mecha mech anism prevents prevents an unnec unneces essary sary increase increase in bus load in the MOST system. system. To query query its function function blocks and address ad dresses, es, each MOST device de vice has the “Net Block” (system) (system) function function block with FBlockID=0x01. FBlockID=0x01. The function func tion blocks can learn about the function func tion blocks imple implement ment ed ed on a MOST device de vice using using the FBlockIDs FBlockIDs function function (FktID=0x000). The FktIDs 0x002, 0x003 and 0x004 are used to find the physi physical adaddress, logi logical address address and group address address of a MOST device. de vice. The Net work work Master Master plays an impor important tant role in the manage man agement ment of a MOST system. system. It is respon re sponsi sible ble for the system sys tem start and manage man age-ment of the “Central “Central Regis Registry”. try”. This regis reg istry try contains contains the logi logical address ad dresses es of the MOST devi de vices ces imple implement ment ed ed in a MOST system sys tem and the address addresses es of function function blocks contained contained in the MOST devi de vices. ces.
Hier Hi er archi archical commu communi nica cation tion model model MOST systems systems are pat terned terned on a three-stage hier hi erarch archiical control control philos phi loso ophy based on the “Master-Slave “Mas ter-Slave princi principle” ple” (Figure (Figure 2). Placed at the upper uppermost most hier hierarch archiical level level is the HMI (Human (Hu man Machine Machine Interface), Inter face), an exposed exposed control control ler ler that provides provides the user user with overover all function functional al ity. On the middle mid dle hier hierarch archiical level level are the usual usual concontrol lers. lers. They cover cover part of the system sys tem function functional al ity, and they share their partial par tial system system knowl edge edge with the HMI as the “System “Sys tem Master”. Master”. The lower lowermost most hier hierarch archiical level level is made up of the system sys tem slaves, whose functions functions are used by one or more control con trol lers. lers. They are not equipped with any system sys tem knowl edge, edge, and this substan substantial tial ly ly enenhances their flexi flex ibil ity with regard regard to config configu ura ration. tion. It is easy to add system system slaves or remove re move them from a MOST sys tem. MOST
Fig ure 2: Figure Hier Hi er archy archy of a MOST system sys tem
1/63
MOST Network Network Inter Inter face face The MOST Net work work Inter Interface face (Figure (Figure 3) ensures ensures that the function function blocks housed on the vari var ious MOST devi devices ces are capa capable ble of real real comcommuni mu nica cation tion with one anoth an other. er. The MOST System Sys tem Servi Services (Low Level Level System Sys tem and MOST Net work work Servi Services) provide provide the commu communi nica cation tion function func tional al ities needed needed to transport trans port all mul time timedia dia rel evant data data (time-contin (time-con tinu uous bit streams, packet packet data data and control control data). data). Low Level Lev el System System Servi Services (Layer (Layer 2 servi services) are imple implement ment ed ed in hardhardware (Net work work Inter Interface face Control Control ler ler – NIC) and are placed over the Physiical Layer. Phys Layer. MOST Net work work Servi Services, which encom en compass pass the Transport Trans port Layer Layer in the form of Basic Ba sic Layer Layer System System Servi Services and higher higher manage management ment in the form of an appli ap plica cation tion socket, socket, are housed on an exter ex ternal nal Host Control Con trol ler ler (EHC) and control control the NIC. It must be en sured that the EHC can serve the time-crit ical parts of the Net work work Inter Interface. face. Over time, with the progres pro gressive sive devel devel opment opment of MOST technol tech nol ogy from MOST 25 to MOST 50 and MOST 150, this archi ar chitec tecture ture has now enencountered coun tered its limits. lim its. In new devel devel opments, opments, INIC INIC (Intel (Intel ligent ligent Net work work Inter Interface face Control Control ler) repla replaces ces NIC. While INIC IN IC assumes assumes control control of exe execu cution tion of timecrit ical portions por tions of the net work work driver driver of the EHC, just a rel ative tively ly small part of the net work work driver driver still runs on the EHC, which essen es sen-tial ly ly repre represents sents a socket socket for the appli ap plica cation. tion. The INIC INIC archi architec tecture ture thereby there by relieves relieves the load of the EHC. For control, control, the INIC INIC provides provides the EHC or MOST API (MOST Net work work Servi Services) with a function func tional al ininterface, ter face, the so-called INIC-API. INIC-API. The functions functions of the INIC IN IC are encap encap-sulat su lat ed ed in a function function block (FBlock INIC). INIC).
MOST Network Networking ing MOST technol technol ogy ena enables transmis transmission sion of contin continu uous bit streams (bit streaming) streaming) without without buff ering er ing or unnec unneces essary sary overhead. overhead. This ininvolves having having a special special ly ly desig designat nat ed ed MOST device device (Timing (Timing Master) Mas ter) feed the MOST frame (Figure (Figure 4) at a fixed frequen frequency cy (44.1 KHz or 48 KHz) into into the transmis trans mission sion medi medium, um, which is typi typical ly ly opti optical. cal. In a MOST25 system, sys tem, the MOST frame provides pro vides 60 streaming streaming chanchannels at 8 bits (or 15 quadlets quad lets of 4 bytes each) for transmis transmission sion of contin con tinu uous bit streams (source data da ta area). area). The bandwidth bandwidth of a streaming am ing channel channel yields either either 352.8 KBit/s (44.1 KHz) or 384 KBit/s (48 KHz). Since the MOST devi de vices ces are physi physical ly ly inter intercon connect nect ed ed into into a ring, each MOST frame must pass through every ev ery MOST device device at the frefrequency quen cy prescribed prescribed by the Timing Timing Master. Master. As soon as the rel evant
1/64
Fig ure 3: Figure Dif fer fer ence ence between between NIC and INIC INIC ar chitec chi tectures tures in a MOST de vice de vice
communi commu nica cation tion part ners ners (data (data source and sink) have connect con nect ed ed to the same streaming stream ing channel, channel, bit streaming streaming begins begins (Figure (Figure 5). Connection Connec tion or discon disconnec nection tion is usual usual ly ly made by a query query by the funcfunction block “Connec “Connection tion Master Master – CM” (FblockID=0x03). (FblockID=0x03). For this purpurpose, the CM provides pro vides the two functions functions “BuildSync “BuildSyncCon Connec nection” tion” and “Remov “RemoveeSync SyncCon Connec nection”. tion”. In the framework frame work of building building a connec connection, tion, the CM requests re quests that the rel evant data data source, e.g. the TV tuner, tun er, have the suit able number number of streaming stream ing channels channels al locat locat ed ed by the Timing Timing Master. Mas ter. That is because because the Timing Timing Master Mas ter is respon re sponsi sible ble for manage management ment of the “channel “chan nel resource re source al loca location tion table”. table”. The CM passes passes the address ad dresses es of the al lolocat ed ed streaming streaming channels channels to the data data sink, e.g. to the display, display, so that it can connect con nect to the streaming stream ing channels. channels. Final Final ly, ly, the CM upupdates the “sync connec con nection tion table”, table”, which it uses us es to manage manage all synsyn chronous chro nous connec connections. tions. Discon Disconnec nection tion is performed per formed accord according ing to the same scheme. To ena enable transmis transmission sion of data data packets, packets, the user user has the option op tion of reduc re ducing ing the number number of streaming streaming channels channels by up to 24 (six quadquadlets) using using the “Bounda “Boundary Descrip Descriptor”. tor”. All those streaming stream ing chanchannels that are not reserved re served for bit streaming, streaming, are combined combined to form the packet packet channel. channel. While a maxi max imum transmis transmission sion rate of up to 12.7 MBit/s is possi possible ble at a frequen frequency cy of 44.1 KHz, a maxi maximum rate
SERI SE RIAL AL BUS SYSTEMS SYS TEMS IN THE AUTO AU TOMO MO BILE
Fig ure 4: Figure Lay out out of the MOST frame: Sent in admin ad minis istra trative tive byte 0 are synchro synchro-niza ni zation tion in for mation ma tion and the boundaary descrip bound de scriptor, tor, and in admin ad min-istra is trative tive byte 63 the status status bits and a par ity bit for protec pro tection tion of the MOST frame.
of up to 13.8 MBit/s is at tained tained at 48 KHz. The bounda bound ary descrip descriptor tor is managed managed by the Net work work Master Master function function block (FBlockID=0x02). (FBlockID=0x02). It can be set via the “Bounda “Bound ary” function function (FktId=0xA03). A Layer Layer 2 proto protocol col is used to transmit trans mit data data packets. packets. The frame comcom prises pris es the arbi arbitra tration tion field, source and target target address, address, data data length code, data data field (either (either 48 or 1014 byte) and data data protec protection. tion. A token circu circulat lat ing ing in the ring regu reg ulates bus access. access. The MOST device device that takes the token to ken from the ring may access ac cess the packet pack et channel. channel.
Final ly, Final ly, the MOST system sys tem must transmit trans mit the MOST commands commands needneeded for manage management ment and control. control. Control Control messa messages ges (Figure (Figure 6) are used here, which are transmit trans mit ted ted on the control control channel channel (2 bytes). Therefore, There fore, 16 MOST frames (MOST block) are required re quired to transmit transmit a control con trol message. message. The bandwidth bandwidth at 44.1 KHz is 705.6 KBit/s, and at 48 KHz it is 768 KBit/s. Transmis Trans mission sion of control control messa messages ges is al so so based on a Layer Layer 2 proto protocol. col. Bus access access is imple implement ment ed ed by the CSMA method meth od (Carri (Carrier er Sense Mul tiple tiple Access). Access).
Fig ure 5: Figure Princi Prin ciple ple of bit streaming: streaming: The Timing Tim ing Master Master transmits transmits MOST frames at a frequen frequency cy of 48 KHz. 40 streaming streaming channels channels (10 quadlets) quadlets) are avail able for al loca lo cation, tion, each oper op er ating at ing at 384 KBit/s (bounda (boundary descrip de scriptor tor = 0xA). The packet pack et channel chan nel (20 bytes) pro vides pro vides a bandbandwidth of 7.68 MBit/s for the transtransmission mis sion of data data packets. packets.
1/65
Fig ure 6: Figure Control Con trol message. message. A MOST block is required re quired to transmit transmit a control control mesmessage. The control control message message is comcomposed of: ar bitra bi tration tion (a), tar get get address ad dress (b), source address address (c), message mes sage type (d), data da ta field (e), data da ta protec protection tion (f), acknowl acknowl edgedg ment (g), and reser reser va vation tion (h).
Physiical Lay er Phys er
De vel opment, opment, testing testing and anal y sis sis of MOST systems sys tems
Today, opti Today, optical cal conduct conduct ors ors of pol y ymer mer fibers fibers (POF – pol y ymer mer opti optical cal fiber) fi ber) are the state-of-the-art technol tech nol ogy for transmit transmit ting ting audio audio and video video signals signals in the MOST system sys tem (Figure (Figure 7). Overall, Overall, the techtech nical ni cal proper properties ties of pol y ymer mer fibers fibers are far supe su peri rior or to those of elecelec trical tri cal transmis transmission sion media. media. Espe Especial cial ly ly notewor noteworthy thy are its excel excel lent lent electro elec tromag magnet net ic ic immu immuni nity ty and rel ative tively ly high signal signal transmis trans mission sion rate of up to 500 MBit/s. Further Furthermore, more, the combi combina nation tion of POF, a red light-emit ting ting diode diode as the light source (wavelength (wave length 650 nm) and a sil icon PIN photo photodi diode ode as the receiv receiver er repre represents sents a very ecoeco nomiical and compar nom comparaative tively ly simple simple and manage manageaable form of opti optical cal signal sig nal transmis transmission. sion.
Vector Infor Vector Informa matik tik GmbH has been an asso as soci ciate ate member member of the MOST Coop Co oper eraation since 1999. Besides Be sides its exten ex tensive sive activ activiities in the area ar ea of seri serial al bus systems systems such as CAN, FlexRay Flex Ray and LIN, the Stutt gartgartbased net working working special special ist ist has been support support ing ing the devel devel opment opment and anal y ysis sis of info infotain tainment ment solu solutions tions in the auto au tomo mobile bile since the year 2000. It of fers fers a compre comprehen hensive sive product product lineup lineup of anal y ysis, sis, dedevel opment opment and test tools for appli ap plica cations tions such as high-end audio au dio systems, sys tems, mul time timedia dia streaming, streaming, tel ephone and navi naviga gation. tion. HardHardware inter interfa faces ces for bus access, access, a mul tibus tibus data data logger logger as well as training train ing courses courses and engi engineer neering ing and devel devel opment opment servi services round out its of fering fer ing [3]. The Vector Vector Acade Academy [4] supplies supplies the neces nec essa sary ry basic ba sic knowl edge edge relat relat ed ed to ECU commu communi nica cation tion in the auto automo mobile bile in the framework frame work of semi seminars on CAN, LIN, FlexRay FlexRay and MOST.
MOST 150, which fol lows lows MOST 50, is a MOST system sys tem that is current cur rent ready to start. It is based on this sender send er and receiv receiver er technol technol ogy and of fers fers the user user a transmis transmission sion rate of 150 MBit/s. It can therethere fore handle handle the rel ative tively ly short paths in the car of up to 20 me ters can without without any problems. problems.
1/66
SERI SE RIAL AL BUS SYSTEMS SYS TEMS IN THE AUTO AU TOMO MO BILE
Background Back ground knowl edge edge on signal signal transmis transmission sion in a MOST system system via POF
When a light beam passes pass es from one transpar trans parent ent medi medium um to anoth anoth-er, it is refract re fract ed. ed. The great er er the angle angle of inci incidence, dence, the great er er the refrac refraction. tion. The medi me dium um in which the light beam forms a small er small er angle an gle with the prima primary ry axis axis is the opti optical cal ly ly denser medi medium. um. In the
transition transi tion from the opti op tical cal ly ly denser to the opti op tical cal ly ly less dense medi medium, um, the beam is refract re fract ed ed away from the prima prima-ry axis. axis. The angle angle of refrac refraction tion a can be cal culat culat ed ed if the so-called indi indices ces of refrac refraction tion n of the two media me dia are known (Snel lius lius Law). If the light beam exceeds ex ceeds an inci in cidence dence angle an gle a0 in the transi tran sition tion from the opti optical cal ly ly denser medi medi-um to the opti optical cal ly ly less dense medi me dium, um, then total total reflec reflec-tion occurs. occurs. This proper property ty makes it possi possible ble to transport transport light in an opop tical ti cal conduct conduct or. or. In the MOST system, sys tem, pol y ymer mer fibers fibers are usual usu al ly ly imple implement ment ed ed for opti optical cal signal signal transmis trans mission, sion, where a core of PMMA (pol ym ymeth eth yl yl metha methacryl ate) ate) is encased encased in a thin sheath of fluor flu oriinat ed ed acryl ate. ate. PMMA has a larger larg er rerefract ive ive index index than the fluor fluoriinat ed ed pol y ymer. mer. If the angle angle of the inci incident dent light beam is great er er than the limit lim it angle, angle, then the light is conduct con duct ed ed in the core due to total to tal reflec reflection. tion. The small est est at tenu tenuations for transmis transmission sion of light in a so-called step-index step-index PMMA fiber fiber are obtained obtained at 520 nm (green), 560 nm (yel low) low) and 650 nm (red). Red LEDs are gener gen eral al ly ly used (at tenu tenuation 0.14 dB/m), since they are very inex inexpen pensive. sive.
Fig ure 7: Figure Background Back ground knowl edge edge on opti optical cal signal signal transmis transmission sion in a MOST system system
Liter ature and links: Liter [1] www.diw.de [2] www.most coop cooper eraation.com [3] www.vector-group.net/most/en www.vector-group.net/most/en [4] www.vector-acad www.vector-acadeemy.com
Eugen May er Eugen er (Graduate engineer; technical teaching certificate); after vocational training as a communication electronics technician, he studied electrical engineering and technical education at the Technical College of Ravensburg/Weingarten and the University of Stuttgart. Since 1999 he has been employed at Vector Informatik where he works as a Senior Trainer.
1/67
Ef f icient Test ing ing in Auto Automo motive tive Electron Electronics ics
One test envi environ ronment ment from HIL simu simula lation tion to diag diagnos nostics tics Testing cer tainly Testing tainly plays an impor im por tant tant role in the auto au tomo motive tive electron electronics ics de vel opopment process process today, today, but there is unex un ex-ploited ploit ed poten potential tial for more ef ficient fi cient and auto au tomat mated ed testing testing exe execu cution tion in the future fu ture by util izing izing the right strate strategies, ideas and tools. This ar ticle ticle ana analy zes zes the cur rent rent state of the technol tech nol ogy, clar ifies problem problemat atic ic inter inter actions actions occur occur ring ring in practice, practice, and demon demonstrates strates that tools are al ready ready avail able today today for solving solving concrete con crete project tasks relat re lated ed to testing testing in an el egant and ef ficient ficient way.
1 Intro Introduc duction tion Over the past ten years, the status sta tus of auto automo motive tive electron electronics ics has changed funda fundamen mental tal ly. ly. At the begin beginning, ning, just a few ECUs were used in the auto au tomo mobile bile but now more than 60 ECUs are being be ing installed in stalled in some luxu luxury class cars. Addi Ad dition tional al electron electronic ic systems systems offer improve improvements ments in the are ar eas of safety, safety, conve convenience nience and ener en ergygysaving sav ing oper operaation. Today, Today, more inno innova vations tions are based on electron elec tron-ics, and increas increasing ingly, ly, a large share of this function func tional al ity is based upupon soft ware. ware. Growing Grow ing complex complexiity has made exten extensive sive and ef fect fect ive ive tests more impor im portant tant than ever ev er before. before. The widespread widespread use of numer numerous ous elecelectronic tron ic compo components nents has caused the number num ber of poten potential tial error er ror soursources to rise dispro dis propor portion tionate ately. ly. Tests are indis in dispen pensa sable ble in all phases phas es of ECU devel devel opment opment to detect detect and correct correct errors errors early, early, keeping keeping costs as low as possi pos sible. ble. Some weakness weaknesses es of a total total system system do not maniifest themselves man themselves until until compo components nents are inte in tegrat grat ed ed under under actu actual al and real-time real-time condi conditions. tions. This has turned test ing ing into into a crossdepart de part mental mental and cross-manu cross-man ufac factur turer er disci discipline. pline. The enormous enor mous electron electronic ic problems problems that occurred occurred in ini initial years have shown what happens hap pens when these facts are not con sid sidered ered and system sys temat at ic ic tests are neglect ne glect ed. ed. The lat er er that problems problems are identi iden ti-fied in the devel devel opment opment process, process, the more seri se rious ous impact impact there is to the increase increase in cost. This becomes be comes clear in an extreme ex treme way when correc cor rection tion of errors errors leads to cost ly ly recall recall actions actions aft er er product product has been shipped. Partic Par ticiipants in the auto au tomo motive tive indus industry try have learned their lessons les sons and now at tach tach great impor importance tance to the topic, topic, but it is possi pos sible ble to further fur ther increase increase ef ficien fi ciency cy by consist consist ent ent appli applica cation tion of avail able resour resources. ces.
2/0
Costs for tests repre represent sent a consid consider eraable share of a project budget, budget, but proper proper function functional al ity of the ECU must be assured. assured. Therefore, Therefore, it is impor im portant tant to achieve a maxi max imum of test qual ity and test depth with transpar trans parent ent concepts, concepts, e.g. by replac replacing ing insuf insuf ficient fi cient ly ly auto automat mat ed ed test steps by modern modern methods methods and tools.
2 Tool for anal y sis, sis, simu simula lation tion and testing testing The net working working of ECUs repre rep resents sents the backbone back bone of motor motor vehi vehicle cle electron elec tronics. ics. In this context, con text, the method meth od of remain remaining ing bus simu simula la-tion provides provides an impor important tant founda foundation tion in perform per forming ing ECU tests. Without With out at least a rudi rudimen menta tary ry simu simula lation tion of the ECU envi en viron ronment, ment, most ECUs cannot cannot be put into in to oper operaation meaning meaningful ful ly. ly. For exam example, ple, many ECUs only only oper operate ate proper properly ly if they serve net work work manage manage-ment functions. functions. CANoe CA Noe from Vector Vector Infor Informa matik tik is a widely wide ly used tool for ana analyz lyzing, ing, simu sim ulat ing ing and test ing ing distrib distribut ut ed, ed, embed embedded ded systems systems (Figure (Figure 1). It is used widely widely for remain remaining ing bus simu simula lation tion and supports supports all impor im portant tant bus systems sys tems – in partic par ticu ular CAN, LIN, MOST and FlexRay FlexRay – for which Vector Vector Infor Informa matik tik al so so supplies supplies suit able PC inter interfa faces. ces. Commer Com mercial cial ly ly avail able inter interface face cards can be used to address address the I/O lines of ECUs from CANoe. CA Noe. Moreover, Moreover, Vector Vector has announced announced an I/O hardware hardware product product that supple supplements ments these gener gen eral al capa capabil bil ities with test-specif test-spe cif ic ic functions functions such as switching switch ing addi addition tional al loads and short circuits circuits direct direct ly ly to the ECU termi ter minals. nals.
Fig ure 1: Figure CANoe CA Noe includes includes anal y sis, sis, simu simula lation tion and test capa capabil bil ities for networked networked systems. sys tems.
The vari var ious anal y ysis sis capa capabil bil ities, simu simula lation tion compo components, nents, and test sequen se quences ces rely rely on models models inte integrat grat ed ed in the tool in the form of data da ta-bases. bas es. These might be the commu com muni nica cation tion matri matrices ces in DBC format format for CAN, FIBEX FIBEX for FlexRay, FlexRay, XML function function cat alogs for MOST or LDF files for LIN. Simi Similar larly, ly, CDD and ODX descrip descriptions tions may be used to describe de scribe the diag di agnos nostic tic capa capabil bil ities of an ECU. Besides Besides contain containing ing essen es sential tial infor informa mation tion on the system, sys tem, test descrip de scriptions tions al so so contain contain symbol sym bol ic ic names for signals, sig nals, messa messages, ges, diag diagnos nostic tic servi services, etc. This simpli sim plifies fies the work of the test user us er and test devel devel oper oper and creates creates an abstrac ab straction tion layer layer between between the test and commu com muni nica cation tion descrip description. tion. Any simple simple worksta workstation tion PC running running under under Windows Windows can be used to run CANoe. CANoe. More power powerful ful test stations stations with improved improved real-time real-time cacapabil pa bil ities can be set up in a real-time real-time config configu ura ration. tion. This is done by exeecut ing ex ing the remain remaining ing bus simu simula lation tion and the actu actual al test exeecu ex cution tion on a dedi ded icat ed ed comput comput er er running running under under a real-time real-time oper op erat at ing ing system system (Windows (Windows CE), while a sepa separate PC is used as the graphiical user graph user inter interface face and for eval uation purpos purposes es (Figure (Figure 2). In this set up, up, the system system can al so so serve as a test exe ex ecu cution tion envi environ ron-ment for a compo component nent HIL test er. er.
Fig ure 2: Figure Dual-com Du al-comput puter er oper oper ation of CANoe CANoe Real Real time time of fers fers improved im proved real-time re al-time capa capabil bil ities.
2/1
3 Inte Integra gration tion of testing testing and de vel de vel opment opment Today’s devel Today’s devel opment opment models models call for tests in vari various phases phases of devel devel opment op ment (Figure (Figure 3). Gener General al ly, ly, the indi individ vidu ual tests are self-contained, self-contained, sepaarate activ sep activiities that are performed per formed by special special ized ized person personnel nel at suit ably equipped, dedi dedicat ed ed worksta workstations tions using using special special tools, lanlan guages and methods. methods. In this context, context, test crea creation is of ten ten orga organized nized as an inde independ pendent ent task, detached detached from other other devel devel opment opment activ activiities. This segment segment ed ed work approach approach results results from distri dis tribu bution tion of the many dif ferent ferent tasks of the devel de vel opment opment process process to special special ized ized working work ing groups. Howe However, if this sepa separa ration tion of tasks is fol lowed lowed too strict ly, ly, the numer numerous ous contact contact points between be tween vari var ious devel devel opment opment and test ing ing tasks will most likely like ly not be util ized ized opti optimal mal ly. ly. For exexample, am ple, only only good coor coordi dina nation tion between between compo component nent test ing ing and system sys tem test ing ing can prevent pre vent expen expensive sive redun redundant dant devel devel opment opment of test cases cases that are identi iden tical cal in content. con tent. When compat compat ible tools are used, test cases cases that have al ready ready been devel devel oped oped once can be used as a basis basis for other other devel devel opments opments in vari var ious are areas. This avoidance avoidance of redun redundant dant devel devel opments opments frees up resour re sources ces that could be used, for exam example, ple, to prof it it ably invest invest in the val ida dation tion of exist exist ing ing test cases cas es and their advanced advanced devel devel opment. opment. Compre Comprehen hensive sive test manman agement age ment supplies supplies a sol id id founda foundation tion for coop cooper eraation and, apply applying ing the same resour re sources, ces, opti optimiz mizes es the depth and breadth of test ing. ing. Coor Co ordi dina nation tion al so so helps to detect de tect and fill gaps in test ing. test ing.
Figure Fig ure 3: Tests are indis indispen pensa sable ble in all phases phases of de vel de vel opment. op ment.
2/2
Besides linking Besides link ing the dif ferent ferent test phases, phas es, devel devel opment opment and test acac tiviities must al so tiv so be inter interre relat lat ed ed and adapt ed ed to one anoth another. er. Test ing must be under understood stood as an inte in tegral gral compo component nent of devel devel opment opment that requires requires compre comprehen hensive sive support support using using proper proper methods methods and tools. This must be guaran guar anteed teed in addi addition tion to the proce pro cedur dural al and organ or ganiiza zation tional al inte integra gration. tion. What is impor important tant here is to make tests avail able in con junc junction tion with devel devel opment, opment, not just in the required re quired formal for mal veri ver ifi fica cation tion phases. phases. Ideal Ideal ly, ly, it is possi possible ble to perform per form tests direct di rect ly ly at the ECU devel de vel oper’s oper’s worksta work station tion with the resour re sources ces exexist ing ing there. For this purpose, pur pose, CANoe CANoe of fers fers a run-time envi en viron ronment ment for test exeecu ex cution tion that can be used in par al lel lel to the remain remaining ing bus simu sim ula la-tion and anal y ysis sis functions. functions. The process process is very easy to set up, espe es pe-cial ly ly if devel devel opers opers are al ready ready using using CANoe CANoe for remain remaining ing bus simu simulation la tion and anal y ysis sis of bus commu communi nica cation. tion. CANoe’s CA Noe’s test compo component nent ena enables manu manual, semi semiau auto tomat mat ic, ic, and ful ly ly auto au tomat mat ic ic exe execu cution tion of tests. The devel de vel oper oper can begin begin with simple simple tests and lat er er expand expand and complete complete them. In gener gen eral, al, the process process of creat creat ing ing complex complex tests is a task of val ida dation tion depart depart ments ments that build their tests upon up on the devel devel oper’s oper’s tests. An impor important tant founda foundation tion for such tests is the remain re maining ing bus simu simula la-tion, which ideal ideal ly ly is not set up manu man ual ly, ly, but rather rather is auto automat mat ical ly gener generat at ed ed and param parameeter terized ized from the data databas bases es of the system sys tem
EF FI FI CIENT TEST ING I NG IN AUTO AU TOMO MO TIVE ELECTRON ELEC TRONIC IC S
description. descrip tion. The actu actual al work is performed per formed by so-called model model ing ing DLLs (e.g. Inter Interac action tion Layer, Layer, Net work work Manage Management, ment, etc.), which are supplied supplied with the tool or which Vec tor puts togeth together er as OEMspecif spe cif ic ic model model ing ing packets. packets. The signals sig nals that the remain re maining ing bus simsimula lation tion supplies supplies to the simu sim ulat ed ed nodes may be acquired acquired direct direct ly ly from test scripts, or may be stim ulat ed ed or added added manu manual ly. ly. In contrast contrast to the system sys temat at ical ly ly planned, exe execut ed ed and docu document ed activ activiities of the test phases, phas es, formal formal exe execu cution tion and docu documen menta ta-tion are gener general al ly ly omit ted ted in tests accom ac compa pany nying ing devel devel opment. opment. Never Nev erthe theless, less, these tests make substan sub stantial tial contri contribu butions tions toward toward overall over all qual ity, because because they give the devel de vel oper oper the abil ity to deliv deliv-er a more stable stable product product to the subse subsequent quent test ing ing phase.
4 Matur Matur ity level level assess assessment ment and er ror ror anal y sis sis To assess assess the matur ma turiity level level of an ECU during dur ing devel devel opment, opment, a compre com prehen hensive sive eval uation of all exe execut ed ed tests is neces nec essa sary. ry. The qual ity of indi individ vidu ual test results re sults with regard regard to reli reliaabil ity and rel evance must be consid considered, ered, but more impor important tant is broad cover coverage age of the required required proper properties ties by suit able tests. Therefore, Therefore, the results results of less formal formal ly ly exe execut ed ed tests are al so so helpful helpful in matur maturiity anal y ysis. sis. A prereq prerequi uisite site for this – besides besides keeping keeping records records of test exe execu cution tion – is the consist consist ent ent use of config configu ura ration tion manage management. ment. This is al so so
indispen indis pensa sable ble from the perspec perspective tive of achieving achieving qual ity-ori ty-orient ent ed, ed, structured struc tured devel devel opment opment process processes. es. A test record is produced pro duced whenev whenever er a test is exe ex ecut ed ed using using CANoe, CANoe, whether wheth er in the test labo lab ora rato tory ry or at a devel de vel opment opment worksta work station, tion, and is creat creat ed ed without without inter interven vention tion by the user us er or test case devel de vel oper. op er. It is then avail able for tests accom ac compa pany nying ing devel devel opment opment without with out requir requiring ing addi addition tional al ef fort. fort. The XML format format used for the test records records is an open format for mat thus other other tools can be used for furfur ther process processing ing of the results. results. For exam example, ple, a test manage man agement ment system sys tem might be used to eval uate the test records rec ords in the context con text of a matur maturiity level level anal y ysis. sis. Essen Es sential tial in this ef fort ef fort is a mapping mapping of test results results to test cases, cas es, and of test cases cases to require requirements. ments. This is easy to achieve by the use of unique identi identifi fiers ers (e.g. a require requirement ment ID), which the test case devel de vel oper oper ref eren erences ces in indi individ vidu ual test cases. cases. CANoe CANoe auto automat mat ical ly ly copies cop ies this identi identifi fier er to the test record so that all test cas es, test results re sults and require requirements ments are clearly clear ly inter interre relat lat ed ed (Figure (Figure 4). At least as impor important tant as record re cording ing and eval uat ing ing test results, re sults, is the anal y ysis sis of the causes caus es of the errors er rors that actu actual al ly ly occur. occur. Most test tools do not provide provide any such capa capabil bil ities or provide provide just rudi rudi-menta men tary ry capa capabil bil ities. One impor important tant reason reason is that error er ror anal y ysis sis is of ten ten con consid sidered ered as a complete completely ly inde independ pendent ent task for devel devel opers. opers.
Figure Fig ure 4: Test cases cases and test results results are clear ly ly ref er er enced enced by IDs.
2/3
First, they are faced with the problem prob lem of under understand standing ing errors errors dedetect ed ed in the test and tracing trac ing their causes. causes. In partic par ticu ular, when erer rors are report re port ed ed by test labo labora rato tories, ries, the devel devel oper oper usual usual ly ly does not even have access access to the systems sys tems used in test ing. ing. Therefore, There fore, at the test bench it is manda man dato tory ry to precise precisely ly record the test proce procedure dure and log every every inter interac action tion with the DUT, espe es pecial cial ly ly bus commu communi nica cation. tion. During Dur ing the role of anal y ysis, sis, CANoe CANoe ena enables replay and anal y ysis sis of any desired desired record recordings ings (log records). records). It is thus possi possible ble and bene benefi ficial cial to have the same type of test sys tem at the devel devel opment opment worksta work station tion as that of the test bench, so that the devel de vel oper oper can repro re produce duce error error produc producing ing test cases cases inde independ pendent ent ly. ly. In many cases cases it is possi possible ble to exe execute the rel evant test cases cas es even if many simpli simplifi fica cations tions are neces nec essa sary, ry, e.g. to avoid address addressing ing nonnonexist ex ist ent ent measure measurement ment hardware. hardware.
5 Signal Signal abstrac abstraction tion and diag diagnos nostics tics Abstraction Abstrac tion is a common com monly ly used and impor important tant method method for handling handling complex com plexiity in soft ware ware devel devel opment opment and system system design. design. This can al so be applied applied to the handling handling of tests. Growing Grow ing function functional al ity in the ECUs not only only increas increases es the complex complexiity of systems, systems, but al so so requires requires tests that are more exten ex tensive sive and complex. complex. The choice of the corcor rect abstrac abstraction tion layer layer in compos composing ing tests not only only af fects fects the ef fort fort required re quired to create create test cases, cas es, and therefore therefore costs, but al so so the qual ity of test cases. cases. Like all other oth er soft ware ware compo components, nents, the test cases cas es themselves them selves may contain contain errors er rors as well and should be checked bebe fore use. Anoth Another er aspect aspect is the neces nec essa sary ry mainte maintenance nance tasks, e.g. making mak ing adap adapta tations tions to modi mod ified require requirements ments and correct cor rect ing ing test cases. cas es. Abstrac Ab straction tion on the signal sig nal level level is a common com mon way to test ECU funcfunc tional tion al ity, and this is why in the ECU the actu ac tual al appli applica cation tion is gener gen er-al ly ly based on a signal signal abstrac abstraction tion (Figure (Figure 5). In a CAN system, system, for exam ex ample, ple, an Inter Interac action tion Layer Layer in the ECU provides pro vides the signal signal ababstraction. strac tion. That is exact ex act ly ly how CANoe CANoe uses uses an Inter Interac action tion Layer; Layer; it param pa rameeter teriz izes es it self self from infor informa mation tion contained contained in the net work work descriptions, descrip tions, which al so so serve to create cre ate the ECU soft ware. ware. This ensures that ECU and test envi en viron ronment ment util ize ize the same abstrac ab straction tion layer lay er and are therefore therefore opti optimal mal ly ly tuned to one anoth another. er. Simul Si mul tane taneous ously, ly, signal signal abstrac abstraction tion al so so repre represents sents – at least on the proto pro tocol col level level – the remain remaining ing bus simu simula lation. tion. For exam example, ple, it enensures that peri period odic ic signals signals are actu ac tual al ly ly transmit transmit ted ted peri period odiical ly. ly. In test ing, ing, the ECU is repre rep resent sent ed ed in a real real istic istic envi environ ronment ment regard regarding ing bus commu communi nica cation. tion. Moreover, Moreover, when a change is made to the sys tem’s commu communi nica cation tion matrix, matrix, it is usual usu al ly ly possi possible ble to contin continue ue to use the test cases cas es unmod unmodiified. With the same appli ap plica cation, tion, the ababstraction strac tion ena enables reuse reuse of test cases cas es in simi sim ilar pro jects. In test ing ing ECUs, it is not only on ly the signal sig nal inter interface face that is impor important. tant.
2/4
Many ECU functions functions can only only be test ed ed meaning meaningful ful ly ly if deeper deeper access to the ECU is possi pos sible. ble. Such access accesses es are provid provided ed by the diagnos nostic tic and cal ibra bration tion inter interfa faces, ces, which are accessed ac cessed via an ECU’s exist ex ist ing ing bus inter interfa faces. ces. It does not make sense to ad dress these interfa inter faces ces by simple simple message message sequen sequences, ces, since defined defined proto protocols cols under un derlie lie the commu communi nica cation tion process. process. It is more conve con venient nient and reliable relia ble to have appro appropri priate ate abstrac abstractions tions for diag diagnos nostics tics and calibration. bra tion. In CANoe, CANoe, either either descrip description tion files from the CANdela CAN dela tool or ODX dede scription scrip tion files are respon re sponsi sible ble for param parameeter teriz izing ing the diag diagnos nostic tic acaccess layer. layer. If no descrip description tion is avail able for the actu actual al diag diagnos nostic tic cacapabil pa bil ities of an ECU, a gener generic ic descrip description tion for KWP2000 and for UDS supplied sup plied with CANoe CA Noe may be used. Either Either the gener ge neric ic descrip description tion or a diag di agnos nostic tic descrip description tion file custom cus tomized ized for the ECU will of fer of fer conconvenient ve nient access access to the diag di agnos nostic tic servi services defined defined there. It is possi possi-ble to obtain obtain the same abstrac ab stractions tions and advan advanta tages ges as in the signal sig nal abstrac ab straction tion described described above.
Fig ure 5: Figure Signals Sig nals of fer fer an abstrac abstraction tion level level between between messa messages ges and I/O connec con nections tions on the one hand, and between be tween test def ini nitions tions and simu simula lation tion models mod els on the other oth er hand.
EF FI FI CIENT TEST ING I NG IN AUTO AU TOMO MO TIVE ELECTRON ELEC TRONIC IC S
The CCP and XCP measure meas urement ment and cal ibra bration tion proto protocols cols can be used to access access inter internal nal ECU vari var iables via test scripts in CA Noe. The measure meas urement ment and cal ibra bration tion tool CANa CANape pe handles handles these proto pro tocols cols and the ECU descrip description tion files (A2L) that are needed. need ed. CANoe CANoe controls controls CANa CA Nape pe via the COM inter interface. face. This accom accomplish plishes es the same goals as in the signal signal and diag diagnos nostic tic abstrac abstraction tion described described above.
6 Ef ficient fi cient test gener gener ation A precise precise study of an ECU’s test cases cas es will reveal re veal that many of the test cases cases can be derived derived from just a few recur recurring ring pat terns. terns. This is quite evi evident in gateway gateway ECUs: A ma jor ma joriity of the test cases cases serve to check the rout ing ing of signals signals and messa mes sages. ges. Final Final ly, ly, the only only reason reason for the large number num ber of test cases cas es is the large number num ber of possi possible ble input in put and out put put data. data. But the same types of pat terns terns are al so so found in other other types of ECUs. Expressed Ex pressed abstract abstract ly, ly, this means that many functions functions are test ed ed by first put ting ting the ECU in a specif spe cif ic ic state using using a suit able stimu stimulus and then checking check ing the state that is reached. The recur recurring ring pat tern tern of these test cases cas es is: Set signals sig nals (stim(stim ula lation), tion), wait for the maxi maximum al lowa lowable reac reaction tion time, and then check the signals sig nals of the new ECU state. With some expe ex peri rience ence in the use of test pat terns, terns, users users will likely likely recognize recognize a few addi ad dition tional al run-time pat terns terns from which many test cas es can be derived. derived. These pat terns terns repre represent sent an oppor op portu tuni nity ty for further further opti optimi miza zation tion of test case gener gen eraation. CANoe, CANoe, in addi addition tion to of fering fer ing classic classic proprogramming gram ming of test cases, cas es, al so so lets the user us er define define test cases cases based on test pat terns. terns. It is no longer neces nec essa sary ry to program program the pat tern tern contents, con tents, since the proce pro cedures dures are al ready ready known and perma permanent nent ly ly
integrat inte grat ed ed in the pat terns terns that are supplied sup plied (Figure (Figure 6). Test case gener gen eraation is reduced reduced to defin defining ing the target target behav behavior, ior, includ including ing any supple supplemen mental tal data data needed, needed, such as the set tling tling times to be tol eranced. er anced. To the extent ex tent that it is sensi sen sible, ble, the supplied sup plied test pat terns terns themthemselves are placed on the signal sig nal abstrac abstraction tion described described above and enenable symbol symbol ic ic access access to signals, signals, messa messages, ges, etc., via the asso as soci ciat at ed ed data da tabas bases. es. The use of diag diagnos nostic tic servi services or I/O signals signals is al so so pospossible. si ble. In short: The entire entire test ing ing infra infrastruc structure ture of CANoe CANoe can be used with test pat terns. terns. If there are require re quirements ments that extend ex tend beyond these capa capabil bil ities, the option option of program programming ming the test cases still exists. ex ists. Auto Au tomat mat ic ic gener generaation of test cases cas es is anoth another er method method for creat creat ing ing tests ef ficient fi cient ly, ly, if suit able sources sources of infor informa mation tion are avail able. The contents contents of gener generat at ed ed tests are by neces necessi sity ty limit limit ed ed to the dedescription scrip tion levels levels and depths of the sources. sour ces. Never Neverthe theless, less, gener generaation of fers fers val uable support, support, prima primari rily ly when it comes to cover cov ering ing the formal formal ly ly defined defined basic basic proper properties ties of an ECU by tests. The rel atively tive ly low ef fort fort required required to gener generate ate test results results in quicker quicker avail abil ity thereby thereby making making it possi possible ble for earli earlier er detec detection tion of unde undesir siraable trends. The tool chain from Vector Vec tor util izes izes such test gener gen eraator approach approaches. es. Descrip De scription tion files such as the DBC data da tabase base or CANdela CANdela def ini nitions tions are used as the source for the gen er eraator (Figure (Figure 7). The gener gen eraator uses us es them to gener gen erate ate test cases, cas es, which CANoe CA Noe then exe executes. Since test scripts may make use of the en tire tool infra in frastruc structure, ture, the test gener generaators are of ten ten designed designed to be quite simple. sim ple. For exam example, ple,
Fig ure 6: Figure The use of patterns patterns abstracts abstracts the actu ac tual al exe execu cution tion of the test case and thereby there by simpli simplifies fies test de vel opment. op ment.
2/5
Fig ure 7: Figure Test cases cases can be creat created ed from very dif fer fer ent ent sour ces ces using us ing gener gener ators.
with just a lit tle tle ef fort fort a gener generaator can create create suit able test cases cases from a custom customer-spe er-specif cif ic ic gateway gateway descrip description tion (e.g. in the form of a data da tabase base or Excel Excel spreadsheet). spreadsheet). Thanks to the test pat terns terns dedescribed above, this just requires re quires a simple simple transfor transforma mation tion of the cuscustomer-spe tom er-specif cif ic ic data data into into the format format of the test pat terns. terns. Users Users can create cre ate such a gener gen eraator in a straight forward for ward manner. manner. Vector Vector of fers fers further fur ther support support in the form of project-relat project-relat ed ed servi services.
7 Summa Summary ry The only only way for auto automo motive tive OEMs and suppli suppliers ers to deal with the growing grow ing require requirements ments for ECU tests is by ef fi ef ficient cient test crea cre ation and auto au tomat mat ic ic test exe execu cution. tion. The test ing ing tool present present ed ed of fers fers a provproven solu solution tion for imple implement ment ing ing test ing ing tasks with signal sig nal abstrac abstraction, tion, inte in tegra gration tion of diag diagnos nostic, tic, cal ibra bration tion and I/O inter in terfa faces, ces, the concon cept of test pat terns, terns, and test case gener gen eraators. CANoe CANoe is a highperform per formance ance runtime runtime envi environ ronment ment for test ing ing ECUs and net works. works. The tool ena enables early early crea creation and exe execu cution tion of tests with lit tle tle ef fort, right at the devel devel oper’s oper’s worksta work station. tion. The open inter interfa faces ces of CANoe CA Noe facil facil itate seamless seamless inte integra gration tion in a compre comprehen hensive sive test ing ing strat egy and tool-support tool-support ed ed test manage management. ment. Al though though some ususers might still imag im agine ine it to be a futur fu turis istic tic vision, vision, with suit able inte inte-gration gra tion of CANoe CANoe it is al ready ready possi possible ble to deter determine mine matur maturiity levels levels today. to day. Vector Vector is contin continu uous ously ly devel devel oping oping CANoe CANoe for use in these areas, are as, thereby thereby support support ing ing users users with a modern mod ern and ef ficient fi cient test plat form. form.
2/6
Thomas Rie Thomas Riegraf (Grad (Gradu uate Engi Engineer) neer) is Global Global Product Product Line Mana Manager and respon re sponsi sible ble for the product product line “Tools for Net works works and Distrib Dis tribut ut ed ed Systems” Systems” at Vector Vector Infor Informa matik tik GmbH in Stutt gart. gart.
Siegfried Beeh (Grad Siegfried (Gradu uate Engi Engineer) neer) is team leader leader and respon responsi sible ble for test tools, diag di agnos nostics tics and model model ing ing in CANoe CANoe at Vector Vector Infor Informa matik tik GmbH in Stutt gart. gart.
Dipl.-Inform. Stefan Dipl.-Inform. Stefan Krauß (Grad (Gradu uate in Infor In forma matics) tics) works as product product mana manager for test tools at Vector Vector Infor Informa matik tik GmbH in Stutt gart. gart.
ECU Testing
Systemize your ECU test with systematic and reproducible tests. Efficient test systems accelerate your CAN, LIN, MOST and FlexRay development.
Distr. Systems
t n e m p o l e v e D
> 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.
U C E
Diagnostics
> Take Take advantage of the calibration calibration,, diagnostic or I/O por t interfaces in your tests. > Test the full range of ECU functions with the V T System that can simulate or control the environment.
Calibration U C E
Software U C E
Vector tools and services help you achieve optimum test quality and test coverage within all development phases. Management
s s e c o r P
Vector Informatik GmbH Ingersheimer Str. 24 70499 Stuttgart Tel. Te l. +49 +49 711 / 8 06700670-0 0 www.vector.com
Information and Downloads: www.vector.com/ecu-test
t e m T S y s V r a r e o t V e c h a r d w
e s t u l a r t v t - s y s t e m d o m T h e c o m/ t o r. c c e v v . w w w
Reli Re liaable Engi Engineer neering ing Test ing ing on a Wiper Wiper Motor Motor Test Bench Time-synchronous Time-synchro nous record recording ing and eval uation of bus mes messa sages ges and physi physical param parameeters during during endur endurance ance test ing ing Synchroniz Synchro nizing ing the bus commu communi nica cation tion with measured measured physi physical param parameeters is one of the most dif ficult ficult require requirements ments for reli re li-able tests of ECUs. The data da ta from four data da ta acqui acquisi sition tion boards was eval uat ated ed in real-time real-time and synchro synchronized nized with the bus commu com muni nica cation tion of a control control module module in real-time. real-time. The special spe cial ists ists of Vector Vector Infor Infor matik matik de vel oped oped an indi indi vidu vidual solu solution tion based on the de vel de vel opment opment and test tool CANoe CANoe for the require requirements ments of Valeo Valeo Wiper Wiper Systems. Systems.
Valeo Wiper Valeo Wiper System System devel devel ops ops wiper wiper modules modules using using electric electric concontrolled revers reversing ing DC motors motors to real real ize ize complex complex wiper wiper movements movements based on the OEM custom cus tomer er speci specifi fica cations. tions. The wiper wip er system system has to react re act flexi flexibly and “intel “intel ligent ligent ly” ly” to envi environ ronmen mental tal condi conditions. tions. This can be real real ized ized with the use of a bus commu com muni nica cation tion system. system. Addi Addi-tional tion al features features of revers reversing ing wiper wiper motors motors are: > Soft ware-based ware-based wiper wiper field control control > Al ternat ternat ing ing park posi position tion to prevent prevent perma permanent nent set of the rubber rub ber el ement > Soft ware ware control control of wiper wiper movement movement and other other oper operat at ing ing states > Serv Service ice posi position tion for the exchange exchange of wiper wiper blades > Load-de Load-depend pendent ent speed control con trol > Over Overload load protec protection tion
In order order to val idate the correct correct function function of wiper wiper motors motors controlled controlled by bus messa messages, ges, Valeo Valeo needs to record and eval uate the physi physical param pa rameeters such as angle, an gle, revo revolu lutions, tions, and current current on the test bench. The deter determi mina nation tion and docu documen menta tation tion of vio viola lations tions to cuscus tomer tom er speci specifi fica cations tions shall be rather rath er simple simple and conve convenient. nient. Valeo Valeo engi en gineers neers worked with dif ferent ferent suppli suppliers ers on vari var ious propos proposals als for the real real iza zation tion of such a test bench. Final Final ly ly the concept concept of Vector Vector Infor In forma matik tik GmbH from Stutt gart, gart, which is based on the flex ible dedevel opment opment and test soft ware ware CANoe, CANoe, was most convin convincing. cing. A deci deci-sive factor factor for choosing choosing Vector Vector Infor Informa matik tik was Vale Valeo’s o’s expe experi rience ence in the success successful ful appli applica cation tion of Vector Vector tools such as CANa CAN aly lyzer, zer, CANoe, CANoe, and CANis CANister. ter. The “CANoe “CANoe Appli Applica cation tion Devel Devel opment” opment” team of Vector Vec tor managed managed the imple im plemen menta tation. tion. Through numer numerous ous test and simu simula lation tion pro jects,
Unlike conven Unlike convention tional al ful ly ly rotat rotat ing ing DC motors, motors, the out put put shaft of this motor motor type revers reverses es at an angle an gle less than 180 degrees. degrees. The momo tor drives a linkage link age that moves the wipers wip ers across the windshield. wind shield. In conform conformance ance with the vehi ve hicle cle archi architec tecture, ture, Valeo Valeo uses uses a CAN or LIN data data bus to control control the revers reversing ing wiper wiper motor. motor. This new wiper wiper system sys tem technol technol ogy al so so requires requires new standards stand ards for test ing ing technol technol ogy, which needs to be devel devel oped oped in addi addition tion to the actu ac tual al product. product. Therefore, There fore, Valeo Valeo has derived derived the require requirements ments for an endur endurance ance test bench and test process proc esses es based on custom customer er speci specifi fica cations: tions: > Test dura duration tion of more than 1.5 mil lion lion wiping wiping cycles cycles which is equal to a contin continu uing test time of more than 28days. > Au Auto tomat mat ed, ed, soft ware-controlled ware-controlled test sequen sequences ces > The highest highest level level of test system sys tem stabil stabil ity (soft ware ware and hardware) hardware) > The simul simul tane taneous ous test ing ing of up to 5 motors mo tors using using indi individ vidu ual control (volt age, age, motor motor loads, current current limi limita tation, tion, etc.) includ including ing the remain remaining ing bus simu simula lation. tion. > Se Sequen quential tial measure meas urement ment of physi physical motor motor param parameeters such as angle, an gle, current, current, volt age, age, and temper temperaature; cal cula culation tion of speed and RMS val ues ues > Con Contin tinu uous moni monitor toring ing of bus commu communi nica cation, tion, motor motor out put put shaft movement movement profiles profiles as well as other other physi physical param parameeters and their eval uation by compar comparing ing actu actual al measure measurements ments to envel envel op op curves. > Con Control trol of the climate cli mate chamber cham ber accord according ing to speci specified climate climate profiles pro files
2/8
Fig ure 1: Figure Wiper Wip er test bench at Valeo Valeo
RELI RE LIA A BLE ENGI EN GINEER NEERING ING TEST ING I NG ON A WIPER WIP ER MOTOR MO TOR TEST BENCH
the team has the neces nec essa sary ry expe experi rience ence and know-how to create cre ate cuscustomer-spe tom er-specif cif ic ic test systems systems with CANoe. CANoe. The Valeo Valeo test engi en gineers neers and the Vector Vector team worked joint ly ly to deter determine mine require requirements ments for the config configu ura ration tion inter interface face of the test process proc ess control. control. Both project part ners ners creat creat ed ed the require requirements ments for record recording ing and eval uat ing ing measure meas urement ment data data col lect lect ively. ively. The devel devel opment opment was initial ini tial ly ly based on a simu simulat ed ed test envi environ ronment ment prior prior to test ing ing and ad just ad just ing ing the CANoe CA Noe test system sys tem on the actu actual al Valeo Valeo test bench (Figure (Figure 1).
Customer-tai Custom er-tailored lored hardware hardware for record recording ing measure measurement ment data da ta The test bench hardware hard ware was build by the Gesell Gesell schaft schaft für Messund System Systemtech technik nik (GMS) [Asso [Associ ciaation for measur measuring ing and system system technol tech nol ogy] in Spaichin Spaichingen, gen, Germa Germany. ny. DAQ cards from Nation National al InInstruments stru ments were used for record re cording ing ana analog and digi digital signals. signals. The param pa rameeters such as angles, an gles, currents, currents, volt ages, and torques torques are rerecorded cord ed for each test station sta tion indi individ vidu ual ly. ly. Vector Vector inte integrat grat ed ed the four data da ta acqui acquisi sition tion boards into into the CANoe CANoe test system system (Figure (Figure 2). For standard stand ard appli applica cations tions this inte integra gration tion is real re al ized ized using using the CANoe CA Noe port link feature. feature. At that time (before (be fore version version 6.0), CANoe CANoe did not support sup port the signal signal block transfer transfer between between data data record recording ing board and CANoe. CA Noe. Thus Vector Vector devel devel oped oped a C APL APL-DLL -DLL custom cus tomized ized for the appli appli-cation, ca tion, which expand expanded ed the CAPL program programming ming language language in CANoe CANoe to include include user-de user-defined fined functions functions and inter interfa faces. ces. This DLL is used to read and condi con dition tion the measured meas ured signals signals direct direct ly ly from the input input buff er er of the hardware. hardware. This al lows lows nearly nearly real-time real-time signal sig nal process processing ing with a high sampling sam pling rate. Then these signals sig nals are forward for warded ed to the data data record recording ing within within CANoe CANoe (Figure (Figure 3). Paral Paral lel lel to the data data process processing ing via the DAQ boards, the test bench con trol acti ac tivates vates the motors mo tors depend depending ing upon upon the test scenar sce nariios using using a low-speed CAN bus or a LIN-1.3/2.0 bus.
Fig ure 2: Figure Inte In tegra gration tion of CANoe CANoe in the wiper wiper test bench
In order order to achieve the required re quired test cover coverage, age, the test bench is equipped with five indi individ vidu ual stations, stations, permit permit ting ting inde independ pendent ent opoperaation. Each station er sta tion is equipped with its own power power supply, supply, brake, and bus inter interface. face. The brake provides provides the load of the wiper wip er motor motor with a maxi max imum torque of 15 Nm. The test engi en gineer neer speci specifies the indi in divid vidu ual load in the test set up. up. The bus commu communi nica cation tion between between each test speci spec imen and the CANoe CA Noe control con trol is al so so provid provided ed sepa separate rately ly in order order to simu simulate the commu commu-nica ni cation tion charac char acter teris istics tics between between the electric elec tric motor motor and the ECU as real re al isti istical cal ly ly as possi possible. ble. Vector Vector creat creat ed ed a remain remaining ing bus simu simula lation tion for the CAN or LIN bus commu com muni nica cation tion for acti activat vat ing ing the wiper wip er momotor. Since there was not a real re al wiper wiper ECU at the begin be ginning ning of the project, the remain re maining ing bus simu simula lation tion was expand expanded ed by an addi addi-tional tion al node that simu sim ulat ed ed the charac char acter teris istics tics of the wiper wiper motor. motor. Aft er er the inte integra gration tion of the real re al ECU, this node was simply sim ply deac deacti ti-vat ed. ed. The test bench is equipped with a stand ard indus industri trial al PC for the simu sim ula lation tion and control control functions functions as well as for the eval uation of the measured meas ured signals signals in paral par al lel lel for all five test stations. sta tions. The PC is al so so respon re sponsi sible ble for acti activat vat ing ing the wiper wip er motors motors via the CAN or LIN busbuses. A CANcardXL CANcardXL and two CANboardXL CANboardXL with the appro ap propri priate ate CANcabs CANcabs or LINcabs LINcabs from Vector Vector are used as inter in terface face for the bus inter interface. face.
Per manent manent set point/actu point/actual al compar compar isons make the eval uation easier easier The test sequen se quences ces of an endur endurance ance test are custom cus tomer er specif specif ic ic and include in clude all functions functions of the wiper wiper motor. motor. For exam example, ple, an endur en durance ance test might last more than 1200 hours. The wip er motor motor is oper operat at ed ed at dif ferent ferent loads and temper temperaatures in all modes such as high and low speed, inter interval val mode, off and sleep mode.
Fig ure 3: Figure Data Da ta eval uation in the CANoe CANoe node lay er er DLL
2/9
During these tests, the moni During mon itored physi physical param parameeters such as curcur rent, rota rotation tion angle, angle, the posi position tion of the motor motor out put put shaft, and motor mo tor temper temperaature are al lowed lowed to vary within within specif specif ic ic limits limits only. only. The limits limits are speci specified as envel envel ope ope curves (Figure (Figure 4). In order order to achieve the required required accu accura racy cy for exam example ple of the RMS val ue ue of the current, cur rent, the data da ta is record recorded ed with a sampling sampling rate of up to 20 kHz. Post process processing ing of the raw data da ta redu reduces ces the data data to one single single val ue ue within with in 2 ms. A part of the eval uation is the perma permanent nent compar compariison between between the measured meas ured signals signals and the speci specified envel envel ope ope curve. The data data is tempo tem pora rari rily ly stored in a ring buff er. er. In case of devi de viaations, CANoe CANoe stores pre and post event data da ta val ues ues (logging). (logging). The data data vol ume ume is ad just able (Figure (Figure 5). The Vector Vector soft ware ware appli applica cation tion is able to record real real time bus commu communi nica cation tion between between the motor motor control control and the wiper wiper motor motor in paral par al lel lel to the measured meas ured signals. signals. If commu communi nica ca-tion errors errors occur, occur, the CANoe CANoe logging logging function function records records the measured measured physiical param phys parameeters as well as the cor re respond sponding ing bus commu communi nica ca-tion, includ including ing the pre and post event data. da ta.
Synchronous Synchro nous record recording ing of the bus commu communi nica cation tion with the physi physical measure meas urement ment val ues ues al ready ready mentioned mentioned above is the crit ical factor factor in achieving achieving the most useful useful test results. results. It has shown to be espe es pe-cial ly ly favor favoraable that the record re cording ing of the bus commu com muni nica cation, tion, the measure meas urement ment record recording ing and the control control of the test bench be done by a single single soft ware ware tool with a common com mon time basis basis (CANoe). (CANoe). CANoe is al so CANoe so respon responsi sible ble for compar comparing ing the measured measured physi physical paparameeters and the bus commu ram communi nica cation tion with the speci spec ified limits. limits. If crit ical events occur occur the results results are record recorded. ed. I.e. if defined defined limits limits are exceed exceeded ed or if switch-off crite criteria ria are reached. The lat ter ter is al so so used to switch off the test.
The clear oper op er ating ating structure structure simpli simplifies fies test config configu ura ration tion According Accord ing to the speci spec ifi fica cation tion of Valeo Valeo the Vector Vector team al so so devel devel oped a CANoe CANoe user user inter interface face to create create vari var ious test sequen se quences, ces, visu visual iza zations tions (Figure (Figure 6) and for the test bench con trol. The oper operaatorfriendly friend ly user user inter interface face al lows lows the test engi en gineers neers to create create complex complex test proce procedures dures and test sequen se quences, ces, based on time, event, or cycle. cy cle. The dif ferent ferent levels levels of the user user inter interface face support support the test engi engineer neer in speci specify fying ing a logi logical structure structure of the indi in divid vidu ual test param parameeters accord ac cording ing to the test speci spec ifi fica cations. tions. The acti activa vation tion of the climate climate chamber cham ber as a part of the test bench es is al so so inte integrat grat ed ed in the user user inter in terface. face. The status sta tus display display (Figure (Figure 7) shows the current cur rent number number of oper operat at ing ing cycles cycles and error er ror messa messages ges as well as the vio vi ola lations tions for current, cur rent, speed, or angle angle limits limits for each of the five test motors. mo tors. The Auto Automo mobile bile manu manufac factur turers ers only only tol erate erate rota rotation tion angles angles within within speciified tol eran spec erances ces in the endur endurance ance test of the out put put shaft from a revers re versing ing wiper wiper motor. motor. Thus Valeo Valeo contin continu uous ously ly moni monitors this anangle. The CANoe CANoe appli applica cation tion is able to distin dis tinguish guish dif ferent ferent levels levels of limit lim it vio viola lations. tions.
Fig ure 4: Figure Confi Con figgura ration tion of limit limit val ues ues
2/10
Fig ure 5: Figure Confi Con figgura ration tion of pre and post trigger trigger times. In case of an er ror, ror, all events which occur occur in this time window window are stored.
RELI RE LIA A BLE ENGI EN GINEER NEERING ING TEST ING I NG ON A WIPER WIP ER MOTOR MO TOR TEST BENCH
In case of low-level low-level vio viola lations tions the soft ware ware issues issues an error er ror message message (Figure (Fig ure 4). If a high-level high-level vio viola lation tion occurs occurs the soft ware ware inter interrupts rupts the test imme immedi diate ately. ly. The dif ferent ferent levels levels are ad just able in the set up. up.
from a true motor motor out put put shaft movement. movement. The elimi elim ina nation tion of false of false data da ta must occur occur rather rather fast due to the real-time re al-time signal signal compar compariison between be tween the physi phys ical angel angel signals signals and the bus commu com muni nica cation. tion.
The appli applica cation tion devel devel opers opers of Vector Vector have prepared prepared simi similar test propro cedures ce dures for the param parameeters current current and temper temperaature. The Valeo Valeo test engi en gineer neer can pre-select pre-se lect how of ten ten the limit lim it may be exceed exceed before before the soft ware ware will termi ter minate nate the test. In gener gen eral, al, each test ed ed wiper wiper motor mo tor can be start ed ed indi individ vidu ual ly, ly, i.e. it is possi possible ble to inter interrupt rupt and contin con tinue ue a test indi in divid vidu ual ly. ly. Param Parameeters such as loading load ing torque, volt age, age, or current current can be ad just ad just ed ed sepa separate rately. ly. Error Er ror logging logging stores the data da ta in small blocks, which al lows lows the test engi en gineers neers to perform per form anal y yses ses during dur ing the test. The test bench soft soft ware includes includes status status logging logging which stores the current cur rent signals signals in freely ad just able inter intervals. vals.
Dif fer fer ent ent wiper wiper test benches benches – one solu so lution tion
Compen Com pensa sation tion of en vi viron ronmen mental tal influ influen ences ces Some bounda boundary condi conditions tions made the devel devel opment opment of measure measurement ment and test al gorithms gorithms very chal lenging. lenging. For exam example, ple, the test bench is at tached tached to a climate cli mate chamber chamber for temper temperaature test ing. ing. The comcompressor press or of the chamber cham ber transmits transmits vibra vibrations tions to the test rig and the test ed ed wiper wiper motor. motor. The high-reso high-res olu lution tion angle angle sensor sensor is able to rereal ize ize the vibra vibrations tions as movements movements of the wiper wip er motor motor even thought the motor motor out put put shaft is not moving. moving. A damping damping or physi physical disdisconnec con nection tion of the compress compressor or from the test bench would be exex tremely treme ly dif ficult, fi cult, and an angle angle sensor sensor with a lower lower reso resolu lution tion would not ful fill fill the required required measure measurement ment accu accura racy. cy. In order order to compen compensate sate such errors, er rors, the measured meas ured data data are post processed proc essed using using digi digital fil tering ter ing and compared compared with speci spec ified speed limits. lim its. In case the soft ware ware detects detects a contin continu uous ously ly oscil oscil lat lat ing ing move move-ment within within certain cer tain limits, limits, it is able to dif feren ferenti tiate ate these signals signals
Aft er er the success successful ful imple implemen menta tation tion of the CANoe CANoe test appli applica cation tion in the dura durabil bil ity test bench for revers re versing ing wiper wiper motors, motors, both devel devel opment op ment part ners ners extend extend the appli ap plica cation tion to test conven convention tional al rota rotary ry wiper wip er motors. motors. While other other test benches benches moni monitor the motor motor speed and temper temperaature only, only, this appli applica cation tion improves improves the data data acqui acquisi si-tion, real-time real-time data data moni monitor toring ing and data data anal y ysis. sis. Valeo has al ready Valeo ready planned an addi ad dition tional al expan expansion: sion: the CANoe CANoe test system sys tem should be enhanced enhanced to a mobile mobile oper operat at ing ing and data data acqui acquisi si-tion system system for bus controlled controlled wiper wiper motors motors for the use in conven con ven-tional tion al test benches bench es and even onboard on board test vehi vehicles. cles. This al lows lows simsimple anal y ysis sis of wiper wiper systems systems in a wind tunnel tunnel or road test ing. ing. With the planned exten ex tension sion of the appli applica cation tion Valeo Valeo bene benefits from the large data data acqui acquisi sition tion and anal y ysis sis capa capabil bil ity of the CANoe CA Noe soft ware tool. The devel devel opment opment team just needs to speci spec ify the options options that have to be imple implement ment ed ed in the soft ware. ware. The expense ex pense is rel atively tive ly small: Valeo Valeo employ employees ees support support ed ed the Vector Vector team with their specif spe cif ic ic product product know-how and the def ini nition tion of the appli ap plica cation. tion. The “CANoe “CANoe appli applica cation tion team” from Vector Vec tor start ed ed the devel devel opment opment of the test regi reg imen, bus commu communi nica cation tion and the data da ta acqui acquisi sition tion as well as the eval uation of the test data da ta with two engi engineers. neers. Subse Subse-quent expan expansions sions has been real re al ized ized with one person per son form both part ners. ners.
Fig ure 6: Figure Confi Con figgura ration tion of test proce procedures dures
2/11
Valeo and Vector Valeo Vector clearly clearly exceed exceeded ed the ob jec ob jectives tives set for this project by react react ing ing flexi flexibly to unfore unforesee seeaable chal lenges lenges along the devel de vel opopment and imple implemen menta tation tion process. process. Further Fur thermore more they are planning plan ning an exten extension sion of the appli applica cation tion as more capa ca pabil bil ities of the CANoe CA Noe tool become become appar apparent ent during dur ing the appli applica cation tion devel devel opment. opment. During Dur ing the exe execu cution tion of the project the speci spec ifi fica cation tion had to be rede re defined fined in order or der to real real ize ize addi addition tional al test features. fea tures. Usage Usage of el egant soft ware ware solu so lutions tions al lows lows opti optimiz mizing ing the appli applica cation. tion. With the new wiper wip er motor mo tor test bench, Valeo Va leo will use the mul tifunc tifunction tional al CANoe CANoe tool as a contin con tinu uous system system plat form form from the start of the product prod uct devel devel opopment to the val ida dation, tion, thus guaran guaranty tying ing its custom cus tomers ers the deliv delivery ery of reli reliaable products. products.
Dipl.-Ing. (FH) Diet Dietmar mar Baumgärt Baumgärtner ner studied stud ied preci precision sion mechan mechanics ics at FH Heil bronn. bronn. He is mana manager of system system and compo component nent test ing ing for wiper wiper systems systems at Valeo Valeo WischerWischersysteme sys teme GmbH in Bie Bieti tigheim. gheim.
Dipl.-Ing. (BA) Ben ja Ben jamin min Dietz Dietz studied stud ied Mechat Mechat ronics ronics at BA Stutt gart gart and at the Valeo Valeo Wischer Wischersys systeme teme GmbH compa company. ny. Aft er er his studies, studies, he changed over to the test ing ing depart depart ment ment of revers reversiible wiper wiper motors. mo tors. Current Current ly, ly, he is the electron electronics ics devel de vel oper oper for advance advance devel devel opment. opment.
Dipl.-Ing. (FH) Mar co co Rommel Rommel studied stud ied electron electronics ics with an empha emphasis sis in auto au toma mation tion technol technol ogy at FH Heil bronn. bronn. He works for the Valeo Valeo Wischer Wischersys systeme teme GmbH compa com pany ny in the test ing ing depart depart ment ment and is respon re sponsi sible ble for creat creat ing ing and mana managing test ing equipment. equipment.
Dipl.-Ing. Kat ja Kat ja Hahmann Hahmann studied stud ied electri electrical cal engi engineer neering ing at TU ChemChemnitz. Aft er er her studies, studies, she began began working working for Vector Vector Infor Informa matik tik GmbH in Stutt gart gart in 1997 and is current cur rent ly ly team leader leader of the team for CANoe Application Development in the produc pro duction tion line Net works works and Distrib Dis tribut ut ed ed Systems. Sys tems.
Dipl.-Ing. (FH) Rainer Rainer Brändle Brändle studied stud ied tel ecom commu muni nica cation tion engi engineer neering ing at FH Esslin Esslingen gen and began began working working for Vector Vector Infor In forma matik tik GmbH in 2005. He is project leader lead er for vari various Valeo Valeo wiper wiper test benches benches as Senior Sen ior Soft ware ware Devel Devel opment opment Engi Engineer neer in the appli ap plica cation tion devel devel opment opment team.
Fig ure 7: Figure Cur rent rent status status of the five test speci specimens
2/12
Case Study Automating ECU Test Execution, Pass/Fail Pass/Fail Detection, and Report Generation
Nippon Seiki Co., Ltd.
The Customer
The Advantages
From the time it was founded, Nippon Seiki has extended
Test Execution Time Dramatically Reduced
its business, focusing on the development and manufactur-
Automating ECU test execution, pass/fail detection and re-
ing in-vehicle instrumentation. Nippon Seiki’s technologi-
port generation helped Nippon Seiki to successfully reduce
cal competence in this field is highly rated, and as a leading
total ECU test time from more than 18 hours to just over 12
manufacturer of instrument panels it supplies a large num-
hours. In particular, test execution time, which previously
ber of automobile and motorcycle manufacturers.
took 11 hours, has now been shortened to about 4 minutes! The more frequently testing is executed, the greater t he gains
The Challenge Reducing ECU testing man-hours while simultaneously improving quality of overall testing With 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 increased ECU testing man-hours, and their reduction has become a major issue.
The Solution Automation of ECU Testing using the CANoe Test Feature Set
in testing efficiency. Finally, use of the CANoe Test Feature Set has dramatically reduced the man-hours needed to perform the tests (see table below). A System Design Department Manager described the advantages of automatic execution like this: “There is certainly some test case implementation work to be done when automating. 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.
CANoe, provided by Vector, is used by a large number of customers 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, including 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.
(*) Test No. 2 is executed simultaneously with Test No. 1.
Table: Comparison, in relation to test case and manhours, between conventional test method and the use of the CANoe Test Feature Set Your contact at Vector: Katsuhiro Kinoshita
[email protected] www.vector-japan.co.jp
Comprehensive ECU Tests Tests with wit h Fault Simulation 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 industry. The new compact test hardware VT System from Vector meets the various challenges that face such a test system. Electronics and software have become indispensable components in the automobile. Therefore, verification of development results
reactions. Additional devices are necessary to cover fault states; they are placed in the circuit between the ECU’s ports and the origi-
not only covers the mechanical systems, but to a large extent the electronic ECUs and their software as well. The complexity of heavily networked systems places high requirements on the test process and the test tools used. Systematic and comprehensive tests are
nal or simulated sensors and actuators (Figure 2). Such test
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 trials, 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
2/14
Figure 1: Different test methods are used in the various development phases.
XXXXXXXX
components are often referred to as fault simulators. They might be used to disconnect lines to simulate line breaks, for example.
system may make fault memory entries, deactivate certain functions in the ECU or generate error messages. So the sensors and
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
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
CAN, LIN, FlexRay or MOST – it must be possible to comprehensive comprehensively ly 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
equipped with simple connection boxes for this purpose, which take the necessary components and have suitable cable connections. Similarly, original sensors and actuators are also provided to the ECUs under test on large test benches. However, automating
performance, flexibility and, last but not least, the costs of a complete test system.
In verification of ECU functionality, the primary task is to represent the ECU in an environment that mimics the real vehicle environment as closely as possible. The sensors connected to the ECU are operated to activate the functions to be tested, and the ECU’s reactions are evaluated. There are very dif ferent ways to produce a suitable 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.
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 connected components, generally a simple sensor or actuator simulation 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 processes in the connected components. In this case, however, simulation
In the simplest case, an elaborate stimulation circuit is omitted and the ECU’s inputs are operated directly by simple means, e.g. by
and test execution would require elaborate and cost-intensive test systems, and they would not always be available where they are
manual switches between specific ECU lines. The ECU’s outputs remain unconnected for the most part. Testing the ECU’s reaction
needed. This also applies to the necessary knowledge of operators.
might only involve measuring the voltage at an output, for example. Such approaches usually do not lend themselves to automatic test execution, but they are easy to perform – especially during development.
Simulation of fault situations
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
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
Challenge of functional testing
+
+
In
Sensor
controlling, stimulating
To test an ECU’s reactions to faults in the connected environment, the test system must be able to produce various fault situations.
fault injection
Out ECU under Test
CAN, LIN, FlexRay...
Automated Testsystem
Actuator
fault injection
observing reaction
Figure 2: Fault simulators are inserted between the sensors/actuators and the ECU.
2/15
forgotten, because the primary focus of developers is on the desired functions. To achieve reliability of systems, however, it is
> Sensors or actuators are damaged: sensors do not supply any values, values lie outside allowable value range, or a compo-
critically important t hat the ECUs also react properly in response to faults. In conjunction with sensor and actuator connections, it is especially important to simulate the following fault situations:
nent’s electrical properties, e.g. internal resistance or current draw, do not conform to the specif ication. > Incorrect input values, especially incorrect sensor data: from the perspective of the ECU, the sensor is operating properly and
> The electrical wiring is damaged: open circuits, short circuits to ground or battery voltage, short circuits between certain connected lines.
measured values also lie within the allowable r anges. Yet, the values are implausible or contradict other sensor v alues, and the ECU must recognize this. In all cases, the ECU must continue to work in a defined way. Furthermore, 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 – typically 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
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 individual and flexible test solutions depending on requirements.
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
Actors
VT System
ECU +
-
Power Supply
under
CANoe
Test CAN, LIN, FlexRay, ...
Sensors
2/16
Vector Businterface
Figure 4: The VT System is placed in the I/O lines between the ECU and actuators or sensors.
COMPREHENSIVE ECU TESTS WITH FAULT SIMULATION XXXXXXXX
lines – and if necessary original sensors and actuators – are connected to the modular system (Figure 4). The PC is connected to
be operated simultaneously. This enables simulation of multiple faults and more complex operating processes.
CANoe via a fast Ethernet-based real-time network. This makes it possible to assemble flexible test systems without great integration or wiring effort. The VT System is well-suited to both small test setups at a developers’ desk as well as comprehensive test benches
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-
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
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,
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. driving motors via an H-bridge in the ECU. The measurement and stimulation devices contained in the modules 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 modules serve to connect the ECU lines to the attached or iginal sensors and actuators. It is relatively easy to set incorrect sensor data with original sen-
short circuits only occur at adjacent pins on the connector. In the VT System, the necessary switching options are once again available 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 effor t 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 output for use in an actuator simulation or load simulation. In simulating faulty sensors, the sensor simulations described above are
sors, since here the sensors just need to be operated to be implausible. However, the number of conceivable value combinations is
implemented as a resistor decade or output voltage. If there are not enough integrated components for a test, it is possible to con-
large. For systematic testing, a high level of automation is therefore desirable; to make it possible to reproduce as many fault pat-
nect external load simulations, sensor simulations or measurement and test instruments via bus bars.
terns as possible within a short period of time. Therefore, one approach is to replace the original sensors by electronic simulations. They are present on the V T modules for each channel and can be controlled in any desired way by CANoe as a test system.
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 interface to the test automation tool. In CANoe, after a simple configu-
The sensors are simulated by a resistor decade or a voltage output with relevant signal conditioning. There are stimulation units for each of the VT System’s I/O channels, so that all ECU inputs can
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
Figure 5: All components needed to test an ECU’s I/O channel are contained in the VT modules.
2/17
(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 seamlessly integrated in the CANoe test environment.
Literature and links: [1] Riegraf; T., Beeh, S.; Krauß, S.: Effizientes Testen in der Automobilelektronik [“Efficient Testing in Automotive Electronics”]. ATZ (Volume 108), Issue 7-8, 2007, pages 648-655 [2] http://www http://www.vector.com/can .vector.com/canoe oe
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 e valuating the reactions 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 switching as well as their simulation. It also offers the equipment needed to create the dif ferent fault situations. These functions and properties 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 department until 2001. Since 2002 he has been employed at Vector Informatik GmbH in Stutt gart, 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.
2/18
2/19
Semi-Synthetic Regression Tests with Real-World Data Reducing Reduc ing 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 i ts software testing of electrical power steering units by using the methods of limit value and effects analysis to reduce the number of test cases. Its practical implementation involves simulating driving maneuvers from the real world that are used as a reference.. This article reference ar ticle describes how to reduce the set of all theoretically possible test cases and to implement tests with a development and testing tool. Now more extensive, time-consuming and therefore more costintensive tests and simulations are necessary, especially when software 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
for the driver according to the situation. The system (Figure 1) only operates and only consumes energy when the driver turns the
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
2/20
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.
steering wheel. An EPS offers better control and contributes to improved fuel economy and reduced emissions. For the driver, it is
several years to test. Practical testing would therefore require that the sum of all possible input combinations be reduced to just a few
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,
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
they just irritate the driver; in other cases, unlikely input signals might cause serious malfunctions, including complete failure of t he EPS, that would impair driving safety. Thus whenever the software is changed, reevaluating it is essential by running regression tests
analysis to find those signals that have the greatest impact on system 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.
to reveal changes in steering behavior between different software levels.
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.
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
Real-world data instead of high-cost HIL
system. The sheer number of possible combinations of input parameters yields an incredible number of test cases that would take
real vehicle tests. This involves logging the bus traffic in the vehicle by laptop with CANoe, the test and simulation tool from Vector
In practical tests on the HIL test bench, semi-simulated driving maneuvers (replaying and calibrating recorded real dr iving maneuvers) 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
Figure 2: Reducing the number of test cases by knowledge integration
2/21
(Figure 3). This “real world data” can then be replayed 1:1 on a test bench to recreate the EPS as a virtual environment.
system developed by Daimler, the logged measurement data are sent to a Replay block in CANoe f or playback (Figure 4). In the first
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 vehicle speeds, different engine speeds, friction values or modified
branch, a blocking f ilter 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 analog voltages. This is done with the help of the script language CAPL
manual steering torques. To do this, it is necessary to set and adjust certain parameters during the simulations. In the test
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 t arget 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, second, 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 fr iction and rolling resistance. The HIL measurement data (Figure 5) can be conveniently analyzed offline with Matlab/Simulink. To do this, CANoe exports the target and actual values in .mat format. So far, no online evaluation has been necessary, but it would be possible by integrating the
Figure 3: Test setup for logging real bus communication, driving the HIL and evaluating measured values.
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 4: Various internal processing blocks are used to log and replay the data in CANoe.
2/22
SEMI-SYNTHETIC REGRESSION TESTS WITH REAL REAL-WORLD -WORLD DATA
in the real vehicle, since unanticipated risks for driver and vehicle have now been reduced to a minimum.
and those that are smaller, with each performing a test in that range. The equivalence class method is prescribed by IEC 61508/ISO 61508/IS O 26262. 26 262.
Summary Limit Analysis The testing approach for evaluating software levels and revisions
This is based on the equivalence classes, where the primary
described here met Daimler’s expectations for the project. Suitable
focus is on the limits or extremes of the value ranges, e.g. maximum defined signal values, steering torques, etc. Experience 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.
test methods combined with intelligent knowledge integration reduce the theoretically possible number of test cases to just a few conceivable 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 effor t. Instead of computing driving situations and effects analysis with a complex, exact vehicle model in cost-intensivee HIL systems, logged real-world data is used, which can cost-intensiv
Pairwise Method
be modified in semi-simulated driving maneuvers. maneuvers. The simulation and
This 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 combinations, it makes sense to select combinations with knowledge integration, to focus on typical input combinations of the application in question.
test system CANoe provides valuable services here; it runs on a laptop, 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, replaying, filter ing 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 positive 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 dr ives at any time.
Figure 5: Real measured target values are compared to HIL output values in Matlab.
Equivalence Class Method Equivalence classes are made up of input or output values presumed 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-
Andreas Herp (Graduate Engineer), studied electrical engineering at the University 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 development of electrical power steering, and he directed the thesis work by Mr. Herbert.
Michael Herbert (Graduate Engineer), studied electrical engineering and information 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.
Oliver Falkner (Graduate Engineer), studied electrical engineering at the University of Stuttgart. After graduating, he joined Vector Informatik GmbH in Stuttgart in 1999, where he is currently senior product management engineer in product management of the Networks and Distributed Systems product line.
vided into values that are larger than the valid value range
2/23
Model-Based Testing for Better Quality 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 commercially available since 2007. 2007. The automatically generated test cases simplify regression tests during iterative developd evelopment of complex models. Transformations make it possible to re-use the test cases that are generated, e.g. in ECU acceptance testing, so that test cases do not need to be recreated manually. manually. This results in considerable savings in time and cost for functional developers. Software engineering is a discipline of computer science that has
requirements. The test specification should be used again to verify
great innovative potential. Great software complexity and the overabundance 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 automatic generation to produce a large share of the test documentation. 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 specification, tests are implemented to verify proper software implementation in the ECU (Figure 1).
the functional model. This process reveals errors and inconsistencies in early development phases, which can then be corrected at a fraction of the cost of correcting them later, after system or acceptance 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
Over the past five years, automotive OEMs have been applying more and more model-based methods to develop embedded soft-
generated test cases and which advantages they offer in the development of embedded vehicle systems. The new approach can be
ware. One possible approach that integrates these model-based methods into the development process is one in which the software
used during iterative development of functional models to automatically generate test cases for regression tests, for example.
is manually implemented in the ECU while functional models are created in parallel (Figure 1). The development of executable functional models represents a quality improvement in requirements analysis and development. First, the functional models define func-
Another possibility is to re-use the test cases generated from this development phase in later testing phases of the development process, such as in ECU acceptance tests (Figure 1).
tions and then validate them with respect to the given
Figure 1: Comparison of different approaches to developing ECU software
2/24
Test case generators simplify regression tests
coverage entails immense effort, because if there are coverage gaps, the related code sections must be analyzed, and other
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-
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.
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 process, the developer must ensure that changing a functional model
One answer lies in the use of new commercially available test case generators, such as Simulink Design Verifier from The Mathworks or Telelogic Rhapsody ATG from IBM. Test cases are automatically generated after specifying a specific code coverage to be
does not introduce any new errors or undesirable effects on functionality. 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
attained. The test cases then increase the quality of the comparison. In addition, the tools can often simultaneously generate an MiL test environment, execute test cases and automatically generate 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 Model-in-the-Loop test environment. Functions are modeled in Simulink/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
A key aspect of regression testing is the quality of the comparison of a modified functional model with its previous version. One measure of this quality is code coverage, which is why comparing different versions of a functional model requires the greatest possible coverage. In test cases related to requirements, greater code
Figure 2: Setup of a Modelin-the-Loop test environment for regression tests in MATLAB/Simulink. A script generates test reports and automatically adapts their output format
2/25
Unit” system under test. This represents the modified functional model. The “Expected Results” block contains the reference outputs
advantage here is that the test cases do not need to be manually re-created.
from the previous version of this functional model. In the “Regression Test Analyzer” block, the newly generated outputs of the modified functional model are compared to the reference outputs at each step of the simulation. After the test run, a script automati-
A tester wanting to re-use the test cases may find that changing the test environment from Model-in-the-Loop (MiL) to Hardwarein-the-Loop (HiL) also shifts test boundaries. Test cases in the MiL test environment refer back to the logical input and output signals
cally creates the test report and adapts it to the desired output format. 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
of the functional model. Test cases in a HiL test environment, on the other hand, require physical signals, e.g. C AN signals, to stimulate the system and ev aluate system behavior. It is therefore necessary to transform the test cases, which involves mapping logical
an error. The iterative approach presented here is an efficient way to support 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 accept ance testing.
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-
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-
ically generated test report helps in evaluating the test results. All necessary steps in this tool chain can be automated, which yields
cation. To perform an acceptance test, suitable test cases must be created which test the specified functionality. Clearly, one poten-
time and cost savings. Acceptance testing with reusable test cases now tests both the
tial way to reuse the test cases generated from model-based development is in a Hardware-in-the-Loop test environment. The
software integration and the hardware-software integration. Testing 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 transformatio n of the test cases.
2/26
MODEL-BASED TESTING FOR BETTER QUALITY
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 additional 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 modelbased function development with functional descriptions in MATLAB/Simulink. Use of model-based test methods is being studied 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 semiformal description languages such as the Object Constraint Language (OCL) and temporal logic methods can be used to generate test cases via model transformations [2]. The use of formal description 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.
Wolfgang Hartig (M. Eng.), obtained his Master of Engineering degree in Electrical and Microsystems at the University of Applied Sciences in Regensburg. He conducted 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, Today, he is employed in the area of Technical Consulting and Engineering Services at Vector. E-mail:
[email protected] 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. Habermann is project manager for the eASEE process tool in the Customer Service area 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, programming languages, operating systems and functional fu nctional safety. He directs the Laboratory for Safe and Secure Systems (LaS 3), is a member of the advisory board of the Bavarian Cluster of IT Security and Safety, and active in other working committees. E-mail:
[email protected] juergen.mottok@ e-technik.fh-regensbur -regensburg.de g.de
Literature references: [1] Liggesmeyer, P.: P.: Soft ware-Qualität, 2002 [2] Laboratory for Safe and Secure Systems LaS 3, VitaS3 research project, (www.las3.de/englisch/forschu (www.l as3.de/englisch/forschung/forschungsproj ng/forschungsprojekte.html) ekte.html)
2/27
Efff icient Airbag Ef Airbag ECU Tests Tests 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 airbag control unit is responsible for proper operation of the entire occupant restraint system, consisting of all sorts of airbags, belt tensioners, sensors and switches. Even during product development, numerous validation tests are indispensable at all development stages. A new test system at the Robert Bosch company increases eff iciency in early test phases in development; it shortens test times ti mes while simultaneously increasing testing depth. It also reduces the number of test iterations for system tests on existing existi ng HIL test benches. 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
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,
system components involved such as squibs, sensors, switches and the airbag control unit itself. Fault conditions are stored in fault
mobile airbag test system. The goal was to obtain a flexible system that implements the requirements of early test phases more cost-
memory and can be read out in the service garage. The test system presented here focuses less on crash-triggering
effectively than powerful HIL systems (Figure 1), and which is well-suited to worldwide use at all Bosch development sites for air-
tests, and more on validation of software requirements derived from customer and internal requirements. In addition, the test
bag systems.
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
2/28
Requirements of the new test system
generating short circuits between lines and to different voltages, for example. Resistor decades simulate the operating ranges of
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 SoftwareEntwicklung & Elektronik (TBM). In the joint planning phase, it w as
squibs and seatbelt switches in this application. The test system must also simulate connection of the wrong lines as well as overvoltages and undervoltages. This involves use of an integrated voltage supply to run through various individually programmable volt-
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
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-
majority of the sof tware 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
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 application 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
Figure 1: Use of the new test system in the V-Model
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).
Figure 2: Layout of the test system
2/29
In creating the test sequences, it is often very advantageous to be able to address ECU pins by meaningful names. Mapping tables
At the Bosch company, the test system was systematically further developed and a test control was implemented for individual,
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,
manually executed tests, for example. The system offers a graphic CANoe operating panel for this pur pose, and this renders the previous manually operated test hardware unnecessary.
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
The results
evaluate CAN messages, e.g. in testing the ECU’s error memory. Additional CAPL convenience functions are used to search for a specific 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 u sed. This makes it possible to use symbolic descriptors for diagnostic services and parameters in all projects. The Bosch airbag ECUs also support production diagnostics – an internal company diagnostic protocol. Production diagnostic services are already integrated in ECU implementations 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
les and configurable warning lamps. It is universally applicable for the airbag ECUs of most OEMs, vehicle lines and equipment variants, 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 behavior. 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 completed 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
detail is set separately for each test run.
modifications to the overall test system.
The new test system – subcontracted by Bosch and implemented by Vector and TBM – includes project-dependent squibs, seatbelt buck-
Figure 3: Components of the CANoe configuration
2/30
VALIDATING SOFTWARE REQUIREMENTS BY EFFICIENT AIRBAG ECU TESTS
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 development means that errors in the airbag ECUs can be detected and corrected 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 airbag 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 airbag test system. An airbag triggering process consists of a sequence of highly precise, interrelated and coordinated individual actions. Sensors 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 ignition 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 pyrotechnical propellant charges that generate a lot of gas in a short period of time.
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: david.oberschmidt@fr
[email protected] .bosch.com
Frank Böhm (Dipl.-Ing. (FH)) studied Automotive Engineering at the University 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/81 +49- 711/811-20939 1-20939 E-mail:
[email protected] [email protected] m
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 MaxPlanck-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 validation in the Airbag area. Tel. +49-711/81 +49-711/811-24324 1-24324 E-mail: mar
[email protected] [email protected] sch.com Katja Hahmann (Dipl.-Ing.) studied Electrical Engineering at the Technical University of Chemnitz. Since 199 1997 7 she has been employed at Vector Informatik GmbH in Stuttgart where she is group manager for CANoe application development in the Networks and Distributed Systems product line. Tel. +49-711/80670-459 E-mail:
[email protected] [email protected] om
2/31
Vehi hicle cle Diag Diagnos nostics tics – The whole Stor Stor y Ef f icien ciency cy gains by standard standardiiza zation tion and the use of tool-support tool-support ed ed process processes es in diag di agnos nostic tic devel devel opment opment The de vel de vel opment opment and intro in troduc duction tion of new diag diagnos nostic tic conconcepts and diag di agnos nostic tic solu solutions tions of fer fer signif signif icant poten potential tial to auto automo motive tive OEMs and suppli sup pliers ers for real real izing izing ef ficien ficiency cy gains and qual ity improve improvement. ment. Growing Growing complex complexiity in auto au tomo motive tive electron electronics ics can only only be mastered mastered – techni technical cal ly ly and econom economiical ly ly – by use of nonpro non propri prieetary standards standards such as ODX, close coop co oper er ation and power power ful ful tools. This ar ticle ticle of fers fers an over view of topics top ics rel e vant to the past, present and future fu ture of auto automo motive tive diag diagnos nostics tics as present pre sent-ed and discussed discussed in Octo Oc tober ber 2006 before before an audi audience ence of 350 par tici ticipants at the Vector Vector Congress Congress in Stuttgart. Stuttgart. 20 years of auto au tomo motive tive network networking ing and diag diagnos nostics tics The fast growth of electron elec tronic ic functions functions in vehi vehicles cles during dur ing the secsec ond half of the 1980s at first led to many in su sular lar solu solutions tions that prepre vent ed ed compre comprehen hensive sive concepts concepts from taking taking hold in the area ar ea of electri elec trical/elec cal/electron tronic ic archi architec tectures. tures. At the begin beginning ning of the 1990s a consol con sol ida dation tion phase began began that was marked by devel de vel opment opment of electri elec trical/elec cal/electron tronic ic structures structures and asso associ ciat at ed ed net working working topol topol ogy from a compre comprehen hensive sive perspec perspective. tive. This meant that electri elec tri-cal/electron cal/elec tronic ic content content and its net working working could claim an undis un disput put ed posi position tion in the vehi vehicle. cle. The recog recogni nition tion that many functions func tions could only only be imple implement ment ed ed sensi sensibly bly with the help of electron elec tronics ics al so prevailed. prevailed. So the image image of electron electronics ics transformed trans formed from being being a neces nec essa sary ry evil to being being a key to new, inter interest est ing ing and inno innova vative tive functions. func tions. The three bus nodes in commer com mercial cial vehi vehicles cles in 1989 have become be come more than 70 today today in simi similar larly ly equipped vehi vehicles; cles; see FigFigure 1. The under un derly lying ing soft ware ware amounts to about 10 mil lion lion lines of program pro gramming ming code.
This trend has not been with out conse consequen quences ces for diag diagnos nostics tics eieither. Twenty Twenty years ago the diag diagnos nostic tic capa capabil bil ity of a function function was not even consid considered ered until until short ly ly before before produc production tion startup. star tup. Today Today basic ba sic diag diagnos nostic tic functions functions usual usual ly ly exist exist as early ear ly as in the B-Sample. B-Sample. Handling Han dling of diag diagnos nostics tics has improved improved signif signif icant ly. ly. In the times of flash codes the process proc ess required required that users users tedi tedious ously ly count the number num ber of flashes flashes and convert convert them to error er ror codes based on print ed-out tables. tables. Today Today test ers ers out put put instruc instructions tions in clear text. In the past it was possi pos sible ble to do without without tool support support entire entirely. ly. ToToday power powerful ful diag diagnos nostic tic tools are an every everyday day real real ity. It is possi pos sible ble to create create the diag diagnos nostic tic speci specifi fica cation, tion, gener generate ate ECU-specif ECU-specif ic ic code and param parameeter terize ize the diag diagnos nostic tic test er er util izing izing the “single “sin gle source princi prin ciple”. ple”. A precon precondi dition tion is that speci spec ifi fica cation tion of diag diagnos nostics tics must be shift ed ed to the begin be ginning ning of the devel de vel opment opment process process (Front loadloading); see Figure Figure 2. The ODX format for mat al so so ena enables cross-OEM exchange exchange of diag diagnos nostic tic data. data.
Fig ure 1: Figure De vel De vel opment op ment of electron electronic ic netnetworking work ing based on the exam ex ample ple of the E-Class model model series series W210 (1995) and W211 (2002).
3/0
From propri proprieetary diag diagnos nostic tic tool to standard standard tool chain The devel devel oping oping trend of diag diagnos nostic tic tools is simi sim ilar to the trend of electron elec tronics ics in the vehi ve hicle. cle. Back in 1990 auto automo motive tive OEMs creat cre at ed ed their own tools in-house. Special Spe cial ists ists in dif ferent ferent depart depart ments ments cuscustomized tom ized their tools precise pre cisely ly to their require requirements ments and specif spe cif ic ic apapplica pli cations. tions. This produced pro duced indi individ vidu ual in-house solu so lutions tions within within each OEM and even for dif ferent ferent process process steps. About 1995 auto automo motive tive OEMs came around to a new way of think ing, i.e. that they want ed ed to once again focus focus more on their core business. busi ness. Accord According ingly, ly, tool devel devel opment opment was out sourced sourced to exter exter-nal service service provid providers. ers. Ini Initial ly, ly, these out sourcers sourcers produced produced special special in-house solu solutions tions as well, but they succeed suc ceeded ed in reduc reducing ing the dif feren fer ences ces between between tools and standard stand ardiz izing ing exist exist ing ing solu solutions tions within within certain cer tain limits. limits. This trend contin con tinued ued until until open, nonpro nonpropri prieetary didiagnos ag nostic tic tools became became avail able on the market mar ket in the year 2000. For users, us ers, the route of product product licens licenses es is notice no ticeaably more cost-ef fect fect ive than assum assuming ing respon responsi sibil bil ity for devel devel oping oping and maintain maintaining ing propri pro prieetary tools in-house. Moreover, More over, there are shared bene ben efits due to syner synergis gistic tic ef fects fects of the combined combined expe experi rience ence of other other market market partic par ticiipants. In 2005 the tools began be gan to support support gener general al standards. standards. Contem Con tempo pora rary ry tools of fer fer standard standardized ized inter interfa faces ces that can be seamless seam lessly ly inte integrat grat ed ed into into exist exist ing ing tool chains.
Old and new standards stand ards for diag di agnos nostics tics Standards current Standards current ly ly in the spot light light include include the diag diagnos nostic tic data data model mod el per ISO 22901-1 ODX (Open Diag Diagnos nostic tic Data Data Exchange, Exchange, ASAM ASAM MCD-2D), the hardware hardware inter interface face per ISO 22900-2 (D-PDU API) and
the inter interface face between between the runtime run time system system and the test appli ap plica cation tion per ISO 22900-3 (ASAM (ASAM MCD-3D, D-Server D-Server API). Each of the proprogramming gram ming inter interfa faces ces mentioned mentioned are avail able to the user us er as soft ware librar libraries. ies. Al so so worthy wor thy of mention mention are the diag diagnos nostic-rel tic-rel evant standards stand ards per SAE J2534 and in the context context of AUTO AUTOSAR SAR standard standardiization za tion AUTO AUTOSAR SAR WP4.2.2.1.4 (DCM, DEM). Further Furthermore, more, the UDS didiagnos ag nostic tic proto protocol col per ISO 14229-1 (Unified (Unified Diag Diagnos nostic tic Servi Services on CAN) will gradu gradual ly ly replace replace older older proto protocols cols such as the K-Line per ISO 9141-2 and “KWP2000” as well as “KWP2000 on CAN”; see Fig ure 3.
Char acter acter istics istics of modern modern diag diagnos nostic tic solu solutions tions The devel devel opment opment of compre comprehen hensive, sive, homo homoge gene neous ous diag diagnos nostic tic solu solu-tions is a chal lenge. lenge. It requires re quires studies studies and ef forts forts on many dif ferferent levels, levels, in order order to sat isfy isfy all require requirements ments under under one roof. On the one hand, this involves in volves ration rational al ly ly creat creat ing ing power powerful ful diag diagnos nostic tic systems sys tems and on the other oth er hand devel devel oping oping a user-friend user-friendly ly apapproach. It is only only possi possible ble to real real ize ize these two goals with a univer uni ver-sal, complete complete and practi practical cal diag diagnos nostic tic tool chain. Solu So lutions tions must be speciified, imple spec implement ment ed ed and docu document ed ed for both the overall over all vehi vehi-cle diag diagnos nostic tic system system and diag diagnos nostics tics for specif specif ic ic ECUs. Further Fur ther-more, consist consist ent ent manage management ment and distri dis tribu bution tion of diag diagnos nostic tic data data must be assured. assured. That is because be cause the appli ap plica cations tions of diag diagnos nostic tic sosolutions lu tions range from the devel de vel opment opment process process with its many dif fer dif ferent ent areeas of focus, ar focus, to qual ity assur assurance ance in produc production tion and final final ly ly diag diag-nostics nos tics in the service serv ice garage. garage.
Fig ure 2: Figure Diag Di agnos nostic tic tool chain based on single-source sin gle-source princi principle ple util izing iz ing standard stand ardized ized exchange exchange for mats. mats.
3/1
The above-named standards standards serve as a founda foun dation tion and building building blocks for imple implemen menta tation tion of such compre comprehen hensive sive diag diagnos nostic tic syssystems. They bene benefit indi individ vidu ual market market partic par ticiipants without without restrain restrain-ing nat ural compe competi tition. tion. Besides Besides achieving achieving cost reduc reduction, tion, standstandardiiza ard zation tion brings the user user addi addition tional al advan advanta tages ges such as inter in ter-changeaabil ity of products, change products, compo components nents and data. data. It can be expect ex pect ed that even more standards stand ards will be creat cre at ed ed in the future, future, which in turn will af fect fect the tools used.
the standard standardiiza zation tion commit commit tee. tee. For suppli suppliers, ers, for exam example, ple, it is crucrucial that they be capa ca pable ble of handling handling pro jects for dif ferent ferent auto automo mo-tive OEMs with one and the same diag di agnos nostic tic tool. And to accom accomplish plish a gentle gentle migra migration tion from the exist exist ing ing solu solution tion to the standard stand ardized ized diag di agnos nostic tic system, system, special special tempo temporary rary measures measures are of ten ten neces necessa sary ry during dur ing a transi tran sition tion time. In the intro in troduc ducto tory ry phase for new standstand ards it is impor im portant tant to support support mul tiple tiple paral paral lel lel versions versions in a conconsist ent ent way.
Practi Prac tical cal capa capabil bil ities are trump
Openness Open ness for progress and inno in no va vation tion
In intro introduc ducing ing modern modern diag diagnos nostic tic tools, focus focus on the needs of users users is of funda fundamen mental tal impor importance tance for their accept ac cept ance. ance. The user user should not be confront confront ed ed with the full complex com plexiity of the standards. stand ards. Rather Rather it makes sense to present a diag di agnos nosti tical cal ly-driven ly-driven perspec perspective tive of the data da ta to the user. user. Special Special knowl edge edge of the under underly lying ing data data format format should not be neces nec essa sary. ry. It is al so so impor important tant to opti op timize mize typi typical rerecurring cur ring work steps by guiding guiding the user us er in perform per forming ing the neces necessa sary ry tasks correct correct ly, ly, consist consist ent ent ly ly and with time savings. sav ings. In partic par ticu ular this includes includes avoiding avoiding redun redundant dant process processes es and wherev wherever er possi possible ble reus re using ing al ready ready exist exist ing ing data data mate materi rial. al.
Even if standard standardiiza zation tion and inno innova vation tion seem to be two irrec ir recon oncil cil able goals at first glance, au to tomo motive tive electron electronics ics is charac char acter terized ized by contin con tinu ual devel devel opment. opment. Progress is one of the most im por portant tant key perform per formance ance indi indica cators tors for auto automo motive tive OEMs and suppli suppliers. ers. ThereTherefore expand expandaabil ity of current current ly ly used tool chains is al ways ways in dedemand, so that inno in nova vations tions and function functional al ities of future future standards standards can be util ized ized or test ed ed in advance. advance.
Flexiibil ity in handling Flex handling custom customer-spe er-specif cif ic ic features features In all of the ef forts forts to achieve uniform uni formiity and standard standardiiza zation tion in creat cre at ing ing power powerful ful tools, it is impor im portant tant not to lose sight of flexi flex ibil ity. Current Current diag diagnos nostic tic standards standards of fer fer a certain cer tain degree degree of lat itude that can be exploit exploit ed ed to address address supple supplemen mental tal require requirements ments not covered cov ered by the standard. standard. These include in clude custom customer-spe er-specif cif ic ic features features and conven conventions tions or special special wishes wishes not support support ed ed by the ma jor joriity of
Enough ideas and tasks still remain re main to ensure ensure that in the future fu ture auautomo to motive tive electron electronics, ics, net working working and diag diagnos nostics tics will contin continue ue to improve im prove on the achievements achievements of the last 20 years and adapt them to new require requirements. ments. It must be assumed as sumed that the pace of inno in nova vation tion will accel accel erate erate even more, and even closer clos er col labo labora ration tion will be neces nec essa sary ry between between auto automo motive tive OEMs, suppli suppliers ers and tool produc producers. ers. This al so so pertains per tains to a common common approach approach in deal ings ings with legis leg isla la-tive bodies. bodies.
Fig ure 3: Figure The most impor im por tant tant applied applied netnetworking work ing and diag di agnos nostic tic technol technol ogies over the past 15 years.
3/2
VEHI VE HI CLE DIAG DI AGNO NO S TICS – THE WHOLE STORY STO RY
Uni ver ver sal sal and auto automat matic ic tool chain Similar Simi larly, ly, there is much future fu ture poten potential tial for diag diagnos nostics, tics, now that it has succeed succeeded ed in quasi quasi evolving evolving from a “minor “mi nor append appendage age to funcfunctions” to a “function “function in its own right”. This sig ni nifies fies the step from simul si mul tane ta neous ous devel devel opment opment to inte integrat grat ed ed devel devel opment, opment, which rere sults in even closer clos er coop cooper eraation between between diag diagnos nostic tic and function functional al devel de vel opers. opers. For the diag diagnos nostic tic system system a model-based model-based approach approach al so so came to frui fruition, which applies ap plies knowl edge edge acquired acquired from FMEA (Fail ure ure Mode and Ef fects fects Anal y ysis) sis) for exam example. ple. Tools like DaVin DaVinci ci and CANde CANdelaS laStu tudio dio from the Vector Vector Infor Informa matik tik compa company, ny, IQ-FMEA and Mat lab/Simu lab/Simulink ena enable diag diagnos nostic tic design design strat egies util izing izing a univer uni versal sal and auto automat mat ed ed tool chain, from model model ing ing tool to author au thor-ing system. system.
Diag Di agnos nostic tic de vel opments opments at Daimler Daimler Chrysler Chrysler DaimlerChrys Daimler Chrysler ler AG and Vector Vec tor Infor Informa matik tik GmbH have expand expanded ed their close coop co oper eraation over the past sever sev eral al years, includ including ing in the area ar ea of diag diagnos nostic tic tools. Easy and conve con venient nient use of tools and dede scription scrip tion of all diag diagnos nosti tical cal ly-rel ly-rel evant data data in a uniform uniform format format are impor im portant tant princi principles ples of their joint pro pro jects. Data Data and diag diagnos nostic tic functions func tions are only only formal formal ly ly speci specified once in the solu so lutions, tions, which are based on the “single-source “sin gle-source princi principle”. ple”. Therefore Therefore they are uniuniversal ver sal ly ly avail able to all project par tic ticiipants and suppli suppliers ers in mama chine-readaable XML descrip chine-read description tion files; see Figure Fig ure 2. In CANdela CANdela (CAN diag diagnos nostic tic envi environ ronment ment for lean appli ap plica cations) tions) Vector Vec tor Infor Informa matik tik structured structured its diag diagnos nostic tic product product line-up with suf ficient fi cient flexi flexibil ity so that OEM-specif OEM-spe cif ic ic export export formats formats could be
integrat inte grat ed. ed. DIO DIOGENES, the Daimler DaimlerChrys Chrysler-spe ler-specif cif ic ic descrip description tion dadata format, format, is al so so auto automat mat ical ly ly gener generat at ed ed and is then processed proc essed by the uniform uniform diag diagnos nostic tic runtime runtime system. sys tem. The require requirements ments and exex peri pe rien ences ces of other other coop cooper eraation part ners ners such as OPEL/GM and agri ag ri-cul tural tural machine machine produc producer er CLAAS have had signif sig nif icant influ influen ences ces on the CANdela CANdela approach approach too. In the meantime mean time Vector Vector has al so so been working work ing togeth together er with compa companies nies such as Fiat, Fi at, Ford and numer numerous ous auto au tomo motive tive suppli suppliers ers worldwide. worldwide.
Handling Han dling special special project-specif project-specif ic ic features features with templates templates In formal formal diag diagnos nostic tic descrip description tion templates, templates, or just templates, tem plates, are impor im portant tant servi services for taking taking into into consid consider eraation specif specif ic ic require require-ments of the manu man ufac factur turer, er, project and vehi vehicle cle model. model. Ful ly ly speci specify fy-ing diag diagnos nostics tics at a very early ear ly time prevents pre vents most misun mis under derstand stand-ings, errors errors and it era erative opti optimi miza zation tion loops in the diag di agnos nostic tic dedevel opment opment process. process. The use of CANdela CAN dela is firmly firmly estab established lished in the devel de vel opment opment process process at Daimler DaimlerChrys Chrysler. ler. ECU suppli suppliers ers not only only dedevel op op the diag diagnos nostic tic functions functions in the ECU; they al so al so supply supply the asassoci so ciat at ed ed formal formal descrip descriptions. tions. Of ten ten standard standard soft ware ware compo components nents are used to imple implement ment diag diagnos nostics tics in the ECU. The diag di agnos nostic tic comcomponent po nent CANdesc CANdesc (CAN diag diagnos nostic tic embed embedded ded soft ware ware compo component) nent) can be auto au tomat mat ical ly ly gener generat at ed ed from the CANdela CAN dela data; data; see Figure Figure 2. This gives ECU and vehi ve hicle cle produc producers ers a way to achieve uniform uni form imple im plemen menta tation tion of the diag diagnos nostic tic proto protocol col across all products. products.
ODX exchange exchange for mat mat and UDS diag diagnos nostic tic proto protocol col The inter interna nation tional al standard standard ODX (Open Diag Diagnos nostic tic Data Data Exchange) Exchange) serves as the standard stand ard for exchang exchanging ing data data and nearly nearly all diag diagnos nos--
Fig ure 4: Figure Complex Com plex bus network networking ing in the LEX ION ION combine com bine har vest vester. er.
3/3
tic infor informa mation tion between between indi individ vidu ual tools, as well as between be tween auto auto-motive mo tive OEMs and suppli sup pliers. ers. It is being be ing devel devel oped oped within within the ASAM ASAM standard stand ardiiza zation tion body (Asso (Associ ciaation for Standard Standardiiza zation tion of Auto Automa ma-tion and Measur Meas uring ing Systems) Systems) and is expect expect ed ed to be released released as ISO standard stand ard 22901-1 in 2007. Daimler DaimlerChrys Chrysler ler plans to replace re place its own DIO DI OGENES format format by ODX on future future pro jects. The CANdela CANdela approach approach handles handles import import and export export of ODX data data and enaables a smooth transi en tran sition tion from propri proprieetary formats formats to the standstand ardized ard ized exchange exchange format format for suppli suppliers. ers. Moreover, Moreover, the Vector Vector Tools CANoe, CA Noe, CANa CANape, pe, CANdi CANdito to and CANde CANdelaS laStu tudio dio support support the new UDS diag di agnos nostic tic proto protocol col (ISO 14229), which Daimler DaimlerChrys Chrysler ler is intro introduc duc-ing in all of its corpo cor porate rate divi divisions sions on each succes successive sive model model change begin be ginning ning with the current cur rent C-Class where it will replace replace the previ previous ous KWP2000 proto protocol. col. Daimler DaimlerChrys Chrysler ler is rely re lying ing on the standard standard ODX-F format for mat for describ describing ing the flash data data too. This is done with the flash data da ta manage management ment tool CANde CANdela laFlash Flash from the CANdela CAN dela product product line.
In its diag diagnos nostic tic devel devel opment opment process process CLAAS runs through the VModel Mod el with the CANdela CAN dela tool chain. CANde CANdelaS laStu tudio dio is used to create create the speci specifi fica cation tion of diag diagnos nostic tic function functional al ity consist consist ent ent ly. ly. The capcap tured data data are used direct direct ly ly to gener generate ate the ECU-specif ECU-spe cif ic ic diag diagnos nostic tic soft ware ware compo component nent with CANdesc. CAN desc. To param parameeter terize ize the test er er CLAAS util izes izes ODX data data export export ed ed by CANde CANdelaS laStu tudio, dio, Figure Figure 5. For a half year now CLAAS has al so al so been using using CANoe CANoe Option Option DiVa DiVa (Diag (Di agnos nostic tic Inte Integra gration tion and Val ida dation tion Assist Assist ant). ant). DiVa DiVa makes it possi pos sible ble to auto automat mat ical ly ly gener generate ate and exe execute repro reproduc duciible test cases cas es for imple implemen menta tation tion and inte integra gration tion of the diag diagnos nostic tic proto proto-col. Serving Serving as require requirements ments are inter internal nal CLAAS test speci spec ifi fica cations tions and the diag diagnos nostic tic data database. base. Suit ably config configured, ured, DiVa DiVa permits permits test scenar sce nariios of var y var ying ing depth and inten intensi sity, ty, e.g. compre comprehen hensive sive tests or just tests of specif specif ic ic servi services. The program program out puts puts detailed detailed HTML test reports re ports for error error anal y ysis sis purpos purposes. es. In the future, fu ture, auto auto-mat ed ed test ing ing with CANoe CANoe Option Option DiVa DiVa will be used for all CLAAS ECUs.
Auto Au tomat mating ing tests at har vest vesting ing machine machine produc producer er CLAAS At Euro Europe’s pe’s leading leading produc producer er of harvest har vest ing ing machines, machines, CLAAS, ef fifi cient devel devel opment opment of diag diagnos nostic tic systems systems plays a key role. In a comcombine harvest har vest er er there are up to four highly high ly complex complex bus systems systems opoptimized ti mized for agri agricul cul tural tural tasks; see Figure Fig ure 4. The chal lenges lenges facing facing the agri agricul cul tural tural vehi vehicle cle diag diagnos nostic tic system system are enormous: enor mous: 350 connect connect ors ors with 3,000 electri electrical cal contacts, contacts, 3,000 m of copper copper lines, up to 25 ECUs or CAN nodes and nu mer merous ous optooptoelectron elec tronic ic machine machine guards, poten potenti tiom omeeters, valves, servo-drives ser vo-drives and speed sensors sensors must all oper op erate ate proper properly ly and work togeth together. er.
Joint diag diagnos nostic tic project by Daimler Daimler Chrysler Chrysler and Volkswag Volk swagen en A joint project point ing ing the way to the future future and simul simul tane ta neous ously ly serving serv ing as a test case for new diag di agnos nostic tic standards standards and exchange exchange formats for mats was the joint devel de vel opment opment of the new transport trans port er er gener generaation “Sprint er” er” and “Craft er” er” by Daimler DaimlerChrys Chrysler ler AG and Volkswag Volk swagen en AG. The project exe execut ed ed under under the name “Phoenix” “Phoenix” start ed ed in the year 2003 and reached its inter in terim im conclu conclusion sion in mid-2006. Techni Tech ni-cal ly, ly, the Sprint er er and Craft er er vehi vehicles cles are for the most part identi iden ti-cal and will be produced pro duced in vari var ious body config configu ura rations, tions, weight classes class es and equipment equipment vari var iants at Daimler Daim lerChrys Chrysler ler plants in LudLud -
Fig ure 5: Figure Diag Di agnos nostic tic de vel de vel opment op ment at CLAAS by the V-Model V-Mod el using using the CANdela CANdela tool chain.
3/4
VEHI VE HI CLE DIAG DI AGNO NO S TICS – THE WHOLE STORY STO RY
wigsfel de wigsfel de and Düssel Düssel dorf. dorf. Besides Besides dif feren ferences ces in body design, design, other other key dif feren ferences ces lie in each vehi ve hicle’s cle’s brand-specif brand-specif ic ic power powertrain. train. The ini initial idea for a diag diagnos nostic tic concept concept was to “translate”, “trans late”, so to speak, the Sprint er er diag diagnos nostic tic data data from Daimler DaimlerChrys Chrysler ler to VW via a central central ECU in the Craft er. er. This would have made it possi pos sible ble to omit adap adapta tation tion to the VW service serv ice test er, er, since to a cer tain extent extent it speaks a dif ferent ferent language language due to incom incompat pat ible diag diagnos nostic tic phil ososophies. Howe However, this strat egy was re ject re ject ed ed in favor favor of modi modify fying ing the service service test er er and exchang exchanging ing diag diagnos nostic tic data data by ODX. Stat ed ed in somewhat some what simpli simplified fied form, an ODX convert convert er er now process processes es the ODX diag di agnos nostic tic data data gener generat at ed ed by CANdela CANdela and uses uses them to prepare pre pare the ODX data data for VW, Figure Figure 6. Exist Exist ing ing compo components nents of the VW service serv ice test er er are not replaced, replaced, rather rather they are supple sup plement ment ed ed by other other functions func tions needed needed for a migra migration. tion.
ODX: Trials passed success suc cessful ful ly ly In this first joint diag di agnos nostic tic project the partic par ticiipat ing ing auto automo motive tive OEMs were able to acquire ac quire val uable expe experi rience, ence, even though they were confront confront ed ed with dif ficult fi cult constraints. constraints. It was neces nec essa sary ry to deal with funda fundamen mental tal ly ly dif ferent ferent diag diagnos nostic tic phil oso osophies involv involving ing dif ferent fer ent langua languages ges for coding, coding, param parameeter teriiza zation tion and control. control. FurFur thermore, ther more, all compo components nents contained contained in the diag diagnos nostic tic devel devel opment opment process, proc ess, such as export ex port to ODX and the ODX standard, standard, were still just in the devel devel opment opment stage. Numer Numerous ous inter internal nal depart depart ments ments and exex -
ternal suppli ternal suppliers ers were involved, in volved, there was as yet no practi prac tical cal expe experi ri-ence with the new ODX stand ard, and a tight schedule sched ule had to be maintained. main tained. In the Phoenix Phoe nix project the perform per formance ance of the ODX standard stand ard was put to the test in a chal leng chal lenging ing large project and it passed success successful ful ly. ly.
Future Fu ture visions: visions: Where does the road lead? With relent relent less less progress in standard stand ardiiza zation tion many things are simpli sim pli-fied, and it is possi pos sible ble to come to grips with new chal len chal lenges. ges. As evever, nat ural compe competi tition tion will gener generate ate a great deal of dyna dy namism mism in future fu ture devel devel opment. opment. Of course, it is impos im possi sible ble to predict predict exact exact ly ly what ef fects fects this will have on vehi ve hicle cle electron electronics ics and diag diagnos nostic tic systems sys tems of the future. future. Howe However it can be stat ed ed with certain cer tainty ty that the signif signif icance of Inter Internet net technol technol ogies will contin continue ue to grow, as is al so so the case in many other oth er techno technolog logiical are areas. For exam example, ple, “Diag “Di agnos nostics-over-IP” tics-over-IP” is conceiv con ceivaable. Ini Initial studies studies with Ethernet Ether net and TCP/IP are al ready ready under underway way in con junc con junction tion with FlexRay FlexRay gategateways. If vehi vehicles cles take on the posi po sition tion and function functional al ity of a HTTP server serv er from an infor in forma mation tion technol technol ogy perspec perspective, tive, gener general al identi identi-fica fi cation tion via IP address ad dresses es might make sense, for exam ex ample, ple, and this would make Vehi Vehicle cle Identi Identifi fica cation tion Numbers Numbers super superflu fluous. ous. Standard Standardiization za tion will contin con tinue ue to advance advance in test modules modules and test proce proce-dures, and re-use in devel de vel opment, opment, produc production tion and the service serv ice gagarage will become become common commonplace. place. Simi Similar larly, ly, error error messa messages ges in clear text will become become avail able on PCs and Web Browsers. Browsers. Prereq Prerequi uisites sites
Fig ure 6: Figure Cross-OEM exchange exchange of diag diagnos nostic tic data data between be tween Daimler Daimler Chrysler Chrys ler and VW based on ODX.
3/5
for this are diag diagnos nostic tic design design concepts concepts with univer uni versal sal and auto automat mat ic tool chains that can gener gen erate ate diag diagnos nostic tic data data for all compo components, nents, from the model model ing ing tool to the author au thoring ing system. system. Vector Vector will help to drive sustained sustained devel devel opment opment of these inno in nova vative tive concepts. concepts. Liter ature: Liter [1] Kühner, Kühner, T.: “20 years of vehi vehicle cle net working working and diag diagnos nostics tics – What do we antic an ticiipate in the future?”, future?”, Vector Vector Congress Congress 2006 [2] Schlingmann, Schlingmann, N.: “Speci “Specifi fica cation tion – Coding Coding – Test: Devel Devel opment opment of diag diag-nostic nos tic soft ware”, ware”, Vector Vector Congress Congress 2006 [3] Johan Johanson, son, D.: “Intro “Introduc ducing ing ODX diag di agnos nostics tics in a OEM joint venture venture pro ject”, Vector Vec tor Congress Congress 2006 [4] Rätz, C.: “What is the market market demand demand for diag diagnos nostic tic solu solutions?”, tions?”, Vector Vector Congress Con gress 2006 [5] Stimmler, Stimmler, S. and Rätz, C.: “On a sol id id basis basis – Ef ficient fi cient devel devel opment opment of didiagnos ag nostic tic functions functions in the auto au tomo mobile”, bile”, Auto Automo motive tive Electron Electronics ics 2/2005
Hel mut mut Frank (Gradu (Grad uate Engi Engineer)is neer)is a Business Business Devel Devel opopment Mana Manager at Vector Vector Infor Informa matik tik respon responsi si-ble for the Diag Diagnos nostics tics product product line.
Uwe Schmidts (Gradu (Grad uate Engi Engineer) neer) is a Market Market ing ing Coor Coordi dina na-tor at Vector Vector Infor Informa matik tik whose respon responsi sibil bil ities include include the Diag Diagnos nostics tics product product line.
3/6
Vehicle Diagnostics Increase your Development
Distr. Systems
t n e m p o l e v e D
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.
U C E
The CANdela product family supports you by: > Frontloading – early high-quality specification of diagnostic Diagnostics
> > > >
Calibration U C E
Software U C E
Management s s e c o r P
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
Vector Informatik GmbH Ingersheimer Str. 24 70499 Stuttgart Tel. Te l. 0711 / 8 06700670-0 0 www.vector.com
Automatic validation of diagnostic services Automatic ser vices by use of a diagnostic integration and validation assistant
For the first time, ti me, a fully automated test case generator has been introduced in diagnostics validation at General Motors Europe (GME) Development. This article descr ibes the introduction of this automated testing of diagnostic implementations 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 s avings as well as improvements to technical processes that were realized compared to conventional, manual validation at the Opel Corsa. Introduction
3/8
One consequence of strong competition in the global automotive
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
market is that it is forcing a shortening of development cycles. Another is that the complexity of the electronic networking archi-
crucial that diagnostic services are correct. They transport information that helps mechanics in the service garage to quickly deter-
tecture is continually increasing. Key goals in replacing conventional systems by electronically controlled systems relate to cost
mine the cause of a fault and correct it. This information must make it possible for the mechanic to decide which component is the
reductions, a high level of safety and reliability as well as better manageability. Despite all of the benefits, it must not be forgotten
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-
that increased numbers of electronic components in vehicles can increase the probability of electronics-relate electronics-related d faults. f aults. Since reliabil-
neous replacement of properly operating units [1], which causes a rise in warranty costs and a decline in customer satisfaction.
ity is an important criterion for customers when purchasing a new vehicle, it is essential to introduce new methods that enable
The E/E architecture of the Opel Insignia consists of several Controller Area Network (CAN) and Local Interconnect Network (LIN)
bus systems [2, 3]. All bus systems are accessed via a central diagnostic port (DLC), see Figure 1. Communication is defined by a GM-
Validation process and tool environment at General Motors Europe
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
In development of the Opel Insignia, GME introduced the DiVa tool from Vector Informatik for the first time. DiVa automates generation and execution of diagnostic tests.
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 infor mation, the response may include multiple message frames. > Negative responses contain a clearly defined Negative Response Code, which gives information indicating the reason for t he negative response. Negative Response Codes are given in accordance with the GM Diagnostic Specification.
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
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 diagnostic services is essential in performing quick and professional
covered by fully automated tests. Figure 3 shows a typical diagnostic validation process fo r an ECU performed by a test engineer at GME. Development of the ECU software is subdivided into several phases. At the beginning of an ECU development, the focus is more on implementation of ECU functionality than on diagnostic services. The latter are then elaborated and developed in subsequent software versions. As shown in Figure 3, with introduction of the Phase 1 (SWR 1) software version, only a small number of diagnostic services are implemented. The use of diagnostic sof tware 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
service or maintenance to the satisfaction of customers. Diagnostics also plays an important role in end-of-line testing: it is used to
development cycle. Once all diagnostic services have been implemented, regression tests are performed (SWR 7). If no more faults
program ECUs and assure product quality. That is why comprehensive validation of diagnostic functionality is absolutely necessary.
are reported in diagnostic services at that development stage, the ECU is production mature in the e xecution of diagnostic services.
Figure 1: E/E architecture and diagnostic communication on the Opel Insignia
3/9
Since a test engineer normally tests a number of different ECUs simultaneously, without adequate tool support it is impossible for
From specification to test execution and report evaluation
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-
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
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.
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
Requirements for the validation tool A tool for automated diagnostic validation must satisfy the following requirements: > Seamless integration in the existing tool chain > Transpar Transparency ency 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.
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). Furthermore, 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).
Figure 2: Comparison of diagnostic validation and tool environment on the Opel Corsa and Opel Insignia
3/10
AUTOMATIC VALIDATION VALIDATION OF DIAGNOSTIC SERVICES BY USE OF A DIAGNOSTIC INTEGRATION AND VALIDATION ASSISTANT
Table 1: Test execution times for Opel Insignia ECUs
In updating the diagnostic specification, i.e. the CDD file, DiVa
Test coverage
enables synchronization to the new specification while preserving previously defined settings. From a technical perspective, DiVa gen-
After the test has been generated, the user opens the generated test environment in CANoe and starts the test. The test duration
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 generated test cases depend in large part on the completeness of the machine-readable diagnostic diagnostic specification (CDD f ile). All generated tests are derived from it. A total of about 350 test sequences are defined in the GM Diagnostic 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-spec application-specific ific user input is required for 45 (15%) of the test procedures defined in
depends on the complexity of the diagnostic specification and the user-defined test scope that is selected, and it may vary from just a
the GM Diagnostic Specification. In such cases, DiVa pauses test execution and asks the user to put the ECU in the required state.
few minutes to several hours (Table 1). At General Motors, the CANoe test environment serves as a joint platform for test automa-
The remaining 5 % of test procedures are not suppor ted by DiVa and must be tested either manually or by other means. This includes
tion and simplifies reuse of existing GM test programs. For example, 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-
tests that would put the rest of the test procedure at risk (e.g. generate 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
tic specification. Figure 5 shows a typical test report.
additional non-GM-specific test cases.
erates CAPL code for the CANoe test module in order to test all diagnostic services supported by the ECU. To assure conformity to the GM diagnostic specification, the DiVa extension maps the test procedures 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
Figure 3: Scope of diagnostic functions in various phases of ECU development at GME
3/11
Comparisons made at GME between validation for the Opel Corsa and for the Insignia conclude that DiVa shortens test execution
By using DiVa, execution and evaluation times were shortened considerably on the Opel Insignia compared to the Corsa. In the
time enormously by predominantly automated execution of all generated 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
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
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.
results is reduced even further. This can be traced back to the smaller number of failed test cases in the more mature implementation. This trend continues in each new phase up to t he production launch. The production ready ECU must not exhibit any defects;
Economic aspects and efficiency increases When a tool is introduced, its economic benefit is a pr imary consideration. 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
consequently, the evaluation time is equal to the execution time. In this stage of Opel Insignia development, depending on the complexity 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 perform 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
point, and a large number of failed test cases had already been
terms of test scope and time effort, automatic test generation does run into limitations:
captured. Figure 6 shows validation effort in hours for manual testing on the Opel Corsa and automated testing on the Opel
> Quality of the specification: Since the specification represents the basis for generating test cases, completeness and accuracy
Insignia.
of the specifications are essential, i.e. a test is only as good as its specification. Furthermore, there must be conformity to the
Figure 4: Setting test constraints in DiVa (here: configuration of services)
3/12
AUTOMATIC VALIDATION 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 validation, compared to automated validation of diagnostic services on the Opel Insignia (execution and evaluation time)
3/13
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 ver y 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 necessary to put the t he 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 functionality 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 simultaneously 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 successful 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” phenomenon in automotive electronics. In: Microelectronics reliability, Vol. 42, P. 641-651, 2002 [2] LIN Consortium: LIN Specification Pack age Revision 2.1, 2.1, OV. 2006 [3] Robert Bosch GmbH: CAN-Spezifikation 2.0, 1991 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
3/14
Dr. Philipp Peti studied Computer Science at the Vienna University of Technology. He earned his doctorate 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.
Armin Timmerberg studied Electrical Engineering at the University of Applied Sciences at Wiesbaden. After his studies, he was first employed as a systems engineer in the aftersales area at General Motors Europe. His primary job was to implement ECU diagnostics in the GM Service Tester TECH2. Since 2004, Mr. Timmerberg has been working as a development engineer in the “Global Systems Engineering” group at General Motors Europe, where he is responsible for diagnostic validation.
Thomas Pfeffer studied Electrical Engineering at the Darmstadt University of Technology. Mr. Mr. Pfeffer is group manager for Diagnostics and Test Automation in the “Global Systems Engineering” group at General Motors Europe, located in Rüsselsheim, Germany.
Simon Müller studied Software Technology at the University 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 University 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.
Vehicle Diagnostics Automate Your Test Sequences in Diagnostic Integration Distr. Systems
Take advantage of automated test sequences in your integration tests.
t n e m p o l e v e D
Option DiVa for CANoe lets you automatically generate reproducible reproducible test cases for various regress regression ion and release tests and t hen execute them. Test
U C E
You benefit from: Comprehensivee test coverage in implementing diagnostics for an ECU > Comprehensiv
Diagnostics
> Quick execution of test cases and generation of a clearly structured test report
Calibration U C E
> Easy configuration of test contents > Full integration in the Vector tool chain.
Software U C E
Management
These features help you attain maximum efficiency and quality in integrating the diagnostic protocol in your ECUs.
s s e c o r P
More information: www.car www.car-diagnostics.de/diva -diagnostics.de/diva
Vector Informatik GmbH Ingersheimer Str. 24 70499 Stuttgart Tel. Te l. 0711 / 8 06700670-0 0 www.vector.com
A source code generator approach to implementing diagnostics in Vehicle ECUs
Implementing diagnostic functionality in automotive ECUs is usually an expensive, time-consuming and inefficient process. Computer-generated Computer-generated source code based on ECU-specif ic diagnostic data can dramatically decrease costs and development time and increase quality and efficiency. ef ficiency. 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.
3/16
Introduction
Conventional diagnostic development process
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-
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).
independent and the parts that are ECU-specific. The ECU-independent parts are reusable across different ECUs and can be written
The process starts by setting up the requirements documents. The diagnostic requirements are captured in a word-processor spec-
once up front and deployed over multiple ECUs in multiple vehicle programs that share common high-level diagnostic requirements.
ification document. This authoring process requires a great deal of time and effort and produces a document which is difficult to verify
The ECU-specific parts are not reusable across different ECUs in a vehicle. This ECU-specific software will not fit the write-once-use-
as either complete or correct. Once this document is completed, it is delivered to the supplier.
many model of the ECU independent software, but it can still be done in a more eff icient way through a source code generation pro-
The supplier engineers must read and interpret the document. Less experienced suppliers will not fully understand the requirements
cess that automates as much of the ECU-specific software as possible.
on their own and will require significant support from the OEM in getting up the learning curve. Opportunities for misinterpreta -
tion are everywhere and almost always lead to non-compliant
implementations. In this situation, not only non-compliant imple-
In addition, suppliers must also deal with the possibility of changes in diagnostic requirements from the OEM. These new docu-
mentations are likely, but also come in the form of multiple suppliers having the same misunderstandings and producing the same issues across multiple ECUs. Once the ECU software is implemented and delivered to the OEM,
ments not only mean reworks, but also further increase the opportunity for misinterpretation of requirements that can lead to reworks of the reworks.
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
Diagnostic source code generator
failures that are shared by multiple ECUs. In the end, many engineers are all working to f ind and resolve similar issues across multiple 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-
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 different OEMs can share a common application-programming interface. This interface not only hides the complexity of the extensive ECU-independent diagnostic specifications from the programmer, but also keeps ECU application sof tware design OEM-independent. The OEM defines ECU-specific requirements as input data to the source code generator. These formal requirements replace the current word-processing based documents used today as a basis for software development. The source code generator creates an ECUspecific diagnostic software component according to the OEM’s
nology and levels of completeness. Incomplete definitions, ambiguous wording, inconsistent terminology and requirements that are
diagnostic requirements. Next, the supplier develops the ECU-specific parts of the diagnostic software. The complexity of the diag-
just plain assumed and not specified make the job nearly impossible to execute right the first time.
nostic protocol is hidden by t he application-programming interface that connects the communication to the diagnostic functions in the
From office productivity software to web applications, most modern software packages profit from including pre-built components.
ECU.
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.
3/17
Advantages from the OEM perspectives
The diagnostic component is typically available at the beginning of the project. Because the component’s interface mirrors the function-
The component developer manually develops a framework that covers 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 component is ready for use, the same framework is shared by all suppliers.
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 significant 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
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 specification document and to generate input data to test systems. If an appropriate tool supports the data entry process, the entire diagnostic 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 beginning 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.
There is already a working implementation of this approach to imple-
Advantages from the supplier perspective
Resource requirements are a very sensitive point in automotive embedded software. CANdesc was designed with t his point in mind.
The supplier generates source code for all OEM-specific requirements. He does not need to interpret the OEM’s diagnostic protocol
Exact resource consumption depends on microcontroller and compiler selection and so does the optimal generation configuration,
specification at all. Inconsistent interpretations and implementations of the protocol are left out of the process, which leads to a significant reduction of de velopment iterations.
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.
menting diagnostics in an ECU. CANdesc, a part of the Vector C ANdela 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 editing. The CANdelaStudio data model covers all requirements necessary for effective source code generation as described in this document (Figure 3). The source code generation tool outputs the ECU diagnostic sof tware component source code (Figure 4).
Figure 3: Generation of an ECU diagnostic software component
3/18
A SOURCE CODE GENERATOR APPROACH TO IMPLEMENTING DIAGNOSTICS IN VEHICLE ECUS
> ROM: about 8 k for f or an ECU of moderate complexity (like a climate control or transmission unit), about 5 k for even the smallest
The Vector CANdela approach shows that the concept of computer generated diagnostic software components not only works in
ECUs > RAM: about 128 bytes
real world applications, but also delivers on the promises made by such an approach.
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 implementation before the first bench delivery. The total diagnostic development 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 development 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
Christoph Rätz Dipl-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.
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, documentation and tester data replace their hand-made counterpar ts of the conventional diagnostic development process.
Figure 4: From diagnostic specification to C-Code
Figure 5: Effort savings with the CANdela approach
3/19
ECU Soft ware ware for Dry Dual Dual Clutch has Stringent Stringent Require Requirements ments Integrat Inte grat ed ed Diag Diagnos nostic tic and Flash Solu So lution tion with Script Control Control Dual-clutch transmis Dual-clutch transmission sion technol technol ogy not only on ly of fers fers signif signif icant improve improvement ment in driver driv er con ve venience nience and ride comfort com fort at moder mod er ate ate added added cost. At the same time, it al so so deliv delivers ers excel excel lent lent fuel fuel econo economy. The design design of a produc production tion ver sion sion of the world’s first ‘dry system’ sys tem’ dual-clutch dual-clutch transmis trans mission sion repre represent sented ed a special spe cial chal lenge for the ECU’s electron electronics. ics. Frequent Frequent flashing flash ing of the ECU is neces nec essa sary ry in the de vel opment opment process, process, and this requires re quires the use of ration rational al flash methods methods and high-per formance formance tools that are up to the task.
Automat Auto mat ed ed transmis transmissions sions combine combine the conve convenience nience of an auto au tomat mat ic ic transmis trans mission sion with the cost advan ad vanta tages ges of manu manual transmis transmissions. sions. In con junc junction tion with ECM (Electron (Elec tronic ic Clutch Manage Man agement), ment), dual dual clutch transmis trans missions sions form the basis basis for modern modern drive concepts. concepts. While the ECM system sys tem handles handles electric electric motor motor actu actuaation of the dual dual clutch, transmis trans mission sion control control ensures ensures that two gears are al ways ways engaged engaged simul tane taneous ously. ly. Usual Usual ly ly gears 1, 3 and 5 are served by one trans mis mis-sion section, section, while the other oth er section section is respon responsi sible ble for gears R, 2, 4 and 6. Disen Disengage gagement ment of one clutch and simul si mul tane taneous ous engage engagement ment of the other other clutch ena enables a nearly near ly jolt-free gear shift – without without an inter in terrup ruption tion in the propul propul sive sive force – to the next higher high er or next lower low er gear. The opti op timized mized shift ing ing method method requires requires just a few hunhundredths of a second second to shift gears and of fers of fers bet ter ter fuel fuel econo economy than manu man ual shift ing. ing.
Until now, dual-clutch Until dual-clutch transmis transmissions sions were only only avail able in wet technol tech nol ogy, i.e. with compo components nents running running in oil. Al though though they of fer the advan advantage tage of great er er power power loss absorp absorption tion by oil cool ing, ing, this is contrast contrast ed ed by the disad disadvan vanta tages ges of a lower lower friction friction factor factor and a larger larger drag torque when idling. Since LuK uses us es electric electric momotors to actu actuate ate the dry dual dual clutch, this of fers of fers even great er er poten poten-tial for reduc reducing ing fuel fuel consump consumption tion and CO2 emis emissions. sions.
Greatest Great est Ef ficien fi ciency cy with Dry Dual Dual Clutch The first ‘dry’ dual dual clutch was devel de vel oped oped at the facil facil ities of auto automo mo-tive suppli supplier er LuK in Bühl (Figure (Fig ure 1). This compa company, ny, part of the Schaef fler fler Group and a special special ist ist in clutch and transmis trans mission sion compo component nent solu so lutions, tions, has contrib contribut ut ed ed to the advance advancement ment of auto automo motive tive techtechnol ogy with all sorts of inno in nova vative tive devel devel opments. opments. In 1965 it was the first compa company ny in Europe Europe to intro introduce duce the dia diaphragm spring clutch to the market, mar ket, and in 1985 the first dual-mass dual-mass flywheel. flywheel. This was lat er er fol lowed lowed by CVT (Contin (Continu uous Vari Var iable Transmis Transmission) sion) compo compo-nents for torques torques great er er than 300 Nm and the world’s first elec tromechan me chaniical auto automat mat ic ic transmis transmission. sion. Meanwhile, Meanwhile, every every fourth car in the world is driven driven with a LuK clutch. Today, To day, the focus focus of the comcompany’s pa ny’s devel devel opment opment is on al terna ternative tive drive concepts concepts too, such as compo com ponents nents for dual-clutch dual-clutch transmis transmissions sions and hybrid hy brid drives.
3/20
Fig ure 1: Figure The core of the modern modern dual-clutch dual-clutch transmis transmission: sion: Dry (left) or wet (right) dual dual clutches clutches ensure ensure gear shifts without with out inter inter ruption rup tion of tractive tractive force. Software Software de vel de vel opment op ment for these drive concepts con cepts by LuK required re quired frefrequent flashing. flashing.
Intel In tel ligent ligent Software Software protects protects the Clutch System System A problem problem specif specif ic ic to the dry clutch becomes becomes appar apparent ent when stopstop ping on a hill, when the driver driv er applies applies the braking braking torque via the gas pedal pedal and clutch instead in stead of the brakes. Due to poorer poorer cool ing, ing, the clutch gets hot much quicker quick er than in a wet system. sys tem. To protect protect against prema premature ture wear and fail ure, ure, intel intel ligent ligent driver driver warning warning strat egies are required, re quired, which support support the driver driver in opti optimal mal ly ly util izizing the clutch. The soft ware ware might achieve this, for ex am ample, ple, by al lowing low ing the vehi ve hicle cle to slowly slowly roll free aft er er a short peri period od of time, which indu induces ces the driver driver to auto automat mat ical ly ly step on the brake pedal. ped al. During Dur ing the drive, the electron electronics ics must ad ad just the clutch engage engage-ment to be quicker quicker or slower slower depend depending ing on vehi vehicle cle speed, gas pedal pedal posi po sition, tion, etc. Overall, numer Overall, numerous ous constraints constraints and param parameeters need to be consid consid-ered in auto automat mat ic ic clutch oper operaation, and they change dynam dynamiical ly ly during dur ing oper operaation. The clutch heats up, cools down again and is therefore re fore contin continu ual ly ly changing changing its charac char acter teris istics. tics. The electron elec tronics ics must contin con tinu ual ly ly adapt the behav behavior ior of the auto au tomat mat ic ic dual dual clutch to these changing chang ing param parameeters. LuK util izes izes an advanced advanced compu computa tation tional al model mod el that yields a clutch mechan me chaniical design design that is less complex com plex and is therefore therefore more econom economiical for the auto automo motive tive OEM.
From in-house Flash Tool De vel De vel opment opment to uni ver ver sal sal Flash Solu So lution tion At first, LuK handled handled the flashing flash ing that is frequent fre quent ly ly needed needed in soft ware devel devel opment opment (updat (updat ing ing of program program code or data data in the ECUs) with an in-house devel de vel opment opment that was even used to flash produc pro duc-tion ECUs. Inde In depend pendent ent ly, ly, the clutch special special ist ist conduct conduct ed ed a search for a diag diagnos nostic tic tool for CAN. Aft er er finding, finding, during during a test phase, that other other products products were lacking lacking in vari var ious are areas – ranging ranging from the graphic graphic user user inter interface face to product product support support – LuK decid decided ed on CANdi CAN dito to from the Stutt gart-based gart-based compa company ny Vector Vector Infor Informa matik. tik. VecVector impressed impressed them with a solu so lution tion that can imple im plement ment all of the variious flash methods var methods and can al so so serve as a full diag di agnos nostic tic test er er (Figure (Fig ure 2). In the diag di agnos nostic tic test er er CANdi CANdito, to, the LuK employ employees ees found precise precise-ly what they had been looking look ing for, and more. The tool ena enables symsymbol ic ic access access to all data da ta and functions functions that are acces ac cessi sible ble via the diag di agnos nostic tic proto protocol. col. It reads in ODX-2.0 descrip de scription tion files and supsup ports scripts for auto automat mat ing ing diag diagnos nostic tic and oper operat at ing ing sequen sequences. ces. ECU vari var iants are auto au tomat mat ical ly ly detect detect ed. ed. The author authoring ing tool CANde CAN delaS laStu tudio dio is used to describe describe the diag diagnos nostic tic data data in CDD and ODX formats. formats. Each ECU is described de scribed in a sepa sep arate docu document that is based on a docu document template. template. A vari var iants concept concept makes it possi possi-ble to define define the common commonal al ities and dif feren ferences ces of an ECU’s vari var iants, largely largely without without redun redundan dancies. cies. Full param parameeter teriiza zation tion simply simply
Fig ure 2: Figure By using us ing the right tool and ODX, a smooth trantran sition si tion of flash process processes es is possi possible ble – from de vel de vel opment op ment to produc production. tion.
3/21
involves reading involves reading in the ECU descrip de scription tion file. All commu com muni nica cation tion paparameeters and all exist ram ex ist ing ing servi services and data data are imme immedi diate ately ly avail able. In a sepa separate work step, the embed embedded ded soft ware ware can al so so be gener gen erat at ed ed from the descrip de scription tion file. This ensures en sures that the diag di agnos nos-tic descrip description, tion, the soft ware ware in the ECU and param pa rameeter teriiza zation tion of the diag diagnos nostic tic test er er are al ways ways coor coordi dinat nat ed. ed.
whether an update whether update is even neces nec essa sary. ry. Scripts ensure ensure that the tool al ways ways uses uses the right soft ware ware for the partic par ticu ular hardware hardware vari var iant, even when the same ECU hard ware is used on numer nu merous ous dif ferent ferent vehi ve hicle cle models. models. Use of CANdi CANdito to as a diag di agnos nostic tic test er er and flash tool – in includ cluding ing script functions functions to simpli simplify fy the job – goes a long way toward to ward improv improving ing process process reli reliaabil ity.
Diag Di agnos nostics tics and flashing flashing with one Tool
Outlook Out look
A key basic basic require requirement ment for LuK is that it must be pos si sible ble to read out the soft ware ware current current ly ly in the ECU before before flashing. flashing. This is neces nec es-sary sa ry to ensure ensure that the correct cor rect soft ware ware version version is being be ing flashed in the rel evant ECU. Further Fur thermore, more, this capa ca pabil bil ity is impor important tant for reading read ing out system sys tem param parameeters and the error er ror memo memory or for making making before/aft be fore/aft er er compar compariisons. In the old solu so lution, tion, the diag diagnos nostic tic test er er was needed need ed to access access these data. da ta. Aft er er the user user had read out the neces nec essa sary ry data, data, the user user would stop the test er, er, start the flash tool and select select the appro appropri priate ate files – an intri in tricate cate proce procedure. dure. A reme remedy to this sit uation was found in use of the script language lan guage inte in tegrat grat ed ed in CANdi CANdito to (Figure (Figure 3). Aft er er commu communi nica cation tion has been eses tablished, tab lished, the tool reads out the identi iden tifi fica cation tion of the soft ware ware curcurrent ly ly in the ECU. Based on a ta ble, the tool auton autono omous mously ly decides decides
Current trends in repro Current re program gramming ming memo memory chips include: in clude: ODX-F, parparal lel lel flashing flashing and flashing flashing with increased in creased bandwidth bandwidth via FlexRay. FlexRay. In light of these wide-ranging wide-ran ging trends, questions questions relat relat ed ed to protec protection tion of invest invest ment ment and assur as surance ance of future future cover coverage age are thorough thoroughly ly jusjustified. ti fied. Users Users of Vector Vector products products bene benefit here, not only only because because they repre rep resent sent a scal able tool chain with mul tiple tiple flash solu so lutions, tions, but al so because because they of fer fer timely timely program program versions versions that meet current cur rent standards. stand ards. While ODX-F support sup port and paral paral lel lel flashing flashing are al ready ready avail able, FlexRay FlexRay support support is al ready ready coming coming with the next release. re lease. Exist Ex ist ing ing author authoring ing tools for the devel de vel opment opment of diag diagnos nostic tic param parameeteriiza ter zation tion or the ODX-F flash contain con tainers ers round out this area. ar ea.
Werner Schmitt Werner Electri Elec trical cal techni technician, cian, works on devel de vel oping oping electron elec tronic ic systems systems in the transmis transmission sion auto auto-mation ma tion area area at LuK GmbH & Co. oHG. He is responsi respon sible ble for diag diagnos nostics tics as well as startup and service service of these systems. systems.
Andreas Andre as Patzer Patzer (Gradu (Grad uate engi engineer) neer) works at Vector Vector Infor Infor-matik ma tik GmbH where he is Business Busi ness Devel Devel opopment Mana Manager in the “Measure “Measurement ment and Cal ibration” bra tion” product product line.
Fig ure 3: Figure LuK de vel de vel ops ops flash jobs using using the script edi editor inte inte-grated grat ed in CANdi CANdito. to. In the scripts, diag diagnos nostic tic functions functions are exe execut cuted, ed, and the neces necessa sary ry infor infor mation ma tion and data data are read-in from an ODX flash contain container. er.
3/22
3/23
Flexiible Flash Solu Flex Solution tion for every every Job Open standards standards ena enable use of gener generic ic tool chains Reprogram Repro gramming ming of modern modern flash chips has become be come a common com monplace place process process in de vel opment opment and produc pro duction. tion. In practice, practice, the jobs are excep exception tional al ly ly di verse verse – depend de pending ing on the ECU, depart department, ment, manu manufac factur tur er er and suppli sup plier er – so prepa prep ara ration, tion, manage management ment and the flash proc ess itself itself all in volve consid con sider er able ef fort. fort. Therefore, Therefore, this ar ticle ticle first sur veys the purely pure ly techni technical cal ter rain rain in which flash solu so lu-tions occur. occur. After After wards, wards, the per spective spective is expand expanded ed to cover cov er process-ori process-orient ented ed jobs and ration ra tional al approach approaches es to solutions. solu tions.
Memo Mem ory funda fundamen mentals tals Wherever Wherev er infor informa mation tion needs to be saved for a cer tain peri period od of time, one finds rewrit re writ able flash memo memory in use today, today, e.g. in USB sticks, digi digital camer cameras as and mobile mobile tel ephones. Long-term storage stor age of the firmware firmware of micro microcon control trol ler-based ler-based ECUs in the au to tomo mobile bile is a frequent frequent appli applica cation tion area area for flash memo memory. The market mar ket of fers fers variious flash archi var architec tectures tures as NAND or NOR flash, which dif fer dif fer in terms of control control logic, logic, access access speed, current current consump consumption tion and life. Common Com mon to all types is that the mem ory needs to be erased before be fore rewrit re writ ing. ing. Al though though data data can be read-out byte-by-byte, the erasing eras ing process proc ess – in contrast con trast to conven con vention tional al EEPROM EEPROM memo memory – can only only be performed per formed block-wise. In ECUs, NOR flash is used al most most exclu exclusive sively. ly.
Techni Tech nical cal flashing flashing “Technical “Techni cal flashing” flashing” essen essential tial ly ly refers refers to a process process for updat updat ing ing program pro gram code and/or data data in ECUs. This may be done, for ex am ample, ple, using us ing a PC or laptop lap top with special special soft ware ware – the so-called flash tool – via the exist ex ist ing ing net work work infra infrastruc structure, ture, e.g. the CAN seri se rial al bus system sys tem (Figure (Figure 1). Require Requirements ments dif fer, fer, sometimes sometimes signif signif icant ly, ly, for flashing flash ing during dur ing the devel devel opment opment phase, end-of-line program pro gramming ming or soft ware ware updates updates at service serv ice centers. centers. While soft ware ware changes changes in the devel devel opment opment phase al ways ways involve involve provid providing ing new code or new data da ta to the same ECU, what mat ters mat ters in produc production-re tion-relat lat ed ed flashing flashing is to use – from a wide vari va rieety of released released soft ware ware levels levels – those that are correct cor rect for the specif spe cif ic ic vehi vehicle cle and its features. fea tures. In this case, it is essen es sential tial to consid consider er the vehi vehicle cle vari var iant, installed installed feafeatures, country country code, seri serial al number, number, safety safety aspects, aspects, etc. At a mini minimum, the fol lowing lowing compo components nents are needed need ed for flashing: flashing: > Flash data, data, > Flash tool, > Flash boot loader, loader, which is inte in tegrat grat ed ed in the ECU and exe ex ecutes the actu ac tual al erase/write process processes es > The neces necessa sary ry meta meta infor informa mation. tion.
3/24
Fig ure 1: Figure Memo Mem ory structure structure in ECU with FlashBoot FlashBootLoad Loader er from Vector. Vector.
The flash data data contain contain the program pro gram code and specif specif ic ic param parameeter sets intend intended ed for the ECU. The flash tool imple implements ments the flash rourou tine on the PC side. If the tool on ly supports supports a special special flash routine, rou tine,
then dedi dedicat ed ed flash tools may be needed need ed for dif ferent ferent flash jobs. Data-driv Da ta-driven, en, mul tipur tipurpose pose flash tools are ef fi ef ficient cient and more modmodern. Flash job control con trol ena enables their use for dif fer dif ferent ent ECUs and flash routines, rou tines, e.g. if the same ECU is to be used at dif fer dif ferent ent OEMs. A sinsingle dedi dedicat ed ed tool is all that is need ed to manage manage flash jobs and asas soci so ciat at ed ed flash data data in contain containers, ers, and it al ways ways has the same user us er inter in terface. face. Responsi Respon sible ble for the routine rou tine on the ECU side is the flash boot loader loader (FBL) that is inte in tegrat grat ed ed in the ECU and is al ways ways active. active. The FBL is parti par titioned tioned into into the perma per manent nent boot loader loader exist exist ing ing in the ECU and the flash driver. driv er. For secu securi rity ty reasons, reasons, the flash driver driv er is only only temtempora po rari rily ly loaded loaded in the ECU’s RAM, since among oth er things it concon tains the service serv ice for ini initial erasure erasure of the flash memo mem ory, accept accept ance ance of data data from the flash tool and exe ex ecu cution tion of the subse sub sequent quent reset. reset. The boot loader loader consists consists of the CAN driver, driv er, transport transport proto protocol col and dia diagnostic nos tic layer layer and thereby thereby ensures ensures that the ECU al ways ways remains remains adaddressaable, even if the flash process dress proc ess could not be complet com plet ed ed proper properly. ly.
CAN drivers, drivers, CCP/XCP proto protocols, cols, etc. A gener generaator tool is respon responsi sible ble for data data config configu ura ration tion and gener generaation of the header header files. If one util izes izes a suit able author authoring ing tool to conve convenient nient ly ly gener generate ate diag di agnos nostic tic data data and servi serv ices, the tool can be used to di rect ly ly paparameeter ram terize ize the diag diagnos nostic tic test er er and gener generate ate the rel evant diag diag-nostic nos tic code for the ECU. An ODX-D data data contain container er stores the diag di ag-nostic nos tic data data and flash job togeth to gether. er. There is an ODX-F manage man agement ment and author authoring ing tool for linking linking flash data, data, jobs and meta-da me ta-data. ta. The asso as soci ciat at ed ed commu communi nica cation tion param parameeters are not contained contained in the ODX-D contain container, er, rather rather in a dedi ded icat ed ed ODX-C contain container er ('C' stands for “Commu “Communi nica cation”), tion”), Figure Figure 2.
Process-ori Proc ess-orient ented ed flashing flashing A special special chal lenge lenge in flashing flash ing is to al ways ways load the right appli ap plica ca-tion in an ECU. That is the on ly way to ensure ensure complete complete and errorer rorfree function functional al ity in the vehi vehicle. cle. In produc production-re tion-relat lat ed ed flashing, flashing, meta-da me ta-data ta are required re quired for this, such as ECU and vehi ve hicle cle vari var iant, soft ware ware seri serial al number, number, name of the flash job and much more. Da ta contain con tainer er files, which are referred re ferred to here as flash contain con tainers, ers, are appro ap propri priate ate for consist consist ent ent manage management ment of this infor in forma mation tion totogether with the flash data da ta and flash jobs. ODX (Open Diag Diagnos nostic tic data eXchange) eXchange) is avail able as a standard stand ardized ized format, format, wherein wherein a distinc dis tinction tion is made between be tween ODX-D for diag diagnos nostic-rel tic-rel evant infor informa ma-tion and ODX-F for flash-specif flash-specif ic ic data. data. Since meta me ta infor informa mation tion is gener gen eral al ly ly una unavail able in devel devel opment, opment, flashing flash ing is of ten ten very dif ferent ferent during dur ing devel devel opment opment and during dur ing proproduction. duc tion. So ECU devel devel opers opers sometimes some times flash – not via the diag di agnos nos-tic proto protocol, col, but via CCP (CAN Cal ibra bration tion Proto Protocol) col) or XCP (Univer (Univer-sal Measure Measurement ment and Cal ibra bration tion Proto Protocol). col).
Ration Ra tional al gener gener ation and manage management ment by tools To gener generate ate the exe execu cuta table ble flasha flashable bina binary ry files via compi compiler/link ler/link-er, one needs the source code for the appli ap plica cation, tion, diag diagnos nostic tic code and embed embedded ded code el ements, which are supple sup plement ment ed ed by checkchecksum infor informa mation, tion, finger fingerprints prints and other oth er data. data. Use of a compre comprehen hen-sive product product solu solution tion quickly quickly leads to the desired de sired results results – e.g. one from Vector Vector Infor Informa matik tik with source code for the embed embedded ded portion portion in the ECU, consist con sist ing ing of oper operat at ing ing system, system, net work work manage management, ment,
Fig ure 2: Figure Based on the ODX-F contain con tainer, er, the flash routine rou tine is executed ful ly ly auto automat matiical ly ly with CANa CA Nape, pe, CANdi CANdito to and CANdit CAN dito oFlash. The contain container er contains contains all neces necessa sary ry data da ta and infor infor mation ma tion such as ref er er ence e nce to the flash file, flash job and meta meta infor infor mation. ma tion.
3/25
Fig ure 3: Figure Use of the ODX-Standards ODX-Standards ena enables a smooth transi transition tion in flash process process-es from de vel de vel opment op ment to produc production. tion.
Getting Get ting “a grip” on ref er er ences ences Lat er er in the flash process proc ess the system sys tem reads from the ODX-F file the flash files, meta me ta infor informa mation tion and ref erence erence to the flash job being be ing used. The lat ter ter is found in the diag diagnos nostic tic descrip description, tion, from which it is loaded loaded and exe execut ed. ed. Ref eren erences ces are used to produce produce the rela rela-tionships tion ships between between the ODX-F, ODX-D and ODX-C contain con tainers. ers. On the one hand, ref eren erences ces to flash data data and flash jobs are easy to replace re place without without requir requiring ing regen regener eraation of the ODX files, but they are al so so asso associ ciat at ed ed with the risk that the process proc ess will no longer function func tion if a ref erenced erenced docu document is missing. miss ing. One solu solution tion to this problem prob lem was to create cre ate “meta” “me ta” contain containers ers that save all asso as soci ciat at ed ed data da ta in a single, sin gle, compressed compressed file. By def ini nition, tion, the contain containers ers – with the 'PDX' (Packaged (Pack aged ODX) exten extension sion – do not permit per mit any ref ererences en ces to files out side side of the contain container. er. This concept concept ensures ensures that one al ways ways loads the right flash data da ta with asso as soci ciat at ed ed meta meta infor informa mation tion into into the ECU by the proper proper flash rouroutine. Further Fur thermore, more, it permits per mits both ful ly-automat ly-automat ic ic and semi-auto semi-auto-mat ic ic flashing. flashing. Ful ly ly auto automat mat ic ic means that the user us er does not perper form any config configu ura ration tion or selec selection tion activ activiities. In semi-auto sem i-automat mat ic ic flashing flash ing the user user can influ influence ence the flash process. proc ess.
Summa Sum mary ry The use of standards standards such as ODX ena en ables the use of tool chains that ensure en sure reli reliaable and process-con proc ess-conform formant ant flash process processes es in every every dedevel opment opment phase (Figure (Figure 3). Gener Generic ic and data-driv data-driven en tools bene benefit
3/26
the user user by of fering fer ing enhanced enhanced flexi flexibil ity with the goal of cover cov ering ing a wide vari varieety of require requirements ments and job tasks relat re lat ed ed to flashing. flashing. Flash routines routines cannot can not be imple implement ment ed ed without without suit able tool chains. From Vector Vector the ECU devel de vel oper oper gets univer universal sal tool support support in all aspects of flashing: flashing: CANde CANdelaS laStu tudio dio for speci specify fying ing diag diagnos nostic tic requirements require ments and gener gen erat at ing ing the CDD, ODX-D and ODX-C files, CANde CAN dela laFlash Flash for gener generat at ing ing the ODX-F flash contain containers ers and the flash boot loader loader for a wide range of control con trol lers. lers. As author au thoring ing and devel de vel opment opment tools, CANa CANape pe and CANdi CANdito to are used to gener gen erate ate script-based flash routines, routines, and they al so so form the actu actual al runtime runtime envi en viron ronment ment for the flash process. proc ess. CANdit CANdit oFlash serves as a pure runtime run time envi environ ronment ment for flash process proc esses es gener generat at ed ed with CANa CANape pe and CANdi CANdito. to.
Andreas Andre as Patzer Patzer (Gradu (Grad uate engi engineer) neer) is employed employed at Vector Vector Infor In forma matik tik GmbH as Business Business Devel Devel opment opment Manaager for the “Measure Man “Measurement ment and Cal ibra bra-tion” product product line.
Vehicle Diagnostics ODX at the press of a button! Rely on proved and tested ODX solutions In your ODX development, you can benefit from the know-how
Distr. Systems
t n e m p o l e v e D
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 ser vices:
Test U C E
> Create diagnostic data easily and exchange this data with your process partners Diagnostics
> Diagnose individual ECUs or the total vehicle > Flash ECUs based on ODX-F data > Migrate master data to ODX
Calibration
> Benefit from our consultation in implementing and
U C E
integrating ODX Add ODX to your diagnostic development reliably and quickly.
Software U C E
Vector tools and services will support you in all phases.
Management s s e c o r P
Vector Informatik GmbH Ingersheimer Str. 24 70499 Stuttgart Tel. +49 +49 7118 0670-0 www.vector.com
Press the button! www.odx-solutions.com
g o I n d i g c s t i c N e w : g n o s a a i d e c l e h i c E a s y v e d o n O D X b a s
l o o T
Flash programming via CAN requires supplier’s flexibility By Peter Liebscher (Vector Informatik)
A
lot of flexibility is demanded of automotive suppliers in the development of electronic components. This also applies to the area of Flash programming. Constraints in the various phases of the product 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 available to them. ECUs need to be reprogrammed and analyzed more or less frequently over the various phases of a vehicle ranging from development to production to operation in the target vehicle to diagnostic analysis of returned 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 interface for exchanging software. For suppliers the basic challenge is to achieve the most rational flow in their own development and production phases and satisfy the (strict) requirements of the vehicle OEM. The solution approach of the company Continental Automotive Systems (www. conti-online.com), for example, involves creating their own OEM-specific Flashloader for development and production phases and a customer-specific Flashloader for the product operation phase. The production boot-loader is optimized for standardized standardiz ed in-house flash processes and is decomis-
3/28
22
sioned at the end of the production process, so that in normal operation only the
still active. For the supplier this eliminates potential compatibility problems between the production boot
flashing process. Since the topic of security plays an important role in Flash programming in the vehicle operation phase, all security mechanisms for integrity, 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 product. Therefore, in reactivation precautions are taken to ensure that unauthorized persons cannot exploit this
indirect path to manipulate or spy data. A specific application at Continental involves reprogramming a multiprocessor system with master and slave controllers and external sensors. The master controller can be flashed directly 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 constraints, 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 serial IPC (Interprocessor Communication) connection between the master and slave in Flash programming. In this project a Flash tool with
Source: CAN Newsletter, CAN in Automation
a hard-coded Flash procedure 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 rationally at the supplier. The advantage 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 future de-facto standard enables data exchange with other tools. At the same time required diagnostic data are stored in the container that might be generated with the CANdelaStudio program of the same producer.
[email protected]
3/29
1
l
AUTOMOTIVE
9.2006
INTERVIEW Use of XCP on FlexRay FlexRay at BMW This fall the first FlexRay production application will 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-
AdaptiveDrive in the new X5 utilizes sensors and per-
ry 2006 tool producer Vector Informatik
forms computations to acquire data on vehicle speed,
worked together with BMW on the
steering steerin g angle, longitudin longitudinal al and lateral acceleration, body and wheel accelerations as well as their heights.
FlexRay solution. FlexRay experts Mar-
The swivel motors of the stabilizer bars and electro-
tin Peteratzinger and Florian Steiner of
magnetic valves of the shock absorbers are controlled
BMW and Roel Schuermans of develop-
based on this infor information.This mation.This provides full-time control of body roll and damping based on the given dri-
ment partner and software provider
ving situation.The new BMW X5 is the f irst vehicle in
Vector discussed their experiences in
the world to utilize FlexRay technology.
HANSER automotive.
Mr. Peteratzin Mr. Peteratzinger ger,, why FlexRay and why why now? Peteratzinger : That was a strategic decision. We have already 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 indicated that up to eight CAN buses would be needed for just the powertrain and chassis areas in the next 7-series car. But we do not want to implement even more sub-buses; at some point they become unmanageable. Therefore, some years ago BMW decided to build up its development experience with FlexRay. We now have a foundation for future electrical systems and will expand them to include additional vehicle systems in upcoming car models. If we did not start on this now, we would have had to utilize a large number of CAN systems and sub-buses to carry us through, and this would last for many years due to the development cycles for car models. Steiner : Another criterion of course i s transmission rate. In the current application sensor signals are acquired and processed both by the central ECU and by the satellites. On the one hand, this decentralized approach leads to an i ncreased demand for communication, and on the other hand shorter cycle times are needed on this and future architectures due to their separation of sensors, control system and actuator.. In addition, many of the new functions and archiactuator tectures place stricter requirements on real-time capability and communication availability. This can only succeed with a bus system l ike FlexRay.
Translated by Vector Vector Informatik
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 projects. In this case, the first step was to build up this knowledge. It was therefore important for BMW to be able to quikkly apply this acquired knowledge and implement necessary changes during development. In a system such as an engine controller the adaptation effort would be considerable due to the large number of interfaces. This new suspension system has a well-defined and limited functionality. In a small team, together with our ECU suppliers and development partners such as Vector, we were able to make decisions and introduce modifications over short decision-making paths. Furthermore, aspects of this application made it possible to implement many new FlexRay features meaningfully. When did you decide to eliminate CAN entirely as a fall-back solution in this project? Peteratzinger : That was done in a relatively early phase of the project in the summer of 2004. After we had successfully started up FlexRay as a bus system to network the five ECUs in a stable manner and had all identified and assessed unresolved risk issues,
Martin Peter Peteratzinger atzinger,, Graduat Graduate e Engineer (University of Applied Sciences), develops electronics in the vehicle dynamics area of the BMW Group and has functional responsibility for the FlexRay application.
4/0
INTERVIEW
VECTOR'S
CANAPE
l
AUTOMOTIVE
9.2006
l2
basic definitions. Part 2 of the document describes the XCP command set as a bus-independent protocol l ayer ayer.. Whenever a new Transport Layer is added, as is being done now with FlexRay, 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 specification defines dynamic bandwidth control. Since the XCP protocol is essentially a MasterSlave communication protocol, the XCP Master can distribute XCP Slots to individual Slaves depending on how much bandwidth the Slave needs. Dynamic bandwidth management requires that the Master knows which slots are available for this purpose. That must be a part of the FIBEX file. Optimization of ECU parameters with CANape
the decision was made to eliminate CAN altogether beginning with the next hardware level. In the process this raised the question: How would we calibrate the application? Initially calibration was still performed via CAN, but in the end this fall-back level was dropped. Therefore we first developed a CCP-CAN-FlexRay gateway that converts CCP messages to FlexRay and in the reverse direction too. In the ECUs we also “restructured” the CCP module for FlexRay. This made it easier to continue utilizing CANape with CCP (CAN Calibration Protocol). But that too was j ust a transitional solution, since first it is necessary to create such gateways, and then they need to be maintained for a number of years. Therefore it was important to find a product that would not just work exclusively in one project, but would be available to the entire market. In the ASAM working committee XCP on FlexRay was driven by Vector with the support of BMW and attained specification status in February 2006. Technically we had gotten a handle on the “measurement & calibration via XCP on FlexRay” concept relatively quickly. For Vector though it was clear that we had to turn XCP on FlexRay into a standard as quickly as possible. ASAM has been working on XCP for quite a long time now. XCP itself was finalized in 2003. The aim of the standard is to only require adaptation of the underlying transport protocol. The specific solution needs at BMW allowed us to implement both the XCP stack in the ECU and on the tool side CANape as the XCP Master very quickly. Schuermans:
XCP on FlexRay was standardized standardized in February. February. What was involved in this process? Schuermans: Of course the work in ASAM requires a certain amount of time: First a project application is submitted, then a working committee is formed, and finally a draft is developed. XCP is split up into several subdocuments. Part 1 is an overview of the protocol family, XCP features and
Why is that good? Steiner: Compared to the potential bandwidth of FlexRay the current bus load is still very small. We therefore had the luxury of making three XCP slots available to each ECU: One to communicate from CANape in the direction of the ECU, and two to send measurement data from the ECU in the direction of CANape. That means that 15 slots are used just for XCP. XCP. In the next car models the bus will be utilized more intensively with more ECUs. Then we will no longer have this freedom. All Florian Steiner, ECUs must then share one Graduate Engislot or just a few slots for neer (University XCP. of Applied ScienThe only limitation here is ces), deve develops lops that it will no longer be pos- electronics in the sible to calibrate all ECUs vehicle dynamics simultaneously. However, area of the BMW this is of no consequence in Group and as a FlexRay devepractice, because devel- lopment expert he is responopers generally only calibrate sible for production-level ECU their “own” ECU. With dyna- development. mic bandwidth allocation this can be done very qui ckly. That is XCP will remain in the ECU? Steiner: Yes! Although there is no need for direct measurement on the FlexRay bus while it is in service, the XCP module will be retained in production versions of the ECU. Diagnostics of the FlexRay ECUs is performed via OBD, the standard diagnostic interface in the vehicle. XCP plays a central role in testing and validating ECU functions and is therefore 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 on FlexRay here, has a so-called Seed&Key security mechanism. XCP is of course based on a Master Master-Slave -Slave principle. 4/1
3
l
AUTOMOTIVE
INTERVIEW
9.2006
The Master must ask the Slave for a "Seed", and this is used to compute an associated key. The Master does not grant the Slave access until the correct key is obtained.
Roel Schuermans, Schuermans, Gradu Graduate ate Engineer, Engineer, is Senior Product Management Engineer at Vector Informatik for t he “Measurement & Calibration Calib ration” ” produc productt line. As an expert in the FlexRay protocol he has been involved
Peteratzinger: Our hardware supplier has also installed another software protection mechanism. So protection is twofold.
in the development of XCP on FlexRay in the ASAM working committee up to its standardization and worked on its implementation in CANape.
What did Vector bring to the table as a partner with FlexRay? Important tant was was this We need Peteratzinger: Impor to measure and calibrate signals internal to the ECU. It might have been possible to turn to other suppliers for a solution. In this context there were many open
issues. During HANSER automotive’ automotive’s s FlexRay roduct Day in 2004 we met with experts from Vector, Vector, discussed these issues and formulated our requirements. Althoug Although h no standard existed yet at that time, Vector showed great interest in working with us, and wanted to implement a solution for us based on XC on FlexRay and then make it an official standard in the ASAM working committee. It was also a good fit, because Vector’s CANape product was already being used in the existing BMW tool environment, and this meant that our developers already had experience with this tool.
Mr. Pet Mr. Peteratzi eratzinger nger,, in retrospect retrospect what what is your assessment of this joint effor effort? t? From our perspective the collaboration with Vector was very good. Vector Vector handled most of the standardi standardi ation work and the first implementation. So I would like to express my sincere thanks to Vector Informatik. Calibration of ECUs with CANape and the XC Stack performed flawlessly flawlessly from the start, requiring just minimal modifications. Application of suspension control system with CANape as the XCP on FlexRay Master © automotive
FIRST
4/2
F LEXRAY
A P P L I C AT I O N
AT
BMW
The application is an active suspension control system. Each of
A special measurement and calibration protocol is needed for this
the four shock absorbers has a valve with dedicated electronics
XC on FlexRay FlexRay.. In efforts toward toward the standardi standardi ation of XC on
to control it. The valve is able to generate different damping
FlexRay in February 2006, Vector helped to give shape to its fun-
properties, since its continuously variable aperture determines
damental principles on the ASAM working committee and imple-
how much and how quickly shock absorber oil is pushed from
mented an application concept in the Vector measurement, cali-
the upper oil chamber to the lower one. The central control
bration and diagnostic tool CANape. This solution provides access
module is interconnected with the damper modules, the so-cal-
to all relevant ECU parameters over the FlexRay bus.
led satellites, via FlexRay. Different than in previously imple-
The ECUs of the suspension system transport all functional con-
mented suspension systems, while driving the vehicle the
trol data in the static area of the FlexRay protocol. Although XC
shock absorber characteristics can be independently adapted
communication is by definition allowed in both the static and
to the specific driving situation at all wheel suspensions. The
dynamic areas, BMW only utili utili es the dynamic area of the Flex-
satellite electronics controls excitations at the individual
Ray protocol for XC. It is also used for non-time-critical network
wheels, while the central ECU with its higher-level algorithms
management messages and the Transport Layer mapping of
monitors the overall effect on the chassis, and its control
FlexRay (i.e. diagnostics, coding, flashing). Due to strict time
system intervenes when pitching or rolling movements occur.
requirements of the control functions, the cycle time is 5 ms.
Direct access to internal ECU parameters is necessary to tune
Scheduling is not just set for the currently implemented applica-
the suspension system in driving trials and to assure system
tion, it will also be applied in precisely t he same form in the next
functions in system integration.
planned vehicle startups at BMW.
ECU Calibration
Universal tool support simplifies your calibration of ECUs. The versatile CANape tool lets you cover all application cases eff ortlessly: Distr. Systems
> Quickly and reliably capture measured data from various sources – synchronous and time-precise. Whether via CCP, CCP, XCP-on-CAN/FlexRay/Ethernet XCP-on-CAN/FlexRay/Eth ernet or from external e xternal test equipment > Conveniently calibrate the parameters of your ECU algorithms, either online in the ECU or offline in the Hex file
t n e m p o l e v e D
U C E
Diagnostics
> 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
Calibration U C E
> Benefit from a universal tool chain with extensive rapid prototyping capabilities and MATLAB/Simulin MATLAB/Simulinkk integration Software U C E
Vector supports you from functional development to production-ready ECU, in the laboratory, on the test bench and duManagement s s e c o r P
ring driving trials. Information and downloads: www.ecu-calibration.com
Vector Informatik GmbH Ingersheimer Str. 24 70499 Stuttgart Tel.. +49 711 8 0670-0 Tel www.vector.com
XCP-on-FlexRay XCP-on -FlexRay at Audi AUTOSAR-compatible AUTOSARcompatible 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 sof tware 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. Starting in 2009, Audi will be implementing the FlexRay communication bus on its next generation of sporty luxur y limousines. Since FlexRay – compared to CAN – offers a significantly greater bandwidth 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 thousand 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-onFlexRay. 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
4/4
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 fr amework of ECU calibration, and they then load the parameter set files into the ECUs’ application 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 Systems) 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
Figure 1: As the XCP-on-FlexRay master, CANape measures and calibrates individual nodes directly via FlexRay
they are CAN, FlexRay, Ethernet or SPI/SCI. In Februar y 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
transport layer software modules for the slaves using XCP-onFlexRay 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
Figure 2: Integration of Vector XCP software modules in an AUTOSAR 3.0 compatible application.
4/5
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 transport 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 module, 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 forming 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 t he XCP specification these frames must exclusively contain XCP data. Therefore, in the crosssystem 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 measurement 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 par ticipating ECUs. However, 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.
4/6
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 individual 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 handles 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
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, L-PDU, so that t hat memory 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 (generally 5 ms long). To significantly accelerate the start procedure before each measurement, the necessary initialization also had to be optimized thanks to the extension of the previous single “WRITE-DAQ” command. 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.
The new dynamic bandwidth management is only one of the FlexRay-specific CANape functions that support efficient ECU calibration 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.
4/7
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 measure 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 software 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
Christian Braun, Audi
studied Electrical Engineering at the Technical College of Munich, specializing in Data Technology. Technolo gy. 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 measurement 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 development for the area of CAN, J1939 and Diagnostics. Since 2005, she has been employed as a product management engineer at Vector Informatik GmbH in the area of Embedded Software Components.
Literature:
[1] www.asam.net Links:
Homepage Audi AG: www.audi.com Homepage Vector: www.vector www.vector.com .com Product Information CANape: www.vec www.vector.com/canape tor.com/canape Product Information XCP on FlexRay: www.vector.com/canape_flexray www.vector.com/canape_flexray
Figure 5: The slave uses “Incycle multiple DAQ list transmission” to measure very dynamic signals from a DAQ list. The signal is measured several times per FlexRay base cycle.
4/8
4/9
XCP at the Focal Point of Measurement and Calibration Applications
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, however, this means that the complexity of individual devices must grow to compensate. 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 runtime. A tremendous advantage of this successor protocol to CCP is its independence of the physical transport layer.
4/10
Today, control modules with more than 10,000 parameters are no longer uncommon. Since numerous dynamic processes need to be
cross-OEM standard. However, additional bus systems such as FlexRay, LIN, MOST, etc. came into play with the continued devel-
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
opment of automotive electronics. Since CCP’s use was restricted to CAN-networked applications, it increasingly encountered limitations in terms of its potential areas of use. This led to the development of its successor, XCP.
components. Therefore, it usually takes some effort until a sufficiently good compromise is found between stability, speed and
Universal standardized protocol
transient behavior. This can be accomplished by reading and modifying parameters during runtime (Figure 1).
The “Universal Measurement and Calibration Protocol” (XCP), like
To keep the time and cost requirements for ECU calibration low, engineers and technicians depend on powerful tools and standards
CCP, also has its origins in the Association for Standardization of Automation and Measuring Systems (ASAM) [1] and was standard-
that enable flexible read and write access to variables or memory contents. For this purpose, the CAN Calibration Protocol (CCP) was
ized in the year 2003. The “X” stands for the variable and interchangeable transport layer. XCP separates the protocol and trans-
created in the 1990s, a time in which CAN was the only dominant networking system in the automobile. CCP was slated to become a
port layers completely by means of a two-layer protocol, and it takes a Single-Master/Multi-Slave approach. Depending on the
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
identifies the amount of bandwidth still available and dynamically
example (Figure 2). A XCP Master is capable of communicating with different XCP Slaves simultaneously. These include: > ECUs or ECU prototypes
The available bandwidth is thereby optimally exploited in XCP com-
> Measurement and calibration hardware such as debugging interfaces or memory emulators > Rapid prototyping hardware > HIL/SIL systems
is sufficient demand for them from user groups. The broad range of supported transport layers enables simple migration from broadband solutions such as Ethernet or USB in the development phase to a final CAN interface in series production.
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: Minimal 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 number of parameters and scalability.
Single-Master/Multi-Slave concept
allocates it to the current application data traffic very efficiently. 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, XCP-on-MOST, if there
XCP is capable of utilizing the same protocol layer on different transport layers. This protocol is a universal measurement and calibration protocol that operates independent of the network type
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 t hem. 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 information 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
used. Currently, ASAM has defined these transport layers in standards: XCP-on-CAN, XCP-on-SxI (SPI, SCI), XCP-on-Ethernet (TCP/IP
Object over the bus to the ECU that acknowledges it over the same path after executing the requested service. CTOs provided are: CMD
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
(Command), RES (Response), ERR (Error), EV (Event) and SERV (Service Request Processor). The DAQ (Data Acquisition) and STIM
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]
(Stimulation) Data Transfer Objects are used for event-driven reading of measurement variables from memory, or for wr iting of values to the memory of the XCP Slave (Figure 3).
Interchangeable Interchangea ble transport layer
Figure 1: Optimization of a PID controller algorithm with the measurement, calibration and diagnostic tool CANape.
4/11
From automotive bus to standard PC interface
megabyte-size data volumes with 32-bit processors over highspeed networks such as Ethernet. Since an XCP driver is made up of
PC platforms are used almost exclusively as the Master for measurement 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-
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
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.)
basic consideration is: Number of signal transmissions vs. bus bandwidth. Overall, the XCP drivers are easy to implement and require just a few parameters.
and memory emulators can be implemented in this way. In principle, 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 conventional 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 driver 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 instabilities increases.
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
Versatile, scalable and resource-economizing
millisecond timer expires), the XCP Slave reads the previously defined data from the memory, copies them to a protected RAM
One and the same XCP driver code is used for all communication
area and sends them to the Master in the form of messages. This assures that the values originate from the same event cycle and
processes. It can serve to send just a few bytes that come from small controllers and interfaces, e.g. 8-Bit processors with integrated serial interface. Or the same code might be used to send
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
Figure 2: Separation of transport and protocol layers lets XCP utilize a large number of hardware interfaces.
4/12
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
storage schemes for characteristic maps, and much more. Highperformance calibration tools such as CANape from the Vector dis-
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.
play the characteristic curves and maps clearly on the screen in graphic diagrams or as numeric values in tables.
Besides the advantages of XCP compared to CCP already been mentioned, XCP also offers support of so-called cold-start measurements 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 measurement and calibration system, rather it is the time at which the data were created in the XCP Slave. This eliminates uncertainties attributable to possible delays in the transmission process, e.g. under conditions of insufficient bus bandwidth or high load.
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
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
have reached a certain maturity level that the developer generates from them a source code that is compiled together with other ECUrelevant 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 independent 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 sufficient for bypassing and modeling. This is good news, since solutions 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 op timized XCP Mas-
characteristic value tables are usually set up and optimized experimentally, e.g. at the test bench. A2L files serve to describe the
ter, simultaneously handles communication with the real ECU and with the model running on the PC (Figure 4). The ECU parameters
measurement variables and calibration parameters. The description options in the A2L f iles range from simple scalar parameters to
and model parameters can both be calibrated via CANape and XCP XCP..
Optimizing characteristic curves and maps
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
4/13
Flashing via XCP
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
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 principle, two approaches are conceivable: In solution 1, the flash rou-
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.
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 microcontroller’s RAM via XCP if it is needed for reprogramming. Besides con-
In the development of the first production vehicle with FlexRay, the BMW X5, this was a crucial factor in the decision by BMW engineers to rely on Vector’s XCP stack and CANape for calibrating the damper control system.
taining the flash routines for erasing the flash memory and rewriting data, the flash kernel also contains its own bus and SCP drivers for communicating communicating with the PC tool over the bus interface.
Translation of a German publication in Elektronik automotive, 4/2007
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, functional 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
Literature and Links: [1] www.asam.net [2] www.vector.com/canape [3] www.v www.vector.com/dow ector.com/downloads/drivers/xcp.exe nloads/drivers/xcp.exe
from NEXUS to XCP-on-Ethernet. The benefits to the user are independence from tool producers with proprietary solutions, and reusability of components.
Figure 4: Bypassing: Use of a standard PC with CANape as a test system.
4/14
XCP AT THE FOCAL POINT OF MEASUREMENT AND CALIBRATION APPLICATIONS
Andreas Patzer After a practical education to become an IT technician, Andreas Patzer studied Electrical Engineering at the Technical University of Karlsruhe between 1986 and 1993. He specialized in measurement and control engineering as well as information and automation 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” product line.
4/15
Quantum Leap in Microcontroller Measurement Technology Innovative ECU measurement concept for maximum data rates with minimal effects on execution time
In the development of complex ECU applications, there are greater 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 measur ing, calibrating and flashing are increasingly encountering limits with regard to the necessary data throughput. It was in this context that Robert Bosch GmbH initiated initi ated 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.
4/16
The long-range radar sensor LRR3 (Long-Range Radar) from Bosch
From a technical perspective, it made sense to implement a mod-
operating at 77 GHz is the “sensory input“ for many safety-related and driver assistance systems. They include various versions of Predictive Safety Systems (PSS) and Adaptive Cruise Control (ACC). These smallest radar sensors in automotive industry, used in pro-
ular layout of the measurement system and to make use of a standardized 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
duction vehicles since the beginning of 2009, are distinguished by their long acquisition range of 250 m and their wide aperture angle
100,000, without errors, a data rate of at least 4 MB/s is necessary while affecting the processor as little as possible.
of up to 45°. Together with a favorable price the application area is broadened from luxury class to mid-class vehicles and commercial
Existing solutions: Low data rates and high CPU load
vehicles. This development posed enormous challenges for Bosch engineers when it came to performing measurement and calibra-
In solutions that utilize the standardized measurement and cali-
tion tasks. Along with options for measuring and logging data, it was essential to have eff icient methods for calibrating and flashing
bration protocols [1] CCP or XCP-on-CAN, FlexRay, JTAG or SPI, a driver integrated in the ECU is responsible for periodically reading,
as well as bypassing. All of these applications require extremely high transmission rates with low latency times.
copying and sending out the desired signal v alues. Due to the large volume of data to be measured, the driver requires RAM memory
and processor resources that have limited availability. In addition, there is increased loading of the data bus, which impacts the ECU
modular VX1000 system developed by Vector (Figure 1). The base module primarily consists of a FIFO buffer, Dual-Port RAM (DPRAM)
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).
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
A high-performance debug interface on the microcontroller opens up new possibilities.
DPRAM there. From a logical perspective, since this d ata 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 crucial aspect of this approach is t hat all measurement processes occur
Bosch decided to join together with specialists at Vector to conceptualize 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 standardized 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 measurement adapter via a special high-speed cable. The data are transmitted 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 standardized XCP-on-Ethernet protocol.
via the mirror memory. To initiate a measurement and thereby initiate 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 memory map at the trigger time. This keeps the data to be measured constant over the measurement period. The XCP Engine now processes the data according to the protocol. A transmission rate of up to 5 MB/s was achieved for the XCP-onEthernet connection between the VX1100 measurement adapter
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 errorfree operation, the POD fulfills the same mechanical and electronic environmental requirements as the relevant ECU. This allows the POD to be installed in cr itical 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
Figure 1: The VX1000 system is distinguished by very high measurement data rates and very low software modification requirements and effects on ECU execution time.
ECU interface
ECU softwaremodification
ECU RAMreqmt.
Measurement data rate
ECU execution time effects
Bypass latency time
CCP/XCP on CAN
CCP/XCP driver software
1–2 KB
50 KB/s
Moderate
High
XCP on FlexRay
XCP driver software
2–16 KB
50–400 KB/s
Large
Moderate
XCP on JTA JTAG/SPI G/SPI
Tables for DAQ transfer via software
4–16 KB
200–400 KB/s
Large
Moderate
Data trace VX100 VX1000 0
Low
None
5,000 KB/s
Very low
Low
Table 1: Comparison of different methods of measurement data acquisition
4/17
and the measurement and calibration tool on the PC. A highly robust, temperature-resistant HSSL cable was used to ensure abso-
fulfilled all expectations set in the Bosch project. Last but not least, along with good cooperation between the two companies,
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
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
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
ACC, the CANape Option Advanced Multimedia offers specialized capabilities. Among other things, it lets users display objects detected by the sys tem in a perspective view in time-synchronously logged video images, which gives them a reliable means for verify-
microsecond, while bypass turnaround times of 300 microseconds were attained.
ing object detection algorithms.
Other application options and outlook From laboratory simulations to rapid prototyping These properties make the system ideally suited for the two primary applications at Bosch. The f irst 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 necessary for the LRR development, and it is now being used in other projects at the Bosch company. Compared to classic measurement
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 currently supported, besides the Freescale PowerPC, are the TMS570 from Texas Instruments and the Infineon TriCore processors with
principles, the VX1000 solution offers performance increases by a factor of 10 to 100 in all disciplines. The effect of measurements on
DAP interface which are widely used in engine controllers (Figure 2). DAP enables a cost-effective solution via a plug con-
the ECU, with CPU loading of less than 1%, lies significantly below usual values. The modular layout of the VX1000 system assures
nector on the mini-PC-board connected to the ECU. Cycle times of 50 microseconds are possible with the measurement and calibra-
cost-effective re-use as a measurement technology solution in subsequent projects, even with dif ferent microcontrollers.
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
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
offered in the near future. They include plans to support additional processors. Well-known semi-conductor manufacturers have approached Vector seeking recommendations recommendations on how to adapt their processor architectures in the direction of optimal measurement
could reach previously unattainable measurement data rates, it
functionality.
Figure 2: High flexibility in measurement and calibration tasks is achieved by modular layout with base module, ECU interface, cables and POD.
4/18
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: andreas.r
[email protected].
[email protected] com
Alfred Kless (Dipl.-Ing. (FH)), a Business Development Manager at Vector Informatik GmbH since 2004, is responsible for the “Network Interfaces” and “Measurement and Calibration” product lines. E-mail: alfred.kless@vector
[email protected] .com
4/19
Ef f icient Analysis Eff Analysis of Model Behavior Behavior in ECU Function Development
The focus in ECU function development is always on finding the best possible control algorithms and parameter combinations. A new solution now of fers users a single measurement and calibration tool with universal application – from initial model design to the production level ECU. In the framework of model-based software development, application functions are checked in an iterative process. This involves
MATLAB console, or modifying an M-script and running it. To visualize the signal responses that occur when t he model runs in Simu-
repeated runs of the model in Simulink from The Mathworks. Depending on the results, the developer may add function blocks
link, the user instruments the model by attaching scope blocks to each of the desired signals.
by drag-and-drop operation from libraries. These blocks are parameterized either directly in the function block with a numeric
Use of the standardized XCP measurement and calibration protocol gives the developer a considerably more user-friendly way to
value or by defining a parameter and its value on the MATLAB console. To modify an existing parameterization, the same steps are
eff iciently manage parameters and measure signals signals from the Simulink model without instrumentation.
executed again, either by looking for a block in the model and changing its value, setting the parameter and its new value on the
4/20
Communication via XCP-on-Ethernet
identification because the application’s data objects do not yet have a real ECU memory address. After instrumenting the model,
The ASAM protocol XCP (Universal Measurement and Calibration Protocol) has become established as the preferred solution for measuring and calibrating applications in ECUs. This approach gives application engineers convenient access to measurement data and
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.
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
Numerous measurement and calibration functions accelerate model optimization
ECU’s software, such as characteristic values (parameters, characteristic 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-
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 variables 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
port layer – such as the host name and server port – can be configured in the block’s dialog. They are necessary, since the “XCP-on-
model, or those of one or more subsystems, easily and conveniently. This provides a way to test and optimize a Simulink model with
Ethernet” protocol is used to interconnect the measurement and calibration tool with the Simulink model (Figure 1).
different parameter sets. CANape supports different file formats here. Once the model has attained the desired maturity level, the
After this parameterization step, the XCP Server is ready to use. The model’s A2L description file is generated from the block’s dialog. A virtual address is assigned to each Simulink object there. This is how the Simulink XCP Server explicitly implements address-
relevant parameters are saved to a parameter set file. The parameter 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
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
packets to obtain optimal settings for the entire model. These settings 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).
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 generated A2L file.
4/21
MATLAB/Simulink as Time Master
Summary
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 simulation step in Simulink, the associated time stamp is sent via XCP.
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
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
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 protocol over the entire development process, this reduces overall pro-
data sent out by the model can be visualized in CANape at simulation 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 XCPon-Ethernet enables better computing performance, since two separate 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
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.
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, costintensive test hardware entirely.
Figure 2: Efficient analysis of model behavior behavior by convenient navigation and quick access to objects of the Simulink model in CANape.
4/22
EFFICIENT ANALYSIS OF MODEL BEHAVIOR IN ECU FUNCTION DEVELOPMENT
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.
Figure 3: Overview of actions in CANape and their effects on the model in Simulink
4/23
Accelerated Turbocharger Development Eff iciently developing 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 Turbochargers high level of driving drivi ng dynamics. Today’s engine charging systems must flexibly adapt to engine speed and momentary power requirements; therefore, therefore, turbocharger control requires careful optimization. For the automotive supplier BorgWarner Turbo Systems, use of the CANape C ANape software tool has produced enormous streamlining potential in developing demo vehicles and hardware equipment for road durability tests. “Charging” of combustion engines is a core technology when it comes to fulfilling requirements for low fuel consumption, low haz-
on smaller turbochargers, e.g. on the Smart car, they may even reach 300,000 rpm. Accordingly, the challenges in the develop-
ardous emissions and quality over long service life, while simultaneously 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-
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
bocharging is also being used more frequently to improve the efficiency of gasoline engines, although the considerably higher
Kirchheimbolanden, in the German state of Rheinland-Pfalz, is one of the leading producers of turbochargers; it manufactures about
exhaust temperatures make it essential to use higher grade materials that are more expensive.
3.5 million charging systems annually in Germany and about 6 million worldwide. According to company information, BorgWarner in
Development competence and innovative force in demand
Kirchheimbolanden currently has the most advanced development center for turbochargers in the world. Besides various standard
When a gasoline engine is driven at high power output, the turbine
products for diesel and gasoline engines, its product line also includes advanced developments with multi-stage control of charg-
can become white-hot at exhaust temperatures of up to 1050°C. Simultaneously, charger speeds typically reach 220,000 rpm, and
4/24
ing systems as well as the eBooster concept.
From the “turbo hole” to controlled charging Due to its operating principle, high startup torque and high maximum 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
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
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
measurement, calibration and diagnostic tool performs valuable service. CANape is a powerful ASAM-conformant tool for all tasks related to ECU calibration. Via physical interfaces such as CAN, FlexRay or LIN and the standardized measurement and calibration protocols
equipped with bypass valve or the variable turbine geometry (VTG) that has become a standard today. Its adjustable vanes can be flexibly 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 compressor supports the turbocharger turbocharger..
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 backpressures and underlying parameters such as angles or positions of actuator elements by sensors and process them in the ECU. Actua-
CCP (CAN Calibration Protocol) and XCP (Universal Measurement and Calibration Protocol), parameters can be measured from a PC at runtime, 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 modifications. 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-
tors on the turbocharger consist of electrically or pneumatically actuated components for adjusting the vanes or actuating flaps
uation boards with integrated power electronics for driving the actuators. This may involve use of an actuator/sensor combination
and valves. Control of the turbocharger is an integral component of engine
that differs from the one in the production vehicle (Figure 1). CANape’s tasks here include calibration of the engine controller
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 d evelopment phase, BorgWarner uses
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
the Matlab/Simulink program package to design the relevant
A2L-based calibration of the application. The parameter files
Turbochargers Turbochar gers increase complexity of engine control
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
4/25
created in optimization of the turbocharger application may of course be exported from CANape and read back into Matlab/Simu-
changes take effect immediately, without requiring the detour of making a modification in Simulink and then regenerating the code.
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
These applications point out the capabilities of high-performance development and diagnostic software in practice. CANape makes part of the hardware equipment superfluous, saves on licenses for modeling software and noticeably accelerates develop-
To achieve an even more efficient solution, BorgWarner is now testing CANape in conjunction with a PC as a rapid prototyping platform. In this case, the system makes use of a DLL generated from
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
the Simulink model, which runs in the CANape context. The Matlab integration package supplied with CANape provides a CANape target with which the user generates CANape-specific code in the realtime workshop. The generation provides the DLL with an XCP interface, so that the user can access the DLL in measuring and cali-
times as short as 2 ms are possible on PC platforms.
Translation of a German publication in Hanser Automotive, 11/2007
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 communication 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
Links: Homepage BorgWarner Inc.: www.borgwarner.com www.borgwarner.com Homepage Vector: www.vector www.vector.com .com Product Information CANape: www.vec www.vector.com/canape tor.com/canape
the DLL can be calibrated exactly like a real ECU. Parameter
Figure 2: PC and CANape used as rapid prototyping environment with supplemental bypassing capability.
4/26
ACCELERATED TURBOCHARGER DEVELOPMENT
Gerd Spinner, BorgWarner Turbo Systems is 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.
4/27
Optimizing Optimizin g Driver Dr iver Assist Assistance ance Systems Verification of Object Recognition Recognition Algorithms by Driver Assistance Assist ance 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 b y Munich’s leading car producer also flowed into the design of an extension that effectively handles the special requirements involved in calibrating dr iver assistance systems. ACC (Adaptive Cruise Control) systems monitor the corridor in front of a vehicle, detecting vehicles ahead and maintaining the d istance to these vehicles desired by the driver. ACC systems also adjust the
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
car’s current speed to the traffic situation by automatically reducing 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.
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
What sounds relatively simple is in reality a great challenge for the development engineers, because a driving situation that a
system is not always clear and unambiguous. Some of the radar reflections are bumps in the road or simply false reports. This indi-
human driver is able to evaluate effortlessly is a nearly endless array of numbers in an ACC ECU. A forward-looking radar unit sup-
cates just how important it is to conduct a check of the acquired data (signals) based on visible evidence (the video image). The
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
reliability and operating safety of this system, with its acceleration and braking maneuvers, is in the truest sense a matter of life or
as polar coordinates with vehicle distance and azimuth angle. From these, the ACC ECU concludes whether the distance to the car ahead
death. Faulty behavior could lead to vehicle reactions that are incomprehensible incomprehensi ble to the driver. dr iver. For this reason, additional data are utilized at BMW to determine the exact distance between vehicles and exclude irrelevant objects.
is sufficient, whether braking needs to be initiated or whether it is possible to accelerate.
4/28
Besides dynamic driving data, data from GPS navigation are also used, for example.
To achieve optimal control functionality in the ECU, it is necessary to make numerous parameter modifications in an iterative process
Since there were no suitable products on the market, BMW initially supported the ACC development process by a tool it had written in-house, which helped engineers reach an objective assessment of the control algorithms. For production development, how-
that can be performed online or offline with CANape. BMW utilizes the CANape Option “Advanced Multimedia”, Multimedia”, an extension especially designed for developing driver assistance systems. A core element here is the Multimedia Engine, which displays ECU signals and
ever, BMW is now increasingly relying on standard products that can also be used by its suppliers.
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 (Figure 2). Only by means of such visual “matching” is it possible to
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 calibration protocols and flexible interfaces enable simple integration into an existing tool environment, leave room for engineering extensions and offer maximum future compatibility, compatibility, e.g. for obtaining objective test results to evaluate the assistance systems of suppliers. Even the base version of the measurement, calibration and diagnostic 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-
objectively assess the original mass of numbers. The BMW developers 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 calibrate the connected camera, all the BMW developers need to do is
tion protocols > Peripheral measurement technology
click eight reference points whose coordinates are known. Based on stored information, the tool automatically computes a coordinate
> Video and audio signals, and > GPS signals (optional).
transformation for each detected object – from global coordinates to image coordinates – and then displays the objects accordingly in the video image.
Figure 1: Time-synchronous real-time acquisition and visualization of internal ECU signals via CCP/XCP, and of signals from CAN, LIN and FlexRay buses and external measurement equipment equipme nt via CANape.
4/29
Vector also offers a suitable camera for the system, since BMW is not the only customer who values a universal and tested solution.
ional extensions. For example, today – at the request of BMW developers – a so-called “driving tube” is generated with data from
ECU developers using CANape AM can use practically any desired camera, from a webcam to a professional high-tech device, provided that it has a USB or Firewire port and a DirectX interface. Optimal results are obtained with a camera that has a logarithmic
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
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-
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
ber of cameras used, data might accumulate at rates of 20MByte/ sec or more. That is why developers work with reduced image resolution; data compression units are also used to reduce the data volume. A number of standard pixel graphics are provided for object representation 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-
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 performance. 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
tion, users can also integrate their own graphics. By visually comparing those objects detected by the ECU with the
Joint advanced development work
real environment, BMW developers now have an easy and efficient way to verify the object recognition algorithms of their ACC ECU.
For BMW, cooperative teamwork with the tool producer is a prerequisite for developing intelligent high-end systems. In this project, good cooperation has led to ideas that have spawned real funct-
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
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
4/30
OPTIMIZING DRIVER ASSISTANCE SYSTEMS
developing parking assistance systems. In the next f ew years, safety systems will also be implemented based on environmental data acquisition. They require even higher levels of computing performance due to the need for comprehensive detection of the surroundings 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.
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: Development: Driver Assistance and Active Safety, ACCSnG, ACC and DCC Calibration, BMW AG Alfred Kless is Business Development Manager for the “Measurement & Calibration” product line at Vector Informatik GmbH.
Figure 3: Use of the GFX Editor for convenient object-signal mapping and grouping in displaying objects
4/31
Trends in Embed Embedded ded Devel Devel opment opment Requirements Require ments and future future concepts concepts in hardware, hardware, sof sof t ware ware and tools In the future future contin continu ual ad van vances ces in the dede vel opment opment of auto automo motive tive electron electronics ics will place signif signif icant new demands demands on under under ly ly ing ing base technol technol ogies. In spite of growing growing funcfunctional tion al ity auto automo motive tive OEMs must keep costs under un der control; control; one way to achieve this is by limit lim iting ing the number number of ECUs in a car. At the same time extend extended ed safety safety and reli reliaabil ity concepts con cepts will be key ar eas of inter inter est. est. In light of the chal lenges lenges and mul titude titude of electron electronic ic compo components, nents, power power ful ful tools for de vel opopment, data data manage management ment and transfer transfer of software software modules modules into into a control control module’s module’s flash memoory will contin mem continue ue to gain in impor impor tance. tance. Without further Without fur ther advan advances ces in standard standardiiza zation tion it no longer be possi pos sible ble to master mas ter the growing growing complex complexiity of auto automo motive tive electron elec tronics. ics. In the 1990s auto au tomo motive tive OEMs such as Daimler Daim ler-[1] Chrysler Chrys ler went to great ef forts ef forts to estab establish lish the OSEK em embed bed-ded oper operat at ing ing system system as a binding binding standard standard for in-house dedevel opments opments and suppli supplier er compo components. nents. Today Today the real-time real-time and mul titask titasking ing capa capable ble oper operat at ing ing system system is used by auto auto-motive mo tive OEMs and suppli suppliers ers as the basis basis for improved improved code qual ity, good structur structuring ing and inte integra gration tion of the compo components nents of dif ferent ferent suppli suppliers. ers. In “Herstel “Herstel ler ler Ini Initi tiaative Soft ware” ware” [2] (HIS) too the large auto automo motive tive OEMs have come to an agreement agree ment on uniform uniform standards. standards. Working Working commit commit tees tees have al so so been estab established lished in the are ar eas of soft ware, ware, soft ware ware test ing, ing, process process assess assessment, ment, simu simula lation tion and tools as well as flash program programming. ming. The AUTO AU TOSAR SAR (Auto (Automo motive tive Open System Sys tem Archi Ar chitec tecture) ture) Consor Consorti tium um is respon responsi sible ble for the standards standards of future fu ture vehi vehicle cle gener generaations.
OSEK: Flexi Flexible and cal cula culable ble A number number of OEMs have certi cer tified fied OSEK imple implemen menta tations. tions. ApApplica pli cations tions of the “osCAN” “osCAN” OSEK imple im plemen menta tation, tion, for exam exam-ple, range from normal normal ECUs to mul ti-bus ti-bus gateways gateways and ininterface ter face hardware. hardware. In the Vector Vector Inter Interface face for MOST VN2600 the perform per formance ance capa capabil bil ities of osCAN osCAN were put to the test under un der a 133 MHz Al tera tera Excal Excal ibur control control ler ler process processing ing up to 35,000 Events/s, which corre corresponds sponds to a data data throughput throughput of 1.7 MByte/s. At gateway gateway produc producer er K2L osCAN-based osCAN-based solu solu-tions have demon demonstrat strat ed ed fast reac reaction tion times and precise pre cise timtiming.
5/0
An ECU for mul tiple tiple appli applica cations tions A clear trend in auto au tomo motive tive net working working is reduc reduction tion in the number num ber of ECUs in a vehi vehicle. cle. Today Today up to 40 ECUs oper operate ate in a luxu lux ury auto automo mobile. bile. To permit per mit imple implemen menta tation tion of even more functions, func tions, in the future future consist consist ent ent ef forts forts must be made totoward running running as many appli applica cations tions as possi possible ble within within the same control control module. module. The OSEK mul titask titasking ing oper operat at ing ing syssystem was speci specified for this purpose. purpose. Howe However, other other proper proper-ties are required required of the oper operat at ing ing system system for use in safetysafetycrit ical systems systems and to inte integrate grate the soft ware ware of dif ferent ferent produc pro ducers. ers. For exam example, ple, an appli applica cation tion must not disturb dis turb othother appli applica cations tions running running in paral par al lel. lel.
Al ways ways in demand: demand: The right timing tim ing One of the focal focal points in advanced ad vanced devel devel opment opment of emembedded bed ded oper operat at ing ing systems, systems, for future future OSEK versions versions and AUTO AU TOSAR, SAR, is the abil ity to moni monitor soft ware ware behav behavior ior relat relat ing ing to timing timing and memo mem ory access accesses. es. The most advanced advanced methods methods for moni monitor toring ing timing timing are provid provided ed by AUTO AUTOSAR-con SAR-conform formant ant imple im plemen menta tations. tions. Methods Methods such as “Exe “Execu cution tion Time Enforce Enforce-ment” and “Arriv “Ar rival al Rate Enforce Enforcement” ment” provide provide a manda mandato tory ry miniimum time budget min budg et for low-prior low-prioriity tasks too; these methods meth ods not only only detect detect errors, errors, they can al so so clearly clearly identi identify fy their sources. sources.
Reli Re liaable bounda boundaries for memo mem ory protec protection tion In the future future memo memory protec protection tion functions functions will restrict restrict a task’s access access to the memo memory space assigned assigned to it. This is eses pecial pe cial ly ly impor important tant to prevent prevent write access accesses es to other other data data segments, seg ments, detect detect stack overruns, over runs, and prohib prohibit it exe execu cution tion of
incorrect incor rect code. On the other other hand, tasks belong belonging ing to the same appli applica cation tion need to be able to access ac cess the same memo memory areeas, and special ar special system system functions functions such as drivers drivers could rerequire unre unrestrict strict ed ed memo memory access. access. A distinc distinction tion is made here between be tween so-called “Trust ed ed Appli Applica cations” tions” with full access access rights and “Non-Trust ed ed Appli Applica cations” tions” with restrict restrict ed ed access access rights. These names can lead to some confu confusion: sion: Non-trust ed Appli Applica cations tions are stored programs programs that cannot cannot real real ly ly cause any damage. damage. It is good design design practice practice to place function func tional al ities in Non-T Non-Trurust ed ed Appli Applica cations tions whenev whenever er possi possible. ble. Vector Vector Infor Informa matik tik therefore there fore of fers fers imple implemen menta tations tions that al so so permit permit call ing ing of Non-Trust ed ed Functions. Functions. They are intend intended ed for safety-crit safety-crit ical
applica appli cations tions and of fer fer a maxi maximum level level of reli reliaabil ity. A relat relat ed propos proposal al for handling handling this issue is sue in AUTO AUTOSAR SAR is current cur rent ly ly being be ing discussed discussed in a working working subcom subcommit mit tee. tee.
Better Bet ter hardware hardware support support in the future? fu ture? The cit ed ed timing timing and memo memory moni monitor toring ing functions functions can only only be imple implement ment ed ed ef ficient fi cient ly ly with suit able hardware hardware support. support. What are needed needed for memo memory protec protection tion are Memo Memory Protec Protec-tion Units (MPUs) that are tailored tailored to the needs of auto automo mo-tive appli applica cations tions in terms of options op tions of fered fered for number number and sizes siz es of memo memory blocks. In many cases cas es today today the small est est units that can be managed man aged are blocks 16 kByte in size. In the auto au tomo motive tive embed embedded ded field, howe however, substan substantial tial ly ly small er er memo mem ory units are needed. needed.
Figure Fig ure 2: osCAN osCAN Timin TimingA gAna naly ly zer zer ena enables simu simula lation tion of schedul schedul ing ing tables tables (schedules) (schedules) and compu computa tation tion of schedu schedula labil bil ity
5/1
Essential Essen tial ly ly the hardware hardware require requirements ments of current current and future future OSEK real-time real-time systems sys tems can only only be ful filled filled by a complete com plete rede re design sign of today’s today’s process processor or cores. Desired Desired features features are curcurrent ly ly being being nego negoti tiat at ed ed with semi semicon conduct duct or or produc producers. ers. Among the most impor im portant tant require requirements, ments, besides besides the named moniitor mon toring ing functions, functions, are an Inter Interrupt rupt Control Control ler ler for dif ferferent inter interrupt rupt levels levels with low laten latency cy times, hardware hardware support support in task switching, switching, and process processor or cores with as few regis reg isters ters as possi possible. ble.
Can er ror-free ror-free embed embedded ded systems systems be de vel de vel oped? oped? Interest Inter est ing ing possi possibil bil ities for master mas tering ing indus industri trial al complex complexiity are being being researched researched in ongo ongoing ing pro jects involv involving ing the inintensive ten sive appli applica cation tion of mathe mathemat ics ics to the engi engineer neering ing scien scien-ces. System Systemat at ic ic ana analyt ical methods methods ena enable detec detection tion of erer rors in real-time real-time systems sys tems that would other otherwise wise not even be revealed re vealed in exten extensive sive test ing. ing. Scien Scientists tists on the Veri Ver isoft pro ject have taken taken this one step further fur ther in conclud concluding ing that it is possi pos sible ble to devel de vel op op error-free er ror-free embed embedded ded systems systems and elecelectronic tron ic compo components. nents. Entire Entire systems systems consist consist ing ing of hardware, hardware, soft ware, ware, oper operat at ing ing system system commu communi nica cation, tion, appli applica cations, tions, etc., might be univer universal sal ly ly veri ver ified by methods methods of formal formal veri ver ifica fi cation. tion.
from Vector Vector Infor Informa matik tik save the flash data data togeth together er with ref eren er ences ces to the flash jobs in a ODX flash data da ta contain container. er. In some cases cases it may be neces necessa sary ry to ena enable modi modifi fica cation tion of flash data data in the field by means of a post-build proc ess. In this context context it is impor important tant to recal recal culate culate checksums checksums and signa sig natures, tures, in addi addition tion to other other param parameeters, and to send them to the flash boot loader loader during dur ing a flash update. update. The CANa CA Nape pe Graph and CANdi CAN dito to tools, both online online and off line line post-build process processes es can be handled handled in an el egant way, whereby re by a script language lan guage opti optimized mized for flash and diag diagnos nostic tic tasks is very helpful. helpful.
Manaaging dif fer Man fer ent ent memo memories in the ECU An impor important tant topic topic in repro re program gramming ming is the manage man agement ment of dif ferent ferent memo memory types in an ECU. Rising Ris ing complex complexiity, e.g. in mul tiproc tiprocess essor or or distrib dis tribut ut ed ed systems, systems, goes hand in hand with great er er memo memory require requirements ments and the use of dif ferent ferent types of memo memory. Some conven con vention tional al nonvol nonvol atile memo memory devi de vices ces have very dif ferent ferent physi physical charac character teris istics. tics. Among the impor important tant dif feren ferenti tiat at ing ing charac character teris istics tics of nonvol nonvol atile
Repro Re program gramming ming ECUs Reprogram Repro gramming ming of ECUs by flexi flex ible flash program programming ming is contin con tinu uing to draw great er er inter interest. est. The issues issues here do not relate re late to the actu actual al flash program programming ming technol technol ogy as much as they do to the organ or ganiiza zation tion and handling handling of the overall over all process. proc ess. Constraints Constraints vary from project to project, whereby whereby in addi ad dition tion to OEM and model mod el specif specif ic ic require requirements, ments, other other rerequirements quire ments must be consid considered ered such as hardware hardware proper properties ties (boot loader, loader, flash ini initi tiaation), flash formats, for mats, transport transport and diag di agnos nostic tic proto protocols. cols. If flash data data pass through vari various gateways, gate ways, for exam example, ple, it must be assured as sured that no data data can be lost there. These and simi similar questions questions must be answered answered indi in divid vidu ual ly ly for each partic par ticu ular sit uation. In practice practice it is not real re al ly ly possi possible ble to imple implement ment a simple simple auto automat mat ic ic approach approach here. Given Given these constraints, constraints, the ration rational al handling handling of flash process proc esses es contin continues ues to gain in impor im portance. tance. Therefore, Therefore, one trend leads in the direc direction tion of uniform uniform manage management ment of flash process proc esses es in standard standardized ized formats. for mats. For this purpose, purpose, tools
5/2
Figure Fig ure 4: Flash program programming ming
TRENDS IN EMBEDDED DEVELOPMENT
memory types are: Size of the write segment, memo seg ment, size of the erase segment, segment, maxi maximum number number of program programming ming cycles, cycles, and times required required to program program and erase. The lat est est flash memo memory is based on NOR Stacked Gate and MONOS MON OS (Met al al Oxide Oxide Nitride Nitride Oxide Oxide Sil icon) technol technol ogies. BeBeginning gin ning about 2008 new memo mem ory products products are expect expect ed ed that are based on FeRAM FeRAM (ferro-elec (ferro-electric), tric), MRAM (magne (magneto-re to-resist sist ive) and other oth er technol technol ogies, which could permit per mit unlim unlimit it ed ed numbers num bers of write/erase cycles. cycles.
HIS-standard HIS-stand ardized ized Memo Memory Driver Driver Inter Inter face face With the goal of achieving achiev ing uniform uniform memo memory manage management, ment, the HIS Auto Automo motive tive Group defined defined a standard standard for the Memo Memory Driver Driver Inter Interface face that is expe ex peri rienc encing ing growing growing support support from semi semicon conduct duct or or produc producers. ers. The inter interface face provides provides funcfunctions for ini initial izing, izing, de-ini de-initial izing, izing, erasing, erasing, program programming ming and reading reading data. data. In an imple implemen menta tation tion based on the HIS inin terface ter face a Mul tiple tiple Memo Memory Type I/O Mana Manager used to access access variious types of memo var mem ory. The memo memory config configu ura ration tion can be defined de fined conve convenient nient ly ly with the Geny Ge ny tool from Vector. Vec tor. The ususer bene benefits from maxi maximum flexi flexibil ity in access accessing ing dif ferent ferent memo mem ory types, includ including ing access access by SPI (Seri (Se rial al Periph Peripher eral al InInterface). ter face).
Time is money: mon ey: Accel Accel er er ating ating flash process processes es Depending Depend ing on the number num ber of ECUs, it may take a full hour or more to transfer transfer data data in the produc production tion envi environ ronment. ment. ThereTherefore auto automo motive tive OEMs and tool suppli sup pliers ers are consid consider ering ing adding add ing great er er bandwidth bandwidth to the transport transport media media as well as data da ta compres compression. sion. Scien Scientif tif ic ic studies studies indi indicate cate that for comcompression pres sion purpos pur poses es a combi combina nation tion of the LZ77 method meth od and an arithmetic arith metic coding coding method method would be ideal ide al and might reduce reduce data da ta vol ume ume by up to one half.
[1] OSEK stands stands for “Of “Of fene fene Systeme Systeme und deren deren Schnitt stel stel len len für die El ekektronik tron ik im Kraft fahrzeug” fahrzeug” (Open Systems Systems and their Inter Interfa faces ces for ElecElectronics tron ics in Motor Motor Vehi Vehicles). cles). [2]] “H [2 “Her erstel stel ler” ler” = Produc Producer er or OEM
Author: Au thor: Peter Liebscher Peter Liebscher (Grad (Gradu uate Engi Engineer) neer) studied studied tel ecom commu muni nica cations tions engi engineer neering ing at the Techni Tech nical cal Col lege lege in Esslin Esslingen, gen, Germa Germany. ny. Since 2002 he has been employed employed as Business Business Devel De vel opment opment Mana Manager at Vector Vector Infor Informa matik tik GmbH where he is respon responsi sible ble for the Embed Embed-ded Soft ware ware Compo Components nents product product line. Tel. +49-711/80670-4 + 49-711/80670-413, 13, Fax +49-711/80670-11 +49-711/80670-111, 1, E-mail: peter.lieb peter.liebscher@vec scher@vector-in tor-infor forma matik.de tik.de
5/3
DEVELOPMENT TOOLS
Timi iming, ng, memo memory ry protec protectio tionn and error error detection in OSEK systems by Peter Liebscher, Vector Informatik
A powerful certified OSEK implementation or AUTOSAR-conformant embedded operating system, together with a universal tool-chain, will make it possible to master the complexity of future electronic development.
Figure 1. Repre Representatio sentation n of gateway, system and bus APIs gateway,
The real-time and multitasking operating system OSEK is the standard in automotive embedded developments today. today. Its most important properties include low consumption of of processor resources resources and memory, memory, and event-driven task management that effectively handles both cyclic and non-cyclic non-cyclic program blocks. Continuing advances in automotive electronics and the new HIS and AUTOSAR standardization initiatives also place new demands on the operating opera ting system. system. Area Areass of emph emphasis asis in future operating system versions will be timing and memory protection. I
In the 1990s the large automotive OEMs introduced the OSEK/VDX operating system specification with the the goal of establishing a uniform standard for software in electronic control units.. The wide variety units variety of prop proprietary rietary embedembedded operating systems at numerous suppliers had proved to be an obstacle to smooth integration in light light of the growing growing significa significance nce of automotive electronics. Besides defining defining the the actual operating system core, core, OSEK also defines communication services and functions for network management. Since most automotive suppliers had already committed to a preferred operating system beforehand, automotive OEMs had to introduce introduce OSEK persuasive persuasively ly in some cases. Daiml DaimlererChrysler,for Chrysler, for example, example, made OSEK mandatory
as a standard for new new developments, both for in-house developments developments and those at suppliers. The company organized OSEK training courses, created OSEK design guides and supported operating system producers. It also financed one OSEK licence licence per supplier, whereby only certified OSEK operating systems were permitted. The costs costs of intro introductio duction n reached reached a high point in 2002 and then dropped significantly. significantly. In the meantime OSEK has generated its own success, and now most ECUs in the automotive automotive field run on OSEK operating systems. Efforts have paid off: applic Efforts application ationss based on OSEK have fulfilled expectations by their improved code quality, structuring and the ability to integrate components from different suppliers. At gateway producer producer K2L solutions with osCAN, the OSEK/VDX-conformant OSEK/VDX-conformant operating system from Vector Vector Informatik, have demonstrated fast reaction times and precise timing. Last but not least, what has proven proven to be decisive for OSEK in conjunction with a table-drivtable-dr iven interpreter concept are flexibility gains leading to shorter shorter development development times, higher quality and functionality and ease in creating variants. Leading the way way here were were comparcomparisons between OSEK with its preemptive scheduling and a fixed coded static approach with cooperativ cooperativee scheduling. scheduling. The “osCAN “osCAN”” OSEK implementation implementation has proven itself, not only in ECUs but also in the t he interface hardware 41
5/4
of the same compan company. y. In the the MOST Interface VN2600 osCAN’s capabilities were put to the test under a 133 MHz Altera Excalibur Excalibur controller: troll er: its processin processingg of up to 35,000 35,000 Events/s Events/s corresponds correspon ds to a data throughput of 1.7 MB/s. Requirements of an operating system grow in Requirements parallel with the continuing continuing penetration penetration of electronic technologies. technologies. In particular the advance of safety-relevant safety-re levant applications applications in the vehicle, such as fully electronically controlled steering and braking systems (X-by-wire), (X-by-wire), make determindeterministic behaviour essential under peak loads and fault conditions. conditions. For example, example, the specification specification of OSEKtime will supplement the event-driven OSEK with a time-triggered variant. Fault tolerance, tolerance, error detection detection mechanisms mechanisms and memory protection also play an important impor tant role in achieving system reliability. reliability. This has acquired special relevance, because in the future an ECU will handle multiple applications running simultaneously. simultaneously. In “Hersteller Initiative Initiative Software”(HIS; Hersteller = producer or or OEM) the large German automotive OEMs have come to an agreement on the standards needed to implement the named functions. Working committees have been established in the areas of sof softwa tware, re, sof softwa tware re testin testing, g, pro proces cesss assessassessment, simulatio simulation n and tools as well as flash programming. The AUTOSAR AUTOSAR (automotive (automotive open system architecture) consortium is responsible
June 2006
DEVELOPMENT TOOLS
properties are required of the operating properties operating system for use in safety-critical systems and to integrate the software software of of different producers. For examexample, an application must not not disturb other applications running in parallel. To prevent this from happening, new operating system features features are aimed at optimal monitoring of of the time behaviour beha viour of indivi individual dual tasks tasks and universal universal memory protection.
Figure 2. Function block block diagram with MOST interface VN2600 and an Altera Altera Excalibur controller controller
Figure 3. Deadlin Deadlinee monitoring monitoring to detect deadline deadline violations. violations. The error source source of Task 2 is not found in Task 1.
Figure 4. Tasks belonging to the same same application must be able to access the same memory areas.
for the latest standards for f uture vehicle generations, whereby the HIS HIS group is integrating its results into AUTOSAR and is representing uniformity interests there. When one considers that over 50 ECUs operate on a luxury automobile today and that there appears to be no end to potential new automotive electronic applica-
June 2006
tions in the foresee foreseeable able future, future, it becomes becomes clear why limiting the number of control modules in the vehicle has become a pressing topic. This objective can only be achieved if multiple applications run on the same control module. The multitasking OSEK operating system was specifie spec ified d for this this purpose. purpose. Ho Howev wever er,, othe otherr
Progress has varied considerably in the various development levels levels as a result of these efforts. OSEKtime, specified since 2001 for time-triggered tasks,with tasks, with its deadline monitoring, monitoring, only begins to cover functions that will be necessary in the future. future. Deadl Deadline ine monitorin monitoringg detects whether a task has ended by a prescribed point in time. time. Unfortunately Unfortunately,, the method cannot discern the causes for deadline violations. For example, example, if the monitor monitored ed task was interinterrupted by by a higher-prio higher-priority rity task, then the the monitored task is not really responsible for being unable to satisfy the prescribed time window.. In HIS-conform dow HIS-conformant ant OSEK extensions extensions memory protective functions are defined in addition to deadline deadline monitoring. monitoring. The most advanced is AUTOSAR with its “execution time enforce enfo rcement ment”” and “arrival “arrival rate enfo enforce rcement ment”” methods, metho ds, whic which h give low-priority low-priority tasks a mandatory minimum time budget, too. These methods are able to clearly identify error sources.Furthermor sources. Furthermore, e, in the various various operating system versions, Vector Informatik has integrated options for run-time measurements. Memory protection functions restrict a task’s access to the memory space assigned to it. This applies especially to preventing write accesses to other data segments, detecting stack overruns, overruns, and detecting detecting executio execution n of inco incorrect rrect code. code. Tasks belonging to the same application, on the other hand, must be able to jointly access the same memory memory area areas. s. Ho Howeve wever, r, speci special al system functions such as drivers could require full unrestricted memory access. A distinction is made here between so-called “trusted applications” applications” with full access rights and “non-trusted applications” applications” with restricted access rights. These names can lead to some conconfusion: non-trusted applications applications are programs programs that, due to restricted restricted memory access, access, cann cannot ot cause any damage. damage. The trusted applications, applications, on the other hand, hand, are given quasi quasi blind trust. The latter are easy to use but represent risks to system security and cannot provide identification of error errorss or error error sourc sources. es. It is good good design design practice to place functionalities in non-trusted applications whenever possible. Vector Informatik therefore offers implementations that also permit calling of of non-trusted functions. They are intended for safety-critical applications and offer a maximum maximum level of monitorin monitoring. g. A related proposal for handling this issue in
42
5/5
DEVELOPMENT TOOLS
AUTOSAR is currently being discussed in a working sub-committee. sub-committee. The cited timing and memory monitoring functions can only be implemented efficiently with suitable hardware support.What support. What are needed for memory protection are memory protection units (MPUs) that are tailored to the needs of automotive applications in terms of options offered for number and and size sizess of me memor moryy blocks blocks.. In man many y cases today the smallest units that can be managed are are blocks 16 KB in size. In the autoautomotive embedded embedded field, howev however, er, substantially smaller memory units are needed. Essentially Essentially,,
the hardware hardware requirements of of current and future OSEK real-time systems can only be fulfilled by a complete complete redesign of today’s processor cores. Desired features are currently currently being designed together with semiconducto semiconductorr producers. Among the most important requirements, requirements, besides the named monitoring monitoring functions, are an interrupt controller for different interrupt levels with low latency times, hardware support in task switching,and switching, and processor processor cores with as few registers as possible. For hardware-related hardware-related and time-critical automotive applications what counts is the ability to react as quickly as pos-
sible. Man Manyy of these appli application cationss consi consist st of of drivers and interrupt service routines (ISRs) which in contrast to the workstation field belong to the application here. It is problematproblematic that on today’s controllers the ISRs often can only be disabled disabled complet completely ely.. In general, general, disabling mechanisms must be made more efficient in implementations, implementations, since this basic
Interested in more information? Visit our specific website with links to: Real-time operating system for
automotive
control units Protocols
and drivers for CAN communication
Flash programming via CAN and LIN Solutions
for AUTOSAR AUTOSAR by Vector
Simply type-in Reader Service #: 783 at Embedded-Control-Europe.com/know-how
Figure Figu re 5. Phas Phases es of of a task task switc switch h
5/6
DEVELOPMENT TOOLS
function is executed very frequently. The quick task switches by which real-time embedded systems “thrive” “thrive”are are currently given just rudimentary support support in hardware. hardware. The majority majority of resources is consumed in saving and restoring the context. The context context is made up of core registers, regist register er banks, banks, memo memory ry access access registers, registers, floating point and arithmetic registers of the stack pointers, pointers, special peripheral units and a number numb er of opera operating ting system system variables. variables. A fully hardware-supported context switch would be ideal here. Furthermore, it has been shown that processors processors with a low number number of registers offer offer better performance. forman ce. Man Manyy registers registers can only be used meaningfully in typical workstation environments, because that that is where individual proprogram sequences run for a relatively long time without interruption. interruption. A potential trend here could lead in the direction of so-calle so-called d softcore processors and to compilers that permit configuration figurati on of the registers registers used. Inte Interestin restingg possibilities for mastering industrial complexity are being researched in ongoing projects involving the intensive intensive application of mathem mathematatics to the engineering sciences. sciences. Systematic analytical methods can be used to reveal critical situations situatio ns in the time behaviour behaviour of an OSEK system that would otherwise not be found even by exten extensive sive test testing. ing. In this this conte context, xt, too tools ls from the SympTAVision company enable targeted searches searches for “bottlenec “bottlenecks” ks” and “hot “hot spots”, informing users of worst-case situations. The advantages advantages of system systematic atic analysis analysis lie in
June 2006
reduced testing reduced testing effort, produc productivity tivity gains, gains, quality improvement and comprehensive system optimization. optimization. Scient Scientists ists on the Verisoft Verisoft project have taken this one step further in concluding that it is possible to develop absolutely error-free embedded systems and electronic components. They turn to the methods of formal verification to verify entire systems consisting of hardwa hardware, re, software software,, operating system communication, commun ication, applications, etc. In cooperation with project partner Infineon, the TriCore TriCore 2 processor processor,, the future flagship flagship of the compacompany’ss 32-bit microco ny’ microcontroller ntroller device line, offered the first evidence evi dence that this innovative technology could be applied to highly complex designs. The long-term long-term Verisoft Verisoft project project set up under the the project project leadership leadership of Prof. Dr. Wolfgang J. Paul Paul,, of the Un Universi iversity ty of Saarbrü Saarbrücken cken,, is being supported by the German Federal Ministry for Education and Research. Foundations and base technologies have been created for achieving reliable electronic systems in the automobile. automobile. Specific challenges must still be overcome overcome by by controller controller producers. producers. Apart from that it is the responsibility responsibility of automotive OEMs and suppliers to utilize the available resources optimally. optimally. A powerful certified OSEK implementation or AUTOSAR-conformant embedded operating operating system, together with a universal tool-chain, tool-chain, will make it possible to rationally rationa lly master master the complex complexity ity of future electronic development. I
44
5/7
Current Cur rent Chal lenges lenges in Auto Automo motive tive Net working working The vision vi sion of cross-platform cross-platform use of ECUs, uni ver ver sal sal commu communi nica cation tion capa capabil bil ity, ininter changea change abil ity and reus reusa abil ity of softsoftware modules modules be yond vehi vehicle cle and OEM bounda bound aries is fast approach ap proaching ing real real ity. Until Un til produc production tion matur matur ity is reached, howe how e ver, auto automo motive tive OEMs and suppli sup pliers ers still need to over come come a number num ber of chal lenges. lenges. Two presen pres enta tations, tions, one by Volkswag Volk swagen en and the other oth er by Bosch, giv en en at the Vector Vec tor Congress Congress in Octo Oc tober ber 2006 serve to explain ex plain this.
The topic topic of AUTO AUTOSAR SAR was a common common thread throughout throughout the twoday event sponsored sponsored by the special special ist ist in devel devel oping oping auto automo motive tive electron elec tronics, ics, Vector. Vector. For the over 350 partic par ticiipants meet ing ing in Stutt gart, the themes of diag diagnos nostics, tics, test ing, ing, qual ity and distrib distribut ut ed ed systems sys tems were of prima pri mary ry impor importance. tance. There was gener gen eral al agreement agreement that the cit ed ed visions visions and future future goals could only only be achieved by compre com prehen hensive sive standard standardiiza zation. tion. The well-worn road will contin con tinue ue to be traveled, traveled, where the rel ative impor importance tance of soft ware ware will concontinue tin ue to grow compared compared to mechat mechat ronics ronics and hardware. hardware. That is bebe cause in the future fu ture crucial crucial inno innova vations, tions, specif specif ic ic functions functions and brand-typiical proper brand-typ properties ties will be firmly firmly based in the soft ware ware area. area. Mechat Me chat ronic ronic systems systems on the other other hand will be respon re sponsi sible ble for basic basic functions func tions and emergen emer gency cy back-up systems systems for exam example. ple. This contin continued ued growth of electron electronic ic systems systems in the auto au tomo mobile bile must howeever be achieved without how without increas increasing ing the number number of control control
modules. That assures modules. assures stable stable net works works and compo components nents essen es sential tial to achieving achiev ing reus reusaabil ity of total total system system solu solutions tions across vehi vehicle cle lines that have dif ferent ferent Electri Electrical/Elec cal/Electron tronic ic infra infrastruc structures. tures. The global glob al chal lenges lenges lie in at taining taining qual ity improve improvements ments with simul si mul tane taneous ous cost reduc reduction, tion, creat creat ing ing new business business models models for handling handling soft ware ware as an inde in depend pendent ent product product with regard re gard to issues issues of util iza zation tion rights, pricing, pricing, product product lia liabil ity, etc., and real real izing izing a profes profession sional al organ or ganiiza zation tion with a high level lev el of process process matur maturiity.
Activ Ac tiv ities at Volkswag Volk swagen en and Audi The current current net work work archi architec tecture ture in Volkswag Volk swagen en vehi vehicles cles is based on a to total tal of seven seven CAN buses buses plus LIN sub-net works works and the K-line. Current Cur rent ly ly the focus focus in standard standardiiza zation tion work and devel devel opment opment ef forts at VW is on standard stand ardiz izing ing the diag diagnos nostic tic exchange exchange format format per ASAM/ODX, AS AM/ODX, working working togeth together er with other other leading leading auto automo motive tive OEMs
Figure Fig ure 1: Cur rent r ent network network ar chitec chi tecture ture at Volkswag Volkswagen. en.
6/0
in the HIS (Herstel (Her stel leri ler ini niti tiaative Soft ware) ware) inter interest est group, devel devel opoping and intro introduc ducing ing AUTO AUTOSAR-con SAR-conform formant ant soft ware ware compo components nents and util izing izing the FlexRay Flex Ray and MOST bus systems. sys tems. ODX has al ready ready proven proven its capa capabil bil ities in a future-ori fu ture-orient ent ed ed joint project. The new gener gen eraations of the Sprint er er and Craft er er vans from Daimler Daim lerChrys Chrysler ler and Volkswag Volk swagen en are simi sim ilar from the net working working archi ar chitec tecture ture perspec perspective. tive. An ODX convert convert er er process processes es the ODX diag di ag-nostic nos tic data data gener generat at ed ed by the Vector Vector Tool CANdela CANdela by DC and uses uses it to prepare prepare the diag diagnos nostic tic data data for VW. In intro introduc ducing ing AUTO AUTOSAR, SAR, VW and Audi are taking taking the approach approach of gentle gen tle migra migration tion and are convert convert ing ing ECUs gradu grad ual ly, ly, ECU by ECU. Iniitial ly In ly there will be dif fer dif ferent ent “next gener gen eraation” devel devel opment opment levlevels of the standard stand ard soft ware ware core, in which both AUTO AU TOSAR SAR and VW modules mod ules are imple implement ment ed ed simul simul tane taneous ously. ly. Adap Adapta tation tion work is fofocusing cus ing on hardware-re hardware-relat lat ed ed are areas such as the commu com muni nica cation tion drivdriver, I/O driver driver and memo memory driver driver as well as asso as soci ciat at ed ed abstrac abstraction tion modules. mod ules. Aft er er the last migra migration tion step, steps will be taken tak en to thorthoroughly ough ly sepa separate the appli ap plica cation tion layer layer from the under underly lying ing layers, layers, such that it only on ly access accesses es other other system system compo components nents via the AUTO AU TO-SAR Runtime Runtime Envi Environ ronment ment (RTE). Cost and perform per formance ance consid consider eraations play a key role in deci de cisionsionmaking mak ing process processes es for future future net work work technol technol ogies. Volkswag Volkswagen en is trimming trim ming its large number num ber of CAN net works: works: LIN and CAN-C are rere -
placing CAN-B. With regard placing regard to accept accept able bus load, the CAN bus has al ready ready reached its maxi max imum in some instan in stances. ces. Therefore, Therefore, begin begin-ning in 2008, time-triggered time-trig gered FlexRay FlexRay will assume assume certain cer tain chal lenglenging net working working tasks in distrib dis tribut ut ed ed systems. systems. In 2009 FlexRay FlexRay will be used in an extend extended ed appli applica cation tion with more than three bus nodes. MOST has been transport trans port ing ing data data in mul time timedia dia appli applica cations tions since 2003 on the Audi A8, and since 2006 on Volkswag Volk swagen en models models too. Addi Addition tional al imple implemen menta tations tions are planned [1].
Suppliers: Suppli ers: Gener Gener ating ating custom customer er util ity instead instead of mainmaintaining tain ing vari varie ety AUTOSAR AUTO SAR al so so simul simul tane taneous ously ly repre represents sents an oppor op portu tuni nity ty and a chal lenge for Tier-1 suppli suppliers ers such as Bosch [2]. For suppli sup pliers ers the bene ben efits of a global global de-facto de-facto AUTO AUTOSAR SAR standard standard lie in the use of stand ard plat forms; forms; this limits limits the number number of versions versions and facil facil itates cost-ef fect fect ive ive mass produc production. tion. Suppli Suppliers ers can devote devote their ener energies gies entire en tirely ly to gener generat at ing ing custom customer er util ity and do not need to employ em ploy their devel devel opment opment resour resources ces in numer numerous ous inter interface face modi modifi fica cations. tions. In imple implemen menta tation tion seeming seemingly ly contra contrary ry require requirements ments sometimes some times need to be sat isfied. isfied. For exam example, ple, on the one hand product prod uct lines should demon demonstrate strate unique compet compet itive advan advanta tages, ges, but at the same time they should fit trouble-free troub le-free into into dif ferent ferent system system envi envi-ronments. ron ments. System Sys tem model model ing ing and system system design design must be kept sepa sep arate in inte integrat grat ing ing the devi devices ces in a net work work of ECUs and bus syssys tems. This can only on ly be achieved by very close coop co oper eraation with
Figure Fig ure 2: Future Fu ture network network technol tech nol ogies at Volkswag Volk swagen. en.
6/1
OEMs in design design and eval uation of E/E infra infrastruc structures. tures. Migra Migration tion of today’s to day’s soft ware ware archi architec tecture ture to AUTO AUTOSAR SAR demands demands much inno innova va-tive work by the suppli supplier er in adapt ing ing devel devel opment opment process processes, es, methmethods, tools and ways of thinking. think ing. In the devel devel opment opment process process ef forts forts must be direct direct ed ed toward toward creat creat ing unam unambig bigu uous def ini nitions tions of inter interfa faces, ces, complet complet ing ing unfin unfinished ished work and deliv deliver ering ing results; results; precise precise soft ware ware speci specifi fica cations tions that prescribe pre scribe the depth of detail detail and devel devel opment opment levels levels are essen essential. tial. All in all what is required re quired are profes profession sional al techniques techniques of project and qual ity manage management, ment, project risk assess assessment ment and a high matur ma turiity level lev el among all part ners. ners.
Summa Sum mary ry and outlook out look Key goals of cross-OEM standard standardiiza zation tion ef forts forts are qual ity improve improve-ment, cost reduc reduction tion and ef ficient fi cient manage man agement ment of the contin con tinu uous ously ly growing grow ing soft ware ware share in the val ue-creat ue-creat ing ing process. process. The path totoward at taining tain ing these goals at OEMs and suppli sup pliers ers neces necessa sari rily ly ininvolves devel devel oping oping and intro introduc ducing ing system system compo components nents that concon form to AUTO AUTOSAR, SAR, HIS, etc. and facil facil itate reus reusaabil ity across OEM boundaaries. Simul bound Simul tane taneous ously, ly, power powerful ful bus systems systems such as FlexRay Flex Ray will reduce reduce the appli applica cation tion field of CAN.
6/2
At the Vector Vec tor Congress Congress it was made clear that to master mas ter the rising ris ing complex com plexiities involved involved in devel devel opment, opment, admin adminis istra tration, tion, data data exexchange and process process manage management, ment, it is increas in creasing ingly ly becom becoming ing necnecessa es sary ry to turn to massive massive soft ware ware support. support. Vector Vector supports supports vehi vehicle cle OEMs and suppli suppliers ers in net working working the described described systems systems with a uniuni versal ver sal tool chain and soft ware ware compo components, nents, wherein wherein contin continu uous adadvanced devel devel opment opment of the tools is al ways ways orient orient ed ed toward toward the lat est speci specifi fica cations tions of standards. standards. Liter ature ref er Liter er ences: ences: [1] Lange, K. (Volkswagen AG): “The chal lenge lenge of net working working and soft ware ware – Imple Implemen menta tation tion of new standards“, standards“, Vector Vector Congress Congress 2006. [2] Schnelle, Dr. K.-P. K.-P. (Robert Bosch GmbH): “AUTO “AUTOSAR SAR – Exam Examples ples of a syssys tem archi architec tecture ture from the perspec perspective tive of an auto automo motive tive suppli supplier”, er”, Vector Vec tor Congress Congress 2006.
ECU Software
Accelerate Your Your Embedded Embed ded Software Development with standardized basic software. Benefit from scalable software modules for CAN, LIN, FlexRay, J1939 and CANopen used successfully by many OEMs worldwide. > Build upon OSEK- or AUTOSAR-conformant operating systems Distr. Systems
which serve as the foundation for a stable implementation.
t n e m p o l e v e D
> Create functionally reliable networks with the communication stacks that most developers rely on. Test
> Use the Flash Bootloader to update your ECU software in a
U C E
controlled process and protect it from third party access. > Focus on your application development tasks by using AUTOSAR-conformant AUTOSAR-c onformant basic software modules.
s c i t s o
> Improve your eff iciency with Vector‘s tailored consultation
n g a i D
and development services. Calibration
U C E
Vector supports you with embedded software, configuration tools and services throughout the ECU development Software
U C E
s s e c o r P
Management
Vector Informatik GmbH Ingersheimer Ingersheim er Str. 24 70499 Stuttgart Tel.. +49 Tel +49 711 8 0670-0 www.vector.com
process.
More Informationen: www.ecu-software.com
The Univer Universal sal Gateway Gateway ECU Flexiible post-build conf Flex conf ig igu ura ration tion of AUTO AUTOSAR SAR gateways gateways High flexi flexibil ity of gateway gateway ECUs is achieved by the post-build princi prin ciple, ple, since it per mits mits a later later config configu ura ration tion at any time – even in late de vel de vel opment opment phases phases dur ing ing ECU inte integra gration tion or even in the field. This results re sults in uni ver sal sal ly ly deploy deploy able ECUs. Based on the AU TO AU TOSAR SAR standard, standard, a method method is present presented ed here that describes de scribes how the gateway gateway function func tional al ity in the finished finished ECU can be adapted adapted to new require re quirements. ments.
Embedded Embed ded systems systems can be config con figured ured at dif ferent ferent points in time: Before Be fore the source code runs through the build process, process, the socalled pre-compile pre-compile config configu ura ration tion occurs. occurs. This ena enables ef ficient fi cient imimplemen ple menta tation tion of config configu ura rations, tions, e.g. vari var iants, by macros macros or C prepreprocess proc essor or switches. switches. The link-time config con figu ura ration tion is typi typical ly ly used to gener gen erate ate a library library and to link it with ROM con stants. Further Fur thermore, more, there is the option op tion of config configu ura ration tion during dur ing the run-time of the ECU (run-time config configu ura ration), tion), e.g. by cal ibra bration tion or diag diagnos nostic tic comcommands. In such cases, cas es, the config configu ura ration tion param parameeters must be stored in RAM. In contrast contrast to the config con figu ura ration tion types al ready ready named, postbuild config configu ura ration tion is performed per formed on ECUs that have al ready ready been built by loading loading the config configu ura ration tion data data into into the ECU via a flash boot loader loader (Figure (Figure 1). The AUTO AUTOSAR SAR standard standard [1] defines defines three so-called Config Con figu ura ration tion Conform Con formance ance Classes Class es (CCC), which cover cover these dif ferent ferent config configu ura ra-tion times: > CCC0 refers refers to a Pre-Compile Pre-Compile Config Configu ura ration tion > CCC1 Link-Time Config Configu ura ration tion > CCC2 Post-Build Config Configu ura ration. tion. Just which of these config con figu ura ration tion options options is in princi principle ple avail able for a specif specif ic ic basic basic soft ware ware module module depends depends on the charac char acter ter of the module. module. The RTE (Runtime (Runtime Envi Environ ronment) ment) supports supports only only CCC0, because be cause it is closely closely linked to the appli ap plica cations tions and consists consists of ful ly ly gener gen erat at ed ed code. The oper operat at ing ing system system is al so so config configured ured only only at pre-compile pre-com pile time. Figure Figure 2 shows – in the context con text of the AUTO AUTOSAR SAR layer lay er model model – which config con figu ura ration tion options options exist exist for CAN commu communi ni-cation ca tion modules. modules.
Fig ure 1: Confi Con fig gura ration tion concepts con cepts in ECU de vel de vel opment op ment
6/4
Figure Fig ure 2: Confi Con fig gura ration tion classes classes in the lay er e r model model of an AU TO AU TOSAR SAR ECU
For the most part, the modules modules belong belonging ing to the commu com muni nica cation tion stack beneath beneath the RTE support sup port the post-build config configu ura ration tion per CCC2. Nonethe Nonetheless, less, these modules mod ules have some pre-compile pre-compile param parameeters such as the number num ber of channels, channels, use of data data buff ers ers (queues) and acti activa vation tion of debug debug modes. These set tings tings must be known at the time the library li brary is gener generat at ed. ed. In design designing ing an ECU, a sensi sensible ble strat egy must be devel devel oped oped for using using the post-build capa ca pabil bil ities of neighbor neigh boring ing modules. modules. For exam example, ple, it would make lit tle tle sense to provide pro vide post-build capa capabil bil ity to an indi individ vidu ual module module such as the PDU Rout er er (PDU-R), while only on ly grant ing ing pre-compile pre-compile config configu ura ration tion to all other other modules. modules.
When is a post-build imple implement mented ed for gateways? gateways? If the function functional al ity of indi individ vidu ual ECUs changes, chan ges, e.g. during during a vehi vehicle cle facel fa cel ift, ift, of ten ten changes changes must al so so be made to the commu com muni nica cation tion matrix ma trix of one or more net works. works. This is where post-build comes into in to play and ena enables simple simple adap adapta tation tion of the basic basic soft ware ware respon responsi si-ble for commu communi nica cation tion between between all ECUs of the af fect af fect ed ed net work. work. This elimi eliminates the need for recom re compil pil ing ing and linking link ing the code. If a gateway gate way ECU is designed de signed to be post-build capa capable, ble, it is easier eas ier to fit it in as a standard stand ard ECU in dif ferent ferent vehi vehicle cle models. models. Gateway Gateway ECUs perform per form a ma jor ma joriity of their tasks via the commu com muni nica cations tions basic basic soft ware. ware. A vehi vehicle cle facel facel ift ift for such ECUs of ten ten consists consists of just new or modi modified rout ing ing rela relation tionships, ships, for which all that is need ed is a recon re config figu ura ration tion of the basic basic soft ware. ware. The prima primary ry moti motiva vation tion for using using a post-build config configu ura ration tion is the fact that it avoids the need for a new build process, proc ess, and the config con fig-ura ration tion can be performed per formed in late devel devel opment opment phases phases during dur ing ECU inte in tegra gration tion or even in the field. This ap proach is of special special inter interest est for gateway gateway ECUs.
The gateway gate way ECU as flexi flex ible switchboard switchboard The main purpose pur pose of a gateway gateway ECU is to distrib dis tribute ute commu communi nica cation tion data da ta among the indi in divid vidu ual net works works in a vehi ve hicle. cle. Accord According ing to the AUTO AU TOSAR SAR standard, standard, vari var ious basic basic soft ware ware modules modules of the ECU perper form this task. Which modules mod ules are used depends depends on the specif spe cif ic ic gateway gate way function functional al ity that is needed: needed:
Figure Fig ure 3: AU TO AU TOSAR SAR basic basic software software modules mod ules with gateway gateway function func tional al ity
Nonetheless, Nonethe less, it should be not ed ed that in accord ac cordance ance with the AUTO AU TOSAR SAR speci specifi fica cation tion the PDUs must be rout ed ed imme immedi diate ately ly aft er er they are received. re ceived. Conse Consequent quent ly, ly, the PDU rout er er cannot cannot perform per form send type or cycle cycle time conver conversions. sions. In some cases, cas es, howe however, such a conver con version sion is neces necessa sary. ry. An exam example ple of this might be a FlexRay-CAN Flex Ray-CAN gateway gate way that routes a PDU from a Flex Ray cluster cluster to a CAN net work work as a CAN message. message. In this case, the gateway gate way ECU must for exam ex ample ple conform con form to mini minimum transmis transmission sion delay delay require requirements ments (debounce (debounce time) for the CAN message. message. In such cases, cases, the PDUs are therefore there fore rout ed ed direct direct ly ly to the COM layer, layer, which then assumes as sumes this task.
TP gateway gateway PDU gateway gateway The PDU gateway gateway is a part of the PDU rout er er (Figure (Figure 3). It routes enen tire data data packets, packets, known as Proto Protocol col Data Data Units (PDUs), from one net work work to anoth another. er. This princi principle ple assumes assumes that the PDUs are dede fined identi identical cal ly ly on both the source and target tar get net works, works, i.e. they must agree in length and contents. con tents. This means that data da ta can al so so be exchanged exchanged between between dif ferent ferent bus systems sys tems such as CAN, LIN or FlexRay. Flex Ray.
Another Anoth er task of the PDU rout er er is to route transport trans port proto protocol col data. data. This comes into in to play, for exam example, ple, if the exten extensive sive diag diagnos nostic tic data data of an ECU need to be auto au tomat mat ical ly ly transferred transferred from one net work work to anoth an other. er. This involves involves receiv receiving ing the data data via the Transport Transport Proto Protocol col (TP) and resend resending ing it. At first, the transmis trans mission sion occurs occurs above the TP (Layer (Lay er 4 in the ISO/OSI layers layers model), model), and this ena enables a conver conver-sion to dif ferent ferent address addressing ing methods methods and vari var ious bus systems. systems. To keep delays delays and RAM require requirements ments in the gateway gateway as low as possi pos sible, ble,
6/5
the TP gateway gateway supports supports so-called “on-the-fly rout ing“: ing“: The gategateway does not wait until un til all TP data da ta have been received, received, rather rather it al ready begins begins to resend resend the data da ta at an earli earlier er time point. Conse Conse-quent ly, ly, it receives receives and sends simul si mul tane taneous ously. ly.
Signal Sig nal gateway gateway Of ten ten just indi individ vidu ual signals signals are needed need ed on the other other net work. work. In this case, the gateway gate way does not transfer transfer the entire entire PDU, but only only sends indi individ vidu ual signals signals to the other oth er bus. To do this, it first disas dis as-sembles sem bles a received received PDU into into indi individ vidu ual signals, signals, so that it can then assem as semble ble them into in to one or more send PDUs. Besides Besides modi modify fying ing the signal sig nal compo composi sition tion and signal sig nal posi positions tions within within a PDU, the send type and cycle cycle time can al so so be changed. This method meth od is al so so used when a PDU should contain contain both rout ed ed signals signals and signals signals gener generat at ed ed didirect ly ly in the gateway gate way ECU.
Techni Tech nical cal aspects aspects of post-build config con figu ura ration tion Data structures Data structures for the post-build config configur uraable data data essen essential tial ly ly have two dif fer dif ferent ent types of layouts layouts (Figure (Figure 4). In the non-fragment non-frag ment ed ed variiant 1, the data var da ta structures structures are arranged ar ranged one direct direct ly ly aft er er anoth anoth-er in memo mem ory. The indi individ vidu ual data data structures structures are accessed ac cessed via an inin direc di rection tion table table locat locat ed ed at a stat ic ic posi position. tion. The data data structures structures on the other other hand may vary in size depend de pending ing on the post-build conconfigu fig ura ration. tion. The remain remaining ing memo memory is a contig con tigu uous block that is
Fig ure 4: Data Da ta structures struc tures for post-build con fig ura ration tion
6/6
avail able for other other purpos purposes. es. Howe However, the basic basic soft ware ware modules modules are highly highly depend dependent ent with respect respect to their imple implemen menta tation. tion. If the babasic soft ware ware origi originates from dif ferent ferent soft ware ware suppli suppliers, ers, this vari var iant gener gen erates ates a high coor coordi dina nation tion needs and is therefore therefore imprac impracti tical. cal. In the fragment frag ment ed ed vari variant 2, the data data structures structures are al ways ways placed at a stat ic ic posi position tion in memo mem ory. Here, at the time of design, de sign, an asas sumption sump tion is made concern concerning ing the largest largest possi possible ble memo memory usage usage of indi in divid vidu ual data data structures. structures. In practice, practice, some unused unused memo memory bebetween the data data structures structures remains. remains. With regard re gard to runtime runtime behav behav-ior, vari var iant 2 is more ef fi ef ficient, cient, since no indi in direc rection tion is needed needed in data access. access. Despite Despite the fragmen frag menta tation, tion, this vari var iant al so so of fers fers advanta advan tages ges in terms of memo memory ef ficien fi ciency, cy, since an indi indirec rection tion table is unnec unneces essary. sary. The use of post-build data data structures structures has an enormous enor mous ef fect fect on the design de sign of the basic ba sic soft ware ware modules. modules. In the case of the pre-compre-com pile config configu ura ration, tion, for exam example, ple, the sepa separa ration tion of code and data data is not required. required. This makes it easier eas ier to imple implement ment config configu ura ration tion set tings very ef ficient fi cient ly ly with macros macros or preproc preprocess essor or switches switches and to gener gen erate ate opti optimized mized C functions functions with the help of code gen er eraators. The princi principle ple of the post-build config configu ura ration, tion, on the other oth er hand, requires re quires strict sepa separa ration tion of code and data da ta for post-build param parameeters. A gener generaator is only only avail able for gener generat at ing ing constants constants tables. ta bles. The C functions functions are stat ic. ic. Figure Figure 5 shows how the dif fer dif ferent ent config config-ura ration tion concepts concepts appear appear based on code exam ex amples. ples.
THE UNIVERSAL GATEWA GATEWAYY ECU
Figure Fig ure 5: Code exam ex amples ples for dif fer fer ent e nt confi con fig gura ration tion concepts con cepts
A gateway gateway ECU requires re quires knowl edge edge of large numbers numbers of signals signals or messa mes sages. ges. This infor informa mation tion exists exists in the form of data da ta structures structures in the ECU’s memo mem ory. As a result, re sult, in gateway gateway ECUs the commu communi nica cation tion layers lay ers in the soft ware ware archi architec tecture ture take up a consid consider eraable share of memo mem ory and runtime runtime resour resources. ces. Even when the more ef fi ef ficient cient vari var iant 2 is select se lect ed, ed, the post-build capa capable ble layout layout of the ECU typi typ ical ly ly causes caus es increased increased resource resource require requirements. ments.
A tool chain for post-build config con figu ura ration tion of gateway gateway ECUs Besides the aspects Besides as pects of memo memory and runtime runtime resour resources ces in the ECU, the post-build princi principle ple al so so requires requires new process processes es to coor coordi dinate nate config con figu ura ration tion param parameeters between between partic par ticiipat ing ing devel devel opment opment part ners and exchange exchange them reli reliaably. One impor important tant source of support support here is a well-function well-func tioning ing tool chain. Figure Figure 6 shows the tool chain from Vector Vector Infor Informa matik, tik, which can al so so be used for post-build conconfigu fig ura ration tion of gateway gateway ECUs.
Figure Fig ure 6: Vector Vec tor tool chain for the post-build config con fig ura ration tion
6/7
At the begin beginning ning of a devel de vel opment opment project, the ECU suppli sup plier er sets up the project based on the Pre-Config1 Pre-Config1 param parameeter set. Vector Vector proprovides this param pa rameeter set along with the base soft ware ware deliv delivery ery for the ECU, and it contains con tains pre-compile pre-compile param parameeters that do not have any ef fect fect on the post-build config con figu ura ration. tion. Exam Examples ples of this are gener gen eral al set tings tings and use of the Devel De vel opment opment Error Error Tracer Tracer (DET). In coor coordi dina nation tion with the ECU suppli sup plier, er, the auto automo motive tive OEM provides provides the Pre-Config2 Pre-Config2 param parameeter set and an ini in itial net work work descrip description tion (data (da tabase). base). The Pre-Config2 Pre-Config2 param parameeter set contains contains those pre-compre-com pile and link-time param pa rameeters that have an ef fect ef fect on the post-build process proc ess and need to be defined defined in advance. advance. Exam Examples ples of this are the address ad dresses es of post-build data data in the ECU, compi com piler ler options options and maxi max imum memo memory size (Flash and RAM). The ini in itial net work work descrip description, tion, which the auto automo motive tive OEM might create cre ate with the DaVin Da Vinci ci Net work work Design De signer er tool, for exam example, ple, contains contains all signals sig nals rel evant to the ECU. In the case of a gateway gate way ECU, the rout ing ing rela relation tionships ships between between the net works works are al so so described described there. The ECU suppli sup plier er uses uses the GENy GENy tool to config configure ure and gener generate ate the basic ba sic soft ware ware using using this input in put infor informa mation. tion. The rout ing ing infor informa ma-tion is prepared prepared in the form of gener generat at ed ed data data structures structures (tables) (tables) for the indi individ vidu ual basic basic soft ware ware modules. modules. This provides provides a founda founda-tion for devel devel oping oping the ECU based on the ini in itial net work work descrip descrip-tion. During Dur ing the actu actual al post-build process, process, these tables ta bles must be regen regener er-at ed ed and exchanged exchanged in the ECU. The basis ba sis for this is a modi mod ified net work descrip description tion by the auto automo motive tive OEM. If the updat updat ed ed tables tables now exist ex ist in bina binary ry format format – and indeed in deed in precise precisely ly the same form as the compi compiler ler would have creat creat ed ed them – then anoth an other er compil compil ing ing and linking linking run is obso obsolete. lete. The knowl edge edge about the compi compiler ler bebehavior hav ior when gener generat at ing ing the bina binary ry format format is stored in GENy. GE Ny. This binary bina ry file is now convert con vert ed ed to a standard standard hex format format and is loaded load ed into in to the ECU via the CANfbl flash boot loader. loader. If the pre-config pre-config ininforma for mation tion is known to the auto au tomo motive tive OEM, the OEM it self self can al so so perform per form the post-build process process direct direct ly. ly.
6/8
Summa Sum mary ry The post-build process process provides provides flexi flexibil ity when changes changes are made in the commu communi nica cation tion descrip description. tion. Config Configu ura ration tion is even possi possible ble in late devel devel opment opment phases phases during dur ing ECU inte in tegra gration tion or in the field. This approach ap proach is espe especial cial ly ly useful useful for gateway gateway ECUs, since it is possi pos sible ble to adapt them to modi modified net work work condi conditions tions without without having having to change the complete complete appli applica cation tion code. Howe However, the increased increased reresource require requirements ments must be taken taken into into account. account. In any event, a gateway gate way ECU is an inter in terest est ing ing candi candidate date for the post-build process, process, at least during dur ing the devel devel opment opment phase. Reference: [1] AUTO AUTOSAR SAR speci specifi fica cations: tions: www.auto www.autosar.org sar.org
Hart mut Hörner Hartmut Hörn er studied stud ied Electri Electrical cal Engi Engineer neering ing at the Univer Uni versi sity ty of Stutt gart gart from 1987 to 1992. Aft erwards, erwards, he worked as a soft ware ware devel devel oper op er for ATM Test Systems. Systems. In 1998, Mr. Hörner Hörner came to Vector Vector where he is the team leader leader respon responsi sible ble for the devel devel opment opment of embed embedded ded soft ware ware compo components. nents. Hart mut mut Hörner Hörn er repre represents sents Vector Vector on vari var ious standards standards working work ing commit commit tees tees (OSEK, ISO, AUTO AUTOSAR). SAR).
Start your Series Development with AUTOSAR 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.au www.autosar-solu tosar-solutions.com tions.com
Vector Informatik GmbH Ingersheimer Str. 24 70499 Stuttgart Tel. +49 (0) 711/80670-0 www.vector-informatik.com
Early Ear ly Migra Migration tion creates creates Oppor Opportu tuni nities ties for Inno Innova vations tions Mix of Indi Individ vidu ual Soft ware ware and AUTO AUTOSAR SAR Compo Components nents in Vehi Vehicle cle Electron Electronics ics ECU de vel opment opment in the motor mo tor vehi vehicle cle is evolv ing ing rapid rapidly. ly. This ar ticle ticle sheds light on one impor im por tant tant aspect: aspect: The intro introduc duction tion of standard standardized ized basic basic software software defined defined by the AU TO AU TOSAR SAR de vel opment opment partner partner ship. ship. If AU TO TOSAR SAR software soft ware compo components nents are added add ed to the over all all ar chitec chitecture ture in a stepwise stepwise and dif fer fer enti entiat ated ed manner, manner, this assures assures qual ity enhance enhancements. ments.
At the begin beginning ning of 2007, the AUTO AUTOSAR SAR devel devel opment opment part nership nership defined, de fined, in its Release Re lease 2.1, a practice-test practice-test ed ed soft ware ware archi architec tecture ture that is used as a founda foun dation tion for devel devel oping oping reus reusaable appli applica cations. tions. With publi publica cation tion of these speci spec ifi fica cations, tions, in the future fu ture it will be pospossible si ble for all compa companies nies belong belonging ing to the AUTO AUTOSAR SAR devel devel opment opment part nership nership to devel devel op op AUTO AUTOSAR-con SAR-conform formant ant compo components. nents. Howe However, its practi practical cal imple implemen menta tation tion is not trivi triv ial. The transi transition tion from indi in divid vidu ual soft ware ware to standard stand ard soft ware ware has to be well-planned and is certain cer tainly ly only only conceiv conceivaable if a stepwise step wise approach approach is taken. taken. The AUTO AUTOSAR SAR philos philoso ophy and descrip description tion language language create create a diverse diverse envi en viron ronment ment for using using standard standardized ized soft ware. ware. In practice, practice, this may be a mixed instal in stal lation lation of AUTO AUTOSAR SAR and non-AUTOSAR non-AUTO SAR compo components nents or an inte integra gration tion of basic basic soft ware ware for specif specif ic ic plat forms forms by a numnumber of dif ferent ferent soft ware ware suppli suppliers. ers. For both types of imple implemen menta ta-tion, it is neces necessa sary ry to clari clar ify and define define the rel evant constraints constraints from vari var ious perspec perspectives. tives.
Vehi Ve hicle cle per spective spective From the OEM perspec per spective, tive, basic basic plat forms, forms, techno technolog logiical plat forms, etc. are being being devel devel oped, oped, from which the next gener gen eraations of cars will be derived. derived. The under underly lying ing goal here is to inte in tegrate grate one and the same ECU in many vehi ve hicles cles and thereby there by reduce reduce costs. At the same time, the qual ity and the stabil sta bil ity of the vehi vehicle cle electron electronics ics should be improved. improved. This results results in a dilem dilemma ma between between the impon impon-deraables of a newly der newly intro introduced duced technol technol ogy and the stabil stabil ity of the product. prod uct.
Ar chitec chitectur tur al al per spectiv spectiv From the point of view of an ECU indi in divid vidu ual soft ware ware compo components nents are discern discerniible. At the same time, two contra con tradict dict ory approach approaches es are being be ing fol lowed lowed with regard regard to the base soft ware ware of today’s today’s ECUs. On the one hand, many OEMs require re quire specif specif ic ic soft ware ware compo components nents or at least they speci spec ify them. On the other oth er hand, control control module module proproducers duc ers are striving striv ing inter internal nal ly ly to al ways ways use the same archi ar chitec tecture ture for a control control module module plat form. form. Added Added to this is the fact that the de gree of standard standardiiza zation tion of the soft ware ware is not as compre com prehen hensive sive as
Figure Fig ure 1: Ear ly l y intro introduc duction tion of a uniform uni form inter inter face face and RTE simpli simplifies fies migra mi gration. tion.
6/10
described by AUTO described AUTOSAR. SAR. The goal here is to ap ply a standard standard to soft ware that does not serve the pur pose of compet compet itive dif feren ferenti tiaation, thereby thereby creat creat ing ing space for new inno in nova vations. tions. Opti Optimal mal ly, ly, low ininvest ment ment costs would be incurred in curred by new tools, since those tools al ready in service service can for the most part be re used.
Clear migra migration tion strate strategy as factor factor in success success When these two perspec per spectives tives are applied applied to a deci decision sion on intro introduc duc-ing AUTO AUTOSAR, SAR, it makes sense to select se lect a mul tistage tistage approach. approach.
Stage II - Replace: Replace:
Non-AUTOSAR compo Non-AUTOSAR components nents can now be replaced re placed gradu gradual ly ly by AUTO AUTO-SAR compo components nents without with out put ting ting the overall over all archi architec tecture ture at risk or requir re quiring ing repro reprogram gramming ming of other other modules. modules. The goal here is to set up an AUTO AUTOSAR SAR archi architec tecture ture and use the appro ap propri priate ate tools. Ini Initi tiat at ed in indi individ vidu ual ECUs, in the end the entire en tire vehi vehicle cle is concep conceptu tual al ized with AUTO AUTOSAR SAR soft ware, ware, start ing ing with system sys tem design design and endend ing with inte integra gration. tion.
Using Us ing the AU TO TOSAR SAR ar chitec chitecture ture in design designing ing new ECUs Stage I – Set up the archi architec tecture ture and expand: ex pand:
The first step is to compare compare the exist exist ing ing custom custom soft ware ware and the AUTO AU TOSAR SAR archi architec tecture. ture. Aft er er ana analyz lyzing ing overlaps overlaps and inte integra gration tion popotentials, ten tials, a deci decision sion is made regard re garding ing which modules mod ules will be prepreserved and which ones can be replaced re placed by standard standard soft ware. ware. At this stage it is recom rec ommend mended ed that a sepa sep arat ing ing layer layer be intro introduced duced between be tween appli applica cation tion soft ware ware and base soft ware ware as well as a standstand ardized ard ized inter interface. face. The so-called Runtime Runtime Envi Environ ronment ment (RTE) serves as the link for the neces nec essa sary ry data data exchange, exchange, and as a buff er er with defined de fined inter interface face it ena enables modu modular program programming ming without without depend depend-encies. en cies. This is how AUTO AU TOSAR SAR compo components nents can be inte in tegrat grat ed ed without without making mak ing addi addition tional al changes changes to the custom custom and appli ap plica cation tion soft ware. ware. The custom custom soft ware ware is linked to the system sys tem archi architec tecture ture via an AdAd apta ap tation tion Layer Layer to ena enable data data exchange exchange with the AUTO AU TOSAR SAR compo compo-nents via the RTE; see Figure Fig ure 1. To mini minimize cost and ef fort ef fort and arrive arrive at an opti op timal mal overall overall solu solu-tion, it is helpful help ful at this point to inte integrate grate the custom cus tom soft ware ware in the config configu ura ration tion tools.
Figure Fig ure 2: Inte In tegra gration tion of custom custom software software in the AU TO TOSAR SAR ar chitec chi tecture. ture.
As implied implied in Figure Fig ure 2, essen essential tial parts of the indi in divid vidu ual soft ware ware can al so so be reused reused in the framework frame work of an AUTO AUTOSAR SAR archi architec tecture. ture. They are then linked to the appli ap plica cation tion via an adap ad apta tation tion layer layer as a comcomplex device device driver. driver. An overlap overlap matrix matrix shows the portions por tions in which AUTO AU TOSAR SAR soft ware ware can be intro introduced duced without without great risk. Prima Primari rily, ly, the memo memory section section and the IO hardware hard ware abstrac abstraction tion can be migrat mi grat ed ed smoothly. smoothly. Cluster Cluster memo mem ory manage management ment in partic par ticu ular has very clear and eas y-to-use eas y-to-use inter in terfa faces ces that ena enable its early ear ly migra migration tion to new ECUs. In commu communi nica cation tion and diag diagnos nostics, tics, on the other oth er hand, there are consid con sider eraable overlaps overlaps between between propri proprieetary vehi vehicle cle soft ware ware and the standard stand ard modules modules of the AUTO AUTOSAR SAR basic basic soft ware. ware. In the inter in ter-est of stabil stabil ity in the vehi vehicle, cle, a more conserv con servaative approach approach is rerequired here. Many OEMs util ize ize plat form form ECUs, in which exist ex ist ing ing soft ware ware modules modules are transferred transferred to new vehi vehicle cle models. models. One impli impli-cation ca tion is that the net work work and commu communi nica cations tions strat egy cannot cannot be changed over the short term. In the case of an im me medi diate ate migra migra-tion, ECU cal ibra bration tion and off-board diag diagnos nostics tics would al so so need to be adapt ed, ed, which in practice prac tice would lead to signif signif icant problems. problems. Therefore, There fore, the simplest simplest path is to use the exist ex ist ing ing commu communi nica cation tion stack in the AUTO AU TOSAR SAR envi environ ronment ment too. This stack can be linked to the RTE via an adap ad apta tation tion layer. layer. Vector Vec tor has the neces nec essa sary ry expert expert ise ise in this area ar ea and can propose propose the right solu solutions tions for creat creat ing ing such mixed archi ar chitec tectures tures or supply supply them to the custom customer. er. For exam example, ple, the famil famil iar iar XCP proto protocol col can be inte inte-grat ed ed in a migra mi gration tion archi architec tecture ture so that exist exist ing ing measure measurement ment and cal ibra bration tion tools such as CANa CA Nape pe can be used. The described described approach approach is not a pure top-down approach, approach, since at many points AUTO AUTOSAR SAR soft ware ware can even be inte in tegrat grat ed ed on lower lower hardware-re hard ware-relat lat ed ed layers. layers. Its modu modular structure structure and defined defined inter interfa fa-ces help in imple im plement ment ing ing the standard stand ard soft ware ware on the SPAL level lev el without with out af fect fect ing ing the upper upper layers. layers. This of fers fers an enormous enor mous advan advan-tage with regard regard to reuse. reuse. Vector Vec tor Infor Informa matik tik util izes izes the concept concept of Product Product Cluster Clustering ing here. Based on AUTO AUTOSAR SAR speci specifi fica cations, tions, the products products of fered fered range over a number number of layers layers and provide provide total total solu solutions tions for memo memory, commu commu--
6/11
nication, nica tion, diag diagnos nostic tic and system sys tem are areas. These are inde independ pendent ent ly ly function func tioning ing are areas, some of which can al so so be imple implement ment ed ed without without AUTO AU TOSAR SAR archi architec tecture. ture. Cluster Cluster memo memory for exam example ple can be inte in tegrat grat ed quickly quickly and easi easily in many ECU appli ap plica cations; tions; see Figure Figure 3.
Support Sup port by tools An impor important tant pil lar lar in the intro in troduc duction tion of AUTO AUTOSAR SAR relates relates to the tools. They must be able to oper op erate ate the AUTO AU TOSAR SAR inter interfa faces, ces, yet they must remain remain open to inte integra gration tion of third-party third-par ty compo components. nents. Above all, config configu ura ration tion tools should be able to master mas ter this chal lenge and al so so support support the user user in val ida dation tion of the system sys tem config configu uration. ra tion. The tool world servic serv icing ing AUTO AUTOSAR SAR can be subdi subdivid vided ed into into three cat ego gories: ries: Design, Design, config configu ura ration tion and test/simu test/sim ula lation. tion. Above all, suit able test instru instruments ments are an essen es sential tial compo component nent for success successful ful dedevel opment. opment. An ECU oper op erates ates as a part of a whole. Checking Check ing for and assur as suring ing consist consist ency ency in the overall over all system sys tem requires requires a high-perform high-per form-ance simu simula lation tion tool. Vector Vector Infor Informa matik tik GmbH has come to grips with these require re quirements ments and can make a contri con tribu bution tion to the sucsuccess of AUTO AUTOSAR SAR with its compre comprehen hensive sive tool solu solutions tions such as the DaVin Da Vinci ci Tool Suite, MICRO MICROSAR SAR Config Configu ura ration tion Suite and CANoe. CANoe. SupSupport in the context con text of project work and consul consul tation tation comple complement ment the products products of fered. fered.
Summa Sum mary ry When consid considered ered from dif ferent ferent points of view, a stepwise step wise intro introduc duc-tion of the standard stand ard compo components nents defined defined by the AUTO AUTOSAR SAR devel devel opopment part nership nership into into an indi individ vidu ual compa company’s ny’s soft ware ware archi architec tec-ture appears appears to be the correct cor rect path. This approach approach guaran guarantees tees qual ity and consist consist ency. ency. Proper Proper tools support support this process. process. Gradu Gradual mimigration gra tion instead instead of an imme im medi diate ate total total conver conversion sion leads to an overall over all AUTO AU TOSAR SAR solu solution tion in the vehi vehicle cle that mini min imiz mizes es risks. Vector’s Vec tor’s exexpert ise ise and many years of expe ex peri rience ence lend support sup port to this process. proc ess.
Peter Schiek Peter Schieko ofer (Gradu (Grad uate Engi Engineer) neer) has been employed employed at Vector Vec tor since May 2006. He mana manages Vector’s Vector’s Regens Re gensburg burg subsid subsidiiary and is respon responsi sible ble for advanced ad vanced techni technical cal devel devel opment opment of AUTO AUTOSAR SAR solu so lutions. tions. As an active active working working partic par ticiipant on Working Working Packa Packages WP 1.1.2 and WP 20 of the AUTO AUTOSAR SAR Devel Devel opment opment Part nership nership he is direct di rect ly ly involved involved with the new technol technol ogy. Tel. +49-941/20865-101, Fax +49-941/20865-111 +49-941/20865-111,, E-mail: peter.schi pe ter.schiek eko ofer@vec fer@vector-in tor-infor forma matik.de tik.de
Figure Fig ure 3: Vector Vec tor of fers f ers MICRO MICROSAR, SAR, which contains con tains the entire en tire range of AU TO AU TOSAR-BSW SAR-BSW includ including ing RTE.
6/12
6/13
AUTOSAR on its Way to Production To master the growing complexity of software in modern vehicles, automotive OEMs are increasingly developing their electronic systems based on AUTOSAR. The standards created by this development partnership simplify d evelopment processes and make ECU software reusable. Since its introduction in 2004, this innovative and pioneering pi oneering technology has been tested in many evaluation projects and is now enter ing an implementation phase in production ECUs. AUTOSAR standard software covers the current state of technology and is undergoing continual advanced development in new releases. The automo automotive tive industry industry is being confront con front ed ed with new times. Growth in the number num ber of complex complex vehicle vehicle functions functions is making making the devel opment opment of automo automotive tive electron electronics ics increasing increas ingly ly more extensive extensive and compli complicat cat ed. ed. Custom Customer er wishes, wishes, e.g. for more vari var iants and equipment equip ment varie variety in the vehicle, vehicle, as well as non-function non-func tional al requirerequirements such as diagnos diag nostic tic capabil capabil ity and avail abil ity, are requiring requir ing more intensive inten sive ECU devel opment opment process processes. es. Vehicles, Vehicles, in partic par ticu ular luxu lux ury vehicles, vehicles, may have more than approx. 1,000 soft ware ware funcfunctions, sever several al vehicle vehicle electri electrical cal net works works and more than 70 ECUs. Due to the varie variety of hardware hardware plat forms forms used in this field, ECU soft ware ware dependen dependencies cies on the hardware hard ware and system sys tem config configu ura rations tions being used has become problem prob lemat at ic. ic. Each change to one of these constraints con straints requires reprogram repro gramming ming or at least modi mod ifi fica cation tion of the soft ware. ware. To make the complex complexiity of ECU soft ware ware devel opment opment manage manageaable, the AUTOSAR AUTOSAR devel opment opment part nership nership has defined a practice-test prac tice-test ed soft ware ware architec architecture ture that serves as a founda foun dation tion for devel oping oping reusaable applica reus applications. tions. This open standard stand ard for system sys tem architec architecture ture – creat cre at ed ed by automo automotive tive OEMs, suppli suppliers ers and other other compa companies nies in the global glob al soft ware, ware, semi semicon conduct duct or or and electron electronics ics industries indus tries – lets users avoid propri proprieetary solutions solutions that would result in increasing increas ingly ly high devel opment opment cost and effort. AUTOSAR subdi AUTOSAR subdivides vides the electron elec tronics ics architec architecture ture into a number num ber of layers lay ers and modules. modules. With the simul tane taneous ous def ini nition tion of interfa inter faces, ces, AUTOSAR AUTO SAR creates creates standards standards for easy exchange of soft ware ware compo compo-nents or hardware hardware plat forms. forms. The devel opment opment part nership nership not only provides pro vides speci specifi fica cations tions for the base soft ware ware modules. modules. It also offers a method methodol ol ogy for devel oping oping applica applications tions and distrib dis tribut ut ed ed syssystems. This method meth odol ol ogy begins with a model-based mod el-based description description of the soft ware ware applica applications tions and the distrib dis tribut ut ed ed system, system, and ideal ideal ly ly ends in an automat automat ical ly ly gener generat at ed ed and reproduc reproduciible test. This forfor mal approach simpli simplifies fies the use of a univer uni versal sal tool chain.
is abstract ed ed and subdi subdivid vided ed into sever several al layers layers (Figure (Figure 1). The conconnection nec tion to the actual actu al microcon microcontrol trol ler, ler, i.e. the physi physical founda foundation, tion, is repre represent sent ed ed by the Microcon Micro control trol ler ler Abstraction Abstraction Layer, Layer, which maps the microcon microcontrol trol ler’s ler’s functions functions and periphery. periphery. It defines inter fa faces ces for memo memory, the I/O driver driver and its commu communi nica cation tion connec connections. tions. In this layer, layer, features features that the microcon micro control trol ler ler does not offer may also be emulat emulat ed ed in soft ware. ware. The second sec ond layer layer that lies above this is t he ECU Abstraction Abstraction Layer. Layer. It establish establishes es die ECU-specif ECU-specif ic ic hardware hardware laylayout and provides provides drivers drivers for the periphery periphery external exter nal to the ECU, for example. exam ple. In another anoth er layer, layer, the Servi Services Layer, Layer, vari var ious basic servi services are repre represent sent ed ed such as net work work servi services, memo memory manage management, ment, bus commu communi nica cation tion servi services and the operat oper at ing ing system. system. This layer lay er is already largely largely independ independent ent of the hardware. hardware. The RTE repre represents sents the fourth layer. layer. This is where the actu al sepa separa ration tion of applica application tion and basic soft ware ware (BSW) is made. The RTE handles han dles integra integration tion of the applica application tion soft ware ware and regu regulates the exchange of data between the applica appli cation tion and the BSW. It is only at this layer lay er that reuse of already writ ten ten applica application tion soft ware ware is possi possible, ble, because the defined interfa inter faces ces make it possi possible ble to devel op op the applica application tion soft ware without without special special knowl edge edge of the hardware hard ware to be used at a lat er er time, and the soft ware ware can be used for any other oth er AUTOSARAUTOSARconform con formant ant ECUs. The so-called Virtu Vir tual al Function Functional al Bus (VFB) forms the basis for concon figu fig ura ration tion of the layers. lay ers. All compo components nents of the vehicle’s vehi cle’s electron elec tronics ics commu com muni nicate cate in an abstract ed ed view via this bus. The soft ware ware comcomponents po nents use ports for this, whose interfa inter faces ces can be defined as port interfa inter faces. ces. Connect Connect ors ors connect connect the ports. It is irrel evant to the VFB whether wheth er this is a connec con nection tion within within an ECU or a connec con nection tion via an external exter nal bus. This is not decided decid ed until the final system sys tem layout layout is made and specif specif ic ic functions functions are assigned to a spe cif ic ic ECU.
A full three years aft er er its start, the AUTOSAR AUTO SAR devel opment opment part nernership published published Release 2.1 at the beginning begin ning of 2007. A stable stable level level was reached with this release, and it has been test ed test ed in sever several al val idation da tion pro jects for its practi tical cal util ity. At many business businesses, es, the action item of “AUTOSAR “AUTO SAR eval uation” has been success suc cessful ful ly ly comcomplet ed. ed. Now it is ready to be implement imple ment ed ed in concrete concrete produc production tion ECUs.
AUTOSAR AUTO SAR Architec Architecture ture To real ize ize the objectives objectives of AUTOSAR AUTOSAR – sepa separa ration tion of the applica application tion soft ware ware from basic modules mod ules and functions functions – the vehicle vehi cle electron electronics ics
6/14
Fig ure 1: Figure AU TO AU TOSAR SAR lay er e r model model for ECU software. software.
The soft ware ware compo component nent itself does not require any knowl edge edge of this lat er er distri distribu bution, tion, and it can therefore there fore be devel oped oped independ independ-ent of it. The compo component nent is subdi sub divid vided ed into execu executa table ble units, socalled Runna Runnable ble Entities, Entities, which are execut exe cut ed ed like proce procedures dures when a specif specif ic ic event occurs. Such an event might be the arriv al of a new sensor sen sor val ue ue or a period peri odic ic activa activation, tion, for example. example. The description descrip tion of the electron electronic ic system system formu formulat lat ed ed from the perspec per spective tive of the VFB defines the interfa inter faces ces of the specif spe cif ic ic soft ware ware compo components. nents. As a result, the applica application tion compo components nents can be devel oped oped independ independent ent of the specif specif ic ic ECU. The “counter “counterpart” part” on the ECU is the RTE. It guar an antees tees access to I/Os, memo memory and other other basic servi serv ices. Using the model-based mod el-based description, descrip tion, the RTE is gener gen erat at ed ed ECU-specif ECU-specif ical ly, ly, which means that it can be adapt ed ed to dif ferent ferent requirements requirements while econo econ omiz mizing ing on resources. resources.
Method Meth odol ol ogy Besides defining defining the ECU’s soft ware ware architec architecture, ture, the AUTOSAR AUTOSAR standard stand ard also defines a method methodol ol ogy to help in the devel opment opment of AUTOSAR AUTO SAR systems. systems. Conform Conformance ance to a structured struc tured crea creation process process is recognized recog nized as an important impor tant precon precondi dition tion in creat cre at ing ing error-free soft ware. ware. Deficien Deficiencies cies in the requirements require ments list are detect ed ed early, early, reuse and port ing ing of soft ware ware compo components nents is simpli sim plified, fied, and the overall over all system system is more relia reli able. Nonethe Nonetheless, less, this method meth odol ol ogy also allows certain cer tain freedoms: freedoms: for example, example, users can decide whether wheth er to use a top-down approach or a bot tom-up tom-up devel opment. opment.
The AUTOSAR AUTOSAR Initi Initiaative provides provides univer universal sal support support for the soft ware ware devel opment opment process process by tools. Mature tools are used for structured structured implemen imple menta tation tion of requirements requirements and their consist con sist ent ent manage management; ment; config con figu ura rations tions are system sys temat at ical ly ly creat creat ed, ed, and complex complex dependen dependen-cies are automat auto mat ical ly ly taken taken into account. The first step involves formal for mal description descrip tion of the three prima primary ry conconstit uents: Soft ware ware (SW Compo Components), nents), ECUs (ECU Resources) Resour ces) and System Sys tem Constraints. Constraints. Suit able editors editors are used to create cre ate a config configu ura ration tion description description of the complete complete system system (Figure (Figure 2). This system sys tem config configu ura ration tion serves as the basis for the ECU Config Con figu ura rations tions that the user creates cre ates for the individ indi vidu ual basic soft ware ware modules modules with the help of config con figu ura ration tion tools. At the end of the process, process, mul tiple tiple gener generaators supply supply the ECU-specif ECU-spe cif ic ic implemen implementa tation tion of the RTE and basic soft ware. ware. All design and config con figu ura ration tion data produced produced in the devel opment opment process proc ess are described in a uni form format. format. AUTOSAR AUTOSAR has defined an XML-based format format for this purpose. pur pose. On the one hand, it guaran guar antees tees univer uni versal sal ity of the devel opment opment process, process, and on the other oth er it also simpli sim plifies fies seamless seamless integra inte gration tion of neces necessa sary ry and auxil auxil iary iary tools.
Migration Migra tion The soft ware ware architec architecture ture of an AUTOSAR AUTOSAR ECU is not mono mon olith lithic, ic, rather rath er it consists consists of a number num ber of standard standard modules modules with well-dewell-defined interfa inter faces. ces. This enables enables implemen implementa tation tion of migration migration solusolutions that offer a risk-free transi tran sition tion to AUTOSAR. AUTOSAR. Such a migration migration solution solu tion must typi typical ly ly be worked out project-specif project-specif ical ly. ly. In pracprac-
Figure Fig ure 2: Structur al Structur al descripdescription of the software software compo com ponents. nents. The crea cre ation process process for AUTO SAR-conform AUTOSAR-con formant ant software soft ware compo components nents is organized organized in clear ly prescribed prescribed devel opment op ment steps.
6/15
tice, this may involve a mixed config con figu ura ration tion of standard standard AUTOSAR AUTOSAR modules mod ules and propri pro prieetary soft ware. ware. To work out a migration migration solution, solution, one begins by compar comparing ing the exist ing ing custom custom soft ware ware and the AUTOSAR AUTO SAR architec architecture. ture. Aft er er an anal y ysis sis of overlap overlapping ping function functional al ities and integra inte gration tion options, a decision deci sion is made regarding regard ing which modules mod ules will remain and which ones can be replaced by standard stand ard soft ware. ware. So, it is advisa advisable, for example, example, to introduce introduce a sepa separa ration tion layer layer bebetween the applica application tion and basic soft ware. ware. A potential potential scenar scenario io in this case is to prepare pre pare the applica applications tions as AUTOSAR AUTOSAR soft ware ware comcomponents po nents already in early ear ly migration migration phase, and to integrate inte grate them via an RTE. Beneath the RTE, a spe cif ic ic adapta adaptation tion layer layer is used for interfac inter facing ing to the exist ing ing basic soft ware ware (Figure (Figure 3). If parts of the exist ing ing basic soft ware ware are to be replaced by AUTOSAR AUTOSAR basic soft ware, ware, the emphasis empha sis should lie on the use of a uniform uni form config con figu ura ration tion tool for both worlds. Vector Vec tor offers suit able tools
Fig ure 3: Figure Ear ly ly intro introduc duction tion of a uniform uniform inter inter face face and RTE simpli sim plifies fies migra migration. tion.
here, which are flexi flex ible enough to be used to config con figure ure propri proprieetary basic soft ware ware too. Non-AUTOSAR Non-AUTOSAR modules modules can now be replaced by AUTOSAR AUTO SAR modules modules in succes successive sive steps, without without put ting ting the overall over all architec archi tecture ture at risk or requiring requir ing reprogram reprogramming ming to other other modules. modules.
Outlook Out look The current current AUTOSAR AUTOSAR Release 3.0 repre represents sents another another step taken taken to enhance the qual ity of the AUTOSAR AUTOSAR standard. standard. The contin continu uing involvement ve ment of partic particiipat ing ing compa companies nies clearly clearly demon demonstrates strates commit ment to the goals of the AUTO SAR devel opment opment part nership. nership. Ideas are current current ly ly being introduced introduced that should become a real ity in the framework frame work of the future Ver Version sion 4.0 of the AUTOSAR AUTOSAR standard. standard. New ideas relat ed ed to AUTOSAR AUTOSAR are also being gener generat at ed ed by tool supsuppliers. pli ers. Current Current devel opments opments at Vector Vector are aimed at making mak ing AUTOSAR AUTOSARbased ECU devel opment opment as conve convenient nient and and eff icient as possi possible. ble. One example exam ple is a PC-based test tool for AUTO SAR applica application tion compo compo-nents, which serves as an emula emulator tor for the AUTOSAR AUTO SAR ECU environ environ-ment on the level level of the VFB. This makes it easy to test the impleimple menta men tation tion code of the AUTOSAR AUTO SAR soft ware ware compo components nents on a devel opopment PC. Widely Widely used standard standard tools such as Vector’s Vector’s CANoe may be used for test execu execution, tion, visu visual iza zation tion during dur ing or aft er er test ing, ing, and gener gen eraation of test reports. Vector Vec tor supports supports all phases phases of the ECU devel opment opment process process with its full set of AUTOSAR AUTOSAR basic soft ware ware and a univer universal sal tool chain of design and devel opment opment tools (Figure (Figure 4). The avail able Vector Vector solution solution has been test ed ed in practice practice through its use in eval uation pro jects, pro jects, and it is produc production-ma tion-mature ture for AUTOSAR AUTOSAR Release 2.0 or 2.1 (3.0 too start ing ing in the 2nd quarter quar ter of 2008).
Summa Sum mary ry AUTOSAR is becoming AUTOSAR becoming a real ity. Vari Var ious OEMs have concrete concrete plans for implement implement ing ing AUTOSAR AUTOSAR in upcoming upcoming vehicle vehicle produc production tion proprograms. Vector Vector offers a compre comprehen hensive sive product product lineup lineup for this, as well as basic soft ware ware and tools relat ed ed to AUTOSAR. AUTOSAR. Not only does this enable ena ble the devel opment opment of pure AUTOSAR AUTOSAR systems; systems; it can also support sup port a stepwise stepwise migration migration toward AUTOSAR. AUTOSAR. Matthias Wernicke (Graduate engineer) is responsible for product management of the DaVinci Tool Suite and is also actively engaged in AUTOSAR standardization work.
Figure Fig ure 4: The Vector AUTOSAR solution: From system description to standardized ECU software.
6/16
6/17
AUTOSAR AU TOSAR:: New Paths to ECU Software Sof tware – Part Par t 1 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. Each OEM has its own functional requirements for the ECUs in its vehicles, especially when it comes to communication and diagnos-
requirements of different OEMs. This eliminates manual modification of the software and facilitates its reuse. Defined interfaces
tics. These requirements are implemented in OEM-specific sof tware. 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
make it possible to replace OEM-specific software components (e.g. for diagnostics) with just minimal effort.
adapted to the OEM-specific requirements, this modification effort is still work intensive and prone to errors. Figure 1 shows how
The AUTOSAR reference architecture is described in the document
unmodified functional software is adapted to different vehicle projects without AUTOSAR.
AUTOSAR Layered Software Architecture [1]. In this document, the ECU software is organized into the three parts shown in Figure 2:
One goal of AUTOSAR is to minimize these adaptation efforts in software integration. Therefore, AUTOSAR focuses on consistent
> The functional software consists of software components (SWCs). The SWCs are created, independent of the ECUs, based on a
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 significantly, they can be substantially configured to cover the
6/18
AUTOSAR reference architecture
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.
> 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 ser vices.
majority contains functions that were already usually present in previous software architectures, but now they are more precisely
The RTE is the layer between the functional software and the basic software modules. It provides all interfaces the SWCs need to
distinguished from one another. Consistent partitioning of functions 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
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-
software. In most cases, this standardization covers the interfaces as well as functions of the BSW modules. Representing an exception here are the BSW modules for diagnostics. Since diagnostic processes are very dependent on manufacturing and after-sales
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 configuration of these services in greater detail. The AUTOSAR Release 3.0 defines approx. 50 different configu-
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 integrate 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-
rable basic software modules; some of them are very complex. The
rator Pro from Vector.
Figure 1: Creating ECU software without AUTOSAR
6/19
AUTOSAR Methodology
> Activity: “ECU design and configuration” Starting with the “ECU Extract of System Descrip-
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 standardizes data exchange between development partners with a set
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
of XML files:
an ECU. Another prerequisite for ECU configuration is the existence of the “BSW Module Description” files, which contain the definition of the data struc-
> Activity: “Component implementation” The TIER1 or OEM defines the SWCs. For this purpose, it creates an XML file for each SWC, the socalled “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 communication networks and distribute SWCs to the available ECUs. The result is saved in the “System Description”.
tures and all configurable parameters of a BSW module. These files are implementation-specific and – along with the generators and the st atic 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 Description”and 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
For each ECU, the OEM reduces the “Sys tem Description” to an “ECU Extract of System
Description” is the foundation for ECU-specific generation of the RTE and the BSW modules by
Description” which the OEM can pass to the supplier (TIER1) of the relevant ECU. This file repla-
the relevant generators.
ces the DBC, FIBEX or LDF files previously used to configure the BSW modules.
Fig ure 2: Figure AUTOSAR architecture of an ECU
6/20
AUTOSAR: NEW PATHS TO ECU SOFT WARE
The AUTOSAR method is flexible and suitable for satisfying the practical requirements of different projects or different OEMs. For
For configuration of the BSW modules, the TIER1 needs the support of a universal tool with user-friendly functions. That is why
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 f rom Vector – how the “ECU design and configuration” activity can be implemented with tool
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
support.
manufacturers > Configuration of software modules you have created yoursel
Configuring and integrating all software components MICROSAR BSW modules are configured by using a graphical user 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 primary work of integrating the ECU software from manual code adaptation 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 advisable to procure either the entire BSW package, or at least defined BSW clusters, from a single source. The advantage is that the software 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-
interface that shows the complex interrelationships of the conf iguration 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 modules from third-party producers. As an alternative, the TIER1 supplier may choose to develop a user-friendly and integrated configuration 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 conf igure its own BSW modules,
ules. This increases integration effort, however, since both functional integration and integration in the configuration tools need
e.g. complex device drivers. Both DaVinci Configurator Pro and DaVinci Developer contain validation 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
to be performed. Essentially,, all MICROSAR BSW modules are tested within systemEssentially 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.
Description” is generated consistently. This consistency is essential for subsequent generation of the RTE and the BSW modules.
Fig ure 3: Figure Tool-supported integration of SWCs and configuration of RTE and BSW modules per AUTOSAR methodology
6/21
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 (0)711/80670-2211,, Fax +49 +4 9 (0)711/80670-111, (0)711/80670-111, E-mail:
[email protected] [email protected] m
In the second part of this article, you will learn – based on examples of selected use cases – how the exchange files and configuration 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
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 Informatik in Stuttgart, developing methods and tools for the design of distr ibuted electronic functions in motor vehicles. Today he is responsible for product management of DaVinci AUTOSAR tools.
All Figures: Vector Informatik GmbH
Literature: [1] Layered Software Architecture: http://www.autosar.org/download/specs_aktuell/AUTOSAR_LayeredSoftwareArchitecture.pdf [2] AUTOSAR Methodology: http://www.autosar.org/download/specs_aktuell/AUTOSAR_Methodology. pdf
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-111 E-mail: justus.maier@vector
[email protected] .com
Links: Homepage Vector: www.vector www.vector.com .com Product information about AUTOSAR: www.autosar www.autosar-solutions.com -solutions.com
>> Your >> Your Contact: Germany and all countries, not named below Vector Informatik GmbH, Stuttgart, Germany, www.vector.com
France, Belgium, Luxembourg Vector France, Paris, France, www.vector-france.com
Sweden, Denmark, Norway, Finland, Iceland VecScan AB, Göteborg, Sweden, www.vector-scandinavia.com www.vector-scandinavia.com
Great Britain Vector GB Ltd., Birmingham, United Kingdom, www.vector-gb.co.uk
USA, Canada, Mexico Vector CANtech, Inc., Detroit, USA, www.vector-cantech.com www.vector-cantech.com
Japan Vector Japan Co., Ltd., Tokyo, Japan, www.vector-japan.co.jp www.vector-japan.co.jp
Korea Vector Korea IT Inc., Seoul, Republic of Korea, www.vector.kr www.vector.kr
India Vector Informatik India Pr v. Ltd., Pune, India, www.vector www.vector.in .in
E-Mail Contact
[email protected]
6/22
6/23
AUTOSAR AU TOSAR:: New Paths to ECU Software Sof tware – Part Par t 2 AUTOSAR in Practice – Life Cycle of AUTOSAR ECU Software The first part par t 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. 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-
New development of software components (SWCs)
lowing extensive description files mentioned in the first part of the article: > The “ECU Extract of System Description” contains the ECUspecific 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-
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 description (runnable entities) or interfaces to the standard services of the BSW modules. The Tier1 developer can add this missing specification 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 manually based on a generated code template or with the help of model-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.
ration whenever a change is made. In performing this task, it is helpful to use configuration tools that support iterative work pro-
If SWCs are already available at the Tier1, they can also be integrated in the ECU. This involves importing the relevant “SWC
cesses during an ECU development project. Typical scenarios and change cases are described as well as having work steps explained
Description” and linking the SWC to the other SWCs of the ECU (Step D2).
Depending on the OEM, the “ECU Extract of System Description”
based on the Vector tools DaVinci Developer and DaVinci Configurator Pro.
Figure 4: Development of functional software consisting of multiple SWCs
6/24
In a separate integration step, data elements of the SWC interfaces are assigned to bus signals (data mapping) – provided that
Component. This SWC can also be created by a “top-down” or “bottom-up” approach.
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
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.
receives a new version, the SWCs it contains might also be modified. 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 interfaces 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 represented by special SWCs, the so-called ser vice components. These service components are created and integrated with the SWCs by what is referred to as Service Mapping, which can be performed automatically 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
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 software 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, inconsistencies are reported so that the Tier1 can correct the “SWC Description” or RTE configuration.
Incorporating changed communication data from the OEM
those services that are not typically specified by the OEM in detail. Examples are services of the NVM (Non-Volatile Memory Manager)
A typical change scenario is updating the communication data of an ECU, e.g. because the distribution of signals to messages has
or the ECUM (ECU Manager). In the “bottom-up” method, the service is first configured in the
changed. Such a change is only relevant to those BSW modules related to communication and does not require any changes to 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-
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-
sented by a special SWC – the I/O Hardware Abstraction
erated, and the contents of the old “ECU Configuration Description”
Figure 5: Work steps in configuring the RTE
6/25
are converted to the new “ECU Configuration Description” (Step C1-2). All parameter values unaffected by the change are automati-
processors or own BSW modules. This is enabled by the DaVinci Configurator Kit, which is used to create the Tier1 BSWMD files and
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.
module interface files. They contain definitions of specific configuration interfaces, validation rules or generators for the BSW modules (Steps C5 and C6).
As a supplement to the AUTOSAR standard, Vector has implemented an “Update” function and validation in DaVinci Configurator Pro. If the OEM does not provide an AUTOSAR-conformant ECU Extract of the System Description, the Tier1 can instead use the
Replacing OEM-specific diagnostics
familiar network description formats (DBC, LDF or FIBEX) as inputs to the DaVinci tools.
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 modules are removed and the new MCAL modules are added to the pro ject by selecting the new BSWMD files. The new platform-dependent parameter values that were added are checked in DaVinci Configurator Pro and reconfigured by the Tier1 as necessary (Step C3 for each changed MCAL module). Consistency of the “ECU Configu-
OEM-specific. This affects the DCM and DEM (Diagnostic Event Manager) 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 automatically 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 modif ied 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).
ration Description” is restored by final validation (Step C4). Especially useful to the Tier1 is the ability to extend the tool
The Tier1 can now use DaVinci Developer to generate the service mapping for all diagnostic services of the new OEM. Validation of
environment, e.g. to support the MCAL modules of future
the SWCs ensures that no service is forgotten in the change
Switching over to a different processor or processor type
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
Figure 6: Work steps in configuring the basic software
6/26
AUTOSAR: NEW PATHS TO ECU SOFT WARE
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 representation 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 prevents 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 diagnosticspecific software parts of an ECU
6/27
Networking Heavy-Duty Vehicles Based on SAE 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 J1939 networks are based on the CAN bus (high-speed CAN per ISO1 ISO11898); 1898); 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. The J1939 protocol – founded in the USA and defined by the Soci-
scheme. Despite all of its standardization aspects, J1939 gives
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
OEMs sufficient freedom for customized extension of communication. This is especially important in promoting innovations, because no OEM wants to announce or discuss plans in working committees before their implementation.
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 specific vehicles. In Europe, on the o ther hand, it is the OEMs who fully
7/0
ISO Layers Model decouples the Application from Transmission Physics
define the design of the entire vehicle, including the components and their configuration.
From the perspective of the ISO/OSI network model, J1939 is essentially based on the Application Layer (Layer 7), Network Layer
Besides using uniformly defined signals and data formats to communicate, it is of course important that receivers know how to
(Layer 3), Data Link Layer (Layer 2) and Physical Layer (Layer 1) (Figure 1). This lets developers work with signals without needing
interpret the information. Ideally, it should be possible to interconnect individual J1939 components based on a plug-and-play
to be concerned about communication details on the Application Level, such as details of the transport protocols. J1939
Figure 1: The J1939 protocol essentially covers 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 working on the application level.
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.
(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 priority field; although these bits do not replace the implicit priority established by the CAN protocol, they make it possible to organize
CAN Message Format in J1939
the Parameter Groups into up to eight J1939-specific priority levels. These priorities are used to adjust the priority to momentary
Although J1939 utilizes normal 29-bit CAN messages with up to 8
application requirements at the time the Parameter Group is transmitted – or during an optional ECU configuration phase. This makes
bytes of data, here the CAN identifier quasi defines the mask of a uniform J1939 scheme (Figure 2). This is necessary to assure plugand-play properties. The CAN identifier – besides identifying the useful data with the help of the Parameter Group Number
it possible to fine-tune communication to the application without the SAE protocol permanently setting the priority when the Parameter Group is defined.
Figure 2: The J1939 message format – which is based on normal 29-bit CAN messages – requires some supplementation to achieve plug-and-play capability.. The CAN identifier quasi capability defines the mask of a uniform J1939 scheme.
7/1
The Name says it all: J1939 Device Names
address; they are used for device configuration or ECU commands, for example. Broadcast messages (1:n), on the other hand, are
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 functionality. The device name is subdivided into different elements,
simultaneously addressed to all bus nodes, which is practical when it comes to sending out measured values, error handling and diagnostic purposes.
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-
Flexible Network Topology
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 ser ial number, number, the complete name over all f ields is unique worldwide, and there are no o verlaps. 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, transmission, retarder, brakes, etc., while the range from 128 to 247 is
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 physical transmission layer, 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 requirements 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.
reserved for agricultural, marine, construction equipment, etc. Service tools, OBD scanners, etc. occupy addresses from 248 to
Timing Requirements in ECU Design
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
In designing J1939 ECUs, care should be taken to ensure that no messages are lost due to hardware or design limitations. At a
address for addressing broadcast messages.
baudrate of 250 Kbps, transmission of one bit takes 4 microseconds. With 8 data bytes, a typical message length of about 128 bits is obtained, yielding a transmission time of about 500 microseconds per CAN message. The shortest message length, however, is
Types of Communication: Point-to-Point or Broadcast The J1939 protocol supports two communication types: point-topoint transmissions (1:1) are directed to precisely one target
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-
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.
7/2
NETWORKING HEAVY-DUTY VEHICLES BASED ON SAE J1939
this leads to a high interrupt load due to the CAN controller’s often limited CAN identifier filtering capabilities. Filtering also usually
A J1939 extension is available for the widely used CANoe development and test tool; it spares heavy-duty vehicle developers from
needs to be implemented in software.
Testing and Diagnostics of J1939 Components and Systems
needing to train in the details of the J1939 protocol. The package from Vector extends basic software functionality to cover all necessary protocol-specific features. When CANoe.J1939 is used consistently, the models and databases created in the design phase not
In view of the rising number of J1939 ECUs and the fact that software solutions in heavy-duty vehicles are becoming increasingly complex, a systematic strategy for testing and diagnostics also
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-
continues to gain in importance in the J1939 field. Tests are indispensable in all development phases, from functional tests to integration 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 possible 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 developers 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-
oped. The tests are further refined during development and are used in verification of the total system.
ciently solve the most challenging tasks in networking and communication in the heavy-duty vehicle field [1]. Besides development,
figuration. The J1939-specific extensions in the Test Service Libraries allow the system react to Parameter Groups (PG) instead
testing and analysis tools, embedded software components tailored to the special requirements of J1939-based applications are
of typical CAN identifiers. They also offer test patterns for J1939 protocol functionality and checks (background monitoring) for
available, and customized project work and training events round out Vector’s products and services.
protocol violations. For example, it is possible to test whether the ECU is able to send all Parameter Groups at the configured cycle
Extensive J1939 Test Test Library Librar y 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 challenges 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 application-specific test modules (function libraries) in CAPL and then generate test control that is individually adapted to the ECU con-
Figure 4: Tests conducted with the help of simulations during development make it possible to detect and correct errors early on in all development phases. The CANoe Test Feature Set offers extensive testing and analysis capabilities.
7/3
time under high bus load. Furthermore, it is possible to send faulty transmissions via the BAM (Broadcast Announce Message) and
and are implemented step-by-step on the final target hardware platform. CANoe.J1939 can also integrate Matlab/Simulink models
CMDT (Connection Mode Data Transfer) transport protocols for test purposes. To create the test modules – besides the J1939 Test Module Manager and the convenient Test Automation Editor – the Option DiVa
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
is useful. DiVa creates a connection between CANoe and the diagnostic specification tool CANdelaStudio, so that specifications created there can be ideally used in further ECU-specific diagnostic tests.
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
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.
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 realtime requirements of the simulation platform, a special real-time version is available with CANoe RT.
Integrating Matlab/Simulink Models in J1939 Network Simulations
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 OEMmanaged database containing all elementary information related to ECU communication. Depending on requirements, this informa-
Generally, various function models are created for mechanical components such as transmission, powertrain or even the entire vehicle
tion might be distributed to other working partners, producing flexible distribution of tasks between the OEM, network specialists
during the different heavy-duty vehicle development phases. ECU architectures are initially saved in virtual CANoe function models
from Vector and suppliers (Figure 6). The latter can use the GENy configuration tool for specific settings and parameterizations. The
Figure 5: Not only is CANoe able to simulate functional models models of ECUs during the development process and integrate models created with Matlab/Simulink in the scenarios; at the same time it also serves as a convenient conven ient user-inte user-interface. rface. (Source: Renault Trucks)
7/4
NETWORKING HEAVY-DUTY VEHICLES BASED ON SAE J1939
results are reduced cost and timing for implementation and testing, 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 eff iciency.
Internet links: [1] J1939 solutions from Vector Vector – www.j1939-solutions.com [2] Download of presentations from J1939 J1939 User Day – www.vector-worldwid www.vec tor-worldwide.com/ud e.com/ud [most of them are German]
Peter Fellmeth studied at the University of Applied Sciences in Esslingen, Germany, majoring in Computer Engineering and specializing in Automation Technology. Technolo gy. 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 Technology at t he University 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 developments and enables optimal work distribution.
7/5
CAN and J1 J1939 939 under under Extreme Extreme Duty Duty Condi Conditions tions Vehi Ve hicle cle electron electronics ics guaran guarantees tees function functional al ity in cold, ice and snow Any one one who has par tici ticipat pat-ed in winter winter sports at one time or anoth another er is famil famil iar iar with them: The slope groomers groom ers that tireless tirelessly ly prepare pre pare the ski slopes and transport trans port goods to mounmountain stations stations or in jured per sons safely safely down to the val ley. They not only only embody embody a special spe cial species species of all-ter rain track vehi vehicle, cle, they al so so deliv de liver er the expe experi rience ence of true high per formance. formance. Vehi Vehicle cle electron electronics ics play a deci decisive sive role in the incred incrediible capa capabil bil ities of these machines. machines. Without Without electron electronics ics neither neither function functional al ity nor safety safety nor any other other signif signif icant inno inno va vations tions would be conceiv conceiva able. This techni technical cal ar ticle ticle of fers fers insights insights into into the vehi vehicle cle technol technol ogy, de vel opment opment process process and de vel opopment tools of the latest latest gener gener ation of Pisten PistenBul Bul ly ly vehi vehicles cles from the Kässboh Käss bohrer rer Compa Company. ny. In contrast contrast to conven convention tional al off-road vehi vehicles, cles, the techni technical cal chal lenge lenge for the Pisten Pis tenBul Bul ly ly is to master mas ter the numer numerous ous exextreme sit uations encoun encountered tered in cold, snow and night time time oper op eraation. The machine, machine, capa capable ble of moving moving in any direc direction tion on inclines inclines up to 45°, covers covers an area area of 96,000 m2 /h with its mul tiflex tiflex till er. er. This technol technol ogy is standard standard equipment equipment for duties du ties up to 4,000 m above mean sea lev el and extreme extreme out side temper temperaatures; the el eva vation tion capa capabil bil ity of the polar polar verversion even reaches reaches up to 6,000 m.
in the cockpit cock pit display display al so so provides provides opti optimal mal visi visibil ity when driving driv ing in reverse. reverse. To support support grooming grooming on steep inclines inclines the vehi ve hicles cles can be option op tional al ly ly equipped with electro-hy elec tro-hydrau draulic lic cable ca ble drums that carry carry 1,000 m of cable. ca ble. A special special feature feature is free rota rotation tion of the drum, al lowing lowing the vehi vehicle cle to turn 360° as of ten ten as desired. desired. Besides Besides models models for use on mountains mountains and snow, there are al so so Pisten PistenBul Bul ly ly versions versions without without a loadload -
Greatest Great est Safety Safety under under Extreme Extreme Condi Conditions tions Slope grooming grooming is of ten ten scheduled scheduled for evening evening and night time hours, while there are no regu regular winter winter sports activ activiities. If vehi vehicle cle drivers drivers are under underway way alone in a snowstorm snowstorm or fog at high el eva vations tions or in Arctic Arc tic regions, regions, the reli reliaabil ity and avail abil ity of the vehi vehicles cles can be life preserv preserving ing factors. factors. Safety Safe ty as well as comfort comfort able and fatigue-free fatigue-free steering steer ing and controls con trols were therefore therefore key aspects aspects of the vehi vehicle cle concept. concept. Intel In tel ligent ligent auto automat mat ic ic functions functions support support the driver driver and rereduce the number number of control control inter interven ventions tions needed, needed, so that the driver driver can concen con centrate trate on what is impor important. tant. Impact Im pact and puncture puncture resist resist ant ant windshield windshield glass protects protects the driver driv er from rock impacts, impacts, and a light ing ing system system with a wide array ar ray of running running lights, searchlights searchlights and working working lights turn night into into day. Auto Automat mat ic ic inte integra gration tion of a rear camera cam era image image
7/6
Figure Fig ure 1: Up to 620 Pisten Pis tenBul Bul lys lys are produced pro duced in Laupheim Laupheim ever every y year
ing plat form, form, versions versions exclu exclusive sively ly used to transport transport person person-nel, exca excavat vat ing ing versions versions and even versions versions that can swim. Kässboh Käss bohrer rer produ produces ces about 600 to 620 units per year, and the cost per vehi vehicle cle lies between be tween 80,000 and 340,000 euros. eu ros.
Power for Driving, Power Driving, For Ski Lifts and Emer gency gency Electri Elec trical cal Gener Gener ators The vehi vehicles cles are driven driven by engines engines from Mercedes-Benz Mercedes-Benz with power pow er rat ings ings between between 90 HP and 460 HP. The lat est est Pisten Pisten-Bul ly ly 600 has a standard standard 12.8 Liter Liter engine engine deliv deliver ering ing 295 kW (400 HP) and torques tor ques of up to 1,900 Nm. Two in de depend pendent ent hydro hy drostat stat ic ic drive circuits cir cuits without without sepa separate clutches clutches are reresponsi spon sible ble for tractive tractive power power to the right and left sides. The engine en gine control control ler ler deliv delivers ers the required required engine engine torque when
start ing ing up from a stop and prevents pre vents adverse adverse events such as stall ing. ing. Simul Simul tane taneous ously, ly, load limit lim it control control of fers fers protec protection tion against overload overloading ing and over revving rev ving of the diesel diesel engine. engine. A single single gas pedal pedal is used to accel accel erate erate and decel decel erate erate (brak(braking), i.e. there is no working work ing brake, only only a parking parking brake. Changes Chan ges in driving driving direc direction tion are achieved by dif feren ferential tial track speeds. Each drive has infi infinite nitely ly vari var iable out put put speed ad just ment ment and its direc direction tion of rota rotation tion can be reversed. reversed. As a result, re sult, the ful ly ly electron electronic ic steering steer ing can support support turning turning in place, pre-selec pre-selection tion of driving driving direc direction tion and speed reduc re duc-tion. The “steering “steer ing aggres aggressive siveness” ness” varies varies with driving driving speed; the driver driver can ad just it to his or hers specif specif ic ic needs. This means that the driving driv ing speed can be changed by gas
Figure Fig ure 2: Over view of CAN networks net works in the cur rent rent Pisten PistenBul Bul ly ly
7/7
pedal or load limit pedal lim it control control without without af fect fect ing ing the turning turning raradius. di us. Wheel sensors sensors ena enable straight-line and uniform uni form curve control con trol or asymmet asymmet rical ri cal steering steer ing charac character teris istics tics for special special appli ap plica cations. tions.
Nothing Noth ing runs without without vehi vehicle cle electron electronics ics Electronics Electron ics is or at least was of ten of ten consid considered ered a neces necessa sary ry evil by conven convention tional al machine machine building building compa companies. nies. The KässKässbohrer boh rer Compa Company, ny, whose ori or igins are in the steel building build ing inindustry, dus try, has come full circle cir cle in its perspec per spective tive here. Without Without electron elec tronics ics any meaning meaningful ful inter interplay play between between complex complex vehi vehi-cle compo components nents would be incon inconceiv ceivaable. Vehi Vehicle cle electron electronics ics is ever ever present, from steering, steer ing, control control of the engine en gine and hyhydraulic drau lic system, sys tem, conve convenien niences ces of vehi vehicle cle navi naviga gation tion and the control con trol of imple implements, ments, to functions functions for oper operaation tional al data data acacquisi qui sition, tion, tel emat emat ics ics and GPS. Consist Con sist ent ent and thorough thorough net working working of the vehi vehicle cle by CAN (Control (Con trol ler ler Area Area Net work) work) was a prereq prerequi uisite site for achieving achieving a decen de central tral ized ized control control structure. structure. This made it possi pos sible ble to rarational tion al ly ly combine combine electron electronic ic and mechan me chaniical compo components nents to make one control control module. module. In compar compariison to earli earlier er Pisten Pis ten-Bul ly ly gener generaations, decen decentral tral iza zation tion has ena enabled signif signif icant reduc re ductions tions in wiring wir ing costs. Nearly Nearly all commu com muni nica cation tion is rout ed over the two prima pri mary ry buses buses CAN1 and CAN2 (of a total to tal of five CAN bus lines). While CAN3 is used for ex ter ternal nal commu commu-nica ni cations tions in fleet manage management, ment, the CAN4 and CAN5 systems sys tems
are reserved reserved for future future functions functions not current cur rent ly ly needed, needed, and they are techni technical cal ly ly ready to imple im plement ment them. Addi Addition tional al ly, ly, CAN is util ized ized for soft ware ware updates, updates, param parameeter config configu ura ra-tion and in measure meas urement ment systems. systems. Since all functions func tions can current cur rent ly ly be imple implement ment ed ed with CAN, the use of newer newer comcommuni mu nica cation tion systems systems such as FlexRay, Flex Ray, LIN or MOST is not curcur rent ly ly under under discus discussion. sion. The electri electrical cal system system is set up to be ful ly ly modu modular and is uniform uniform across all vehi vehicle cle vari var iants. Since the basic basic wiring wir ing al ready ready consid considers ers all current cur rent and future future opoptions, it is easy to accom accomplish plish expan expansions sions and retrof retrof its its by means of adapt er er wire harness harnesses. es.
Lots of power power electron electronics, ics, just a few fuses fus es and no relays relays The Pisten Pis tenBul Bul ly ly univer universal sal PSX control con trol module module is respon responsi sible ble for central central control control of all functions functions such as perform per formance ance and power pow er manage management, ment, engine engine control, control, hydrau hydraulics lics of the drive and till ing ing pumps, oil flow dis tri tribu bution tion of the working working hyhydraulics, drau lics, front and rear, as well as moni monitor toring ing of all sensors sen sors and actu actuaators. It is supple supplement ment ed ed by the “central “central electron electron-ics” unit, which besides besides of fering fer ing numer numerous ous diag diagnos nosti tical cal ly ly cacapable pa ble and short-circuit short-circuit protect protect ed ed inputs/out inputs/out puts, puts, al so so houshouses other other function functional al ity such as central central locking, locking, RF remote remote control, con trol, light ing ing control control and volt age age convert convert ers ers for 12 V. The full load capa capable ble unit supplies supplies a summed contin continu uous current current of 640 A at 24 V and thereby there by achieves a switching switching capac capaciity of up to 15 kW. The “Central “Central electron electronics” ics” unit has connec connections tions to all five CAN buses. bus es. In total total there is need for just eight “ac“ac tual” tu al” fuses; fuses; every everything thing else has been imple im plement ment ed ed to be short-circuit short-cir cuit protect protect ed ed and “self-heal ing” ing” without without relays. relays.
Maneu Ma neu ver ing ing is easy and intu intuiitive Connect ed Connect ed to the inter in ternal nal vehi vehicle cle bus (CAN1) are the concon trols and display display el ements of the cockpit. cockpit. In addi addition tion to the ergo er gonom nomic ic semi-cir semi-circu cular lar steering steer ing wheel, al so so includes includes a mul tifunc ti function tion display display with touchscreen, touchscreen, round CAN instru in struments, ments, a Termi Terminal nal Control Control Center Center (TCC) inte integrat grat ed ed in the arm rest and a joystick joy stick with program programma mable ble function function but tons. tons. Fig ure 3: Controls Con trols and display display compo components nents in the Pisten Pis tenBul Bul ly ly cockpit cockpit
7/8
The mul tifunc tifunction tion display display gives momen momentary tary infor informa mation tion at a glance on the most impor important tant oper operat at ing ing states and on drivdriv ing speed, cable cable drum tension, ten sion, engine engine data, data, etc. It of fers fers inin-
CAN AND J1939 UNDER UN DER EXTREME EX TREME DUTY DU TY CONDI CON DITIONS TIONS
Fig ure 4: Figure CANoe CA Noe as joy stick stick simu sim ula lator tor for testing test ing hy draulic draulic valves
Fig ure 5: Figure CANoe CA Noe in flash mode
7/9
tuitive control, tui control, on the touchscreen touch screen or via the TCC. The oper op er-at ing ing panel panel mount ed ed to the right of the driver driv er with its film keypad key pad lets the user us er select select numer numerous ous Pisten Pistenbul bul ly ly functions functions direct di rect ly. ly. A joystick joy stick is used to control con trol the vari var ious movements movements of the snow blade and of the rear imple im plement ment carri carrier er as well as used to set the till ing ing pressure, pressure, cable cable drum tension, tension, etc. The joystick joystick is an in-house devel de vel opment, opment, since none of the commer com mercial cial ly ly avail able models models could sat isfy isfy the expec expecta tations tions of Pisten Pistenbul bul ly ly devel devel opers. opers.
CAN controls controls hy draulic draulic module module CAN2 serves as a sensor-ac sensor-actu tuaator bus for engine engine control control and valve control control and an inter interface face for sensors. sensors. The hydrau hydraulic lic valves are driven driven entire entirely ly via CAN, i.e. without with out supple supplemen mental tal anaalog or digi an dig ital I/O signals. signals. On the part of the sensor/ac sen sor/actu tu-ator bus, so-called mul ti-modules ti-modules provide provide input input channels, channels, digiital out puts, dig puts, PWM out puts puts and bridge out puts puts that are didiagnos ag nosti tical cal ly ly capa capable, ble, short-circuit short-circuit protect protect ed ed and self-heal ing. The sensors sensors connect connect ed ed here are all equipped with 4 to
20 mA current cur rent inter interfa faces ces to auto automat mat ical ly ly compen compensate sate for contact con tact resist resist ances ances when electri electrical cal connec connections tions corrode. corrode. While Kässboh Kässbohrer rer util izes izes its inter internal nal KGF proto protocol col for the CAN1 function functional al bus, the J1939 proto protocol col is used on CAN2 for the drive system. system. The advan advantage tage of standard standardized ized drive manmanagement age ment based on SAE J1939 is that the drive sys tem can be built with compo components nents from out side side suppli suppliers, ers, inde independ pendent ent of the vehi vehicle cle produc producer, er, includ including ing a suit able diag diagnos nostic tic syssystem. On the function functional al side, the propri proprieetary proto protocol col was used inten intention tional al ly ly to prevent prevent unau unauthor thorized ized manip manipu ula lations tions and simul simul tane ta neous ously ly to protect protect know-how. That is why it was al so so decid decided ed not to use the CCP (CAN Cal ibra bration tion Proto Protocol) col) standard stand ard for the ECU appli applica cation. tion. The CAN bus systems sys tems can be param parameeter terized ized and diag diagnosed nosed from a laptop. laptop.
Safe return return to the val ley ley even if the bus fails It is inter interest est ing ing that X-by-wire systems sys tems have al ready ready been used in Pisten Pis tenBul Bul ly ly produc production tion vehi vehicles cles since the 1970s, while its imple implemen menta tation tion in gener general al road vehi vehicles cles was not even a
Fig ure 6: Figure CANoe CA Noe in measure measure-ment data data acqui acquisi si-tion dur ing ing vehi vehicle cle trials
7/10
CAN AND J1939 UNDER UN DER EXTREME EX TREME DUTY DU TY CONDI CON DITIONS TIONS
topic of discus topic discussion sion until until decades decades lat er. er. Entire Entirely ly dif ferent ferent legal le gal regu regula lations tions apply apply to the oper op eraation and safety safety of pure off-road vehi vehicles cles not sub ject sub ject to highway high way vehi vehicle cle regis registra tration, tion, since the vehi vehicles cles are used exclu exclusive sively ly on private private land. If there is fail ure ure of the steering steer ing poten potenti tiom omeeter, driving driving direc direc-tion pushbut pushbut tons tons and/or the redun redundant dant gas pedal pedal with a contact con tact less sensor, sensor, driving driving capa capabil bil ity is preserved preserved as long as possi pos sible. ble. The vehi vehicle, cle, weighing weighing in at between be tween 7 and 10 met ric tons and capa ca pable ble of a maxi maximum speed of 23 km/h, can then be driven driven safely safely back to the val ley ley with emergen emergency cy runrunning charac character teris istics tics at a throt tled-down tled-down speed of 5 km/h. Even if both CAN buses bus es fail the Pisten Pis tenBul Bul ly ly remains remains maneu maneu-veraable with control ver control via PWM signals. sig nals. For the electron electronics, ics, besides besides sat isfy isfying ing require requirements ments for harsh temper tem peraature and humid humidiity condi conditions tions and mechan me chaniical stressstresses, other other special special require requirements ments al so so apply, apply, e.g. with regard regard to electro elec tromag magnet net ic ic compat compat ibil ity. This ensures ensures that the high field strengths of radio radio transmit transmit ters ters on mountain mountain peaks will never nev er impair impair vehi vehicle cle functions. functions.
From simu simula lation tion to real real Pisten PistenBul Bul ly ly electron electronics ics Soft ware ware devel devel opment opment and vehi vehicle cle cal ibra bration tion cover covering ing all control con trol modules modules are all performed per formed at the Kässboh Kässbohrer rer Compa Compa-ny. This lets the produc producer er from Laupheim Laupheim adapt flexi flexibly to new oper operat at ing ing sit uations. Since the complex complexiity of the soft ware and the electron electronic ic functions functions is constant con stant ly ly growing, growing,
devel opers devel opers on a project like the Pis ten tenBul Bul ly ly must rely rely on power pow erful ful tools for soft ware ware devel devel opment opment too. Over the course of the devel de vel opment opment process process it is essen essential tial to perform per form design de sign functions, functions, tests and simu simula lations tions of subsys subsystems tems and overall over all systems. systems. This is where CANoe CANoe with the J1939 Option Option from Vector Vector comes into into play. CANoe’s CA Noe’s capa capabil bil ities as a devel de vel opment opment and simu simula lation tion tool range from simu simula lation tion of a single single net work work node, to test ing ing and diag diagnos nostics, tics, to repre represen senta tation tion of complete complete CAN net works. Begin Beginning ning with ini initial studies studies on the purely purely virtu vir tual al model, mod el, the virtu vir tual al nodes can gradu grad ual ly ly be replaced replaced by real real hardware hard ware step-by-step over the further fur ther course of devel devel opopment. In this case, vehi vehicle cle functions functions are exe execut ed ed by a virtu vir tu-al ECU in an OSEK emu em ula lation. tion. Among other other things, this makes it possi possible ble to control control and display display the states of virtu vir tual al sensors sen sors and actu actuaators. It is al so so possi possible ble to gener generate ate asso associ ci-at ed ed control control panels panels auto automat mat ical ly. ly.
Short de vel opment opment times At Kässboh Kässbohrer rer some of the uses us es of CANoe CANoe are to simu sim ulate bus loads, function function as a measure measurement ment tool and param parameeter terize ize ECUs by the propri proprieetary KGF Proto Protocol. col. The devel de vel opers opers use this proto protocol col to gener generate ate diag diagnos nostic tic and set up up infor informa mation tion in temper temperaature tests, EMC tests and reac re action tion tests of valve controls, con trols, for exam example, ple, and this helps them to keep solu so lutions tions for produc production tion vehi vehicles cles lean.
Figure Fig ure 7: Easy fault local local iza zation tion for the driver driver with OBD
7/11
The devel devel opment opment of dual-chan dual-channel nel fan control control in the Pisten Pis ten-Bul ly ly was complet complet ed ed in an excep ex ception tional al ly ly short time without with out util izing izing real real hydrau hydraulic lic pumps, valves or motors. mo tors. In such cascases CANoe CANoe real real isti istical cal ly ly simu simulates all neces necessa sary ry CAN nodes, sensor sen sor signals signals and ECU infor informa mation. tion. In ECU set up up CANoe CANoe enenables access access to EEPROM EEPROM contents contents via an in-house flash proto proto-col. This is easy to repro reprogram gram with the inte integrat grat ed ed program program-ming language language CAPL (Commu (Com muni nica cation tion Access Access Program Programming ming Language). Lan guage). The EEPROM EEPROM data data stored on the hard drive can be loaded load ed into into the control control ler ler at any time.
Indispen Indis pensa sable: ble: Real-time Real-time capa capabil bil ity of de vel opopment tools An employ employee ee explains: explains: “As devel devel opers opers we rely rely on good tools, and CANoe’s CANoe’s reli reliaabil ity is excel excel lent! lent! Real-time Real-time capa capabil bil ity is espe es pecial cial ly ly impor important tant to us. We have al ready ready had nega negative exexperi pe rien ences ces with simi similar soft ware ware on anoth another er project. It took days of trouble troubleshoot shoot ing ing to final final ly ly find out that the tool simsimply could not keep pace with our sampling sam pling rate require requirements, ments, and this led to erro errone neous ous results.” results.” In-house user user inter interfa faces, ces, panels panels and other other tools that are frefrequent ly ly needed needed are gener general al ly ly programmed programmed in-house at KässKässbohrer boh rer using using Borland Borland C++. Even in such custom cus tom devel devel opopments CANoe CANoe data databas bases es al ways ways serve as the founda foundation. tion. Moreover, More over, CANoe CANoe facil facil itates opti optimal mal coop cooper eraation with suppli suppli-ers since the behav behavior ior of assem as semblies blies can be test ed ed in adadvance. The Pisten PistenBul Bul ly ly devel devel opers opers only only regret regret that not all system sys tem suppli suppliers ers provide provide CANoe CANoe simu simula lations tions of their proproducts or make them avail able early early on.
Mobil Mo bil ity for fine tuning tun ing on the slopes Another Anoth er impor important tant aspect aspect is tool mobil mo bil ity. Since snow condi condi-tions are constant constant ly ly changing, changing, fine tuning tuning of the drive syssys tem is of ten ten performed per formed local local ly ly in the mountains. moun tains. When it is impor im portant tant to perfect per fect control control loops for the var ious types of slope prepa prepara rations tions and adapt them to local local condi conditions, tions, CANoe CA Noe oper operat at ed ed on a laptop lap top proves to be an ef fi ef ficient cient mobile mobile diag di agnos nostic tic and measure measurement ment labo labora rato tory. ry.
Comprehen Compre hensive sive vehi vehicle cle diag diagnos nostics tics on a display display screen The vehi vehicle cle can be ful ly ly param parameeter terized ized at any time via a propro -
7/12
gramming PC that is connect gramming con nect ed ed to the CAN diag di agnos nostic tic conconnect or. or. For every every Pisten Pis tenBul Bul ly ly there is an electron electronic ic vehi vehicle cle record that seamless seamlessly ly docu documents soft ware ware updates, updates, the life of indi individ vidu ual compo components, nents, current current soft ware ware levels, levels, etc. It is possi pos sible ble to restore restore the deliv delivered ered state at any time. If probproblems occur occur at the custom cus tomer, er, On-Board Diag Diagnos nostics tics of fers fers fast and conve convenient nient fault local local iza zation tion over the cockpit cockpit display. display. All hydrau hy draulic lic functions, functions, sensors sensors and actu actuaators are designed designed to be electron electroniical ly ly diag diagnos nosaable. All that is needed need ed for in-vehi in-vehi-cle trouble troubleshoot shoot ing ing is a circuit cir cuit dia diagram and the display; display; no other oth er equipment equipment is needed. needed. Stored in the fault memo memory are the error error histo history ry and error error frequen frequencies. cies. All figures: figures: Kässboh Kässbohrer rer Gel ände ändefahrzeug fahrzeug AG
Authors: Au thors: Thomas Böck (Grad Thomas (Gradu uate Engi Engineer) neer) studied studied gener general al electri elec trical cal engi engineer neering ing at the techni technical cal col lege lege in Kempt en, en, Germa Germany. ny. He mana manages devel devel opment opment in the electron electronics/hy ics/hydrau draulics lics area. area. Tel. 07392/900-254, Fax 07392/900-259, E-mail: thomas.boeck@pis thomas.boeck@pisten tenbul bul ly.com ly.com
Peter Betz (Grad Peter (Gradu uate Engi Engineer) neer) studied studied tel ecom com-muni mu nica cation tion engi engineer neering ing at the techni technical cal col lege lege in Ulm, Germa Germany. ny. He is respon responsi sible ble for system system devel devel opment op ment in the electron electronics ics devel devel opment opment area. area. Tel. 07392/900-262, Fax 07392/900-259, E-mail: peter.betz@pis peter.betz@pisten tenbul bul ly.com ly.com
Markus Hör mann Markus mann (Grad (Gradu uate Engi Engineer) neer) studied studied tel ecom commu muni nica cation tion engi engineer neering ing at the techni technical cal col lege in Kempt en, en, Germa Germany. ny. He mana manages test equipequipment construc construction tion in the electron elec tronics ics test ing ing area. area. Tel. 07392/900-250, Fax 07392/900-249, E-mail: markus.ho markus.hoer ermann@pis mann@pisten tenbul bul ly.com ly.com Lothar Fel binger Lothar binger (Grad (Gradu uate Engi Engineer) neer) studied studied auto au toma mation tion engi engineer neering ing at the techni technical cal col lege lege in Reu Reutlin tlingen. gen. Since then he has been working work ing as Key Account Account and Business Business Devel Devel opment opment Mana Manager at Vector Vec tor Infor Informa matik tik GmbH for the Open Net working working product prod uct line. Tel. 0711/80670-505, Fax 0711/80670-555, E-mail: lothar.fel lothar.fel binger@vec binger@vector-in tor-infor forma matik.de tik.de
7/13
Current Trends in Network Development for Heavy-Duty Vehicles 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 vari ants with low production volumes and longer product life cycles, requir ing a suitable architecture layout. layout. Specially modified development methods are indispensable in handling cost pressure and sending reliable vehicles onto the street.
7/14
The number of ECUs, and hence the amount of software, has multiplied 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.
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 simultaneous use of electronic ECUs over different brands and integration of
Examples include ABS, ESP, ESP, ACC and other o ther driver assistance systems that make highway traffic safer and driving more pleasant. Analy-
standardized components can reduce cost pressure, they make the design of electronics and software more complex.
ses [1] assume that their implementation will increase further, and that electronic control modules will account for 90% of all innova-
Flexible solutions are in demand
tions by the year 2010. A key aspect is that 80% of these innovations will exclusively involve software or the functions implemented
When one considers the variety of strategies used by different
in software. In this context, it is clear that software development methods play a crucial role in the development process for the total
heavy-duty vehicle manufacturers, it quickly becomes clear that there is no universal solution. However, from a bird’s eye perspec-
vehicle, and they have a significant influence on a vehicle’s success or failure on the market.
tive clear trends can be seen, such as the use of standards, code generators and a universal tool chain. The number of ECUs is
increasing at a rather moderate rate, while the number of functions implemented purely in software continues to grow rapidly.
the available signals, but also the use of communication protocols. In Europe, for example, proprietary communication protocols are
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
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 differences in the area of in-vehicle diagnostics: In Europe, OBD diag-
tools are too different. This makes it difficult to achieve universality 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
nostics is implemented per UDS (ISO15765), (ISO15765), and in the t he USA per SAE J1939-73.
Attaining the goal by different approaches
friction losses, especially in inter-departmental or inter-site development 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-
The approach at MAN Nutzfahrzeuge AG is based on use of an integrated 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
pled to the database and support the supplier especially in such aspects as compatibility to requirements, quality and efficiency.
automatic code generation for the ECUs (Figure 2). In code generation, the Munich-based heavy-duty vehicle producer relies on
Examples would be code generators for embedded systems or test tools such as the CANoe.J1939 development and test tool from
proven CANbedded.J1939 standard software components from Vector. CANbedded.J1939 gets all of the information it needs for
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
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 conf ig-
number of variants. This requires flexibility in communication structures and in mapping functions to ECUs. This not only affects
uration of the code generating tool and guarantees error-free and complete code generation. This process also simplifies verification
Figure 1: The MAN Common Engineering Data Backbone
7/15
of the total system, since sections of the software have already been checked. It is possible to reuse the communication data for
AUTOSAR integration of J1939 makes it possible to achieve fundamental independence in tool selection. Volvo chose Vector as its
analysis tools like CANalyzer.J1939 or test tools like CANoe.J1939 from Vector, Vector, supporting the development of application layers. The Volvo Truck Corporation chose a strategy for software development that has now become established in the automotive indus-
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.
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 architecture is quickly achieved. It is easier to integrate suppliers, and it is not absolutely necessary to specify tools. This reduces dependencies on individual tool producers and suppliers. Problematic in this approach is the use of communication methods that are either incompatible with AUTOSAR properties or can only be used with it in a proprietary way. The use of J1939, in particular,, should be mentioned in this context. While AUTOSAR essenticular tially assumes a network of known nodes – and therefore a communication 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
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/j19 www.v ector-informatik.de/j1939ud 39ud [most of them are German]
Peter Fellmeth is a 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.
tool chain. Secondly, Volvo – together with Vector and other European 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 t he other hand,
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 standardized data formats are chosen, standard products can be used to describe and create the ECUspecific software.
7/16
SOLUTIONS FOR
Commercial Vehicles
The reliable, ef ficient way to design and test networks Development processes for open networks in commercial vehicles
. J1939 J1939 . J1587 J1587 .CANopen
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 comprehensive services will improve the efficiency of your entire development process, from design to analysis. Information and Downloads: www.j1939-solutions.com
Vector Informatik GmbH Ingersheimerr Str. 24 Ingersheime 70499 Stuttgart Tel.. +49 7 118 0670-0 Tel www.vector.com
n g n T e s t i e c n E o r m a r t s SA o p C o n f p s 9 s u J 1 9 3 e T e s t . J c e n o a a N i l CA o m p - 8 2 C 9 3 9 J 1
Automatic Interoperability Interop erability Tests for f or ISO11 ISO11783 Systems 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 usi ng 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. In the agricultural machinery field, the information age has long taken hold, and system thinking has replaced insular solutions. As
compatibility (system and manufacturer independent) of ISO11783ISO11783compatible products [1]. For the customer this is not only very easy
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 coordinated bus system ISOBUS was developed and introduced for the
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 manufacturers, however, this promise represents a great challenge in terms of
first time at the 2001 Agritechnica fair. ISOBUS standardizes data communication between tractor, implements and farm manage-
development, operation and maintenance of the machines. CANoe. ISO11783 from Vector offers a universal development and testing
ment computers and enables system-wide data exchange. The ISO11783 series of standards consists of 14 sub-standards; they
solution here. Option ISO11783 for the CANoe tool provides the necessary domain knowledge and supports conformity to the
each address different aspects of the technology, ranging from System Description (Part 1), Physical Layer (Part 2), Data Link Layer
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 conformity tests [2], different components, such as the Task Controller and implement, do not always harmonize in their interaction without problems. There is the potential for surpr ises in operation of an
(Part 3), Network Layer (Part 4) and Virtual Terminal (Part 6), Diagnostics (Part 12) and File Server (Part 13). “One person’s pleasure is another’s pain” is common folk wisdom. The situation is similar with the requirement for unlimited
7/18
implement when the Virtual Terminal is used too. As well as for service technicians, in such a heterogeneous environment as the
ISO11783-12 compatible diagnostic tool to detect problems related ISO11783-12 to an implement from a different manufacturer. The technician
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
might not be able to correct the problem, but can clearly identify its cause. If the cause lies in the implement, the tractor manufacturer’s service technician – who was summoned by mistake – can call up valuable information such as error codes or part numbers of
initiative AEF (Agricultural Industry Electronics Foundation) set up a project group tasked with conducting activities to improve the interoperability of ISOBUS devices [3].
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.
Uniform diagnostic access for the worst case
Ongoing efforts to extend Part 12 of the ISO11783 draft standard are taking the direction of a standardized description format for diagnostics. This would let each manufacturer describe diagnostic contents individually for each ECU. A prepared diagnostic application could use this description to diagnose the ECU regardless 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 ISO11783 diagnostics into their existing tool. Manufacturers without their own custom tools could use future standardized 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.
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 common 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 identification of the ECUs on the bus as well as information on the software 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 localization of the error causes. This is especially advantageous if a network 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 utilize, 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.
7/19
Automated tests during the development phase
certain aspect are desired, e.g. a check of the Transport Protocol. Such tests conducted over the course of development are generally
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
performed very frequently, they have many alternative test sequences, and they must be flexible in their configuration. Therefore, such tests should be designed for automation. If problems occur during the test, extensive analytical capabilities are needed
this does not correct the cause of the problem. In such a case, corrected 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
as well.
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 addition, 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
CANoe.ISO11783 from Vector is a universal development and test solution that is used to verify conformity to the ISO11783 ISO11783 standard, providing the necessary domain knowledge [6]. The Virtual Terminal, for example, is a fixed component of CANoe (Figure 1). Diagnostic messages can be visualized using the Diagnostic Trouble Code Monitor and Scanner 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
One tool for all cases
Figure 2: Phases of Test creation and interfaces 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 “Midsizee HIL”. “Midsiz HIL”.
7/20
AUTOMATIC INTEROPERABILITY TESTS FOR ISO11783 SYSTEMS
example. Figure 2 shows a schematic representation of the Test Feature Set. In such an environment, CANoe.ISO11783 CANoe.ISO11783 may assume the role of the test master and link to or drive other tools over various 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 capabilities, its use is not limited to just testing or simulation of individual 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
Peter Fellmeth studied Computer Engineering at the University of Applied Sciences at Esslingen, Germany, specializing in Automation Technology. He is a team leader and product manager at Vector Informatik GmbH, where he is responsible for development of products and customer-specific projects related to ISOBUS , SAE J1939, Ethernet and DeviceNet.
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 Society for Agricultural Engineering: ISOBUS speaks all languages. Just speak along with it.2005, pg. 2 [2] VDMA Professional Society for Agricultural Engineering: ISOBUS-conformant devices per the ISO 11783 11783 standard, www.iso www.isobus.net/isobus_ bus.net/isobus_EE [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
7/21
e c i v e D
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)
I
n developing electronics for modern construction equipment, a large share can even be tested and simulated meaningfully on test benches. In later development stages, on the other hand, it is preferable to perform tests and trial runs under real conditions at construction sites or outdoor test sites. To avoid distracting the operator in the driver’s cabin with test equipment, a wireless interface has now been realized for the first time with the CANoe and CANalyzer development and analysis tools from Vector Informatik. Electronics developers at Bomag GmbH now use this interface to log the communication on various vehicle buses at a distance and analyze it. Quality requirements in earthmoving work and highway construction are continually growing with a simultaneous rise in cost and time pressure. Soil compaction and cost-, raw material- and energy-saving methods of road preservation 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 machines annually for soil, asphalt and garbage compaction as well as stabilizers/ recyclers. Today, a large share of the company’s expertise has its foundation in electronics. When it comes to networking technology, Bomag
7/22
66
machine with the most extensive 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 secondly for milling, pulverizing and recycling existing materials in-place and locally.
Network cluster with multiple CAN buses
Fig. 1: The electronics on the MPH 125 support efficient implementation in soil stabilization and recycling
bases its work on the CAN bus standards of the automotive industry. Initially, the electronics concept was established on the large 10-t to 15-t machines, and it was then ported to the smaller machines. Since Bomag would like to have hardware and software components be reused as often as possible within the overall corporate group, the focus was on a modular concept. This also required standardization of development and test equipment across their business sites.
enables satellite-supported, large-scale compaction monitoring with seamless documentation of all parameters. In the future, radio networks will provide for data exchange between the machines driving in a group. The new type MPH 125 stabilizer/recycler – with an operating weight of 24.5 t and a power of 440 kW – is the
All Bomag machines of a given product line have the same control system, and they acquire their specific control functionality in end-of-line parameterization. Therefore, electronic developers mapped the machine’s modular product concept to a modular CANbased network cluster. CAN 1 – as the central BodyCAN bus – is connected to the most bus nodes. Its operation is based on the CANopen protocol, which enables the use of standard
Nothing works without electronics High-tech equipment and electronics electronic s can be found everywhere in the machines, from remote controls to drive-by-wire steering systems to the use of GPS. Sensors continually acquire the soil composition, and the display graphically indicates to the driver where compacting work is still needed. The GPS option
Fig. 2: The electronics concept reflects the modular layout of the machines
CAN Newsletter
2/2008
Fig. 3: J1939-specific interpretation of data in the Trace Window is performed with CANalyzer.J1939
automation components. Besides the vehicle’s main computer, the data acquisition 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 interfaced to the data acquisition unit, e.g. hydraulic pressure sensors and fill level sensors. The I/O module on the rear frame is responsible for control of the variableheight rotor, lateral tilt angle and lowering cabin feature for transport purposes. It was possible to significantly reduce wiring cost and effort by interfacing controls to the bus; these include the CAN-bus-capable joysticks, LC displays and external switches. Bomag created an in-house development of a CANopen driving lever with friction brake. The powertrain bus is defined as CAN 2, and it interconnects the vehicle’s main computer, engine controller, steering and driving levers, including operator consoles on the right and left. Interesting here is that the J1939 and CANopen protocols are implemented in parallel on CAN 2. A special feature of the drive control system is load-limit control of the Deutz diesel drive, which provides for dynamic power distribution between higher milling 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, depending on how the MPH 125 is equipped. It incorporates an optional metering computer with auxiliary display and the necessary actuators for water injection. Similarly, CAN 3 is needed to interface to the metering system for bitumen emulsion and foamed bitumen.
Multi-protocol capable tools In electronics development, Bomag implements a number of software tools from Vector Informatik. The Stuttgart-based networking specialist offers tailor-made tools for all electronic development tasks, such as CANoe for network development and ECU tests, CANalyzer for analysis of bus data and CANape for calibrating ECUs. At the beginning of development, CANoe simulates the behavior of individual bus nodes or entire sub-networks (rest-of-bus simulation). Over the further course of ECU development, the models serve as a foundation for analysis, testing and integration of bus systems and ECUs. The C-like programming language CAPL and userdefined interfaces simplifies the user’s work. A special real-time configuration significantly improved realtime capabilities even further, first by using separate PCs for rest-of-bus simulation and test execution, and second by graphic control/ evaluation; this yielded the high performance of a component HIL tester.
CAN Newsletter
2/2008
67
7/23
The CANalyzer analysis tool offers numerous functions for bus analysis. They range from tracing the bus data traffic to displaying signal values, performing statistical evaluations of messages, busloads and disturbances, and finally targeted generation of specific bus disturbances. CANape is used in the calibration of electronic ECUs. All important variables and parameter sets can be modified and visualized in real time. Helpful in conjunction with the de-
Besides supporting CAN, the tools also support the LIN, FlexRay and MOST buses as well as the higher level protocols proto cols J1939, J1587 J1587,, NMEA2000, ISO11783 and CANopen. In the case of Bomag, CANape and the CANalyzer/CANoe options for J1939 and CANopen are used. Protocol-specific extensions of the tools relieve the user of the need for detailed training in the J1939 or CANopen protocol; this avoids faulty interpretations of CAN frames. Last but not least, another important re-
now made it possible to establish contact with the DUT by an extension via a modified WLAN system. So the transceiver cable between PC and CAN bus is quasi removed and replaced by the radio pathway. NoteworNoteworthy here is the fact there are no significant compromises with regard to accuracy or measurement requirements. In implementing the extension, special attention was given to satisfying requirements for correct timing in data transmission, low latency times and time-syn-
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
velopment of GPS applications is CANape Option GPS, which supplements the system with visualization of the momentary vehicle positions on an electronic map. The universality of Vector tools is paying off at Bomag by helping it to master the complex challenges of working with multiple buses, and in particular the J1939/CANopen multi-protocol environment. The consistently applied database concept is an important pillar for the efficiency of the development tools. All members of the tool chain access the same data set, so that it is possible to save all data consistently without unnecessary redundancies or sources of error. Fitting for the bus systems used, the relevant databases of the network description are either already integrated or automatically generated to match the network configuration.
7/24
68
quirement in the analysis of muli-bus/multi-protocol environments 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 developers to achieve until now is time-synchronous analysis of the measurement data during the field tests mentioned in the introduction without having to be passengers 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 to the bus system being analyzed when working with the tools, the specialists from Stuttgart have
chronous display of the data on the PC. The CAN messages – together with their time stamps – are tunneled via a TCP/IP connection, so that the time stamps provided with the messages can serve as reference times for CANoe and CANalyzer.
‘Drilled out’ WLAN solution
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 developers can measure, observe and evaluate without a hard wire connection to the machine.
Summary and outlook This example from the commercial vehicle sector shows that there are interesting and demanding challenges outside of the realm of automotive electronics for luxury cars, challenges that can only be handled by complex network clusters and high-performance development 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 multiple buses or simultaneous use of different protocols on the same bus do not present any problems. The tools always ensure correct timing with the same time base in data acquisition and evaluation – even in the case of wireless communication. The Bomag developers already have their sights set on the next WLAN project involving automatic, multiday 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 Internet, e.g. from home during the weekend.
This solution offers some key advantages compared to the capabilities of a simple CAN/WLAN bridge. Only a bridge header is necessary for this setup. Sufficient as a host is a WLAN-capable laptop/ Sources: Fig.1 and 2: Bomag notebook, which maintains GmbH, Fig. 3 and 4: Vector Inthe connection via stan- formatik GmbH dard on-board resources and WLAN. The “probe” on holger.heit@ vector-informatik.de the DUT that is responsible for converting from CAN to
[email protected] WLAN sends the messages andreas.nacke@ bomag.com in strict and chronologically chronologically-correct order by considering hans-werner.schaal@ vector-informatik.de the time stamps originally
CAN Newsletter
2/2008
7/25
Moving Communication Wireless Analysis of In-Vehicle Networks
In the future, data communications in the automobile will also take place beyond the vehicle’s boundaries. New requirements 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. Modern driver assistance systems are indeed capable of looking
external sensors. This takes other vehicles into consideration (Car-
into the distance, but only with sensors (Radar, Lidar, ultrasonic, cameras, infrared, etc.) installed on-board the vehicle. Their rang-
2Car communication) as well as stationary systems known as “roadside units”, e.g. at traffic lights or tunnel entrances (Car2Infra-
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
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
external environment is necessary to utilize measured values from
technologies such as WLAN and pWLAN are already available.
Figure 1: The electronics in the MPH 125 support its eff icient use in soil stabilization and recycling.
7/26
While the advantages sound promising for all traffic participants, the challenges for developers are great too. Although the
Wireless analysis of modern construction equipment
developer had extensive capabilities for analyzing a vehicle’s various 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.
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 however,, it is preferable to conduct testing and trial runs under real conditions
Wide-ranging applications Besides its use in the development of future driver assistance systems, there are many other application areas for wireless analysis of bus systems. A typical example would be the testing of agricultural 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 solutions that can fulfill current Car2x and remote diagnostic
at construction or test sites. In a joint project with Vector, electronic developers at BOMAG GmbH implemented a wireless interface to the development and analysis tools CANoe and CANalyzer. This allowed developers to log communications of the various vehicle buses remotely and analyze them. BOMAG, the global market leader in the field of compaction technology, 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 stabilizer/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 materials (Figure 1).
requirements.
Figure 2: The electronics concept addresses the modular structure of the machines to integrate customerrequested options: metering computers, water injection, bitumen emulsion or foamed bitumen.
7/27
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.
Network cluster with multiple CAN buses Electronic developers have modeled the product concept as a modular 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, steering 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).
Without “umbilical cord”: Wireless field tests now possible Previously, it was difficult for BOMAG electronic developers to conduct 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 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 establish 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
Figure 4: Panels in CANoe.IP helps to visualize signals. Signals are displayed in the Data and Graphic windows, while analysis of the Ethernet protocol and signal
decoding appear in the Trace Window.
7/28
MOVING COMMUNICATION
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
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.
This solution offers some key advantages compared to the capabilities of a simple CAN/WLAN bridge. Only one bridge head is necessary 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 spatially 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 overabundance 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 Ethernetbased networks, sending of Ethernet packets and simulation of gateways between Ethernet and CAN.
7/29
Prototyping and Testing CANopen Systems Reaching Reach ing goals rapidly with minimal effort ef fort 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. The bandwidth of tasks in the development of CANopen systems
process during the test phase, since generally only one test setup
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).
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.
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 ver y late time, when actual system components are available. Then, the system completion date is at risk if prob-
Above all, prototypes of total systems networked by CAN should support testing and validation activities. In addition, it is important 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
lems occur. In practice, tests are not performed on the real system at the
endeavor in which it pays to use suitable tools. CANoe.CANopen from Vector offers valuable assistance in creating communication
customer’s facilities, rather test setups are used for this purpose. Besides special measurement or diagnostic setups, in testing they
for the prototype system. In just a few configuration steps, it lets the user create a prototype whose communication properties match
also include actuators for simulating system environments as realistically as possible. Depending on the project size, such a test setup could incur much cost and effort. Bottlenecks are built into the
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
Creating a prototype environment with tool support
Figure 1: Representation of the V-model
7/30
beforehand. This next step is to define the interrelationships between calibration data that will later be exchanged over the bus,
Test functionality
e.g. the “PressureValve” input of the device with address 5 (pressure transducer) is linked to the “Gas pressure” variable of the device with address 10 (control module). This is how all PDO (Process Data Object) interrelationships are defined in the prototype
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 functionality required for a CANopen system comprises several stages
system. The tool automatically computes the resulting mapping, which can be modified later if necessary. From this configuration information (DCF – Device Configuration File) the user now generates
(Figure 4):
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).
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.
Defining application behavior The application behavior of individual ECU nodes cannot be d erived 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 programming 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
> Protocol level: Tests on this level ensure that CANopen-specific communication protocols of the individual devices are implemented within the
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
7/31
Creating and executing test procedures with CANoe
Summary
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
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
processes the individual test cases sequentially. Suitable test flow control makes it possible to skip or repeat individual tests. Simultaneously, it is possible to monitor conformance to other conditions and restrictions – quasi in background. This might be done, for
offer the user efficient support in creating prototypes. The requirements for technical aspects of communication, in particular, are very easy to cover in t his way. In every phase of a project, this gives the system developer the test functionality needed to check and
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 handle 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 generated with a single tool. So CANoe utilizes a number of test patterns specified in XML and processes them accordingly.
verify components completed up to that point in time.
Figure 3: Representation of the CANoe. CANopen environment
7/32
PROTOTYPING AND TESTING CANOPEN SYSTEMS
Mirko Tischer, Product Manager for CANopen.
Figure 4: Test levels in CANopen
7/33
s l o o T
Automatic testing of CANopen devices Kai Schmidt (Vector Informatik)
T
he growing complexity of today’s system architectures 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 components. Test specifications should be available in early phases of the development process, e.g. after the system architecture has been created or during component design. This makes it possible to detect errors early and correct them costeffectively. The development process 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 definitions of individual “use cases”. This information represents the input for the next step, where initial assessments can already be made of the system architecture. Functions are assigned to
Fig. 2: Device functionality
8 7/34 2
Fig. 1: Development process of a CANopen system
the individual ECUs, and device descriptions can be created for all devices in the form of EDS files (the format of the EDS files was standardized by CiA and is being further developed by this organization in cooperation with industry). In addition, communication relationships between the ECUs can be configured, as network management and error detection mechanisms. EDS files describe significant parts of the functional scope of a CANopen device. These device descriptio descriptions ns form the foundation for executing the simulation and creating test specifications. Communication-specific tests can be derived directly from the device descriptions. An example of this would be a test that checks all
objects in the object dictionary by SDO accesses and records the results. Besides communication-specific 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. Afterwards, a check is made to verify that the signal value exists at the output. Both tests could be used early in the simulated overall system. As soon as the stability of the overall system has been achieved, development of the individual components can be subcontracted. The EDS files can – with the exception of application-related behavior – be considered as a requirements specification for the supplier. Parallel development 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 behavior of the device to be developed within the overall system. This can signifi-
Newsletter er CAN Newslett
2/2008
cantly reduce the number of cost-intensive changes desired by the OEMs – which generally occur within the integration phase. Communication-specific tests can be created at the supplier in a similar way as at the OEM. After completion and acceptance of the components, they are successively integrated into the simulated overall system. The previously created communication and applicationrelated tests can now be applied to the system, consisting of the physical components and the rest-of-bus simulation. As soon as all of the components have been delivered the concluding test of the real overall system follows.
EDS files as the basis for tests The development process should include the creation of an EDS file appropriate to the device. Unfortunately, practice shows that device producers often ne-
s l o o T
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 device producers who need to be concerned with creation of EDS files, but system designers too. The task of the system designer here is to distribute functionalities to the individual components. These could be standardized functionalities such as mechanisms for process data communication, but they might also be manufacturer-specific functionalities. Both of these are mapped via objects in the object dictionary. CiA specifications describe standardized functions. Standardized parameters (process data, configuration and diagnostic data) as well as manufacturerspecific data can be stored in a database format that is also standardized. The necessary objects can be selected from the object pool that is created in this way, and be assembled into an object dictionary dictionary.. The device descriptions contain all of the information necessary for simulation of the CANopen device. The overall system, consisting of the individual device descriptions, is parameterized utilizing a suit-
able configuration tool, and an initial system description is obtained in the form of device configuration files (DCF), whose format has also been standardized by CiA. Based on this configuration, simulation models can be generated and executed in a suitable runtime environment. At an early point in the project, this already enables conclusions about the time behavior of the overall system. If excessive bus loads occur, for example, actions can immediately be initiated to correct the problem, since suppliers have not been involved in the development process yet. Accordingly, the simulated 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-effectively and be checked immediately.
Derivation of test sequences Besides the simulation, it is also possible to derive initial tests on the protocol and communication levels from the device descriptions. The protocol test includes checking of the SDO protocol, for example. The communication tests do not check for correctness of the
protocol, but instead for correct flow of message sequences. 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 test ◆ SDO upload test ◆ Heartbeat producer test ◆ Heartbeat consumer test ◆ Transmit PDO test ◆ EMCY test Test functions are created for each object contained in the object dictionary here. The test functions are parameterized based on the data contained in the configuration files for the devices. Among other things, test sequences can be generated to check the: ◆ PDO configuration ◆ Default values ◆ Object dictionary ◆ NMT state machine, and ◆ SDO protocol The generated tests may be executed right away in a suitable runtime environment. In the framework of integration work, it is precisely such tests that are used to check the delivered components. In turn, suppliers can generate similar test sequences to assist in development. They can immediately be applied to the
prototypes. Essentially, this is a way to generate test sequences of the conformance test (CiA 310) 310) device-specifdevice-spec ifically. However, the goal of the system should not be to replace the CiA conformance test altogether. The system should accompany the development and give developers a way to test devices in advance of the actual tests. The final certification is only performed by CiA.
Generation template for each version Generation templates must be created for each test, but they are applied to each device to be tested. A generation template that describes the creation of a test for checking the object dictionary would appear as follows: for all objects { get access type if(access == read only){ add test function SDO Upload to test sequence } // if else if (access == read write) write){ { add test function SDO Upload to test sequence add test function SDO Download to test sequence } // else if . . }
The generated test sequence created based on this test template contains a number of parameterized (by entry of object index, etc.) write and read routines. They are processed sequentially in test execution.
Iterative development process Since iterative processes are applied throughout a device’s development, the
Fig. 3: Test sequences of a CANopen system
10
Newsletter er CAN Newslett
2/2008 7/35
process for generating test sequences must be repeatable as often as needed. Changes to the device design can affect the device
es receive or send them. Among other things, precisely these aspects must be tested. This subject matter can be explained by the
Fig. 4: “GPS date” object description
descriptions. The test that was originally generated would then likely fail. Nonetheless, it is still necessary to be able to manually extend test sequences after generation, e.g. to incorporate application-specific supplements. These extensions must be read back when the sequence is regenerated.
Application-related tests The application-related behavior of the devices can not be represented in the device descriptions. Furthermore, the tester does not want to have to deal with the CANopen-specific conceptual world and its definitions on the application level. On this level, it is entirely unimportant to know which signal is mapped to which object at which position. More important is information about which signals exist and which devic-
7/36
example of the CiA 447 application profile (application profile for special-purpose car add-on devices): The standard defines 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 allocations in the objects, also defines the transmission type. The standard specifies that the object value “GPS data” is transmitted by SDO protocol. The following information is needed to transmit a signal as part of a test: ◆ Index + Sub-Index of the object ◆ Signal length ◆ Start 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, information such as the signal length and start position of
s l o o T
Fig. 5: Generated test environment
the signal is also unsupported. Even if these requirements could be implemented, it is not possible to automate generation of application-related test sequences, since the behavior of the system is not described.
Generated test environment Nonetheless, the developer can be supported by gener-
T
he Codix 538 display by Kübler provides a CAN/ CANopen interface in order to display locally any user-defined value. Numerical values can be directly scaled using a factor or offset from the display device. The display has a floating decimal point that can be inserted in any position. Via the CAN network encoders can be read out directly, thanks to the Automatic Operational Mode. The display is provides automatic bit-rate detection and up to 16 node-IDs that can be set via rotary switches. The CAN port supports base and extended frame formats with maximum datarate of 1 Mbit/s. The disdi splay comes equipped with a 6-digit, 8-mm high-red 7segment LED. Each segment can be directly written to, allowing not only val-
12
ation of an “interaction layer” in test creation. If this thi s extension can be integrated in the simulated overall system, then it is easy to create application-related test cases. The test system consists of the simulated nodes that are extended to include an “interaction layer”. One or more physical devices are tested. The simulated devices are stimulat-
ed via generated interface functions. Signal values are mapped to object values and the CAN messages 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
Display communicates with encoder ues to be displayed but text es per revolution. As well messages also. There will as the CANopen output, the always be room for the dis- encoder is also fitted with play, thanks to its DIN hous- an RS-422 interface, which ing that measures 48 mm outputs the signals A,/A, x 24 mm, with an installa- B,/ B. “This “Thi s means it is postion depth of just 59 mm. sible to implement simultaReverse polarity protection neously both positioning via likewise facilitates installa- the CAN network and dition. On account of its high rect feedback of the speed IP65 protection rating the – all in just one encoder,” display can be easily used said Pierre Brucker, Marketin industrial environments ing Director at Kübler. “This without the need for an ad- saves on the costs and inditional protective housing. stallation space that a secThe company offers sever- ond encoder would have al encoders with CANopen entailed.” Using the variable connectivity since many PDO Mapping in the memyears. The Sendix absolute ory the user can decide, encoder features now an which information is to be additional incremental track. available in real-time. FuncParallel to the CANopen tions, such as the transmisoutput this encoder outputs sion of speed, acceleration an additional TTL compati- or exiting the work area, ble signal with 2048 puls- ensure fast data availabil-
Newsletter er CAN Newslett
known. Moreover, the transmission type must be considered. This information is described exclusively in the standard and must be considered in test creation. Use of an “interaction layer” enables signal-oriented test creation. It will be possible to define the function “Send_GPS_month” and generate its implementation based on the CiA 447 specification, if it exists in XML format in the future. Today’s format of the specification requires converting the specification to a readable format (XML or Excel). This conversion task can be assumed by a generator. The generated functions contain a mapping of the signal to the object value and a routine for sending the CAN messages. During test creation, the test engineer need not be concerned about signal positions, indices or transmission types. All the test engineer is interested in are the signal name, sender, receiver and signal value. kai.schmidt@ vector-informatik.de
ity while reducing the load on the bus and controller. The real-time position acquisition of the expanded CANopen Sync function enables genuine time-synchronous position detection of several axes. Kübler is also lunching lunchin g slip rings (ISTSR085 and IST-SR060) that can be used to transmit bus signals between a stationary and rotating platform. Typical applications include cranes, rotary tables, etc. The transmission between stator and rotor units takes place via sliding contacts (for current up to 40 A). Thanks to their fully encapsulated housing (in high-grade glass-reinforced plastic), high protection rating (up to IP 64) and resistance to vibration, these rugged products are suited to industrial use. www.kuebler.com
2/2008 7/37
Before Be fore consid consider ering ing tools it is essen essential tial to have a handle handle on Vector Consult Vector Consulting, ing, with its eASEE eASEE product, product, is of fer ing ing a complete complete tool en vi viron ronment ment for mana managing and control control ling ling engi engineer neer ing ing business business procprocesses. ess es. The software software is capa capable ble of or ganiz ganizing ing all of the process processes es and product product data data for software software and electron electronic ic systems systems over their entire entire product product life cy cle. cle. ATZ el ektron ektronik ik maga magazine spoke with Dr. Thomas Thomas Beck, CEO of Vector Vector Infor Infor matik matik and Vector Vec tor Consult Consulting ing GmbH, about de vel opment opment process proc esses es in de vel oping oping auto automo motive tive electron electronics ics and about the ad van vanta tages ges of eASEE eASEE (pro(pronounced: “easy”). Dr. Thomas Thomas Beck, CEO of Vector Vector Infor Infor matik ma tik GmbH and Vector Vec tor Consult Consulting ing GmbH
8/0
typical issues issues that ariATZ el ektron ektronik: ik: Dr. Beck, what are the typi
eASEE contrib contribute ute in this context, context, ATZ el ektron ektronik: ik: What does eASEE
se in the devel de vel opment opment process process for auto automo motive tive electron electronics? ics? dis tinction tion should be made between be tween two sub ject Beck: First a distinc areeas here. They are the engi ar engineer neering ing process process on the one hand, and the manage management ment process process on the other. other. The engi engineer neering ing process process is concerned concerned with mas tering tering techni techni-cal complex complexiity, i.e. the inter interac action tion of electron electronic ic compo components nents that are evolving evolving into into increas increasing ingly ly compre comprehen hensive sive systems, systems, e.g. driver driver assist assist ance ance systems, systems, ACC, lane keeping keeping systems, systems, etc. These systems systems of fer fer great chal lenges lenges to auto automo motive tive manu man ufac factur turers. ers. In the context context of manage management ment process processes es the prima primary ry conconcern is with planning plan ning and control control of engi engineer neering, ing, such as in project planning planning and tracking. tracking. Howe However, improved improved commu communi ni-cation ca tion between between produc producers ers and suppli suppliers ers and the chal lenge lenge of contin con tinu ual ly ly bringing bringing new products products to market market fast er er and more ef ficient fi cient ly ly are al so so require requirements ments of the manage management ment procprocess. When one exam ex amines ines the methods, methods, process processes es and organ organiization za tional al forms with which the auto automo motive tive indus industry try has typi typical ly ly oper operat at ed, ed, the writ ing ing was al ready ready on the wall sever several al years ago: Manu Manufac factur turers ers and suppli suppliers ers had to improve improve their system sys tem devel devel opment opment capa capabil bil ities enormous enormously ly to even be able to devel devel op op complex complex net worked worked electron electronic ic systems systems and to thereby there by remain remain compet compet itive. If you look into in to large corpo corpora ra-tions today, today, you will see that exten ex tensive sive programs programs are being being start ed ed every everywhere where to improve improve devel devel opment opment process processes es and enhance en hance qual ity.
and how are devel de vel opment opment tools linked to it? Vector tor has set up a team that works inten in tensive sively ly in conconBeck: Vec sul tation ta tion servi services relat relat ed ed to devel devel opment opment process processes. es. These are special special ists ists who togeth together er with custom customers, ers, i.e. OEMs and Tier-1 suppli suppliers, ers, ana analyze and opti optimize mize their devel devel opment opment process proc esses. es. Before Before consid consider ering ing the tools to be used, it is necnec essa es sary ry to have a handle handle on the process process level level first – i.e. to unun derstand der stand and docu document it. A tool like eASEE eAS EE can help to firmly firm ly embed embed process processes es in the organ or ganiiza zation tion in a last ing ing way. This protects protects invest invest ments ments made in process process improve improvement ment pro jects. eASEE eASEE supports supports all techni tech nical cal process processes es in an organ or ganiiza zation, tion, such as config configu ura ra-tion manage management, ment, change request request manage management, ment, project manage man agement ment and product product life cycle cycle manage management. ment. Our tool handles han dles all of an organ or ganiiza zation’s tion’s data data storage storage needs. To some extent ex tent this makes eASEE eASEE a backbone backbone that of fers fers certain cer tain funcfunctional tion al ities, and engi engineer neering ing tools dock to this system. sys tem. Exam Exam-ples of such tools are: Doors, our Da Vin Vinci ci tool, Ascet Ascet SD and Mat lab lab Simu Simulink. intel ligence ligence look like for linklink ATZ el ektron ektronik: ik: What does the intel ing these useful useful data data that origi originate from very dif fer dif ferent ent sources? sources?
Beck: eAS eASEE EE has vari var ious modules: modules: Engi Engineer neering ing Data, Data, WorkWorkflows, Process Proc ess and Project Manage Management ment and Strate Strategic gic Project Planning. Plan ning. This means that we al so so of fer fer Engi Engineer neering-Da ing-Data ta Manage Man agement. ment. This module module provides provides the neces necessa sary ry logic logic for linking link ing dif ferent ferent docu documents and data. data. The docu documents are embed em bedded ded in a coher coherent ent corpo corporate rate data data structure, structure, and rela rela--
the process processes es first
tionships are estab tionships es tablished lished between between them – accord according ing to predefined de fined process processes. es. The questions questions addressed addressed here are al ways ways process-re proc ess-relat lat ed. ed. Supple Supplemen mental tal logic logic is required re quired for data data that are rel evant to mechan mechaniical design. design. Such data data are inte integrat grat ed ed into in to the system system in the form of custom cus tomiz izing. ing. A data da ta structure structure might repre represent sent a vehi vehicle cle config configu ura ration tion for a passen passenger ger car or heavy truck, for exam example. ple. Data Data it contains contains might belong belong to the Engine Engine Manage Management ment System, System, Gateway, Gateway, or Transmis Transmission sion System; System; in the specif specif ic ic control control module module these data da ta extend extend deeper deeper into into the soft ware, ware, into into function functional al ity, to the CAN message message level level or to the model mod el level, level, for exam ex ample ple a Mat lab lab Simu Simulink model. model. As an anal ogy, one might picture pic ture a well-orga well-or ganized nized drawing drawing cabi cabinet contain containing ing all of the el ements that make up the vehi vehicle. cle. eAS EE imple implement ment ed ed at your custom custom-ATZ el ektron ektronik: ik: How is eASEE ers? prerequi uisite site for meaning meaningful ful use of such a product prod uct Beck: The prereq is that the custom customer er must have al ready ready defined defined its process processes es inter in ternal nal ly. ly. If that is not the case, the cus tom tomer er cannot cannot even start to use eASEE. eAS EE. In intro introduc ducing ing the product product to a compa company ny it is unim un impor portant tant whether whether we perform per form the service service or anoth another er consul con sul tation ta tion firm handles handles it. In princi prin ciple, ple, poten potential tial col labo laborative ra tive part ners ners not only only include include large corpo cor pora rations tions like IBM, but al so so small compa com panies nies who are special special ists ists in this area. area. Once process processes es have been clearly clearly defined, defined, the product product must be “custom “customized” ized” to the process processes. es. Vector Vector al ready ready of fers fers preprepared solu solutions tions here that can be adapt ed ed to a custom customer’s er’s needs.
sta tus of the process. status process. Aft er er all, the purpose pur pose of such a system sys tem is to produce produce transpar transparen ency. cy. To use an exam example: ple: eASEE eASEE is like a corset corset that should be suppor supportive tive but not restrict restrict ive. ive. recent exam example ple like AUTO AU TOSAR: SAR: ATZ el ektron ektronik: ik: Let’s take a recent What role does eASEE eASEE play here? AUTO TOSAR SAR defines defines a great deal of infor in forma mation. tion. Essen Essen-Beck: AU tial ly ly you must dif fer dif feren enti tiate ate two levels: levels: The base soft ware, ware, CAN net working, working, LIN net working, working, etc. on the one hand, and above these the so-called AUTO AUTOSAR SAR soft ware ware compo components nents that speci specify how a function function such as exte ex teri rior or light ing ing control control or inte interi rior or light ing ing control control must be described. de scribed. It is precise precisely ly this infor informa mation tion that must be managed. man aged. The AUTO AUTOSAR SAR data data backbone back bone accom accomplish plishes es this, in this case eASEE. eAS EE. By the way, one of our next devel de vel opment opment goals is to of fer fer a standard standard enenviron vi ronment ment that mirrors mirrors the AUTO AUTOSAR SAR data data model model and devel devel opment op ment process. process. AUTO AUTOSAR SAR takes the complex complexiity of the devel devel opment op ment process process to a yet higher higher level, level, making making eASEE eASEE that much more bene benefi ficial. cial.
Sometimes times it is not so simple sim ple to intro introduce duce ATZ el ektron ektronik: ik: Some new process processes. es. What has your expe experi rience ence been in this area? ar ea? performed recent recent ly, ly, manage management ment Beck: In pro jects that we performed stood clearly clearly behind behind process process devel devel opment. opment. The bot tom tom line is that engi engineers neers too are upset upset when they cannot cannot find docu documents or when coop cooper eraative work ef forts forts do not succeed. succeed. The climate cli mate for process processes es has been transformed transformed in recent recent years based on this fact. Good organ or ganiiza zation tional al devel devel opment opment means address ad dressing ing both sides. It must be a Win-Win sit uation for manage man agement ment and engi engineers. neers. To cite anoth an other er exam example: ple: At all times the engi engineer neer has the oppor opportu tuni nity ty to observe observe in eASEE, eASEE, the workflow workflow process process has taken taken to date as well as the current cur rent
Author: Au thor: Dr. Thomas Thomas Beck finished his studies on Electrical Engineering in 1986; doctor doc torate ate degree degree in 1992; began began business business career career in vari various posi po sitions tions at Bosch and ETAS; 1997–2000 CEO of the ETAS Group; and since 2001 part ner ner and and CEO of Vec Vector tor Infor Informa matik tik GmbH and Vector Vector Consult Con sult ing ing GmbH
8/1
Tool-sup port ed Tool-support ed Data Data and Process Process Manage Management ment at MAN Nutzfahrzeuge Nutzfahrzeuge AG At MAN Nutzfahrzeuge Nutzfahrzeuge AG an inte in tegrat grated ed approach approach was applied applied to mana managing all engi engineer neer ing ing data data gener gen er ated ated in the E/E de vel de vel opment opment process process and its subproc sub process esses. es. The goal is to fur ther ther improve improve the ef ficien fi ciency cy and qual ity of de vel de vel opment, opment, despite despite the growing growing complex complexiity of electron elec tronic ic systems. systems. MAN Nutzfahrzeuge Nutzfahrzeuge AG de vel de vel oped oped and intro introduced duced an inte integrat grated ed de vel opment opment data database base for this pur pose, which is based on the eASEE eAS EE Tool Suite from the Vector Vector compa company: ny: The MAN Common Common Engi Engineer neer ing ing Data Data Backbone. Backbone.
1 Moti Moti vation vation and Goals The devel devel opment opment of vehi vehicle cle functions, functions, ECUs and ECU net works works is bebecoming com ing more and more complex. complex. It is becom be coming ing increas increasing ingly ly impor impor-tant for MAN Nutzfahrzeuge Nutzfahrzeuge AG to be able to master mas ter this complex complexiity into in to the future. future. The prima primary ry ob jec jective tive is to increase increase devel devel opment opment ef ficien fi ciency cy while further fur ther improv improving ing product product qual ity.
2 Basic Basic Ideas Two factors factors led to the devel de vel opment opment of the MAN Common Com mon Engi Engineer neer-ing Data Data Backbone: Backbone: First, it was clear to man age agement ment very early ear ly on that qual ity could not simply simply be achieved aft erwards er wards by an exten ex ten-sive test ing ing process. process. Rather Rather a univer universal, sal, well lived-out devel devel opment opment process proc ess is neces necessa sary, ry, which encom encompass passes es all are areas of devel devel opment. opment. Second, Sec ond, manage management ment at MAN favored fa vored an inte integrat grat ed ed data database base solu solu-tion that saves all data da ta of the devel devel opment opment process process in a meta me ta model model (single (sin gle source) [Figure [Figure 1] and thereby there by ena enables very ef ficient fi cient data data
usage and data usage data univer universal sal ity. The abil ity to set rela relation tionships ships bebetween data data further fur ther increas increases es ef ficien fi ciency. cy. This data database base solu solution tion is referred re ferred to at MAN as the Common Com mon Engi Engineer neering ing Data Data Backbone. Backbone.
3 Imple Implemen menta tation tion The compa company ny was looking looking for a techni technical cal plat form form that lets users users concen con centrate trate on the actu actual al contents: contents: The data data structures structures and funcfunctional tion al ities. The system sys tem al ready ready provides provides basic basic mecha mechanisms such as user us er admin adminis istra tration, tion, version version manage management ment and client-serv cli ent-server er archi archi-tectures. tec tures. That is why the choice was made to go with the eAS EE Tool Suite from Vector. Vector.
3.1 eASEE eASEE as Technol Tech nol ogy Platform Platform eASEE is a process eASEE process tool whose core consists consists of a hier hi erarch archiical config config-ura ration tion manage management ment system sys tem for any desired desired data. data. This basic ba sic system system includes: in cludes: > Func Functions tions for version versioning ing and vari var iant forma formation tion > A user-con user-config figur uraable data data model model for user user data data and meta me ta data data > A workflow workflow engine engine > Mul ti-site ti-site oper operaation, and > A dif feren ferenti tiat at ed ed roles and rights concept. con cept. Overlaid Over laid on this basic ba sic system sys tem are modules modules specif specif ical ly ly designed designed for variious process var process are areas. These modules mod ules cover cover the ma jor ma joriity of key process proc ess function functional al ities that are needed need ed in the auto automo motive tive indus industry try [Figure [Fig ure 2]. Program Programming ming inter interfa faces ces are provid provided ed to al low low for indi indi-vidu vid ual exten extensions. sions. Besides Besides being being used at MAN, eASEE eASEE is al so so used at Bosch, Gener General al Motors, Motors, Daimler, Daimler, ZF, Vol vo, vo, Porsche, VW, Audi and Get rag. rag.
3.2 The MAN Common Com mon Engi Engineer neer ing ing Data Data Backbone Backbone
Figure Fig ure 1: Single-source Sin gle-source princi prin ciple ple for the de vel de vel opment op ment process proc ess
8/2
Today, the MAN Common Today, Common Engi Engineer neering ing Data Data Backbone Backbone consists consists of eight domains. domains. Its founda foun dation tion is an Ora Or acle data database base upon upon which the eASEE eAS EE Tool Suite is placed [Figure [Fig ure 3]. The process process model model distin distinguish guishes es between between the actu ac tual al devel devel opment opment process proc ess (“Do it”) [Figure [Figure 1] and the manage management ment process process (“Control (“Control it”) [Figure [Figure 4]. Anal ogous gously, ly, in the MAN Common Common Engi Engineer neering ing Data Data
Fig ure 2: Figure The eASEE eASEE process process tool suite
Backbone there are “Do it” data Backbone da ta domains domains (FDM, TDM, CDM, etc.), and a “Control “Control it” project manage man agement ment domain domain (PPM) [Figure [Figure 3]. The two are areas are inter interlinked linked across all domains. domains. Project schedules sched ules (Gantt Charts), for exam ex ample, ple, are auto au tomat mat ical ly ly updat updat ed ed based on the states of the el ements in the data da ta domains. domains. Thus, the project leader lead er no longer needs to perform per form mainte maintenance nance work on the states of work packets. packets.
Function Func tion Data Data Manage Management ment – FDM The indi individ vidu ual data data domains domains are orient orient ed ed direct direct ly ly toward toward the process. process. Function Func tion Data Data Manage Management ment (FDM), for exam example, ple, repre represents sents the left side of the V-Model. V-Model. This domain domain contains contains a complete complete meta meta model model used to describe describe all of the data data of an electron electronic ic structure, structure, includ including: ing: > Ve Vehi hicle cle config configu ura rations tions > ECUs > Hard Hardware ware (connect (connect ors/pins) ors/pins)
> Sig Signals nals (e.g. CAN) > Ve Vehi hicle cle functions functions > Func Functions tions > Soft ware ware archi architec tectures. tures. In addi addition, tion, a classic classic require requirements ments manage management ment system system is repre repre-sent ed. ed. Based on these data da ta structures, structures, the FDM of fers fers many function func tional al ities for the daily daily tasks of the engi en gineer. neer. These include: include: > Var Variious inter interfa faces ces to expert expert tools, e.g. Mat lab/Simu lab/Simulink/Tar link/Target get Link as a devel de vel opment opment envi environ ronment ment and XMet aL aL as an XML-based author au thoring ing envi environ ronment ment for detailed detailed speci specifi fica cations tions [Figure [Figure 5] > The option option of a virtu vir tual al vehi vehicle cle design/check, design/check, > Sig Signal nal path anal y ysis sis > Abil ity to gener generate ate DBC files to describe describe bus systems sys tems for anal y ysis sis and test tools such as Vector’s Vector’s CANa CANaly lyzer zer and CANoe. CA Noe.
Fig ure 3: Figure MAN Common Common Engi Engineer neer ing ing Data Data Backbone Back bone
8/3
Test Data Data Manage Management ment – TDM The right side of the V-Model V-Model is covered covereded ed by Test Data Data Manage Management ment (TDM). In this domain domain it is possi possible ble to map entire entire test pro jects. pro jects. Among other other things, TDM mana man ages the test speci spec ifi fica cations, tions, test exe execution cu tion infor informa mation tion for each test, test results, results, test envi en viron ronments ments and test methods. methods. Test data data in the TDM are direct di rect ly ly linked to devel devel opment op ment data data in the FDM. Since the system sys tem is used cross-depart cross-depart menmental and over all test levels, lev els, it is possi possible ble and very easy to draw conclusions clu sions about test cover coverage age – from compo component nent test ing ing to val ida da-tion test ing. ing.
Service Serv ice Data Data Manage Management ment – SDM Service Serv ice Data Data Manage Management ment (SDM) makes it possi possible ble to provide provide serviceservicerel evant data data to the service serv ice area area from the devel de vel opment opment area. area. Al so so reprepresent re sent ed ed in this system sys tem is a workflow work flow mecha mechanism that tracks the path from the released released ECU to its produc pro duction tion and use in series se ries vehi vehicles. cles.
Fault and Require Requirement ment Manage Management ment – FRM
Traceaabil ity Trace
Fault and Require Requirement ment Manage Management ment (FRM) contains contains a complete complete change manage man agement. ment. This system sys tem can be used to input in put issues issues into into the devel devel opment opment process. process. The indi individ vidu ual issues issues may be classi classified fied as errors er rors or new require requirements. ments. Errors Er rors are linked to both the test cycle cy cle in which the error er ror was found, in the TDM, as well as to the function func tion in which the error er ror occurred. occurred. This makes it very easy for function function devel devel opers opers to look in the FDM to see which issues is sues are still open for them. The test en gi gineer, neer, in turn, sees very quickly quickly which errors er rors were correct correct ed ed in a new function func tion verversion, and what form of post-test ing ing is neces nec essa sary. ry.
Today, al most Today, most all data da ta gener generat at ed ed in the devel devel opment opment process process is saved in a meta meta model model in the MAN Common Com mon Engi Engineer neering ing Data Data BackBackbone. Inte Integrat grat ed ed data data storage storage in a data database base ena enables nearly nearly perfect per fect traceaabil ity of the data. trace data. For exam example, ple, start ing ing from a test cycle cy cle it is possi pos sible ble to deter determine mine which error er ror was found with this test cycle cy cle and which require requirement ment the test cycle cy cle covered. covered. Anoth An other er poten potential tial use is to start with a CAN signal sig nal and have the syssys tem indi indicate cate which functions func tions in an electron elec tronic ic structure structure util ize ize this signal. sig nal. For exam example, ple, it is possi possible ble to deduce deduce whether whether a certain cer tain sensen sor can be omit ted ted in the system. sys tem.
Cal ibra bration tion Data Data Manage Management ment – CDM
3.3 Status Status of the MAN Common Common Engi Engineer neer ing ing Data Data Backbone Back bone
Cal ibra bration tion Data Data Manage Management ment (CDM) maps the data da ta of the cal ibra bra-tion process. process. Based on the data data of the FDM, in cal ibra bration tion pro jects this system system makes it possi possible ble to manage manage data data records records of ECUs via the ASAM ASAM MCD-2MC file. Data Da ta records records from estab es tablished lished cal ibra bration tion
Fig ure 4: Figure Planning Plan ning and control control of the de vel de vel opment op ment process process
8/4
tools such as CANa CA Nape, pe, INCA INCA or Caldesk Caldesk – which have an ASAM AS AM MCD2MC inter interface face and which support sup port the CDF or DCM exchange exchange forformat – may be read direct direct ly ly into into the CDM. Complet Complet ed ed and released released param pa rameeter sets may be ref erenced erenced in the FDM as ini in itial data data sets.
The MAN Common Common Engi Engineer neering ing Data Data Backbone Backbone has been in produc pro duc-tive oper operaation for sever several al years and is current cur rent ly ly util ized ized by about one hundred hundred devel devel opers. opers. Today Today it consists consists of the eight domains do mains
Fig ure 5: Figure FDM inter in ter face face to Matlab/Sim Mat lab/Simu ulink
TOOL-SUPPORTED DATA DATA AND PROCESS MANAGEMENT AT MAN NUTZFAHRZEUGE AG
Fig ure 6: Figure FDM inter inter fa faces ces to author author ing ing tools and exter exter nal nal data databas bases es
described and vari described var ious inter interfa faces ces [Figure [Figure 6]. Since devel devel opers opers are active ac tively ly support support ed ed by the backbone backbone in their daily daily work, from the first require requirement ment to the last test, the Common Com mon Engi Engineer neering ing Data Data Backbone Back bone is very well accept ac cept ed ed by devel devel opers. opers. It has been shown that it is very impor important tant for devel devel opers opers to work within within the system sys tem from the very first minute, and to single-source sin gle-source their data da ta here. This elimi elim inates an addi addition tional al mainte maintenance nance ef fort fort that would other oth er-wise be perceived perceived as rather rather disrupt disrupt ive. ive.
4 Util ity Aft er er about three years of produc productive tive use by the Common Com mon Engi Engineer neer-ing Data Data Backbone, Backbone, the ini initial ob jec jectives tives were real real ized. ized. Ef ficien fi ciency cy gains were achieved due to redun re dundan dancy-free cy-free data data input input and data data storage stor age and due to the many dif fer dif ferent ent options options for supply supplying ing infor infor-mation ma tion and prepar preparing ing data. data. Previ Previous ously, ly, an engi engineer neer would have to work through dozens dozens of docu documents to predict pre dict the conse consequen quences ces of transfer trans ferring ring a certain cer tain function function from ECU A to ECU B. To day, it takes just a few mouse clicks and the rel evant infor informa mation tion is avail able at the lat est est revi revision sion level. level. Anoth Another er advan advantage tage is reus re usaabil ity of engi engi-neering neer ing arti ar tifacts facts and data, data, which is made possi pos sible ble by Vari Var iant ManManagement. age ment. Other Other posi positive ef fects fects are the consid consider eraably improved improved transpar trans paren ency cy for engi engineers neers involved involved in the devel devel opment opment process process and the abil ity to estab es tablish lish role-specif role-specif ic ic views for one and the same data da ta content. content. Thus, the MAN Common Com mon Engi Engineer neering ing Data Data Backbone Backbone of fers fers very specif specif ic ic views of devel devel opment opment status, status, e.g. for the pro ject leader, leader, system system archi architect, tect, function function devel devel oper, oper, inte integra gration tion manmanager and test engi en gineer. neer.
established estab lished standards stand ards such as MSRSW and ASAM ASAM were used. Today, Today, this is very bene benefi ficial cial espe especial cial ly ly at suppli supplier er inter interfa faces. ces. Therefore, Therefore, MAN is fol lowing lowing the devel devel opment opment of the AUTO AUTOSAR SAR standard standard very closely. close ly. If the advan advanta tages ges of the standard stand ard appear appear suf ficient fi cient ly ly great, the MAN Common Common Engi Engineer neering ing Data Data Backbone Backbone would be adapt ed ed to the AUTO AUTOSAR SAR standard standard and brought to a level lev el of AUTO AUTOSAR SAR compat compat ibil ity. The inter interests ests of MAN and Vector Vector overlap overlap here too: The Stutt gart-based tool produc producer er has set the goal of devel de vel oping oping an eASEE eAS EE module mod ule for AUTO AUTOSAR-com SAR-compat pat ible system system data data manage management, ment, which combines com bines the advan advanta tages ges of the standard stand ard with key function functional al ities of the Common Common Engi Engineer neering ing Data Data Backbone. Backbone.
Stefan Teuchert Stefan Teuchert (Gradu (Grad uate Engi Engineer) neer) mana manages the Soft ware ware Devel De vel opment opment and Basic Basic Technol Technol ogies depart depart ment at MAN Nutzfahrzeuge Nutzfahrzeuge AG
Georg Zimmer Georg Zimmer mann mann (Gradu (Grad uate Engi Engineer) neer) mana manages the “Product “Product Line Process Process Tools” depart depart ment ment at Vector Vector Infor In forma matik tik GmbH
5 The Road Ahead In imple implement ment ing ing the MAN Common Common Engi Engineer neering ing Data Data Backbone, Backbone, special spe cial at tention tention was giv given en to exchange exchange formats formats to ensure ensure that
8/5
From Pilot Pilot Studies Studies to Produc Production tion Devel Devel opment opment Ef f icien ciency cy and Qual ity in cal ibrat ing ing Transmis Transmissions sions To soundly soundly manage manage growth in the num ber of complex complex transmis transmission sion cal ibra bration tion pro jects and their data da ta at ZF Friedrichs Fried richs-haf en en AG, the compa com pany ny needed needed to intro intro-duce a new cal ibra bration tion data data manage manage-ment system. system. Decid Deciding ing factors factors for intro intro-ducing duc ing the cal ibra bration tion data data manage management ment system sys tem eASEE.cdm eASEE.cdm from Vector Vec tor were the tool’s high function func tional al ity, flexi flexibil ity and poten po tential. tial. Anoth Another er crucial crucial factor factor was the compa com panies’ nies’ de vel opment opment partner partner ship ship over many years with the goal of joint ly meeting meet ing ZF tar gets gets for qual ity assur assur ance ance and improved improved ef ficien ficiency. cy.
To be success successful ful as a global global ly-active ly-active auto automo motive tive suppli supplier er in a marmarket charac character terized ized by inno innova vation, tion, compe competi tition tion and cost pressure, pres sure, it is neces necessa sary ry to have products products that meet the stringent strin gent techni technical cal and econom eco nomiical require requirements ments of auto automo motive tive OEMs. Based on its compre comprehen hensive sive expert expert ise, ise, contin continu uous ously ly opti optimized mized proprocess esses es and process process tools, ZF is able to posi po sition tion its products products for power power-train and chassis chas sis systems systems very success successful ful ly ly in the market. mar ket. In the power pow ertrain train area, area, ZF supplies supplies transmis transmissions sions for passen passenger ger cars, comcommercial mer cial vehi vehicles, cles, buses, buses, rail vehi vehicles, cles, ships and hel icop copters. ters. These areeas are marked by a very high level ar lev el of model model diver diversi sity. ty. This diver diversi sity ty in models models and vari var iants can be achieved by vehi vehicle-spe cle-specif cif ic ic param parameeteriiza ter zation tion (cal ibra bration) tion) of the transmis trans mission. sion. For exam ex ample, ple, ZF supplies supplies the 6HP26 6-speed auto automat mat ic ic transmis transmission, sion, which ena enables ef ficient fi cient gear shift ing ing in dif ferent ferent vehi vehicles cles with vehi vehicle-spe cle-specif cif ic ic torque curves ranging ran ging from 300Nm to 800Nm; this is accom ac complished plished by indi individ vidu ual param pa rameeter teriiza zation tion (Figure (Figure 1). Short shift times, smooth gear shifts, reduced re duced fuel fuel consump consumption tion and low emissions emis sions are other other ob jec jectives tives that can be met by opti op timal mal ly ly adapt ing ing param parameters eters to the vehi vehicle. cle.
Ob jec jectives tives for the new cal ibra bration tion data data manage management ment system sys tem were: > Uni Uniform form and corpo corporate-wide rate-wide system sys tem for central central manage management ment of all ZF drive and chassis chas sis pro jects > In Intro troduc duction tion of a modern, modern, market-es market-estab tablished lished Engi Engineer neering ing Data Data Manage Man agement ment system system (EDM system) sys tem) with a data da tabase base orien orienta tation tion > Sup Support port and standard standardiiza zation tion of defined defined cal ibra bration tion process processes es > In Inte tegrat grat ed ed checking checking and test routines rou tines for qual ity assur assurance ance > Mass oper operaations to improve improve ef ficien fi ciency cy > Flex Flexiibil ity of data data storage storage – from simple simple address addressing ing via vari var iantencod en coded ed groups for mul tiple tiple systems systems or vehi vehicles cles to complex complex data data storage stor age for many vehi vehicles cles
Require Re quirements ments of ZF Friedrichs Fried richshaf haf en en AG Even the first micro mi crocon control trol ler-based ler-based transmis transmission sion control control electron electron-ics includ included ed param parameeters for adapt ing ing the electron elec tronics ics to the envi environ ron-ment (e.g. transmis transmission sion hardware, hardware, vehi vehicle). cle). Start ing ing with just a few cal ibra bration tion param parameeters, the number num ber of param parameeters contin continu ual ly ly rose in response response to increas increasing ing function functional al ity. A growing growing model model diver diversi sity ty in transmis trans mission sion and power powertrain train systems systems – as well as a ris ing number number of paral paral lel lel pro jects – required required functions functions for central, central, ef ficient fi cient and process-con proc ess-conform formant ant manage management ment of the cal ibra bration tion data. data. The exist exist ing system system for data data manage management ment devel devel oped oped in-house at ZF had been stretched to its limits lim its by the complex complexiity of pro jects.
8/6
Fig ure 1: Figure The 6HP26 transmis transmission sion from ZF
Vector’s Vec tor’s eASEE.cdm eASEE.cdm Solu Solution tion To ful fill fill the require requirements ments out lined lined by ZF, a tool was needed need ed that inte in tegrates grates the functions functions of EDM systems, systems, process process tools and cal ibra bra-tion tools in a compre com prehen hensive sive system system solu solution. tion. In decid deciding ing on eASEE.cdm eAS EE.cdm from Vector, Vector, ZF chose a mature mature and market-es mar ket-estab tablished lished system. sys tem. The eASEE.cdm eASEE.cdm cal ibra bration tion data data manage management ment system sys tem consists consists of a data da ta manage management ment system sys tem for engi engineer neering ing arti ar tifacts facts and a graphic graph ic Param Pa rameeter Edi Editor; it al so so contains contains cal ibra bration-spe tion-specif cif ic ic functions functions and auto au tomat mat ed ed sequen sequences ces for mana managing all program program and data data sets ococcurring cur ring in the cal ibra bration tion process. process. As a modu mod ular compo component nent of the eASEE eAS EE tool suite, it is al so so easy to inte integrate grate it with other other process process domains do mains (Figure (Figure 2). Functions of the eASEE Functions eAS EE base system sys tem include: include: > Func Functions tions for version versioning, ing, and for forming forming vari var iants and config con figu ura rations tions > Flex Flexiibly config configur uraable data data model model for produc productive tive data data and the meta-da me ta-data ta that describes describes it > A workflow workflow engine engine for process-con process-conform formant ant flow control control > Mul ti-site ti-site oper operaation for coop cooper eraation between between distrib distribut ut ed ed work teams > A dif feren ferenti tiat at ed ed roles and rights concept con cept Flexible config Flexi configur uraabil ity of the data data model model makes it easy to imple imple-ment appli applica cation-spe tion-specif cif ic ic exten extensions sions – eASEE.cdm eASEE.cdm becomes becomes the dadata backbone backbone of cal ibra bration tion process processes. es.
Cal ibra bration-spe tion-specif cif ic ic functions functions support support project leaders, leaders, data data inte inte-grators gra tors and cal ibra brators tors in all phases phas es of a project. From project def inition ni tion to data data prepa prepara ration tion to release release of the inte in tegrat grat ed ed overall overall param pa rameeter sets, users us ers bene benefit from cal ibra bration tion data data manage management ment system sys tem function functional al ity: Project leaders leaders at ZF are able to clearly clear ly structure structure complex complex cal ibra bra-tion pro jects that have many vari var iants by proper property-sup ty-support port ed ed vari var iants manage management. ment. Data Data set vari var iants are formed by combi com bina nations tions of variiant-rel evant at tributes. var tributes. Vari Var iant crite criteria ria are al so so util ized ized as fil ter ter crite criteria ria in releas re leasing ing param parameeters (Figure (Figure 3). ECU suppli suppliers ers of ten ten perform per form cal ibra bration tion pro jects joint ly with the OEM, and this requires re quires flexi flexible handling handling of data. data. Cal ibra brators tors at ZF process proc ess and manage manage ECU param parameeters – either either param parameeter-ori ter-orient ent ed, ed, function-ori func tion-orient ent ed, ed, compo component-ori nent-orient ent ed ed or vari var iant-cod ant-coded, ed, depend depend-ing on the specif spe cif ic ic cal ibra bration tion process. process. The CANa CANape pe and INCA INCA cal ibration bra tion tools that are used gener gen erate ate market-rel market-rel evant data data formats: formats: both physi physical charac char acter teris istic tic data data formats formats (CDF, CSV, DCM, PaCo, PaCo, PAR) and program program formats formats (Intel (Intel Hex, Motor Motoro ola-S) are support support ed. ed. The cal ibra bration tion area area at ZF imple implements ments the graphic graphic Param Parameeter Edi Editor for checking, checking, ad just ment ment and data data inte integra gration tion (Figure (Figure 4). It of fers fers exten ex tensive sive options options for visu visual iza zation tion (table-for (table-format, mat, 2D and 3D) and off line line edit edit ing ing of ECU programs programs and param parameeters. Changes Changes are saved direct di rect ly ly in the eASEE eAS EE data data backbone. backbone. Data inte Data integra grators tors make exten extensive sive use of al gorithms gorithms to improve improve data data consist con sist ency ency and integ integri rity ty by checking checking for complete completeness, ness, unam unambi bigu gu--
Fig ure 2: Figure The eASEE eASEE process proc ess tool suite
8/7
ity and physi physical limits. limits. Project leaders lead ers at ZF appre ap preci ciate ate the added added secu se curi rity ty of fered fered by label-based label-based rights manage man agement, ment, which prevents pre vents paral par al lel lel releas releases es of overlap overlapping ping data. data. Other Other impor important tant functions functions have been inte integrat grat ed ed in the cal ibra bration tion data data manage management ment system, system, such as checksum check sum gener generaation and the abil ity to inter interface face to signa signa-ture tools for protect protect ing ing ECU soft ware. ware.
Intro In troduc duction tion of the System Sys tem The deci decision sion to imple implement ment eASEE.cdm eASEE.cdm as a corpo cor porate-wide rate-wide solu solution tion at ZF was made in 2003. Before Be fore roll-out in the indi in divid vidu ual business business areeas, eASEE.cdm ar eASEE.cdm was first intro in troduced duced and eval uat ed ed in two pilot pilot pro jects. Aft er success successful ful ly ly complet complet ing ing the pilot pilot phase, the system sys tem was intro introduced duced to daily daily business business oper operaations in 2004. The first propro duction duc tion pro jects were the ECOMAT ECOMAT (auto (automat mat ic ic transmis transmission sion for city buses) bus es) and ASTRON AS TRONIC IC (auto (automat mat ic ic transmis transmission sion for trucks and buses) buses) pro jects. Today, Today, approx. approx. 150 cal ibra bration tion engi engineers neers manage man age project and cal ibra bration tion data data for 20 pro jects in dif ferent ferent domains. domains. This ena en ables custom customer-spe er-specif cif ic ic sepa separa ration tion of project data. data. Imple Im plemen menta tation tion of ZF require requirements ments was based on a mul ti-year ti-year dedevel opment opment part nership. nership. Close coop cooper eraation made it possi possible ble to meet targets tar gets in a timely time ly way. The focus focus in imple implement ment ing ing require requirements ments was on gener general al usa usabil ity of the joint ly ly devel devel oped oped functions. functions.
Fig ure 3: Proper Prop er ty ty support supported ed var iants manage management ment
8/8
Util ity Production Produc tion cal ibra bration tion pro jects at ZF are performed performed using using cal ibra bra-tion process processes es that are defined de fined area-wide. area-wide. The process processes es are strucstructured so that many process proc ess steps can be run in par al lel lel and exe execut ed by an auto automat mat ed ed tool. All aspects aspects of this cal ibra bration tion process process at ZF are ful ly ly support support ed ed by eASEE.cdm. eASEE.cdm. It ensures ensures process-con process-conform form-ant exe execu cution tion of cal ibra bration tion pro jects in practice, practice, and it supports supports of cal ibra brators, tors, devel devel opers opers and project leaders. lead ers. In their daily dai ly work, users users bene benefit from the fol lowing lowing function functional al ities: > Im Improved proved coop cooper eraation of cal ibra bration tion teams due to uniform uniform and corpo cor porate-wide rate-wide system sys tem > Da Data ta freeze time is reduced re duced from one week to one day by auto au tomat mat ed ed checking checking and safeguard safeguarding ing functions functions > Re Reduced duced manu manual ef fort fort by auto automat mat ed ed gener generaation of the data da ta exchange ex change contain containers ers > Re Repro produc duciibil ity of data data revi revision sion levels levels by auto automat mat ic ic storage storage of test and signa signature ture config configu ura rations tions > Ef fect fect ive ive vari var iants manage management ment redu reduces ces number number of time-wast ing ing and error-prone error-prone actions actions > Col lision-free lision-free data data inte integra gration tion by label-based label-based rights manage man agement ment > Full tracea traceabil ity of the cal ibra bration tion process process by thorough thorough version ver sioning ing of all rel evant data data and proto protocols cols > Re Reus usaabil ity of cal ibra bration tion data data by compo component nent library library
FROM PILOT PI LOT STUDIES STUD IES TO PRODU PRO DUCC TION DEVE DE VELL OP OPMENT MENT
Summa Sum mary ry The eASEE.cdm eASEE.cdm cal ibra bration tion data data manage management ment system sys tem has been intro in troduced duced corpo corporate-wide rate-wide at ZF, facil facil itat ing ing ef ficient, fi cient, process-con process-con-formant form ant data data manage management ment while ensur en suring ing high data data qual ity. Besides Be sides being being used to support support the business business oper operaations, the tool al so so serves as an impor im portant tant founda foundation tion in conduct con duct ing ing (SPICE) assess as sessments ments of ZF business business process processes es in soft ware ware devel devel opment opment and cal ibra bration. tion. All of the ob jec jectives tives ZF sought to achieve were ful ly ly at tained. tained. Signif Sig nif icant increas increases es in ef ficien fi ciency cy of up to 90% were at tained tained in safeguard safe guarding ing and signing-o signing-off ff da data ta sets. Overall, Over all, eASEE.cdm eASEE.cdm is makmaking an impor important tant contri contribu bution tion toward toward reduc reducing ing costs in cal ibra bration. tion.
Rainer Röhrle Rainer studied stud ied Physi Physical Technol Technol ogy and Comput Comput er er Engi En gineer neering ing and has been employed employed at ZF since 1997. He is respon re sponsi sible ble for tool devel de vel opment op ment in the Electron Electronics/Soft ics/Soft ware ware area. area. Since 2003 he has been project leader leader for the corpo cor porate-wide rate-wide intro introduc duction tion of eASEE.cdm. eASEE.cdm.
Christoph Hel ler Christoph ler studied stud ied Electri Electrical cal Engi Engineer neering ing at the Uni verversity si ty of Stutt gart. gart. He works at Vector Vector Infor Informa ma-tik GmbH as Business Business Devel Devel opment opment Mana Manager in the Process Process Tools product prod uct line area. area.
Figure Fig ure 4: Param Pa ramee ter edi editor
8/9
Your Contact Con tact Ger many many and all countries countries not named below Vector Infor matik Vector matik GmbH Vector Vec tor Consult Consulting ing Serv ices GmbH Ingersheim Inger sheimer er Str. 24 70499 Stutt gart gart GERMA GER MANY NY Tel.: +49 711 80670-0 Fax: +49 711 8067-111
USA, Canada, Canada, Mexi Mexico Vector CANtech, Vector CANtech, Inc. Suite 550 39500 Orchard Hill Place Novi, Mi 48375 USA Tel.: +1 248 449 9290 Fax: +1 248 449 9704
France, Bel gium, gium, Luxem Luxembourg bourg
Japan
Vector France Vector 168, Boule Boulevard vard Camél Camél inat inat 92240 Mal akoff akoff FRANCE Tel.: +33 1 4231 4000 Fax: +33 1 4231 4009
Vector Japan Co., Ltd. Vector Seafort Sea fort Square Center Center Bld. 18F 2-3-12 Higashi-shin Higashi-shinaagawa, Shinaagaw Shin gawa-ku a-ku Tok yo 140-0002 JAPAN Tel.: +81 3 5769 7800 Fax: +81 3 5769 6975
Sweden, Denmark, Sweden, Denmark, Nor way, way, Finland, Fin land, Iceland Iceland
Korea
VecScan AB VecScan Theres Svenssons Svenssons Gata 9 41755 Göteborg Göteborg SWEDEN SWED EN Tel.: +46 31 764 7600 Fax: +46 31 764 7619
Vector Korea IT Inc. Vector 1406 Mario Mario Tower Tower 222-12 Guro-dong, Guro-gu Seoul 152-848 REP. OF SOUTH KOREA Tel.: +82 2 8070 600 Fax: +82 2 8070 601
United Unit ed Kingdom, Kingdom, Ireland Ireland
India
Vector GB Limit Vector Limited ed Rhodi Rho dium, um, Central Central Boule Boulevard vard Blythe Val ley ley Park Sol ihull, Birming Birmingham ham West Midlands, Midlands, B90 8AS UNIT ED ED KINGDOM KINGDOM Tel.: +44 121 50681-50 Fax: +44 121 50681-69
Vector Infor matik Vector matik India Prv. Ltd. 4/1/1/1, 3rd floor, Sutar Icon Sus Road Pashan Pash an Pune 411 411021 021 INDIA Tel.: +91 20 2587 2023 Fax: +91 20 2587 2025
China Chi na Vector Infor matik Vector matik GmbH Shanghai Shang hai Repre Represent senta ative Office Suite 605, Tower Tower C, Everbright Ever bright Conven Convention tion Center Center No. 70 Caobao Caobao Road, Xuhui District District Shanghai Shang hai 200235 P.R. CHINA CHINA Tel.: +86 21 6432 53530 Fax: +86 21 6432 5308
www.vector.com www.vec tor.com
