Intelligent vehicles, systems and control logic for dynamic external control of vehicles using visible or audible cues

Abstract

Intelligent vehicle control systems that enable external control of vehicles using hints, methods for manufacturing / using such vehicle control systems, and vehicles equipped with such control systems are provided. A method for controlling the operation of a vehicle includes a vehicle controller receiving a signal indicating that the vehicle is in a particular operating mode, and, in response to receiving a hint, determining whether an instruction is executable and, if so, executing the instruction.

Description

CROSS-REFERENCE TO RELATED REGISTRATIONS

[0001] This application claims priority as a partial continuation of the non-provisional application No. 18 / 304,431 entitled “Intelligent Vehicles, Systems, and Control Logic for External Control Of Vehicles Using Visible or Audible Cues”, filed on 21 April 2023, which is incorporated herein in its entirety by reference. AREA OF INVENTION

[0002] This disclosure relates generally to intelligent control systems of motor vehicles. In particular, aspects of this disclosure relate to systems, methods, and devices for dynamically providing automated vehicle control using visual or audible cues. BACKGROUND

[0003] Motor vehicles, such as cars, can be equipped with a network of onboard electronic devices that provide automated driving capabilities to help minimize driver effort. In automotive applications, for example, one of the most recognizable types of automated driving features is the cruise control system. Cruise control allows a vehicle operator to set a specific vehicle speed, and the vehicle's computer system will maintain that speed without the driver using the accelerator or brake pedals. Next-generation adaptive cruise control (ACC) is an automated driving feature that regulates vehicle speed while simultaneously managing the following distance between the host vehicle and a target vehicle ahead.Another type of automated driving feature is the collision avoidance system (CAS), which detects impending collision conditions and provides a warning to the driver, while also taking autonomous preventive action, such as steering or braking without driver input. Intelligent parking assist systems (IPAS), lane keeping assist and automated steering systems (auto steer systems), electronic stability control systems (ESC systems), and other advanced driver assistance systems (ADAS) are also available in many vehicles.

[0004] As vehicle processing, communication, and data acquisition capabilities continue to improve, manufacturers will continue to offer more automated driving capabilities, striving to produce fully autonomous "self-driving" vehicles that can operate among heterogeneous vehicle types in both urban and rural environments. Original equipment manufacturers (OEMs) are moving toward vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) "talking" passenger cars with higher levels of driving automation, employing intelligent control systems to enable vehicle guidance including steering, lane changes, scenario planning, and more. Automated path planning systems utilize vehicle state and dynamics sensors, geolocation information, map and road condition data, and path prediction algorithms to provide route derivation with automated lane centering and lane change prediction.

[0005] Many motor vehicles are equipped with an in-vehicle telecommunications and information technology unit (“telematics” unit) that provides navigation, control, entertainment, and other desired functionalities. Wireless telematics units, in addition to allowing vehicle occupants to connect to the internet and communicate with a centralized back-office host vehicle service (BO-host vehicle service), can also allow a vehicle owner or driver to interact with the telematics unit via a cellular or short-range communication connection using a smartphone or similar device. For example, if the owner / driver misplaces the vehicle keys or locks them inside, the user can use their smartphone to communicate with the telematics unit to unlock a vehicle door.Additionally, an owner / driver who forgets where they parked the vehicle in a parking garage can communicate wirelessly with the telematics unit using their smartphone to activate the vehicle's horn and / or lights. Generally, wireless communication with and remote control of a vehicle is typically restricted to the vehicle owner or an authorized driver and requires a wireless-enabled computing device and prior user authentication. SUMMARY

[0006] This document describes intelligent vehicle systems with accompanying control logic for providing external control of vehicles using visual and audible cues, methods for manufacturing and operating such vehicle control systems, and motor vehicles equipped with such control systems. As an example, a system and method for externally controlling a vehicle using signs, sounds, verbal instructions, gestures, etc., are presented. The method can enable the dynamic assignment of external vehicle control to previously registered or unregistered third parties, first responders, and pre-authorized users such as a vehicle owner or driver. Under compelling circumstances, such as...In the event of a vehicle collision or emergency, the vehicle control system can allow a person outside the host vehicle to safely and safely operate the vehicle using hand gestures, verbal instructions, or other visual / audible inputs detectable by the vehicle's networked sensor array. One of three different operating modes—automatic, manual, and remote—can be triggered to assign different levels of vehicle control based on vehicle sensor feedback, contextual data, vehicle status, the identity of a remote user, and other factors. Restrictions on prior authorization for specific individuals or access credential sharing within a device can be eliminated using a flexible algorithm that determines when and to what extent the functionality is required.

[0007] Associated benefits for at least some of the disclosed concepts include enhanced vehicle control protocols that dynamically enable external control of a host vehicle using visual and / or audible cues without requiring prior authentication or recognition of the cue-generating unit. Disclosed vehicle control protocols allow a first responder or pedestrian to gain access to a host vehicle and / or safely relocate it during one of several predefined emergency situations without the need for a wireless computing device or access to the passenger compartment. Further associated benefits may include control protocols that enforce a hierarchy of instruction authority, such as different operating modes to which different levels of instructions with associated sets of authorized controls are assigned.The enforced hierarchy helps the host vehicle dynamically extend or restrict external user control. The vehicle can allow an external entity to submit a formal request for enhanced control authorization or to enter a predefined gesture or set of credentials. If a preset identification threshold is not met, the host vehicle or a remote authorization unit can restrict or deny external control.

[0008] Aspects of this disclosure relate to intelligent vehicle control systems, system control logic, and commands stored in memory for providing external control of vehicles using visual and audible cues. An example presents a method for controlling the operation of a host vehicle comprising a resident or remote controller, or a module or network of controllers / modules (collectively referred to as a "controller" or "vehicle controller"), and a vehicle-side network of sensing devices (e.g., one or more radar transceivers, one or more LiDAR scans, one or more high-resolution video cameras, one or more microphones, one or more short-range radio transceivers, magnetometers, etc.).This exemplary procedure comprises, in any order and in any combination with any of the options and features described above and disclosed below, the following: receiving, e.g., by means of the vehicle controller, from an in-vehicle telematics unit an automatic release signal indicating that the host vehicle is in one of several predefined automatic control release states; activating, e.g., by means of the vehicle controller in conjunction with an ADAS module in response to receiving the automatic release signal, an automatic control mode that enables a unit outside the host vehicle to control the host vehicle using visual and / or audible cues; determining, e.g.,by means of the vehicle controller, whether at least one sensor in the network of detection devices detects a visible / audible indication from the external unit and outputs a sensor signal indicating it; determine, e.g., by means of the vehicle controller in response to receiving the sensor signal, whether the detected visible / audible indication is one of several preset valid instructions; and send, e.g., by means of the vehicle controller in response to the detected visible / audible indication being a preset valid instruction, one or more instruction signals to one or more resident vehicle subsystems of the host vehicle to perform one or more vehicle operations that correspond to the preset valid instruction (e.g., reposition host vehicle, unlock host vehicle, lower vehicle windows, disconnect vehicle battery pack, or perform any of the operations / instructions that correspond to any mode, e.g.,to automate (corresponding to an obedience mode, which will be discussed below, etc.).

[0009] Aspects of this disclosure also relate to computer-readable media (CRM) for enabling external control of vehicles using visual and audible cues. In one example, a non-transient CRM stores commands that can be executed by one or more processors of a vehicle controller. When executed by the one or more processors, these commands cause the controller to perform operations that include: receiving an automatic trigger signal indicating that a host vehicle is in one of several predefined automatic control trigger states; activating, in response to receiving the automatic trigger signal, an automatic control mode that allows an external entity outside the host vehicle to control the host vehicle using a visual and / or audible cue;Receiving a sensor signal from a network of sensing devices of the host vehicle indicating detection of the visual and / or audible cue from the external unit; determining whether the detected visual and / or audible cue is a preset valid instruction; and, in response to the detection of the visual and / or audible cue being the preset valid instruction, sending an instruction signal to a resident vehicle subsystem of the host vehicle to automate a vehicle operation according to the preset valid instruction.

[0010] Additional aspects of this disclosure are directed toward motor vehicles with intelligent control systems that provide external vehicle control using signs, gestures, verbal instructions, etc. As used herein, the terms "vehicle" and "motor vehicle" can be used interchangeably and synonymously to include any relevant vehicle platform, such as passenger cars (ICE, HEV, FEV, fuel cell, fully or partially autonomous, etc.), commercial vehicles, industrial vehicles, tracked vehicles, all-terrain vehicles and quads, motorcycles, agricultural equipment, watercraft, aircraft, etc. By way of example, a motor vehicle includes a vehicle body with a passenger compartment, several road wheels mounted to the vehicle body (e.g., by means of corner modules coupled to a unibody or non-unibody structure), and other normal original equipment.A vehicle powertrain, comprising a propulsion unit such as an internal combustion engine (ICE) and / or an electric traction motor, drives one or more of the wheels to propel the vehicle forward. A network of sensing devices is distributed across the vehicle body and communicates sensor data to a resident or remote vehicle controller to help regulate the operation of the motor vehicle.

[0011] Continuing the preceding discussion, the vehicle controller is programmed to receive an automatic trigger signal indicating that the motor vehicle is in one of several predefined automatic control trigger states, and in response to receiving this trigger signal, to activate an automatic control mode that allows a unit outside the vehicle to control the vehicle using visual and / or audible cues. The controller then determines whether the vehicle's network of sensing devices detects a visual / audible cue from the external unit; if so, the controller determines whether the detected visual / audible cue is a preset valid instruction.Based on a determination that the detected visual / audible cue is a valid instruction, the controller in response directs one or more resident vehicle subsystems of the motor vehicle to automate one or more vehicle operations in accordance with the preset valid instruction.

[0012] Aspects of the present disclosure relate to a method for controlling an autonomously operated vehicle. This method may include the vehicle receiving a signal indicating that the vehicle is controllable in one or more of several operating modes. Each operating mode defines a unique set of actions that the vehicle can perform. This method may further include the vehicle receiving a prompt to operate the vehicle in one or more of the several operating modes. This method may further include the vehicle receiving a first instruction. This method may further include the vehicle determining whether the first instruction is executable. This method may further include the vehicle executing the first instruction after determining that the first instruction is executable.

[0013] Aspects of this disclosure relate to a vehicle controller. The vehicle controller can be configured to receive a signal indicating that the vehicle is controllable in one or more of several operating modes, each operating mode defining a unique set of actions that the vehicle can perform. The vehicle controller can further be configured to receive a prompt to operate the vehicle in one or more of the several operating modes. The vehicle controller can further be configured to receive an initial instruction. The vehicle controller can further be configured to determine whether the initial instruction is executable. The vehicle controller can further be configured to execute the initial instruction after the vehicle has determined that the initial instruction is executable.

[0014] Aspects of the present disclosure relate to non-transient, computer-readable media for storing instructions executable by one or more processors of a vehicle controller, causing the vehicle controller to perform certain operations. These operations may include receiving a signal indicating that the vehicle is controllable in one or more of several operating modes, each operating mode defining a unique set of actions that the vehicle can perform. These operations may further include receiving a cue to operate the vehicle in one or more of the several operating modes. These operations may further include receiving an initial instruction. These operations may include determining whether the initial instruction is executable.These operations may also include executing the first instruction after the vehicle has determined that the first instruction is executable.

[0015] For any of the disclosed vehicles, methods, and CRMs, the vehicle controller can respond to the detection that the detected visual / audible cue is not a valid instruction by communicating with the network of sensing devices to receive a new sensor signal indicating the detection of a new visual / audible cue from the external unit. If detected, the controller determines whether this new visual / audible cue is one of the predefined valid instructions; if so, the controller, in response, instructs one or more of the resident vehicle subsystems to automate a vehicle operation that complies with this valid instruction. Determining whether a visual / audible cue has been detected may include determining whether the network of sensing devices has detected a visual and / or audible cue within a preset timeframe.In this case, the vehicle controller can conclude that no visible / audible signal was detected if the sensors did not detect any such signal within the preset timeframe. Based on this conclusion, the vehicle controller may then deactivate the automatic control mode.

[0016] For any of the disclosed vehicles, methods, and CRMs, the vehicle controller, after instructing one or more resident vehicle subsystems to automate one or more vehicle operations, can communicate with the sensing devices to receive a new sensor signal indicating the detection of a new visual / audible cue from the external unit. The controller then determines whether this new visual / audible cue is one of several preset valid instructions; if so, the controller can, in response, instruct one or more resident vehicle subsystems to automate one or more new vehicle operations according to the preset valid instruction.As an additional option, the vehicle controller can respond to the failure to receive an automatic release signal by receiving a manual release signal indicating that the host vehicle has received one of several predefined manual release inputs. In this case, the controller can respond to receiving the manual release signal by activating a manual control mode, which is distinct from the automatic control mode and allows the external unit to control the host vehicle using visual and / or audible cues. For example, the automatic control mode might include a different (first) set of vehicle operations that can be triggered by a visual / audible cue from an external unit, whereas the manual control mode might include a further different (second) set of vehicle operations that can be triggered by visual / audible cues from the external unit.Manual trigger input may include the host vehicle detecting a predefined gesture or pre-approved code and / or receiving in-vehicle approval from an occupant of the host vehicle.

[0017] For any of the disclosed vehicles, procedures, and CRMs, the vehicle controller may respond to the failure to receive an automatic or manual release signal by receiving a remote release signal indicating that the host vehicle has received authorization from an external vehicle control system via a remote vehicle instruction center (e.g., ONSTAR® or MYGMC®). In this case, the vehicle controller may respond to receiving the remote release signal by activating a remote control mode that is different from both manual and automatic control modes. For example, the remote control mode may allow the instruction center to control the host vehicle using wirelessly transmitted control signals. The remote control mode may also allow an external entity to control the host vehicle using visual and / or audible cues.For example, the remote control mode can include a different (third) set of vehicle operations, distinct from the automatic and manual control modes, and executable by the command center or triggered by a visual / audible signal from an external unit. The remote trigger signal can be generated in response to a telephone call between a remote vehicle command center and a cellular-enabled computing device of the external unit or a telematics unit in the passenger compartment of the host vehicle.

[0018] For any of the disclosed vehicles, methods, and CRMs, the vehicle controller can respond to the activation of automatic control mode by activating a vehicle lighting system and / or a vehicle audio system of the host vehicle to issue a predefined visual and / or audible acknowledgment indicating to the external unit that automatic control mode is activated. As a further option, the predefined automatic control trigger state can include the host vehicle being in a vehicle collision state (e.g., an SOS call is being made by the telematics unit, an airbag or seatbelt pretensioner is being deployed, etc.), the host vehicle being in a vehicle inoperative state (e.g., a thermal walkthrough event has been detected), and / or the host vehicle being at a predefined location (e.g.,Specify geolocation data indicating that the host is in a predefined geofence, a manufacturer's warehouse, a car dealer's parking lot, etc.).

[0019] The summary above does not represent every embodiment or aspect of the present disclosure. Rather, the preceding summary merely provides an overview of some of the novel concepts and features set forth herein. The features and advantages described above, and further features and concomitant advantages of this disclosure, will become apparent from the following detailed description of illustrated examples and exemplary modes of implementation of the disclosure when considered in conjunction with the accompanying drawings and the attached claims. Furthermore, this disclosure expressly includes all combinations and subcombinations of the elements and features illustrated above and below. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is a partially schematic side view of an exemplary intelligent motor vehicle with a network of in-vehicle controllers, sensing devices and communication devices for providing improved remote vehicle control by an external unit according to an embodiment of the present disclosure. Fig. 2 is a flowchart illustrating an exemplary vehicle control algorithm for providing external operation of a vehicle using visual or audible cues that may correspond to commands stored in memory, which can be executed by a resident or remote controller, control logic circuit, programmable control unit or other integrated circuit device (IC device) or network of devices, according to an embodiment of the disclosed concepts. Fig. Figure 3 is a flowchart illustrating a further exemplary vehicle control algorithm for providing external operation of a vehicle using hints that may correspond to commands stored in memory, which can be executed by a resident or remote controller, control logic circuit, programmable control unit or other integrated circuit device (IC device) or network of devices, according to an embodiment of the disclosed concepts. Fig. Figure 4 is a flowchart illustrating a further exemplary vehicle control algorithm for providing external operation of a vehicle using hints that may correspond to commands stored in memory, which can be executed by a resident or remote controller, control logic circuit, programmable control unit or other integrated circuit device (IC device) or network of devices, according to an embodiment of the disclosed concepts. Fig. Figure 5 is an exemplary data set for influencing the operation of a vehicle control algorithm according to an embodiment of the disclosed concepts. Fig. Figure 6 is another exemplary data set for influencing the operation of a vehicle control algorithm according to an embodiment of the disclosed concepts. Fig. Figure 7 is another exemplary data set for influencing the operation of a vehicle control algorithm according to an embodiment of the disclosed concepts. Fig. Figure 8 is another exemplary data set for influencing the operation of a vehicle control algorithm according to an embodiment of the disclosed concepts. Fig. Figure 9 is another exemplary data set for influencing the operation of a vehicle control algorithm according to an embodiment of the disclosed concepts.

[0020] The present disclosure is open to various modifications and alternative forms, and some exemplary embodiments of the disclosure are shown in the drawings and are described in detail here. However, it should be understood that the novel aspects of this disclosure are not limited to the specific forms illustrated in the drawings listed above. Rather, this disclosure covers all modifications, correspondences, combinations, permutations, groupings, and alternatives that fall within the scope of this disclosure, which is included, for example, by the attached claims. DETAILED DESCRIPTION

[0021] This disclosure can take many different embodiments. Exemplary embodiments of the disclosure are shown in the drawings and are described in detail here with the understanding that these embodiments are provided as an explanation of the disclosed principles, not as limitations of the comprehensive aspects of the disclosure. Accordingly, elements and limitations that are described, for example, in the abstract, introduction, summary, and detailed description sections, but are not expressly set forth in the claims, are not to be incorporated into the claims individually or collectively by inference, deduction, or otherwise. Furthermore, a repetition of "first," "second," "third," etc., is avoided.not used in the application text or the claims to define a serial or numerical limitation; rather, these designations may be used to simplify reference to similar features in the application text and the drawings and to distinguish between similar elements in the claims.

[0022] For the purposes of this precise description, unless expressly rejected, the following shall apply: the singular includes the plural and vice versa; the words "and" and "or" shall be used to connect and separate as well as separate; the words "any" and "all" shall both mean "all"; and the words "exhibit," "contain," "encompass," "possess," and the like shall each mean "contain without limitation." Furthermore, words of approximation such as "about," "near," "essentially," "generally," "approximately," and the like may be used here in the sense of, for example, "at, near, or about at" or "within 0-5% of" or "within acceptable manufacturing tolerances," or any logical combination thereof. Finally, directional adjectives and adverbs such as front, back, inside, outside, starboard, port, vertical, horizontal, up, down, forward, aft, left, right, etc., may be used.in relation to a motor vehicle, such as a forward direction of travel of a motor vehicle when the vehicle is functionally oriented on a horizontal roadway.

[0023] Referring to the drawings, whereby similar reference numerals refer to similar features in the course of the several views, it is in Fig. Figure 1 shows an exemplary motor vehicle, generally designated 10, which for the purposes of discussion is represented here as a sedan-like electric motor vehicle. The illustrated motor vehicle 10—here also referred to simply as the “motor vehicle” or “vehicle”—is merely an exemplary application with which aspects of this disclosure can be put into practice. Likewise, the incorporation of the present concepts into the illustrated wireless communication network for cellular- and mesh-enabled “talking” passenger cars should also be understood as a non-restrictive implementation of disclosed features. Therefore, it is understood that novel aspects and features of this disclosure can be applied to other wireless network architectures, implemented for a myriad of different triggering events, and incorporated into any logically relevant type of vehicle.Furthermore, only selected components of motor vehicles and intelligent vehicle control systems are shown and described in additional detail here. Nevertheless, the vehicles and systems discussed below may include numerous additional and alternative features and other available peripheral components for performing the various procedures and functions of this disclosure.

[0024] The exemplary vehicle 10 of Fig. 1 is originally equipped with a vehicle telecommunications and information unit (vehicle “telematics” unit) 14, which communicates wirelessly with a remotely located back-office (BO) cloud computing host service 24 (e.g., ONSTAR®) via, for example, non-restrictive examples of mobile phone masts, base stations, mobile switching centers, satellite services, etc. Some of the other vehicle hardware components 16, which are in Fig. The hardware components shown in Figure 1, which are generally included, include as non-limiting examples an electronic video display device 18, a microphone 28, audio speakers 30, and various user input controls 32 (e.g., buttons, knobs, switches, touch-sensitive control panels, joysticks, touchscreens, etc.). These hardware components 16 function partly as a human-machine interface (HMI) that allows a user to communicate with the telematics unit 14 and other components located in and away from the vehicle 10. For example, the microphone 28 provides occupants with a means of inputting verbal or other audible instructions, and the vehicle 10 employs an embedded speech processing unit using audio filtering, processing, and analysis modules to convert the inputs into signals.Conversely, the loudspeakers 30 provide an audible output for a vehicle occupant and can either be a standalone loudspeaker permanently assigned for use with the telematics unit 14, or they can be part of an audio system 22. The audio system 22 is functionally connected to a network interface 34 and an audio bus 20 to receive analog information and render it as sound by means of one or more loudspeaker components. Such components can be located inside or outside the vehicle and can be capable of interpreting or providing signals from outside or inside the vehicle.

[0025] A network connection interface 34 is communicatively coupled to the telematics unit 14. Suitable examples of such interfaces include Ethernet switches for twisted pair cables / fiber optics, parallel / serial communication buses, local area network (LAN) interfaces, CAN interfaces, and the like. The network connection interface 34 enables the vehicle hardware 16 to send and receive signals with each other and with various systems, both within the vehicle and outside the vehicle body 12. This allows the vehicle 10 to perform various vehicle functions, such as modulating a powertrain output, activating friction or regenerative braking, controlling the vehicle steering, managing the operation of a traction battery pack, controlling vehicle windows, doors, and locks, and other functions that can be automated.For example, the telematics unit can exchange signals with a powertrain control module (PCM) 52, an advanced driver assistance system (ADAS) module 54, an electronic battery control module (EBCM) 56, a steering control module (SCM) 58, a brake system control module (BSCM) 60 and various other vehicle ECUs such as a transmission control module (TCM), an engine control module (ECM), a sensor system interface module (SSIM) or any other module that can control a function assigned to the vehicle, etc.

[0026] With continued reference to Fig. 1. The telematics unit 14 is a vehicle-side computing device that provides a mix of services both individually and through its communication with other networked devices. This telematics unit 14 generally consists of one or more processors 40, each of which can be embodied as a discrete microprocessor, an application-specific integrated circuit (ASIC), or a dedicated control module. The vehicle 10 can provide centralized vehicle control by means of a central processing unit (CPU) 36, which is functionally coupled to a real-time clock (RTC) 42 and one or more electronic storage devices 38, each of which can take the form of a CD-ROM, a magnetic data carrier, an IC device, solid-state storage (SSD), hard disk storage (HDD), flash memory, semiconductor memory (e.g., various types of RAM or ROM), etc.

[0027] Long-range communication (LRC) capabilities with external devices can be provided by one, more, or all of a cellular chipset, an ultra-high frequency radio transceiver, a navigation and location component (e.g., a global positioning system transceiver (GPS transceiver)), and / or a wireless modem, all shown together in Figure 44. Short-range communication (SRC) can be provided by a near-range communication device 46 (e.g., a BLUETOOTH® unit or a near-field communication transceiver (NFC transceiver)), a UWB communication device, a permanently assigned near-range communication component (DSRC component) 48, and / or a dual antenna 50.The communication devices described above can provide data exchanges as part of a regular broadcast in a vehicle-to-vehicle (V2V) or vehicle-to-everything (V2X) communication network, such as vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), vehicle-to-device (V2D), etc. The concept is that the vehicle can be implemented without one or more of the components listed above, or it can optionally include additional components and functionality for a specific end use as required.

[0028] The CPU 36 receives sensor data from one or more sensing devices, which may include, for example, photodetection, radar, laser, ultrasonic, optical, infrared, or other suitable technologies, incorporating short-range communication technologies (e.g., DSRC or BLUETOOTH® or BLE®) or ultra-wideband radio technologies (UWB radio technologies), for example, to perform automated vehicle operation or a vehicle navigation service. In accordance with the illustrated example, the motor vehicle 10 may be equipped with one or more digital cameras 62, one or more distance sensors 64, one or more vehicle speed sensors 66, one or more vehicle dynamics sensors 68, and any necessary filtering, classification, fusion, and analysis hardware and software for processing raw sensor data.The type, arrangement, number, and interoperability of the distributed arrangement of in-vehicle sensors can be individually or collectively adapted to a given vehicle platform to achieve a desired level of automation and simultaneous autonomous vehicle operation.

[0029] To propel the motor vehicle 10 forward, an electrified powertrain can be operated to generate traction torque and deliver it to one or more of the vehicle's drive wheels 26. The electrified powertrain of a vehicle is in Fig. 1 is generally represented by an electric traction motor 78, which is functionally connected to a rechargeable energy storage system (RESS) that may be a body-mounted traction battery pack 70. The traction battery pack 70 may generally be formed from one or more battery modules 72, each containing a group of electrochemical battery cells 74, such as lithium-ion, lithium polymer, or nickel-metal hydride battery cells. The traction motor / generator unit (M) 78 extracts electrical power from the battery pack 70 and selectively supplies electrical power to it. A power inverter module (PIM) 80 electrically connects the battery pack 70 to the one or more motor / generator units 78 and modulates the transfer of electrical current between them.The battery pack 70 can be configured such that module management, cell sensing, and module-to-module or module-to-host communication functionality are directly integrated into each module 72 and are performed wirelessly via a wireless-enabled cell monitoring unit (CMU) 76. This electrified powertrain is one example, and other powertrains such as conventional internal combustion engines, hybrid systems, diesel engines, turbines, etc., can be used.

[0030] Furthermore, in Fig. Figure 1 shows a mobile vehicle communication system (MVC system) 82 that enables wireless communication between remotely located computing nodes and one or more motor vehicles 10. The MVC system 82 is represented here by a constellation of GPS satellites 84, a wireless service satellite 86, an uplink transmission station 88, a cellular (cell) transmit / receive tower 90, and a mobile switching center (MSC) 92. Other types of communication systems can be used, including microwave, laser, and other radio systems. The GPS transmit / receive device of a host vehicle 44 can exchange radio signals with the GPS satellites 84 to derive geoposition and time data for the vehicle 10 in real time or near real time, which can be used to provide navigation and other related services for vehicle occupants.The wireless service satellite 86, through cooperative operation with the uplink transmission station 88, provides unidirectional and bidirectional communications with the vehicle 10, such as satellite radio and media services (e.g., music, news, videos, etc.) and satellite telephony services (e.g., to contact a remote vehicle command center). While shown with a single vehicle 10 communicating with multiple GPS satellites 84, a single wireless service satellite 86, a single uplink station 88, a single cell tower 90, and a single MSC 92, the MVC system 82 can include any number and combination of the preceding elements, as well as other available and subsequently developed communication hardware.

[0031] The MVC system 82 can operate in a mobile communications system 96, which is in Fig. The mobile communication system 96 is represented by one or more cell towers 90, one or more mobile switching centers 92, and other networking components required to connect the mobile communication system 96 to various end nodes (e.g., the BO host service 24). Each cell tower 90 can be equipped with a set of transmit and receive antennas for exchanging radio signals with vehicles 10. Base stations of the various cell towers can be connected to the MSC 92 either directly or via intermediate equipment such as a base station controller (not shown). The mobile communication system 96 can implement any suitable communication technology, including earlier mobile communication protocols such as 2G cellular digital packet data (CDPD) technologies or modern mobile communication protocols such as 4G LTE from advanced 5G technologies.The vehicle telematics unit 14 can operate as a cellular-enabled mobile component registered with a mobile network carrier to transmit network data packets to and from the mobile communications system 96. It should be noted that the system 96 can assume countless tower / station / MSC arrangements, including a base station and cell tower being located at the same site, a remote arrangement of base stations and cell towers, a single base station serving a single cell tower, a single cell serving multiple cell towers, and multiple base stations coupled to a single MSC, to name just a few possible arrangements.

[0032] In accordance with disclosed concepts, it is often desirable to enable operation of a host vehicle by a person located outside the vehicle's passenger compartment, or in a combination of inside and / or outside the vehicle, without requiring prior authorization from that person or a wireless handheld computing device to input vehicle control instructions. Below, we discuss intelligent vehicle control systems and control logic for providing deviceless external instruction and control by third parties, for example, in predefined urgent situations where predicting the need for control and authorizing users in advance is not practical. Urgent situations may unexpectedly require a person to direct a vehicle from outside the vehicle using visual or audible instructions.Some non-restrictive examples of such "urgent" situations may include allowing law enforcement officers, military personnel, medics, or any first responders to: reposition a vehicle during a riot or crowd control incident; access a passenger compartment or move a vehicle to a road shoulder after a collision; relocate a vehicle from railway lines, intersections, etc., to resolve hazardous situations; move a vehicle with an officer inside to provide active protection and cover; move a vehicle to an open area if it is on fire or has the potential to catch fire, etc. Disclosed vehicle control modes may also be available in non-urgent situations such as...This disclosure can be used by original equipment manufacturer (OEM) personnel after a vehicle rolls off the production line (“pre-shipment mode”), by fleet personnel during leasing, delivery, or maintenance, by government personnel or sales personnel in a designated parking area / garage or virtual geofence, etc. While not limited in themselves, aspects of this disclosure may be particularly relevant for software-defined vehicles (SDVs), which manage vehicle operations, provide new vehicle functionality, and enable new in-vehicle user features substantially or entirely through software. SDVs are highly mechatronic intelligent devices that offer increased flexibility, customization, and remote upgradeability compared to their traditional counterparts.

[0033] In general, many motor vehicles cannot receive or authorize instructions from an external entity without some form of electronic device, wireless connectivity, and predefined unit assignment or authentication. Disclosed systems and procedures reduce or eliminate these obstacles by using vehicle-side sensors, available vehicle condition and state data, context-aware assessments, and so on, to dynamically evaluate and allow an external entity to control the host vehicle. For example, an intelligent vehicle control system can monitor obedience mode triggers and then, when received, attempt to detect an event that allows automatic authorization.Some such examples include vehicle controller acknowledgment of the following: an automated collision event call to a BO host vehicle service / vehicle instruction center; an airbag / seatbelt pretensioner / fast deployment / low stage deployment event; a thermal runaway propagation event (TRP event); a remote vehicle deceleration; geolocation data indicating that the vehicle is within a defined geofenced area; or the host vehicle is in a specific vehicle operating mode (e.g., manufacturing mode, fleet override mode, long-term remote authorization, etc.).

[0034] Upon confirmation of a valid trigger event, the vehicle system automatically allows external control to be taken over by a third party outside the vehicle, indicating the activated mode to the external party via visual and audible signals. The vehicle control system works in conjunction with an onboard network of sensors, such as cameras, motion sensors, and microphones, to receive visual or audible cues, such as predefined gestures (e.g., "secret" combinations of hand movements), verbal commands (e.g., preset passwords or specific words), predefined QR codes (dynamically downloaded from an instruction center, for example), or in-vehicle authorizations via buttons or displays. Under predefined conditions, the vehicle control system can receive remote authorization from an instruction center to enable external control.Remote control mode can be initiated in various ways, such as the host vehicle contacting an instruction center agent for authorization, the instruction center contacting the host vehicle to initiate authorization, a third party contacting the instruction center and providing proof of ownership or authority, or an instruction center agent contacting the third party, for example, after attempting to enter manual mode but exceeding a limit of invalid attempts. Once remote control mode is entered, the host vehicle can respond to valid instructions and reject invalid instructions (e.g., if they are not recognized or are deemed unsafe or illegal). The host vehicle can issue a visual / audible warning to the user for invalid instructions. The system can also time out (e.g.,The system will be notified (remotely or by default) if no further instructions are received or a threshold number of invalid instructions is received; and the system will automatically notify the instruction center and exit control mode. A general intention of at least some disclosed concepts is to provide controlled authorization of the instruction authority of a vehicle for a human or non-human operator, regardless of the vehicle's occupancy state.

[0035] Then, with reference to the schedule of Fig. 2, at 200 an improved method or an improved control strategy for providing external control of a motor vehicle such as the motor vehicle 10 of Fig. 1 by means of a unit outside, but in the vicinity of, the vehicle according to an embodiment of the present disclosure generally described. Some or all of the operations described in Fig. Figure 2, illustrated and described in more detail below, provides an example of an algorithm corresponding to non-transient processor-executable instructions that may be stored, for example, in main memory, auxiliary memory, or remote memory (e.g., storage device 38 and / or database 98). Fig. 1) are stored and are, for example, managed by an electronic controller, a processing unit, a permanently assigned control module, a logic circuit, or another module or device or network of modules / devices (e.g., the CPU 36 and / or the cloud computing service 24 of Fig. 1) are executed to perform some or all of the functions described above and below that are associated with an embodiment of the disclosed concepts. It can be seen that the execution order of the illustrated operation blocks can be changed, additional operation blocks can be added, and some of the operations described here can be modified, combined, or removed.

[0036] Procedure 200 begins in START terminal block 201 of Fig. 2 with processor-executable instructions stored in memory for a programmable controller or control module, or a suitably appropriate processor, to invoke an initialization procedure for an obedience mode protocol. This routine can be executed in real time, near real time, continuously, systematically, sporadically, and / or at regular intervals, e.g., every 10 or 100 milliseconds, during the operation of the motor vehicle 10. As yet another option, terminal block 201 can respond to a user instruction prompt (e.g., via telematics input controls 32), a resident vehicle controller prompt (e.g., via the CPU 36), or a broadcast prompt signal from an "external" centralized vehicle service system (e.g.,Initialize the BO-Cloud Computing Service 24), which may each be a signal or instruction for the vehicle, which is controllable in one or more modes (obedience, operation, etc.). By way of example and without limitation, the procedure 200 can be initialized by a host vehicle controller in response to monitoring for and detecting one of a variety of obedience mode instruction triggers. Non-limiting examples of possible instruction triggers are listed above and are detailed in . Fig. 2. Automatic trigger in data file 202, manual trigger in data file 204, and remote trigger in data file 206, each described in more detail below, are illustrated. After completion of some or all of the control operations described in Fig. As shown in Figure 2, the procedure 200 can proceed to the END terminal block 235 and temporarily end, or it can optionally loop back to terminal block 201 or decision block 203 and run in a continuous loop.

[0037] Progressing from terminal block 201 to the AUTOMATIC-TRIGGER decision block 203, procedure 200 determines whether or not an automatic trigger is received, which would automatically enable external control of the host vehicle using visual / audible instructions. The automatic trigger data file 202, stored in memory, indicates that an automatic trigger has been received by a vehicle controller (e.g., a vehicle's automatic system).the telematics unit CPU 36) may contain one or more sensor signals indicating the following: (1) an SOS / collision call was made to / from the host vehicle; (2) an airbag / seatbelt pretensioner / near-deployment event was detected in the host vehicle; (3) a thermal runaway propagation event was predicted or detected in the host vehicle's RESS; (4) a real-time or near-real-time location of the host vehicle is within a defined geofence; and / or (5) the host vehicle's operating mode is set to a "pre-sale" or "pre-shipment" mode (e.g., in OEM, dealer, or rental parking lot / garage / warehouse / etc.). It should be acknowledged that the automatic, manual, and / or remote triggers described herein may include more, fewer, or alternative triggers than those presented.

[0038] Upon receipt of one of the predefined automatic triggers (Block 203 = YES), procedure 200 proceeds to the predefined AUTOMATIC CONTROL MODE process block 205 and activates an automatic control mode that allows a unit outside the host vehicle to control predefined vehicle operations using one or more visual and / or audible cues. The automatic control mode can permit a limited (initial) set of vehicle operations, each of which can be triggered by a specific visual or audible cue received from the external unit.Because prior authorization of the external unit is not mandatory due to the compelling nature of an automatic control trigger, the set of vehicle operations stored in memory and assigned to it can be limited to only those vehicle control operations deemed necessary to protect the host vehicle and its occupants. The concept is that the host vehicle can request instructions from the external unit or provide instruction options to it.

[0039] After an external control mode is activated, procedure 200 can execute the EXTERNAL-CONTROL-CONFIRMATION process block 207 and provide visual / audible confirmation to the external unit that external control is activated and the host vehicle is ready to receive instructions. For example, the telematics unit CPU 36 can activate an automatic control mode (block 205), a manual control mode (block 225), or a remote control mode (block 231) and simultaneously instruct a vehicle subsystem of the host vehicle to issue a predefined visual and / or audible confirmation indicating that an external control mode is now active (block 207). For this purpose, an activation signal can be sent to a host vehicle lighting system (e.g., front turn signals, headlights, etc.) to produce a predefined light pattern (e.g., headlights flashing twice), or to a host vehicle audio system (e.g.,a vehicle horn or vehicle audio system) to generate a predefined sound pattern (e.g. horn sounds twice) or a predefined verbal confirmation (passenger compartment loudspeaker says “EXTERNAL CONTROL ACTIVATED!” off).

[0040] With continued reference to Fig. 2. Procedure 200 proceeds from process block 207 to the COMMAND-DETECTION decision block 209 to determine whether a control instruction is received by the host vehicle from the external unit. In a non-restrictive example, the vehicle controller (e.g., CPU 36 of Fig. 1) Communicate with a vehicle-side network of detection devices (e.g., a microphone 28, one or more digital cameras 62, one or more environmental sensors 64, etc.) to detect any visible and / or audible cues input by the external unit. If the external unit does not input any visible / audible cue, or if it does so in a manner or from a location that renders the cue undetectable by the host vehicle, the decision block 209 may conclude that no control instruction has been received.

[0041] As a further option, activating an external control mode (blocks 205, 225, or 231) can start a timer (e.g., using a real-time clock (RTC) 42), and decision block 209 can then monitor this timer to determine whether the vehicle's network of sensing devices detects a visual / audible cue within a preset timeframe (e.g., a window of no more than two (2) minutes). In this example, the vehicle controller can respond to the non-detection of a visual / audible cue within the preset timeframe by inferring that no visual or audible cue has been received.If no instruction is received (Block 209 = NO), the procedure 200 executes the NO-COMMAND-TIMEOUT block 211 and sets a marker in a buffer indicating that neither an audible nor a visible instruction has been detected, and then executes the predefined EXTERNAL-CONTROL-DISABLED process block 213 and disables the previously enabled external control mode.

[0042] If a sensor-detectable instruction is received from the external unit (Block 209 = YES), Procedure 200, in response, executes VALID-COMMAND decision block 215 to determine whether the detected visual / audible cue is one of several preset valid instructions. For example, the one or more digital cameras 62 may detect a first responder signaling with their right arm and hand that the host vehicle should move to the shoulder of the road; and sensor signals indicating these hand gestures are sent to CPU 36 for processing and evaluation. CPU 36 can compare the detected hand gesture with a preset list of valid instructions—the restricted set of vehicle operations—which may be enumerated in a lookup table stored in memory and assigned to the automatic control mode.If the detected hand gesture corresponds to one of the valid instructions listed in the vehicle operation set, CPU 36 infers that a valid instruction has indeed been received (Block 215 = YES). Consequently, Procedure 200 automatically triggers the EXECUTE COMMAND process block 217 to send one or more instruction signals to a necessary resident vehicle subsystem or a subsystem of the host vehicle to automate vehicle operation according to the preset valid instruction associated with the detected cue. At this interface, Procedure 200 can loop back to Decision Block 209 and monitor for additional instruction inputs; otherwise, Procedure 200 can disable the external control mode in the predefined process block 213 and then temporarily terminate in Terminal Block 235.

[0043] Based on a determination that the detected external instruction is not recognized as one of the preset valid instructions (Block 215 = NO), Procedure 200, in response, causes the COMMAND-FAILURE-NOTIFICATION Process Block 219. Process Block 219 can provide computer-readable commands that cause the host vehicle to provide a predefined visual / audible output to the external unit indicating that the received instruction is a invalid or rejected instruction. It may be desirable for the visual / audible outputs implemented in Process Block 219 (e.g., a single horn blast or a single flash of both front turn signals) to be different from the visual / audible outputs implemented in Process Block 207 (e.g., a double horn blast or a double flash of the front headlights).At this interface, the procedure 200 can loop back to decision block 209 - and each of the situation-relevant process blocks downstream of it - where the vehicle controller communicates with the networked detection devices, in order to receive additional (new) sensor signals from the external unit that indicate the detection of additional (new) clues.

[0044] Before looping back to decision block 209 from process block 219, procedure 200 may optionally execute the FAILED-THRESHOLD decision block 221 to determine whether the external entity has exceeded a predefined maximum number of attempts to enter a valid instruction. As a non-restrictive example, activating an external control mode in process blocks 205, 225, or 231 may overlay a time-overflow invalid instruction counter built into the control algorithm. For example, after the automatic control mode is activated in process block 205, the external entity may be granted five (5) attempts to enter a valid instruction before the system disables automatic control. Optionally, a different number of attempts may be set with respect to the severity of the situation or the purpose of vehicle control (e.g.,More attempts are granted during an urgent situation than during a non-urgent situation. There is also the idea that the number of attempts can be dynamically set by the vehicle control system or the BO-Host vehicle service based on vehicle sensor feedback, context-dependent data, vehicle state, the identity of a remote user, etc. Based on a determination that the external entity has exceeded its allocated maximum number of instruction attempts (Block 221 = YES), Procedure 200, in response to Block 213, disables the external control mode. Conversely, if the entity has not exceeded its allocated maximum number of instruction attempts (Block 221 = NO), Procedure 200 loops back through Process Block 209.

[0045] Returning to processing block 203 of Fig. 2. Procedure 200 does not need to respond to the receipt of a predefined automatic trigger (block 203 = NO) by executing the MANUAL-TRIGGER decision block 223 to determine whether a manual trigger is received or not to allow manual external control of the host vehicle. The data file 204 stored in memory for manual triggers indicates that a manual trigger may contain a message indicating that a vehicle controller (e.g.,The telematics unit CPU (36) receives one or more sensor signals indicating: (1) detection of a predefined “specialized” gesture or sequence of gestures; (2) scanning of a quick reference code (QR code), barcode, data matrix code, NFC or RFID tag, or widely scannable or detectable handheld device item assigned to a specific level of access; and / or (3) receipt of in-vehicle authorization from a driver or occupant of the host vehicle. Other examples of possible “manual” triggers may include the vehicle controller and a vehicle-side sensor network working together to identify a recognized user pattern (e.g., an EMS or law enforcement uniform, helmet, or other protective gear), rank, special identification, biometric characteristics, etc.

[0046] Upon receiving at least one of the predefined manual triggers (Block 223 = YES), Procedure 200 proceeds to the predefined MANUAL-CONTROL-MODE process block 225 and activates a manual control mode that allows a unit outside the host vehicle to control predefined vehicle operations using one or more visual and / or audible cues. The manual control mode may allow a less restricted (second) set of vehicle operations, each of which can be triggered by a respective visual or audible cue received from the external unit. Because some form of preauthorization of the external unit is required to enable manual control, the set of vehicle operations stored in memory and assigned to it may grant more vehicle control operations than those provided for automatic control.Similar to the automatic control mode, however, the number and type of vehicle operations available during external vehicle control can be increased or decreased based on situation-specific data (e.g., the level of pre-authorization provided).

[0047] If neither an automatic nor a manual trigger is received (Block 203 = NO && Block 223 = NO), in response, Procedure 200 executes the TRIGGER FAILURE NOTIFICATION process block 227, causing the host vehicle to provide a predefined visual / audible output designed to inform the external unit that no valid trigger has been received or that a received trigger is deemed invalid. It may be desirable for the visual / audible outputs implemented in process block 219 (e.g., a single horn blast or a single flash of both front turn signals) to be different from the visual / audible outputs implemented in process block 227 (e.g., three rapid horn blasts or flashing of headlights) to help ensure that the external unit can distinguish between these notifications.

[0048] The procedure 200 of Fig. Process 2 proceeds from process block 227 to the remote trigger decision block 229 to determine whether or not a remote trigger is received to enable remote external control of the host vehicle. The remote trigger data file 206, stored in memory, indicates that a remote control request trigger may be received by a vehicle controller (e.g., a remote trigger).The telematics unit CPU (36) receives one or more sensor signals indicating the following: (1) a call was made by an occupant or controller of a host vehicle to a BO host vehicle service (also referred to herein as the "Vehicle Instruction Center"); (2) a call was made by an external unit or other third party to the BO host vehicle service; (3) a call was received by the host vehicle from the BO host vehicle service; and / or (4) the received manual triggers were detected but not authorized, and authorization for external control is requested. In general, remote control authorization may require some form of "off-board" authorization process, or the centralized instruction center may require either taking control of the host vehicle or authorizing external control for a local third party.Based on a determination that the remote control attempt was unsuccessful (Block 229 = NO), the procedure 200 can loop from decision block 229 back to terminal block 201 or decision block 203, or can temporarily terminate in terminal block 235.

[0049] Upon receiving at least one remote control trigger (Block 229 = YES), Procedure 200 proceeds to the predefined REMOTE-CONTROL-MODE process block 231 and activates a remote control mode in response to remote authorization, allowing a vehicle instruction center and / or an external unit to control predefined vehicle operations. The remote control mode can enable an extended (third) set of vehicle operations, each of which can be triggered by a specific visual or audible cue received from the external unit. Because enhanced preauthorization of the external unit is required to enable remote control, the set of vehicle operations stored in memory and assigned to it can grant more vehicle control operations than those provided for manual control mode.In addition to or as an alternative to approving control of an external unit, remote control of the host vehicle can be summarized by the vehicle command center. For example, procedure 200 can execute the REMOTE-CONTROL-APPROVED decision block 233 to determine whether an external unit can assume vehicle control using visual / audible cues. If yes (block 233 = YES), procedure 200 proceeds to process block 207; otherwise, procedure 200 can respond to a rejection of remote control (block 233 = NO) by disabling an external control mode in process block 213.

[0050] Then, with reference to the schedule of Fig. 3 a further embodiment of an improved method or an improved control strategy for providing external control of an autonomously operated vehicle such as the motor vehicle 10 of Fig. 1 by means of a unit outside, but in the vicinity of the vehicle at 300 according to some embodiments of the present disclosure generally described. Some or all of the operations described in Fig. Figure 3, illustrated and described in more detail below, provides an example of an algorithm corresponding to non-transient processor-executable instructions that may be stored, for example, in main memory, auxiliary memory, or remote memory (e.g., the storage device 38 and / or the database 98 of Fig. 1) are stored and are, for example, managed by an electronic controller, a processing unit, a permanently assigned control module, a logic circuit, or another module or device or network of modules / devices (e.g., the CPU 36 and / or the cloud computing service 24 of Fig. 1) can be executed to perform some or all of the functions described above and below that are associated with the disclosed concepts. It should be noted that the execution order of the illustrated operation blocks can be changed, additional operation blocks can be added, and some of the operations described here can be modified, combined, or removed.

[0051] Procedure 300 begins in block 302 of Fig. 3 with processor-executable instructions stored in memory, so that a programmable controller or control module or suitably appropriate processor may invoke an initialization procedure for an obedient mode or an operating mode upon receipt of a suitable signal indicating that the vehicle is controllable in such a mode. Block 302 may be similar to Block 201 of Fig. 2 and include features described above. Block 302 may include continuous monitoring for instruction triggers that start or place a vehicle in an obedient mode. As appropriate with respect to Fig. As described in Section 2, Block 302 can initialize a user instruction prompt (e.g., via telematics input controls 32 from inside or outside a vehicle), a resident vehicle controller prompt (e.g., via the CPU 36), or a broadcast prompt signal received from or originating from an "external" centralized vehicle service system (e.g., the BO cloud computing service 24 or a central instruction and control location). By way of example, and without limitation, the procedure 300 can be initialized by a host vehicle controller in response to monitoring for and detecting a particular obedience mode instruction trigger or signal, which may themselves be instructions for the vehicle to perform certain actions, in one or more of these operating modes.In addition to the non-restrictive examples of possible instruction triggers listed above and in . Fig. As illustrated in point 2, further triggers can include the cyberattack data ( Fig. 5), an automatic trigger (which may be similar to the automatic trigger data 202), ADAS intervention data ( Fig. 6), Standstill data ( Fig. 7), Battlefield data (or attack data) ( Fig. 8) and battlefield problem detection data ( Fig. 9), each of which is further described below. After completion of some or all of the control operations described in Fig. As shown in Figure 3, the procedure 300 can end, similar to the description of the END terminal block 235 of Fig. 2, can temporarily terminate or can optionally loop back to block 301 and be executed in a continuous loop. The external control can be removed in procedure 300 according to block 213, as above for Fig. 2 was described.

[0052] In some embodiments, the signal indicating that the vehicle is controllable in one or more operating modes is received by a remote back office, control center or instruction center that can control and / or authenticate the vehicle operating in such modes.

[0053] Various obedience or operating modes can be activated and implemented by procedure 300, including those listed in blocks 304, 306, 308, 310, 312, and 314, as well as those operating modes described in Fig. 2 (e.g., blocks 203, 223, and 229) contain. The activation of any of these modes (e.g., a "yes" decision in the preceding blocks) and operations (e.g., instructions indicated by a hint) that can be performed in these modes can be controlled by a set of unique data for each of these modes. All of this data can be stored in the controllable vehicle or accessed remotely. For example, according to some embodiments, cyberattack data 500, as in Fig. Figure 5 shows how to influence or determine a vehicle's operation. Based on the detection of a cyberattack, as determined by Data 502, the vehicle's actions may be restricted to a set of actions that may be unique to a cyberattack obedience mode. For example, Data 504 may restrict the vehicle's actions to defensive actions only. More specifically, if a vehicle is, for example, a military vehicle capable of both offensive and defensive actions, the vehicle may be restricted to defensive actions only if it is detected that the vehicle may be compromised or attempts are being made to compromise it as a result of a cyberattack. Such restrictions on operation as a result of a cyberattack may also be applied to instructions occurring in other obedience modes.In other examples, Data 504 can generate an operating mode that, during a cyberattack, more generally restricts vehicle actions and / or requires additional authentication, encompassing actions in further obedience modes. An access control list can regulate access to this mode, with action procedures enforcing restricted actions (e.g., instructions). Examples of a restricted action might include limiting offensive functionality, restricting actions to positioning instructions (e.g., retreating to a safe location), or limiting the vehicle to providing shielding capabilities to protect personnel or equipment.

[0054] Access control lists, which trigger any of the obedience modes, can use any of a variety of factors to determine whether a unit has access to a vehicle's requested instructions. Such factors may include uniforms, rank, insignia, unit badges, worn national insignia, short-range emissions, radio or other predefined symbols worn or displayed by the unit requesting access, name tags, facial recognition or other biometric identifiers and infrared markings, in addition to other factors known to relevant experts.

[0055] As another example, Block 506 can provide data that grants more restricted access and / or additional authorizations required to execute certain instructions. For instance, while a vehicle might be controllable simply by providing an external cue, a potentially compromised vehicle might require additional cues or authentication before executing an instruction. For example, an operator might pair with the vehicle to provide biometric data or use an electronic device that provides an additional authentication factor before the vehicle executes an instruction.An access control list can manage access to specific actions / instructions, and action procedures can be executed depending on approval from an authorized source in the vehicle prior to execution and / or from another external entity via a secure connection.

[0056] The 508 data can only control the vehicle with manual instructions, such as those listed above. Fig. The procedures described in blocks 204 and 223 may restrict the vehicle's ability to respond to external instructions. This may require a direct connection to the vehicle, rather than, for example, the use of wireless instructions (such as short-range wireless, optical, or audio) to guide the vehicle. A direct connection may be accessible on an external surface of the vehicle or may be required internally, which in turn may require additional authentication factors, such as a key. The procedures described in blocks 510 may further restrict the external instructions to which the vehicle can respond. For both the procedures described in blocks 508 and 510, the procedure described in blocks 300 may implement an access control list to limit the available external instructions, allowing only manual instructions or limited capabilities based on authentication levels that may be further restricted following the detection of a valid cyberattack.

[0057] According to some embodiments, an override autonomous mode obedience mode can be regulated by data 600, as in Fig. Figure 6 shows that this autonomous mode can be regulated by an ADAS. While the following description may refer to an ADAS, it may also be applicable to other autonomous operating modes and systems.

[0058] Similar to the cyberattack mode, the activation of the mode to interfere with autonomous mode, as specified by block 602, can be regulated by an access control list, as described above. This list establishes criteria for accessing certain action procedures or instructions that an external entity can provide to the vehicle, as specified by block 604. Data block 606 can further contain criteria that regulate which instructions the vehicle can accept in this mode. For example, data block 606 can contain information related to the complexity or simplicity of the monoverse (or environment) in which certain actions can be performed. This scope can be small and can define the area in which interference with the ADAS is permissible. This includes, for example, the use of geofences or other situational factors that regulate whether interference with the ADAS is allowed.Actions can be limited to returning to a home base, a more permanent location, a maintenance depot, or expanding the area in which the vehicle can operate. For example, the ADAS can restrict the vehicle's operating area, and the ADAS intervention mode can expand that area. Other ADAS features, such as braking or collision avoidance, can also be overridden in this mode, provided a suitable instruction is given by a unit with sufficient authority to issue that instruction. Furthermore, the instruction to override the ADAS does not necessarily require further instructions from the external unit that sends the warnings or signals to the vehicle. For example, after ADAS intervention, the vehicle performs automated tasks without the restrictions of the ADAS.In some embodiments, the ADAS intervention mode is implemented with an access control list to control access to the activation / deactivation of the ADAS system and defines action procedures to activate / deactivate the system in response to authorized prompts / instructions. Such features can be implemented with or without the installation of external devices or the requirement of manual vehicle control.

[0059] According to some embodiments, a stand-hold obedience mode can be implemented according to Data 700, as in Fig. Figure 7 shows that in block 702, the stand-on obedience mode is implemented according to various criteria, which may be implemented, for example, in an access control list. This mode can define an autonomous stand-on mode using predefined criteria and an access control list for access control. In this mode, vehicles can respond to various instructions regulated by data blocks 704, 706, 708, and 710. For example, as shown in block 704, the vehicle can enter a mode to request assistance from another vehicle, unit, or entity such as a vehicle, the nearest base, or a person. Instructions specified in data block 704 can also use predefined or dynamic criteria and an access control list as a basis. As another example, block 706 can provide data that regulates a retreat mode.In this mode, instructions can be entered that can disable offensive capabilities and / or trigger a retreat to a secure position. As another example, Block 708 can contain data regulating instructions related to patrolling. These patrols can be conducted in predefined or dynamically geofenced areas and utilize access control lists that govern access to this functionality. Block 710 can regulate an auto-start / stop mode. In this mode, the vehicle can automatically start / stop various battery maintenance systems based on predefined states and an access control list that regulates access to this functionality. Such communication can help extend the vehicle's range and the time it can be away from a charging and / or refueling station.This mode can also include autonomous forward or backward movement of the vehicle based on a situational analysis and an access control list.

[0060] According to some embodiments, the vehicle can be placed in a battlefield obedience mode regulated by Data 800, as in Fig. Figure 8 illustrates this. For example, the vehicle can use an access control list and other predefined criteria specified by Data 802 to enter this mode. When in battlefield mode, the vehicle can accept instructions according to Data 804, 806, and 808, which can enable autonomous action by the vehicle. For example, Data 804 can define executable instructions for an offensive / attack mode, which includes a retaliatory mode, allowing the vehicle to take autonomous action in these modes. According to Data 806, the vehicle can be placed in a battlefield-oriented deployment, in which the vehicle could autonomously self-destruct or be instructed to do so if, for example, it is detected or an external entity determines that the vehicle may be compromised. Accordingly, the vehicle could enter a kamikaze mode.According to data in Block 808, instructions can be issued to interfere with the security systems of equipment containing battlefield equipment. For example, a security system related to firing a pistol can be affected by this mode, potentially lowering or raising the criteria for using the weapon. Such operations can use an access control list to control access to interfere with instructions for battlefield equipment and security systems. Such an access control list can define or list multiple criteria for these instructions to occur. For example, the vehicle might need to be in a specific mission mode for one or more security instructions to be interfered with. This could allow the vehicle to take a destructive path to its destination and be deployed in specific areas.Criteria that can be specified in Data 808 include the location of the vehicle, its proximity to specific locations (e.g., enemy lines) or positions in relation to them.

[0061] According to some embodiments, a "detecting problems on the battlefield" obedience mode is regulated by Data 900, as in Fig. Figure 9 shows that in this mode, the detection and warning algorithms can be used to detect problems or concerns in the environment, as well as access control list-driven action procedures to relay hazard warnings to other vehicles, as specified by Data 904. Given instructions can also include forwarding or communicating hazards to warn other vehicles or units, as specified by Data 906. Similarly, Data 908 can be used to create a checkpoint or warning point for other vehicles or units. As specified by Data 910 and 912, this mode can define and restrict access to instructions aimed at using the vehicle as a shield (910) and / or setting priorities for protecting facilities (912).Both data blocks can define an access control list to control which actions can be instructed by which instructions from external entities. They can further define criteria such as prioritizing asset protection, for example, protecting lives over equipment and more valuable equipment over less valuable equipment. For instance, instructions according to Data Block 910 can allow the vehicle to act as a shield for people or other equipment, as specified by an entity issuing instructions to the vehicle. This enables the vehicle to provide a defensive function in the face of an aggressor threatening violence. When asset protection (such as that regulated by Data Block 912) is prioritized, it can be useful to direct the autonomous vehicle to dangerous locations by means of an external instruction that provides an instruction to the vehicle.Lives can be protected from cargo, and cargo can be classified by a value that can be predefined or dynamically defined by instructions given to the vehicle by the external unit.

[0062] According to some embodiments, one or more additional obedience modes can be implemented. For example, the classification and access of instructions related to the deployment and positioning of the vehicle can be managed using an access control list to determine access to deployment and positioning instructions based on factors such as location, proximity to enemy lines, and facility priority.

[0063] Returning to Fig. 3. Procedure 300 proceeds from block 301 to the valid cyberattack decision block 304. Procedure 300 determines whether a valid cyberattack is detected or not, which can restrict the types of external instructions to which a vehicle will respond due to the vehicle being in a compromised state. The cyberattack data file stored in memory of Fig. 5 indicates that a cyberattack trigger is detected by the vehicle or an external unit, which initiates the process of executing instructions as defined by the cyberattack data file. Fig. 5, which is determined, can be implemented according to procedure steps 316 to 332. The cyberattack obedience mode can first check in block 304, since the detection of a potentially compromised vehicle may affect the ability to enter the subsequent obedience modes or may limit the actions taken. According to some embodiments, the decisions as to whether or not to enter the respective obedience mode, as indicated by the decisions in blocks 304, 306, 308, 310, 312, and 314, can be independent of each other.

[0064] Upon receiving any predefined triggers that activate any of the obedience modes, such as a "yes" response to any of the following: Cyber ​​Attack Block 304, Automatic Trigger Block 306, ADAS Intervention Block 308, Standstill Block 310, Battlefield (or Attack) Block 312, or Battlefield Problem Detection Block 314, Procedure 300 proceeds to Block 316 and subsequent blocks (e.g., 324, 326, and 328) to determine whether an instruction can be executed according to the data governing such a mode (as described above). Such instructions may be given, or attempted to be given, by a clue or signal detected by the vehicle. Each of these obedience modes allows a unit outside the vehicle to override predetermined operations of the vehicle using one or more visual, audible and / or other cues (such as...).Short-range wireless communication) to control. Each obedience mode can permit a limited, unique set of vehicle operations, each of which can be triggered by a specific cue (audible, visual, or other) received from the external unit. Following activation of the obedience mode, the vehicle can execute an acknowledgment that it is available for external control, such as that described for Block 207 above. Fig. As described in section 2, it is ready. Such confirmation by the vehicle may be unique for the activated obedience mode.

[0065] Procedure 300 can proceed with further steps in response to the activation of an obedience mode. For example, in block 316, the procedure can determine whether successful authentication of the external entity has been performed. Different levels and types of authentication may be required based on the one or more specific obedience modes in which the vehicle is operating, as well as the specific instruction the external entity is attempting to provide to the vehicle, as regulated by the data block for that obedience mode. For example, an instruction to intervene in safety systems may be subject to more thorough access control techniques than a simple repositioning of the vehicle, which does not interfere with the ADAS and would not create a condition under which the vehicle could harm people or damage equipment.

[0066] If authentication fails, the vehicle may store data related to the failed authentication in block 318 and / or allow the vehicle to enter a spying (or observation) mode. This step may be taken because the absence of successful authentication may indicate that the vehicle is compromised or in a compromising situation, such as being near personnel not authorized to direct the vehicle. Block 320 may cause the vehicle to enter a lock-up mode if the vehicle detects that it is compromised or if an external entity informs the vehicle of this. This lock-up may restrict the actions the vehicle can perform and may result in an asset recovery or reconfiguration mode in block 322.

[0067] If authentication is successful, the procedure checks in block 324 whether control of the vehicle is authorized. If control is not authorized, the procedure returns to check whether an obedient mode has been entered, and if so, returns to block 316.

[0068] If the control is approved in block 324, procedure 300 proceeds to block 326, where the vehicle determines whether an instruction has been received. According to some embodiments, block 326 may be substantially similar in its performance to block 209, as described above for Fig. 2 described above. As stated above, instructions and the cues that provide those instructions can vary depending on the obedience mode in which the vehicle is operating. Furthermore, while these instructions can be given by audio and visual signals, other signals, such as direct interaction with and / or touching the vehicle or using one of the sensors mentioned above, can also provide these cues, triggering the instructions according to the obedience mode data discussed above. Block 326 can also provide timing controls, such as those described above in relation to Block 211. Fig. 2 are specified, contained, or linked to them. Such features can serve to limit the time for which the vehicle operates in an obedience mode before reverting to another operating mode.

[0069] Block 328 determines that the instruction / instruction is not valid (Block 328 = no), and the vehicle can indicate a fault in Block 332 by providing an audible, visual, or other indication to an external operator of the vehicle. Block 328 can be similar to the valid instruction block 215 of Fig. 2. Furthermore, procedure 300 can be used to make an error threshold decision similar to block 221 of Fig. 2. Due to reaching such a threshold of invalid instructions, Procedure 300 may proceed to Blocks 320 and 322, since reaching this threshold may indicate that the vehicle may be in a physically compromised location or otherwise being directed by an entity that need not have the authority or training to control the vehicle from outside.

[0070] If the instruction is determined to be valid (block 328 = yes), the procedure in block 330 can execute the instruction according to the obedience mode to which the instruction belongs. The execution of this instruction can be similar to that described for block 217, as referenced in Fig. 2 is described.

[0071] Similar to Procedure 200 and in particular Blocks 211 and 221, Procedure 300 can terminate the external control of the vehicle as in Block 213 if no external instruction is detected and / or there is evidence that the vehicle may be compromised or that an external user is not properly trained in the operation of the vehicle, e.g., when a certain threshold is reached by a number of instruction attempts that fail to provide a valid instruction.

[0072] According to some embodiments, Fig. 4 a method 400 and a further embodiment of an improved method or an improved control strategy for providing an external control of an autonomously operated vehicle such as the motor vehicle 10 of Fig. 1. By means of a unit outside, but in the vicinity of the vehicle, is generally described in section 400 according to one embodiment of the present disclosure. Some or all of the operations described in Fig. Figure 4, illustrated and described in more detail below, can provide an example of an algorithm corresponding to non-transient processor-executable instructions that may be stored, for example, in main memory, auxiliary memory, or remote memory (e.g., storage device 38 and / or database 98). Fig. 1) are stored and are, for example, managed by an electronic controller, a processing unit, a permanently assigned control module, a logic circuit, or another module or device or network of modules / devices (e.g., the CPU 36 and / or the cloud computing service 24 of Fig. 1) can be executed to perform some or all of the functions described above and below that are associated with the disclosed concepts. It can be seen that the execution order of the illustrated operation blocks can be changed, additional operation blocks can be added, and some of the operations described here can be modified, combined, or removed. Furthermore, any of the blocks of Procedure 400 can be combined with the procedures described above by Fig. 2 and Fig. 3 can be combined and vice versa.

[0073] The procedure can start in block 402, in which case the vehicle's ignition is switched on. As a standard, the vehicle can start in an autonomous mode in block 404, which may resemble more conventional functionality for autonomous vehicles. Procedure 400 continuously monitors for a clue or signal to put the vehicle into an obedient mode in block 406. Block 406 may be similar to block 302, which is described above. Fig. 3 is discussed. This monitoring can, for example, use access control lists and external indicators from units attempting to interact with the vehicle. These obedience modes can be similar to the obedience modes discussed above in relation to Fig. 2 and Fig. 3 will be discussed. In some embodiments, the signal indicating that the vehicle is controllable in one or more operating modes is received by a remote back office, control center, or instruction center that can control and / or authenticate the vehicle operating in such modes.

[0074] If no such acceptable interaction is detected, the vehicle may be instructed in Block 408 to enter a recovery mode, or it may enter recovery mode on its own if, after a certain period of time, no instruction to enter an obedience mode is detected, and / or after a number of failed interactions, or if no instructions are received, as specified by Block 410. In such a mode, the vehicle may enter a self-protection mode in Block 412, in which it may defend itself from harm in Block 414 until the vehicle is recovered and / or an appropriate obedience mode is instructed. In some embodiments, the vehicle may revert to an autonomously operating mode.

[0075] If an instruction or signal to enter an obedient mode is detected in block 406 (block 406 = yes), then procedure 400 proceeds to check the authentication of the unit attempting to control the vehicle in block 416. This authentication may be similar to the authentication check in block 316, which was described above in relation to Fig. 3 is being discussed.

[0076] If authentication fails, a count can be incremented in block 418, which can issue a warning flag indicating the failed authentication. This count can be compared to a predefined threshold in block 420. If the threshold is exceeded, a central instruction authority can intervene in block 448. If the central instruction authority so desires, it can release the lock in block 450 and cause the vehicle to seek further instructions (block 434). Alternatively, in block 452, the central instruction authority can instruct the vehicle to enter a lockout mode because the vehicle may be compromised. In block 454, the vehicle can also store the data or enter a spy mode to collect data regarding the failed authentication. The vehicle can also enter a recovery mode, as described in [reference to relevant documentation]. Fig.As discussed in section 3 above. In some embodiments, the vehicle can enter blocks 452 and 454 and any possible recovery mode without an affirmative instruction from the central authority. Rather, the vehicle may perform such an action due to a failure to receive the instruction from the central authority for block 450 to release the lock and / or counter. If it is in a lock mode, the vehicle may also instruct itself to protect valuable information or equipment it may carry, such as by destroying such information or equipment.

[0077] If authentication is successful, procedure 400 can move to block 422 to determine whether to respond to the cue / signal if the unit attempts to control the vehicle and execute the instructed instruction. This determination can include several further determinations. For example, block 424 can determine whether the instruction given by the cue meets certain legal requirements, such as identifying suitable destinations and / or their location within an authorized area, which may be defined by a geofence. Block 426 can also determine whether the instruction is chosen by a user, and if so, block 428 whether higher-level authorization is required.For example, if the instruction is to intervene in a safety system, such an instruction may require approval from a higher authority before this action can be carried out. This higher-level authority could be internal to the vehicle, another external but still local entity, or a remote entity such as a central authority. If additional authorization is required, procedure 400 proceeds to decision block 446. If the additional authorization is not granted, the process proceeds to block 434 to consider further instructions.In some embodiments, an error in successfully granting approval from a higher authority may increment an incremental counter similar to the one used for authentication, which may lead to actions similar to those provided by blocks 420, 458, 450, 452, 454, and a possible asset recovery.

[0078] If additional authorization is granted, or if no additional authorization is required, procedure 400 proceeds to block 430, where the vehicle provides an indication (e.g., audible, visual, or other) of acceptance of the instruction it is executing. In block 432, the vehicle may provide an indication of whether or not it has successfully executed the instruction before proceeding to check for multiple instructions received in block 434. If no further instructions are detected, procedure 400 returns to block 404, where the vehicle operates in autonomous mode.

[0079] Returning to blocks 422 and 426, if a block is unsuccessful, procedure 400 proceeds to block 438, where the vehicle can request or provide a message indicating that the instruction should be reissued. If no message is provided, the procedure in block 440 may involve notifying an instruction center or central instruction authority of the error. In block 442, the instruction center may classify the problem and then, in block 444, notify the user of the faulty instruction and / or provide the correct instruction to the vehicle before returning to block 422 to await further instructions.

[0080] In various embodiments described above, the autonomous system, which can include defensive systems, encompasses a range of features designed for adaptability and resilience in scenarios where vehicle control may be contested. The system can include capabilities such as remote ADAS system control (activate / deactivate), cyberattack detection that triggers a limited defense mode, and various autonomous modes for different situations. Performance management can be employed to ensure extended communication, while patrol and battlefield operational features / modes enable flexible responses to threats. Conflict detection and response mechanisms / modes allow for proactive problem identification and the relaying of a threat to other vehicles.Asset protection and prioritization modes ensure the safety of valuable cargo and assets, with the system adapting strategies based on threat levels and mission objectives. Overall, the system aims to provide comprehensive defense capabilities while prioritizing security and mission success in a manner that can be controlled externally using cues such as audible and visual signals. While some of the embodiments described above are for battlefield scenarios, a person skilled in the art will recognize that the instructions above can be applied to other scenarios where, for example, a relaxation of security requirements may be justified.

[0081] Several benefits are provided by the embodiments disclosed herein. Among these are: Security enhancement: preventing or reducing unauthorized access and mitigating cyberattack risks for the control, including remote control, of autonomous vehicles; Cybersecurity resilience: effectively detecting and responding to cyber threats; Operational flexibility: autonomously adapting to various scenarios in response to external cues, including in contested environments, for improved mission effectiveness; Resource optimization: extending mission duration and increasing operational efficiency; Tactical advantage: autonomously intervening in offensive and defensive actions in a well-regulated and controlled manner; Safety and risk mitigation: performing critical actions in high-risk situations, thereby ensuring the safety of personnel and equipment.Mission effectiveness: Optimizing mission execution and increasing situational awareness; threat detection and warning: Improving situational awareness and enabling stronger and better-coordinated responses; and asset protection and prioritization: Prioritizing critical assets, minimizing losses, and maximizing mission objectives.

[0082] The embodiments disclosed herein provide the capability to safely and securely control a vehicle from the outside using hand gestures and signals, while avoiding counter-detection threats in combat situations. This enables the operation and movement of a vehicle without having to enter it. This provides greater ease of use and mobility for autonomous vehicles for various purposes, including the delivery of medicines and food, disaster response, and more effective evacuation and rescue, including in hostile environments.

[0083] In some non-restrictive examples, visible cues described herein may include hand gestures, head movements, body movements, hand-drawn or hand-operated signage, instructions displayed by means of an electronic display device, etc. In some non-restrictive examples, audible cues described herein may include verbal instructions, oral sounds (e.g., whistling), human-generated sounds (e.g., clapping, thigh-slapping, finger-snapping, foot-stamping), sounds emitted by means of an audio loudspeaker, etc. As a further option, any of the external control modes described herein may enable an external unit to execute a preset number N of instructions (e.g., the next five (5) instructions pre-approved by a central instruction authority).Another option may include the ability to propagate a gesture-based instruction from a lead vehicle (first vehicle) to one or more coordinated (second, third, fourth, etc.) vehicles in a formation. The control system can be programmed so that one or more instructions need not be executed in predefined areas, or a higher authority can grant authorization for activation. As yet another option, a wirelessly enabled "talking" vehicle of a third party can be operated, for example, to connect to the host vehicle using V2V communication protocols to authorize external control of the host vehicle or to act as a target vehicle followed by the host / deputy vehicle.

[0084] In at least some embodiments, an intelligent vehicle control system can manage conflicting instructions using intervention or cloud-based forwarding devices that seek intervention. If an instruction conflict cannot be resolved using any of the preceding "standard" protocols, the host vehicle can contact a BO vehicle instruction center for conflict resolution. As another option, an intelligent vehicle control system can indicate a request for external control (e.g., via lights, horn, wheel movement, etc.), or a visual / audible instruction can require additional / supplementary "confirmation" to proceed, for example, if the vehicle controller determines that a requested maneuver is risky or prohibited. If an identification threshold is not met, the host vehicle can indicate that supplemental authorization or intervention is required.

[0085] In some implementations, conflicting instructions can be addressed by prioritizing instructions from individuals with higher levels of authority, such as personal rank and / or positional authority. An access control list or databases may use additional criteria, facial recognition, name badges, country indicators, infrared markers, and other information as part of the access control decision.

[0086] Aspects of this disclosure may, in some embodiments, be implemented by a computer-executable program consisting of instructions, such as program modules, generally referred to as software applications or application programs, which is executed by any one of the controllers or controller variations described herein. In non-limiting examples, the software may include routines, programs, objects, components, and data structures that perform specific tasks or implement specific types of data. The software may provide an interface to enable a computer to respond according to an input source. The software may also interact with other code segments to initiate a variety of tasks in response to received data in conjunction with the source of the received data. The software may be stored on any one of a variety of storage media, such as...Data may be stored on CD-ROM, magnetic storage media and semiconductor storage devices (e.g., various types of RAM or ROM).

[0087] Furthermore, aspects of this disclosure can be implemented with a variety of computer systems and computer network configurations, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Additionally, aspects of this disclosure can be implemented in distributed computing environments, where tasks are performed by resident and remote processing devices linked by a communication network. In a distributed computing environment, program modules can reside in both local and remote computer storage media containing storage devices. Therefore, aspects of this disclosure can be implemented in a computer system or other processing system in conjunction with various hardware, software, or a combination thereof.

[0088] Any of the methods described herein may contain machine-readable instructions for execution by: (a) a processor, (b) a controller, and / or (c) any other suitable processing device. Each algorithm, software, control logic, protocol, or method disclosed herein may be embodied as software stored on a physical medium such as flash memory, solid-state storage (SSD), hard disk storage (HDD), CD-ROM, digital versatile storage medium (DVD), or other storage devices. Alternatively, the entire algorithm, control logic, protocol, or method and / or parts thereof may be executed by a device other than a controller and / or embodied in firmware or permanently assigned hardware in an available manner (e.g.,The machine-readable example instructions may be implemented using an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a field-programmable logic device (FPLD), discrete logic, etc. Furthermore, although specific algorithms may be described with reference to flowcharts and / or workflow diagrams shown here, many other methods for implementing the machine-readable example instructions may be used alternatively.

[0089] Aspects of the present disclosure have been precisely described with reference to the illustrated embodiments; however, those skilled in the art will recognize that many modifications can be made without departing from the scope of the present disclosure. The present disclosure is not limited to the specific construction and compositions disclosed herein; all modifications, changes, and variants apparent from the preceding descriptions are within the scope of the disclosure as defined in the appended claims. Furthermore, the present concepts expressly include all combinations and subcombinations of the preceding elements and features. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] WO 18 / 304,431

[0001]

Images