Abstract

The FlexRay Transport Protocol (FrTp) is designed to support reliable and efficient communication between various computers embedded in vehicles. It uses a standardised FlexRay communication bus and introduces a go-back-N style retransmission algorithm. A formal modelling language, Coloured Petri nets (CPN), has been applied to verify the protocol design. Separate CPN models of the FrTp service and protocol are developed and with state space analysis-used to prove for selected configurations that FrTp is deadlock-free and conforms to the service specification when transferring a single-protocol data unit from sender to receiver. In addition, closed-form solutions relating the state space size, retransmission limit, and number of segments are found, giving increased confidence that FrTp is error-free, even for configurations where the state explosion problem arises.

Highlights

  • Vehicles today may contain nearly 100 embedded computers, or Electronic Control Units (ECUs), that together control the engine, airbags, suspension, seats, as well as provide information to other on-board devices and users [1]

  • The Run Time Environment (RTE) are a set of Automotive Open Systems Architecture (AUTOSAR) services, and corresponding hardware abstractions and drivers, that will be commonly used by multiple software applications, thereby avoiding the need to be implemented in each component

  • Results from the state space and language analysis have been collected for a range configurations

Read more

Summary

Introduction

Vehicles today may contain nearly 100 embedded computers, or Electronic Control Units (ECUs), that together control the engine, airbags, suspension, seats, as well as provide information to other on-board devices and users (e.g., telephone and entertainment systems) [1]. For the former, FlexRay [2] is a potential replacement for Controller Area Network (CAN), a bus for inter-ECU communication in many vehicles today For the latter, automobile manufacturers are developing the Automotive Open Systems Architecture (AUTOSAR) [3] to allow software components to communicate irrespective of the ECU or bus technology (FlexRay, CAN) that is in use. The RTE are a set of AUTOSAR services, and corresponding hardware abstractions and drivers, that will be commonly used by multiple software applications, thereby avoiding the need to be implemented in each component These include services for memory management, communications, and I/O, as well as device-specific drivers for the microcontroller and sensors/actuators. The microcontrollers of each ECU communicate via one of the possible bus technologies

Results
Discussion
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call