Development of FlexRay Driver and its Simulink ...

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

Development of FlexRay Driver and its Simulink Blockset Implementation for SAE Benchamrk Application Zouhaira Abdellaoui 1†, Ihsen Ben Mbarek , Rim Bouhouch and Salem Hasnaoui [email protected] , [email protected], [email protected], ,[email protected] Université de Tunis El Manar École Nationale d'Ingénieurs de Tunis LR-99-ES21 Laboratoire des Systèmes de Communications 1002, Tunis, Tunisie working process of the network, and the application in need of communication [1]. FlexRay is a new communication system that offers reliable and real-time capable high-speed data transmission. This protocol protocol is meeting safety critical applications performance requirements (flexibility, fault-tolerance, determinism, high-speed…) [2] [3]. We have chosen the SAE (Society of Automotive Engineers) application which is normally connected by the CAN bus we extended it to the FlexRay Bus. The aim is to guarantee the intra-vehicular confidentiality Networks and to improve security, safety luxury and reliability in the automotive sector.

Summary FlexRay Networks is known for their speed and performance insuring communication over a shared medium since it offers reliable and real-time capable high-speed data transmission between electrical and mechatronic components. It is known as one of the newest x-by wire communication systems [1] thanks to its several features such as flexibility, faulttolerance, and determinism and high-speed. In the same context, the real-time middleware Data Distribution Service (DDS) is an appropriate alternative for the standard vehicular middleware. In this paper, we focus our interest on the development of FlexRay Driver and the Simulink Blockset implementation of its Driver in order to validate its performances and design and to provide current and future innovative functions into distributed systems within automotive applications.

We have exploited the platform of a vehicular network based on the Society of Automotive Engineers (SAE). There for, to validate the vehicle system design and to guarantee the arrival of the right data on the right time we have chosen to work within the bus FlexRay. In this paper, we have developed the FlexRay driver of its MB88121B Controller and we have implemented its Simulink blockset using the S-Function tool. We have applied the studied approach on a new vehicle benchmark developed in [4]. The author added to the original benchmark a number of nodes and messages to better represent the complexity of today’s vehicles and to model some options responsible for improving vehicle safety, reliability, cost, and luxury. We have adapted it to the FlexRay protocol instead of CAN network since this protocol is known for its speed and performances which uses ranges from planes to cars networks to insure communication over a shared medium [5]. We applied the real-time middleware Data Distribution Service (DDS) to this model in order to connect the designed sub-blocks [6].

The proposed blockset is dedicated for the SAE (Society of Automotive Engineers) application. The SAE benchmark model is normally connected by the CAN bus we extended it to the FlexRay Bus. We have applied the real-time middleware Data Distribution Service (DDS) in order to guarantee the QoS of SAE benchmark using the FlexRay protocol.

Key words: WSWAN; DDS; Embedded MATLAB; FlexRay; Suspension; SAE Benchmark; Simulink Blockset

1. Introduction Real-time Networks for automobile application are based on the interaction between the driver, reflecting the

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

1

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

2.2 Data Distribution Service DDS

In fact, DDS is an appropriate alternative for the standard vehicular middleware considering its ability to handle Quality of Service (QoS) parameters. The association between the DDS middleware and real-time network such as FlexRay enable automotive applications to run in a hardware and software environment meeting their timing requirements, thanks in part to the rapid access technique provided by the network and secondly to the temporal QoS guarantees by DDS.

The Data Distribution Service (DDS) is an open standard managed by the Object Management Group (OMG) and representing the first general-purpose middleware standard that addresses challenging real-time requirements. In fact, DDS handles a wide range of data flows, from extremely high performance combat management or flight control to slower command sequences. This specification describes two levels of interfaces: A lower level Data-Centric Publish-Subscribe (DCPS) that is targeted towards the efficient delivery of the proper information to the proper recipients and an optional higher-level Data-Local Reconstruction Layer (DLRL), which allows for a simpler integration into the application layer. It is based on publish-subscribe communication model illustrated in fig1, and supports both messaging and dataobject centric data models [7]. Also, DDS provides the DEADLINE QoS Policy, LATENCY_BUDGET Qos Policy, TRANSPORT_PRIORITY QoS Policy and other policies Specifically targeted to minimum latency, predictable realtime operation in high-performance distributed data critical systems [8].

2. Related Works 2.1 SAE Benchmark Model Features and sub-systems that are new to the SAE model are presented, and their corresponding nodes and messages are incorporated to the developed benchmark. First, the SAE modules names were translated to their equivalents in today’s terminology. The Driver and Battery modules were combined in the Body Control Module (BCM), which acts usually as gate way between the low-data rate and the high-data rate networks in a vehicle. Similarly, the Vehicle Controller and Inverter/Motor Controller were combined in a single node called Engine Control Module (ECM), while the Transmission Controller denoted the Transmission Control Module (TCM). Finally, the Brake controller in the SAE was transformed to the Hydraulic Brake Control Unite (HBCU).The Brakes Controller was usually called the Electronic Brake Control Module (EBCM) and the Steering Assist module was called Active Frame Steering (AFS). The rest of the modules didn’t have common names, and they kept their terminology unchanged like active suspension module, this is illustrated in [4]. All the signals in the extended benchmark are summarized in [7]. Our model is connected by the FlexRay bus instead of the CAN. According to the FlexRay specification, each node consists of a host (CPU) that processes incoming messages and generates outgoing messages, a communication controller (CC) that independently implements the FlexRay protocol services, and a two-way controller-host interface (CHI) that serves as a buffer between the host and the CC. The main goal of the proposed architecture is to ensure better performance of the vehicular network and to guarantee the arrival of the right data on the right time by meeting the tasks deadline. The framework architecture is a set of nodes connected via FlexRay Real-Time Transport protocol. In each node is embedded a Real-Time Operating System and a publish/subscribe middleware DDS.

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

Fig.1.DDS Communication Model : Publication/souscription

2.3 FlexRay Networks FlexRay Networks are one of the newest x-by wire communication systems .It is a real-time communication bus designed to operate at speeds of up to 10 M bits/s. It is developed by a consortium that includes automobile builder. It provides time-triggered and an event triggered architecture. Data are transmitted in payload segment containing between 0 and 254 bytes of data, 5 bytes for the Header segment and 3 bytes for the trailer segment.

2

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

However, if the register is Read Only we affect him only the Read function. We have to add the three services:Read(),Write() and ImmediateWrite.Ther for we have:

The topology may be linear bus, star or hybrid topologies. This bus contains two channels; each node could be connected to either one or both channels [9]. This bus contains a static segment for time triggered messages and a dynamic segment for event triggered messages. In time triggered networks, nodes only obtain network access at specific time periods, also called time slots. In event triggered networks, nodes may obtain network access at any time instant. The static (ST) segment and the dynamic (DYN) segment lengths can differ, but are fixed over the cycles. Both the ST and DYN segments are composed of several slots. The first two bytes of the payload segment are called message ID, this is used only in dynamic segment. The message ID can be used as a filterable data. In order to guarantee safety and performance required for time-critical applications (flexibility, fault tolerance, determinism, speed FlexRay), we have to develop its driver (API and Services) and implement its Simulink Blockset.

The number of driver sevices ∈ [Number of feild, 2x Number of feild]+3 (6) The service Get_Nom_du_champ() is essential for developing the services by following these tasks:






The service Set_Nom_du_groupement () ensures the formation of the field in question:

3. Development Methodology of FlexRay Driver





In this section, we focus our interest on developing the driver of our automotive Networks. It serves communication between its Network controller MB88121B and the SAE Benchmark application with the incorporation of the real time operating system µC/OS-III [10]. We have begun with the development of the API (Application Programming Interface) of our protocol.





The API (Application Programming Interface) is a program interface between our SAE Benchmark application and the FlexRay Driver which consist of procedures and functions that gives access to the various fields composing the network screen (data, ID,...). It is extremly related to MAC physical layer since it is the interface between our application and the driver. In the case of emission, it ensures the writing in the buffer of emission via the services driver after achieving the concatenation of fields necessary to formation of the FlexRay protocol header. While in the case of reception, it ensures the extraction of data from the queue reception by introducing the Read service of the FlexRay Driver. The protocolar treatement present the first step of Driver development. It consists of set of services identified by functions Get and Set. This protocol processing requires the assignment to each field of the header of the FlexRay protocol the two functions Get and Set as shown in (1) and (2).

The second step of developing of services according to the specificity of the FlexRay Network Controller. It should be noted that the number of services of the FlexRay Networks is one among its specific;which make this protoc ol evolutionary, flexible,answering the challenge posed by the increasingrequirements of automobile industry. The FlexRay protocol has 453 registers and 1248 services that we have developed.We have to affect to ech group of bit of all controller register the two functions set and get. If the register is Read/Write, we have to affect him two function Set and Get as expressed in (4) and (5).

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

Formation of grouping bits in question. Masking of the other groupings which does not interest us. Writing of the result R in the desired register. Send a message system to the task having called upon the service.

3.2 Development of the API

3.1 Development of the Driver Services

Get_Name_of_ feild Set_Name_of_feild

With the Read () service of our driver we can achieve the reading of the register which consist of the grouping requested from Emission, Reception or ISR tasks. The extraction is introduced by the shift and masking to rech a result R. Discussion according to the value R obtained.

(4) (5)

3

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

of the bit which do not ineterest and 1 for the bits in question .

(1) (2)

Get_Name_of_feild Set_Name_of_feild

While The Service Set _Name_of_feild() ensures the following steps:

Also, we must provide both services Send () and Receive ().Thus the number of API function that we have developed will include all function Set, Get,Send and Receive (3).




The nmber of API Functions ≈ 2x [Number of feild of header +1]




(3)


So we have to a protocol treatment of FlexRay frame in order to develop all these function for the driver. As shown in the following figure.

Reading of the variable of the state running of the FSM (Final State Machine) of the FlexRay protocol. Formation of the value of each field depending on the current state of the FSM in order to achieve the formation of the header. Once the formation of the values of the fields is completed, it is necessary to carry out their concatenation to build the heading of the FlexRay protocol.

Let’s take the example of WRHS1 (Write Header Section Register 1) register .It is a Read/ Write(R/W) register consisting of 7 groups such as the [bit 27] PPIT: Payload Preamble Indicator Transmit. This service is responsible for monitoring the payload preamble indicator status of the transmitted frame. Get PPIT () and Set PPIT ().

4. Simulink Blockset Implementation of FlexRay Driver In this paper, we focus our interest on studying a new methodology of development of automotive Nteworks’s driver based in Model Based design approach. It is the implementation of Simulink Blockset.This implementation will be a good and reliable tool regarded as a solution to resolve software development process. It facilitates the modeling that is required as design basis. It guarantees the complex systems validation

Fig.2.FlexRay Frame

For the implementation of MB88121B driver, the API of the FlexRay protocol needs eight fields for the header.There for we reach 8 Get_Name_of_feild () and 8 Set_Name_of_feild(). The number of API Function of FlexRay protocol becomes 18 functions. The Service Get_Name_of_feild() following steps in the reception event:




ensures

4.1 SAE Application Model We have chosen to work within a platform of a vehicular network based on the extended SAE benchmark. In this system a set of network processors subsystems produces routing data. It must be distributed along the vehicular network. It is based on the SAE Benchmark presented in fig1. The author has added to the original benchmark a number of nodes and messages to better represent the complexity of today’s vehicles and to model some added options responsible for improving vehicle safety, reliability, cost, and luxury. The resulting architecture is composed of 15 nodes connected by the FlexRay bus [11] [12].

the

The reception task extract the data including the field in question beginning from the queue reception by Read service () related to driver. The extraction is introduced by the shift and masking to rech a result R. It consist in translating to the left the bits of the field in question at the beginning of the register so that one can read correctly by putting 0 in front

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

4

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

We have used this tool to implement the Blockset Simulink of MB88121B Driver to be present in the Matlab Library.As shown in the Fig.4 Fig.4.

Fig.3. the Application Model

4.2 Simulink Blockset Implementation of FlexRay Driver In order to exploit the different services of the FlexRay Driver in Simulink models, we have developed a new methodology of implementation according to the ModelModel Based Design. Since we find in Matlab library the Simlink Blockset only of CAN protocol.This approach presents a solution conceived for software development process. Thus it facilitates the modeling that is required as design basis. We have used the S--Function tool to implement this Simulink Blokset and specially the LCT (Legacy Code Tool).The The following figure illustrates the process of this tool.

Fig.5. Simulink Blockset Implementation of FlexRay Driver

In fact, the Blockset Simuink developed for the CAN Networks is equipped with C166 Library driver. In our case, we have implemented this Blockset for the MB88121B Controller. This Library gets to us all the specific blocks for the controller network MB88121B and necessary for the implementation of FlexRay protocol model. This Blockset et consist of FlexRay Interface,Interruption Handing blocks and Execution Profiling blocks .As shown in Fig5.

Fig.4. Process generation of Blok S--Function

mmunication

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

5

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

Fig.7. Blockset of FlexRay Interface Driver Fig.6. Blockset of MB88121B Driver

The block of the MB88121B Library is equipped with the Inerrupts Bock wich is boocked for the external interrupt of type FIQ (Fsat Interrupt Request). There for, we have chosen the both pine three and nine of port 0 since it ensures connection with the external interrupt of the development map. The block of the “FlexRay Interface” gathers those of FlexRay Transmitted, Receive, Reset, Status and under library named “Open FlexRay MessageBlock”. The following figure shows the contents of FlexRay Interface.

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

The block “Open FlexRay Message Block” consist of the FlexRay- Message-Packing, FlexRay- MessageUnpacking and the FlexRay-Message-Filter blocks. These blocks included in Open FlexRay MessageBlock are illustrated in the following figure:

6

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

Fig.8. Open FlexRay Message Block

5. Test and Results In this section, we have tested the FlexRay Driver that we have developed and the blockset that we have implemented in Simulink. We have used the IAR (Integrated ARM) Embedded Workbench as tool pack designed for the development of the ARM environment to validate our development of FlexRay Driver. Take for example the function Set of VIEW register that belong to OBCR (Output Buffer Command Request Register). As shown in fig.8.

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

Fig.9. the behavior of the CPU registers of SETVIEW () Function

Also, we have tested the Blockset Simulink that we have implemented; let’s take the example of FlexRay-Receive block.Fig.9.

7

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

Fig.11.Génération of S-Function Transmit Block Fig.10. Compilation and execution of FlexRay receive code

We have tested the Blockset Simulink implemented of the MB88121B-FlexRay-Transmit. We have provided all the files necessary for the generation of the block transmitted according to this method of S-Function. Once, the files are compiled correctly and checked, the block transmit of FlexRay is generated automatically.

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

6. Conclusion We have presented a new methodology of development of automotive Networks driver. It guarantees the achievement of reliability and luxury in the developed Vehicle model. In my present paper; we focused our interest on the development of FlexRay driver and its controller Simulink Blockset implementation using the SAE Benchmark model with its different sub-blocks. We have proposed to use DDS on top of the real-time network FlexRay to take advantage of its high speed and to profit of the DDS QoS management in an automotive context. In my future work, I will integrate the Simulink blockset of other blocks of the SAE Benchmark model extended.

8

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

Acknowledgment The researchers presented in my paper are thanks to the support of many people. We wish to express our gratitude to the SYSCOM ENIT members for their help and assistance.

References [1] N. Navet (editor) and F. Simonot-Lion, “Automotive

Zouhaira

embedded systems handbook”. Industrial Information Technology Series. CRC Press, 2009.

[2] FlexRay Consortium, FlexRay Communications SystemProtocol Specification, Version 2.1, Revision A, 2005. [3] I. Broster. “Flexibility in dependable real-time communication”. PhD Thesis, Department of Computer Science, University of York, August 2003. [4] M. Utayba Mohammad, N. Al-Holou, “Development of an Automotive Communication Benchmark”, Canadian Journal on Electrical and Electronics Engineering, Vol. 1, No. 5, August 2010.) [5] D. Millinger, R. Nossal, « FlexRay CommunicationTechnology », The Industrial Communication Technology Handbook, CRC Press, Taylor & Francis, éditeur R. Zurawski, ISBN 0-8493-3077-7, janvier 2005. [6] « Data Distribution Service for Real-time Systems», Version 1.2. OMG Available Specification formal/07-01-01. [7] R. Bouhouch, H. Jaouani, Amel Ben Ncira3, S. Hasnaoui, “DDS on Top of FlexRay Vehicle Networks: Scheduling Analysis”, International Journal of Computer Science and Artificial Intelligence, Vol. 3 Iss. 1, PP. 10-26, Mar. 2013

Ihsen Ben Mbarek was born in Mahdia, Tunisia in 1983. She received the degree in Electronic and Microelectronic engineering in 2007, as well as the postgraduate Master's degree in Industrial Systems Engineering in 2009. They are both from the National Engineering School of Tunis in Tunisia. She has been a PhD student since 2010 in the "Networking and Distributed computing" research group within the Communications Systems Laboratory at the National Engineering School of Tunis. She has held a contractual assistant post at the Higher Computer Science Institute of Tunis in Embedded Systems Department also since 2010. Her research interests are the industrial networks for realtime, distributed applications and Network on Chip design. She has served on some conference committees and journals reviewing processes since 2012.

[8] Teton SNA Core Team, “DDS vs DDS4CCM”, Northrop Grumman, the Teton Project, July 13 2011. [9] D. Millinger, R. Nossal, « FlexRay CommunicationTechnology », The Industrial Communication Technology Handbook, CRC Press, Taylor & Francis, éditeur R. Zurawski, ISBN 0-8493-3077-7, janvier 2005. [10] A J. J. Labrosse. “MicroC/OS-II The Real Time Kernel”. Miller Freeman, Inc, United States of America, 1999. [11] Christopher A. Lupini, “Vehicle Multiplex Communication - Serial Data Networking Applied to Vehicular Engineering”, SAE, April 2004. [12] Tindel, K., Burns, A., “Guaranteeing Message Latencies On Control Area Network (CAN)”, Real-Time Systems Research Group, Department of Computer Science, University of York, England, 1994. [Online] available.

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

Abdellaoui

received the engineering degree in Electrical Engineering from the National Engineering School of Tunis, Tunisia, in 2010, a master degree in Automatic and Signal Processing in the same institute, in 2011, and she is a PhD student in Telecommunications. Her current research interests are performance evaluation of the DDS Middleware on Realtime vehicular networks using the SAE Benchmark as a standard vehicle prototype.

9

Full Paper NNGT Int. J. on Networking and Communication, Vol. 3, Jun 2015

Rim Bouhouch received the Engineering degree in Telecommunications Engineering from the National Engineering School of Tunis, Tunisia, in 2008, a master degree in Communication Systems in the same institute, in 2009, and is a PhD student in Telecommunications. Her current research interests are the implement and evaluation of Real-time Middleware for Real-time vehicular networks.

Salem Hasnaoui is a professor in the Department of Computer and Communication Technologies at the National School of Engineering of Tunis. He received the Engineer diploma degree in electrical and computer engineering from National School of Engineering of Tunis. He obtained a M.Sc. and third cycle doctorate in electrical engineering, in 1988 and 1993 respectively. The later is extended to a PhD. degree in telecommunications with a specialization in networks and real-time systems, in 2000. He is author and co-author of more than 200 refereed publications, a patent and a book. His current research interests include real-time systems, sensor networks, QoS control & networking, adaptive distributed real-time middleware and protocols that provide performance assured services in unpredictable environments. Prof. Hasnaoui is the responsible of the research group "Networking and Distributed computing" within the Communications Systems Laboratory at the National School of Engineering of Tunis. He served on many conference committees and journals reviewing processes and he is the designated inventor of the Patent "CAN Inter- Orb protocol-CIOP and a Transport Protocol for Data Distribution Service to be use over CAN, TTP and FlexRay protocols".

© N&N Global Technology 2015 DOI : 03.IJNC.2015.1.5

10