Open jdsika opened 7 months ago
Imho we must distinguish between different classes of boundaries:
The model boundaries are strictly restrictive (i.e., moving outside these boundaries causes runtime errors due to singularities or unexpected physical behaviour), for instance "the model MUST be instantiated from standstill", "the model MUST NOT be used for reverse drive", etc. --> model boundaries should be moved to the future specification
The model boundaries represent permissive behaviour (i.e., moving outside these boundaries is possible from runtime point-of-view, but is not supported due to the modeling approach), for instance "the sensor model does not support identification of static objects", "the model does not support accelerations above 0.4g" --> model boundaries could be stated in the documentation (up to discussion)
Validated model boundaries (i.e., the boundaries have been validated in the test pipeline, for example by comparing them to reference data) should be added as extra information in the documentation, like "the model supports velocities from 0 to 130 km/h (Credibility Level 2)"
The readme contains the requirements regarding the documentation of the model. Currently the boundaries in which the model is allowed to operate and its limitations are not described.