ijirae:: configuration and development of autosar4.0.3 compliant ecu and evaluating fault tolerant...

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 (ECU’s) are increasing rapidly .With this increased demand there is a need for the secured high speed networks to support the communication between networked ECU’s. 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 it’s easy to maintain. This paper will suggest how to configure and generate FR dual channel communication stack, Develop the application software components (SW-C’s 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-wire1. For designing the ECUs different vendors, OEMs use different hardware components and different software development approaches. This leads to the problem of 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 Opensystem ARchitecture) 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 from the existing hardware. AUTOSAR is a worldwide development partnership of car manufacturers, suppliers, and other companies from electronics, semiconductors and software industry11.

In the traditional ECU development hardware and software are tightly coupled leaving little room for 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 it’s easy to maintain. • Supports scalability to different vehicle and platform variants. • 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 from the

infrastructure. Application is composed of several connected SWC’s. 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 system design 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 system description files and ECU extract of system description 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 connectivity’s.

Table 1.1: Environment considered in developing the AUTOSAR ECU

Step: 1 Upload the ECU extract of system description .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 from the 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 from the tools and will be helpful in opening the project with the updated or saved configurations. Main intension in reusing the core code provided from the 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 diagram for 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 from the RTE and when ever FR IF request for the Data, COM will be providing with the data that it received from RTE. 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(PDU’s)/Frame .Once FRCC copied two redundancy frames from the 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

From the 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(PduInfoType **SDU_Data, UI_8 NumberOfPdus, UI_8* SelectedPduIndex)

Fugure1.11: Debugger trace: Equal PDUs received at the FR interface level

Different signals of PDU1

Different signals of PDU2

Transmitting from ECU2 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 from call back API as PDU1 got selected (By setting the variable SelectedPduIndex to 0), which can be seen from the Figure 1.12. FRIF follows the defined communication path and signals got updated through RTE runnable read APIs which can also be noticed from Figure1.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.(From the Figure 1.14).

VI. CONCLUSION

Finally ECU software platform was 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 ECU’s can be tried out and also performance of the system can be estimated while moving the software modules between ECU’s 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 – From free 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 – IJIRSET 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...

Documents