Method for verifying applications of a navigation module

Abstract

A method for approving the application of a navigation module (1) for a safety level, wherein the navigation module (1) has at least one GNSS module (2) for measuring navigation data as input data for navigation in a motor vehicle (3), and the method comprises the steps of: a) receiving application data related to the application; b) receiving application-related test data, the test data being measured during testing in a vehicle (3) including the applied navigation module (1); c) creating a large number of test scenarios (4) for the application using a Monte Carlo method based at least on the application data and the test data; d) performing tests on the application based on the test scenarios (4) created in step c); and e) granting approval to the application based at least on the results of the tests performed according to step d).

Description

Technical Field

[0001] The present invention particularly relates to a method for demonstrating the intended integrity risk of a location created using a navigation module in the application of a navigation module.

[0002] This invention relates to the quality verification and validation of a high-precision navigation module (also known as a vehicle positioning system) for vehicles, which is designed to determine the position of a vehicle, for example, with an accuracy in the centimeter range. Background Technology

[0003] Running such navigation modules requires fusing data from various sensors. This is the only way to achieve the required high-precision positioning (also known as location determination). Sensor fusion algorithms must be redeveloped and adapted for the specific application of the navigation module in a particular vehicle type, because even small differences between the sensors whose data to be fused, as well as the specific environment of each sensor in the corresponding vehicle type, can have a significant impact on positioning and its accuracy.

[0004] Such navigation modules are designed for use in automated driving or advanced driver assistance systems, such as activating / deactivating automated driving functions, safe parking operations, or SAE Level 3 and above lane keeping assist. High-precision navigation modules typically include a GNSS (Global Navigation Satellite System) receiver, a high-performance inertial measurement unit (IMU), and wheel speed sensors (WSS) to meet performance, availability, and safety requirements. Furthermore, these modules process GNSS correction data and integrity information from a global GNSS reference network. These high-precision navigation modules typically require collaboration with other sensors connected to the vehicle to determine high-precision positioning. Therefore, in automotive applications, these high-precision navigation modules are often difficult to distinguish from other vehicle components.

[0005] Such navigation modules typically require certification according to the ISO 21448 standard for their applications. ISO 21448 is the standard for Road Vehicles' Expected Functional Safety (SOTIF). According to this standard, the navigation module must be demonstrated to reliably prevent unidentified erroneous positioning. In this context, if the positional error exceeds a preset limit, the positioning result is considered erroneous.

[0006] The primary signals associated with SOTIF are the fused location and its corresponding protection level (also known as the protection level PL). This protection level can be represented by an ellipse around the defined location. The protection level indicates the probability that the actual location lies outside the ellipse. The higher the protection level, the lower this probability. The elliptical shape of the protection level is typically due to a slightly higher degree of positioning unreliability in a particular direction of vehicle movement (usually along the driving path), which is generally permissible. Therefore, the protection level defines an upper limit to the statistical error for the fused positioning solution, thus reflecting the positioning unreliability. The purpose of the method described herein is to demonstrate the required integrity risk, which users of the positioning solution can leverage for risk analysis of systems using the solution.

[0007] The goal of SOTIF classification is to enable users of positioning solutions (such as autonomous or highly automated driving systems in motor vehicles) to easily identify and classify the safety of positioning solutions based on SOTIF classification, and to conduct risk analysis on systems using these positioning solutions. The following parameters are specified: Alert Limit (AL): The "Alert Limit" defines the position error tolerance. This tolerance value must not be exceeded; otherwise, a signal will be sent at the navigation module output indicating a loss of integrity. Time to Alert (TTA): The Time to Alert defines the maximum time allowed to elapse between the occurrence of an integrity loss and its signaling (e.g., via an integrity validity flag). Target Integrity Risk (TIR = Target-Integrity-Risk): Target integrity risk is expressed as a probability (dimensionless) or a probability per unit time (typically per hour). It indicates the probability that a positioning solution's positioning error exceeds an "alarm limit" without indicating a loss of integrity within the time frame for which an alarm is issued. Target integrity risk describes the target rate, which is usually specified by the customer. The corresponding probability is also known as the HMI rate (HMI Risk Misleading Information). The HMI rate represents the probability of approving an incorrect positioning solution. Security or integrity availability: Security availability refers to the percentage of time a system service is available to the user; in the context of a navigation module, this means the percentage of time during which safe and reliable positioning can be achieved. It depends on the physical characteristics of the environment and the technical capabilities of the navigation module system.

[0008] The specifications of these parameters depend on numerous conditions, constraints, and limitations associated with SOTIF, such as the defined Operational Design Domain (ODD), the customer's application scenario, and the vehicle functionality that will utilize the positioning solution. For highway applications, an example of the parameter set that needs to be defined for AD / ADAS functionality could be: TIR in 10... -4 / h to 10 -6 The horizontal distance is 3 to 5 meters, and the time-to-action (TTA) is 5 to 10 seconds. This set of parameters defines the verification process to be conducted. Once a specific application of the navigation module is to be classified as "safe," this parameter set must be strictly adhered to. This parameter set forms the basis for all subsequent activities, such as analyzing SOTIF triggering conditions and developing SOTIF concepts and strategies to demonstrate the reliability of the intended functionality. Whether such reliability exists for the provided positioning solution must be demonstrated separately for each application (e.g., for each vehicle type). Summary of the Invention

[0009] Based on this, the present invention aims to introduce an effective verification strategy, thereby enabling the efficient provision of corresponding proofs to demonstrate security levels for specific applications.

[0010] This article describes a method for verifying the application of a navigation module for safety level verification, wherein the navigation module has at least one GNSS module for determining navigation data as input data for navigation in a motor vehicle, and the method includes the following steps:

[0011] a) Receive application data related to the application;

[0012] b) Receive application-related test data, which is measured when the vehicle is tested using the navigation module being applied;

[0013] c) Apply the Monte Carlo method to create a large number of test scenarios for the application, based at least on application data and test data;

[0014] d) Based on the test scenario created in step c), perform tests on the application; and

[0015] e) Approval for the application shall be granted at least based on the results of the tests performed in accordance with step e).

[0016] It is particularly advantageous that the approval granted under step e) is a SOTIF approval.

[0017] This approval is a SOTIF approval, and its certification must be conducted in accordance with ISO 21488. However, this method is also generally applicable to other approvals and / or verifications of navigation modules according to other standards. Here, "verification" specifically refers to the process used to determine approval. This method is particularly used to provide proof of the required integrity risks to the protected components (the location / position to be determined using the navigation module) for the specific application of the navigation module.

[0018] Of particular advantage is that, according to the approval granted in step e), an upper limit is specified on the probability of at least one unidentified error occurring in the navigation data determined using the navigation module.

[0019] Based on customer needs, specific application scenarios, system design, experience, or historical events (i.e., incidents observed in other navigation systems or similar products in the past), hazardous events and scenarios are identified and compiled into a verification catalog. This catalog lists all tests required to grant SOTIF classification.

[0020] The validation catalog is the starting point for SOTIF validation and the foundation for SOTIF categorization. Ideally, the validation catalog is not static and not fixed for any specific navigation module. Instead, it is a dynamic document that continues to adapt and improve even after it has been initially categorized for a specific application within a particular navigation module.

[0021] It is recommended to construct a verification catalog based on application data, which is determined for the specific application of the navigation module in a particular vehicle type, a particular vehicle series, etc. (step a)). Here, the term "application" refers to the configuration of the navigation module for a particular vehicle type or a particular vehicle series.

[0022] According to the validation catalog, each case or situation that must be examined to grant a specific SOTIF classification will preferably be classified in the validation catalog based on its probability of occurrence in the field. In principle, the validation catalog includes both high-probability cases or situations and lower-probability cases or situations.

[0023] In step b), test data relevant to the application, determined using a vehicle prototype, is received. Here, a vehicle prototype refers to a vehicle configured for the application—specifically, the first prototype of the corresponding model or series.

[0024] Nominal event / scenario: All effects and behaviors expected to occur within a sufficient amount of test driving time are defined as nominal events / scenarios, i.e., events with an occurrence rate of 10. -2Systematic effects or periodic errors of / h or higher are considered only if more than 1000 hours of statistically representative test driving have been evaluated. Such events / scenarios or effects and behaviors are preferably covered by the test data received in step b). In the context of test driving, "representative" means that the driving conditions tested during the test driving period are sufficiently representative of the normal use of the corresponding vehicle. For example, 1000 hours of test driving on a test track is less representative than test driving in normal road traffic. Generally, all events that can be evaluated through test driving should preferably be tested through test driving, as real-world behaviors, including interface and communication channels, vehicle design, chassis and installation issues, etc., will be reflected in the data.

[0025] The specific tests performed during the test drive (which form the basis of the test data received in step b) are preferably specified in the verification catalog. Therefore, the test drive is preferably not completely random; rather, it is specifically designed to examine specific scenarios / impacts within the scope of the test drive.

[0026] Special events / scenarios refer to events for a specific ODD and application scenario with an expected probability of less than 10%. -2 / hourly effects and behaviors. These special events are often not covered by existing experience test drive databases, or test drives cannot adequately guarantee that such special events / scenarios have been properly considered. Statistically, the probability of occurrence is less than 10. -2 An event or scenario occurring per hour occurs less than 10 times in 1000 hours of test driving. Therefore, if the total number of test drives is limited, only the relatively infrequent occurrences of such scenarios can be studied through test driving.

[0027] To test such special events / scenarios, it is preferable to use the Monte Carlo method in step c) to create a large number of test scenarios for the application.

[0028] For each case in the verification catalog, a suitable verification scheme should be specified. This verification scheme preferably includes a verification setup that describes the architecture for performing the verification (e.g., also known as the test architecture). The verification scheme can have a suitable architecture for each case in the verification catalog; a uniform architecture is not required. The verification setup may include the embedded model to be tested (MIL = Model in the Loop) (possibly a component of the navigation module).

[0029] Of particular advantage is that, when creating the test scenario in step c), the input data for the navigation module is taken into account, and the occurrence of the input data is determined based on the test data received in step b).

[0030] Furthermore, it is advantageous that when creating the test scenario in step c), the input data for the navigation module (1) is used, the input data being determined in prior tests of the navigation module in other applications and / or test models.

[0031] Furthermore, it is advantageous that in step c), the Monte Carlo method is used to generate multiple test scenarios with modified input data by randomly modifying the input data.

[0032] Furthermore, it is advantageous that the number of test scenarios created in step c) and the number of tests performed in step d) be chosen to be sufficiently large such that there is a statistical probability that particularly problematic input data for the navigation is tested.

[0033] Furthermore, it is advantageous that the tests performed in step d) are conducted at least in part using an embedded model (MIL = Model in the Ring), which simulates the applied navigation module.

[0034] Preferably, an embedded model (MIL = Model in the Loop) should be used for further testing based on the test scenario created in step c). The embedded model does not necessarily have to be a vehicle that can be used for test driving. In implementation variations, the embedded model can also be a model specifically set up for the corresponding test, including software components of the navigation module, and, if necessary, hardware components, which are embedded in an environment adapted to or usable for testing the corresponding application.

[0035] For the corresponding approval granted according to step e), the test data from the test drive (step b) and the results of further tests performed according to step d) are preferably taken into consideration.

[0036] As previously stated, a verification protocol is defined for the approval / verification of the corresponding application. This protocol forms the basis of the testing or predetermines the test content. This is preferably applicable to test data determined from test runs (step b) and tests performed according to step d). The verification protocol may also include analytical methods, such as the so-called Fault Tree Analysis (FTA) described herein.

[0037] The SOTIF verification strategy described in this article is mainly based on three so-called verification pillars: Verification is performed through test drives, which allows for the identification and analysis of data received during the nominal event (step b). Simulation-based verification can be performed using the so-called Monte Carlo method, which can support or supplement the verification of nominal and anomalous events (step d). SOTIF fault tree analysis focuses on analyzing abnormal events.

[0038] SOTIF fault tree analysis differs fundamentally from the other two pillars. Validation using test data and Monte Carlo methods involves practical research, while SOTIF fault tree analysis is an analytical method that relies on correctly identifying the causes of errors that have occurred and then analyzing and calculating the probability of subsequent errors based on this.

[0039] It should also be noted that all three validation pillars are used (to varying degrees) to evaluate known and unknown hazard events and scenarios. Neither explicit distinction is expected nor performed in the study of known and unknown hazard events. In this context, a hazard event is an event that, if unidentified, could lead to mislocalization. A known hazard event is an event known to cause unidentified mislocalization. An unknown hazard event is an event whose likelihood of causing unidentified mislocalization is unknown.

[0040] Some aspects involved in each validation pillar are as follows: Statistical validation of large datasets: In all the validation pillars described, large datasets are ultimately studied to identify scenarios / events where errors may occur. Scenario or event-driven validation: All validation pillars aim to determine the frequency of a particular scenario or event and the potential for undetectable location errors. Verification of sensor performance fluctuations: Sensor performance fluctuations are implicitly considered in all the verification pillars mentioned. System design check: Each verification pillar also checks the basic design / structure of the corresponding navigation module in the relevant application. Sensitivity testing: The sensitivity of the navigation module or individual components in the corresponding application is also checked using each verification column.

[0041] In principle, the knowledge gained through each verification pillar overlaps with each other. Therefore, by using all three verification pillars mentioned above for verification, a comprehensive overall picture can be obtained.

[0042] In the final step of the validation process, the results are summarized into overall HMI rate and security availability, which are taken into account in the SOTIF validation demonstration of the navigation module in the relevant application.

[0043] The following sections will describe the three validation pillars of SOTIF and their respective activities in more detail.

[0044] SOTIF-verified components or pillars based on actual test drives aim to validate and approve integrity requirements through real-world test drives. Theoretically, the dataset required to achieve a specified target integrity rate (TIR) ​​is far larger than the dataset that can be collected during test drives during product development. For example, to empirically validate 10... -5To achieve the target integrity rate of / h, over 100,000 hours of test driving are required to employ common descriptive methods (where one event should statistically occur at least 10 times within the test period). To overcome this challenge, statistical prediction methods can be used to predict sensor behavior based on a limited dataset. Three key points need to be considered here: A limited dataset of test driving data can represent the statistical behavior of the sensors. Choose statistical forecasting methods that are adapted to the system's behavior. Any remaining subcritical events (i.e., location errors that, although not exceeding alarm limits, exhibit statistical outliers) will be thoroughly analyzed and classified as safe according to the specified integrity requirements.

[0045] Test vehicles equipped with the navigation module under test (DUT) and a more accurate reference system are used for data recording. Driving scenarios and datasets are pre-defined to ensure diversity and representativeness of the test coverage. Data evaluation involves comparing the fused positioning results determined by the DUT with the position determined by the significantly more accurate system (also known as the "reference ground truth position"). To ensure the representativeness of the dataset, several aspects must be considered. For example, the integrity-related behavior of the test vehicle, particularly the behavior and accuracy of the fused position, must closely approximate that of the target system. This includes components that are not directly part of the navigation module but affect its SOTIF approval. Examples of this include the type and design of the GNSS antenna, the installation location of the antenna and sensors, and the quality or software of the GNSS correction data. Furthermore, empirically, the accuracy of the ground truth information (also known as the "ground truth position") provided by the reference system must be at least ten times that of the DUT.

[0046] During the test drive, it is particularly preferred to test driving scenarios that are known to have particularly high requirements for the accuracy of the position determined by the navigation module.

[0047] To determine the driving scenarios for test drives, a special scenario database is particularly preferred: scenarios including known problem cases (e.g., hydroplaning, emergency braking) and special vehicle configurations (e.g., driving with a roof box or trailer) are defined and driven to take into account conditions that affect various SOTIF-related elements of the navigation module (e.g., GNSS signal reception behavior).

[0048] Statistical representativeness of the database: To define a statistically representative database, the dataset must include representative scene variations, including but not limited to weather, traffic and environmental conditions, as well as road types and trajectories. Furthermore, based on the specified target integrity risk and depending on the system's expected nominal performance, a minimum amount of data is required to ensure sufficient predictive reliability.

[0049] Validation based on test drives preferably uses statistical prediction data to supplement the results.

[0050] Preferably, statistical prediction is used to enrich and evaluate the probability of specific events measured during test drives. After data is collected from the test drives, the test drive structure can be compared and converted with actual operating scenarios to calculate the frequency of specific events occurring in real-world applications or operating scenarios. For this purpose, extreme value theory can be used, for example. Furthermore, probability density functions (PDFs) can be obtained, adapted, and applied. An adapted probability density function can also be obtained.

[0051] Based on this model, so-called subcritical events are identified as statistical outliers that significantly increase the probability of HMI. In the final validation step, these events are analyzed in detail to arrive at a reasonable argument regarding the probability of unidentified false localizations.

[0052] A typical and significant error source identified during test runs and better assessed through statistical prediction is the effect of multipath signal propagation, i.e., GNSS signal reflections at environmental obstacles such as buildings, vegetation, or traffic, causing signal delays. Large positioning errors caused by multipath propagation can be analyzed using the multipath propagation error envelope. For example, GNSS observation errors caused by multipath effects are limited by scene conditions, which are influenced by existing signal reflectors and vehicle dynamics. On the other hand, simulations can be used to analyze the potential impact of measurement errors caused by multipath propagation on fusion solutions. Simulations of similar scenarios can demonstrate that in such or similar scenarios, the error will not exceed a safety-critical positioning error threshold.

[0053] Preferably, all known relevant important scenarios should be covered within the test driving range. In particular, it is necessary to analyze the statistical behavior of the recorded data relative to the TIR. Based on this, the expected probability of HMI occurrence can be predicted. For anomalous subcritical events appearing in the statistical analysis, detailed analysis is preferred to derive the following argument: these risks will not occur in the field (in actual use of the navigation module), or will only occur within acceptable limits.

[0054] Preferably, a model-in-the-loop (MiL) simulation based on the Monte Carlo (MC) method is performed to verify the navigation module's performance without a test drive. The Monte Carlo method allows for a large number of parameter variations, which can be used to test the navigation module based on the model.

[0055] In Model-in-the-Loop (MiL), applying Monte Carlo (MC) methods to acquire test data for navigation module analysis is particularly effective for certain events / scenarios. For example, undetected positioning errors may occur in the following events / scenarios: GNSS and / or correction data loss GNSS environments are complex, with issues such as poor visibility and multipath effects; or Correct for data quality fluctuations.

[0056] These types of events / scenarios will be tested periodically within the test driving range. The various input parameters used by the navigation module to create positioning will change to some extent during these events / scenarios.

[0057] Using Model-in-the-Loop (MiL), positioning can be tested using a navigation module based on a specific set of parameters.

[0058] By utilizing the Monte Carlo method to change parameters, Model-in-the-Loop (MiL) can be used to create and test a large number of variations of parameter combinations that occur during test drives. In particular, worst-case scenarios (especially unfavorable parameter combinations) that can be studied using Model-in-the-Loop (MiL) can be determined.

[0059] Such worst-case driving scenarios can be obtained from test drives (through parameter variations) or specifically designed based on experience and expectations. Subsequently, using the Monte Carlo method, a large number of independent test scenarios (with parameter combinations as localization inputs) can be determined around the worst-case scenarios based on experience and expectations. These scenarios can then be systematically studied using Model-in-the-Loop (MiL).

[0060] Typical worst-case driving scenarios are characterized by high dynamics and complex environmental conditions, which are combined with parameter variations based on the Monte Carlo method. This method will be described in more detail below.

[0061] To utilize Model-in-the-Loop (MiL) and Monte Carlo methods, a simulation environment is preferably constructed. Worst-case driving scenarios are simulated using a driving dynamics simulation environment. To simulate complex environmental conditions related to GNSS, configurable synthetic observation data is modeled using a so-called GNSS rover simulator. Defects based on the Monte Carlo method are incorporated into the IMU signals, correction data, and GNSS signals based on the vehicle dynamics simulation environment and the GNSS rover simulator results. Simulation data is processed using a software-in-the-loop environment. Finally, the output of the navigation module's software under test is evaluated as required, including, for example, analyzing variations in positioning error and sensitivity to integrity parameters.

[0062] The Monte Carlo method is used to inject errors into the parameters to be processed. The output data of the navigation module's software under test is extremely complexly influenced by the parameters fed into the positioning system, making it impossible to know in advance which imperfect combinations of the measured inputs will pose the greatest challenge to the algorithm. Therefore, a simulation method based on Monte Carlo is chosen to apply various imperfections to the algorithm's input parameters. The idea behind using this method to ensure the integrity of complex systems is to select a sufficiently large number of simulation runs, each using a different set of modified input parameters, to identify and cover the worst-case combinations of imperfect inputs. In this way, the system's response can be studied under the most complex conditions without needing to know all the details of the conditions beforehand. For example, the range of various imperfections in the input parameters can be determined by the statistical distribution measured when characterizing the various input systems.

[0063] Of particular advantage, the navigation module includes at least one inertial sensor module that provides input data for navigation.

[0064] Of particular advantage, the navigation module has at least one correction data interface through which GNSS correction data can be received as input data for navigation.

[0065] The three components that have the greatest impact on the positioning output of the software under test as a navigation module are the input parameters provided by the inertial sensor, the GNSS correction data, and the raw GNSS observations output as a GNSS receiver, all of which are combined with the corresponding quality information.

[0066] Inertial sensors include accelerometers and yaw rate sensors. These sensors are calibrated in a laboratory to determine various possible error values, such as noise or offset. The results are then fitted, preferably using an appropriate distribution function, to obtain characteristic values, such as the mean or variance. For each simulation run, a set of inertial sensor defects is determined by calculating the possible realizations of the defects based on probabilities given by relevant statistical data. These defects are added to the signals simulated using dynamic vehicle simulation.

[0067] Based on the calibration data specifications and characteristic calibration provided by the calibration data provider, a suitable defect distribution is selected. Similar to inertial sensors, signal defects are determined based on statistical probability during each run. These defects are then added to the calibration data.

[0068] GNSS measurement accuracy and quality can deteriorate due to environmental factors, such as multipath effects. To account for the impact of these factors on navigation module software, a Monte Carlo-based simulation method is used to modify the measurement results and corresponding quality information. The statistical characteristics of the measured GNSS errors are studied, and characteristic values ​​of the distribution are derived for a configurable number of altitude-related categories. GNSS observation errors are preferably modeled using a stationary Gaussian-Markov process, taking into account the effects of signal strength and quality information. Similar to inertial sensor and calibration data, a set of input parameters for the Gaussian-Markov process is preferably calculated for each test using a Model-in-the-Loop (MiL) method. These errors are then added to the previously calculated synthetic observations.

[0069] This Monte Carlo method incorporates various worst-case driving scenarios and complex environmental conditions, as well as multiple defect variants. For each set of simulations, Model-in-the-Loop (MiL) is used to examine the system behavior and its sensitivity to integrity-related requirements. Finally, conclusions are drawn regarding integrity risks and safety availability.

[0070] Monte Carlo simulations via MiL and single-fault injection simulations via HiL support the proof process. The Monte Carlo method complements measurement-based proofs, while single-fault injection complements fault tree analysis.

[0071] Fault tree analysis (FTA) is used to analyze the propagation of signal errors through the navigation module or through various data processing stages within the navigation module or its software. FTA supports functional development and is particularly useful for validating navigation modules in response to abnormal events, demonstrating the safety of expected functions.

[0072] Fault tree analysis is best performed starting from the so-called "normal condition" (i.e., operation without faults), but this is never possible in reality.

[0073] Potential anomalous events or conditions (also known as hazardous events) are derived and evaluated within the scope of SOTIF hazard analysis and risk assessment. An important input source is the validation catalog described above, which lists various scenarios / events analyzed within the test drive scope.

[0074] Within the scope of fault tree analysis, each potential fault is listed, and the possible subsequent faults it could cause are identified. The probability of a fault triggering a possible subsequent fault is determined. This leads to the construction of a complex fault tree, which can be used to estimate the actual probability of an unidentified mislocation occurring under specific input parameters.

[0075] Furthermore, a confidence assessment is preferably introduced to demonstrate the reliability of information regarding anomalous events. For example, ionospheric irregularities are highly dependent on solar activity, and their frequency of occurrence is derived by analyzing geomagnetic index time series and historical events. Because of the complex geophysical processes and phenomena behind these triggering conditions, reliable exposure grading is nearly impossible; therefore, the confidence grading can be set low, increasing the necessity for fault injection testing, which will be explained later. The result is more accurately the probability of the top-level event (HMI in this case). It also results in identifying which paths / subsequent errors / cutsets contribute most to the top-level event, allowing for targeted responses through enhanced testing and / or the development of countermeasures (i.e., monitors) in the software.

[0076] Preferably, fault tree analysis includes forming scenario / event clusters.

[0077] Because fault tree analysis is used to analyze anomalous events, the probabilities of occurrence for specific events and the probabilities of relationships between specific events and subsequent events used within the scope of fault tree analysis are either derived from expert assessments (referencing considerations from other GNSS-related fields such as avionics) or from historical assessments of previous analyses of navigation modules or similar systems. For many identified triggering events, pure analytical assessment is insufficient. Therefore, cutset analysis can also be performed to identify the most critical paths—those events with particularly high trigger probabilities that lead to unidentified mislocations. Based on this, further testing can be conducted as necessary—for example, during test drives or, if necessary, using Monte Carlo methods and the aforementioned fault injection. The goal of testing using fault injection is to induce dangerous positioning behavior by injecting single or combined triggering events or conditions. The navigation module's behavioral response will be recorded and subsequently evaluated to confirm or modify the risk assessment obtained through fault tree analysis. The testing process is divided into system qualification testing and software qualification testing. The focus is on two aspects: firstly, conducting black-box testing of the system using pass / fail criteria derived from customer or system requirements; and secondly, conducting white-box testing of the system using pass / fail criteria that govern the system's expected detection and error avoidance capabilities.

[0078] When constructing a fault tree for fault tree analysis, it is preferable to answer the following questions: Can fault injection elicit functional behavior? What is the order of error occurrence, detection, and response time? In subsequent studies, were the initial assumptions upon which the component fault tree was based confirmed? To what extent are these errors symptomatic and characteristic? For example, do these errors increase over time? What mechanisms (such as monitoring) can reduce the impact of errors?

[0079] These issues are preferably evaluated and discussed by experts regarding potential feedback from the quantitative fault tree analysis, and should include assumptions that can lead to confirmation and / or adjustment of exposure probabilities, severity, or preventative measures. All steps are performed iteratively, ultimately resulting in a stable fault tree analysis with quantitative probability estimates that describe the probability of unidentified mislocations occurring.

[0080] According to step e), it is preferable to summarize or combine the verification results from the three verification pillars (i.e., approval based on test driving, Monte Carlo simulation, and fault tree analysis) into a whole verification in order to ultimately prove the safety of the expected function.

[0081] In this context, the aggregation method can vary. The first method involves summing the probabilities of unidentified error locations. This method is preferably based on the assumption that all validation columns are complementary. More refined methods can weight the probabilities of each validation column based on the application and validation type. Attached Figure Description

[0082] The present invention and its technical background will now be described in more detail with reference to the accompanying drawings. The drawings show preferred embodiments, but the invention is not limited thereto. It should be particularly noted that the drawings, especially the dimensional relationships shown, are merely schematic diagrams. Herein lies:

[0083] Figure 1 A schematic diagram of the navigation module's operation; its application can be verified and classified using the methods described in this article.

[0084] Figure 2 Protection level diagram;

[0085] Figure 3 : An embedded model used to perform tests based on test data generated using the Monte Carlo method;

[0086] Figure 4 Overview of potential factors that may cause positioning distortion. Detailed Implementation

[0087] Figure 1Vehicle 3 is shown in traffic. Navigation module 1, located within vehicle 3, performs navigation. This primarily relies on GNSS satellite signals, as well as information from calibration data service 19, inertial sensors, and wheel speeds. Information from calibration data service 19 is preferably also distributed via satellite. The positioning result determined by navigation module 1 has a tolerance range 16. If the deviation between the determined position 14 and the actual position 15 of vehicle 3 is within tolerance range 16 (providing sufficiently high safety), the positioning is correct and the integrity of the position output is satisfied. Tolerance range 16 is also known as the protection level. The protection level is continuously available. If the alarm limit is exceeded, an alarm must be issued within a predefined alarm time.

[0088] Figure 2 The protection levels and the minimum security requirements specified in the SOTIF approval were explained in further detail. Figure 2 The upper part shows the actual location, the output (or measured) location 14, and the protection level represented by ellipse 13 in an exemplary scenario. Figure 2 In the lower region, for ease of illustration, the tolerance range 16, defined as ellipse 13 in the upper plane, is plotted on a straight line. The actual position 15 and an example of a measured position 14, which deviates from the actual position 15, can be identified. The probability distribution 20 of the measured position 14 is also plotted on this straight line. It can be seen that almost all measured positions 14 lie within the tolerance range 16 surrounding the actual position 15. Figure 2 Alarm limit 17 is also plotted on the straight line. If the measurement location 14 cannot be measured with sufficient accuracy, i.e., it is not within the tolerance range 16 but exceeds the alarm limit 17, then an alarm must be triggered.

[0089] according to Figure 3 An embedded model 21 (MIL = loop model) is shown, which allows the described process to be performed at least partially (partially according to step d).

[0090] Navigation module 1 is simulated here in embedded model 21 as its input data sources. These input data sources include, in particular, GNSS module 2, inertial sensor module 5, GNSS correction data interface 6, and wheel speed sensor 10. If necessary, other data sources exist upstream of these input data sources to simulate the input data of these input data sources. For example, dynamics simulation 7 is used to simulate the vehicle's driving dynamics, while GNSS data simulator 8 is used to simulate GNSS input data. Based on embedded model 21 described herein, modifications or errors can be selectively injected into the input data using Monte Carlo simulation 9. The tolerance of navigation module 1 to these injected modifications and errors can be simulated in simulation 11 and evaluated in evaluation 12 to perform further testing according to step d).

[0091] exist Figure 4 The diagram schematically illustrates various input data and influencing factors that can be investigated using fault tree analysis. Vehicle 3, equipped with a navigation module 1 (not shown separately here), is visible in the diagram. Input data used to perform positioning using the navigation module 1 is indicated by arrows pointing to vehicle 3.

[0092] The input data initially comes from GNSS satellite 18. Errors in the input data may arise, for example, from the atmosphere, such as the plasma layer 22, ionosphere 23, and troposphere 24. In these atmospheric layers, factors such as ions or weather conditions can affect the input data / signal from GNSS satellite 18. Correction data is provided by correction data service 19 and, if necessary, transmitted as input data to vehicle 3 or navigation module 1 located therein via geostationary satellite 25. Plants 26 and buildings 27 may also interfere with vehicle 3 or navigation module 1 receiving input data, for example, by generating reflected signals, interference, etc. All these effects, or more precisely, the possibility that these effects may cause distortion of the positioning results generated by navigation module 1, can be analyzed through fault tree analysis to identify particularly critical situations.

Claims

1. A method for approving the application of a navigation module (1) for a safety level, wherein the navigation module (1) has at least one GNSS module (2) for determining navigation data as input data for navigation in a motor vehicle (3), the method comprising the steps of: a) Receive application data related to the application; b) Receive test data related to the application, which is determined when the application is tested using a vehicle (3) including the navigation module (1) to which the application is applied; c) Using the Monte Carlo method, at least based on the application data and the test data, create a large number of test scenarios for the application (4). d) Based on the test scenario (4) created in step c), perform tests on the application; and e) Grant approval to the application based at least on the results of the test performed according to step d).

2. The method according to claim 1, wherein, The approval granted according to step e) is a SOTIF approval.

3. The method according to claim 1 or 2, wherein, Based on the approval granted in step e), an upper limit is specified for the probability of at least one unidentified error occurring in the navigation data determined using the navigation module (1).

4. The method according to any one of the preceding claims, wherein, The navigation module (1) has at least one inertial sensor module (5) which provides input data for the navigation.

5. The method according to any one of the preceding claims, wherein, The navigation module (1) has at least one calibration data interface (6), through which GNSS calibration data can be received as input data for the navigation.

6. The method according to any one of the preceding claims, wherein, When the test scenario (4) is created in step c), the input data for the navigation module (1) is taken into account, and the occurrence of the input data is determined based on the test data received in step b).

7. The method according to any one of the preceding claims, wherein, When creating the test scenario (4) in step c), input data for the navigation module (1) is used, which is determined in other applications and / or test models in prior tests of the navigation module (1).

8. The method according to any one of the preceding claims, wherein, In step c), the Monte Carlo method is used to generate multiple test scenarios (4) with modified input data by randomly modifying the input data.

9. The method according to any one of the preceding claims, wherein, The number of test scenarios (4) created in step c) and the number of tests performed in step d) are chosen to be sufficiently large such that there is a statistical probability that particularly problematic input data for the navigation is tested.

10. The method according to any one of the preceding claims, wherein, The test performed in step d) is performed at least in part using an embedded model (MIL = Model in the Ring), which simulates the applied navigation module (1).

Images