IJIRAE:: Configuration and Development of AUTOSAR4.0.3 Compliant ECU and Evaluating Fault Tolerant Redundant Communication On 2 Node FlexRay Cluster

International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2163
Volume 1 Issue 8 (September 2014) www.ijirae.com

_________________________________________________________________________________________________
2014, IJIRAE- All Rights Reserved Page - 409

Configuration and development of AUTOSAR4.0.3
compliant ECU and Evaluating fault tolerant redundant
communication on 2 node FlexRay cluster
Gayathridevi Koppineedi
*
Anjaiah Talamala M.Tech.;
ECE, Sri Sai Aditya IST, ECE, Sri Sai Aditya IST,
SURAMPALEM SURAMPALEM

Abstract With the recent advancements in automotive domain usage of no. of electronic control units (ECUs) are
increasing rapidly .With this increased demand there is a need for the secured high speed networks to support the
communication between networked ECUs. As ECUs handles more safety critical real time applications automotive
industries demand for more reliable, safe, secure, versatile topology configuration options. There is also an increased
demand for high bandwidth in the serial communication protocol. This lead to the development of the FlexRay (FR)
protocol as current protocols like CAN,LIN e.t.c are falling short to meet the requirements of the automotive industry
for real time control applications or x-by-wire systems. A group of automobile manufactures suppliers and tool
vendors created standard automobile software AUTOSAR (AUTOMOTIVE OPEN SYSTEM ARCHITECTURE) to
facilitate ECU software development also making software independent, more scalable, modular and its easy to
maintain. This paper will suggest how to configure and generate FR dual channel communication stack, Develop the
application software components (SW-Cs or SWC) and integrate with the AUTOSAR basic software modules (BSW)
to generate AUTOSAR 4.0.3 compliant ECU software, Integrate FR Active Star (AS) with AUTOSAR compliant ECU
in order to manage versatile topology, Evaluates the safety related fault tolerant redundant communication on FR
cluster connected as hybrid topology (Bus and star topology). Implemented solution will be forward compatible to
newer versions of AUTOSAR with minimal or no changes. During the system design hardware considered was
MPC5657 free scale based evolution board, AUTOSAR4.x compliant ECUs software configuration and development
was proposed using vector Davinci tool chain and FR communication network analysis was carried out using VN3600
FR network interface and Vector CANoe tool.

Keywords AUTOSAR, Flex Ray (FR), Hybrid Topology, ECU Software Development, BSW Configuration

I. INTRODUCTION

In the automotive domain no. of electronic control units (ECUs) usage is getting increased rapidly. For making
these ECUs to communicate between each other many standardized networks are being used. Among them most
commonly used protocols are Controller area network (CAN), LIN (Local area network), TTCAN (Time triggered CAN)
etc. But with the increased complexity of ECUs in the automobile vehicle, demand for the fail safe and secure
communication also got increased. As ECUs are handling more safety critical applications there is a need for more
reliable, safe, secure, versatile topology options and also there is a high requirement on the secured high speed networks
to support communication between ECUs. This lead to the development of the FlexRay (FR) protocol as current standard
protocols like CAN,LIN etc. are falling short to meet the requirements of the automotive industry for real time control
applications or x-by-wire systems. The FR communication systems are designed to provide high speed deterministic
distributed control for advanced automotive applications. Its dual channel architecture offers system-wide redundancy
that supports the reliability requirements of safety related systems such as brake-by-wire and steer-by-wire
1
. For
designing the ECUs different vendors, OEMs use different hardware components and different software development
approaches. This leads to the problemof reusing the software components, developing reliable software and integrating
different components. Also hardware and software are so tightly coupled that there is little flexibility to implement
additional security features. To address these issues a group of automobile manufactures suppliers and tool vendors
created standard automobile software framework AUTOSAR (AUTomotive OpensystemARchitecture) to facilitate ECU
software development making software independent, more scalable, modular and easy to maintain. This reduces the cost
of software development life cycle and also time to market will be minimal. FlexRay and AUTOSAR together create a
new challenge for the automobile industry. Automotive original equipment manufacturers (OEMs) hopes to meet future
demands on increasing functionality, increase in communication bandwidth requirements, deterministic fault tolerant
reliable communication and make easy the product development process by combining a faster and more reliable
protocol with a standardized automotive E/E (Electrics/Electronics) architecture. Before start of ECU development for
production, OEMs will analyze the feasibility of using the FlexRay communication protocol with their electronic units
and they will also identify the issues raised by integrating their specific requirements with the combination of
communication Protocol FlexRay and AUTOSAR. Tool chains and environment need to be decided upfront before
starting up the development and evolution phase.

_________________________________________________________________________________________________

This paper will suggest how to configure and develop such AUTOSAR4.0.3 complaint ECUs communicating on
FR cluster connected in hybrid topologies (Star and Bus topologies supported by FR) and shows the procedure for
evaluating the fault tolerant redundant communication on FR network.

II. AUTOSAR ESSENTIALS

AUTOSAR (AUTomotive Open System ARchitecture) is standardized and open, to facilitate software
development and maintenance of applications, independently fromthe existing hardware. AUTOSAR is a worldwide
development partnership of car manufacturers, suppliers, and other companies fromelectronics, semiconductors and
software industry
11
.
In the traditional ECU development hardware and software are tightly coupled leaving little roomfor reusing
the software components and also little flexibility in implementing the security features. AUTOSAR paves the way for
innovative electronic systems that further improve performance, safety and environmental friendliness. In addition the
advantages are listed as follows:
Strong global partnership that creates one common standard: "Cooperate on standards, compete on
implementation"
Key enabling technology to manage the growing electrics/electronics complexity. It aims to be prepared for the
upcoming technologies and to improve cost-efficiency without making any compromise with respect to quality
Facilitates the exchange and update of software and hardware over the service life of the vehicle.
Facilitate ECU software development making software independent, transferability of software, more scalable,
modular and its easy to maintain.
Supports scalability to different vehicle and platformvariants.
Supports broad variety of functional domains
It defines the open architecture for automotive software.
Standardize basic functionalities of automotive ECUs
For making software development independent of under lying hardware AUTOSAR proposed a
framework/layered architecture which distinguishes between hardware independent software modules and hardware
dependent software modules. Because of this efficient layered architecture and best methodologies proposed by
AUTOSAR, major technical challenges can be addressed. They are modularity, scalability, and re-usability.
Modularity allows writing piece of software code as per the functional requirements for specific components
and their tasks. So any enhances/modifications in future for any specific requirement will be limited to this part
of code.
Scalability of software functions/modules allows to use the same software for different platforms/variants this
will prevents rewriting the software code for similar functional purposes ( I.e no redundant code can be seen).
Re-usability of functions helps in improving the reliability of the system.
AUTOSAR framework was defined in 3 layers. As shown in the Figure: 1.1 below they are application SW-Cs,
Real Time Environment (RTE), and basic software modules.

Figure: 1.1: AUTOSAR ECU layered software architecture

A. Application SWCs: A basic design concept of the AUTOSAR framework is to separate application fromthe
infrastructure. Application is composed of several connected SWCs. Each SWC corresponds to a part of the
functionality of the application. There exists no limitation for how large an SWC may be, thus, it may correspond to
a function of a lesser extent or the complete functionality of an ECU. An important property of the SWC is that it
should be atomic. SWCs can run on any ECU compatible with AUTOSAR design irrespective of the type of

_________________________________________________________________________________________________

microcontrollers and ECU boards selected. The communication between SWCs are specified using virtual functional
bus (VFB) in the initial phase of the systemdesign but in the real ECU design SWC executions and interactions with
the basic software modules is through real time environment (RTE).
B. Runtime environment (RTE): The main task of RTE is to support the hardware independent design.
RTE will be adapted as per the specific ECUs; this is because SWC will be dependent on the type of application.
RTE code will be generated at the time of ECU specific configurations and generations and can be found it is
different in different ECUs, so it can't be reused. All the communications that occurs between software components
and BSW modules and also between different SWCs either mapped to same ECU i.e intra - ECU communication or
on different ECUs inter ECU communication will be routed through RTE.

Figure 1.2: Communication between SWCs routed through RTE

C. Basic software modules (BSW): This is the layer located below RTE and above the hardware as shown in the
Figure 1.1.This is standardized software providing the necessary services for running the functional part of the
software. Some of the major services supported by the BSW are diagnostics, communication, memory, input or
output (I/O), network management, and also operating system(OS). BSW layer again divided into 3 layers as shown
in the Figure1.3, namely service layer, ECU abstraction layer, micro controller abstraction layer and complex device
drivers (CDD). Short descriptions of all the 3 layers given below,
Service layer: This layer is below the RTE and will provide the basic services (like diagnostics, communication,
OS, memory management) to applications and also to other BSW modules.
ECU abstraction layer: This layer will decouple the higher -level software from all underlying ECU hardware
by providing standard interfaces.
Micro controller abstraction layer (MCAL): This layer will make the higher layers to be independent of micro
controller. To achieve this it provides the standard interface to the BSW modules / higher software layers by
managing the micro controller peripherals and providing the micro controller independent values.

Figure 1.3: Sub Division of BSW layers
Again each layers themselves divided into different functional groups as per their usage and their purpose. This
is shown in the Figure 1.4


_________________________________________________________________________________________________

Figure 1.4: Division of BSWs based on functional groups.

As shown in the Fig 1.4: one functional group of BSW layers are communication stack.In this paper, we will be
proposing the approach of configuring and generating Flex Ray communication stack and also development of
application SWCs.

III. CONFIGURATION AND DEVELOPMENT OF AUTOSAR ECU

In order to configure and develop AUTOSAR compliant ECUs, one should have the systemdescription files and
ECU extract of systemdescription files ( type .arxml( AUTOSAR xml)) in place. All the development steps specified
below were supported by different tools like Vector Davinci, EB Tresos e.t.c.

Development Environment considered for configuration and development of ECU are shown in Table 1.1

Tools Task
Vector Davinci Tool chain For configuration of BSW modules ,generating
application SWCs and the RTE
CANOE For network analysis of FlexRay cluster
P&ES debugger To download the program in ECU and For
debugging the ECU software
Multi meters For monitoring the voltage levels and checking
the hardware connectivitys.

Table 1.1: Environment considered in developing the AUTOSAR ECU

Step: 1 Upload the ECU extract of systemdescription .arxml file. In vector tools one can find the option under
input files.

Figure 1.5: Vector tool image to upload the ECU extract file

Step: 2 Update the configuration, which will allow us to see all the AUTOSAR supported basic software
modules in the tool.

_________________________________________________________________________________________________

Figure 1.6: AUTOSAR supported BSW modules

Step: 3 Required BSW modules will be configured and unwanted modules can be removed this will reduce the code size
in the final executable file.
Step: 4 During the configuration of FR communication stack some of the main BSW modules to consider are,
Communication module (Com), Protocol data unit router (PDUR), Diagnostic Communication manager (DCM), FR state
manager, Bsw manager (BswM), Communication manager (ComM), Digital input and output (DIO) Drivers, memory
services, Port, FR interface(FRIF) , FR Trans receivers, FR active star (FRAS) Drivers.
Step: 5 In BSW, 2 different types of codes are found one is the core code which is made prior to the ECU integration and
other is configuration code generated fromthe given configuration information in the AUTOSAR supported tool. Project
was mainly focused on generating the BSW FR communication stack, memory, operating system services, DIO, Port
drivers, Watch Dog timers. For configuring the BSW stack, AUTOSAR module specifications of release 4.0.3 and
manufacturer requirement documents to be referred.
Step: 6 After configuring the selected BSW modules, one need to compile and generate the code which will provide the
configured .c and .h files. This will be linked with the core code .c and .h files at the time of linking process for
getting complete executable code of BSW, at this point of time ECU configuration .arxml file will alsoget generated
fromthe tools and will be helpful in opening the project with the updated or saved configurations. Main intension in
reusing the core code provided fromthe tool vendors is bring down the development effort and to reduce the time .

Figure 1.7: SWC design

Step: 7 once the BSW modules are ready one need to start looking in the development of SWCs which are application
specific and this will be designed based on the OEM specific functional requirements. Development of SWCs in the tool
will support in generating the ECU software design template files, in the considered project functionality for supporting
fault tolerant redundant communication was developed as per the requirement. Signals transmitted or received from the
SWCs to be mapped to the real network frame signal data defined in the FlexRay database. As shown in the Figure 1.7,
application port interfaces, Application SWCs must be specified in the module based design.


_________________________________________________________________________________________________

SWC moulded using tools are assigned to runtime entities and mapped to different tasks scheduled in OS. Successful
completion of the SWC design steps results in generating RTE .c and .h files. RTE files, BSW core files and BSW
configuration files, Application SWC, Driver files to be compiled and linked to generate final execute file, which was
ready to be downloaded in the ECU board.

IV. EVALUATION OF FAULT TOLERANT REDUNDANT COMMUNICATION ON FR CLUSTER

For evaluating the Fault redundant communication between ECUs in order to achieve the reliability, final
executable software compatible with the AUTOSAR standard was downloaded in 2 nodes connected on FR cluster as
hybrid topology shown in the Figure 1.8 below. ECU hardware considered for the evolution is MPC5657 free scale based
board. Channel A of ECU1 and Channel B of ECU2 were connected as FR Bus topology and Channel B of ECU1 and
Channel A of ECU2 were connected as star topology.

Figure 1.8: ECU FR communication flow between 2 nodes connected on FR cluster using hybrid topology

Hardware connection diagramfor connecting the 2 ECU on the FR cluster with hybrid topology is presented in
the below Figure 1.9. ECU1 ChannelA (ChA) and ECU2 ChannelB(ChB) FR data Bus plus (FRBP) and Bus Minus
(FRBM) are connected as bus topology and data was captured by VECTOR FR 3600 interface for network analysis.
Similarly ECU1 ChannelB(ChB) and ECU2 ChannelA(ChA) connected as Active star network topology and data
communication between ECUs and Active star supporting board is through SPI (Serial peripheral interface) .

As represented in the Figure 1.8, ECU2 acting as a transmitter started sending the frames of similar type as an
initial step on the dual channel of FR network by invoking the RTE_Write application specific interface (API) calls.
(NOTE: Type of signal to be transmitted must be mentioned or implemented by the developer in the application code).
During the transmission of signal it was observed in the debugger that RTE does the call backs to the COM APIs for
sending the signal and COM grouped all the received signals fromthe RTE and when ever FR IF request for the Data,
COM will be providing with the data that it received fromRTE. In the configuration of FR buffers only one transmitter
buffer was considered and same data was placed on the 2 channels of FR connected as different topologies.

_________________________________________________________________________________________________

Figure 1.9 : Hardware connection diagram

Similarly at the receiving end, 2 FR receive buffers were configured and on receiving the FR data on 2 different
channels (ChA and ChB), FR Interface module was configured such that instead of transmitting the PDUs (Protocol Data
Units) through FR communication stack, it will do the call back to the application specific API function call, where there
was logic implemented for taking the decisions whether to discard the received PDU or to receive the PDU. (NOTE: In
order to receive the dual redundant frames in the AUTOSAR 4.0.3 based ECU FRIF job List for transmission and
reception was configured).

AUTOSAR reception configuration: - Using Vector BSW configurator:

When the configuration parameters of FR job list for the reception changed to receive two redundant frames
(DUAL_REDUNDANCY_STATUS == ON) then CC of FR was ready to receive the 2 protocol data unit
s(PDUs)/Frame .Once FRCC copied two redundancy frames fromthe FR receive buffer then FR receive function will
do the call-back to the application voting algorithm function that was implemented in application layer SWC. Note:
Name of the call-back voting function will be given in the configuration in case of VECTOR generated BSW.
When PDU1 received on ChA and PDU2 received on ChB are with NULL values =>Invalid PDU received =>
Return value to FRIF Module is PDU not ok (- Discard the message.)
When PDU1 received on ChA and PDU2 received on ChB are with different length =>PDU with variable
length =>Return value to the FRIF is PDU not ok (Discard the message invalid PDU received.)
When PDU1 received on ChA and PDU2 received on ChB had different CRC Values =>Not reliable data =>
Return value to FRIF is PDU not ok (Discard the message)
When PDU1 and PDU2 are of equal payload and with equal length parameters =>VALID PDUs received on
FR dual channel network =>Return Value to FRIF is Selected Value of the PDU (Either received on ChA or
ChB as directed by application layer SWC logic function).
Once PDU is validated and selected by voting logic, FR receive will transmit the selected PDU to the application layer
through comm. Stack as shown in the figure 1.8

V. RESULTS OF THE EVALUTION

Fromthe Figure 1.10 results showing that ECU1 is receiving the PDU1 data on channel A and B of FR network,
data received on both the PDU are equal. Debugging at FR Interface level finalizes equal PDUs were received in 2 FR
buffers; this is shown in the Figure1.11.FRIF does the call back to the application API

_________________________________________________________________________________________________

Figure 1.10: CANoe Image showing Trace window, FR Network connectivity between 2 real nodes and Frames and
signal layout

UI _8 Appl_RxVotingFct( PduI nf oType **SDU_Dat a, UI _8 Number Of Pdus, UI _8*
Sel ect edPduI ndex)

Fugure1.11: Debugger trace: Equal PDUs received at the FR interface level
Different
signals of PDU1
Different
signals of PDU2
Transmitting fromECU2
to ECU1 on FR network
Equal PDUs
received to
FRIF

_________________________________________________________________________________________________

Figure: 1.12: Debugger trace: Validating the 2 PDUS and selecting the PDU index, received the
data (Signal1 to Signal9)

Once the PDUs received to Application SW-C level, call back function Appl_RxVotingFct applied the
algorithm. As they are equal and valid CRC_Validation was set to one and FRIF will receive the return data fromcall
back API as PDU1 got selected (By setting the variable SelectedPduIndex to 0), which can be seen fromthe Figure 1.12.
FRIF follows the defined communication path and signals got updated through RTE runnable read APIs which can also
be noticed fromFigure1.12.

Figure 1.13: Receiving different or unequal PDUs on dual channel FR

Application data
got updated
CRC Validation is set one =>2
PDUS are equal
Selected PDU is PDU1
Unequal PDUs
received to
FRIF

_________________________________________________________________________________________________

Figure 1.14: Discard the PDUs: SelectedPduIndex =2 invalid (Message received to FRIF)

Figure1.13 shows that we are receiving the unequal PDUs on the dual channel network, Fault injection corruption of data
in the frames was done using CANoe tool, now results shows that CRC_Validation is set to zero and SelectedPduIndex is
2 i.e PDU got discarded and no updates on the signals in the application SWCs.(Fromthe Figure 1.14).

VI. CONCLUSION
Finally ECU software platformwas designed and implemented as per the AUTOSAR standards leaving the
flexibility to move or reuse the software modules; this has been achieved only because software design is completely
independent on the type of hardware we choose. By AUTOSAR compliant design over head of redesigning of the
software will be reduced because it is completely independent of the hardware and also engineering cost & time will be
saved. FR redundancy concept was integrated efficiently within the AUTOSAR architecture for supporting maximum
bandwidth and in order to achieve safety related fault tolerant communication over FR network. Dual channel
architecture of FR supports the system-wide redundancy because of this reliability requirements of safety related
systems can be achieved successfully; notice the same from the application level PDU handling in the debugger images
and network analyser results. Implemented solution can be forward compatible to newer versions of AUTOSAR with
minimal or no changes. In future this can be extended by considering the different versatile topology options of FR,
Reusability of the software components between the automotive systems ECUs can be tried out and also performance of
the systemcan be estimated while moving the software modules between ECUs on the network. Cyber security area in
the automotive domain can be explored and developed using AUTOSAR tool chain. Safety related concepts (E2E) and
fault injections during data transmissions can be evaluated in future work.

REFERENCES

[1] FlexRay communication strategy specification Release2.1
[2] FIBEX : Field bus Exchange Format
[3] FlexRay communication stack interface specification
[4] MPC 5675K reference manual Fromfree scale website
[5] AUTOSAR 4.0 FR communication stack specifications
[6] Internet Design process for the FlexRay based systems
[7] DataSheet NXP Semiconductors TJA1080 Bus driver
[8] Internet - AUTOSAR C coding standards
[9] FlexRay handouts
[10] www.Vector.com For understanding on Davinci tool chain
[11] www.AUTOSAR.ORG For AUTOSAR related information
[12] Development process for AUTOSAR-Based Embedded systems - International journal of control and Automotive
Vol.6, No.4, August,2013.
[13] A Case Study of Clock Synchronization in FR
[14] A Study on signal Group Processing of AUTOSAR COM Module.
[15] An overview if AUTOSAR Multicore operating systems implementation IJ IRSET Vol2, Issue 7, July 2013.
[16] FLEXRAY A communications network for Automotive Control Systems WFCS2006

CRC Validation is set zero =>2
PDUS are unequal
SelectedPduIndex =2 =>invalid
PDU

IJIRAE:: Configuration and Development of AUTOSAR4.0.3 Compliant ECU and Evaluating Fault Tolerant Redundant Communication On 2 Node FlexRay Cluster

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IJIRAE:: Configuration and Development of AUTOSAR4.0.3 Compliant ECU and Evaluating Fault Tolerant Redundant Communication On 2 Node FlexRay Cluster

Încărcat de

Drepturi de autor:

Formate disponibile

International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2163

Volume 1 Issue 8 (September 2014) www.ijirae.com

S-ar putea să vă placă și