AUTOSAR Communication Stack Implementation With FlexRay Master of Science Thesis in the Programme Networks and Distributed Systems JOHAN ELGERED JESPER JANSSON Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering Gothenburg, Sweden, March 2012 The Authors grant to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Authors warrant that they are the authors to the Work, and warrant that the Work does not contain text, pictures or other material that violates copyright law. The Authors shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Authors have signed a copyright agreement with a third party regarding the Work, the Authors warrant hereby that they have obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. AUTOSAR Communication Stack Implementation With FlexRay JOHAN ELGERED JESPER JANSSON © JOHAN ELGERED, March 2012. © JESPER JANSSON, March 2012 Examiner: ROLF SNEDSBÖL Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 [Cover: Illustration of a FlexRay car platform, developed by TTTech Automotive and AEV. http://www.audiblog.nl/?p=11008.] Department of Computer Science and Engineering Göteborg, Sweden, March 2012 Abstract The demand for a high level of fault-tolerance and high bandwidth communication has in- creased, as a result of a growing number of ECU’s (Electronic Control Unit) inside vehicles. FlexRay was developed to meet the continuously growing demands, offering a time-triggered functionality and a higher bandwidth than existing protocols. To facilitate ECU software development, a group of automobile manufacturers, suppliers and tool developers created the standardized automobile software, AUTOSAR (Automotive Open System Architecture). Merging FlexRay and AUTOSAR together creates a new challenge for the automobile indus- try. By combining a faster and more reliable protocol with a standardized automotive E/E (Electrics/Electronics) architecture, manufacturers hope to meet future demands. The goals with this project were fulfilled with wide margin. In order to obtain a working AUTOSAR communication stack with FlexRay, the FlexRay Interface module was developed according to the AUTOSAR specifications. The new FlexRay Interface module together with the available FlexRay Driver module was integrated into the Arctic Studio environment. This proved that modules of different AUTOSAR versions are compliant with each other and that modules from different vendors can be combined. Also, tests with a developed demonstrator indicated that the FlexRay communication stack is fully functional regarding PDU (Protocol Data Unit) handling. The demonstrator showed that PDU transmissions and receptions were successful, i.e. no messages were lost, and that all time properties were fulfilled. The configuration of the different AUTOSAR modules were made with the Arctic Core configurator in the Arctic Studio, and a new FlexRay configurator adapted to the existing FlexRay modules. Acknowledgements During our master thesis we have been in contact with a lot of people, and we want to give special attention to those who have been crucial for our project. Rolf Snedsböl has been our supervisor and examiner at Chalmers. He has helped us with issues about the report and how to structure it. Daniel Linné has been our supervisor at QRTECH. He has helped us with practical issues and we have discussed a lot of ideas and suggestions with him. QRTECH AB and the staff at QRTECH have provided us with the necessary equipment and knowledge to be able to complete this project. Ecore has provided the essential software and support. Table of Contents 1 Introduction 1 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Problem description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Previous work within the AUTOSAR software stack for FlexRay . . . . . . . . 2 2 Theory 4 2.1 AUTOSAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 Layered software architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1 Comparison with existing protocols . . . . . . . . . . . . . . . . . . . . . 10 2.2.2 FlexRay communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3 Frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3 Development methods 17 3.1 ODEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1 FlexRay configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1 Software environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2 Hardware environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4 Implementation 20 4.1 FlexRay Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.1 Interaction with other modules . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.2 Main function and initialization . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.3 FlexRay Job List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.4 Data transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1.5 Data reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2 Adaptation of considered modules . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.1 The connection between Arctic Studio modules and FlexRay modules . 26 4.2.2 Problems with modules of different releases of AUTOSAR . . . . . . . . 26 4.3 Code generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5 Configuring the development environment 29 5.1 Configuration in FlexRay configurator . . . . . . . . . . . . . . . . . . . . . . . 29 5.1.1 Global parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 i 5.1.2 Node parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2 Configuration in Arctic Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2.1 Available modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6 Results 33 7 Discussion and conclusion 36 7.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 References 39 Appendix A Flow charts 42 Appendix B XML and C code examples in configuration files 48 ii List of Abbreviations API Application Programming Interface AUTOSAR Automotive Open System Architecture BSW Basic SoftWare CAN Controller Area Network CC Communication Controller CORBA Common Object Request Broker Architecture CRC Cyclic Redundancy Check ECU Electronic Control Unit GDB GNU DeBugger I-PDU Interaction Layer Protocol Data Unit ISR Interrupt Service Routine L-PDU Link layer Protocol Data Unit LIN Local Interconnect Network MCAL MicroController Abstraction Layer N-PDU Network layer Protocol Data Unit NIT Network Idle Time ODEEP Open Dependable Electrical Electronic Platform OS Operating System PDU Protocol Data Unit PEEDI Powerful Embedded Ethernet Debug Interface POC Protocol Operation Control RTE Run-Time Environment SDU Service Data Unit SWC SoftWare Component TCP/IP Transmission Control Protocol/Internet Protocol TDMA Time Division Multiple Access TTCAN Time-Triggered CAN USB Universal Serial Bus XML eXtensible Markup Language iii Chapter 1 Introduction Network communication is an important part in modern vehicle industry. Components inside vehicles today are almost in all cases related to electronics. This has lead to an increasing number of ECU’s (Electronic Control Unit). In order for the different ECU’s inside a vehicle to communicate with each other, an interconnection through some sort of standardized network is needed. The rapid development in the electronics industry has lead to progress within the area of vehicle network technology [1]. As a result of an increasing number of electrical components inside vehicles, the demands on the communication have increased as well [2]. It is of great importance to maintain a high fault-tolerant level which challenges the capability of current standard protocols such as CAN (Controller Area Network) [3], LIN (Local Interconnect Network) [4] and TTCAN (Time-Triggered CAN) [5]. The automotive network communication protocol FlexRay was developed to meet the continuously growing demands, offering a time-triggered functionality and a higher bandwidth than existing protocols. Different vendors use different hardware and software components to create an automotive communication network. This has caused difficulties in developing reliable software and inte- grating the different components. To facilitate software development, a group of automobile manufacturers, suppliers and tool developers created standardized automotive software, AU- TOSAR (Automotive Open System Architecture) [6]. This standard aims at making the soft- ware more scalable, more reusable and easier to maintain, thus reducing the cost for software development. FlexRay and AUTOSAR together create a new challenge for the automobile industry. Manu- facturers hope to meet future demands when it comes to both product development as well as the use of the products, by combining a faster and more reliable protocol with a standardized automotive E/E (Electrics/Electronics) architecture. 1 1.1 Background QRTECH AB [7] is a company which has its focus on development combined with consulting services within the field of electronics and software products. In order for QRTECH to be at the front edge, regarding new automotive technology, they have started the work of implementing parts of the AUTOSAR software stack combined with the FlexRay protocol. One of their products used for development within this area is the ODEEP (Open Dependable Electrical Electronical Platform) platform [8]. One of the goals with the ODEEP platform is to reach a fully implemented and compatible AUTOSAR platform. QRTECH will meet future demands from the automotive industry, with a solution involving both the AUTOSAR platform and FlexRay. 1.2 Problem description The purpose of this master thesis is to obtain the AUTOSAR communication stack with FlexRay compliance. The final goal is to successfully run a demonstrator, which primary function is to send FlexRay frames in a FlexRay cluster consisting of three different nodes. This is achieved by completing the following tasks: • Integrating the existing AUTOSAR FlexRay modules from QRTECH with available AUTOSAR modules in Arctic Studio • Configure all AUTOSAR modules using the QRTECH ODEEP FlexRay configurator and the BSW (Basic SoftWare) Builder configurator in Arctic Studio • Implement the AUTOSAR FlexRay Interface module release 4.0 • Adapt surrounding modules to be compliant with FlexRay Interface caused by version differences • Implement a demonstrator for FlexRay communication between three different FlexRay nodes 1.3 Previous work within the AUTOSAR software stack for FlexRay The ODEEP hardware used in this project is developed at QRTECH. There have been several previous master thesis performed, using this hardware for different applications. Some of these master theses have developed software adapted for ODEEP. Thus, the tools and software needed for the hardware was already in place before the start of this project. Much of the knowledge needed to use these tools was provided via written manuals and guides, but also through the employees at QRTECH. Software components like start up routines, basic drivers and hardware tools were already developed and without them this project would not have been possible within the given time 2 frame. The main purpose for the ODEEP hardware is to be used for development and test- ing in the automotive industry. Therefore, some work has been done to make the ODEEP hardware compatible with AUTOSAR. Several modules have been implemented but the most important modules for this thesis were FlexRay Driver and FlexRay Interface. The modules are implemented with an older 2.1 release of AUTOSAR. 3 Chapter 2 Theory The theory defining the base for AUTOSAR and FlexRay is described in this chapter. Firstly, an overview of the concept of AUTOSAR is presented in terms of different software layers. This is followed by more detailed information about the so called AUTOSAR modules that are treated in this project and their relation to FlexRay. Finally, the theory of the FlexRay protocol and its communication features are introduced. 2.1 AUTOSAR AUTOSAR is a software architecture in the automotive industry, which has been globally de- veloped by companies within the automotive and electrical branch. AUTOSAR is standardized and open, to facilitate software development and maintenance of applications, independently from the existing hardware [6]. It is especially suitable for ECU’s that have the following properties: • Strong interaction with hardware, such as sensors and actuators • Connection to vehicle networks, for example CAN, LIN and FlexRay • Microcontrollers (16 or 32 bit) with limited resources of computing power and memory • Real-time systems. • Program execution from internal or external flash memory. It is not compatible with applications such as graphics library, CORBA (Common Object Request Broker Architecture), Bluetooth, USB (Universal Serial Bus), and TCP/IP (Trans- mission Control Protocol/Internet Protocol) [9]. To achieve hardware independency when using AUTOSAR, it distinguishes between hardware independent software and hardware dependent software by creating different layers. With this software structure AUTOSAR fulfills particularly four technical properties. These are mod- ularity, scalability, transferability, and re-usability. Modularity divides software according to the requirements for specific components and their tasks. This makes it possible to adapt the 4 software to individual requirements. The scalability of functions makes it possible to use the same software for different platforms, which prevents redundant code for similar functional purposes. Transferability means optimizing the availability of resources in the electrical archi- tecture of the vehicle. Re-usability of functions helps in improving the reliability of the system. A prerequisite for this to work in practice is that there have to be connections between the different software modules. This is an important aspect of AUTOSAR’s functionality. 2.1.1 Layered software architecture As previously mentioned, the AUTOSAR software stack is designed with different layers to separate software that is hardware dependent from software which is hardware independent. As shown in Figure 2.1, the highest abstraction level consists of three different software layers: Application Layer, RTE (Run-Time Environment), and Basic Software. Figure 2.1: The three different software layers on the highest abstraction level: Application, Runtime Environment, and Basic Software [9]. Application layer A basic design concept of the AUTOSAR software stack is the separation between application and infrastructure. In AUTOSAR, an application is composed of several connected SWC’s (SoftWare Components). These should be structured according to AUTOSAR’s definition and follow the constraints for the 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 5 important property of the SWC is that it should be atomic. This implies that only one instance of a certain SWC may exist in a vehicle, thus, an SWC is assigned to only one ECU. With this design, SWC’s are independent of the type of microcontroller the ECU is using, the type of ECU on which the SWC is executed and the location of other SWC’s that interacts with the current SWC. In order for an SWC to be able to execute and communicate with the AUTOSAR Basic Software, a run-time environment is needed. RTE All communication that occurs with an SWC and services and/or between an SWC with another SWC at the Application Layer is routed through the RTE. This holds for inter-ECU communication (communication between SWC’s mapped on the same ECU) as well as intra- ECU communication (using e.g. FlexRay, CAN, LIN, etc.). The main task of the RTE is to make SWC’s independent from the ECU on which they are mapped. As SWC’s are dependent on the type of application, the RTE has to be adapted for the specific ECU in which it serves. This is done by ECU-specific generation and configuration and leads to the fact that RTEs differentiate between different ECU’s. Basic software Basic Software is a standardized software layer and is further divided into different layers as shown in Figure 2.2. These layers are: Services, ECU Abstraction, and Microcontroller Abstraction. Figure 2.2: The layers of Basic Software: Services, ECU Abstraction, Microcontroller Abstrac- tion and Complex Drivers [9]. 6 The MCAL (MicroController Abstraction Layer) contains internal drivers and has the function of making the higher software layers independent of the microcontroller. The purpose of the ECU Abstraction Layer is to make higher software layers independent of ECU hardware layout. More specifically, it provides an API (Application Programming Interface) for devices and their connection to the microcontroller. The Service Layer is localized just underneath the RTE. It provides basic services for applications and Basic Software modules such as operating system functionality, diagnostic protocols, memory management, and communication services. AUTOSAR communication stack The layers of the Basic Software are further divided into modules, forming functional groups. One of these functional groups is the communication stack. The communication stack consti- tutes a part of the Basic Software reaching from the bottom connection with the microcon- troller, to the top connection with the RTE and SWC’s, see Figure 2.3. Figure 2.3: The AUTOSAR communication stack; Communication Drivers, Communication Hardware Abstraction, and Communication Services [9]. The communication stack is implemented according to the specifications of the communica- tion protocol used, e.g. FlexRay, CAN, LIN, etc. Figure 2.4 shows the communication stack for FlexRay. One portion of the communication stack is the communication services, which consists of three of the modules important for this project, namely FlexRay State Manager, PDU Router, and AUTOSAR COM. These are also shown in Figure 2.4. Beneath the commu- nication services lies the communication hardware abstraction layer. This is a protocol specific layer, consisting of the modules FlexRay Interface, and Driver for FlexRay Transceiver. 7 Figure 2.4: The AUTOSAR communication stack for FlexRay [9]. A message between the various modules is named differently depending on which module it is sent from. A PDU (Protocol Data Unit) refers to a data unit that is defined in the protocol for a certain module. It contains data of that module, SDU (Service Data Unit), with protocol information added. Thus, an SDU as seen from one module, is a PDU from a module localized above in the communication stack. The definitions of the different PDU’s are seen in Table 2.1. FlexRay Driver The FlexRay Driver abstracts FlexRay CC’s (Communication Controller), which is compliant to both the latest and earlier FlexRay specifications. All properties of a specific CC are made 8 Table 2.1: The definitions of the different PDU’s [9]. PDU Definition Description I-PDU PDU of an upper layer module, e.g COM, DCM etc. L-PDU PDU of the FlexRay Interface module N-PDU PDU of the FlexRay Transport Layer. It contains address infor- mation, protocol information and data (N-SDU) available through the FlexRay Driver module. Since different CC’s offers different hardware implementation features, a single FlexRay Driver module supports only one separate type of a FlexRay CC [10]. FlexRay Interface The purpose of the FlexRay Interface module is to provide a generally specified interface to the communication system for the upper layer modules, e.g. PDU Router and COM. However, this is limited to the transmission of data. The configuration of the Interface module depends on the communication bus. Since the configuration relies on specific features of the communication system. The FlexRay Interface does not access the hardware directly. It uses one or several FlexRay Driver modules to get access to the FlexRay CC(s). The same applies for the FlexRay Interface when accessing the FlexRay Transceiver(s), by using one or several FlexRay Transceiver Driver module(s) [11]. FlexRay Transport Protocol This module is localized just above the FlexRay Interface and underneath the PDU Router. The object with the FlexRay Transport Protocol is to segment and perform reassembly of PDU’s that are too large to fit in one L-PDU [12]. However, it is not required to use the FlexRay Transport Protocol in order to have a functioning AUTOSAR communication stack. This holds as long as the size of a message fits in a FlexRay frame, which can be up to 127 words or 254 bytes. The FlexRay Transport Protocol is not used within the scope of this thesis. PDU Router The function of the PDU router is to statically route I-PDU’s based on the I-PDU identifier. Thus, there is no occurrence of dynamic routing during run-time. Since the PDU router is generally specified [13], it serves in the same way irrespective of which communication protocol that is used, except for the name of the call-back functions used to the surrounding modules. The PDU router uses the modules COM, FlexRay Interface and FlexRay Transport Protocol for providing its services. 9 AUTOSAR COM Just as the PDU Router, the COM module has the same design independent of which com- munication protocol that is used [14]. Its main function is to provide an interface to the RTE, packing and unpacking AUTOSAR signals into I-PDU’s. FlexRay State Manager The function of the FlexRay State Manager is mainly to provide an abstraction layer to the AUTOSAR Communication Manager module [15]. Since the Communication Manager con- trols the states of all communication channels bounded to the ECU, and the fact that the module must be compliant with all type of AUTOSAR communication protocols, an abstrac- tion layer is needed. Together, the FlexRay State Manager and the FlexRay Communication Manager handles the process of starting up and shutting down the communication of a FlexRay cluster. In turn, the FlexRay State Manager does not access the FlexRay hardware directly, but rather through the FlexRay Interface module. 2.2 FlexRay FlexRay is a recent protocol for vehicle network communication. It was developed by the FlexRay Consortium from 2000 until 2010. The FlexRay Consortium does no longer exist, but the specifications of the latest release (version 3.0.1) are still available for download [16]. Core companies included in the FlexRay Consortium were BMW, Bosch, Daimler, Freescale, General Motors, NXP Semiconductors and Volkswagen. Because of increased demands within the vehicle areas: fuel efficiency, comfort and safety, more calculations and communication are needed. For a network system to be able to efficiently handle these demands, a faster and more reliable network protocol is required. FlexRay was developed to meet todays and future requirements. 2.2.1 Comparison with existing protocols The CAN protocol is one of the standard protocols in the vehicle industry [3]. It was offi- cially released in 1986 and was introduced to the market the year after. Today, CAN is the dominating communication protocol in vehicles, and is also used to manage operating rooms in hospitals, to control devices such as lights, tables, x-ray machines and patient beds. Other areas of use are laboratory equipment, sports cameras, automatic doors and coffee machines [17]. There are several advantages of the CAN protocol which have contributed to its suc- cess. CAN is inexpensive in the way that it provides the condition for ECU’s to rely on only one common interface to communicate with other devices in the system. Each device in the system is considered to be smart. Since each device has a CAN controller, all devices see the transmitted messages and can decide for themselves if a specific message is relevant or if it should be disregarded. Messages are sent on the common bus with different priorities. Thus, a message with higher priority will be sent first while a message with lower priority will be postponed [17]. 10 Another widely used standardized protocol is the LIN protocol. It was first released in 1999 by the LIN-Consortium, which expired in 2010. LIN is a single-wired serial communications protocol and is organized as one master and several slaves (up to 16 slaves). Nodes acting as slaves in a LIN network determines the master node, and do not bother about the remaining network configuration. The messages from the master device are broadcasted out on the network and there is no mechanism for collision detection. Advantages with the LIN protocol are that it is easy to use and it is cheaper than other protocols, for example CAN. LIN is not seen as a full replacement for CAN, but rather a good complementary to CAN where cost is prioritized over bandwidth [4]. The TTCAN protocol was first developed by Bosch in 2003 [5], with the aim to add syn- chronization between nodes to the already existing CAN protocol. Thus, its main purpose is to reduce latency jitter, which may be present in a CAN network even for nodes with high priorities. This can occur if another message is already in process for transmission or if some other message has higher priority also tries to get access to the bus. TTCAN serves as an additional layer to CAN and brings the ability of combining both time-triggered and event- triggered communication. An advantage is that it can easily be modified to be used on already existing CAN systems. A considerable drawback is that it lacks in reliability [18]. The aims with FlexRay are to provide communication that achieves high data rates up to 10 Mbit/s. It provides both time-triggered and event-triggered communication in comparison to CAN, which is an event-triggered based protocol. Also, it aims to provide a more fault-tolerant and redundant architecture [19]. Figure 2.5 illustrates the comparison between FlexRay, CAN, TTCAN and LIN in their relation to cost and bandwidth. FlexRay came in use for the first time in 2006 in BMW’s X5 car, with FlexRay version 1.1. Several more car models have been equipped with FlexRay during the last couple of years, such as BMW 5 and 7-series, Audi A8, Bentley Mulsanne and Rolls-Royce Ghost [20]. Figure 2.5: The difference between LIN, CAN, TTCAN and FlexRay in their relation to cost and bandwidth [21]. 11 2.2.2 FlexRay communication FlexRay provides both time-triggered and event-triggered communication in comparison to CAN, which is an event-triggered based protocol where nodes are allowed to make bus access depending on the priority-level for the event. With FlexRay, the communication between nodes must be precisely defined. This is achieved by allocating a specific time slot for a mes- sage within a communication cycle according to the TDMA (Time Division Multiple Access) method. A communication cycle is divided into a static segment, a dynamic segment, a symbol window, and a NIT (Network Idle Time) as shown in Figure 2.6. Figure 2.6: The different segments of a FlexRay communication cycle [22]. Static segment The static segment consists of statically configured time slots of equal length, thus each static slot consists of the same number of macroticks. A macrotick is a FlexRay timing unit, for further details see Section Timing Hierarchy. The number of macroticks per time slot is defined by a global variable for all participating nodes in the network. Time slots can be of different types, either a key slot or a non-key slot. A key slot is used by a node to transmit sync and startup frames. One or more key slots can exist in the static segment. Time slots that are non-key slots are used for transmission of frames on either one channel or both. Each node uses two slot counters, one for each channel, to facilitate the scheduling of trans- missions. At the start of a communication cycle the slot counters are set to the value one, and is incremented at the end boundary of each time slot. The number of static time slots are the same for all nodes in the network. These precisely defined timing characteristics of the static segment allows time-triggered communication between nodes. Since each frame transmission is defined to occur during an exact point of time, all participating nodes involved in that transmission have knowledge about when the transmission and reception of a frame will take place. 12 Dynamic segment The dynamic segment allows event-triggered communication between FlexRay nodes. A com- munication slot in the dynamic segment is called a minislot. In comparison to the equal length of transmitted frames in the static segment, a transmitted frame in the dynamic segment may be of different length. However, minislots in the dynamic segment contains an identical number of macroticks defined by a global variable for the network, just as for the number of minislots. There exist no sync or startup frames in the dynamic segment. Another feature within the dynamic segment is in the process of scheduling transmissions. A node uses one slot counter for each channel. They may, however, be incremented independently in compliance with the dynamic procedure of transmitting frames of different lengths. If no transmission takes place, the dynamic slot transmission phase consists of one minislot. If there is an ongoing transmission, then several minislots may compose a dynamic slot. The length of a dynamic slot depends on the transmitted frame size. The communication behavior in the dynamic segment can be described as asynchronous in which some frames are prioritized over others. This means that a node can use full bandwidth for a transmission, but it also means that frames with lower priority may not be transmitted within the current communication cycle. Symbol window The symbol window can be used for transmission of different symbols, for example a start up or a wake up symbol. A wake up symbol is used as a power management tool to wake up a node which is currently in sleep mode. The symbol window is not required in a FlexRay communication cycle. Network idle time The NIT is a phase that is used for calculation of clock divergence and clock correction between the nodes in the network. Also, other tasks are performed during this phase such as error handling and updating counters. Clock synchronization Since FlexRay is a time-triggered communication protocol all nodes in the network must have the same view of the time. This is needed because all nodes need to know when to send and when to receive data on the bus. This common view of time is called global time. As all nodes have their own clocks with different clock skew and offset, they have their own interpretation of the global time. This is why FlexRay needs a clock synchronization algorithm. The following text will introduce and explain how FlexRay handles time and clock synchronization [22]. 13 Timing Hierarchy FlexRay handles time in three different levels; the communication level, the macrotick level and the microtick level as illustrated in Figure 2.7. Microtick is the smallest timing unit, and the length of a microtick is defined as x number of clock ticks on the CC’s oscillator. The value of x is different on each node since they have different rates on their oscillators. The next level in the timing hierarchy is the macrotick, which has a length of y number of microticks. This structure is used by the clock synchronization mechanism to be able to make the time go faster or slower on the local node, this is described further in the next part. The macrotick is the smallest unit that the nodes try to synchronize with. With a cluster that has perfectly synchronized clocks, the nodes have exactly the same number of macroticks within the third timing level, the communication cycle. A communication cycle is built up by z number of macroticks, and if the clock synchronization is correct, all nodes in a cluster shall have the same cycle number at any given time. Figure 2.7: The timing hierarchy in FlexRay communication [22]. Clock calculation and correction The global time is not a time taken from a real clock, the global time is represented by visible events sent on the FlexRay bus. It is with these events the nodes can get a virtual interpretation of the global time. However, with this method there must be some requirements fulfilled to make it work. The majority of all local clocks need to act in a correct way. A correct local clock is a clock that does not deviate too much from all other clocks. The clock of one node shall not drift more than 0.15% macroticks from the global time. This means that the difference between the slowest and the fastest clock cannot be more than 0.3% macroticks. The event that is used for the time measurements is called sync frames. These sync frames are sent from several nodes that are selected as sync nodes. When a node receive a sync frame it compares the time of the arrival with the time of the expected arrival time. The 14 deviation of these times is stored for every cycle. The clock is corrected in two ways, rate and offset correction. Offset correction is done by scheduling the next execution earlier or later compared to what otherwise would have been the case. This is accomplished by adding or removing macroticks from the network idle time. To make the local clocks on the nodes “tick” in the same rate, microticks are added or removed within a macrotick. By doing this the node can correct its own clock without affecting the number of macroticks within a cycle, but still make the macroticks longer or shorter according to their own local time. 2.2.3 Frame format The FlexRay frame is composed of three segments, the Header segment, the Payload segment and the Trailer segment, see Figure 2.8 Figure 2.8: The segments and fields of a FlexRay frame. The frame is transmitted on the network with the Header segment first, followed by the Payload segment and last the Trailer segment. Header segment The header segment is composed of nine different fields, taking up five bytes of the frame altogether. The first five fields in the header segment, consisting of one bit each, are the reserved bit, the payload preamble indicator, the null frame indicator, the sync frame indicator and the startup frame indicator. The frame ID indicates the slot in which the frame should be transmitted and ranges from 0 to 2047, where a value of 0 indicates an invalid frame ID. A frame ID is used only once on each channel in a communication cycle. 15 The payload length defines the size of the payload segment. Since only seven bits are used for this field it has the payload size value divided by two, since the payload may consist of as much as 254 bytes. The header CRC (Cyclic Redundancy Check) contains error-detecting code that uses the fields: the sync frame indicator, the startup frame indicator, the frame ID, and the payload length to compute the CRC. The Cycle count contains the value of the cycle counter as seen by the transmitting node. Payload segment The Payload segment consists of 254 bytes of data. It is organized as 0 to 127 two-byte words, as indicated by the Payload length field, and therefore contains an even number of bytes. The first byte is identified as “Data0”, the second “Data1”, etc., increasing the number for each individual byte. Trailer segment The Trailer segment consists of one 24 bit CRC field. The CRC is computed over all the fields within the header segment and the payload segment of the frame. 16 Chapter 3 Development methods This chapter describes the hardware and software tools used in this project. Among these tools are the ODEEP platform with the on-chip FlexRay controller, flash and debugging devices and the Eclipse platform with a debugger plug-in. The tools were accessible from the very beginning of the project which facilitated the execution of the initial tasks in the working process. All software used was executed on Windows XP and Windows 7 OS (Operating System). 3.1 ODEEP ODEEP is the hardware platform used for testing and development. This platform is the only hardware targeted in this thesis and was provided by QRTECH AB. The platform has many features like CAN, LIN, Ethernet, I/O, and Micro SD-Card interface. The most important feature for this work is the two FlexRay interfaces that the ODEEP provides [8]. The ODEEP platform has a processor that is named MPC5567 and is produced by Freescale [23]. 3.1.1 FlexRay configurator To get FlexRay to work it is required to be able to set many parameters. This tool provides a graphical interface to be able to configure all parameters in an easy way. The tool gener- ates data structures for the AUTOSAR BSW modules the FlexRay Driver and the FlexRay Interface. The data structures are then used when the code is compiled to give the nodes the configured parameters [24]. 17 3.2 Development environment 3.2.1 Software environment The Arctic Studio open source development platform [25] with the Eclipse IDE for C/C++ Developers plug-in were used for code development. The Arctic Studio is based on the Eclipse platform. Therefore plug-ins for Eclipse are compatible with the Arctic Studio as well. The C/C++ Developers plug-in includes additional functionality to the platform such as an editor with syntax highlighting and code completion for C/C++, a debugger, a search engine, and a makefile generator. This environment is available to the public by the Eclipse Foundation via their homepage [26]. The hardware debugger, called GDB (GNU DeBugger) debugger, is included in this plug-in and was used to trace the execution of different configurations on the ODEEP platform. The GDB Debugger allows a user to modify the value of program variables and call functions independently of the predefined execution of the program. 3.2.2 Hardware environment This subsection explains which hardware components that were used and how they work. After reading this section it should be rather easy to be able the setup the system that was used in this master thesis. Components used were: • ODEEP QR5567 (hardware platform) • FlexRay Channels (two twisted pair cables) • USB Qorivva MPC55xx/56xx Multlink (named multilink) [27] • PEEDI (Powerful Embedded Ethernet Debug Interface) [28] • USB cables • Ethernet cable • PC As mentioned before, the ODEEP was used as a platform, and it is mostly the environment surrounding ODEEP that is interesting. Between the ODEEP platforms there are two FlexRay channels, each channel is a twisted pair cable. Here all communication between the ODEEP platforms was done. Of course, it is possible to extend the bus and add more nodes. The USB cable between the nodes and the PC’s was used to control the nodes. It is also here the nodes send information and printouts. With the configuration explained so far it is possible to have FlexRay communication and be able to control the nodes. To be able to load new software on the nodes two different flash programmers have been used. Two flash programmers were used because it was only possible to debug with the PEEDI flasher. Both of them are connected to the nodes with a JTAG interface but they have different connections to the PC’s. The PEEDI is connected through an Ethernet cable and can be accessed via a Telnet session. With this connection every PC on the local network can flash the connected node. The Multilink flasher was connected to a PC via a regular USB and the program eSys Flasher [23] was used to flash 18 the nodes. Figure 3.1 describes graphically how the environment was setup. Figure 3.1: The hardware environment setup. 19 Chapter 4 Implementation This chapter describes the implementation of the different AUTOSAR modules. It covers relevant data structures, functions, and included components in the Arctic Studio tools. 4.1 FlexRay Interface The implementation of this module was based on the AUTOSAR FlexRay Interface specifi- cation [11]. As previously mentioned, the FlexRay Interface module communicates with the FlexRay controller(s) indirectly through the FlexRay Driver module. It provides the following features for the upper layer AUTOSAR BSW modules [11]: • initialization • data transmission (sending and reception) • start/halt/abort communication • FlexRay specific functions (e.g. to send a wake-up pattern) • set operation mode • get status information • various timer functions 4.1.1 Interaction with other modules The FlexRay Interface achieves abstraction of the CC(s) and Driver(s) to the upper layer modules, by providing an abstract and unique index for each type of resource. This holds for all resources independent of what type of resource it is, where the resource is localized and how it is accessed. For example, the FlexRay Interface may provide a function pointer to an equivalent Driver’s API service. Such a function pointer is localized in a static configuration table, called container. So, whenever an upper layer BSW module passes an abstract index 20 to the FlexRay Interface, it retrieves the function pointer from a container. It then calls the corresponding lower layer BSW module’s API service via the function pointer and forwards the translated index in the API call. This mechanism is further described in the subsection 4.1.2 about controller initialization. FlexRay Transceiver Driver The different states of a FlexRay Transceiver are controlled by the FlexRay Interface via the FlexRay Transceiver Driver [29]. This is done by calling the function FrTrcv_Set- TransceiverMode. The function call is initially done by FlexRay State Manager. A FlexRay Transceiver module of AUTOSAR version 2 was available at the start of this project. It is compatible with a newer FlexRay Interface module. Thus, no new implementation of the FlexRay Transceiver Driver was needed. FlexRay State Manager As mentioned before, the FlexRay State Manager handles the startup and shutdown of the communication of a FlexRay cluster. This is done through the resources which FlexRay Interface offers to the upper layer modules. Since the FlexRay State Manager did not exist in AUTOSAR version 2.0, an implementation of the basic parts of FlexRay State Manager was done during this project. The most fundamental structures in the FlexRay State Manager are the state machines. There is one state machine for each FlexRay cluster. The different states are mapped to the POC (Protocol Operation Control) states for a specific CC. Examples of some of the states are FRSM_READY, FRSM_WAKEUP, FRSM_STARTUP and FRSM_ONLINE. For further explanations of the state machine see specification [15]. 4.1.2 Main function and initialization The main function of the FlexRay Interface, FrIf_MainFunction_, is called once for each loop of a certain task. The time interval between the Main Function calls depends on the length of the FlexRay cycle. Because the FlexRay cycle length may differentiate in its configuration between different FlexRay clusters, the Main Function calling period may be of different length between two FlexRay clusters. The task, responsible of calling the Main Function, is defined in the BSW Scheduler module. There must exist one Main Function for each FlexRay cluster. Since the use of several FlexRay clusters is outside the scope of this thesis, only one Main Function was implemented. The purpose of the Main Function is to monitor and control the FlexRay Job List Execution Function, which is further described in the upcoming subsection 4.1.4. Initialization of the FlexRay Interface is launched by the AUTOSAR ECU State Manager by calling the function FrIf_Init. The State Manager passes a pointer to the address of the static configuration structure of the FlexRay Interface module. FrIf_Init makes sure that the configuration is made available to all functions within the FlexRay Interface module. It 21 also initializes the local memory space used for storing PDU data, PDU properties and state variables for the FlexRay Interface State Machine. Controller initialization is done through the function FrIf_ControllerInit. This function is a typical example of how FlexRay Interface wraps the corresponding FlexRay Driver API function. The mechanism performs the following two steps: 1. Translation of the static configuration of the FlexRay CC index, to a FlexRay Driver specific CC index. 2. Based on the retrieved CC index, find the appropriate FlexRay Driver and call the corresponding FlexRay Driver API function. The mechanisms for all FlexRay Driver wrapping functions are similar to this example. The difference between them lies in what resource data type is being retrieved. For a better understanding of how this is performed, the code for FrIf_ControllerInit is presented in Listing 4.1. 1 /* Pointer to main configuration, set by FrIf_Init */ 2 static FrIf_ConfigType const *FrIf_ConfigCachePtr; 3 4 Std_ReturnType FrIf_ControllerInit(uint8 FrIf_CtrlIdx) { 5 6 FrIf_IdxConfigType const *MyIdxPtr; 7 8 /* 1) Translate to Driver Idx using FrIf Idx */ 9 MyIdxPtr = &(FrIf_ConfigCachePtr->FrIf_IdxConfigPtr[FrIf_CtrlIdx]); 10 11 /* 2) Call corresponding Driver Init-function, passing correct config struct */ 12 Fr_ControllerInit(MyIdxPtr->FrCtrlIdx, MyIdxPtr->FrLowLevelConfSetIdx, MyIdxPtr->FrBufConfSetIdx); 13 14 } Listing 4.1: Part of the code for the function FrIf_ControllerInit 4.1.3 FlexRay Job List The Job List data structure is simply a list containing the predefined FlexRay communication jobs. The different jobs are sorted after their execution start time. Each job is scheduled according to which FlexRay cycle and the macrotick offset within a FlexRay cycle, in which the job should start its execution. A job may have one or several Communication Operations. Table 4.1 shows the different Communication Operations available in the AUTOSAR release 4.0. FrIf_JobListExec_ This function is rather to be seen as an ISR (Interrupt Service Routine), linked to the FlexRay CC. This holds if the CC does not guarantee an asynchronous buffer access. If the CC can 22 Table 4.1: The different Communication Operations. Communication Operation Description DECOUPLED_TRANSMISSION Decoupled Transmission PREPARE_LPDU Prepare message buffer of CC RECEIVE_AND_INDICATE Immediate reception RECEIVE_AND_STORE Decoupled reception RX_INDICATION Reception indication TX_CONFIRMATION Transmission confirmation guarantee asynchronous buffer access, the Job List Execution Function can be executed in a regular OS task. Just as the Main Function, there must be one Job List Execution Function for each FlexRay cluster. The main task for the Job List Execution Function is to execute the configured Jobs, defined in the FlexRay cluster’s Job List, at specific points in time. Thus, the execution of jobs must be synchronized with the global time of the FlexRay network. 4.1.4 Data transmission Three modules are active and interact with each other during a data transmission. These are the FlexRay Interface, the upper layer BSW module, which is PDU Router in this case, and the lower layer BSW module, the FlexRay Driver. FrIf_Transmit Whenever the upper layer BSW module wants to request a transmission of a specific PDU, it calls the FrIf_Transmit function. The function call passes the unique PDU ID together with a pointer to the data of the PDU. FrIf_Transmit then accomplishes one of two things depending on the configuration of the PDU. The PDU can be configured for either decoupled transmission or immediate transmission. If a decoupled transmission is desired, the PDU is not yet passed to the underlying FlexRay Driver. Instead, the FlexRay Interface remembers the PDU’s transmission request by incre- menting a counter. This means that the upper layer BSW module may call FrIf_Transmit whenever desired, asynchronously of the FlexRay communication system. It also implies that the upper layer BSW module must buffer the PDU data and be able to copy the data to the right location when a transmission interrupt has been obtained. When the PDU has been configured for immediate transmission, the FlexRay Interface simply passes the PDU to the FlexRay Driver module at once. However, one requirement must be fulfilled in order to use an immediate transmission. The upper layer modules must be synchronized to the FlexRay communication schedule, so that when a transmission is desired, the data will be available during the intended time slot. For such a setup, the overhead of decoupled transmission in FlexRay Interface is not needed. 23 Transmit with decoupled buffer access FlexRay Interface supports decoupled transmission by queuing transmit requests from the up- per layer BSW module. This is done when FrIf_Transmit has been called. The remainder of the communication operation execution is done by the Job List Execution Function. Since a FlexRay frame may hold several PDU’s, the Job List Execution Function firstly iterates over these to check whether it is queued and ready for transmission. If that is the case, a call to the upper layer’s