Evaluation of protocols for automotive systems
Michael Waern, Martin Törngren · 2003
Today a Scania truck has more than 20 built-in microcomputers. These are connected to a network and control many of the trucks functions. The vehicles are developed in that way because they can be more advanced when computers control the vehicles functions instead of mechanic. This use of computers in the trucks lead to increased requirements for fast and predictable computer communication. Scania announced this master thesis with background of this. The objective for the thesis is to find a protocol that can replace the CAN communication protocol that Scania uses today. A literature study showed that there are mainly three communication protocols: TTP/C, FlexRay and TTCAN that can be interesting for this application. A deeper investigation showed that FlexRay has the best potential to be the future protocol. FlexRay is developed by a consortium started by big companies like BMW, Bosch, DaimlerChrysler och General Motors among others. The protocol is still in the prototype phase, which means that its properties has not been tested and verified officially. If the consortium develops a protocol that has the properties declared, it will probably be the next standard in the vehicle industry. When the protocols were examined, the possibility to build a test-platform based on the protocol was also evaluated. FlexRay would have been the most interesting protocol to examine in a test-platform. But the examination showed that FlexRay equipment is not available for other than members of the consortium and Scania is not interested in becoming a member at this time. The TTCAN protocol was used instead. This is not a bad alternative, since TTCAN has the same properties as FlexRay in many aspects. Scania also uses CAN today, which is the protocol that TTCAN is based on. The tests on the test-platform showed that when the TTCAN protocol is used, messages are not delayed on a heavy loaded bus in the same way as when an unsynchronised CAN protocol is used. This indicates that TTCAN’s synchronisation and scheduling works well. The tests also showed that a system with mixed TTCAN and CAN nodes does not work well, for the reason that messages in the TTCAN schedule that are blocked by unsynchronised CAN messages are not sent at all. This also indicates what happens when a TTCAN node loses synchronisation and starts to send messages at the wrong time or if a transient disturbance affects the bus at the time when a message is going to be sent. Nodes that send messages at the wrong time are a problem for time-synchronous protocols in general.