Parts of the efficient, systematic test method and the efficient test case generation will be demonstrated by the case study of the constriction assist.
The constriction assist has been developed in the research project UR:BAN. The assistance system supports the driver by the lateral guidance in the situations of narrowed lanes, e.g. road works, or “when passing vehicle platoons in neighboring lanes, fixed obstacles, or parking cars. A warning is given if the constriction is too narrow to pass through”. The system is developed for urban traffic (Scholl2015).
The driver assistance system will be tested in a roadwork scenario. One typical scenario in road works, which are derived from the standards and guidelines, is the drive through a chicane. Figure7.12illustrates one possible configuration of such a chicane. The standards and guidelines provide a standardized range of ratios between the length and the lateral offset of the chicane. A ratio of 1:10 means that the length of the chicane has to be 35 m, if the lateral offset is 3.5 m. Furthermore, the lateral offset, the type of the roadwork elements, the distance of the roadwork elements to each other, and the lane width within the chicane have to be defined to generate a scenario in a road works.
These parameters are identified through an analysis of the standards and guide- lines for road works in Germany (FGSV 2009). However, the standards and guidelines provide no concrete discretization steps for these value-continuous
Fig. 7.12 A roadwork scenario for the constriction assist
parameters for a test case generation. Only minimal and maximal allowed values are provided in the standards and guidelines for instance the minimal allowed lane width in road works is 2.5 m. The values have to be discretized for the test case generation with the method of the efficient, systematic test case generation.
First, equivalence classes are generated for the impact parameters. The minimal and maximal allowed values in the standards and guidelines are also the minimal and maximal boundaries in the equivalence classes.
For the lane width, the minimal allowed value is 2.5 m. Therefore, this value is also the lower boundary of the equivalence class. The upper boundary is 3.75 m, because this is the maximal possible lane width according to standards in Germany.
Between the minimal and maximal value, the values are linear interpolated by 0.25 m within the class. With these steps, all typical lane widths in road works and cross sections are covered (FGSV1996,2009).
The generation of an equivalence class for roadwork elements is trivial, because only three kinds of elements in road works exist in Germany (FGSV2009). These are traffic beacons, cones, and concrete barriers.
The lateral offset of the chicane is based on the typical lane width of 3.5 m in Germany. It will be assumed, that the lateral offset of the chicane is a multiple of the typical lane width in Germany and the lane is always swiveled by complete standard lane widths. Intermediate values are not tested with a remaining risk that a failure occurs for these values.
The distance of roadwork elements are also derived from the standards and guidelines. Here, the provided distance lies between 5.0 and 10.0 m in urban environments (FGSV 2009). To test also road works, which are not correctly constructed to the standards, the distance range is extended up to 13.0 m. The range between 5.0 and 13.0 m is again linear interpolated by the distance of 2.0 m in the first iteration of the test method.
The ratio between the lateral offset and the length of the chicane is also provided in the standards and guidelines (FGSV 2009). Here, the standards provide a ratio between 1:10 and 1:20 for the chicane. To test the system also outside of the standards, the values of 1:5, 1:7, and 1:25 are introduced. Additionally, the value 1:15 is introduced to interpolate between the provided values. With these values, invalid and valid equivalence classes can be generated to test the system boundaries.
Table7.5shows the identified parameter values for the scenario.
Table 7.5 Identified parameter values for the scenario Impact Parameter Parameter values
Lateral offset [m] 3.5 7.0 10.5 14.0
Ratio lateral offset/length 1:5 1:7 1:10 1:15 1:20 1:25
Roadwork elements Traffic beacons Cone Concrete barrier Distance roadwork
elements [m]
5 7 9 11 13
Lane width [m] 2.50 2.75 3.00 3.25 3.5 3.75
On the basis of the identified parameter values, a test suite is generated with the combinatorial algorithm IPOG (Lei et al. 2008). A pair-wise test coverage is chosen to analyze the main effects of the parameter values. With this configura- tion, the algorithm generates 36 test cases. Table7.6 shows all these test cases
Table 7.6 Generated test suite on the basis of the identified parameter values Test
case
Ratio of lateral offset and length
Lateral offset [m]
Roadwork elements
Distance of roadwork elements [m]
Lane width [m]
1 1:5 3.5 Traffic beacons 5 2.50
2 1:5 7.0 Cone 7 2.75
3 1:5 10.5 Concrete barrier 9 3.00
4 1:5 14.0 Traffic beacons 11 3.25
5 1:5 3.5 Cone 13 3.50
6 1:5 7.0 Concrete barrier 5 3.75
7 1:7 10.5 Traffic beacons 7 2.50
8 1:7 14.0 Cone 9 2.75
9 1:7 3.5 Concrete barrier 11 3.00
10 1:7 7.0 Traffic beacons 13 3.25
11 1:7 10.5 Cone 5 3.50
12 1:7 14.0 Concrete barrier 7 3.75
13 1:10 7.0 Traffic beacons 9 2.50
14 1:10 10.5 Cone 11 2.75
15 1:10 14.0 Concrete barrier 13 3.00
16 1:10 3.5 Cone 5 3.25
17 1:10 3.5 Traffic beacons 7 3.50
18 1:10 3.5 Traffic beacons 9 3.75
19 1:15 7.0 Concrete barrier 11 2.50
20 1:15 10.5 Traffic beacons 13 2.75
21 1:15 14.0 Cone 5 3.00
22 1:15 10.5 Concrete barrier 7 3.25
23 1:15 7.0 Concrete barrier 9 3.50
24 1:15 3.5 Cone 11 3.75
25 1:20 14.0 Cone 13 2.50
26 1:20 3.5 Concrete barrier 5 2.75
27 1:20 7.0 Traffic beacons 7 3.00
28 1:20 10.5 Concrete barrier 9 3.25
29 1:20 14.0 Traffic beacons 11 3.50
30 1:20 10.5 Cone 13 3.75
31 1:25 7.0 Traffic beacons 5 2.50
32 1:25 14.0 Cone 7 2.75
33 1:25 3.5 Concrete barrier 9 3.00
34 1:25 10.5 Cone 11 3.25
35 1:25 10.5 Cone 13 3.50
36 1:25 14.0 Traffic beacon 13 3.75
in the test suite. Every pair of parameter values is tested in at least one single test case.
The test suite is created with the aim to generate efficient test cases. The efficient test cases have to be non-redundant, representative, unified, and reproducible.
Due to the analysis of the standards and guidelines and the identified parameters, the test cases are representative for the constriction assist. There is a risk that parameters exist apart from the identified parameters, which are also representative for the system, but not coverable through the standards and guidelines. The test suite is currently lacking these test cases. To identify these test cases, additional sources next to the standards and guidelines, like experts, should be consulted in the step of the analysis.
Due to a combinatorial test case generation and apair-wisecoverage, every pair of parameter values is presented by one single test. With this test suite, all test cases are non-redundant, because no scenario is tested twice. Due to the pair-wise coverage, faults can be detected, which are depending on two values. Faults depending on three or more parameter values cannot be detected with this test suite. Therefore, a3-wiseort-wisecoverage would have to be generated.
The test cases are based on the unified 4-level model for scenarios. On the first layer, a straight line is defined as the basic road. The roadwork is defined on the second level of the model. For testing the roadwork scenario on a new basic road, only the first layer has to be modified. Thus, new test cases can be generated flexibly by varying the single levels of the 4-level model.
Due to the static scenario without dynamic objects, the test cases are reproduc- ible, because no non-deterministic element is part of the scenario. The reproduc- ibility of the test cases with dynamic objects cannot be demonstrated in this case study. In Symkenberg (2015), the reproducibility of scenarios with dynamic ele- ments is demonstrated in different scenarios with the presented control of the dynamic elements.