Automatic testing plan for crypted communication protocol

In the automotive industry, one can observe an impressing increase of electronics presence which is reflected in the presence of Electronic Control Units (ECU) and the communication protocols that connect these. Furthermore, the introduction of large numbers of sensors to provide driver assistance applications and the associated high-bandwidth requirements of these sensors have accelerated the demand for faster and more flexible network communication technologies within the vehicle. One of the latest technologies to overcome this issue is CAN-FD, a new release of the well-known communication protocol CAN. The latter was invented and commercialized by Bosch GmbH in 1982, while CAN-FD was released in 2012. This work was conducted in collaboration with the french branch of Bosch GmbH, in the site of Saint-Ouen. The goal of this project is to develop automatic tests for the CAN-FD. Following the Open Systems Interconnection standard, we can say that this work covered the testing of the data link layer of this communication protocol for the OEM Renault Nissan. In the first phase of the project, the testing plan was designed and developed starting from the system requirements of the OEM. These requirements were to be applied to the CAN-FD frames (i.e. the primary message format). The requirements were divided into TX requirements, those for the frames sent by the ECU under test, and RX requirements for the frames sent in the other direction. Since automatic testing was already developed and applied to CAN, it was convenient to re-use and adapt the existing testing plan for CAN to the new protocol. CAN and CAN-FD have several differencies and the most remarkable are: 1. the possibility of changing the data-rate of transmission and the consequent improvement of throughput; 2. the different length and structure of the data field, i.e. the part of the frame where the message is transmitted without considering all the synchonization and control part, 3. the presence of a crypted authentication system for certain frames called MAC/ARC. The second aspect is the most important aspect to deal with when adapting the already existing CAN testing plan to the CAN-FD. The testing plans were realized and run on the tool ECU-TEST by TraceTronic. Here, for each of the testing requirement, a test package was written. The student was in charge of adapting and developing new test packages, by writing python scripts to be inserted during the stimulation and/or analysis phase. During the second phase of this project, the job of the student was to make the generation of the whole set of frames automatic. This was done by developing a workflow on the internal tool Testflow. The workflow was supposed to: • take and analyse several description files, • extract the frames to test, • divide those into groups for specific properties, • generate the complete testing plan on ECU-TEST, including configuration files and links. For this task, the student had to write, for each of the step above, several scripts in QVTO language, a model transformation language, conform to Meta-Object Facility (MOF) 2.0 metamodels. The third phase of the project was to build the test plan for the validation of the authentication system MAC/ARC. The student developed another ECU-TEST package for it, with another python script aimed to compute the expected authentication code, following the AES-CMAC algorithm, and comparing the result with the received one.