Civil Engineering Reference
In-Depth Information
content-based and time-based dependencies can lead to a large number of possible
errors, some of which can be difficult to reproduce. In sectors such as the automo-
tive industry, CAN systems are sold in products that are built in large quantities but
then used in highly customized ways. For this reason, customers sometimes experi-
ence exotic errors, which can result in high costs (e.g. for product recalls). Reputa-
tional damage is also a risk, as a number of striking examples from the automotive
industry have shown. Beyond the economic impact of undetected errors, safety is
also a consideration. With the increase in distributed functions, safety aspects are of
increasing importance.
Comprehensive testing is therefore indispensable. The functionality of any CAN
network needs to be tested under all the different conditions in which the system
will later operate. It is also important to check ECU behaviour in error situations as
well as inconsistent states, e.g. when protocol specifications are violated. It is often
precisely such theoretically “impossible” cases which lead to particularly unpleas-
ant problems in practical operation. For this reason, it is important that the ECU
reacts as defined in all situations.
Typical test scenarios are aimed at stimulating the ECU and then observing and
interpreting its reactions. This generally requires at least a partial simulation of the
ECU's environment. For instance, it is rarely possible to operate ECUs on a CAN
bus without functioning NM. Similar conditions apply to hardware inputs and out-
puts. Actuators and sensors are partially checked by the ECU. When such a check
fails, the ECU enters an error state. Sensor/actuator inputs/outputs therefore need to
be addressed correctly in every case.
Errors that are difficult to reproduce are often caused by time-based dependen-
cies. A specific software error may only appear after specific events occur in a very
specific sequence. The test system therefore needs to be able to reproduce time
sequences and constraints (e.g. cycle times) in exactly the same way as these would
occur in reality. However, it should also be possible to create erroneous or unrealis-
tic states in a targeted and reproducible way.
As a broad preventative measure, testing is required from the earliest develop-
ment phases. This is because it is far more cost-effective to detect, analyse and
eliminate errors in earlier development phases than later on in the development
process. The large number of possible system states, combined with the need to
maximize the utilization of available bandwidth for efficiency reasons, means that
tests can be significant in scope. The only efficient way to handle such large-scale
testing requirements is to use automated test sequences.
6.6.2
Testing Methods
6.6.2.1
Protocol Tests
Communication at message level is tested using the so-called protocol tests. Such a
test does not use the abstraction layers available in the tester (which, e.g. represent
signals on messages and ensure cyclical message transmission); rather, it communi-
cates directly with the ECU SUT.
