PSI - Issue 38
Florian Grober et al. / Procedia Structural Integrity 38 (2022) 352–361 Grober, Janßen, Küçükay / Structural Integrity Procedia 00 (2021) 000 – 000
356
5
4. Heuristic algorithm In order to meet the requirement of load monitoring, the driver guidance system must be connected to appropriate measuring devices that record the loads during the test drive. For consistency reasons and for the transfer of general driving values in load values, these devices are favorably vehicle-internal standard sensors, which are also used to collect customer field data. The signals can typically be received via CAN bus (CAN: Controller Area Network). By means of their permanent recording as well as calculation of resulting load spectra in regular intervals, the ‘ actual test level’ is determined and incremented. The ‘ actual test level ’ summarizes the so far endured loads and forms the basis for the computation of the optimal further test route. Since an analytical calculation of the optimal route is not possible due to the complexity of the task, a heuristic algorithm was developed instead. It works successively and determines the best following edge for the next node to be reached. Figuratively, this means that a decision for a turning option (driving straight-on is also understood as a turning option) after reaching the next road section center is made. For this purpose, the subsequent edges are weighted according to their expected loads from the experience database. In the calculation of the weighting factors the following criteria are used taking into account the actual test level and the target load spectra: How many missing load cycles are expected on the edge ( ‘ missing ’ means in this context that they are part of the target spectra but have not occurred so far)? Are very high loads expected which are rarely achieved elsewhere? Since the resulting formulas are very extensive, their detailed presentation is omitted here for reasons of space. In order to plan ahead, it is reasonable to include multiple subsequent turning possibilities in the calculation of the weighting factors. Thereby, for example, the access to particularly suitable edges can be selected, although the access road itself only produces very few loads. For subsequent turning possibilities the same weighting criteria are considered but their influence is downscaled with increasing distance. Since every path of subsequent turning possibilities must be calculated individually, only a limited network depth can be considered due to increasing branching. The calculated weighting factors form the basis within the decision-making process for the selection of the next edge to be travelled. However, not the highest weighting is chosen, but instead a random experiment is carried out. The selection probability within this random experiment correlates with the weighting. This leads to more variability in the testing route and to an approximately same chance of selection for turning possibilities with nearly similar expected loads. On the other hand, edges with inappropriate loads are less likely to be chosen. Within the calculation of the selection probability, it can be considered whether an edge possesses sufficient data in the experience database. If this is not the case, a preferred selection is useful to fill the experience database and generate better planning options in the further test drive. The random experiment can be illustrated by an urn containing balls for each turning option. The number of balls per turning option corresponds to the selection probability. By randomly drawing one of them, the decision for the next edge is made. Fig. 3 illustrates the decision process schematically. The procedure is repeated at each node until the target load spectra are reached within a tolerance limit. Are types of loads expected which are more relevant for the test than others? Are types of loads expected which are underrepresented in the actual test level? How much effort (especially time) is required to travel the edge?
Made with FlippingBook Digital Publishing Software