Civil Engineering Reference
In-Depth Information
Fig. 6.15
Basic sequence for protocol tests
Protocol tests are generally set up in the following way: The tester stimulates the
SUT by sending it a message or message sequence and waiting for the reaction. The
test program then checks whether the observed reaction matches the expected one.
Depending on the reaction received, the tester then sends another stimulation, waits
for a further reaction, checks this reaction, etc.
Individual stimulations and reactions can also consist of input/output (I/O) op-
erations, e.g. activation of an ECU output line. Test sequences can also contain
complex conditions and operations. Such a “ping-pong” exchange of actions and
reactions, where the tester examines each of the SUT's reactions, is a typical char-
acteristic of this test concept (see Fig.
6.15
).
A typical use case for a protocol test is to check the ECU's transport protocol
implementation. In this type of test, data items of varying length that are distributed
across various messages (CAN frames) are sent to the ECU. The ECU's reaction
reveals whether it received and interpreted the message sequences correctly. This
also applies in the opposite direction, where the ECU is made to transmit segmented
messages. The test system can also send erroneous message sequences in order to
interpret the ECU's reaction to these.
Test sequences and check conditions are very tightly interwoven. Test sequenc-
es replicate the specified behaviour of the SUT very precisely in order to check
whether the SUT behaves in the specified manner. Because the test program itself
implements the communication protocol, it can generate exceptional situations and
test the SUT's reaction to these. Beyond testing simple protocol sequences, it is also
possible to test message contents and timing conditions.
Complete implementation of such protocols within a TC does, however, require
a degree of effort when creating the test sequence. Furthermore, the tight linkage
