Patent ID: 12233888

DETAILED DESCRIPTION

Those skilled in the art will appreciate that the steps, services and functions explained herein may be implemented using individual hardware circuitry, using software functioning in conjunction with a programmed microprocessor or general purpose computer, using one or more Application Specific Integrated Circuits (ASICs) and/or using one or more Digital Signal Processors (DSPs). It will also be appreciated that when the present disclosure is described in terms of a method, it may 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.

In the following description of exemplary embodiments, the same reference numerals denote the same or similar components. Even though the following disclosure mainly discusses vehicles in the form of cars, the skilled reader readily realizes that the teachings discussed herein are applicable to other forms of vehicles such as trucks, buses and construction equipment.

FIGS.1a-1bare schematic charts that illustrate a development from a basic driver assistance module22to a mature ADS module (may also be referred to as an AD module)26over time (x-axis) for an arbitrary Operational Design Domain (ODD). The y-axis denotes a probability of failure over driving hours, and more specifically “failures” are in the present context to be interpreted as fatal failures if not corrected by the driver. TheFIGS.1a-1bfurther contain a set of lines21a-21crunning across the driver support modules22-26, indicating a path of development/deployment over time.

Note that the number of occasions which require human intervention to avoid incidents and minor accidents can be much higher than the number of “failures”. Naturally all such events contribute to how the drivers perceive the feature hence the risk of increased driver reaction times and “curse of automation”. Depending on the mix of incidents/failures of difference character and magnitude, the switching protocol may be tuned in different ways to maximize the time that the second driver support module is active without exposing the driver to “the curse of automation”.

Data collection plays a key role in enabling an efficient development of high performance or high-end ADAS and ADS modules. It is often mentioned that driven mileage is a good indicator of a maturity level of an ADS module. However, in presently known solutions this data is collected from manually driven vehicles or while an ADAS module is active. In other words, when the intended ADS module is not active.

Thus, the present inventors realized that even though this approach of collecting data from ADAS and manually driven vehicles may work for some software components, it is not as applicable for other aspects such as decision and control components. In fact, one can say that it is crucial for decision and control components to test the complete system in closed loop for verification. Moreover, it may also be advantageous from a perception perspective to perform closed-loop testing since small deviations in lateral control otherwise may lead to situations that the perception system(s) have never been exposed to before and hence to safety and availability problems.

An Operational Design Domain (ODD) may in the present context be understood as a description of the operating domains in which an autonomous or a semi-autonomous driving system (i.e. ADS or ADAS) is designed to function, including, but not limited to, geographic limitations, roadway limitations, environmental limitations, surrounding object limitations, connectivity limitations, and speed limitations.

As mentioned in the foregoing, when moving21a-21cfrom ADAS22-24(e.g. SAE J3016 driving automation level 1-2) to full ADS26(e.g. SAE J3016 driving automation level 5), the development and verification of ADS modules are very costly and time consuming. This is at least partly due to the fact that a lot of attention is focused on identifying and solving corner cases. Corner cases may be understood as situations that need specific design attention in order to be handled in a reasonable and safe manner Some of the corner cases can be frequently occurring while other may be rare. A problem with solving corner cases is the fact that some of them relate to rare situations and are often considered to provide little to no customer value, at least not until the overall performance of the ADS module26has reached an acceptable level for safety and availability. However, identifying and solving corner cases is crucial if one is to ever launch an ADS module within a specified ODD.

Moreover, aside from the problems associated with the handling of the corner cases, if one adopts a “linear” development (represented by line21c) there is a risk of running into the previously mentioned “curse of automation”. The curse of automation is in the present context as an induced safety risk during the development stages in the borderlands25between “high-end” ADAS24and full AD26. “High-end” ADAS24may be understood as a driver support module that the drivers perceive as high performing but not so high that the drivers think that they mentally or physically can drop their attention. Full ADS26may be understood as a driver support module that can operate safely without human supervision.

In more detail, this region25between “high-end” ADAS24and full ADS26is more capable than “high-end” ADAS24but it is still not verified nor as capable as full ADS26. Therefore driver support modules residing in this region25(may be referred to as “AD core” modules or “under-development” modules) may require more and more driver monitoring and attention support systems27,28to assure that the driver will be able to detect and act on corner cases that cannot be dealt with, which unavoidably introduces additional costs. In other words, the modules residing in these “borderlands”25are good enough to be perceived as full ADS26and for this reason induce a leniency in driver attention, i.e. the drivers may pay less attention to the traffic situation than necessary, rendering in reduced overall road safety.

The line segments21a-21cillustrate development paths when going from ADAS to ADS, where the dashed line21crepresent the conventional development approach and the solid lines21a-21billustrate a desired “jump” from ADAS to ADS that is to be perceived by consumers/drivers in order to avoid the “curse of automation”. Furthermore,FIG.1bcontains a set of boxes31, triangles32, and circles33where the boxes31represent the performance over time for the high-end ADAS24, the triangles represent the “driver perceived performance” over time, and the circles33represent the “AD core”25performance over time. In the present disclosure the term “AD core”25can be used to denote driver support modules which are in the performance region25between “high-end” or “high-performing” ADAS24and full ADS26. The failure rates may vary depending on what the associated requirements are for the corresponding ADAS module24and ADS module26. Moreover, “AD core”25can be construed as driver support modules or modules upon which full ADS26is to be based. Alternatively, one can view “AD core”25, as the continuous development of “high-end” ADAS24running on “ADS-ready” hardware.

In the following discussion, an ADAS for a first ODD will be referred to as “a first driver support module”, and a “not-yet-ready-for-launch” ADS module for a second ODD will be referred to as “a second driver support module”. The first and second ODDs are at least partly overlapping, where the overlapping part of the first and second ODDs is referred to as an overlapping ODD, i.e. an ODD within which both modules are capable of operation. The “not-yet-ready-for-launch” ADS module may be an unverified ADS module. Moreover, in accordance with an exemplary embodiment, the first driver support module has a first verified frequency of failures and the second driver assistance module has a second verified frequency of failures, the first verified frequency of failures being higher than the second verified frequency of failures. In other words, the second driver support module has a lower probability of dangerous failure and/or incidents 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).

FIG.2is a schematic flow chart representation of a method100for controlling a control system of a vehicle. More specifically, the method100is suitable for controlling which, in a selection of control systems, shall be executed in a vehicle. The method100is particularly suitable for controlling a vehicle platform by means of a driver support module (may also be known as an automated driving system module, a traffic assist module, or a driver assist module), and simultaneously perform closed-loop testing of not-yet-ready-to-be-launched ADS modules. Moreover, 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 operation within an overlapping ODD. Stated differently, the first driver support module has a first ODD and the second driver support module has a second ODD, and the first and second ODD are at least partly overlapping. For example, if the first ODD comprises highway, visible lane markings, and speed below 110 km/h km/h, and the second ODD comprises highway, visible lane markings, daytime, and speed below 60 km/h in a traffic jam, then an overlapping ODD would be an ODD fulfilling the following criteria: the vehicle is traveling on a highway with visible lane markings during daytime in a traffic jam and a speed of the vehicle is below 60 km/h. Preferably, the second ODD is fully inside of the first ODD, i.e. the second ODD is a subset of the first ODD.

The method100comprises obtaining101sensor data comprising information about a surrounding environment of the vehicle. The sensor data may for example be obtained101from a perception system and/or a localization system of the vehicle. A perception system is in the present context to be understood as a system responsible for acquiring raw sensor data from on sensors such as cameras, LIDARs and RADARs, ultrasonic sensors, and converting this raw data into scene understanding. Naturally, the sensor data may be received directly from one or more suitable sensors (such as e.g. cameras, LIDAR sensors, radars, ultrasonic sensors, etc.). The localization system is a system configured to monitor a geographical position and heading of the vehicle, and may in the form of a Global Navigation Satellite System (GNSS), such as a GPS. However, the localization system may alternatively be realized as a Real Time Kinematics (RTK) GPS in order to improve accuracy. The term sensor data also includes data obtained from an HD map where information about the surrounding environment may be based on the vehicle's map position (derived from its geographical position). The term obtaining is herein to be interpreted broadly and encompasses receiving, retrieving, collecting, acquiring, and so forth.

Further, a determination of a fulfilment of the overlapping ODD based on the obtained sensor data is performed. This, may be done by determining102a current ODD of the vehicle102based on the obtained101sensor data, and subsequently checking103whether the vehicle is currently in an ODD that the first and second driver support modules are compatible with or capable of operating within. Stated differently, the method may comprise checking103whether or not the determined102current ODD is an “overlapping ODD”.

Then, if the determined102current ODD is an overlapping ODD, the method100comprises switching104between a first configuration where the first driver support module is active and the second driver support module is inactive, and a second configuration where the first driver support module is inactive and the second driver support module is active. The switching104between the first configuration and the second configuration is based on a switching protocol in order to perform closed loop testing of the second driver support module for at least portion of a time period that the vehicle is within the overlapping ODD.

Stated differently, once it is confirmed that the vehicle is in an ODD compatible with both of the first driver support module (e.g. “high-end” ADAS) and second driver support module (e.g. “AD core”), then the control of the vehicle platform is divided between the ADAS and the AD core according to the switching protocol. For example, the switching protocol may be a predefined time scheme that dictates that the second driver support module assumes control for 50%-90% of the time period that the vehicle is within the overlapping ODD.

However, if it would be determined103that the current ODD of the vehicle is not an ODD compatible with either one or both of the first and second driver support modules, then the method may comprise various fall-back alternatives. For example, if the current ODD is an ODD that neither one of the first and second driver support modules are capable of operating within, e.g. due to the vehicle exiting the overlapping ODD, then the method100may comprise enabling or activating105a third driver support module (ADAS or AD) configured for the current ODD or to initiate105a hand-over to the driver. Accordingly, the requirement to ensure that the vehicle stays within a specific ODD may be alleviated since the method100also may comprise a “safety net” if the vehicle unexpectedly or deliberately leaves the “overlapping ODD”. Naturally, in a scenario where the first driver support module is capable of operating within the current ODD and the second driver support module is not capable of operating within the current ODD (i.e. overlapping ODD is not fulfilled, but an ODD of the first driver support module is fulfilled), then the first driver support module may be active while the second driver support module is suppressed. This will be further exemplified in reference toFIG.3b.

Naturally, the determination of a fulfilment of the overlapping ODD may be performed after the first and second driver support modules are selected without departing from the scope of the present disclosure. For example, a driver may select operation of a first driver support module, then a check is performed if the vehicle is within an ODD that the first driver support module is capable of operating within. Moreover, another check is performed to see if a second driver support module is capable of operating within the current ODD. Accordingly, if it is determined that the vehicle is currently within an “overlapping ODD” of the first and second driver support modules, then the switching procedure104may be initiated.

Referring back toFIG.1b, an effect of this “switching” is illustrated by the boxes31, triangles,32and circles33. As mentioned, the boxes31represent the projected performance over time for the high-end ADAS24, the triangles32represent the projected “driver perceived performance” over time, and the circles33represent the projected “AD core”25performance over time. As discussed in the foregoing, a challenge when trying to move from ADAS to a mature AD module, is the “curse of automation” problem, which predicts that the perceived quality of the control system is so good that it induce a “false sense of safety” in the driver, causing him or her to pay less than needed attention to the surrounding traffic even though the control system is not yet secure enough to be operated without supervision.

Moving on, as indicated by the circles33, over time the development of the “AD core” segment will continue and improve in terms of failure rates, while the “high-end” ADAS remains at a static performance level for that ODD. However, by switching the control system between the “high-end” ADAS and the “AD core” the “perceived performance” by the driver can stay outside “curse of automation zone”25.

Moreover, the switching protocol may comprise a predefined time scheme comprising instructions such that the second configuration is selected for a duration of 25% to 95% of the time period, or more preferably for a duration of 50% to 90% of the time period, while the first configuration is selected for the remainder of the time period. This is because gain in the form an increase of closed-loop testing hours when going from 90% to e.g. 99% is low in comparison with the downside of increased risk of moving the projected “perceived performance”32to the “curse of automation” region25. The time period is here to be understood as a period of time that the ODD requirement of both the first and second driver support modules is fulfilled, or in other words, a period of time that the vehicle is within an ODD overlap of the first and second driver support modules.

FIG.3ais a schematic flow chart representation of a method to be executed by a control system of a vehicle in accordance with an embodiment of the present disclosure. The control system is suitable for enabling closed-loop testing of not-yet-launched ADS modules for specified ODDs. The control system comprises a first driver support module45and a second driver support module46. Both of the first and second driver support modules45,46are capable of operating within an overlapping operational design domain (ODD). According to an exemplary embodiment of the present disclosure, the first driver support module45has a first defined performance level and the second driver assistance module46has a second defined performance level that is higher than the first defined performance level.

Further, the control system comprises suitable control circuitry (may also be referred to as a control unit, control circuit, controller, processor(s), etc.) for executing various functional steps as will be described in the following. The control circuitry is configured to obtain sensor data40comprising information about a surrounding environment of the vehicle. Further, the control circuitry is configured to determine a fulfilment of the overlapping ODD based on the obtained sensor data. The system may comprise an ODD determination module41for this task. Once the current ODD is determined, then a check may be performed42to determine if the overlapping ODD is fulfilled (i.e. if both of the first and second driver support modules45,46are compatible with the current ODD).

If the overlapping ODD is fulfilled, then the control circuitry is configured to switch43between a first configuration where the first driver support module is active and the second driver support module is inactive, and a second configuration where the first driver support module is inactive and the second driver support module is active. Stated differently, the control circuitry is configured to control a switching function47so to switch between the first configuration and the second configuration.

Furthermore, the switching43between the first configuration and the second configuration is based on a switching protocol44in order to perform closed loop testing of the second driver support module for at least portion of a time period that the vehicle is within an environment that fulfils the overlapping ODD. An active driver support module45,46may in the present context be understood as that the active driver support module is arranged to generate control signals for a control system48of the vehicle in order to control at least one of a steering angle of the vehicle, an acceleration of the vehicle, and a deceleration of the vehicle. In contrast, an “inactive” driver support module does not control any manoeuvres of the vehicle. An “inactive” driver support module may however still be “generating control signals” but these control signals are not used as input to a vehicle platform (i.e. not used to manoeuvre the actual vehicle). Instead, the generated control signals of the “inactive” module may be used to verify its compatibility between the fulfilled overlapping ODD by running it in “a background mode”, i.e. a dark launch may be performed.

Naturally, the “switching” may be realized in various ways and does not necessarily only include abrupt switching between the driver support modules45,46. Instead, in some embodiments, the switching protocol44may include some overlap such that the control is “faded” in and out from driver support modules, in order to reduce the risk of jerk or passenger discomfort. Stated differently, in the transition between the first configuration and the second configuration a blend of output (signals) from the first and second driver support modules45,46may be used to get a smooth transition. For example, the switching protocol44may include a transition phase of 0-3 s within which the outputs from the first and second driver support modules45,46is blended/mixed.

Moreover, the switching protocol44may comprise a predefined time scheme comprising instructions for having the second configuration selected for a duration of 1% to 99%, preferably for a duration of 25% to 95%, and more preferably for a duration of 50% to 90% of the time period; and having the first configuration selected for the remainder of the time period. The predefined time scheme may be configured such that specific time portions of the time period are reserved for the first configuration (e.g. first 5% and last 5% or for 1 minute every 10 minutes).

Alternatively, the predefined time scheme may be dynamic (or randomized) such that the time portion that is reserved for the first configuration is distributed randomly throughout the time period. Here, the method may further comprise a step of determining/predicting/estimating a time period that the vehicle will be in an environment that fulfils the overlapping ODD.

FIG.3bis a schematic flow chart representation of a method for controlling a control system of a vehicle in accordance with another embodiment of the present disclosure. Several features and functions of the embodiment ofFIG.3bhave already been described in detail in the foregoing with reference toFIG.3aand will for the sake of brevity and conciseness not be discussed in any explicit detail. Focus will instead be put on the differentiating parts, and in particular to the ODD determination module41and to the determination of the ODD fulfilment50and consequences of various scenarios. Analogously as discussed before the first driver support module is a verified and deployed ADAS function while the second support module is an “AD core” function, i.e. an unverified/unfinished ADS function.

In more detail, the ODD determination41comprises a step of verifying50an ODD fulfilment of the first and second driver support modules respectively. The verification is presented as a table illustrating four different scenarios. In a first scenario, the ODD of the first driver support module is fulfilled while the ODD of the second driver support module is not fulfilled. Accordingly, in the first scenario, the first driver support module may be activated45and used to provide48control signals to the vehicle platform (e.g. control of longitudinal/lateral motion). In a second scenario, the ODD is fulfilled for both of the first and second driver support modules (i.e. an overlapping ODD is fulfilled). Thus, in the second scenario both of the first and second driver support modules are activated45,46and the switching43between the first and second configuration based on the switching protocol44is executed while the vehicle is within an environment that fulfils the overlapping ODD.

In a third scenario, the ODD of the first driver support module is not fulfilled while the ODD of the second driver support module is fulfilled. Since the second driver support module is an unverified/unfinished function, it is not allowed to control48the vehicle platform alone. Thus, in the third scenario a hand-over to a driver of the vehicle or a third driver support module may be activated (if the ODD of the third driver support module is fulfilled). In a fourth scenario, none of the ODDs of the first and driver support modules are fulfilled, and the consequence is the same as for the third scenario.

FIG.4is a schematic block diagram representation of a control system10for a vehicle in accordance with an embodiment of the present disclosure. The control system10has a first driver support arrangement52a, and a second driver support arrangement52b. The first driver support arrangement52acomprises a first driver support module, in the form of an ADAS lane keeping assist (LKA) and adaptive cruise control (ACC)45a, and a second driver support module, in the form of a traffic jam pilot46a. The ADAS LKA+ACC45acan here be considered as a “low-level” traffic jam pilot. Both of the ADAS LKA+ACC45aand the traffic jam pilot46aare capable of operation within a first overlapping ODD. Further, the control system10has a second driver support arrangement52bcomprising a first driver support module, in the form of an ADAS lane keeping assist (LKA) and adaptive cruise control (ACC)45b, and a second driver support module, in the form of a highway pilot46b. Analogously, the ADAS LKA+ACC45band the highway pilot46bare capable of operation within a second overlapping ODD. The two ADAS LKA+ACC modules45a,45bmay be realized as a single module, but are here illustrated as separate units for clarity.

In more detail, the first driver support arrangement52acan be construed as a traffic jam support module comprising a verified ADAS module45a(i.e. “low performance” driver support feature) and an unverified ADS module46a(i.e. “high performance” driver support feature). Accordingly, in a scenario where the ODD is assumed to be a traffic jam scenario (e.g. multiple lanes, speed <30 km/h, clear lane markings, dense traffic), the two driver support modules45a,46amay have an overlapping ODD in specific situations, whereupon the switching between the two driver support modules45a,46aas described herein can be initiated. Analogously, the second driver support arrangement52bcan be construed as a highway support module comprising a verified ADAS module45b(i.e. “low performance” driver support feature) and an unverified ADS module46b(i.e. “high performance” driver support feature).

The system further has control circuitry configured to obtain sensor data40, and to determine a current ODD (i.e. to verify a fulfilment of an overlapping ODD) based on the obtained sensor data40. The ODD determination may be performed by a dedicated ODD determination module41. Similar to the embodiment discussed with reference toFIGS.3a-3b, the control circuitry of the control system10depicted inFIG.4is configured to switch43between a first configuration where the first driver support arrangement45a,45bis active and the second driver support arrangement46a,46bis inactive, and a second configuration where the first driver support arrangement45a,45bis inactive and the second driver support arrangement46a,46bis active. Moreover, the switching between the first configuration and the second configuration is based on a switching protocol44in order to perform closed loop testing of the second driver support arrangement46a,46bfor at least portion of a time period that the vehicle is within the overlapping ODD.

Further, the control system10has one or more safety systems53configured to generate control signals to the vehicle platform48in order to manoeuvre the vehicle in case of emergency (e.g. collision avoidance, emergency braking, etc.). The one or more safety systems53may be arranged to be able to override any control signals generated by the driver support52a,52b.

Executable instructions for performing these functions are, optionally, included in a (non-transitory) computer-readable storage medium or other computer program product configured for execution by one or more processors.

FIG.5is a schematic diagram illustrating a method for controlling a control system of a vehicle according to an embodiment of the present disclosure. More specifically,FIG.5illustrates an example of how the determination of ODD fulfilment may be realized. The vehicle is provided with a first driver support module and a second driver support module. The first driver support module (top row) may be in the form of a low speed highway assist. More specifically, the first driver support module may be configured to control the DDT of the vehicle (i.e. sustained lateral and longitudinal vehicle motion control) at low speeds on a highway, but will rely on the driver to complete object and event detection and response (OEDR). The first driver support module is capable of operating within a first ODD having a first set of predefined ODD metrics: The vehicle is traveling on a highway (e.g. controlled-access highway) at a speed below 120 km/h. The second driver support module (second row from the top) may be an unverified (or “under development”) ADS module in the form of a traffic jam pilot.

More specifically, the second driver support module may be configured to control the DDT, the OEDR, and a DDT-fall back (i.e. automatically achieving a minimal risk condition when necessary) without any expectation of driver-intervention. The second driver support module is capable of operating within a second ODD having a second set of predefined ODD metrics: The vehicle is traveling on a highway (e.g. controlled-access highway), in daylight, at a speed below 60 km/h in a traffic jam.

The first and second rows75,76indicate an ODD fulfilment72of the first driver support module and the second driver support module respectively at each time sample (denoted by ODD det.). Thus, the method may comprise determining a current ODD of the vehicle at a sample rate, and determining an ODD fulfilment72of each of the first and second driver support modules. In some embodiments, the method may comprise determining a fulfilment of both the first and second ODDs (i.e. a fulfilment of an overlapping ODD). A current ODD is indicated in the third row from the top by the presence of a set of ODD parameters73a-d, derived from the obtained sensor data. At a first time sample for a determination of an ODD fulfilment, a current ODD of comprises the following ODD parameters: The vehicle is traveling on a highway73cat a speed of 55 km/h73bat night time73a. These ODD parameters are then compared to the ODD metrics of the first and second ODDs in order to determine a fulfilment72of the first and second ODDs (and consequently a fulfilment of an overlapping ODD). As indicated (by refs.71and72) inFIG.5, at the first time sample only the second ODD is fulfilled. Accordingly, since only the first driver support modules are capable of operating within the current ODD of the vehicle, the switching between the first configuration and the second configuration is not enabled (indicated by “OFF” in the bottom row74).

Moving on, at a second time sample, the current ODD of the vehicle comprises the following parameters: The vehicle is traveling on a highway73cat a speed of 55 km/h73bat day time73a. Accordingly, at the second time sample the first ODD is fulfilled and the second ODD is not fulfilled. Thus, as in the first time sample, the overlapping ODD is not fulfilled and switching between the first and second configurations is not enabled.

At a third time sample, the current ODD of the vehicle comprises the following parameters: The vehicle is traveling on a highway73cat a speed of 30 km/h at day time73ain a traffic jam73d. Accordingly, at the second time sample both of the first and second ODDs are fulfilled, and therefore the overlapping ODD is fulfilled. Thus, the switching between the first and second configurations is enabled, as indicated by the “ON” symbol in the bottom row. A lengthy detailed discussion related to the subsequent time samples are omitted for clarity and conciseness, however, the skilled reader readily understands the concept and is capable of interpreting the illustrated example based on the foregoing disclosure.

FIG.6is a series of schematic Venn diagrams illustrating an evolution of driver assistance modules and their ODD coverage over time that may be facilitated by the method, computer-readable storage medium, a control system, and a vehicle comprising such a control system of the present disclosure. In more detailFIG.6serves to illustrate how an ODD coverage of “high-end” ADAS61a-61dincreases over time (i.e. the “high-end” ADAS is capable of operating within a larger ODD over time), and how the ODD coverage62a-cof the “AD-core”, which may be interpreted as an unverified AD product, increases over time. Moreover,FIG.6also illustrates how the ODD coverage of the “mature” ADS product63a-bevolves from the “AD core”. Also, an overlapping ODD of the “High-end” ADAS61a-cand the “AD core”62a-cis be the full ODD coverage of the “AD core”62a-c.

The proposed switching procedure discussed in the foregoing enables for concentrated and efficient ADS development by expanding the ODD coverage of the ADS product63a-bwithin the ODD coverage of the “high-end” ADAS. In other words, efficient utilization of development and verification resources for moving the automotive industry from “low level” ADS to “high level” ADS is achievable.

FIG.7is a schematic side view of a vehicle1comprising a control system10for a vehicle1. The control system10has a first driver support module and a second driver support module, each of which is configured for an overlapping ODD. The vehicle1further comprises a perception system6and a localization system5. A perception system6is in the present context to be understood as a system responsible for acquiring raw sensor data from on sensors6a,6b,6csuch as cameras, LIDARs and RADARs, ultrasonic sensors, and converting this raw data into scene understanding. The localization system5is configured to monitor a geographical position and heading of the vehicle, and may in the form of a Global Navigation Satellite System (GNSS), such as a GPS. However, the localization system may alternatively be realized as a Real Time Kinematics (RTK) GPS in order to improve accuracy.

The control device10comprises one or more processors11, a memory12, a sensor interface13and a communication interface14. The processor(s)11may also be referred to as a control circuit11or control circuitry11. The control circuit11is configured to execute instructions stored in the memory12to perform a method for controlling a vehicle according to any one of the embodiments disclosed herein. Stated differently, the memory12of the control device10can include one or more (non-transitory) computer-readable storage mediums, for storing computer-executable instructions, which, when executed by one or more computer processors11, for example, can cause the computer processors11to perform the techniques described herein. The memory12optionally includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices; and optionally includes non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices.

In more detail, the control circuitry11is further configured to obtain sensor data from the perception system6and/or the localization system of the vehicle1. The sensor data comprises information about a surrounding environment of the vehicle. The control circuitry11is further configured to determine current fulfilment of an overlapping ODD based on the obtained sensor data. Moreover, if the overlapping ODD is fulfilled, the control circuitry11is configured to switch between a first configuration where the first driver support module is active and the second driver support module is inactive, and a second configuration where the first driver support module is inactive and the second driver support module is active. The switching between the first configuration and the second configuration is based on a switching protocol in order to perform closed loop testing of the second driver support module for at least portion of a time period that the vehicle1is within the overlapping ODD.

An active driver support module is arranged to generate control signals for a control system of the vehicle in order to control at least one of a steering angle of the vehicle1, an acceleration of the vehicle1, and a deceleration of the vehicle1. As mentioned, the sensor data may comprise vehicle data (e.g. vehicle speed, vehicle heading, etc.), a geographical location of the vehicle, external object data (e.g. presence of other vehicles, relative speed difference between the ego-vehicle1and surrounding vehicle, presence of pedestrians, cyclists, etc.), map data, and any other data suitable for determining a current ODD of the vehicle1. Even though the control circuitry11is here illustrated as an in-vehicle system, some or all of the components may be located remote (e.g. cloud-based solution) to the vehicle in order to increase computational power.

Further, the vehicle1may be connected to external network(s)2via for instance a wireless link (e.g. for retrieving map data). The same or some other wireless link may be used to communicate with other vehicles in the vicinity of the vehicle or with local infrastructure elements. Cellular communication technologies may be used for long range communication such as to external networks and if the cellular communication technology used have low latency it may 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, 5G NR, and so on, also including future cellular solutions. However, in some solutions mid to short range communication technologies are used such as Wireless Local Area (LAN), e.g. IEEE 802.11 based solutions. ETSI is working on cellular standards for vehicle communication and for instance 5G is considered as a suitable solution due to the low latency and efficient handling of high bandwidths and communication channels.

The present disclosure has been presented above with reference to specific embodiments. However, other embodiments than the above described are possible and within the scope of the disclosure. Different method steps than those described above, performing the method by hardware or software, may be provided within the scope of the disclosure. Thus, according to an exemplary embodiment, there is provided a non-transitory 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 comprising instructions for performing the method according to any one of the above-discussed embodiments. 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 comprise distributed cloud computing resources that jointly perform the methods presented herein under control of one or more computer program products.

Generally speaking, a computer-accessible medium may include any tangible or non-transitory storage media or memory media such as electronic, magnetic, or optical media—e.g., disk or CD/DVD-ROM coupled to computer system via bus. The terms “tangible” and “non-transitory,” as used herein, are intended to describe a computer-readable storage medium (or “memory”) excluding propagating electromagnetic signals, but are not intended to otherwise limit the type of physical computer-readable storage device that is encompassed by the phrase computer-readable medium or memory. For instance, the terms “non-transitory computer-readable medium” or “tangible memory” are intended to encompass types of storage devices that do not necessarily store information permanently, including for example, random access memory (RAM). Program instructions and data stored on a tangible computer-accessible storage medium in non-transitory form may further be transmitted by transmission media or signals such as electrical, electromagnetic, or digital signals, which may be conveyed via a communication medium such as a network and/or a wireless link.

The processor(s)11(associated with the control system10) may be or include any number of hardware components for conducting data or signal processing or for executing computer code stored in memory12. The device10has an associated memory12, and the memory12may be one or more devices for storing data and/or computer code for completing or facilitating the various methods described in the present description. The memory may include volatile memory or non-volatile memory. The memory12may include database components, object code components, script components, or any other type of information structure for supporting the various activities of the present description. According to an exemplary embodiment, any distributed or local memory device may be utilized with the systems and methods of this description. According to an exemplary embodiment the memory12is communicably connected to the processor11(e.g., via a circuit or any other wired, wireless, or network connection) and includes computer code for executing one or more processes described herein.

It should be appreciated that the sensor interface13may also provide the possibility to acquire sensor data directly or via dedicated sensor control circuitry6in the vehicle. The communication/antenna interface14may further provide the possibility to send output to a remote location (e.g. remote operator or control centre) by means of the antenna8. Moreover, some sensors in the vehicle may communicate with the control system10using a local network setup, such as CAN bus, I2C, Ethernet, optical fibres, and so on. The communication interface14may be arranged to communicate with other control functions of the vehicle and may thus be seen as control interface also; however, a separate control interface (not shown) may be provided. Local communication within the vehicle may also be of a wireless type with protocols such as Wi-Fi, LoRa, Zigbee, Bluetooth, or similar mid/short range technologies.

Accordingly, it should be understood that parts of the described solution may be implemented either in the vehicle1, in a system located external the vehicle1, or in a combination of internal and external the vehicle1; for instance in a server in communication with the vehicle1, a so called cloud solution. For instance, sensor data may be sent to an external system and that system performs the some or all of the necessary steps to determine an overlapping ODD fulfilment. The different modules and steps of the embodiments may be combined in other combinations than those described.

Although the figures may show a specific order of method steps, the order of the steps may differ from what is depicted. In addition, two or more steps may be performed concurrently or with partial concurrence. Such variation will depend on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the disclosure. Likewise, software implementations could be accomplished with standard programming techniques with rule-based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps. The above mentioned and described embodiments are only given as examples and should not be limiting to the present disclosure. Other solutions, uses, objectives, and functions within the scope of the disclosure as claimed in the below described patent embodiments should be apparent for the person skilled in the art.