CERMcity

Within the scope of the sub-project "CERMcity - FVP" an existing vehicle of the DFKI RIC is extended to a vehicle validation platform (FVP) with autonomous functions. The aim is to provide a dynamic platform in addition to the static urban test environment, which can be used within the scope of the pilot validation and within the scope of the trial operation. Building an FVP is a very important aspect of the project so that potential users of the urban test environment must not equip and commission their own vehicle platform, but can concentrate on their core work (for example, sensor development, algorithmic developments).

When using a vehicle as a validation platform, three prototypical applications are to be distinguished:

1. The system to be validated provides data, for example, an environmental sensor to be validated. In this case, the validation platform must provide the possibility of data recording and, optionally, a functional data link (for example, an autonomous vehicle control using the sensor data).
2. The system to be validated requires data, for example an Advanced Driver Assistant System (ADAS) to be validated, such as an optical / acoustic distance warning system. In this case, corresponding sensor equipment is to be provided by the validation platform.
3. The combination of the first two cases, such as a data fusion system or autonomous vehicle control.

In all three cases, the validation system must also record test data, reproduce different driving behaviors reproducibly, and, in particular, provide a "ground truth" by means of infrastructure sensors, as well as a variant of software to be validated and hardware to be validated.

Various points have to be taken into consideration when developing a suitable autonomic function for the vehicle platform. For example, good reproducibility is important for most applications. In addition, the autonomous vehicle control must respond appropriately to the (possibly validatable) sensor outputs. Thus (at least optional) the sensor output should be used directly and not be filtered, checked for plausibility or corrected. In this case, however, a malfunction of the device under test (DUT) to be validated must, of course, be intercepted if a threat to the urban test environment, other vehicles and / or the vehicle validation platform itself has to be prevented.