Nowadays in automotive technology it is not enough in certain cases if only one central controlling unit (CCU) is included in a controlling system. Sometimes it is needed to relieve this central unit (CU) so a second CCU is included beside the main controlling unit. In this case some functions can be executed by the second CCU.
But an automatic transmisson control unit (TCU) of a car is a safety relevant embedded system so it is needed to test roundly as many of its functions as possible directly after the production to be sure that all hardware functions of the device, which is going to be built in the target system, work properly. But minimalization of costs is in the massproduction a requirement. That is why we can communicate with the TCU only through the main central controlling unit which communication goes on CAN bus. So the second CCU can be achieved through the main CCU only. It means that tests on the second unit can be executed only this way.
My aim was to develop a software wherewith not only certain hardware functions of the main central controlling unit could be tested but also some functions of the second CCU (given in the software specification) through the datalines between the two units and information will be available about the state of these functions as well.
First of all I will summarize some difficulties of hardware testing of embedded systems then describe the testing process to validate these devices. After these the target device with the two central controlling units will be in the focus, and through the comparison of some communication protocolls I will explain which reasons lead to use of these solutions were choosen at designing.
Then I will describe the specification of the software functions I had to implement and steps of the development flow and the problems, which were come forward during the development, and its solutions. After that I will show you how I tested the software. And finally I will review my work and sum up which improvements could be made in the future.