Methods and systems for developing and validating autonomous driving features

Abstract

This disclosure relates to methods and systems for developing and validating autonomous driving features, specifically methods for controlling a control system of a vehicle having a first driver support module (such as an ADAS feature) and a second driver support module (such as an "ADS feature under development"). The first and second driver support modules are capable of operating within an overlapping operating design domain (ODD). The method includes acquiring sensor data including information about the vehicle's surrounding environment and determining the satisfaction of the overlapping ODD based on the acquired sensor data. If the overlapping ODD is satisfied, a switch is made between a first configuration where the first driver support module is activated and the second driver support module is not activated, and a second configuration where the first driver support module is not activated and the second driver support module is activated. The switch between the first and second configurations is based on a switching protocol to perform closed-loop testing of the second driver support module during at least a portion of a time period in an environment satisfying the overlapping ODD.

Description

[0001] Cross-references to related applications

[0002] This patent application claims priority to the assignee of European Patent Application Serial No. 19203392.6, filed on 15 October 2019, entitled “METHODAND SYSTEM FOR DEVELOPMENT AND VERIFICATION OF AUTONOMOUS DRIVING FEATURES”, which is expressly incorporated herein by reference. Technical Field

[0003] This disclosure relates to automated driving systems (ADS) and advanced driver assistance systems (ADAS). More specifically, this disclosure relates to methods and systems for developing and validating ADS features or functions. Background Technology

[0004] Automated systems (AS) are capable of acting independently of direct human control and under unscripted conditions. These systems enable a wide range of applications, such as driverless cars, humanoid robots, and mail delivery drones. However, this enhanced capability and flexibility comes at a cost: the difficulty of assessing the reliability and safety of automated systems.

[0005] Traditional testing methods fail to deliver the expected standard of performance, primarily due to the sheer number of possible scenarios to be analyzed. Strict requirements exist to ensure the safety and reliability of the AS. Safety standards mandate that the AS operate in the absence of hazardous conditions, while reliability requirements mandate that the system deliver services as specified. These requirements are typically associated with a low threshold for system failure—a high probability of fault-free operation in a given environment—which in turn necessitates costly and time-consuming AS development, validation, and verification.

[0006] Today, many vehicles feature a variety of driver support functions in the form of Advanced Driver Assistance Systems (ADAS). Moreover, many of these support functions form the basis of current and future Automated Driving Systems (ADS) functions (also known as Automated Driving (AD) functions). Examples of ADAS features or functions include lane departure warning systems, lane centering, lane keeping assist / support, pilot assist, lane change assist, parking sensors, pedestrian protection systems, blind spot monitors, and adaptive cruise control (ACC), among others. These functions supplement traditional driver control of the vehicle with one or more warnings or automatic actions in response to specific situations.

[0007] Currently, the development and validation of ADDS solutions are very expensive and time-consuming, with a significant portion of the work dedicated to identifying and resolving tasks that current ADAS features struggle to address—often referred to as edge cases or extreme situations. Examples of extreme situations include conditions such as low sunlight, rain, snow, road debris, unexpected objects, unexpected road user behavior, dirty sensors, and interactions in heavy traffic. Another issue is that resolving these extreme situations does not provide any direct customer value until overall performance reaches an acceptable level of safety and usability.

[0008] Furthermore, Original Equipment Manufacturers (OEMs) consider the cost and time involved in developing and validating ADS to be an issue. They want to develop ADS, but at the same time, they want to use ADS technology to enhance customer value for ADAS modules. However, this is easier said than done, as engineers working on ADS need to focus on resolving extreme cases within a very limited Operating Design Domain (ODD) to achieve a level of safety (at a reasonably fast speed) within which the ADS can be launched.

[0009] Furthermore, when ADAS becomes good enough to be perceived as providing perfect comfort (by drivers / customers), it can mislead some drivers into believing they no longer need to monitor the system, causing them to subconsciously stop monitoring the feature, or increasing their reaction time due to the rarity of needing to correct or intervene with the ADAS feature. The more people rely on automatic features, the slower their reaction time becomes in situations requiring control—sometimes referred to as the "curse of automation." Therefore, improving ADAS at this point may lead to more problems than benefits for customers, and additionally require OEMs to introduce more attention support systems to ensure drivers can detect and act on extreme situations that ADAS cannot handle.

[0010] Therefore, if extreme cases are one aspect that separates ADAS from ADS, and ADAS is not actually used to address all extreme cases, then even envisioning how to actually achieve an effective transition from ADAS to ADS is a problem. Summary of the Invention

[0011] Therefore, the object of this disclosure is to provide a method for controlling a vehicle, a computer-readable storage medium, a control system, and a vehicle including such a control system, which mitigates all or at least some of the defects discussed above.

[0012] More specifically, the purpose of this disclosure is to provide a solution that accelerates the development of both ADS and ADAS while reducing verification costs and improving data collection. The definitions of ADAS and ADS can be given, for example, by SAE J3016 Driving Automation Levels.

[0013] This objective is achieved by means of a method for controlling a vehicle, a computer-readable storage medium, a control system, and a vehicle including such a control system, as defined in the appended claims. In the current context, the term "exemplary" should be understood as being used as an instance, example, or illustration.

[0014] According to a first aspect of this disclosure, a method is provided for controlling a vehicle having a first driver support module (e.g., an ADAS feature) and a second driver support module (e.g., an ADS feature "under development"). The first and second driver support modules are capable of operating within an overlapping operating design domain (ODD). The method includes: acquiring sensor data including information about the vehicle's surrounding environment; and determining, based on the acquired sensor data, whether the overlapping ODD is satisfied. Further, if the overlapping ODD is satisfied, the method includes switching between a first configuration in which the first driver support module is activated and the second driver support module is not activated, and a second configuration in which the first driver support module is not activated and the second driver support module is activated. Additionally, the switching between the first and second configurations is based on a switching protocol to perform a closed-loop test of the second driver support module during at least a portion of a time period during which the vehicle is in an environment satisfying the overlapping ODD. This presents an effective method for bridging the gap between ADAS and ADS development. Furthermore, this method can accelerate the development of "high-performance" ADAS in conjunction with ADS.

[0015] In the current context, a driver support module can be interpreted as an ADAS feature / function (e.g., adaptive cruise control, automatic parking, hill descent control, lane centering, lane departure warning system, intersection assist, etc.) or an ADS feature / function (i.e., "automatic navigation" for a specified ODD configuration). In other words, a driver support module can be understood as an automated driving system for highway vehicles with an automation level between 1 and 5 according to SAE J3016 driving automation levels. Naturally, if the product is unproven, it cannot be a Level 4 or Level 5 feature, as the definitions of these levels indicate that no driver intervention is required; in this case, the driver support module can be referred to as a "planned" Level 4 or Level 5 feature.

[0016] The Operational Design Domain (ODD) should be understood as a description of the operational domain in which an automated or semi-automated driving system (i.e., AD or ADAS) is designed to have functions including, but not limited to, geography, road surface (e.g., type, surface, geometry, edges and markings), environment, connectivity, surrounding objects and speed limits.

[0017] According to exemplary embodiments of this disclosure, a first driver support module has a first defined performance level, and a second driver support module has a second defined performance level, where the first defined performance level is lower than the second defined performance level. An example of a defined performance level may be a verified fault frequency. Therefore, in some embodiments, the first driver support module has a first verified fault frequency, and the second driver assistance module has a second verified fault frequency, where the first verified fault frequency is higher than the second verified fault frequency. In some embodiments, the first driver support module may be an "ADAS module," and the second driver support module may be an "ADS module under development" (hereinafter referred to as an "AD core" module). In some embodiments, the first driver support module may be an Automated Driving System (ADS) function with a first level of driving automation, and the second driver support module may be an ADS function with a second level of driving automation, where the first level is lower than the second level.

[0018] Furthermore, according to an exemplary embodiment of the present disclosure, the activated driver support module is arranged to generate control signals for the vehicle's control system in order to control at least one of the vehicle's steering angle, vehicle acceleration, and vehicle deceleration.

[0019] Furthermore, according to another exemplary embodiment, the switching protocol includes a predefined timing scheme comprising instructions for selecting a second configuration during 1% to 99.99% of the duration of the time period, preferably during 25% to 95% of the duration of the time period, and more preferably during 50% to 90% of the duration of the time period; while selecting a first configuration for the remaining portion of the time period. The advantage of selecting the second configuration during the duration of 50%-90% (preferably 80%-90%) of the time period is that a large amount of data can be used for closed-loop testing while maintaining a low risk of the “curse of automation.” More specifically, compared to selecting the second configuration during 10% of the time period, a 5-fold to 9-fold increase in available data can be achieved. By using the first configuration for at least a portion of the time period, the driver will maintain the ability to supervise and retain rapid reaction time, thus avoiding the “curse of automation.” Furthermore, compared to selecting the second configuration for 95-99% of the time, this can lead to a significant increase in data for closed-loop testing (the increase is less than 10% compared to 90%), but it also increases the risk of falling into the "curse of automation." Additionally, in this paper, using the second configuration for a portion of the time period can be termed a "grey start," which differs from a dark start where the second configuration simply runs in the background.

[0020] Therefore, the method may include a dark start process for the second driver support module. More specifically, according to an exemplary embodiment of this disclosure, the method further includes, before switching between a first configuration and a second configuration, activating the first driver support module while simultaneously running the second driver support module in a background configuration to perform verification of compatibility between the satisfied overlapping ODD and the second driver support module. This can further improve the overall security of the solution and mitigate the risk of erroneously starting the second driver support module in an incorrect ODD. This may be particularly relevant when the second driver support module is an "not yet ready" ADS feature / function, as full vehicle control may be granted to the vehicle's ADS.

[0021] According to a second aspect of this disclosure, a non-transitory computer-readable storage medium is provided, which stores one or more programs configured to be executed by one or more processors of a vehicle control system, the one or more programs including instructions for performing the method according to any one of the preceding claims. With respect to this aspect of the disclosure, there are similar advantages and preferred modules as those previously discussed in the first aspect of the disclosure.

[0022] As used herein, the term “non-transitory” is intended to describe computer-readable storage media (or “memory”) while excluding media that transmit electromagnetic signals, but is not intended to further limit the types of physical computer-readable storage devices covered by the phrase computer-readable media or memory. For example, the terms “non-transitory computer-readable media” or “tangible memory” are intended to cover types of storage devices that do not necessarily store information permanently, including, for example, random access memory (RAM). Program instructions and data stored in a non-transitory form on a tangible computer-accessible storage medium can be further transmitted via a transmission medium or a signal such as an electrical, electromagnetic, or digital signal that can be transmitted via a communication medium such as a network and / or a wireless link. Therefore, in contrast to limitations on the persistence of data storage (e.g., RAM versus ROM), the term “non-transitory” as used herein is a limitation on the medium itself (i.e., tangible, not signal).

[0023] According to a third aspect of this disclosure, a control system for a vehicle is provided. The control system includes a first driver support module and a second driver support module, wherein the first driver support module and the second driver support module are configured for an overlapping operating design domain (ODD). The control system further includes control circuitry configured to acquire sensor data including information about the vehicle's surrounding environment and to determine the vehicle's current ODD based on the acquired sensor data. Additionally, if the current ODD is an overlapping ODD, the control circuitry is configured to switch between a first configuration in which the first driver support module is activated and the second driver support module is not activated, and a second configuration in which the first driver support module is not activated and the second driver support module is activated. The switching between the first and second configurations is based on a switching protocol to perform a closed-loop test of the second driver support module during at least a portion of the time period during which the vehicle is within the overlapping ODD. For this aspect of the disclosure, there are similar advantages and preferred modules as those previously discussed in the first aspect of the disclosure.

[0024] According to a fourth aspect of this disclosure, a vehicle is provided, comprising: a perception system including at least one sensor device configured to monitor the vehicle's surrounding environment; a positioning system configured to determine the vehicle's geographic location; and a control system according to any of the embodiments disclosed herein. This aspect of the disclosure possesses similar advantages and preferred modules as the first aspect of the disclosure previously discussed.

[0025] Further embodiments of this disclosure are defined in the dependent claims. It should be emphasized that, when used in this specification, the term "comprising / including" is used to specify the presence of the stated module, integral, step, or component. It does not exclude the presence or addition of one or more other modules, integrals, steps, components, or groups thereof.

[0026] These and other modules and advantages of this disclosure will be further illustrated below with reference to the embodiments described herein. Attached Figure Description

[0027] Other objects, modules, and advantages of embodiments of the present disclosure will become apparent from the following detailed description with reference to the accompanying drawings, in which:

[0028] Figures 1a to 1b This is a schematic diagram illustrating the development from basic driver assistance modules to fully autonomous driving over time.

[0029] Figure 2 This is a schematic flowchart illustrating a method for controlling a vehicle according to an embodiment of the present disclosure.

[0030] Figure 3a This is a schematic flowchart illustrating a method executed by a vehicle control system according to an embodiment of the present disclosure.

[0031] Figure 3b This is a schematic flowchart illustrating a method executed by a vehicle control system according to an embodiment of the present disclosure.

[0032] Figure 4 This is a schematic block diagram representing a method for controlling a vehicle according to embodiments of the present disclosure.

[0033] Figure 5 This is a schematic diagram illustrating a method for controlling a vehicle according to an embodiment of the present disclosure.

[0034] Figure 6 These are a series of schematic Venn diagrams illustrating the ODD coverage of a “high-end” ADAS module, an “AD core” module, and a verified AD module over time, according to embodiments of the present disclosure.

[0035] Figure 7 This is a schematic side view of a vehicle including a vehicle control system according to an embodiment of the present disclosure. Detailed Implementation

[0036] Those skilled in the art will understand that the steps, services, and functions explained herein can be implemented using separate hardware circuitry, software that operates in conjunction with a programmed microprocessor or general-purpose computer, one or more application-specific integrated circuits (ASICs), and / or one or more digital signal processors (DSPs). It should also be understood that, when this disclosure is described according to a method, it can also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more programs that perform the steps, services, and functions disclosed herein when executed by the one or more processors.

[0037] In the following description of exemplary embodiments, the same reference numerals denote the same or similar parts. Although the following disclosure primarily discusses vehicles in the form of automobiles, it will be readily apparent to the reader in the art that the teachings discussed herein can be applied to other forms of vehicles, such as trucks, buses, and construction equipment.

[0038] Figures 1a to 1b This is a schematic diagram illustrating the development over time (x-axis) from the basic driver assistance module 22 to the mature ADS module (also referred to as AD module) 26 for any Operating Design Domain (ODD). The y-axis indicates the probability of a failure occurring throughout the driving time, and more specifically, "failure" is interpreted in the current context as a fatal failure (if the driver does not correct it). Figures 1a to 1b It further includes a set of lines 21a-21c spanning driver support modules 22-26, which indicate the development / deployment path over time.

[0039] Note that the number of situations requiring human intervention to avoid incidents and minor accidents may be far greater than the number of "malfunctions." Naturally, all such incidents contribute to how the driver perceives characteristics, thus contributing to increased driver reaction time and the risk of the "curse of automation." Depending on the mix of incidents / malfunctions of varying nature and severity, the switching protocol can be tailored in different ways to maximize the activation time of the second driver support module without exposing the driver to the "curse of automation."

[0040] Data collection plays a crucial role in the efficient development of high-performance or high-end ADAS and ADS modules. Mileage is often cited as a good indicator of ADS module maturity. However, in currently known solutions, this data is collected from manually driven vehicles or when the ADAS module is activated. In other words, it is collected when the planned ADS module is not yet activated.

[0041] Therefore, the inventors realized that while this method of collecting data from ADAS and manually driven vehicles might be feasible for certain software components, it is not suitable for other aspects, such as decision-making and control components. In fact, it can be said that for decision-making and control components, it is crucial to test the entire system in a closed loop for validation. Furthermore, from a perception perspective, performing closed-loop testing is also advantageous, because otherwise small deviations in lateral control could lead to situations that the perception system has never been exposed to before, thus causing safety and usability issues.

[0042] In the current context, the Operational Design Domain (ODD) can be understood as a description of the operational domain in which an automated or semi-automated driving system (i.e., ADS or ADAS) is designed to have functions including but not limited to geographical restrictions, road surface restrictions, environmental restrictions, surrounding object restrictions, connectivity restrictions, and speed restrictions.

[0043] As previously mentioned, the development and validation of ADS modules is very expensive and time-consuming when moving from ADAS 22-24 (e.g., SAE J3016 Driving Automation Level 1-2) to full ADS 26 (e.g., SAE J3016 Driving Automation Level 5) 21a-21c. This is at least in part due to the fact that much attention is focused on identifying and resolving extreme cases. Extreme cases can be understood as situations that require specific design attention to handle in a reasonable and safe manner. Some of these extreme cases may occur frequently, while others may be rare. One problem with resolving extreme cases is that some of them involve rare situations and are often considered to offer little customer value (at least until the overall performance of the ADS module 26 reaches an acceptable level of safety and usability). However, identifying and resolving extreme cases is crucial if the ADS module is to be launched within a specified ODD.

[0044] In addition to issues related to handling extreme situations, there is a risk of encountering the aforementioned "curse of automation" if "linear" development (represented by line 21c) is adopted. In the current context, the curse of automation is a safety risk arising during the development phase of the boundary zone 25 between "high-end" ADAS 24 and full ADAS 26. "High-end" ADAS 24 can be understood as a driver support module that the driver perceives as high-performing but not high enough for the driver to feel psychologically or physically deprived of attention. Full ADAS 26 can be understood as a driver support module that can operate safely without human supervision.

[0045] More specifically, this zone 25, between "high-end" ADAS 24 and full ADS 26, is more capable than "high-end" ADAS 24 but remains unproven and does not possess the same capabilities as full ADS 26. Therefore, driver support modules residing in this zone 25 (which may be referred to as "AD core" modules or "undeveloped" modules) may require increasingly more driver monitoring and attention support systems 27, 28 to ensure drivers can detect and act on unmanageable extreme situations, inevitably introducing additional costs. In other words, modules residing in these "boundary zones" 25 are good enough to be perceived as full ADS 26, thus causing a relaxation of driver attention—that is, drivers may pay less attention to traffic conditions than necessary—thus reducing overall road safety.

[0046] Line segments 21a-21c illustrate the development path from ADAS to ADS, where dashed line 21c represents the traditional development method, while solid lines 21a-21b show the expected "leap" from ADAS to ADS that consumers / drivers would perceive to avoid the "curse of automation." Additionally, Figure 1b The document includes a set of boxes 31, triangles 32, and circles 33, where box 31 represents the performance of high-end ADAS 24 over time, triangles represent "driver perception performance" over time, and circles 33 represent the performance of "AD core" 25 over time. In this disclosure, the term "AD core" 25 can be used to refer to a driver support module located in the performance region 25 between "high-end" or "high-performance" ADAS 24 and full ADS 26. Failure rates may vary depending on the associated requirements of the corresponding ADAS module 24 and ADS module 26. Alternatively, "AD core" 25 can be interpreted as either a driver support module or the module upon which full ADS 26 is based. Alternatively, "AD core" 25 can be considered as a continuation of development of "high-end" ADAS 24 "on ADS-enabled" hardware.

[0047] In the following discussion, the ADAS used for the first ODD will be referred to as the "first driver support module," and the "not yet ready to start" ADS module used for the second ODD will be referred to as the "second driver support module." The first ODD and the second ODD at least partially overlap, wherein the overlapping portion of the first ODD and the second ODD is referred to as the overlapping ODD, i.e., an ODD in which both modules are capable of operation. The "not yet ready to start" ADS module may be an unverified ADS module. Furthermore, according to an exemplary embodiment, the first driver support module has a first verification failure frequency, and the second driver support module has a second verification failure frequency, the first verification failure frequency being higher than the second verification failure frequency. In other words, the second driver support module has a lower probability of dangerous failures and / or incidental events than the first driver support module. In other words, the second driver support module has a higher performance level than the first driver support module (e.g., in terms of Dynamic Driving Task (DDT) capability).

[0048] Figure 2This is a schematic flowchart representation of a method 100 for controlling a vehicle's control system. More specifically, method 100 is suitable for controlling a control system that should be executed in a vehicle in the selection of a control system. Method 100 is particularly suitable for controlling a vehicle platform by means of a driver support module (also referred to as an automated driving system module, traffic assistance module, or driver assistance module) and simultaneously performing closed-loop testing of an ADS module that is not yet ready to be activated. Additionally, the vehicle has a first driver support module and a second driver support module, wherein the first driver support module and the second driver support module are capable of operating within an overlapping ODD. In other words, the first driver support module has a first ODD, and the second driver support module has a second ODD, and the first ODD and the second ODD at least partially overlap. For example, if the first ODD includes a highway, visible lane markings, and speeds below 110 km / h, and the second ODD includes a highway, visible lane markings, daytime, and congested traffic speeds below 60 km / h, then the overlapping ODD is an ODD that meets the following criteria: during daytime traffic congestion, the vehicle is traveling on a highway with visible lane markings, and the vehicle's speed is below 60 km / h. Preferably, the second ODD is entirely inside the first ODD, that is, the second ODD is a subset of the first ODD.

[0049] Method 100 includes acquiring 101 sensor data, which includes information about the vehicle's surrounding environment. Sensor data can be acquired, for example, from the vehicle's perception system and / or positioning system. In the current context, the perception system is understood as the system responsible for acquiring raw sensor data from sensors such as cameras, LiDAR and RADAR, ultrasonic sensors, and converting that raw data into scene understanding. Naturally, sensor data can be received directly from one or more suitable sensors (e.g., cameras, LiDAR sensors, radar, ultrasonic sensors, etc.). The positioning system is a system configured to monitor the vehicle's geographic location and direction of travel, and can take the form of a Global Navigation Satellite System (GNSS) such as GPS. However, the positioning system can alternatively be implemented as Real-Time Kinematic (RTK) GPS for improved accuracy. The term sensor data also includes data acquired from HD maps, in which case information about the surrounding environment can be derived from the vehicle's map location (from its geographic location). The term "acquire" is interpreted broadly herein and encompasses receiving, retrieving, collecting, and acquiring, etc.

[0050] Furthermore, the determination of whether an overlapping ODD is satisfied is performed based on the obtained sensor data. This can be accomplished by determining the current ODD of vehicle 102 based on the obtained sensor data 101 and subsequently checking whether vehicle 103 is currently in an ODD compatible with or capable of operating within the first driver assistance module and the second driver assistance module. In other words, the method may include checking whether the current ODD of 102 determined by 103 is an "overlapping ODD".

[0051] Then, if the current ODD determined by 102 is an overlapping ODD, method 100 includes switching 104 between a first configuration in which the first driver support module is activated and the second driver support module is not activated, and a second configuration in which the first driver support module is not activated and the second driver support module is activated. The switching 104 between the first and second configurations is based on a switching protocol so that a closed-loop test of the second driver support module is performed during at least a portion of the time period during which the vehicle is within the overlapping ODD.

[0052] In other words, once it is confirmed that the vehicle is in an ODD compatible with both the first driver support module (e.g., "high-end" ADAS) and the second driver support module (e.g., "AD core"), the control of the vehicle platform is divided between the ADAS and the AD core according to a switching protocol. For example, the switching protocol could be a predefined timing scheme that instructs the second driver support module to assume control for 50%–90% of the time period during which the vehicle is within the overlapping ODD.

[0053] However, if it is determined that the current ODD of vehicle 103 is not an ODD compatible with one or both of the first and second driver support modules, the method can include various backup options. For example, if the current ODD is an ODD in which neither the first nor the second driver support module can operate, for example, due to the vehicle leaving the overlapping ODD, method 100 can include: enabling or activating a third driver support module (ADAS or AD) configured for the current ODD, or initiating a handover to the driver. Therefore, since method 100 can also include a "safety net" in the event that the vehicle accidentally or intentionally leaves the "overlapping ODD," the requirement to ensure the vehicle remains within the designated ODD can be mitigated. Naturally, in cases where the first driver support module can operate within the current ODD but the second driver support module cannot (i.e., the overlapping ODD is not satisfied, but the ODD of the first driver support module is satisfied), the first driver support module can be activated while the second driver support module is blocked. This will refer to... Figure 3b Further examples will be provided.

[0054] Naturally, the determination of the overlapping ODD can be performed after selecting the first driver support module and the second driver support module, without departing from the scope of this disclosure. For example, the driver can select the operation of the first driver support module, and then a check is performed if the vehicle is within the ODD in which the first driver support module can operate. Additionally, another check is performed to see if the second driver support module can operate within the current ODD. Therefore, if it is determined that the vehicle is currently within the "overlapping ODD" of the first and second driver support modules, the switching procedure 104 can be initiated.

[0055] Refer again Figure 1b The effect of this "switch" is illustrated by box 31, triangle 32, and circle 33. As mentioned, box 31 represents the expected performance of the high-end ADAS 24 over time, triangle 32 represents the expected "driver-perceived performance" over time, and circle 33 represents the expected performance of the "AD core" 25 over time. As previously stated, the challenge when attempting to move from ADAS to a mature AD module is the "curse of automation," which suggests that the perceived quality of the control system is so good that it induces a "pseudo-safety" in the driver, making him or her less attentive to surrounding traffic even if the control system is not safe enough to operate without supervision.

[0056] Continuing, as shown in circle 33, over time, development of the "AD core" portion will continue and improve in terms of failure rate, while the "high-end" ADAS remains at a static performance level for this ODD. However, by switching the control system between the "high-end" ADAS and the "AD core," the driver's "perception performance" can remain outside the "cursed zone of automation" 25.

[0057] Additionally, the switching protocol may include a predefined time scheme comprising instructions to select the second configuration for 25% to 95% of the duration of the time period, or more preferably 50% to 90% of the duration of the time period, and to select the first configuration for the remainder of the time period. This is because the benefit of increasing the closed-loop test time from 90% to, for example, 99% is less than the decreasing trend of increased risk from moving the expected "perceived performance" 32 into the "curse of automation" region 25. Here, the time period is understood as the period during which the ODD requirements of both the first driver support module and the second driver support module are met, or in other words, the period during which the vehicle is within the overlap of the ODDs of the first driver support module and the second driver support module.

[0058] Figure 3aThis is a schematic flowchart illustrating a method performed by a vehicle control system according to embodiments of the present disclosure. The control system is adapted to enable closed-loop testing of an ADS module that has not yet been activated against a specified ODD. The control system includes a first driver support module 45 and a second driver support module 46. Both the first driver support module 45 and the second driver support module 46 are capable of operating within an overlapping Operational Design Domain (ODD). According to an exemplary embodiment of the present disclosure, the first driver support module 45 has a first defined performance level, and the second driver assistance module 46 has a second defined performance level that is higher than the first defined performance level.

[0059] Additionally, the control system includes suitable control circuitry (also referred to as a control unit, control circuit, controller, processor, etc.) for performing the various functional steps described below. The control circuitry is configured to acquire sensor data 40, including information about the vehicle's surrounding environment. Furthermore, the control circuitry is configured to determine the satisfaction of overlapping ODDs based on the acquired sensor data. The system may include an ODD determination module 41 for this task. Once the current ODD is determined, a check 42 can be performed to determine whether overlapping ODDs are satisfied (i.e., whether both the first driver support module 45 and the second driver support module 46 are compatible with the current ODD).

[0060] If the overlapping ODD is satisfied, the control circuit is configured to switch 43 between a first configuration in which the first driver support module is activated and the second driver support module is not activated, and a second configuration in which the first driver support module is not activated and the second driver support module is activated. In other words, the control circuit is configured to control the switching function 47 to switch between the first and second configurations.

[0061] Furthermore, the switching 43 between the first and second configurations is based on a switching protocol 44 to perform closed-loop testing of the second driver support module during at least a portion of the time period in which the vehicle is in an environment satisfying the overlapping ODD. In the current context, the active driver support modules 45, 46 can be understood as being configured to generate control signals for the vehicle's control system 48 to control at least one of the vehicle's steering angle, acceleration, and deceleration. Conversely, the "inactive" driver support modules do not control any maneuvering of the vehicle. However, the "inactive" driver support modules may still "generate control signals," but these control signals are not used as inputs to the vehicle platform (i.e., not used to manipulate the actual vehicle). Alternatively, the control signals generated by the "inactive" modules can be used to verify the compatibility between the module and the satisfied overlapping ODD by running the module in "background mode," i.e., dark start can be performed.

[0062] Naturally, the "switching" can be implemented in various ways and does not necessarily involve only abrupt switching between driver support modules 45 and 46. Instead, in some embodiments, the switching protocol 44 may include some overlap, such that control is "gradually entered" and "gradually exited" from the driver support modules to reduce the risk of abruptness or passenger discomfort. In other words, during the transition between the first and second configurations, the mixing of outputs (signals) from the first driver support module 45 and the second driver support module 46 can be used to achieve a smooth transition. For example, the switching protocol 44 may include a 0-3s transition phase in which the outputs from the first driver support module 45 and the second driver support module 46 are mixed / fused.

[0063] Additionally, the switching protocol 44 may include a predefined time scheme comprising instructions for: selecting a second configuration during 1% to 99% of the duration of the time period, preferably during 25% to 95% of the duration of the time period, and more preferably during 50% to 90% of the duration of the time period; and selecting a first configuration for the remaining portion of the time period. The predefined time scheme may be configured such that specified time portions of the time period are reserved for the first configuration (e.g., the first 5% and the last 5%, or 1 minute every 10 minutes).

[0064] Alternatively, the predefined timing scheme can be dynamic (or stochastic), such that the portion of time reserved for the first configuration is randomly distributed throughout the time period. Here, the method may further include the step of determining / predicting / estimating the time period during which the vehicle will be in an environment satisfying overlapping ODDs.

[0065] Figure 3b This is a schematic flowchart illustrating a method for controlling a vehicle according to another embodiment of the present disclosure. Figure 3b Several features and functions of the embodiments have been previously referred to. Figure 3a A detailed description has been provided, and for the sake of brevity and conciseness, no explicit detailed discussion will be given. Instead, the focus will be on different parts, specifically the ODD determination module 41 and the determination 50 of ODD satisfaction, as well as the results of various scenarios. Similar to what was discussed previously, the first driver support module is the verified and deployed ADAS function, while the second support module is the "AD core" function, i.e., the unverified / incomplete ADS function.

[0066] More specifically, ODD determination 41 includes the step of verifying that the ODDs of the first driver support module and the second driver support module are satisfied, respectively. This verification is presented in tabular form, showing four different scenarios. In the first scenario, the ODD of the first driver support module is satisfied, while the ODD of the second driver support module is not satisfied. Therefore, in the first scenario, the first driver support module can be activated 45 and used to provide 48 control signals (e.g., longitudinal / lateral motion control) to the vehicle platform. In the second scenario, the ODDs of both the first and second driver support modules are satisfied (i.e., overlapping ODDs are satisfied). Therefore, in the second scenario, both the first and second driver support modules are activated 45, 46, and when the vehicle is in an environment where overlapping ODDs are satisfied, a switch 43 between the first and second configurations is performed based on the switching protocol 44.

[0067] In the third scenario, the ODD of the first driver support module is not satisfied, while the ODD of the second driver support module is satisfied. Since the second driver support module is an unverified / incomplete function, it is not permitted to independently control the 48 vehicle platform. Therefore, in the third scenario, handover to the vehicle driver or the third driver support module can be activated (if the ODD of the third driver support module is satisfied). In the fourth scenario, neither the ODDs of the first nor the driver support modules are satisfied, and the result is the same as in the third scenario.

[0068] Figure 4 This is a schematic block diagram of a control system 10 for a vehicle according to an embodiment of the present disclosure. The control system 10 has a first driver support arrangement 52a and a second driver support arrangement 52b. The first driver support arrangement 52a includes a first driver support module in the form of ADAS Lane Keeping Assist (LKA) and Adaptive Cruise Control (ACC) 45a and a second driver support module in the form of Traffic Jam Assist 46a. Here, ADAS LKA+ACC 45a can be considered as “low-level” Traffic Jam Assist. Both ADAS LKA+ACC 45a and Traffic Jam Assist 46a are capable of operating within a first overlapping ODD. Further, the control system 10 has a second driver support arrangement 52b, which includes a first driver support module in the form of ADAS Lane Keeping Assist (LKA) and Adaptive Cruise Control (ACC) 45b and a second driver support module in the form of Highway Assist 46b. Similarly, ADAS LKA+ACC 45b and Highway Assist 46b are capable of operating within a second overlapping ODD. The two ADAS LKA+ACC modules 45a and 45b can be implemented as a single module, but for clarity they are shown here as separate units.

[0069] More specifically, the first driver support arrangement 52a can be interpreted as a traffic congestion support module, comprising a validated ADAS module 45a (i.e., a “low-performance” driver support feature) and an unvalidated ADS module 46a (i.e., a “high-performance” driver support feature). Therefore, assuming the ODD is a traffic congestion scenario (e.g., multi-lane, speed <30 km / h, clear lane markings, dense traffic), the two driver support modules 45a and 46a can have overlapping ODDs under the specified conditions, once so, the switching between the two driver support modules 45a and 46a can be initiated as described herein. Similarly, the second driver support arrangement 52b can be interpreted as a highway support module, comprising a validated ADAS module 45b (i.e., a “low-performance” driver support feature) and an unvalidated ADS module 46b (i.e., a “high-performance” driver support feature).

[0070] The system further includes control circuitry configured to acquire sensor data 40 and determine the current ODD based on the acquired sensor data 40 (i.e., to verify the satisfaction of overlapping ODDs). ODD determination can be performed by a dedicated ODD determination module 41. (Refer to reference...) Figures 3a to 3b The discussed embodiments are similar. Figure 4 The control circuitry of the control system 10 shown is configured to switch 43 between a first configuration in which the first driver support arrangements 45a, 45b are activated and the second driver support arrangements 46a, 46b are deactivated, and a second configuration in which the first driver support arrangements 45a, 45b are deactivated and the second driver support arrangements 46a, 46b are activated. Furthermore, the switching between the first and second configurations is based on a switching protocol 44 to perform a closed-loop test of the second driver support arrangements 46a, 46b during at least a portion of the time period during which the vehicle is within the overlapping ODD.

[0071] Furthermore, the control system 10 has one or more safety systems 53 configured to generate control signals to the vehicle platform 48 to maneuver the vehicle in emergency situations (e.g., collision avoidance, emergency braking, etc.). The one or more safety systems 53 may be arranged to override any control signals generated by driver support 52a, 52b.

[0072] Executable instructions for performing these functions may optionally be included in a (non-transitory) computer-readable storage medium or other computer program product configured to be executed by one or more processors.

[0073] Figure 5 This is a schematic diagram illustrating a method for controlling a vehicle according to an embodiment of the present disclosure. More specifically, Figure 5This illustrates a defined example of how ODD satisfaction can be achieved. The vehicle is provided with a first driver support module and a second driver support module. The first driver support module (first line) can be a low-speed highway assist form. More specifically, the first driver support module can be configured to control DDT (i.e., continuous lateral and longitudinal vehicle motion control) for low-speed vehicles on highways, but relies on the driver to perform object and event detection and response (OEDR). The first driver support module is capable of operating within a first ODD with a first set of predefined ODD metrics: the vehicle is traveling at speeds below 120 km / h on a highway (e.g., entering a controlled highway). The second driver support module (second line from the top) can be an unproven (or “under development”) ADS module in the form of traffic congestion navigation.

[0074] More specifically, the second driver support module can be configured to control DDT, OEDR, and DDT backoff (i.e., automatically implement minimum risk conditions when necessary) without any expectation of driver intervention. The second driver support module is capable of operating within a second ODD with a second set of predefined ODD metrics: vehicles traveling during the day at speeds below 60 km / h on congested highways (e.g., entering a controlled highway).

[0075] The first row 75 and the second row 76 indicate, respectively, ODD satisfaction 72 for the first driver support module and the second driver support module at each time sample (denoted by ODD det.). Therefore, the method may include: determining the current ODD of the vehicle at a sampling rate; and determining ODD satisfaction 72 for each of the first driver support module and the second driver support module. In some embodiments, the method may include determining satisfaction of both the first ODD and the second ODD (i.e., satisfaction of the overlapping ODD). The current ODD is indicated in the third row from the top by presenting a set of ODD parameters 73a-d derived from acquired sensor data. At the first time sample used to determine ODD satisfaction, the current ODD includes the following ODD parameters: the vehicle is traveling at night 73a at a speed 55 km / h 73b on a highway 73c. ​​These ODD parameters are then compared with ODD metrics of the first ODD and the second ODD to determine satisfaction 72 of the first ODD and the second ODD (and thus determine satisfaction of the overlapping ODD). Figure 5 As shown in Figures 71 and 72, at the first sampling point, only the second ODD is satisfied. Therefore, since only the first driver support module can operate within the vehicle's current ODD, switching between the first and second configurations is not possible (indicated by "OFF" in the last line 74).

[0076] Continuing, at the second time sampling point, the vehicle's current ODD includes the following parameters: the vehicle is traveling on a highway 73c at a speed of 55 km / h during the day 73a. Therefore, at the second time sampling point, the first ODD is satisfied while the second ODD is not satisfied. Thus, as in the first time sampling point, overlapping ODDs are not satisfied, and switching between the first and second configurations is not possible.

[0077] At the third time sampling point, the vehicle's current ODD includes the following parameters: the vehicle is traveling at a speed of 30 km / h on highway 73c during daytime 73a and traffic congestion 73d. Therefore, at the second time sampling point, both the first and second ODDs are satisfied, and thus, the overlapping ODDs are satisfied. Therefore, switching between the first and second configurations is possible, as indicated by the "ON" symbol in the last line. For clarity and brevity, lengthy and detailed discussions related to subsequent time sampling have been omitted; however, those skilled in the art will readily understand the concept and be able to interpret the illustrated examples based on the foregoing disclosure.

[0078] Figure 6 These are a series of schematic Venn diagrams illustrating the evolution of driver assistance modules and their ODD coverage over time, which can be facilitated by the methods of this disclosure, computer-readable storage media, control systems, and vehicles including such control systems. More specifically, Figure 6 The diagram illustrates how the ODD coverage of “high-end” ADAS 61a-61d increases over time (i.e., “high-end” ADAS can operate within a larger ODD over time), and how the ODD coverage of “AD cores” (which can be interpreted as unverified AD products) 62a-c increases over time. Additionally, Figure 6 It also shows how the ODD coverage of the “mature” ADDS products 63a-b evolved from the “AD core”. In addition, the overlapping ODD of the “high-end” ADDS 61a-c and the “AD core” 62a-c is the full ODD coverage of the “AD core” 62a-c.

[0079] The proposed switching procedure discussed above enables centralized and efficient ADS development by expanding the ODD coverage of ADS products 63a-b within the ODD coverage of "high-end" ADAS. In other words, it enables the effective utilization of development and validation resources used to transition the automotive industry from "low-level" ADS to "high-level" ADS.

[0080] Figure 7This is a schematic side view of vehicle 1, including a control system 10 for vehicle 1. The control system 10 has a first driver support module and a second driver support module, each configured for overlapping ODDs. Vehicle 1 further includes a perception system 6 and a positioning system 5. In the current context, the perception system 6 is understood to be responsible for acquiring raw sensor data from sensors 6a, 6b, 6c such as cameras, LiDAR and RADAR, and ultrasonic sensors, and converting that raw data into scene understanding. The positioning system 5 is configured to monitor the vehicle's geographic location and direction of travel, and may take the form of a Global Navigation Satellite System (GNSS) such as GPS. However, the positioning system may alternatively be implemented as Real-Time Kinematic (RTK) GPS for improved accuracy.

[0081] The control device 10 includes one or more processors 11, a memory 12, a sensor interface 13, and a communication interface 14. The processor 11 may also be referred to as control circuitry 11. Control circuitry 11 is configured to execute instructions stored in the memory 12 to perform a method for controlling a vehicle according to any of the embodiments disclosed herein. In other words, the memory 12 of the control device 10 may include one or more (non-transitory) computer-readable storage media for storing computer-executable instructions, which, when executed by one or more computer processors 11, may cause the computer processors 11 to perform, for example, the techniques described herein. The memory 12 may optionally include high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices; and may optionally include non-volatile memory, such as one or more disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices.

[0082] More specifically, the control circuit 11 is further configured to acquire sensor data from the vehicle 1's perception system 6 and / or positioning system. The sensor data includes information about the vehicle's surrounding environment. The control circuit 11 is further configured to determine the current satisfaction of the overlapping ODD based on the acquired sensor data. Additionally, if the overlapping ODD is satisfied, the control circuit 11 is configured to switch between a first configuration in which the first driver support module is activated and the second driver support module is not activated, and a second configuration in which the first driver support module is not activated and the second driver support module is activated. The switching between the first and second configurations is based on a switching protocol to perform a closed-loop test of the second driver support module during at least a portion of the time period during which the vehicle 1 is within the overlapping ODD.

[0083] The activated driver support module is configured to generate control signals for the vehicle's control system to control at least one of the vehicle 1's steering angle, vehicle 1's acceleration, and vehicle 1's deceleration. As mentioned, sensor data may include vehicle data (e.g., vehicle speed, vehicle direction of travel, etc.), the vehicle's geographic location, external object data (e.g., the presence of other vehicles, the relative speed difference between the vehicle 1 and surrounding vehicles, the presence of pedestrians, cyclists, etc.), map data, and any other data suitable for determining the current ODD of the vehicle 1. Even though the control circuit 11 is shown here as an in-vehicle system, some or all components may be located at a remote location within the vehicle (e.g., a cloud-based solution) to enhance computing power.

[0084] Furthermore, vehicle 1 can connect to external network 2 via, for example, a wireless link (e.g., for acquiring map data). The same wireless link, or several other wireless links, can be used to communicate with other vehicles in the vicinity or with local infrastructure components. Cellular communication technology can be used for long-distance communication, such as with external networks, and if the cellular communication technology used has low latency, it can also be used for communication between vehicles, vehicle-to-vehicle (V2V), and / or vehicle-to-infrastructure (V2X). Examples of cellular radio technologies are GSM, GPRS, EDGE, LTE, 5G, and 5G NR, as well as future cellular solutions. However, some solutions utilize short-to-medium range communication technologies, such as wireless local area networks (LANs), for example, solutions based on IEEE 802.11. ETSI is developing cellular standards for vehicle communication, and 5G, for example, is considered a suitable solution due to its low latency and efficient handling of high bandwidth and communication channels.

[0085] The present disclosure has been presented above with reference to specific embodiments. However, other embodiments besides those described above are also possible and are within the scope of this disclosure. Within the scope of this disclosure, method steps different from those described above, performed by hardware or software, can be provided. Therefore, according to an exemplary embodiment, a non-transitory computer-readable storage medium is provided storing one or more programs configured to be executed by one or more processors of a vehicle control system, the one or more programs including instructions for performing the methods according to any of the embodiments discussed above. Alternatively, according to another exemplary embodiment, a cloud computing system can be configured to perform any of the methods presented herein. The cloud computing system may include distributed cloud computing resources that jointly perform the methods presented herein under the control of one or more computer program products.

[0086] Generally, computer-accessible media can include any tangible or non-transitory storage medium or memory medium, such as electronic, magnetic, or optical media, for example, a disk or CD / DVD-ROM coupled to a computer system via a bus. As used herein, the terms “tangible” and “non-transitory” are intended to describe computer-readable storage media (or “memory”) while excluding media that transmit electromagnetic signals, but are not intended to further limit the types of physical computer-readable storage devices covered by the phrases “computer-readable medium” or “memory.” For example, the terms “non-transitory computer-readable medium” or “tangible memory” are intended to cover types of storage devices that do not necessarily permanently store information, including, for example, random access memory (RAM). Program instructions and data stored in a non-transitory form on a tangible computer-accessible storage medium can be further transmitted via a transmission medium or a signal such as an electrical, electromagnetic, or digital signal that can be transmitted via a communication medium such as a network and / or a wireless link.

[0087] The processor 11 (as associated with control system 10) may be or include any number of hardware components for transmitting data or signal processing or for executing computer code stored in memory 12. Device 10 has an associated memory 12, and memory 12 may be one or more devices for storing data and / or computer code for performing or facilitating the various methods described herein. Memory may include volatile or non-volatile memory. Memory 12 may include database components, object code components, script components, or any other type of information structure for supporting the various activities described herein. According to exemplary embodiments, any distributed or local memory device may be used with the systems and methods described herein. According to exemplary embodiments, memory 12 may be communicatively connected to processor 11 (e.g., via circuitry or any other wired, wireless, or network connection) and includes computer code for performing one or more of the processes described herein.

[0088] It should be understood that sensor interface 13 can also provide the possibility of acquiring sensor data directly or via dedicated sensor control circuitry 6 in the vehicle. Communication / antenna interface 14 can further provide the possibility of transmitting output to a remote location (e.g., a remote operator or control center) via antenna 8. Additionally, some sensors in the vehicle can communicate with the control system 10 using a local network setup such as CAN bus, I2C, Ethernet, and fiber optics. Communication interface 14 can be arranged to communicate with other control functions of the vehicle and can therefore also be considered a control interface; however, a separate control interface (not shown) can also be provided. Local communication within the vehicle can also be wireless, using protocols such as Wi-Fi, LoRa, Zigbee, Bluetooth, or similar medium / short-range technologies.

[0089] Therefore, it should be understood that parts of the described solution can be implemented in vehicle 1, in a system located outside vehicle 1, or in a combination of inside and outside vehicle 1; for example, in a server communicating with vehicle 1, i.e., a so-called cloud solution. For example, sensor data can be sent to an external system, and that system performs some or all of the necessary steps to determine the satisfaction of overlapping ODDs. Different modules and steps of the embodiments can be combined in other ways different from those described.

[0090] While the accompanying drawings may show a specific order of method steps, the order of steps may differ from the depicted order. Furthermore, two or more steps may be performed simultaneously or partially simultaneously. This variation will depend on the chosen software and hardware system and the designer's choices. All such variations are within the scope of this disclosure. Similarly, software implementations can be accomplished using standard programming techniques with rule-based logic and other logic to perform various connection steps, processing steps, comparison steps, and decision steps. The embodiments mentioned and described above are given by way of example only and should not be construed as limiting the scope of this disclosure. Other solutions, uses, purposes, and functions claimed within the scope of this disclosure in the patent embodiments described below will be apparent to those skilled in the art.

Claims

1. A method for controlling a vehicle, the vehicle having a first driver support module and a second driver support module, wherein the first driver support module and the second driver support module are capable of operating within an overlapping operational design domain (ODD), the method comprising: Obtain sensor data including information about the vehicle's surrounding environment; The satisfaction of the overlapping ODD is determined based on the obtained sensor data; If the overlapping ODD is satisfied, a switch is made between a first configuration and a second configuration, in which the first driver support module is activated and the second driver support module is not activated, and in the second configuration, the first driver support module is not activated and the second driver support module is activated. The switching between the first configuration and the second configuration is based on a switching protocol so that a closed-loop test of the second driver support module is performed during at least a portion of the time period in which the vehicle is in an environment that satisfies the overlapping ODD.

2. The method of claim 1, wherein the sensor data is obtained from: A perception system including at least one sensor device configured to monitor the vehicle's surrounding environment, and A positioning system configured to determine the geographical location of the vehicle.

3. The method according to claim 1, wherein, The overlapping ODDs include an overlapping set of predefined ODD metrics, and the method further includes: A set of ODD parameters derived from the obtained sensor data is compared with a set of predefined ODD metrics that overlap to determine whether the overlapping ODDs are satisfied.

4. The method according to any one of claims 1-3, wherein the activated driver support module is arranged to generate control signals for the control system of the vehicle to control at least one of the vehicle's steering angle, the vehicle's acceleration, and the vehicle's deceleration.

5. The method according to any one of claims 1-3, wherein the switching protocol includes a predefined timing scheme, the predefined timing scheme including instructions for selecting the second configuration during 1% to 99.9% of the duration of the time period and selecting the first configuration during the remainder of the time period.

6. The method according to any one of claims 1-3, wherein the first driver support module has a first defined performance level and the second driver support module has a second defined performance level, the first defined performance level being lower than the second defined performance level.

7. The method according to any one of claims 1-3, further comprising: Before switching between the first configuration and the second configuration: While activating the first driver support module, the second driver support module is run in background mode to perform a verification of the compatibility between the satisfied overlapping ODD and the second driver support module.

8. The method according to any one of claims 1-3, wherein the information about the surrounding environment includes at least one of the vehicle's geographical location, weather data, traffic density, road type, and relative speed of surrounding vehicles.

9. A computer-readable storage medium storing one or more programs configured to be executed by one or more processors of a vehicle control system, the one or more programs including instructions for performing the method according to any one of the preceding claims.

10. A control system for a vehicle, the control system comprising: A first driver support module and a second driver support module, wherein the first driver support module and the second driver support module are capable of operating within an overlapping operational design domain (ODD); The control circuit is configured as follows: Obtain sensor data including information about the vehicle's surrounding environment; The satisfaction of the overlapping ODD is determined based on the obtained sensor data; If the overlapping ODD is satisfied, a switch is made between a first configuration and a second configuration, in which the first driver support module is activated and the second driver support module is not activated, and in the second configuration, the first driver support module is not activated and the second driver support module is activated. The switching between the first configuration and the second configuration is based on a switching protocol so that a closed-loop test of the second driver support module is performed during at least a portion of the time period in which the vehicle is in an environment that satisfies the overlapping ODD.

11. The control system of claim 10, wherein the overlapping ODD comprises an overlapping set of predefined ODD metrics, and wherein the control circuit is further configured to: A set of ODD parameters derived from the obtained sensor data is compared with a set of predefined ODD metrics that overlap to determine whether the overlapping ODDs are satisfied.

12. The control system of claim 10 or 11, wherein the activated driver support module is arranged to generate control signals for the control system of the vehicle to control at least one of the vehicle's steering angle, the vehicle's acceleration, and the vehicle's deceleration.

13. The control system of claim 10 or 11, wherein the switching protocol includes a predefined timing scheme, the predefined timing scheme including instructions for selecting the second configuration during 1% to 99% of the duration of the time period and selecting the first configuration during the remainder of the time period.

14. The control system according to claim 10 or 11, wherein the first driver support module has a first defined performance level and the second driver support module has a second defined performance level, the first defined performance level being lower than the second defined performance level.

15. A vehicle comprising: A perception system including at least one sensor device configured to monitor the vehicle's surrounding environment. A positioning system configured to determine the geographical location of the vehicle; and The control system according to any one of claims 10-14.

Images