Embed Size (px)
Citation preview
iCC 2003 CAN in Automation
Migration from CAN to TTCAN for a Distributed ControlSystem
A. Albert, R. Strasser, A. Trachtler
Besides the well established event triggered bus protocols (such as, for instance, theCAN bus protocol) recently the demand for time triggered communication systems hasintensified. In order to accommodate demand, an extension of the CAN bus protocol toTTCAN (Time Triggered CAN) has been specified in ISO 11898-4. In the meantime also asilicon implementation of TTCAN is available.Since there are no TTCAN compliant sensors and ECUs so far, for an initial examinationan intelligent CAN/TTCAN gateway has been developed. In this way a laboratory stylemigration of a distributed control system which actually was developed around the CANbus to its time triggered version TTCAN easily succeed. This migration is carried outhere exemplarily by means of a vehicle dynamics control concept. Furthermore, thearticle gives some remarks concerning the synchronization of the sensors and the taskmanagement with the bus cycle.
1 Introduction
In recent years the amount of electronicdevices in automobiles has drasticallyincreased. This applies to the number of sen-sors, actuators and electronic control units(ECU) as well as the number of electronicdevices for entertainment and navigationsystems. In order to efficiently handle thelarge amount of data, bus systems areused. Thereby a compromise must be foundbetween economical aspects on the onehand and technological considerations on theother hand – for instance resulting from thedata rate and the required safety concept.A comprehensive overview addressing thedifferent bus concepts in the automotive fieldcan be found in [Ran02].For chassis control systems and powertrain communication the event triggeredCAN bus [CAN90] has established itselfas a de facto standard. Since moderncontrol concepts, such as X-by-wire requirehighly dependable architectures, recently thedemand for time triggered communicationsystems has intensified. For the mentionedapplications time triggered concepts areexpected to be superior compared to eventtriggered concepts, since their behavior isquasi deterministic during regular operation.Usually time slices define the permissionto access the bus (time division multiple
access, TDMA) such that the timeliness ofall messages can be guaranteed [Kop97].An other very interesting property from thepoint of view of the automotive field is the socalled composability. Since the time slices toaccess the bus are predefined, the behavioralong the time axis is decoupled from the ac-tual bus load. In fact, the predefined phasesamong the messages are constant. Thus, itis possible to develop different subsystemsindependently (e.g. by the car manufacturersand suppliers) and subsequently to mergethem into the complete system. There areof course also some disadvantages in com-parison with event triggered systems. Forexample, event triggered systems have abetter real-time performance when reactingto asynchronous external events which arenot known in advance [AG03]. Anotheradvantage is their higher flexibility. Thus,some busses try to merge the advantagesof both concepts (event and time triggered)as for instance TTCAN [LH02, MFH+02] orFlexRay [BBE+02]. It is not within the scopeof this paper to intensively compare the dif-ferent properties of event and time triggeredsystems. Works which address such a com-parison are, for instance, [Kop00, APF02].As already mentioned the CAN bus becamevery popular in automotive applications. Inorder to accommodate demand for time
05-9
iCC 2003 CAN in Automation
Figure 1: Vehicle Dynamics Man-agement with the components ESP(Electronic Stability Program) (in-tervention mainly via the brakes),AFS (Active Front Steering) (in-tervention via the steering angle),EAR (Electronic Active Roll Sta-bilizer), (intervention via the stabi-lizers)
triggered architectures, an extension of theCAN bus protocol to TTCAN (Time TriggeredCAN) has been specified by the InternationalStandardization Organization in ISO 11898-4[Org]. In the meantime also silicon imple-mentations are available, e.g. from Bosch[Har02] or Infineon [LKK03].On the base level the TTCAN communicationis still carried out with the physical CANbus. Hardware components on this level areproved and tested in millions of applications.Thus, all experience with the developmentof CAN based systems can still be utilized.Since further the TTCAN specification allowsa free scalability between time triggered andevent triggered operation, the migration totime triggered communication is simplified.
Within the current study a time triggeredarchitecture should be investigated for adistributed control system. The Bosch globalvehicle dynamics control concept, namelythe Vehicle Dynamics Management (VDM)[TL02] is envisaged as an example appli-cation. The idea of the VDM is to mergedifferent control systems in order to simul-taneously increase the safety, the stabilityand the comfort of the driving. An efficientimplementation implies a safe and adequatecommunication between the participatingECUs and sensors. Currently, the communi-cation is accomplished with a more or lessslack coupling via CAN. Within the study amigration to TTCAN is carried out in order toinvestigate the fundamental aspects of timetriggered architectures like the necessarysynchronization between the bus and the
ECUs on the one hand and the bus and thesensors on the other hand.This paper is organized as follows:Section 2 shortly describes the architectureof the Vehicle Dynamics Management VDM.Further, the current communication struc-ture on the basis of CAN is sketched andthe desired concept of the study based onTTCAN is presented. Since there are neitherECUs nor sensors currently available whichsupport TTCAN, a CAN-TTCAN-Gatewayhas been developed. Section 3 describes therealized printed circuit board (PCB). Besidesthe hardware description, the utilization ofthe gateway is shown in order to realize themigration from CAN to TTCAN. Furthermore,the time behavior (performance) of the gate-way is presented. As already mentioned,for an efficient implementation of the timetriggered architecture it is necessary to syn-chronize the bus with all participating nodes,the ECUs as well as the sensors. Subsection3.4 demonstrates the synchronization of theyaw rate sensor with the TTCAN bus. Thepaper ends with a summary in section 4.
2 Vehicle Dynamics ManagementFigure 1 illustrates the concept of the Ve-hicle Dynamics Management. The VDM isan approach for coordinating vehicle dynam-ics functions by control of active chassis sys-tems. This superior control strategy com-bines several control concepts and preventsnegative interference without restricting thefunctional range. Thus, simultaneously thesafety, the stability and the comfort of the driv-
05-10
iCC 2003 CAN in Automation
ing is increased. Currently, three control sys-tems are integrated in the VDM: active brak-ing, active steering and active suspension.
• The Electronic Stability Program (ESP)actively stabilizes the motion mainly viathe modulation of the brake pressures.The system is able to systematically gen-erate yaw torques in order to influencethe lateral dynamics [Zan02]. Particu-larly, the intention of the ESP is to pre-vent extreme understeering and over-steering when the car turns too fast or onslippery surfaces. Important sensors arethe yaw rate sensor (YR), which mea-sures the yaw rate and the lateral accel-eration of the vehicle and the steering-wheel angle sensor (SA), which mea-sures the steering angle and its timederivative.
• The Active Front Steering (AFS) is capa-ble to vary the actual steering angle byan overriding drive which adds an elec-tronically generated steering angle to thedriver’s steering input [KLS99]. Besidesthe possibility to actively increase thestability (mainly of the lateral dynamics) itis possible to vary the actual steering an-gle in relation to the steering commandfrom the driver and other factors. Thus,not only safety but also comfort and driv-ing pleasure is addressed by this system.
• The main purpose of the ElectronicActive Roll Stabilizer (EAR) is to sup-press rolling during cornering of the ve-hicle [KLV99]. For that purpose activestabilizers are introduced which are ableto shift the forces between the wheels ofeach axis.
The discrete systems partially act on differentdynamics of the system; however, there arealso dependencies which have to be takeninto account. Generally, different control con-cepts can cooperate, compete or merely co-exist. The former two (ESP and AFS) requirean adequate exchange of data (communica-tion) in order to assure an efficient operation.Thus, networking is of essential importance.Figure 2 shows the actual architecture of alab car with a combination of ESP with AFS.
Powertrain CAN
SASA
AFSESP
YR
Private CAN
Figure 2: VDM lab car with ESP and AFS
Some sensor data are required by both sys-tems, the ESP and the AFS. Such data arefor instance the wheel speeds which are avail-able from the Powertrain CAN. The yaw ratesensor (YR) and the steering angle sensor(SA) also communicate via this bus. An-other steering angle sensor is connected tothe AFS and transmits the real steering an-gle (driver’s desired steering angle plus ad-ditional angle of the AFS). Further, there arecrucial data between the ESP and the AFSwhich are exchanged via a private CAN com-munication.Figure 3 illustrates two alternative architec-tures for the study. For alternative a) all sen-
Powertrain CAN
a
b
YR
ESP AFS
SASAYRYR
ESP AFS
Chassis-Bus TTCAN
Powertrain CAN
SA
Chassis-Bus
TTCAN
Figure 3: Two envisaged architectures for thecase study of the VDM
sors communicate via the so called chas-sis bus, which in this case should be imple-
05-11
iCC 2003 CAN in Automation
mented as a TTCAN bus. For alternativeb) the chassis bus connects all participatingECUs whereas the sensors are connectedto the powertrain CAN. It is emphasized thatboth architectures merely present laboratorystudies. In order to realize a time triggeredcommunication with as much as possible par-ticipants in the following alternative a) is pre-ferred. The goals of the study are
• to generally investigate time triggered ar-chitectures,
• to investigate the implications concern-ing the development process,
• to implement synchronization mecha-nisms for the bus with the sensors andthe bus with the ECUs,
• and to investigate consequences on thecontrol performance and safety.
3 CAN-TTCAN-GatewayUnfortunately, so far there does not exist sen-sors and ECUs which are capable to runTTCAN. Therefore, an intelligent PCB hasbeen realized which realizes a CAN-TTCAN-Gateway.
3.1 Hardware Description
Figure 4 shows the top view of the CAN-TTCAN-Gateway. The board is based on
Figure 4: CAN-TTCAN-Gateway
the PowerPC micro controller MPC555. Thiscontroller provides on-the-chip various inte-grated sub systems, which earlier requiredadditional external devices [AW99]. Some se-lected sub systems are two CAN controllerand two TPUs (Time Processor Unit) whichshow the special emphasis to the automotive
field. The real-time multi-tasking operatingsystem RTOS-UH [Ger99] and the applicationprograms reside and run in the internal flashEEPROM of the micro controller [WAG01]. Auser program management allows to simplyexchange user programs via a terminal inter-face. Furthermore, the board has been ex-tended by a digital-to-analog converter andan ethernet module. Since the board makestwo TTCAN chips [Har02] available, togetherwith the two CAN controller of the MPC555one can imagine the following applications ofthe board:• 2 independent CAN and 2 independent
TTCAN nodes running control applica-tions on the MPC555
• 2 separate one-to-one connections be-tween CAN and TTCAN (the intendedgateway functionality)
• 2 CAN-to-CAN-gateways (eventuallywith different data rates)
• TTCAN-to-TTCAN-gateway (see annota-tion above)
• fault-tolerant (synchronous) bus systemwith parallel TTCAN busses
• coupling of the busses to other media,like Ethernet, serial communication, etc.
For time triggered bus concepts the commu-nication structure is defined in advance andgenerally not modified during operation. Forthat purpose the TTCAN chips are initializedat start-up by the content of a SPI-EEPROM(may be modified via the serial interface byimplemented shell commands); afterwards,they operate autonomously. Merely the dataof the messages may be modified during op-eration.
3.2 Migration from CAN to TTCAN
In order to explain the gateway functionalitythe simple architecture of figure 5 is consid-ered. Here two CAN nodes (CAN nodeA and B) communicate via the CAN bus.Now the gateways are attached in betweenas shown in figure 6 (one board realizes twogateways).From the point of view of the nodes noth-ing has changed, since both nodes still seemerely a CAN bus. However, there is adedicated receiver/transceiver to every node.
05-12
iCC 2003 CAN in Automation
CAN-Bus
CAN node B
CAN node A
Figure 5: CAN bus with 2 nodes
connection
TTCAN
CAN
CAN node B
CAN node A
TTCAN
CAN
CAN-TTCAN-Gateway
One-to-One
One-to-Oneconnection
Figure 6: Migration from CAN to TTCAN
Thus, each node is attached to a one-to-one(private) CAN bus. From the point of view ofthe bus a time triggered communication hasbeen established. The tasks of the gatewayare to forward messages from the TTCANbus to their dedicated receivers on the onehand and to place outgoing messages fromthe CAN nodes into the predefined time slicesof the TTCAN bus cycle on the other hand.
3.3 Time behavior
Figure 7 illustrates the behavior of the gate-way along the time axis for the scenario de-picted in figure 6. A situation is shown, wherea message for CAN node B arrives on theTTCAN bus (signal on the top level). Thesecond signal represents the interrupt of thecorresponding TTCAN chip. The falling edgeof this signal indicates the time instance atwhich the TTCAN chip notices that a mes-sage arrived for node B. Now the gatewayrepeats this message on the one-to-one pri-vate CAN bus to node B (signal on the bot-tom level). The third signal from the top in-dicates with its falling edge the arrival of the
data at their dedicated destination (typically atask that is waiting for the data).The repetition of each message implies a la-tency. But since we have a one-to-one con-nection between the gateway and its dedi-cated node, the bus can always be accessedand messages are never delayed. As aresult, the latency is constant1, known andtherefore considerable in advance. If one isconcerned to send a message, the content ofthe message should be at hand the latencytime earlier. If a node receives a message,in fact the message is a latency time delayed.These facts must/can be taken into accountwhen designing the communication matrix fora TT system on the basis of the gateway.The scenario in figure 7 shows a total latencyof approximately 325µs. This was a result forthe data rate 250 kbit/s. For a 1 Mbit/s sys-tem one can expect for an 8 byte message alatency of about 200µs. For the example ap-plication of the VDM which runs a cycle of 20ms the latency is 1% and hence not very criti-cal. Moreover, the latency can be consideredin advance as already explained.Summarizing, it is possible to emulate and totest a pure time triggered architecture if theaddition constant latency is considered.
3.4 Synchronization Bus↔ Sensors
Time triggered architectures work to a prede-fined schedule. Therefore, all participants likethe bus, the sensors and the ECUs have tobe time trigger compliant. Otherwise, for in-stance, it is not assured that measured dataare up to date. In the worst case they canexhibit a time delay of an entire cycle time(see also [AG03]). But since the participatingnodes typically possess different time bases(jittering crystal oscillators etc.) there is thenecessity to synchronize all participants.Usually for time triggered systems it is pro-claimed that the bus serves as the time mas-ter and delivers the global time. All sen-sors and ECUs are then synchronized to thisglobal time. In most cases a single synchro-nization in every global cycle suffices.
1Jitter occurs only when the IR is displaced.Since there is no further application except thegateway function, at most the timer interrupt canlead to a delay (µ seconds).
05-13
iCC 2003 CAN in Automation
-¾ 50µs
TTCAN bus
250 kbit/s
samemessage
BB
BB
BB
BBBM
»»»»:
CAN node B
TTCAN Rx-IR, ’got message’¾ Task at node Bgot data ¤
¤¤²
Figure 7: Time behavior of the CAN-TTCAN-Gateway (data rate of the CAN bus and the TTCANbus each at 250 kbit/s).
T
YYY
YR
YR
YR
YTYTY
constant latency
4T4T4T
TTCAN cycle 3TTCAN cycle 2TTCAN cycle 1
ECU
TTCAN
YRS
N2N1
MMM
N3A0N2A0N1A0
N3
Figure 8: Syn-chronization of theyaw rate sensorMM1.1, resultingin a constant la-tency (annotation:time axis is dis-torted)
As an example for the usage of the gate-way the synchronization of an ECU with theyaw rate sensor (YRS) via the bus is demon-strated in figure 8. It illustrates the actions ofthe different stations with respect to the cycletime on the TTCAN bus.The utilized sensor MM1.1 is not purpose-built for time triggered architectures but as willbe shown subsequently, a synchronization tothe bus cycle is possible.There are two versions of the yaw rate sen-sor. With the analog version we have noproblem since we read the current measure-ment on demand. The digital version inter-nally performs an analog to digital conversionand sends the result on request. To this endone has to request a measurement via a CANmessage with a dedicated ID (0xA0 in fig-ure 8). Triggered by this message the yawrate sensor delivers the current measurement
whereas the time delay between the triggermessage and the result message is guaran-teed to be below a certain time limit. It istherefore possible to make sure that at a cer-tain time instance an up to date measurementis available. As shown in figure 8 one hasto define appropriate time slices for the re-quest and the response in the TTCAN cycle.As a result, a constant latency is assured be-tween the trigger message (the request of themeasurement) and the receipt of the data atthe dedicated node. Constant and known la-tencies generally can be compensated by thecontrol algorithm.The time axis in figure 8 is distorted, since inthe actual application the cycle time is in therange of 20ms whereas the constant latencyis about 1.5ms.
05-14
iCC 2003 CAN in Automation
4 SummaryBy means of the VDM, the Bosch concept ofvehicle dynamics management, a time trig-gered architecture and its effects on the hard-ware, the software and the development pro-cess should be investigated. At present, thecontrol/functionality of the VDM is realizedwith the CAN bus. For the examination an ex-emplary migration to its time triggered versionTTCAN is in progress. The project is roughlydivided into four phases.The first phase was dedicated to a basic com-parison of the real time performance of eventtriggered and time triggered bus concepts. Asexplained in [AG03] it was possible to inter-pret the bus itself as a dynamic system andto measure its frequency response which al-lows the detection of characteristic propertiesof the bus system. For instance, the mea-surements yielded a reliability measure givenby the average latency response time and thejitter when reacting to asynchronous externalevents.The second phase was the subject of this pa-per. Since so far there are no sensors andECUs which are capable to run TTCAN, an in-telligent CAN-TTCAN-Gateway has been re-alized. In this way it becomes possible toemulate an entirely time triggered system.As was shown, merely constant but a prioriknown latencies have to be considered.The last two phases of the project deal withlaboratory and in-vehicle experiments. Thisincludes, for instance, the already mentionedsynchronization problem and the examinationof the implication onto the development pro-cess. Furthermore, it is intended to investi-gate the effects on the control performance.
References[AG03] A. Albert and W. Gerth. Evaluation and
Comparison of the Real-Time Perfor-mance of CAN and TTCAN. 9th CANin Automation Conference, iCC, Mu-nich, 2003.
[APF02] L. Almeida, P. Pedreiras, and J. Fon-seca. The FTT-CAN Protocol: Whyand How. IEEE Transaction on In-dustrial Electronics, 49(6):1189–1201,Dec 2002.
[AW99] A. Albert and B. Wolter. MultitalentMPC555: Schneller durch Gleitkom-
maeinheit. Elektronik, (15):48–53,1999.
[BBE+02] R. Belschner, J. Berwanger, C. Ebner,H. Eisele, S. Fluhrer, T. Forest,T. Fuhrer, F. Hartwich, B. Hedenetz,R. Hugel, A. Knapp, J. Krammer,A. Millsap, B. Muller, M. Peller, andA. Schedl. FlexRay – RequirementsSpecification. FlexRay Consortium, In-ternet: http://www.flexray.com, Version2.0.2, April 2002.
[CAN90] CAN. Controller Area Network CAN,an Invehicle Serial CommunicationProtocol. SAE Handbook 1992, SAEPress, pages 20341–20355, 1990.
[Ger99] W. Gerth. Handbuch RTOS-UH Ver-sion 4.2. Institut fur Regelungstech-nik, Universitat Hannover, Internet:http://www.rtos.irt.uni-hannover.de/,1999.
[Har02] F. Hartwich. TTCAN IP Module User’sManual, Version 1.6. Robert BoschGmbH, Automotive Equipment Divi-sion 8, Development of Integrated Cir-cuits (MOS), 2002.
[KLS99] M. Knoop, K.D. Leimbach, andW. Schroder. Increased Driving Com-fort and Safety by Electronic ActiveSteering. SAE Active Safety TOPTEC,27.-28.09.1999, Vienna, pages 1–8,1999.
[KLV99] M. Knoop, K.D. Leimbach, and A. Ver-hagen. Fahrwerksysteme im Re-glerverbund. Tagung Fahrwerktech-nik, Haus der Technik, Essen 17.-18.03.1999, pages 1–10, 1999.
[Kop97] H. Kopetz. Real-Time Systems – De-sign Principles for Distributed Embed-ded Applications. Kluwer AcademicPublishers Boston/Dordrecht/London,1997.
[Kop00] H. Kopetz. A Comparison of CANand TTP. Annual Reviews in Control,24:177–188, 2000.
[LH02] G. Leen and D. Heffernan. TTCAN:A New Time-Triggered Controller AreaNetwork. Microprocessors and Mi-crosystems, 26(2):77–94, 2002.
[LKK03] P. Leteinturier, N.A. Kelling, andU. Kelling. TTCAN from Applicationsto Products in Automotive Systems.Proceedings of the SAE InternationalConference, paper ID 2003-01-0114,pages 1–10, 2003.
[MFH+02] B. Muller, T. Fuhrer, F. Hartwich,R. Hugel, and H. Weiler. Fault-tolerantTTCAN networks. CAN Newsletter,CiA, pages 18,20,22,24,26,28, Juni2002.
05-15
iCC 2003 CAN in Automation
[Org] International Standardization Orga-nization. ISO 11898-1 (ControllerArea Network, Data Link Layer), ISO11898-2 (High-Speed Transceiver),ISO 11898-3 (Fault-Tolerant Low-Speed Transceiver), ISO 11898-4(Time-Triggered Communication).
[Ran02] M. Randt, editor. Workshop’Bussysteme im Automobil’, Elec-tronics & Communication in Traf-fic Systems ECT2002. Internet:http://www.carbussystems.de/, Juni2002.
[TL02] A. Trachtler and E. Liebemann. VehicleDynamics Management: Ein Konzeptfur den Systemverbund. 11. Aach-ener Kolloquium Fahrzeug- und Mo-torentechnik 2002, 2002.
[WAG01] B. Wolter, A. Albert, and W. Gerth.User-Expandable, On-The-Chip Real-Time Operating System for HighPerformance Embedded MechatronicSystems. Proc. of the 1st IEEEInt. Conf. on Information Technologyin Mechatronics, ITM’01, pages 255–261, Okt. 2001.
[Zan02] A. van Zanten. Evolution of ElectronicControl Systems for Improving the Ve-hicle Dynamic Behavior. 6th Interna-tional Symposium on Advanced Vehi-cle Control, AVEC 2002, 2002.
Dr.-Ing. A. AlbertRobert Bosch GmbH, Dept. FV/SLFRobert-Bosch-Str. 271701 Schwieberdingen, GermanyTel. +49(0)711/[email protected]. R. StrasserInstitute of Automatic Control, Uni HannoverAppelstr. 11, 30167 Hannover, GermanyTel. +49(0)511/[email protected]. A. TrachtlerRobert Bosch GmbH, Dept. FV/SLFRobert-Bosch-Str. 271701 Schwieberdingen, GermanyTel. +49(0)711/[email protected]
05-16
