System and method for implementing a server architecture for on-demand autonomous (ODA) services

Abstract

Systems and methods for a cloud-based server system configured for on-demand autonomous (ODA) services are disclosed. The cloud-based server communicates with a first vehicle and a second vehicle to receive a trip request for the ODA service from the first vehicle and to identify one second vehicle by broadcasting the trip request to the set of second vehicles, seeking an agreement to establish a virtual link with the first vehicle to the second vehicle; to identify a second vehicle from submitted responses to perform a matching operation between the first vehicle and the second vehicle based on an application using a modeled clone with a set of functions; and to coordinate responses to confirm acceptance of the agreement based on results of the matching operation; and to create a trip plan for a trip request for ODA services based on a set of preferences received from each vehicle.

Description

Technical Field

[0001] This disclosure generally relates to autonomous vehicles, and more specifically to systems and methods for on-demand autonomous (ODA) services, and even more specifically to systems and methods for server architectures for adaptively scheduling information among multiple leader vehicles (Lv) and follower vehicles (Fv) by an ODA cloud server to meet various ODA service requests. Background Technology

[0002] Autonomous vehicles are vehicles capable of sensing and navigating their environment with little or no user input. Autonomous vehicles use sensing devices such as radio radar, lidar, and image sensors to perceive their environment. Autonomous vehicle systems also use information from positioning systems to navigate the vehicle, including Global Positioning System (GPS) technology, navigation systems, vehicle-to-vehicle communication, vehicle-to-infrastructure technology, and / or drive-by-wire systems.

[0003] Vehicle automation has been categorized into numerical levels ranging from zero (corresponding to no automation with complete human control) to five (corresponding to complete automation without human control). Various automated driver assistance systems (such as cruise control, adaptive cruise control, and parking assistance systems) correspond to lower levels of automation, while truly “driverless” vehicles correspond to higher levels of automation. On-demand services provide on-demand mobility to users by delivering transportation via fleets of autonomous vehicles. Therefore, it is desirable to provide systems and methods for on-demand autonomous (ODA) services, implemented using a cloud-based server architecture configured with multiple control systems and software that receive service requests from follower vehicles, evaluate the validity of the service requests, and seek agreements from potential stakeholders (i.e., the lead vehicle (Lv) and follower vehicles (Fv)) to determine whether to fulfill or terminate the ODA service request.

[0004] Furthermore, other desirable features and characteristics of the invention will become apparent from the following detailed description and appended claims, taken in conjunction with the accompanying drawings and the background art of the invention. Summary of the Invention

[0005] A system for on-demand (ODA) self-service is disclosed.

[0006] In one implementation, a cloud-based server system configured for On-Demand Autonomy (ODA) services is provided. The system includes a cloud-based server communicating with a first vehicle and at least one second vehicle. The cloud-based server includes a scheduler configured to receive a trip request for the ODA service from the first vehicle and seek a protocol to establish a virtual link between the first vehicle and the at least one second vehicle by identifying the at least one second vehicle from a group of second vehicles. The scheduler is configured to: broadcast the trip request to the group of second vehicles; receive a set of responses to the broadcast trip request submitted by at least one of the second vehicles; identify the at least one second vehicle from the submitted responses based on an application using a modeling clone with a set of functions, to perform a matching operation between the first vehicle and the at least one second vehicle from the group of second vehicles; and coordinate one or more responses between the first vehicle and the second vehicles based on the result of the matching operation to confirm acceptance of the protocol; and in response to the confirmation of acceptance of the protocol, the cloud-based server is configured to create a trip plan based on a set of trip requests received from each vehicle that are preferred for the ODA service.

[0007] In at least one embodiment, the first vehicle is a follower vehicle (Fv), and at least one second vehicle is a leader vehicle (Lv).

[0008] In at least one embodiment, the system includes a scheduler configured to: assess the minimum operational feasibility of at least one second vehicle performing a trip request based on a set of vehicle health parameters before performing a matching operation between the first vehicle and at least one second vehicle from the group of second vehicles.

[0009] In at least one embodiment, the system includes a scheduler configured to perform continuous monitoring of the set of health parameters associated with each vehicle based on data transmitted back and forth between each vehicle and a cloud-based server during the process from the start of the ODA service to the completion of the ODA service and the progress to the completion of the trip request.

[0010] In at least one embodiment, the system includes a scheduler configured to determine trip interruption events in the progress toward completion of a trip request based on continuous monitoring of the set of health parameters associated with each vehicle, and to modify the trip schedule in response to the trip interruption events to enable the completion of the ODA service.

[0011] In at least one implementation, the system includes, in response to determination of a trip interruption event, a cloud-based server configured with a set of options to make a trip modification request to at least a first vehicle.

[0012] In at least one implementation, a set of options for modifying the trip request for each vehicle includes at least modifying or terminating the trip plan, changing at least one second vehicle, downgrading the ODA service, and confirming acceptance of the modified or terminated trip plan.

[0013] In at least one embodiment, the scheduler is configured to present a heartbeat display to each vehicle, which dynamically presents real-time motion corresponding to continuously monitored data transmitted back and forth between each vehicle, the continuously monitored data continuously monitoring the set of health parameters associated with each vehicle.

[0014] In another embodiment, a method for On-Demand Autonomous (ODA) services is provided. The method includes: receiving a trip request for the ODA service from a first vehicle, the scheduler being hosted by a cloud-based server communicating with the first vehicle and at least one second vehicle; the scheduler seeking a protocol to establish a virtual link with the first vehicle to the at least one second vehicle by identifying the at least one second vehicle from a set of second vehicles; the scheduler broadcasting the trip request to the set of second vehicles to receive a set of responses to the broadcast trip request submitted by one or more of the second vehicles; identifying the at least one second vehicle from the submitted responses using an application with a set of functionalities; performing a matching operation between the first vehicle and the at least one second vehicle from the set of second vehicles; and coordinating one or more responses between the first vehicle and the second vehicles based on the result of the matching operation to confirm acceptance of the protocol; and in response to the confirmation of acceptance of the protocol, the scheduler creating a trip plan for the trip request for the ODA service based on a set of preferences received from each vehicle.

[0015] In at least one embodiment, the first vehicle is a follower vehicle (Fv), and at least one second vehicle is a leader vehicle (Lv).

[0016] In at least one implementation, the method includes, prior to performing a matching operation between a first vehicle and at least one second vehicle from a second vehicle group, a scheduler assesses the minimum operational feasibility of at least one second vehicle performing a trip request based on a set of vehicle health parameters.

[0017] In at least one implementation, the method includes the scheduler performing continuous monitoring of the set of health parameters associated with each vehicle based on data transmitted back and forth between each vehicle and a cloud-based server from the start of the ODA service to the completion of the ODA service and progress to the completion of the trip request.

[0018] In at least one implementation, the method includes a scheduler determining a trip interruption event in the progress toward completion of a trip request based on continuous monitoring of the set of health parameters associated with each vehicle, and modifying the trip plan in response to the trip interruption event to enable the completion of the ODA service.

[0019] In at least one implementation, the method includes, in response to determination of a trip interruption event, a scheduler presenting a set of options for modifying the trip request to at least a first vehicle.

[0020] In at least one implementation, the method includes a set of options for modifying the trip request to each vehicle, the set of options including at least modifying or terminating the trip plan, changing at least one second vehicle, downgrading the ODA service, and confirming acceptance of the modified or terminated trip plan.

[0021] In at least one embodiment, the method includes a heartbeat display presented by a scheduler to each vehicle, the heartbeat display dynamically presenting real-time motion corresponding to monitoring data transmitted back and forth between each vehicle, the monitoring data continuously monitoring the set of health parameters associated with each vehicle.

[0022] In yet another exemplary embodiment, an On-Demand Autonomy (ODA) server is provided. The ODA server includes a processor disposed within an ODA server communicating with a first vehicle and at least one second vehicle. The processor is configured to schedule a set of actions to receive a trip request for the ODA service from the first vehicle and to seek a protocol based on the set of actions to establish a virtual link with the first vehicle to the at least one second vehicle to identify the at least one second vehicle from a set of second vehicles. The processor performing the set of actions is configured to: receive a set of responses to a broadcast trip request submitted by one or more of the second vehicles; identify the at least one second vehicle from the responses submitted by the set of second vehicles based on an application using a modeling clone with a set of functions; perform a matching operation between the first vehicle and the at least one second vehicle from the set of second vehicles; coordinate one or more responses between the first vehicle and the second vehicle based on the result of the matching operation to confirm acceptance of the protocol; and, in response to confirming acceptance of the protocol, create a trip plan based on a set of preferences received from each vehicle for the trip request for the ODA service.

[0023] In at least one embodiment, the first vehicle is a follower vehicle (Fv), and at least one second vehicle is a leader vehicle (Lv).

[0024] In at least one embodiment, the ODA server includes a processor configured to: assess the minimum operational feasibility of one or more second vehicles performing a trip request based on a set of vehicle health parameters before performing a matching operation between a first vehicle and one or more second vehicles from a group of second vehicles.

[0025] In at least one embodiment, the ODA server includes a processor configured to: continuously monitor the set of health parameters associated with each vehicle based on data transmitted back and forth between each vehicle during the progress from the start of the ODA service to its completion and to the completion of the trip request; determine trip interruption events during the progress to the completion of the trip request based on the continuous monitoring of the set of health parameters associated with each vehicle; modify the trip plan in response to the trip interruption events to enable the completion of the ODA service; and present a heartbeat display to each vehicle, the heartbeat display dynamically presenting real-time motion corresponding to the continuously monitored data transmitted back and forth between each vehicle, the data continuously monitoring the set of health parameters associated with each vehicle. Attached Figure Description

[0026] Exemplary embodiments will be described below in conjunction with the accompanying drawings, wherein the same reference numerals denote the same elements, and wherein:

[0027] Figure 1 This is a functional block diagram illustrating an exemplary autonomous vehicle of either the leader vehicle (Lv) or follower vehicle (Fv) type, connected to a cloud server for use with the On-Demand Autonomy (ODA) service, according to various implementations.

[0028] Figure 2 This illustrates various embodiments of having a connection to Figure 1 A functional block diagram of the on-demand autonomy (ODA) service of one or more autonomous vehicles' ODA servers;

[0029] Figure 3 This is a data flow diagram illustrating an autonomous driving system according to various embodiments, the autonomous driving system including an on-demand autonomy (ODA) system of vehicle type Fv or Lv of an autonomous vehicle configured to connect to an ODA server.

[0030] Figure 4 It is a diagram of the modules and other entities of the ODA system of an autonomous vehicle according to various implementations, and the data flow between them.

[0031] Figure 5 It is a sequence diagram of requests between modules and other entities of an autonomous vehicle's ODA system according to various implementations, which represents the data flow between them;

[0032] Figure 6 It is a diagram of the modules and other entities of the ODA system of an autonomous vehicle according to various implementations, and the data flow between them.

[0033] Figure 7A , 7B 7C and 7C are flowcharts illustrating control methods for controlling autonomous vehicles based on ODA systems according to various embodiments; and

[0034] Figure 8 It is a diagram showing the monitoring status of modules and other entities according to various implementation methods, as well as the data flow between the autonomous vehicle's ODA system. Detailed Implementation

[0035] The following detailed description is exemplary in nature only and is not intended to limit application and use. Furthermore, it is not intended to be bound by any express or implied theory presented in the foregoing technical fields, background art, summary of the invention, or the following detailed description. As used herein, the term "module" refers individually or in any combination of any hardware, software, firmware, electronic control components, processing logic, and / or processor devices, including but not limited to: application-specific integrated circuits (ASICs), electronic circuits, processors (shared, dedicated, or grouped) and memories executing one or more software or firmware programs, combinational logic circuits, and / or other suitable components that provide the described functionality.

[0036] This document describes embodiments of the present disclosure in terms of functional and / or logical block components and various processing steps. It should be understood that such block components can be implemented by any number of hardware, software, and / or firmware components configured to perform specified functions. For example, embodiments of the present disclosure can employ various integrated circuit components, such as memory elements, digital signal processing elements, logic elements, lookup tables, etc., which can perform various functions under the control of one or more microprocessors or other control devices. Furthermore, those skilled in the art will understand that embodiments of the present disclosure can be practiced in conjunction with any number of systems, and the systems described herein are merely exemplary embodiments of the present disclosure.

[0037] For the sake of brevity, this document may not describe in detail conventional techniques related to signal processing, data transmission, signaling, control, and other functional aspects of the system (and its various operating components). Furthermore, the connecting lines shown in the various figures included herein are intended to illustrate exemplary functional relationships and / or physical connections between various elements. It should be noted that many alternative or additional functional relationships or physical connections may exist in embodiments of this disclosure.

[0038] In various exemplary embodiments, this disclosure provides systems and methods for On-Demand Autonomy (ODA) services that extend platoons and implement multiple control systems configured with software for one or more leader vehicles (Lvs) coordinated to form virtual links with at least one subordinate or follower vehicle (Fv) using a distributed protocol to guide traffic from one location to another in an ODA pricing model for ODA services. Most or all of the Lvs and / or Fvs are configured with the minimum feasible capability to request and acknowledge ODA services in response to communication broadcasts and requests from a cloud-based ODA server.

[0039] In various exemplary embodiments, this disclosure describes a set of features for a vehicle requesting ODA services, the minimum feasible capabilities of which are used to transmit basic and optional parameters required for the ODA service request, to transmit vehicle health parameters and preferences (e.g., multi-stop-trip time / distance) to a central ODA server, and to process to receive commands and appropriately activate actuators and vehicle information of required sensors to send connectivity features for vehicle-to-vehicle (V2V) / vehicle-to-infrastructure (V2I) communication with other agents for communication with the lead vehicle and the On-Demand Autonomous Server (ODAS).

[0040] In various exemplary embodiments, this disclosure describes systems and methods for broadcasting valid trip requests to potential guides, receiving responses from potential guides, communicating with requesting followers and seeking agreements from requesting followers, and identifying rendezvous points for virtually connecting and disconnecting from one or more guide vehicles.

[0041] In various exemplary embodiments, this disclosure describes systems and methods for monitoring the state machine-based trip status via heartbeat messages and selecting appropriate responses, including control switching, adaptation (new route / guide identification), and termination.

[0042] In various exemplary embodiments, this disclosure describes systems and methods for modifying, reconfiguring, or adapting an ongoing ODA service between an Lv and an Fv based on requests from an Lv or an Fv or monitoring of ongoing activities occurring during the ODA service. For example, after a virtual link, the health of an Lv may need to be changed or the route changed when performing a virtual traction of an Fv in a vehicle platoon during the execution of an ODA service and a virtual traction of an Fv in a vehicle platoon, due to the monitored health parameters of the Lv or Fv. In this case, this disclosure describes systems and methods that enable reconfiguration of routes and adaptation of the ODA service to changes detected after the start of the ODA service, thereby providing a basis or need for modifications from the original service request.

[0043] In various embodiments, this disclosure describes systems and methods for implementing server-based architectures for on-demand autonomy (ODA) services, which extend fleets and implement multiple software-configured control systems to provide on-demand autonomy to vehicles not built for full autonomy, as well as a feature set of minimum feasible capabilities for vehicle requests and implementation of ODA services.

[0044] refer to Figure 1 , Figure 1 An exemplary diagram of vehicle 10 is depicted. In one embodiment, vehicle 10 is configured as a follower vehicle (Fv) with Level 2+ autonomy, or in another embodiment as a leader vehicle (Lv) with Level 3, 4, or 5 autonomy. According to the various embodiments, both configurations of vehicle 10 have a minimum level of communication capability for communication requests with an On-Demand Autonomy (ODA) system, typically shown as 100 and associated with vehicle 10. Typically, the On-Demand Autonomy (ODA) system 100 is implemented in an On-Demand Autonomy (ODA) service with programming modules and communication systems that enable one or more vehicles of any type, either follower vehicles (Fv) or leader vehicles (Lv), to receive / respond to requests and independently calculate, based on a price metric provided by the ODA server or in response to a utility function, to confirm acceptance of a request and to create virtual links between any vehicle types of Fv and Lv to build a vehicle pool in which control of vehicle operation is transferred from Fv to Lv via a communication link by a control system implemented by an exemplary embodiment of vehicle 10.

[0045] In an exemplary embodiment, the ODA system 100 includes an ODA server (e.g., an ODA cloud server) configured with a scheduler 7 for adaptive scheduling to coordinate multiple Levels of Vehicles (Lv) and Front-of-Vehicles (Fv) to fulfill ODA trip requests. In this embodiment, the scheduler 7 may include an adaptive scheduling process that performs functions such as: receiving trip requests from one or more Levels requesting ODA services; broadcasting a set of requests to the Levels using various broadcast protocols to identify one or more leader vehicles on possible routes to fulfill Fv requests; selecting one or more Levels based on availability; optimizing the trip plan based on Fv and Levels preferences; identifying safe rendezvous points for seamless connection switching in multi-leader scenarios; monitoring trip status via heartbeat messages initiated for both Levels and Fv; and adapting / optimizing the trip plan based on monitored status updates received from any of the vehicles.

[0046] In an exemplary implementation, the ODA service includes a vehicle equipped with an ADS (i.e., vehicle 10), which can extend its autonomous driving capabilities to other vehicles upon request. In one implementation, vehicle 10 is configured to guide a non-AV vehicle from point A to point B, where the latter's driver pays little attention. In another implementation, vehicle 10 is configured to follow an AV vehicle and hand over driving control to the AV vehicle for the journey as instructed by the ODA service.

[0047] In an exemplary implementation, the follower vehicle (Fv) may be configured with a private space for occupants, allowing them to relax or participate in work. The leader vehicle (Lv) is capable of safely picking up and dropping off the follower vehicles at selected locations. The Fv continuously communicates with the ODA server throughout the journey, including the initial allocation phase and the final drop-off phase. The Lv may pick up one or more vehicles to follow the drop-off. Both the Lv and Fv are configured with V2V and V2I communication capabilities.

[0048] like Figure 1 As shown, vehicle 10 is used to communicate with ODA server 7 and another vehicle type, and typically includes chassis 12, body 14, front wheels 16, and rear wheels 18. Body 14 is mounted on chassis 12 and substantially surrounds the components of vehicle 10. Body 14 and chassis 12 may together form a frame. Wheels 16-18 are rotatably connected to chassis 12 near corresponding corners of body 14.

[0049] In various embodiments, vehicle 10 is autonomous, and vehicle ODA system 82 is integrated into autonomous vehicle 10 (hereinafter referred to as autonomous vehicle 10), and if it is an Fv or Lv, vehicle ODA system 82 is configured with different groups of modules with different programming. For example, autonomous vehicle 10 is a vehicle that is automatically controlled to transport passengers from one location to another, or a vehicle 10 that performs a virtual towing operation of another vehicle to a location while assuming all control of the other vehicle to that location. Vehicle 10 is depicted as a passenger car in the illustrated embodiments, but it should be understood that any other vehicle may be used, including motorcycles, trucks, SUVs, recreational vehicles (RVs), boats, aircraft, etc.

[0050] In an exemplary embodiment, the autonomous vehicle 10 is a so-called Level 2, Level 2+, Level 3, Level 4, or Level 5 automation system. A Level 2 or Level 2+ system refers to a system for vehicle 10 (i.e., Fv) that has the ability to create and confirm virtual links and enable another type of vehicle Lv to control Fv to a requested location, where Fv has already relinquished control of vehicle operation to Lv during the planned journey. That is, for Fv, ODA system 82 will perform a higher level of autonomous driving with a less advanced programming operation, but still maintains a minimum capability to communicate with ODA server 5 (via ODA system 82), relinquish control of the other vehicle, complete the virtual link with the other vehicle, and respond to requests from the other vehicle and ODA server 5. Level 2 or Level 2+ vehicles (Fv vehicles) do not have the control systems and other hardware required to achieve higher levels of automation, such as the control systems and other hardware found in Level 4 or Level 5 systems.

[0051] Level 4 system signifies "high automation," referring to the autonomous driving system's driving mode-specific performance across all aspects of dynamic driving tasks, even if the human driver does not appropriately respond to intervention requests. Level 5 system signifies "full automation," referring to the autonomous driving system's full-time execution of all aspects of dynamic driving tasks under all road and environmental conditions that can be managed by a human driver. Vehicle 10 will be equipped with either Level 4 or Level 5 capability (Lv) and will also have the aforementioned minimum communication capability (via ODA system 82) for Fv to communicate with ODA server 5 to form a virtual link with another vehicle in response to requests from ODA server 5.

[0052] As shown in the figure, an autonomous vehicle 10 typically includes a propulsion system 20, a transmission system 22, a steering system 24, a braking system 26, a sensor system 28, an actuator system 30, at least one data storage device 32, at least one controller 34, and a communication system 36. In various embodiments, the propulsion system 20 may include an internal combustion engine, an electric motor such as a traction motor, and / or a fuel cell propulsion system. The transmission system 22 is configured to transmit power from the propulsion system 20 to the wheels 16-18 according to a selectable speed ratio. According to various embodiments, the transmission system 22 may include a step-ratio automatic transmission, a continuously variable transmission (CVT), or other suitable transmission. The braking system 26 is configured to provide braking torque to the wheels 16-18. In various embodiments, the braking system 26 may include friction brakes, line brakes, regenerative braking systems such as electric motors, and / or other suitable braking systems. The steering system 24 affects the position of the wheels 16-18. Although depicted as including a steering wheel for illustrative purposes, in some embodiments contemplated within the scope of this disclosure, the steering system 24 may not include a steering wheel.

[0053] Sensor system 28 includes one or more sensing devices 40a-40n that sense observable conditions of the external and / or internal environment of the autonomous vehicle 10. Sensing devices 40a-40n may include, but are not limited to, radio radar, lidar, GPS, optical cameras, thermal cameras, ultrasonic sensors, inertial measurement units, and / or other sensors. Actuator system 30 includes one or more actuator devices 42a-42n that control one or more vehicle features, such as, but not limited to, propulsion system 20, transmission system 22, steering system 24, and braking system 26. In various embodiments, vehicle features may also include internal and / or external vehicle features, such as, but not limited to, doors, trunk, and cabin features, such as air, music, lighting, etc. (not numbered).

[0054] Communication system 36 is configured to wirelessly transmit information to and from other entities 48, such as, but not limited to, other vehicles (“V2V” communication), infrastructure (“V2I” communication), remote systems and / or personal devices (regarding...). Figure 2 (Described in more detail). In an exemplary embodiment, communication system 36 is a wireless communication system configured to communicate via a wireless local area network (WLAN) using the IEEE 802.11 standard or by using cellular data communication. However, additional or alternative communication methods, such as Dedicated Short Range Communication (DSRC) channels, are also considered to be within the scope of this disclosure. DSRC channels refer to unidirectional or bidirectional short-to-medium range wireless communication channels specifically designed for automotive applications, along with a corresponding set of protocols and standards.

[0055] Data storage device 32 stores data used for automatically controlling the autonomous vehicle 10. In various embodiments, data storage device 32 stores a defined map of the navigable environment. In various embodiments, the defined map may be predefined by a remote system and obtained from a remote system (regarding...). Figure 2 (Further detailed description follows). For example, the defined map can be assembled by a remote system and transmitted to the autonomous vehicle 10 (wirelessly and / or via wire) and stored in data storage device 32. It is understood that data storage device 32 may be part of controller 34, separate from controller 34, or part of controller 34 and a separate system.

[0056] The controller 34 includes at least one processor 44 and a computer-readable storage device or medium 46. The processor 44 may be any custom or commercially available processor, central processing unit (CPU), graphics processing unit (GPU), auxiliary processor among several processors associated with the controller 34, semiconductor-based microprocessor (in the form of a microchip or chipset), macroprocessor, any combination thereof, or any means generally used for executing instructions. The computer-readable storage device or medium 46 may include volatile and non-volatile storage, such as read-only memory (ROM), random access memory (RAM), and keep-alive memory (KAM). KAM is persistent or non-volatile memory that can be used to store various operational variables when the processor 44 is powered off. The computer-readable storage device or medium 46 may be implemented using any of a variety of known storage devices, such as PROM (programmable read-only memory), EPROM (electrical PROM), EEPROM (electrically erasable PROM), flash memory, or any other electrical, magnetic, optical, or combined memory device capable of storing data, some of which represents executable instructions for controlling the autonomous vehicle 10 by the controller 34.

[0057] The instructions may include one or more separate programs, each including an ordered list of executable instructions for implementing logical functions. When executed by processor 44, the instructions receive and process signals from sensor system 28, execute logic, calculations, methods, and / or algorithms for automatically controlling components of autonomous vehicle 10, and generate control signals to actuator system 30 to automatically control components of autonomous vehicle 10 based on logic, calculations, methods, and / or algorithms. Although Figure 1 Only one controller 34 is shown, but embodiments of the autonomous vehicle 10 may include any number of controllers 34 that communicate via any suitable communication medium or combination of communication media and cooperate to process sensor signals, perform logic, calculations, methods and / or algorithms, and generate control signals to automatically control the features of the autonomous vehicle 10.

[0058] In various implementations, one or more instructions of controller 34 are embodied in ODA system 100 and, when executed by processor 44, implement the methods and systems described herein.

[0059] Now for reference Figure 2 In various implementation methods, regarding Figure 1 The described autonomous vehicle 10 can be used in the context of a taxi or shuttle system in a geographic area (e.g., a city, school or business campus, shopping mall, amusement park, event center, etc.), or it can simply be managed by a remote system. For example, the autonomous vehicle 10 can be associated with a remote transportation system based on autonomous vehicles.

[0060] Figure 2 An exemplary implementation of the operating environment, generally shown as 50, is illustrated, which includes, as per [reference]... Figure 1 The description describes one or more autonomous vehicles 10a-10n associated with an autonomous vehicle-based ODA server 5 (to perform ODA services). In various embodiments, the operating environment 50 also includes one or more user devices 54 communicating with the autonomous vehicle 10 and / or the ODA server 5 (i.e., cloud server) via a communication network 56.

[0061] Communication network 56 supports communication between devices (i.e., Lv, Fv, and ODA server 5), systems, and components supported by operating environment 50 (e.g., via physical and / or wireless communication links). For example, communication network 56 may include a wireless carrier system 60, such as a cellular telephone system, comprising multiple cell towers (not shown), one or more mobile switching centers (MSCs) (not shown), and any other networking components required to connect the wireless carrier system 60 to a terrestrial communication system. Each cell tower includes transmit and receive antennas and a base station, with base stations from different cell towers connected to the MSC directly or via an intermediate device such as a base station controller. Wireless carrier system 60 can implement any suitable communication technology, including, for example, digital technologies such as CDMA (e.g., CDMA2000), LTE (e.g., 4G LTE or 5G LTE), GSM / GPRS, or other current or emerging wireless technologies. Other cell tower / base station / MSC arrangements are possible and can be used in conjunction with wireless carrier system 60. For example, base stations and cell towers can coexist at the same site, or they can be far apart from each other. Each base station can serve a single cell tower, or a single base station can serve various cell towers, or various base stations can be connected to a single MSC, to name just a few possible arrangements.

[0062] In addition to the wireless carrier system 60, a second wireless carrier system in the form of a satellite communication system 64 may be included to provide one-way or two-way communication with the autonomous vehicles 10a-10n. This can be accomplished using one or more communication satellites (not shown) and an uplink transmitting station (not shown). One-way communication may include, for example, a satellite radio service, in which program content (news, music, etc.) is received by the transmitting station, packaged for uploading, and then sent to the satellite, which broadcasts the program to subscribers. Two-way communication may include, for example, a satellite telephone service that uses a satellite to relay telephone communication between the vehicle 10 and the station. Satellite telephones may be utilized in addition to or in place of the wireless carrier system 60.

[0063] It may also include a terrestrial communication system 62, which is a conventional terrestrial-based telecommunications network that connects to one or more landline telephones and to the wireless carrier system 60 that connects to the remote transportation system 52. For example, the terrestrial communication system 62 may include a Public Switched Telephone Network (PSTN), such as a PSTN used to provide hard-line telephone, packet-switched data communications, and Internet infrastructure. One or more portions of the terrestrial communication system 62 may be implemented using standard wired networks, fiber optic or other optical networks, cable networks, power lines, other wireless networks (such as wireless local area networks (WLANs) providing broadband wireless access (BWA) networks), or any combination thereof. Furthermore, the remote transportation system 52 does not need to be connected via the terrestrial communication system 62, but may include wireless telephone equipment that allows it to communicate directly with wireless networks (such as the wireless carrier system 60).

[0064] although Figure 2 Only one user device 54 is shown, but implementations of the operating environment 50 can support any number of user devices 54, including multiple user devices 54 owned, operated, or otherwise used by a single person. Each user device 54 supported by the operating environment 50 can be implemented using any suitable hardware platform. In this respect, the user device 54 can be implemented with any common form factor, including but not limited to: desktop computers; mobile computers (e.g., tablet computers, laptop computers, or netbook computers); smartphones; video game devices; digital media players; home entertainment devices; digital cameras or video cameras; wearable computing devices (e.g., smartwatches, smart glasses, smart clothing), or the like. Each user device 54 supported by the operating environment 50 is implemented as a computer-implemented or computer-based device having the hardware, software, firmware, and / or processing logic required to perform the various techniques and methods described herein. For example, the user device 54 includes a microprocessor in the form of a programmable device, which includes one or more instructions stored in an internal memory structure and applied to receive binary input to create binary output. In some implementations, the user device 54 includes a GPS module capable of receiving GPS satellite signals and generating GPS coordinates based on these signals. In other embodiments, user device 54 includes cellular communication capabilities, enabling the device to perform voice and / or data communications over communication network 56 using one or more cellular communication protocols, as discussed herein. In various embodiments, user device 54 includes a visual display, such as a touchscreen graphic display or other display.

[0065] The remote transportation system 52 includes one or more backend server systems, which may be cloud-based, web-based, or reside on a specific campus or geographic location served by the remote transportation system 52. The ODA server 5 may host applications for real-time advisory interaction with Fv and Lv, or automated advisory, or a combination of both. The ODA server 5 may communicate with user devices 54 and autonomous vehicles 10a-10n to schedule (via a dispatcher application) rides, dispatch autonomous vehicles 10a-10n, etc. In various embodiments, the ODA server 5 stores account information such as subscriber authentication information, vehicle identifiers, profile records, behavioral patterns, and other relevant subscriber information.

[0066] According to a typical use case workflow, a registered user of ODA server 5 can execute an application via the scheduler to create a ride request via user device 54. The ride request typically indicates the passenger's desired pick-up location (or current GPS location), desired destination location (which may identify predefined vehicle stops and / or user-specified passenger destinations), and pick-up time. ODA server 5 receives the ride request, processes it, and schedules one of the selected autonomous vehicles 10a-10n (when and if an autonomous vehicle is available) to pick up the passenger at the specified pick-up location and at the appropriate time. ODA server 5 can also generate and send an appropriately configured confirmation message or notification to user device 54 to inform the passenger that the vehicle is on its way.

[0067] As will be understood, the subject matter disclosed herein provides certain enhanced features and functionalities to objects that can be considered as standard or baseline autonomous vehicles 10 and / or autonomous vehicle-based ODA services. To this end, autonomous vehicles and autonomous vehicle-based long-distance transportation systems can be modified, enhanced, or otherwise supplemented to provide the additional features described in more detail below.

[0068] According to various implementation methods, the controller 34 achieves the following: Figure 3 The autonomous driving system (ADS) 70 shown. That is, suitable software and / or hardware components of the controller 34 (e.g., processor 44 and computer-readable storage device 46) are used to provide the autonomous driving system 70 for use in conjunction with the vehicle 10.

[0069] In various implementations, the instructions of the autonomous driving system 70 can be organized by function, module, or system. For example, Figure 3 As shown, the autonomous driving system 70 may include a computer vision system 74, a positioning system 76, a guidance system 78, and a vehicle control system 80. As will be understood, in various embodiments, instructions may be organized into any number of systems (e.g., combined, further divided, etc.), as this disclosure is not limited to the present example.

[0070] In various embodiments, the computer vision system 74 synthesizes and processes sensor data and predicts the presence, location, classification, and / or path of objects and features in the environment of the vehicle 10. In various embodiments, the computer vision system 74 may combine information from multiple sensors, including but not limited to cameras, lidar, radio radar, and / or any number of other types of sensors.

[0071] The positioning system 76 processes sensor data and other data to determine the position of vehicle 10 relative to its environment (e.g., local location relative to a map, precise location relative to a road lane, vehicle heading, speed, etc.). The guidance system 78 processes sensor data and other data to determine the path that vehicle 10 should follow, such as a path to a pick-up or drop-off location at an ODA service. The vehicle control system 80 generates control signals for controlling vehicle 10 based on the determined path.

[0072] In various implementations, the controller 34 implements machine learning techniques that assist the controller 34 in its functions, such as feature detection / classification, obstacle mitigation, route traversal, map creation, sensor integration, and ground condition determination.

[0073] As briefly mentioned above, Figure 1 The ODA system 100 is included within the ADS 70, for example, as an ODA system 82 that provides communication requests. For instance, in one embodiment of the main vehicle, the vehicle 10 is configured to receive request broadcasts from an on-demand autonomous server configured with an autonomous transportation system 52. Furthermore, in another embodiment of the robot taxi (guide vehicle Lv), the vehicle 10 is configured to receive broadcasts from an ODA server configured with an autonomous transportation system 52.

[0074] For example, such as regarding Figure 4 For more details, please refer to [link / reference]. Figure 3 The ODA system 82 includes functionality to respond to requests from the on-demand server to provide information about the current status of vehicle 10 and various parameters, such as current location, distance, time to a location, vehicle type, availability, ability to initiate virtual connections, etc., for the ODA service to make appropriate selections for the leader vehicle Lv and follower vehicle Fv.

[0075] In an implementation, the ODA system 82 includes a set of modules disposed in the follower vehicle (Fv) for ODA service activities: a user request module, a schedule selection module, a schedule execution module, and an instruction module. The user request module receives requests from the Fv to the ODA server to communicate with the ODA server and processes the request information, transmitting it to the schedule selection module. The schedule selection module coordinates arrival time information with the ODA server, picks up the Fv based on the request information, and transmits the arrival time information to the schedule execution module. The schedule execution module guides the Fv to pick up at a specific point based on the arrival time information and issues a warning via the instruction module, transmitting the pick-up point to the instruction module. The processor then warns nearby vehicles via the ODA service to pick up the Fv.

[0076] In one embodiment, the user status monitoring module includes a monitoring system based on an onboard finite state machine, which can detect and respond to intermittent fault conditions—switching to a fault protection mode. In another embodiment, the user status monitoring module may include a mechanism for generating new events based on observations, the mechanism being used to respond to standard safety guidance states in communication with the ODA server and the vehicle guide.

[0077] In one embodiment, the user status monitoring module includes communication parameters required for the ODA service, including transmitting minimum vehicle (Lv and Fv) health parameters (e.g., battery / oil life) and personal preferences, generating various safety events, or interrupting and transmitting them to the server and the guide (e.g., left rear door open).

[0078] In one implementation, the request initiation module can automatically initiate responses based on various offers, including offer sales, discounts, variable pricing, and flags Fv based on multiple different criteria. The request processing module can be configured with time constraints and other constraints to make the Fv offer attractive and to set time periods for request acceptance and confirmation.

[0079] In one embodiment, controller 34 is configured with an ODA system 82, which includes the ability to acknowledge the acceptance of requests from ODA server 5 (for ODA service 52) and to create virtual links between Lv and Fv. The ODA system may be configured with different software and functions for Lv and Fv to play different roles in accepting coordination requests sent by ODA server 5 for ODA service 52.

[0080] In one embodiment, the ODA system 82 includes processing capabilities to independently make decisions based on a price metric in a smart model and a set of weighting factors regarding whether to accept a request from an ODA server that has been broadcast to multiple Levels (Lv), wherein the ODA server coordinates the acceptance of multiple Levels and Levels (Fv) for the requested location assistance and control of the Fv. The ODA system 82 includes processing capabilities to weigh multiple factors and, in response to a request for route control and navigation assistance from an Fv, link and delink Levels in a multi-segmented route requested by the ODA server. The ODA system 82 has processing capabilities to participate in vehicle platooning configured in response to responses to requests from the ODA server, wherein Levels are changed once or multiple times on a multi-segmented route to a requested destination configured by the ODA server.

[0081] In one implementation, the ODA service 52 of the ODA server 5 can be comprised of software programmed to implement a process of branching between a set of physical and digital entities involved in Lv and Fv. For example, this process can be comprised of cloning Lv and Fv. As an example of the programming process, the L clone can be defined as a leader clone of a digital twin entity with integrated digital information. Next, the F1 clone can be read as a follower clone with merged information of digital twin followers and followers, where one or more followers N can be configured. The ODA server 5 only has digital information about the entities and the operating environment (i.e., the world), as well as information and status regarding each specific service. The ODA server 5 can recalculate optimized costs and, if necessary, reallocate Lv for ODA service 52 requests. In this case, the ODA server 5 matches Lv based solely on the operating environment and digital information, without knowing the associated Lv or Fv.

[0082] In one implementation, the ODA system 82 may include a neural network engine trained on objects of interest for the vehicle. In one implementation, the neural network engine includes training data, a trained process in the form of computer program instructions, and a processor for executing those instructions. Such objects of interest, forming part of the training of the neural network engine, include locations of interest, previous virtual connections of Fv and Lv, previous pick-ups, prior information about disembarkation locations already performed by the vehicle, and cost metrics and route pricing information, etc.

[0083] Figure 3An exemplary implementation of the ODA system 82 is included in an autonomous driving system 70. The autonomous driving system 70 is configured to perform steering and speed control maneuvers, as well as other possible autonomous driving possibilities, to avoid collisions and to move cooperatively with the tracked object, partly based on control commands. The autonomous driving system 70 operates known autonomous vehicle control computer instructions via a processor, partly based on control data.

[0084] Figure 4 A communication network for an on-demand service 400 between the individual facilitators and Fvs, according to an embodiment, is shown, which communicates with a cloud OAD server to configure virtual connections between the individual facilitator and follower vehicles.

[0085] In one implementation, the On-Demand Autonomy (ODA) service 400 can configure a formation to consist of an Level 1 (Lv), which is configured to guide one or more Lvs from one point to another within the ODA service.

[0086] In one implementation, the On-Demand Autonomy (ODA) service 400 implements one or more electronic control systems and software built on top of a platooning service that receives requests from other vehicles via an ODA server (ODAS), selects one or more Fvs, selects one or more Fvs at predetermined points, and commands the Fvs to follow one of the selected Lvs from a plurality of Lvs in the vehicle platoon for navigation, guidance, and instruction to drop one or more Fvs at various designated points.

[0087] In one implementation, the On-Demand Autonomous (ODA) service 400 provides or instructs one or more Levels of Service (Lv) for one or more Functional Levels (Fv), which are configured with enhanced overhead (such as increased time and resources), but are compensated based on a price metric generated by the ODA service using a cost-benefit (investment) model via a smart algorithm based on multiple weighting factors, including increased responsibility and equipment, to provide increased revenue to the selected Level.

[0088] In this implementation, the ODA service 400 enables one or more Levels (LVs) to receive requests and, in response to the requests and the information provided, to independently calculate or evaluate using a utility function or model to appropriately fulfill or satisfy the requests. The LVs can use intelligent models based on various parameters (e.g., requested route, weather, lighting, income, etc.) to determine whether to confirm acceptance of the request and to make choices that maximize the available parameters of the utility function when providing on-demand services.

[0089] In one implementation, the On-Demand Autonomy (ODA) service 400 implements one or more electronic control systems and software built on top of a platooning service that receives requests from other vehicles via an ODA server (ODAS), selects one or more Fvs, selects one or more Fvs to pick up at predetermined points, and commands the Fvs to follow a selected Lv from a plurality of Lvs in the platoon for navigation, guidance, and instruction to drop off one or more Fvs at various designated points.

[0090] In this implementation, the ODA service 400 can be modified after it has started, and the ODA server automatically detects events or parameter changes corresponding to the health of Lv or Fv, which require appropriate scheduling changes or modifications to the original request or the ongoing ODA service.

[0091] In one implementation, the ODA service 400 provides services or indicates one or more Levels of Service (Lv) for one or more Functions (Fv), which are configured with enhanced overhead (such as increased time and resources), but are compensated for by a price metric generated by the ODA service using a cost-benefit (investment) model via a smart algorithm based on multiple weighting factors, including increased liability and equipment, to provide increased revenue to the selected Level.

[0092] In this implementation, the ODA service 400 enables one or more Levels (LVs) to receive requests and, in response to the requests and the information provided, to independently calculate or evaluate using a utility function or model to appropriately fulfill or satisfy the requests. The LVs can use intelligent models based on various parameters (e.g., requested route, weather, lighting, income, etc.) to determine whether to confirm acceptance of the request and to make choices that maximize the available parameters of the utility function when providing on-demand services.

[0093] In an implementation, ODA service 400 configures the formation to include multiple Lv configurations between multiple segments of a route, wherein there are one or more Fv for each route segment that makes up a route from one point to another in the on-demand service.

[0094] In various implementations, the On-Demand Autonomy (ODA) service 400 can propose a pricing model for a configured vehicle formation consisting of multiple route segments, where each route segment may include different created virtual links between different Lv and Fv.

[0095] In an implementation, the ODA server (ODAS) 425 can be configured to enable multiple Levels (Lv) to accept requests coordinated by the ODA server and the Fv to create multiple virtual links between multiple groups of Levels and Fv to form routes from one point to another in an on-demand service.

[0096] exist Figure 4 In this system, ODA system 100 includes the ability to communicate between a host (e.g., a service requester or Fv) 405, an ODA server 425, and a smart taxi (e.g., a guide or Lv) 415 via an On-Demand Autonomy (ODA) service 400. ODA service 400 includes the ability to receive a request 410 transmitted between the ODA server 425 and the host 405, and an acceptance response 430 transmitted between the ODA server 425 and the smart taxi 415 to initiate a trip (or a virtual connection between Lv and Fv) 470.

[0097] In an exemplary embodiment, the ODA server 425 is configured with a scheduler 427, which receives from the ODA server 425 a set of responses to broadcast trip requests submitted by a group of Level 1 (Lv) vehicles. The scheduler 427 identifies Levels (Lv) based on submitted responses from a group of Levels that have already sent responses, using a configured modeling clone of the Levels (in...). Figure 6 (As described in further detail below), the configured Lv has an environment (i.e., the world) suitable for the location of Fv and a set of functions for requesting and planning routes or trips for Fv.

[0098] The scheduler 427, in conjunction with the process of adapting the trip application 490, enables the modification of trip requests based on monitoring events, including trip interruptions and other events that cause changes to or unexpected termination of the ODA service.

[0099] In various implementations, the scheduler 427 includes intelligent algorithms to coordinate one or more responses between vehicles based on the results of a matching operation, confirming acceptance of the protocol between Fv and Lv. Prior to performing the Lv-Fv matching operation, a monitoring application 480 configured with an ODA server 425 (or integrated with the scheduler 427) evaluates Lv (and Fv) for the minimum operational feasibility of executing the requested trip and the planned trip route. The evaluation by the monitoring application 480 may be based on a set of vehicle health parameters.

[0100] The ODA server 425 is also configured with a monitoring application 480 to monitor trip progress and provide data to generate periodic heartbeat messages or heartbeat type displays corresponding to the health of the two vehicles based on a set of health parameters monitored during the ongoing trip in Fv and Lv.

[0101] In one implementation, the monitoring application 480 can be configured to present any vehicle with a set of options for modifying a trip request or planned trip. For example, options may include modifying or terminating the trip plan, changing the Level and meeting location and making changes, downgrading the ODA service, and confirming acceptance of the modified or changed terms of the agreement. For example, changes to the terms of the agreement may include early termination of the trip and early termination of any charges.

[0102] In one implementation, the ODA server 425 is configured with an application that enables the creation of a trip plan for a trip request based on a set of preferences transmitted by either or both of Fv and Lv.

[0103] In one implementation, the ODA server 425 performs the ODA service 400 function to initiate a trip 470 and establishes a virtual connection between Lv and Fv by initially broadcasting a request 420 for acceptance by the smart taxi 415, and subsequently broadcasting the request 420 for acceptance by the smart taxi 415 or by multiple smart taxis (not shown) in an exemplary embodiment through an affirmative or accept response 430.

[0104] In an exemplary embodiment, ODAS 425 can automatically push notifications to the driver or Fv to initiate a request 420 for trip 470 based on input data from the Fv, including poor driving, difficult driving conditions based on weather reports, etc. In an exemplary embodiment, ODAS 425 can facilitate various pricing options for the Fv to initiate a request 420 to create a virtual link with the Lv.

[0105] The ODA server 425, using a decision intelligence algorithm, selects a guide 440 consisting of one or more smart taxis 415. In other words, based on multiple inputs including the vehicle's current status, route, weather, passenger preferences, follower pick-up / drop-off locations, and past history, it identifies and selects one or more guides 440. The ODA server 425 identifies the meeting point 450 and transmits the trip details 460 to the host and guide to execute on-demand actions.

[0106] In an exemplary implementation, the Fv can request location assistance without actually performing driver actions. For example, the Fv can be configured with Level 2+ capabilities, providing limited autonomous vehicle operation but with communication capabilities to make requests for on-demand services, enabling a virtual link with the Lv, where the Lv can be given sufficient operational control over the virtual link and virtually tow the Fv to the desired location, without the driver of the Fv actually needing to operate the Fv.

[0107] In an exemplary implementation, the ODA service 400 can transport the Fv in a platoon configuration with an Level (Lv) to enable an autonomous driving experience (i.e., Level 4 or Level 5 autonomous driving experience), even though the Fv is not actually configured or has Level 4 or Level 5 autonomous driving capabilities. That is, by creating a virtual link between the Level and the Fv, the Fv can operate in a semi-autonomous or near-autonomous manner by relying on control operations provided by the Level. In this implementation, by relying on the Level to control and navigate to a requested location, the Fv can simulate an autonomous driving experience without actually having the necessary software, hardware, and control systems configured for Level 4 or Level 5 autonomous driving capabilities.

[0108] In an exemplary implementation, the driver of the Fv may desire a more autonomous driving experience and be willing to relinquish control of the vehicle over a segment of the Lv's route or the entire route. In this case, the following vehicle (Fv) can send a request 420 to the ODAS 425, which will use a distributed protocol to coordinate the pricing and selection of the Lv, solicit requests from multiple Lvs, and enable a virtual link between the Fv and Lvs to perform a virtual traction operation to the desired location selected by the Fv.

[0109] In various implementations, multiple Levels (Lvs) can be coordinated by the ODAS 425 to assist an Fv, wherein the Fvs are linked via consecutive virtual links to multiple distinct Levels selected from a set of Levels identified by the ODAS 425 during the coordination process (i.e., a distributed protocol solicitation requested by the ODAS 425). The decision to accept the request is made independently based on a value score calculated independently by the ODAS 425 for each Level and Fv based on cost metric information provided by the ODAS 425 for the route or route segment, and virtual links with the Fvs in the vehicle platooning configuration placed by the ODAS 425 can be enabled.

[0110] In various exemplary embodiments, during a linking operation to create a virtual link with an Level (Lv), the Fv is given the option to accept a link request having a value score (or price metric) provided by one or more Levels. In this case, the ODAS 425 coordinates a set of responses from the Fv and one or more Levels to complete or confirm the request for the virtual link based on a suggested price (i.e., value score / cost metric) to bring the Fv under control at the requested location. The suggested price can be for the entire route or for a segment of the route for which the ODAS 425 coordinates the decision to complete or confirm the transaction (i.e., a handshake between the parties).

[0111] In an exemplary implementation, the cost metric or price charge of Lv can be calculated independently of Lv or by ODAS 425. As an example, the price charge can be determined using a weighted factor of parameters from a parameter set, based on empirical testing and the past history of Fv and Lv operations in the ODS service. The weighted factor can allow for more accurate value scoring and allows for adjustments to the value score to account for potential revenue reduction and ride diffraction if Fv chooses not to confirm acceptance of the request from ODAS 425.

[0112] In an exemplary implementation, ODAS 425 may impose constraints on the proposed price of the protocol to be provided by Lv, such as acceptance time, demand pricing to be accepted, or other real-time constraints, to enable timely completion of the request and the formation of a virtual link between Lv and Fv. In another implementation, Lv or a group of Lv may respond to a request broadcast by ODAS 425 (i.e., a broadcast of information) based on a value score calculated independently of the cost metric, which ODAS 425 calculates based on a set of weighting factors for routing and for assisting Fv in virtual traction operations to the requested destination.

[0113] In one implementation, ODAS 425, Fv, and Lv each make independent decisions using cost-benefit value scores directly associated with the operational factors of the requested Lv and Fv, and multiple weighting factors can be used to determine the cost of Lv from the perspective of Lv and Fv to perform navigation and control of Fv to the requested location. In one implementation, the utility function is specified and executed by ODA server 425, and cost values / metrics are sent to Lv and Fv for approval / rejection.

[0114] The cost metrics generated by ODAS 425 also allow ODAS 425 to assign independent initial value scores for each entity, Lv and Fv. Lv and Fv can then each assign their own value scores from the perspective of each entity, based on the cost metrics provided by ODAS 425.

[0115] Next, each entity, Lv, Fv, and ODA server 425 can make independent decisions. For example, using the value scores generated by ODAS 425 itself, ODAS 425 can coordinate and independently decide which Lv and Fv to coordinate the matching process for. In the final stage of the coordination process, a "meeting of the mind" is reached among all three entities or coordinated by ODA server 425. For example, the selection modules for Fv and Lv are configured with intelligent modules to independently calculate and determine whether to confirm the request's value score from the perspective of Fv and Lv. In other words, Lv, Fv, and ODA server are each configured to determine the individual value score that best suits each other, and the value scores may / may not be the same among all three entities, and negotiate the confirmation and approval of the ODA service request within a limited time. In this implementation, the Lv or Fv selection module determines a value score from the perspective of an individual or any entity (Lv or Fv) based on broadcast information received from the ODA server. This broadcast information includes a cost metric for the amount provided by the ODA service to the Lv to execute control of the Fv to the requested location, or for the Fv to request the ODA service from the Lv. The value score is calculated independently based on factors directly associated with the Lv or Fv operation requested by the ODA service from each entity's perspective. For example, these factors may include the current location of one or both entities, the time to travel to the pick-up location, the opportunity cost of waiting for another ODA request, etc.

[0116] In the implementation, Lv can be given a time window to respond to requests and reach an agreement (and can use its own value score to determine this). Lv and Fv can also propose different prices based on their values, and this information is provided to ODAS 425 for coordinated matching. ODAS 425 can also propose price metrics for iterative rounds based on new information received for Fv or Lv, and similarly, Fv will be given a similar type of time constraint to make a decision. Once the coordination process has completed a handshake or agreement via a distributed protocol implemented by the algorithm of ODAS 425, the queue is configured by the created virtual links to assist Fv in making route requests.

[0117] In various exemplary embodiments, Lv may have a set of preferences and a set of capabilities that can be provided to ODAS 425 to alter scores or make Lv a preferred choice for engaging with follower vehicle Fv for route assistance and to provide virtual traction operations via virtual links. In exemplary embodiments, Lv may be an advanced fully autonomous vehicle with Level 4 or Level 5 capabilities that can respond automatically to ODAS 425. For example, Lv may be a pre-designated fleet of smart taxis with pre-configured virtual linking capabilities with Fv to enable Fv to have semi-autonomous or communication capabilities solely for Lv's autonomous control, to traverse routes autonomously via configured vehicle platooning through ODAS 425.

[0118] Figure 5 This is an exemplary diagram showing the timing of interactions between an ODA server, a master vehicle (Fv), and a smart taxi (Lv) according to various implementations of an ODA service. Figure 5 In this implementation, at initial time 535 (time T1), Fv 510 requests to use the ODA service for a location, which is sent to ODA server 530. At time 540 (time T2), ODA server 530 coordinates response requests among a group of Lvs using a distributed protocol to respond to the received request and sends Lv information to Fv 510. In response, and upon confirmation of the facilitator selection information at time 550 (time T3), ODA server 530 then sends an acceptance confirmation to Fv 510 at time 555 (time T4) or almost simultaneously. Furthermore, at time 555, a platooning request is sent to Lv 520 via a virtual link to configure vehicle platooning. At time 555 (time T5), the platooning link is received by Lv 520, the ODA service is confirmed, and periodic updates are also sent. Finally, at time 565 (time T6), when Fv 510 reaches its destination, the virtual link between Lv 520 and Fv 510 is disconnected, and service completion information is sent to ODA server 530.

[0119] Figure 6A diagram illustrates a set of ODA (cloud) servers 605, a set of algorithms 610 stored in an accessible data repository, and a coordinated matching process that enables best-fit matching of Lv with digital information, where Lv is matched with a set of followers F1 to N with digital information. Specifically, ODA server 605 creates a set of cloned Lv (virtual Lv) 615, several sets of cloned followers 620, 630, and parameters associated with an environment 640 to achieve the coordinated matching process. From a combination of cloned Lv and multiple groups of different cloning capabilities configured with cloned Lv plus follower groups (F1 to Fn) 650, a leader vehicle Lv 680 compatible with the preferences of Lv and Fv is selected or identified. Next, several sets of cloned follower groups are combined with cloned Lv and environmental factors to form combination groups 660, 670 including cloned Lv, followers F1 to Fn, and environmental factors to identify a list of suitable followers with priority F1 685, where F1 685 is given the highest priority to Fn 690. Figure 6 The modeling, clone group creation, and matching processes can be implemented using computer program instructions stored on a computer-readable medium, which are provided by means of (…). Figure 1 At least one processor 44 of the processors can execute the ODA service. The ODA service can be performed by, for example... Figure 6 The modules and submodules described in the document are executed, and can also be used with respect to... Figure 3 Other aspects of the ODA system 82 and ODA server 5 described.

[0120] In an exemplary implementation, clone Lv 615 "L" is read at the facilitator clone, which has a digital twin of the facilitator clone and integrated information about the facilitator. Follower (Fv) clone F1 620 is read at the follower 1 clone and its digital twin, where the digital twin of follower 1 has relevant digital information about follower 1. One or more followers may exist, and the count is referred to as "N". In the example, the facilitator has complete information about itself and digital information about other entities received via a multimodal communication link (i.e., digital twins of followers 1 to N, and the environment (i.e., the world)). In the case of follower F1, follower F1 has complete information about itself and digital information about the entity (i.e., digital twins of the facilitator, other followers 2 to N, and the environment (i.e., the world)). The ODA server 605 only has the digital information about the entities and the environment (i.e., the world) and the status of all specific service requests. This allows the server 605 to use intelligent applications to recalculate costs and, if necessary, reassign or change the facilitator (Lv) for service requests.

[0121] Figure 7A , 7B7C is a centralized scheduler according to various implementations for trip requests with alternative flows due to trip interruption requests. Figure 4 The flowchart shows the scheduling actions of the scheduler (427). In one embodiment, the initial trip request R at step 710... o The process originates from the Fv and proceeds to the destination, then is sent to the ODA server. In step 710, the origin of the trip request is determined by the application on the ODA server. For example, the origin could be the Fv, or it could be a mobile device requesting a third-party Fv. In any case, once the origin is verified through the authentication process, the destination is also verified. Both the origin determination and destination verification steps ensure the detection of legitimate trip requests and filter out fraudulent requests (i.e., spam requests, junk mail requests, etc.), while still maintaining an open and accessible system for on-demand, self-reliant requests from Fv or other requesters who have not yet registered in the system or have been previously authenticated.

[0122] At step 720, a decision regarding the validity of the initial trip request (Ro) is made based at least on parameters of the source and destination requests. Other parameters may include route feasibility and availability of fulfilling the initial trip request (Ro). At step 725, the ODA server is configured to evaluate the Fv (Fear Value) and potential Fv (Fear Value) based on a set of vehicle health parameters transmitted from the vehicle to obtain the minimum operational feasibility for fulfilling the trip request (Ro). At step 730, the verification of health parameters is determined based on data received from the vehicle associated with the health parameter analysis. If the health parameters cannot be verified, or are not at the minimum level assessed for the trip request, or if any other tests (including source and destination checks) are deemed invalid in this regard, the process terminates at step 735 and the request for the initial trip request (Ro) is cancelled. Otherwise, if all tests are verified, including the checked health parameter levels, and the source and destination are verified, the initial trip (Ro) is fulfilled and the coordination process continues to identify and select the Lv (Level of Valuation) to complete the virtual link.

[0123] In an exemplary embodiment, Figure 7BIf a trip interruption request Ri exists at step 745, the processing flow differs because the initial step is eliminated, and the feasibility determination process at step 750 determines at step 755 whether the request to interrupt the ongoing or proceeding trip is feasible or appropriate. For example, if the route is nearly complete or the current route prevents the execution of the trip interruption request Ri due to road conditions, the trip interruption request Ri will be considered infeasible. In another example, at step 755, the monitoring application of the ODA server can determine whether the trip interruption request is approved based on the original trip interruption request Ri (based on data from monitoring health parameters indicating that one of the vehicles is not suitable to continue the trip or route). If the trip interruption request Ri is deemed feasible, at step 760, the scheduler or application of the ODA server executes a process to find another Lv or Fv if necessary to modify or revise various trip parameters, such as route, start, and end, and seeks confirmation and acceptance from each party (vehicles in the queue) of the proposed revisions and changes to the original agreement. In step 765, if the trip interruption request Ri is deemed infeasible, or no agreement is reached on the revision or alteration of the original protocol, the request to interrupt the trip (i.e., the trip interruption request Ri) is terminated. Optionally, if both parties (i.e., the Fv / Lv virtual link) agree to the alteration, the trip interruption request Ri is satisfied, and the original protocol is modified.

[0124] exist Figure 7C In the process, once any of the initial requests is deemed satisfied, the flow proceeds to step 780 to continue the initial process Ro request (instead of continuing the interruption request Ri), and the scheduler broadcasts the request to a set of Lvs to receive a set of responses from the set of potential Lvs at step 785. The scheduler then uses a modeling clone matching process (in...) Figure 6 (As described in the text), a matching operation is performed to find the best-fitting Level (Lv) and selects the Lv in part based on a set of preferences from the Functional Group (Fv) and determinations of routes and other requirements (i.e., availability, location, etc.). Next, in step 795, it is determined whether there is actually an available Lv that matches the clone and the desired functional group or is best suited for it. If no suitability or Lv is available, the request is terminated in step 815. Alternatively, if an Lv is identified and selected, the process proceeds to step 800 to agree on terms with the Fv based on the selected Lv, price, planned itinerary, pick-up location, etc. In step 805, the identity and rendezvous point are transmitted to the Fv and Lv determined by the application on the ODA server, and in step 810, a virtual link is created for the formation configuration of the Lv and Fv.

[0125] In another implementation, if the interruption request Ri is satisfied, the process continues to step 820 to adapt or modify the trip plan to accommodate the interruption request. For example, Lv can be changed, the route to the destination can be changed, and the location can be identified to switch between multiple route scenarios configured with Lv, etc. In step 835, a notification of inactivity interruption can be presented. In one implementation, if adaptation has been performed and a degradation decision has been made (in step 840), the ODA service can be downgraded, and control can be switched (in step 825) to Fv.

[0126] In this implementation, during Fv's route operations and platooning, the ODA server's monitoring application continuously monitors heartbeat-based message data sent from the vehicles and adjusts and optimizes the trip plan based on the monitored status (i.e., the vehicle's activity status 845). The monitor application can also present real-time heartbeat-type graphical display data of the vehicle status based on health and other monitored parameters, providing visual indications of the trip and vehicle health.

[0127] In the implementation, the adaptation operation at step 825 includes the following options: initiating a controlled release action on the master (Fv) vehicle, identifying a new Lv in a set of available Lvs and an associated rendezvious point P, or pulling it to a safe position or point in the event of actuation of the Fv or inactivity.

[0128] Figure 8 A diagram showing a monitor display illustrating the formation status of the ODA service, according to an embodiment, is illustrated. Figure 8 In this configuration, the formation status is displayed by a monitored communication link 850, which has a window indicating the range of vehicle statuses from inactive 855 to active 860 within the formation. The status changes when the monitored communication link fails or when the Fv (host) moves away from the vicinity of Lv due to interference from non-participating vehicles.

[0129] It should be understood that Figure 7A , Figure 7B and Figure 7C The process can include any number of additional or alternative tasks. Figure 7A , Figure 7B and Figure 7C The tasks shown do not need to be performed in the order shown, and Figure 7A , Figure 7B and Figure 7C The process can be incorporated into a more comprehensive process or process with additional functions not described in detail herein. Furthermore, as long as the intended overall functionality remains intact, it can be derived from… Figure 7A , 7B The implementation of the process shown in 7C is omitted. Figure 7A , 7BAnd one or more of the tasks shown in 7C.

[0130] The foregoing detailed description is merely illustrative in nature and is not intended to limit the implementation of the subject matter or the application and use of such implementations. As used herein, the word "exemplary" means "serving as an example, instance, or illustration." Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, it is not intended to be bound by any express or implied theory presented in the foregoing technical field, background art, or specific implementations.

[0131] Although at least one exemplary aspect has been described in the foregoing detailed description of the invention, it should be understood that numerous variations exist. It should also be understood that the one or more exemplary aspects are merely examples and are not intended to limit the scope, applicability, or configuration of the invention in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient roadmap for implementing the exemplary aspects of the invention. It should be understood that various changes can be made to the function and arrangement of the elements described in the exemplary aspects without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A cloud-based server system configured for On-Demand Autonomy (ODA) services, comprising: A cloud-based server, communicating with a first vehicle and at least one second vehicle, includes a scheduler configured to receive a trip request for an ODA service from the first vehicle via a processor, and to seek a protocol to establish a virtual link between the first vehicle and the at least one second vehicle by identifying the at least one second vehicle from a group of second vehicles, wherein the scheduler is further configured to: The trip request was broadcast to the group of second vehicles; Receive a set of responses to the broadcast trip request submitted by a subgroup of the second group of vehicles; Based on an application using a modeling clone with a set of functions, at least one second vehicle is identified from the responses submitted by the subgroup of the set of second vehicles to perform a matching operation between the first vehicle and the at least one second vehicle from the set of second vehicles; and Based on the result of the matching operation, coordinate one or more responses between the first vehicle and the at least one second vehicle to confirm acceptance of the protocol; In response to confirmation of acceptance of the protocol, the cloud-based server is configured to create a trip plan for the ODA service trip request based on a set of preferences received from the first vehicle and the at least one second vehicle; and A heartbeat display is presented for each vehicle, which dynamically presents real-time motion corresponding to continuously monitored data that is transmitted back and forth between each vehicle. Each vehicle continuously monitors a set of health parameters associated with it. The heartbeat display includes a window that indicates the range of vehicle states from inactive to active in the formation.

2. The system of claim 1, wherein the first vehicle is a follower vehicle (Fv) and wherein the at least one second vehicle is a leader vehicle (Lv).

3. The system according to claim 1, further comprising: The scheduler is configured as follows: Before performing the matching operation between the first vehicle and at least one second vehicle from the group of second vehicles, the minimum operational feasibility for the at least one second vehicle to perform the trip request is evaluated based on the set of health parameters.

4. The system according to claim 3, further comprising: The scheduler is configured as follows: Based on the data transmitted back and forth between each vehicle and the cloud-based server during the process from the start of the ODA service to its completion and based on the progress toward the completion of the trip request, continuous monitoring of the set of health parameters associated with each vehicle is performed.

5. The system according to claim 4, further comprising: The scheduler is configured as follows: Based on continuous monitoring of the set of health parameters associated with each vehicle, trip interruption events are determined in the progress toward completion of the trip request, and in response to the trip interruption event, the trip plan is modified to enable the completion of the ODA service.

6. The system according to claim 5, further comprising: In response to the determination of the trip interruption event, the cloud-based server is configured to provide a set of options for making a trip modification request to at least a first vehicle, wherein the set of options includes at least the modification or termination of the trip plan, the change of the at least one second vehicle, the degradation of the ODA service, and confirmation of acceptance of the modified or terminated trip plan.

7. A method for providing on-demand self-management (ODA) services, comprising: A scheduler, hosted on a cloud-based server and configured to communicate with a first vehicle and at least one second vehicle via a processor, receives trip requests from the first vehicle for the ODA service. The scheduler seeks a protocol to establish a virtual link from the first vehicle to the at least one second vehicle by identifying the first vehicle from a group of second vehicles; The scheduler broadcasts the trip request to the group of second vehicles to receive a set of responses to the trip request submitted by a subgroup of the group of second vehicles. Based on an application using a modeling clone with a set of functions, at least one second vehicle is identified from the responses submitted by the subgroup of the group of second vehicles. A matching operation is performed between the first vehicle and the at least one second vehicle from the group of second vehicles. Based on the result of the matching operation, one or more responses between the first vehicle and the at least one second vehicle are coordinated to confirm acceptance of the protocol. In response to confirmation of acceptance of the protocol, the scheduler creates a trip plan for the ODA service based on a set of preferences received from the first vehicle and the at least one second vehicle, wherein the first vehicle is a follower vehicle (Fv) and wherein the at least one second vehicle is a leader vehicle (Lv). as well as A heartbeat display is presented for each vehicle, which dynamically presents real-time motion corresponding to continuously monitored data that is transmitted back and forth between each vehicle. Each vehicle continuously monitors a set of health parameters associated with it. The heartbeat display includes a window that indicates the range of vehicle states from inactive to active in the formation.

8. The method according to claim 7, further comprising: Before performing the matching operation between the first vehicle and the at least one second vehicle, the scheduler evaluates the minimum operational feasibility of the at least one second vehicle to execute the trip request based on the set of health parameters.

9. The method according to claim 8, further comprising: The scheduler performs continuous monitoring of the set of health parameters associated with each vehicle based on data transmitted back and forth between each vehicle and the cloud-based server from the start of the ODA service to the completion of the ODA service and based on the progress to the completion of the trip request. The scheduler determines trip interruption events in the progress toward completion of the trip request based on continuous monitoring of the set of health parameters associated with each vehicle, and modifies the trip plan in response to the trip interruption events to enable the completion of the ODA service; as well as In response to the determination of the trip interruption event, the scheduler presents a set of options for modifying the trip request to at least the first vehicle, wherein the set of options for modifying the trip request to each vehicle includes at least the following: modification or termination of the trip plan, change of the at least one second vehicle, degradation of the ODA service, and confirmation of acceptance of the modified or terminated trip plan.

Images