JP2022535664A - Method and device for operation control, electronic device, computer readable storage medium, operation control system and computer program - Google Patents

Abstract

Embodiments of the present disclosure provide methods, devices, devices, media, and systems for operational control. The method for operational control includes providing, at the service node, access to the function node based on an access protocol supported by the function node, the function node communicating with an on-board unit OBU of the vehicle or relating to the vehicle. configured to provide computational functions of information; The method transmits configuration information for the function node to the function node based on the access, and controls message interaction with the function node based on the configuration information to control operation of the vehicle via the OBU. further comprising the step of: The driving control function of the vehicle is realized with the assistance of an external device, and effective safe automatic driving can be realized. This realizes smart control of the entire transportation system. [Selection drawing] Fig. 2

Description

TECHNICAL FIELD Embodiments of the present disclosure relate primarily to the field of operational control, and more particularly to methods, devices, equipment, computer-readable storage media, and operational control systems for operational control.

In recent years, Intelligent Transport System (ITS) is a completely new technology, adopting advanced science and technology, systematically and comprehensively considering related roads, traffic, people and environment, etc., to realize smart traffic management. and offer possibilities and hopes for solving road traffic problems. With the development of communication networks, especially with the deployment of the fifth generation (5G) communication network, ITS is expected to support "people-vehicle-road-cloud" coordinated communication and interaction, and different types of vehicles ( (including highly automated vehicles, connected cars with communication capabilities, and traditional public taxis) with different services. This will improve driving safety and traffic efficiency, and realize an intelligent transportation system. Currently, such solutions are lacking to normative collaborative interactions between vehicle-side, road-side and cloud-side.

Embodiments of the present disclosure provide a solution for operational control.

In a first aspect of the present disclosure, a method is provided for operational control. The method comprises the step of providing, in a service node, access to said functional node based on an access protocol supported by said functional node, said functional node communicating with an on-board unit OBU of a vehicle or associated with said vehicle. transmitting configuration information for said function node to said function node based on said access; and controlling operation of said vehicle via said OBU. controlling message interactions with said function node based on said configuration information to control.

In a second aspect of the disclosure, a method is provided for operational control. The method comprises the step of obtaining, in a function node, access to a service node based on an access protocol supported by said function node, said function node communicating with an on-board unit OBU of a vehicle or associated with said vehicle. receiving configuration information for said function node from said service node based on said access; and operating said vehicle via said OBU. performing message interactions with the service node based on the configuration information to control the .

In a third aspect of the present disclosure, an apparatus is provided for operational control. In a service node, an access module configured to provide access to said function node based on an access protocol supported by said function node, said function node having a communication function with an on-board unit OBU of a vehicle or to said vehicle. an access module configured to provide a computation function of related information; a configuration module configured to transmit configuration information for said function node to said function node based on said access; an interaction module configured to control message interactions with said function nodes based on said configuration information to control operation of said vehicle via an OBU.

In a fourth aspect of the present disclosure, an apparatus is provided for operational control. The apparatus is an access module configured in a function node to obtain access to a service node based on an access protocol supported by said function node, said function node communicating with an on-board unit OBU of a vehicle. an access module configured to provide computing functionality for information related to a function or said vehicle; and based on said access, configured to receive configuration information for said function node from said service node. a configuration module; and an interaction module configured to perform message interactions with the service node based on the configuration information to control operation of the vehicle via the OBU.

In a fifth aspect of the present disclosure, an electronic device comprising one or more processors and a storage device for storing one or more programs, wherein the one or more programs are stored in the one a storage device which, when executed by one or more processors, causes said one or more processors to implement the method according to the first aspect of the present disclosure.

In a sixth aspect of the disclosure, one or more processors;
A storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors receive the first program of the present disclosure. and a storage device that implements the method according to one aspect.

In a seventh aspect of the present disclosure, a computer readable storage medium storing a computer program, which, when executed by a processor, implements the method according to the first aspect of the present disclosure. Provide storage media.

In an eighth aspect of the present disclosure, a computer readable storage medium storing a computer program, which, when executed by a processor, implements the method of the second aspect of the present disclosure. Provide storage media.

In a ninth aspect of the present disclosure, an operational control system is provided. The system includes a central platform subsystem including an apparatus according to the first aspect. The system further includes at least one of a roadside subsystem and an edge computation subsystem including the apparatus of the second aspect.

The content described in the Summary of the Invention is not intended to limit key or key features of the embodiments of the disclosure, nor is it intended to limit the scope of the disclosure. Other features of the invention will be readily understood from the following description.

The above as well as other features, advantages and aspects of each embodiment of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the drawings. In the accompanying drawings, same or similar reference numbers represent the same or similar elements.
1 is a schematic diagram of an exemplary environment in which some embodiments of the disclosure may be implemented; FIG. 1 is a block diagram illustrating an operational control system according to some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating an example network architecture for roadside subsystems in accordance with some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating an example network architecture for roadside subsystems in accordance with some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating an example network architecture for roadside subsystems in accordance with some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating an example network architecture for roadside subsystems in accordance with some embodiments of the present disclosure; FIG. FIG. 2 is a block diagram illustrating an example network architecture for an edge computation subsystem according to some embodiments of the present disclosure; 3 is a block diagram illustrating an example configuration of an abstract service node according to some embodiments of the present disclosure; FIG. 4 is a signaling map between service nodes and function nodes according to some embodiments of the present disclosure; 4 is a signaling map between service nodes, function nodes and an on-board unit (OBU) according to some embodiments of the present disclosure; 4 is a signaling map between service nodes, function nodes and an on-board unit (OBU) according to some embodiments of the present disclosure; FIG. 4 is a block diagram illustrating a driving control system according to some other embodiments of the present disclosure; FIG. 4 is a signaling map between service nodes, function nodes, third party platforms and OBUs according to some embodiments of the present disclosure; 4 is a signaling map between service nodes, function nodes, third party platforms and OBUs according to some embodiments of the present disclosure; 4 is a signaling map between service nodes, function nodes, third party platforms and OBUs according to some embodiments of the present disclosure; 4 is a flowchart of a method for service node side operational control according to some embodiments of the present disclosure; 1 is a schematic block diagram of an apparatus for functional node side operational control according to some embodiments of the present disclosure; FIG. 1 is a schematic block diagram of an apparatus for service node side operational control according to some embodiments of the present disclosure; FIG. 1 is a schematic block diagram of an apparatus for functional node side operational control according to some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating a device in which embodiments of the present disclosure can be implemented; FIG.

Hereinafter, embodiments of the present disclosure will be described in more detail with reference to the accompanying drawings. Although several embodiments of the invention are illustrated in the drawings, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, it should be understood that these examples are provided for a clearer and more complete understanding of the invention. It should be noted that the drawings and embodiments of the present disclosure are merely exemplary and do not limit the protection scope of the present disclosure.

In describing embodiments of the present disclosure, the term "including" and like terms should be understood as a non-limiting expression, "including but not limited to." The term "based on" should be understood as "based at least in part on". The terms "one embodiment" or "the embodiment" should be understood as "at least one embodiment". It should be noted that the terms "first", "second", etc. can refer to different objects or the same object. Other explicit or implicit definitions may also be included below.

As described above, in an intelligent transportation system (ITS), driving control of a vehicle, such as a vehicle, is related to the environment sensing ability and communication ability of the vehicle itself. Vehicles are currently being made smarter and networked.

From the perspective of smartification, smartification of vehicles can be divided from assisted driving to fully automated driving. However, smart vehicles are classified according to the degree of smartness of the vehicles themselves, and the vehicles themselves do not necessarily have the ability to communicate with other devices, ie, smart vehicles are single-car smart vehicles. For example, L4/L5 self-driving vehicles require cameras, lidar, millimeter-wave radar and other devices to be installed in the vehicle to sense the surrounding environment and adjust the motion state of the unmanned vehicle in real time. . Due to the limited nature of motorcycles, even in the highest level of smart vehicles, motorcycle sensing still has problems such as shielding and limited sensing distance. It is necessary to improve the degree of smartness of low-smart vehicles by other methods.

From the point of view of networking, from the traditional networked auxiliary information interaction (such as obtaining navigation information) to networked cooperative decision and control (planned control for vehicles through vehicle-to-vehicle and road-to-vehicle cooperation) , the networking dimension of vehicles mainly focuses on the degree of communication between participants, such as vehicle-to-vehicle, road-to-vehicle, cloud-to-vehicle, and human-to-vehicle. The higher the networking level, the more complete the information that can be shared between vehicles. However, many of the vehicles (e.g. vehicles) currently on the market do not have networking or only have the earliest networking capabilities, so even low-level networking vehicles participate in high-level networking. It is necessary to realize smart control of the entire transportation system.

According to embodiments of the present disclosure, an improved driving control scheme is proposed. This scheme normalizes the interactions between service nodes and function nodes that provide communication or computational functions. A function node may be a computing function that communicates with the vehicle's on-board unit (OBU) or provides information related to the vehicle. Specifically, the service node provides access to the function node based on the access protocol, transmits configuration information for the function node to the function node based on the access, and sends messages to the function node based on the configuration information. Control interactions and facilitate driving control of the vehicle via the OBU. This realizes smart control of the entire transportation system.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

Environment example

FIG. 1 is a schematic diagram illustrating an example traffic environment 100 in which some embodiments of the disclosure may be implemented. This example environment 100 includes one or more vehicles 130-1, 130-2, . . . 130-N. . . 130-N may be collectively referred to as vehicle 130 or simply as vehicle 130 for convenience of explanation. Vehicle, as used herein, refers to any type of mobile vehicle capable of carrying people and/or goods. Vehicle 130 is illustrated as a vehicle in FIG. 1 and other drawings and descriptions herein. Vehicles may be motor vehicles or non-motor vehicles, including, but not limited to, automobiles, passenger cars, trucks, buses, electric vehicles, motorcycles, bicycles, and the like. However, it should be understood that a vehicle is only one example of a vehicle. Embodiments of the present disclosure are equally applicable to vehicles other than vehicles, such as ships, trains, and airplanes.

One or more vehicles 130 in environment 100 may be vehicles with some self-driving capabilities, also referred to as driverless vehicles. Of course, one or more of the other vehicles 130 in the environment 100 may be vehicles with no autonomous driving capabilities or vehicles with only driving assistance capabilities. Such vehicles can be controlled by a driver. Integrated or detachable devices within one or more vehicles 130 may be, for example, vehicle-to-vehicle (V2V) technologies, vehicle-to-roadside-infrastructure (V2I) technologies, vehicle-to-network (V2N) technologies, to-cellular-Network) technology, connectivity between a car and something (vehicles, pedestrians, infrastructure, networks, etc.) (V2X, Vehicle to X) technology, or any other communication technology, one or more communication technology to communicate with other devices.

Vehicle 130 may be fitted with positioning devices to determine its position, such as positioning technology based on laser point cloud data, global positioning system (GPS) technology, global navigation satellite system ( GLONASS) technology, Beidou Navigation System technology, Galileo positioning system (Galileo) technology, Quasi-Zenith Satellite System (QAZZ) technology, base station positioning technology, Wi-Fi positioning technology, etc. can.

In addition to vehicles 130, environment 100 may have other objects such as animals, plants 105-1, people 105-2, movable or non-movable objects such as transportation infrastructure. The traffic infrastructure includes objects for guiding traffic and indicating traffic rules, such as traffic lights 120, traffic signs (not shown), street lights, and the like. Objects outside the vehicle are collectively referred to as an object outside the vehicle 105 .

A driving control system 110 for a vehicle 130 is also located in environment 100 . Driving control system 110 is configured to control driving of vehicle 130 in at least environment 100 . Each vehicle 130-1, 130-2, . . . , 130-N may be provided with a corresponding OBU 132-1, 132-2, . OBUs 132-1, 132-2, . Operations control system 110 may be in signaling communication with OBU 132 . The OBU 132 can support communication with the driving control system 110 to obtain corresponding information and perform driving control of the vehicle 130 based on the obtained information. The OBU 132 also receives information from the vehicle 130 such as, for example, feedback information, sensory data collected by sensing devices (if present) on the vehicle 130, or results of processing into sensory data by computing units (if present) on the vehicle 130. can be transmitted to the operations control system 110 regarding the. According to embodiments of the present disclosure, the driving control system 110 and OBU 132 may support some or all of the driving controls for vehicles having various levels of smartening and networking.

Note that the facilities and objects shown in FIG. 1 are only examples. The type, quantity, relative placement, etc. of objects appearing in various environments may vary. The scope of the disclosure is not limited in this regard. For example, the environment 100 may have more roadside devices 110 and sensing devices 260 placed along the roadside to monitor additional geographic locations. Embodiments of the present disclosure may involve multiple distal devices or no distal devices.

Example of operation control system

FIG. 2 is a schematic block diagram illustrating the operational control system 110 of FIG. 1 according to some embodiments of the present disclosure. FIG. 2 also shows OBU 132 on vehicle 130 that interacts with driving control system 110 . Operational control system 110 includes a central platform subsystem 210 for centrally controlling and managing each subsystem within operational control system 110 . Central platform subsystem 210 may also be referred to as a center platform, central platform, centralized platform, or the like. The maneuver control system 110 may also include one or more roadside subsystems 220 and/or one or more edge computation subsystems 230, which provide sensing, configured to provide decision making and/or coordinated control.

The central platform subsystem 210 may include one or more of a roadside service node 212 , a roadside unit (RSU) service node 214 , and an edge compute service node 216 . The roadside service node 212 is configured to manage, control and message interact with edge computing devices within the maneuver control system 110, the RSU service node 214 manages and controls the RSU within the maneuver control system 110, Configured for data interaction. Edge computing service node 216 is configured to manage, control, and data interact with edge computing devices within operations control system 110 .

The roadside subsystem 220 is primarily located near the geographic area in which the vehicle 130 travels and/or parks, and may be, for example, spaced apart on both sides of a road or where the vehicle 130 is located. It may be arranged at a predetermined distance from the position to obtain. The roadside subsystem 220 may include a roadside computing module 240 , one or more RSUs 250 and one or more sensing devices 260 . The roadside computing module 240 may include a roadside computing unit 242 and an RSU service node 214 .

The RSU 250 is equipment having a communication function. RSU 250 may provide direct communication with OBU 132, which may be, for example, direct connection communication based on the Internet of Things (V2X) protocol. Alternatively or additionally, RSU 250 may also provide network communication, eg, communication over a cellular network, with RSU service nodes 214 within central platform subsystem 210 and/or roadside computing module 240 .

Sensing device 260 is configured to monitor environment 100 in which vehicle 130 is located. For example, the sensing device 260 may be configured to sense road traffic conditions, road natural conditions, weather conditions, etc. of the environment 100 within its sensing range and input the sensed data to the roadside computing module 240 . Sensing devices 260 may be located near areas in which vehicle 130 travels and/or parks. The sensing range of sensing device 260 is limited according to sensing capabilities. In some cases, the sensing ranges of multiple adjacently positioned sensing devices 260 may partially overlap. If desired, the sensing device 260 may be placed on the side of the road, on the road surface, or may be placed at a predetermined height, such as fixed at a predetermined height by a support rod. In some examples, in addition to fixing sensing device 260 at a particular location, moveable sensing device 260, such as a moveable sensing site, may also be provided.

Sensing device 260 may include one or more sensor units, which may be of the same type or different types and may be positioned at the same or different locations in sensing area 102 . Examples of sensor units in the sensing device 260 are image sensors (e.g. cameras), lidar, millimeter wave radar, infrared sensors, positioning sensors, light sensors, pressure sensors, temperature sensors, humidity sensors, wind speed sensors, wind direction sensors, air Including, but not limited to, mass sensors and the like. An image sensor can collect image information. Lidar and millimeter wave radars can collect laser point cloud data. Infrared sensors can use infrared rays to detect environmental conditions in the environment. A positioning sensor can collect position information of an object. A light sensor can collect an index value indicative of the intensity of light illumination in the environment. Pressure, temperature and humidity sensors can collect index values indicative of pressure, temperature and humidity respectively. Wind speed and wind direction sensors can collect index values indicating wind speed and wind direction, respectively. Air mass sensors can collect indicators related to air mass, such as, for example, oxygen concentration, carbon dioxide concentration, dust concentration, pollutant concentration in the air. As will be appreciated, the above listed only some examples of sensor units. Other types of sensors may exist according to actual needs.

The roadside computing unit 242 within the roadside computing module 240 is configured to provide computational functionality, particularly for information related to the vehicle 130 . The roadside computing unit 242 may be any device having computing capabilities such as one or more processors, processing devices, general purpose computers, and the like. The roadside computing unit 242 may be configured to obtain original sensing information from one or more sensing devices 260 . Data transmission between the roadside computing unit 242 and the sensing device 260 may be based on a wired line or wireless communication. Roadside computing unit 242 may further be configured to process sensing information from sensing devices 260 and generate driving-related messages for driving tools 130 based on the sensing information.

The driving-related message includes a sensing message indicating the result of sensing the environment around the vehicle 130, a decision plan message indicating a decision plan when driving the vehicle 130, and a control message indicating a specific driving operation when driving the vehicle 130. can include at least one of Viewed in turn, the information indicated by each of these three types of messages depends on the information contained in the previous type of message. For example, environmental sensing results are based on the sensing information of the sensing device 260, decision plans are based at least on the environmental sensing results, and control messages are typically created based on the decision plans or based on the environmental sensing results. Depending on the computing power and configuration of the roadside computing unit 242, the roadside computing unit 242 may generate sensing messages for the vehicle 130 by performing one or more levels of computation based on the sensing information of the sensing devices 260; Decision planning messages and/or control messages can be established. Driving-related messages determined by roadside computing unit 242 may be further processed by other computing devices or by OBUs as needed.

In some embodiments, the roadside computing unit 242 may determine environmental sensing results associated with the vehicle 130 through algorithms such as data fusion, obstacle sensing, etc., and generate sensing messages. For example, the roadside computing unit 242 may perform direct obstacle sensing processing and/or further semantic level sensing processing on the original sensing information. Obstacle sensing processing includes recognizing the size, shape, speed, etc. of obstacles on the road, and semantic level sensing processing judges vehicles abandoned on the road and special vehicles on the road based on the results of obstacle sensing. Including judging road conditions such as judging.

Depending on the source and specific content of the sensed information, the sensed message may include instructional information related to one or more other aspects of environment 100 and/or vehicle 130 within environment 100 . In some embodiments, the sensory message is for indicating at least one of: obstacle type, location information, velocity information, direction information, physical appearance description information, historical trajectory, and predicted trajectory. information about the physical conditions of the roads in the environment 100 to indicate at least one of the physical conditions of the road surfaces and the structural information of the roads; Information about traffic facilities within environment 100 to indicate conditions and/or traffic signs, and/or lane signs for roads and/or lanes within roads, traffic traffic, and/or traffic incidents. information about traffic conditions on roads within the environment 100 and information about weather conditions within the environment 100. In some embodiments, the sensed messages may also include aiding information regarding positioning of the vehicle 130, diagnostic information regarding malfunctions of the vehicle 130, information regarding software systems within the vehicle 130, and/or time information. Although some examples of content included in sense messages are listed above, it should be understood that sense messages may also include other content, including less or more content.

The decision plan message includes an indication of the road on which the decision is to be applied, start time information and/or end time information of the decision plan, start location information and/or end location information of the decision plan, identifier of the vehicle for which the decision plan is intended, Decision information on vehicle driving behavior, decision information on vehicle driving behavior, route plan trajectory point information, estimated time to reach route plan trajectory point, information on other vehicles related to the decision plan, map information and time information, etc. , may include information of one or more aspects. The map information can indicate, for example, at least one of a map identifier, a map update method, a map updated area, and location information. The map identifier may include, for example, the map version number, map update frequency, and the like. The map update strategy may indicate, for example, the map update source (from remote device 120 or other external source), update link, update time, and the like. Although some examples of content included in decision plan messages are listed above, it should be understood that decision plan messages may also include other content, including lesser or more content.

The control messages include kinematic control information related to motion of the vehicle, dynamic control information related to at least one of a power system, transmission system, braking system, and steering system of the vehicle; Information regarding one or more aspects of control information related to the boarding experience, control information related to the vehicle's traffic warning system, and time information may be included. Although some examples of content that control messages contain are listed above, it should be understood that control messages may also contain other content, including lesser or more content.

The roadside computing unit 242 may have communication with the roadside service node 212 . Communication between the roadside computing unit 242 and the roadside service node 212 may be via a wired or wireless network. The roadside computing unit 242 can transmit driving-related messages to the roadside service node 212 via communication with the roadside service node 212 . The roadside computing unit 242 may also receive control signaling, information, data, etc. from the roadside service node 212 . The roadside computing unit 242 may also forward corresponding information to the OBU 132 via the RSU 250 under the control of the roadside service node 212 . In addition to the roadside computing unit 242 , in some embodiments the roadside computing module 240 may include an RSU service node 214 for managing and controlling the RSUs 250 . RSU service node 214 may be configured to support message interaction with RSU 250 .

The edge computation subsystem 230 within the operations control system 110 may include an edge computation module 270 that includes an edge computation unit 272 and an RSU service node 214 . Edge computing device 230 may also include one or more RSUs 250 and one or more sensing devices 260 . In the Edge Computing Subsystem 230 , the functionality and arrangement of the RSU Service Nodes 214 , RSUs 250 and Sensing Units 260 are similar to those in the Roadside Subsystem 220 . Edge computation unit 272 is configured to provide computational functionality, particularly computation of information related to vehicle 130 . In some embodiments, edge computing device 272 processes sensory information from sensing device 260 and, based on the sensory information, provides operational tool 130 information, such as sensing messages, decision planning messages, and/or control messages. may be configured to generate driving-related messages for

The edge computing device 272 can also be referred to as an edge computing node, and is a network node such as a server, a large server, an edge server, etc., a cloud-end computing device such as a virtual machine (VM), etc., and any network node that provides computing functionality. other devices. In a cloud environment, remote devices are sometimes referred to as cloud devices. In some embodiments, the edge computing device 272 may provide more powerful computing power and/or a more convenient ability to access the core network compared to the roadside computing unit 242 . Accordingly, the edge computation unit 272 can support the fusion of sensory information for a wider geographic area. The edge calculator 272 may be arranged according to the level of the road segment, for example it may be arranged in the computer room of the edge of one road segment.

The roadside subsystem 220 and edge computation subsystem 230 interacting with the central platform subsystem 210 have been described above. Each of the roadside subsystem 220 and the edge computation subsystem 230 is a small local area network responsible for environmental sensing and computation based on sensing information for a specific geographical area of the environment 100 to implement localized driving control. can be viewed. Here, the RSU 250 that provides the communication function and the roadside computing unit 242 and the edge computing device 272 that provide the computing function are collectively referred to as "function nodes". Nodes that service these functional nodes, such as 216, are collectively referred to as "service nodes".

In the driving control system 110 there may be one or more roadside subsystems 220 and one or more edge computation subsystems 230 that interact with the central platform subsystem 210 . The central platform subsystem 210 can obtain multi-segment, multi-region, even city-wide or wider geographic area multi-dimensional information related to operational control of the vehicle 130, such as environmental sensing, incidents, etc. It can be thought of as providing cloud functionality. By knowing global network information, the central platform subsystem 210 can provide more ability to expand based on global information. These abilities are discussed below.

Network construction example

The maneuver control system 110 may include one or more roadside subsystems 220 and one or more edge computation subsystems 230, both of which interact with the central platform subsystem 210. can be done. The connections between these subsystems and the central platform subsystem, and the deployment scheme within each subsystem, can be changed as needed. An example of a network construction scheme for roadside subsystems and edge computation subsystems is described below.

3A-3D show an example of a network configuration associated with the roadside subsystem 220. FIG. In general, the networking scheme within the roadside subsystem 220 may depend on the computing power of the roadside computing unit 242, the communication range supported by the RSU 250, and/or the sensing range supported by the sensing device 260.

In the example network architecture 301 shown in FIG. 3A, a central platform subsystem 210 communicates with a plurality of roadside subsystems (denoted 220-1, . includes a roadside computation module 240 , a single sensing device 260 and a single RSU 250 . Here, K is an integer of 1 or more. For example, roadside subsystem 220-1 includes, in addition to roadside computing module 240-1, a single sensing device 260-1 and a single RSU 250-1, both in communication with roadside computing module 240-1. combined. Roadside subsystem 220-K includes, in addition to roadside computing module 240-K, a single sensing device 260-K and a single RSU 250-K, both communicatively coupled with roadside computing module 240-K. be. A feature of such a network construction method is that the roadside subsystem 220 is arranged with the sensing range of the sensing device 260 as a limit. For example, if the sensing range of the sensing device 260 is 150m, the roadside subsystem 220 is placed every 150m on the road on which the vehicle 130 travels. In this example, it is assumed that the communication range of RSU 250, particularly the direct connection communication range with OBU 132, is greater than the sensing range of sensing device 260, which is normally the case. If the communication range is less than the sensing range, the roadside subsystem 220 is placed with the communication range of the RSU 250 as the limit.

In the example network architecture 302 shown in FIG. 3B , compared to the example network architecture 301 , the roadside computing unit 242 in the roadside computing module 240 has stronger computing power and can process sensing information from multiple sensing devices 260 . Thus, in FIG. 3B, roadside computing module 240-1 is connected to multiple sensing devices 260-11, . can be connected. Here, M is an integer of 1 or more. A feature of the network construction scheme of FIG. 3B is that the communication capabilities of the RSU 250 and the computational resources of the roadside computing unit 242 can be fully utilized. Therefore, assuming that the communication range supported by the RSU 250 is 500m and the sensing range of the sensing device 260 is 150m, each roadside computing module 240 supports processing into sensing information of three consecutive sensing devices 260. A roadside subsystem 220 can be provided every 500m on the road on which the vehicle 130 travels. Note that the number of sensing devices to which each roadside computing module 240 is connected may differ.

In the network construction example 303 shown in FIG. 3B, sensing devices 260 and roadside computing modules 240 are placed at respective locations according to the sensing capabilities of the sensing devices 260, and multiple roadside computing modules 240 have one RSU. The placement of sensing device 260 and roadside computing module 240 is determined based on the sensing range of sensing device 260 , and the placement of overall roadside subsystem 220 is determined based on the communication range of RSU 250 . In other words, in such a network construction method, there is no 1:1 relationship between the RSU and the roadside calculation module 240 . Thereby, the communication capability of the RSU 250 can be utilized to the maximum. As shown in FIG. 3B, the roadside subsystem 220-1 includes a single RSU 250-1, a plurality of roadside computing modules 240-11, . 260-11, ..., 260-1M. Similarly, the roadside subsystem 220-K includes a single RSU 250-K, a plurality of roadside computing modules 240-K1, . . . , 240-KM and sensing devices 260-K1, . , 260-KM.

In each roadside subsystem 220, one roadside computation module 240 may be the master roadside computation module and the other roadside computation modules 240 may be slave roadside computation modules. The master Roadside Computing Module can be established using a master backup mode or using a dynamic election strategy. The master roadside computation module 240 is responsible for fusing the results of all computation units in the sub-network, communicates directly with the RSU 250 and the central platform subsystem 210, transfers slave roadside computation module information, etc. do.

FIG. 3D is also similar to the example network architecture 303 of FIG. Another network construction example 304 is shown. As a result, the calculation resources of the roadside calculation unit 242 can be better utilized.

FIG. 4 shows an example network architecture 401 associated with edge subsystem 230 . In the example network architecture 401 shown in FIG. 4, a central platform subsystem 210 can communicate over a network 310 with multiple edge computing subsystems (designated 230-1, . . . , 230-K, respectively). Here, K is an integer of 1 or more. Since the edge computation module 270 typically has more powerful computational power and network coverage capability, the edge computation module 270 in each edge computation subsystem 230 is required to process sensing information from multiple sensing devices 260. It may include multiple RSUs 250 connected to multiple sensing devices 260 . For example, the edge computation subsystem 230-1 includes an edge computation module 270-1, a first set of sensing devices 260-11, . -1M, and RSU250-11 and RSU250-1M. Here, M is an integer of 1 or more. Similarly, the edge computation subsystem 230-K includes an edge computation module 270-K, a first set of sensing devices 260-K1, ..., 260-KM, a second set of sensing devices 260-K1, ... connected thereto. , 260-KM, and RSU250-K1 and RSU250-KM. In each edge computation subsystem 230, multiple RSUs 250 can provide greater communication range. Therefore, the powerful computing power of the edge computing device 272 can be fully utilized to process more sensing devices to provide driving control of the vehicle over a wider geographic area.

Several exemplary networking schemes for roadside subsystems 220 and edge computation subsystems 230 have been described above. It will be appreciated that the figures show some examples and are not intended to limit the embodiments of the present disclosure. In some embodiments, these different networking schemes may generally exist within the operations control system 110 . For example, a central platform subsystem 210 within the driving control system 110 may be connected via a network to one or more roadside subsystems 220 shown in one or more examples of FIGS. 3A-3D and/or to FIG. It may be communicatively coupled to the edge computation subsystem 230 shown.

Service node architecture and example interaction with function nodes

As noted above, RSU 250, roadside computing unit 242, and edge computing device 272 may be collectively referred to herein as "function nodes," such as roadside service node 212, RSU service node 214, and edge service node 216. , the nodes servicing these functional nodes may be collectively referred to as "service nodes". In the operation control system 110, interactions between subsystems are realized mainly by interactions between service nodes and function nodes.

Service Nodes have a corresponding architecture to support such interactions. FIG. 5 shows an exemplary architecture of service node 501 interacting with function node 502 . The service node 501 may be the roadside service node 212, the RSU service node 214, or the edge service node 216 in the operational control system 110 of FIG. In some embodiments, the functions of multiple nodes within the roadside service node 212, the RSU service node 214, and the edge service node 216 within the central platform subsystem 210 may be consolidated by a single service node 501. . Embodiments of the present disclosure are not so limited. Functional node 502 may be RSU 250, roadside computing unit 242, or edge computing device 272 of operational control system 110 of FIG.

The operation of the service node 501 shown in FIG. 5 can realize information interaction between each subsystem, provide a unified path for interaction inside the subsystem, and provide a unified protocol and interface to the outside of the subsystem. , and implement management and message interaction for function nodes.

As shown in FIG. 5, service node 501 is divided into control layer 510 , management layer 520 and access layer 550 . Access layer 550 includes an access protocol stack 552 for supporting access protocols for functional node 502 . Access layer 550 can integrate access protocol stacks corresponding to one or more access protocols suitable for each function node 502 based on the type of function node 502 . In some embodiments, function node 502 includes RSU 250 and access protocol stack 552 may be V2X-related protocols supported by RSU 250, such as lightweight V2X protocols including LwM2M protocols, mqtt protocols, and the like. A lightweight protocol can reduce node-side resource consumption. In some embodiments, functional nodes 502, such as RSU 250, roadside computing unit 242, and/or edge computing unit 272, support network communications, and thus access protocol stack 552 implements the Hypertext Transfer Protocol (HTTP) protocol. It may be a network protocol stack such as a stack, a hypertext secure transmission (HTTPS) protocol stack, a cellular communication protocol stack.

Management layer 520 relates to device management 530 and configuration management 540 . Device manager 530 includes a connection manager module 532 to function node 502 and a status monitor module 534 . Configuration management 540 includes device configuration module 542 and policy configuration module 544 of function node 502 . Control layer 510 is used to control message collection module 512 , message delivery module 514 and message transfer module 516 of service node 501 .

Specific functions of each layer of the service node 501 will be described in detail below together with interaction with the function node 502 .

FIG. 6 shows a signaling map 600 between service nodes 501 and function nodes 502 according to some embodiments of the present disclosure. In the embodiment of FIG. 6, the service node 501 is one of the roadside service node 212, the RSU service node 214, and the edge service node 216, and the function nodes 502 are the RSU 250, the roadside computing unit 242, and the edge computing device 272. can be either

At 610 , service node 501 provides access to function node 502 based on the access protocol supported by function node 502 . Function node 502 establishes a communication link with service node 501 after accessing service node 501 . In some embodiments, in access provisioning 610, function node 502 may send an access request to service node 501 based on the corresponding access protocol. Access protocol stack 552 within access layer 550 of service node 501 processes access requests. In some embodiments, service node 501 may perform a validation to access permissions of function node 502 in response to an access request. This can be accomplished, for example, by connection management module 534 within device manager 530 . In response to the access authorization being verified, service node 501 can provide access to function node 502 . This allows the function node 502 to connect to and communicate with the service node 501 .

At 620, service node 501 transmits configuration information for the function node to function node 502 based on the access provided. Provision of the configuration information can be realized by the configuration management unit 540 of the service node 501, for example.

In some embodiments, device configuration 542 in configuration manager 540 provides first configuration information (also referred to as device configuration information) to function node 502 to configure communication and/or computational resources of function node 502 . ). For example, if function node 502 includes RSU 250 , the first configuration information can be used to configure RSU 250 transmit power and control RSU 250 communication range. If the functional node 502 includes a roadside computing unit 242 or an edge computing device 272, the first configuration information may allocate computing resources, e.g. pre-reserve some of the computing resources for subsequent computations. can be done.

In some embodiments, policy configuration 544 within configuration manager 540 sends second configuration information (also referred to as policy configuration information) to function node 502 to configure message interaction policies for function node 502 . can be configured as Message interaction policies may include message collection policies, message delivery policies, and message transfer policies for function nodes 502 of service nodes 501 . For example, for message collection and message delivery, the second configuration information may configure message collection and/or delivery start time, sampling interval, data type, priority transmission, transmission frequency, and the like. In the case of message transfer, the second configuration information can set the expiration date of the message to be transferred, the start time of transmission, the repetition cycle within the transmission time, the frequency of transmission, and the like.

In some embodiments, after the function node 502 receives the configuration information, it can configure itself using the configuration information and also return feedback information to the service node 501 .

At 630, the service node 501 can control message interactions with the function node 502 based on the configuration information to cause the OBU to control the operation of the vehicle 130. FIG. Message interactions between service nodes 501 and function nodes 502 may include message collection, message delivery, and message forwarding. Message collection refers to the service node 501 receiving messages from one or more function nodes 502 and the function nodes 502 reporting messages to the service node 501 according to the message collection policy. Message delivery refers to the delivery of messages by service nodes 501 to function nodes 502 and can be controlled by message delivery policies. Message forwarding means that service node 501 performs message forwarding between function nodes when two function nodes 502 need to communicate. Message forwarding can be controlled by a message forwarding policy. The message interaction process between service node 501 and function node 502 is described in detail below.

In some possible embodiments, at 640 the service node 501 further checks the status of the function node 502 to detect whether the function node 502 is online, offline, faulty, or otherwise. perform monitoring; Status monitoring may be performed by status monitoring module 534 within service node 501 . In the status monitoring process, function node 502 can periodically report its status to service node 501 . The service node 501 can update the local state information corresponding to the function node 502 based on the received status reports to record the latest status of the function node 502 . In some embodiments, function node 502 may transmit status reports to service node 501 in response to update requests from service node 501 . For example, if a service node 501 has not received a status report from a function node 502 for an extended period of time (e.g., exceeding a certain time threshold), the service node 501 sends an update request to Status reports can be actively detected.

The message interaction process between service node 501 and function node 502 is described below with reference to FIGS. 7A and 7B, which message interaction process directs OBU 132 to support operational control of vehicle 130 on which OBU 132 is mounted. is also involved. Differences in message interaction processes relate to OBU 132 communication capabilities.

In the signaling map 701 shown in FIG. 7A, function node 502-1 is, for example, the roadside computing unit 242 or edge computing device 272 that provides computing functions, and function node 502-2 is, for example, the RSU 250 that provides communication functions. is. Function nodes 502 - 1 and 502 - 2 may be included in roadside subsystem 220 or edge computation subsystem 230 . Accordingly, service node 501 may include roadside computing unit 242 or edge computing device 272 . In this example, OBU 132 has a communication connection with function node 502-2. Such communication connections may be, for example, V2X communication connections.

At 710, function node 502-1 transmits a driving-related message for vehicle 130 to service node 501 (also referred to herein as a "first driving-related message" for convenience of explanation). The first driving-related message may be at least one of a sensing message, a decision planning message, and/or a control message for vehicle 130 established by function node 502-1. A first driving-related message is determined by function node 502 based on the sensing information of sensing device 260 in subsystem 220 or 230 .

After receiving the first driving-related message from function node 502-1, at 720 service node 501 determines another driving-related message for vehicle 130 by processing the first driving-related message (description (also referred to herein as a "second driving-related message"). The second driving-related message can be different than the first driving-related message and can include at least one of a sensing message, a decision planning message, and/or a control message for vehicle 130 . For example, the first driving-related message may be a sensing message for vehicle 130, and the second driving-related message is a decision planning message for vehicle 130 determined based on the sensing message and/or It may be a control message. As another example, the first driving-related message may be a driving planning message and the second driving-related message may be a control message for vehicle 130 . In such an example, service node 501 provides additional computing power.

In some embodiments, service node 501 receives driving-related messages for another vehicle 130 (also referred to herein as a “third driving-related message” for convenience of explanation) from another function node 502 . You can also The service node 501 can process the first driving-related message and the third driving-related message to determine the first driving-related message. Having more driving-related information, the service node 501 can implement more customized services based on such global information. This can be accomplished, for example, by a separate service module within service node 501 . For example, based on messages from multiple function nodes, the service node 501 can provide global information such as overall traffic congestion status in a specific area, road traffic flow notifications, lane adjustment status, traffic light reminders, road abnormality status, road construction status, etc. Traffic conditions can be determined. Accordingly, the service node 501 can determine whether to adjust the travel route and/or the particular driving maneuver of the particular vehicle 130 and generate a second driving-related message based thereon.

At 730 , service node 501 provides a second driving-related message to function node 502 - 1 , eg, roadside computation unit 242 in roadside subsystem 220 or edge computation unit 272 in edge computation subsystem 230 . At 740, function node 502-1 transmits a second driving-related message to function node 502-2, which may be implemented within a local area network of subsystems 220 or 230, for example. At 750 , function node 502 - 2 , eg, RSU 250 , transmits a second operational-related message to OBU 132 . In one embodiment, function node 502 - 2 may broadcast a second driving-related message to OBU 132 . Upon receiving the second driving-related message, OBU 132 may perform driving control of vehicle 130 according to the second driving-related message.

In the embodiment shown in FIG. 7B, OBU 132 is assumed to have a communication connection with service node 501 . In such an embodiment, the OBU 132 may have network capabilities, for example, the OBU 132 may access the Internet by way of an application in the user terminal or in-vehicle central control platform, etc., thereby communicating with the service node 501. Get a connection. In signaling map 702 of FIG. 7B, the operations at 710 and 720 are similar to signaling map 701 . After service node 501 determines the second driving-related message, it can transmit the second driving-related message to OBU 132 via a communication connection with OBU 132 .

In some embodiments, driving control for vehicle 130 may be implemented within roadside subsystem 220 and/or edge computation subsystem 230 in addition to interacting with service node 501 . Driving-related messages determined by roadside computing unit 242 and/or edge computing unit 272 may be provided directly to OBU 132 via RSU 250 . OBU 132 may further process the received driving-related messages or control vehicle 130 directly based on the messages. Such typical application scenarios include cooperative sensing, semantic level sensing result sharing, and so on. Cooperative sensing is the sharing of global information sensed by roadside subsystem 220 with vehicles to supplement vehicle sensing. Semantic level sensing result sharing means that the roadside subsystem sensed results are semantically identified and shared with vehicles. is shared.

Docking example with 3rd platform

In some embodiments, the driving control system 110 according to embodiments of the present disclosure can also be docked to third party platforms. Such an embodiment is shown in FIG. As shown in FIG. 8, the central platform subsystem 210 of the operational control system 110 further includes a third party docking service node 818 for docking to a third party service platform 880 . Third party service platform 880 may include one or more third party service terminals 882-1, . be called). Each third party service terminal 882 can provide a corresponding third party service, such as map services, navigation services, traffic monitoring services, and the like. Third party docking service node 818 is configured to control, manage and message interact with third party service terminal 882 . The structure of third party docking service node 818 may be similar to service node 501 shown in FIG. Central platform subsystem 210 can provide data support to third party platform 880, making interaction between third party platform 880 and vehicle 130 more flexible and convenient.

In some embodiments, OBU 132 may have network capabilities and may communicate with third party platform 880 . For example, one or more OBUs 132 can be installed with third party applications 830-1, . for convenience, collectively or singly referred to as third party applications 830). OBU 132 may communicate with third party platform 880 via third party application 830 .

FIG. 9A shows a signaling map 901 in an embodiment with communication connections between OBU 132 and third party platform 880. FIG. Signaling map 901 has actions 710 and 720 in signaling maps 701 and 702, and service node 501 performs a second operation for vehicle 130 based on the first driving-related message from function node 502-1. Confirm driving-related messages. Service node 501 preferably provides the second driving-related message to OBU 132 on corresponding vehicle 130 . In the embodiment of FIG. 9A, provision of such messages may be implemented via third party platform 880, specifically third party service terminal 882 within the third party platform. As shown in FIG. 9A , at 910 service node 501 transmits a second driving-related message to third party service terminal 882 . Service node 501 can communicate with third party service terminal 882 via a wired or wireless network. Upon receiving the second driving-related message, at 920 third party service terminal 882 forwards the second driving-related message to OBU 132 via a corresponding communication connection. This will allow third-party platforms to provide more flexible driving assistance.

As a specific example, taking the traffic light reminder function as an example, the first driving-related message uploaded by function node 502-1 includes traffic light conditions in the geographic region or driving route in which vehicle 130 is located. The service node 501 provides the traffic light status related information as a second driving related message to the third party service terminal 882 after performing no processing or corresponding message conversion. Third party service terminal 882 can then provide traffic light status to OBU 132 . For example, third party service terminal 882 may provide a map service to push traffic light status information onto a map application installed on OBU 132 . A map application can display real-time traffic light conditions in a corresponding geographic area or route.

In some other embodiments, there is no communication connection between third party platform 880 and OBU 132 . In this case, third party platform 880 , eg, third party service terminal 882 , may also provide driving-related messages to OBU 132 via driving control system 110 . Such an embodiment is shown in Figures 9B and 9C.

In signaling map 902 shown in FIG. 9B, OBU 132 has a communication connection with function node 502-2 (eg, RSU 250). At 930 , service node 501 receives driving-related messages (also referred to as “fourth driving-related messages” for convenience of explanation) of third-party service terminal 882 for vehicle 130 . A fourth driving-related message may, for example, include information related to the sensing message, but may be generated by the third party platform 880 rather than determined by the sensing information of the sensing device. In some examples, the fourth driving-related message may include information regarding the traversable state of the road, such as, for example, a temporary road closure notification by a traffic management agency. A fourth driving-related message may also include temporary adjustments to road speed limits, emergency broadcasts, and the like.

At 940, service node 501 may forward a fourth operational-related message to function node 502-2 of subsystem 220 or 230 (eg, RSU 250). The selection of function node 502-2 may relate to the geographic location where vehicle 130 is located such that OBU 132 on vehicle 130 is within communication range of function node 502-2. Function node 502-2 forwards the fourth driving-related message to OBU 132 at 950, and OBU 132 may perform corresponding driving control, such as adjusting the route, based on the fourth driving-related message.

In signaling map 903 shown in FIG. 9C , OBU 132 has a network communication connection with service node 501 . At 930 , service node 501 receives the fourth driving-related message of third-party service terminal 882 for vehicle 130 and at 960 transmits the fourth driving-related message to OBU 132 via a communication connection with OBU 132 . can be transferred.

process illustration

FIG. 10 illustrates a flow chart of an operational control method 1000 according to an embodiment of the present disclosure. Method 1000 is implemented in service node 501 of FIG. 5, which may be roadside service node 212, RSU service node 214, edge compute service node 216, and/or third party docking service node 818 in operational control system 110. be able to. It should be understood that although shown in a particular order, some steps in method 1000 may be performed in a different order than shown or in parallel. Embodiments of the present disclosure are not so limited.

At block 1010, the service node 501 provides access to the function node based on the access protocol that the function node supports, the function node providing the ability to communicate with the vehicle's on-board unit OBU or to compute information related to the vehicle. configured to At block 1020, service node 501 transmits configuration information for the function node to the function node based on the access. At block 1030, service node 501 controls message interactions with function nodes based on the configuration information to control operation of the vehicle via OBU.

In some embodiments, the functional node includes at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide computing functionality.

In some embodiments, the function node includes a roadside unit RSU configured to provide communication functions. In some embodiments, the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform, and the RSU is a combination of at least one of the roadside computing unit and the edge computing device and an OBU. configured to provide communication between

In some embodiments, the function node selects a vehicle based on at least one of a communication range supported by the function node, a computing power of the function node, and a sensing range supported by a sensing device associated with the function node. is placed in an environment in which the sensor is placed, and the functional node is configured to process sensory information from the sensing device.

In some embodiments, providing access includes receiving an access request from the function node based on an access protocol supported by the function node and, in response to the access request, verifying permission to access the function node. and providing access in response to the access permission being verified.

In some embodiments, process 1000 includes receiving status reports from function nodes, either periodically or in response to service node update requests, and based on the status reports, generating local status information corresponding to the function nodes. and updating.

In some embodiments, transmitting configuration information for the function node includes transmitting first configuration information for the function node to configure at least one of communication resources and computational resources of the function node. and transmitting second configuration information for the function node to configure a message interaction policy for the function node.

In some embodiments, controlling message interaction with the function node includes receiving a first driving-related message for the vehicle from the function node; processing the first driving-related message; Determining a second driving-related message for the vehicle that is different from the first driving-related message.

In some embodiments, controlling message interaction with the function node may include the function node sending a second operation-related message to the OBU via a communication connection between the function node and the OBU to control operation of the vehicle. further comprising being adapted to transmit to. In some embodiments, process 1000 further includes transmitting a second operational-related message to the OBU via a communication connection between the service node and the OBU. In some embodiments, process 1000 further includes transmitting a second driving-related message to the OBU via a communication connection between the third party platform and the OBU.

In some embodiments, determining the second driving-related message includes receiving a third driving-related message for another vehicle from another functional node; and determining a second driving-related message by processing the 3 driving-related messages.

In some embodiments, the service node has a communication connection with the OBU, and process 1000 receives a fourth driving-related message for the vehicle from the third party platform via the communication connection with the third party platform. and providing a fourth driving-related message to the OBU.

In some embodiments, the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node, the at least one sensing device located in the vehicle's local environment. It is

Diagram 1100 depicts a flow chart of an operational control method 1100 in accordance with an embodiment of the present disclosure. Method 1100 may be implemented in functional node 502 of FIG. 5 , which may be RSU 250 , roadside computing unit 242 , or edge computing device 272 within maneuver control system 110 . It should be noted that although shown in a particular order, some steps in method 1100 can be performed in a different order than shown or in parallel. Embodiments of the present disclosure are not so limited.

At block 1110, the function node 502 obtains access to the service node based on the access protocol it supports, the function node providing the ability to communicate with the vehicle's on-board unit OBU or to compute information related to the vehicle. configured to At block 1120, the function node 502 receives configuration information for the function node from the service node based on the access. At block 1130, the function node 502 performs message interactions with the service node based on the configuration information to cause operational control of the vehicle via the OBU.

In some embodiments, the functional node includes at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide computing functionality.

In some embodiments, the function node includes a roadside unit RSU configured to provide communication functions. In some embodiments, the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform, and the RSU is a combination of at least one of the roadside computing unit and the edge computing device and an OBU. configured to provide communication between

In some embodiments, the function node selects a vehicle based on at least one of a communication range supported by the function node, a computing power of the function node, and a sensing range supported by a sensing device associated with the function node. is placed in an environment in which the sensor is placed, and the functional node is configured to process sensory information from the sensing device.

In some embodiments, obtaining access comprises transmitting an access request to the service node based on an access protocol supported by the function node and verifying that permission to access the function node has been verified by the service node. responding and obtaining access.

In some embodiments, the process 1100 periodically or in response to an update request from a service node to update the local state information maintained by the service node and corresponding to the function node. to the service node.

In some embodiments, receiving configuration information for the function node includes receiving first configuration information for the function node to configure at least one of communication resources and computational resources of the function node. and/or receiving second configuration information for the function node to configure a message interaction policy for the function node.

In some embodiments, performing a message interaction with the service node includes transmitting a first driving-related message for the vehicle to the service node.

In some embodiments, the function node has a communication connection with the OBU and performs message interactions with the service node to receive a first driving-related message and a third message for another vehicle by the service node. receiving from the service node a second driving-related message for the vehicle, determined based on the driving-related message of the vehicle; and forwarding the second driving-related message to the OBU via the communication connection. Including further.

In some embodiments, the service node has a communication connection with the OBU and controlling message interaction with the function node includes obtaining a fourth driving-related message for the vehicle from the service node. , a fourth driving-related message is provided by a third-party platform.

In some embodiments, the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node, the at least one sensing device located in the vehicle's local environment. It is

Examples of devices and equipment

FIG. 12 shows a schematic block diagram of an apparatus 1200 for operational control according to an embodiment of the present disclosure. The device 1200 may be included in the roadside subsystem 112 of FIGS. 1 and 2 or may be implemented as the roadside subsystem 112 . As shown in FIG. 12, the apparatus 1200 includes an access module 1210 configured in the service node to provide access to the function node based on the access protocol supported by the function node. The function node is arranged to provide communication functions with the vehicle's on-board unit OBU or calculation functions of information related to the vehicle. Apparatus 1200 further includes a configuration module 1220 configured to transmit configuration information for the functional node to the functional node based on the access. Apparatus 1200 further includes an interaction module 1230 configured to control message interactions with function nodes based on the configuration information to facilitate operational control of the vehicle via the OBU.

In some embodiments, the functional node includes at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide computing functionality.

In some embodiments, the function node includes a roadside unit RSU configured to provide communication functions. In some embodiments, the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform, and the RSU is a combination of at least one of the roadside computing unit and the edge computing device and an OBU. configured to provide communication between

In some embodiments, the function node selects a vehicle based on at least one of a communication range supported by the function node, a computing power of the function node, and a sensing range supported by a sensing device associated with the function node. is placed in an environment in which the sensor is placed, and the functional node is configured to process sensory information from the sensing device.

In some embodiments, access module 1210 includes a request receiving module configured to receive an access request from a function node based on an access protocol supported by the function node; and a verification-based access module configured to provide access in response to the access permission being verified.

In some embodiments, apparatus 1200 includes a report receiving module configured to receive status reports from function nodes periodically or in response to service node update requests; a state update module configured to update local state information corresponding to the .

In some embodiments, the configuration module 1220 is configured to transmit first configuration information for the functional node and configure at least one of communication and computing resources of the functional node; a policy configuration module configured to transmit second configuration information for the function node and configure a message interaction policy for the function node.

In some embodiments, the interaction module 1230 includes a first message receiving module configured to receive a first driving-related message for the vehicle from the functional node and processing the first driving-related message. a first message processing module configured to determine a second driving-related message different from the first driving-related message for the vehicle.

In some embodiments, the interaction module 1230 is further configured to cause the function node to transmit a second driving-related message to the OBU via the communication connection between the function node and the OBU to control driving of the vehicle. be done. In some examples, the apparatus 1200 further includes a first message transmission module configured to transmit the second driving-related message to the OBU via the communication connection between the service node and the OBU. In some embodiments, apparatus 1200 further includes a second message transmission module configured to transmit a second driving-related message to the OBU via the communication connection between the third party platform and the OBU.

In some embodiments, the message processing module comprises a second message receiving module configured to receive third driving-related messages for other vehicles from other functional nodes; a second message processing module configured to determine a second driving-related message by processing the message and a third driving-related message.

In some embodiments, the service node has a communication connection with the OBU and the device 1200 receives fourth driving-related messages for the vehicle from the third party platform via the communication connection with the third party platform. Further includes a third message receiving module configured to receive and a message providing module configured to provide a fourth driving-related message to the OBU.

In some embodiments, the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node, the at least one sensing device located in the vehicle's local environment. It is

FIG. 13 shows a schematic block diagram of an apparatus 1300 for operational control according to an embodiment of the present disclosure. Apparatus 1300 may be included in onboard subsystem 132 of FIGS. 1 and 2 or may be implemented as onboard subsystem 132 . As shown in FIG. 13, the apparatus 1300 is an access module 1320 configured in a function node to obtain access to a service node based on an access protocol supported by the function node, the function node being a vehicle. It includes an access module 1320 configured to provide communication functions with the on-board unit OBU or calculation functions of vehicle-related information. Apparatus 1300 further includes a configuration module 1320 configured to receive configuration information for the functional node from the service node based on the access. Apparatus 1300 also further includes an interaction module 1330 configured to perform message interaction with the service node based on the configuration information to control operation of the vehicle via OBU.

In some embodiments, the functional node includes at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide computing functionality.

In some embodiments, the function node includes a roadside unit RSU configured to provide communication functions. In some embodiments, the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform, and the RSU is a combination of at least one of the roadside computing unit and the edge computing device and an OBU. configured to provide communication between

In some embodiments, the function node selects a vehicle based on at least one of a communication range supported by the function node, a computing power of the function node, and a sensing range supported by a sensing device associated with the function node. is placed in an environment in which the sensor is placed, and the functional node is configured to process sensory information from the sensing device.

In some embodiments, the access module 1320 includes a request transmission module configured to transmit access requests to service nodes based on access protocols supported by the function nodes, and access authorization to the function nodes by the service nodes. a verification module configured to obtain access in response to being verified.

In some embodiments, the apparatus 1300 periodically or in response to an update request from a service node to update the local state information maintained by the service node and corresponding to the function node. to the service node.

In some embodiments, the configuration module 1320 is a device configuration module configured to receive first configuration information for the function node and configure at least one of communication resources and computational resources of the function node. , and a policy configuration module configured to receive second configuration information for the function node and configure a message interaction policy for the function node.

In some embodiments, interaction module 1330 includes a message transmission module configured to transmit a first driving-related message for the vehicle to the service node.

In some embodiments, the function node has a communication connection with the OBU, and the interaction module receives from the service node based on the first driving-related message and the third driving-related message for another vehicle: a message receiving module configured to receive a second driving-related message for the vehicle established by the service node; and a message receiving module configured to forward the second driving-related message to the OBU via the communication connection. and a message transfer module.

In some embodiments, the service node has a communication connection with the OBU and the interaction module is configured to obtain from the service node a fourth driving-related message for the vehicle provided by the third party platform. including a message acquisition module configured in

In some embodiments, the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node, the at least one sensing device located in the vehicle's local environment. It is

FIG. 14 shows a schematic block diagram of an exemplary apparatus 1400 that can be used to implement embodiments of the present disclosure. Apparatus 1400 may be used to implement service node 501 or function node 502 of FIG. As shown, apparatus 1400 can perform various suitable operations by means of computer program instructions stored in read only memory (ROM) 1402 or loaded into random access memory (RAM) 1403 from storage unit 1408 . and a computing unit 1401 that can perform processing. RAM 1403 may further store various programs and data necessary for operation of device 1400 . Calculation unit 1401 , ROM 1402 and RAM 1403 are connected to each other via bus 1404 . Input/output (I/O) interface 1405 is also connected to bus 1404 .

In device 1400 there are input units 1406 such as keyboards, mice, etc., output units 1407 such as various types of displays, speakers etc., storage units 1408 such as magnetic disks, optical disks etc., network cards, modems, wireless communication transceivers etc. A number of components are connected to the I/O interface 1405 , including the communication unit 1409 . Communications unit 1409 enables device 1400 to exchange information or data with other devices over computer networks such as the Internet and/or various telecommunications networks.

Computing unit 1401 may be various general purpose and/or special purpose processing components having processing and computing power. Some examples of computational unit 1401 include a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computational chips, various computational units that run machine learning model algorithms, digital signal including, but not limited to, processors (DSPs), and any suitable processors, controllers, microcontrollers, and the like. Computing unit 1401 performs various methods and operations such as process 1000 or process 1100 described above. For example, in some embodiments process 1000 or process 1100 may be implemented as a computer software program tangibly contained in a machine-readable medium such as storage unit 1408 . In some embodiments, part or all of the computer program may be loaded and/or installed on device 1400 via ROM 802 and/or communication unit 1409 . A computer program, when loaded into RAM 1403 and executed by computing unit 1401, is capable of performing one or more steps of process 1000 or process 11000 described above. Alternatively, in other embodiments, computing unit 1401 may be configured to perform process 1000 or process 1100 by any other suitable means (eg, by firmware).

The functions described herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, general-purpose hardware logic components that can be employed include Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), System on Chips (SOCs), ), Complex Programmable Logic Devices (CPLDs), and the like.

Program code to implement the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, and when executed by the processor or controller, the flowcharts and/or Alternatively, the functions or operations specified in the block diagrams may be performed. The program code may run entirely on the device, partially on the device, or partially on the device and partially on the remote device as a stand-alone software package. or can be run entirely on a remote device or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium and includes a program for use by or in conjunction with an instruction execution system, apparatus or device. or can be stored. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus or devices, or any suitable combination thereof. More specific examples of machine-readable storage media include electrical connections based on one or more cables, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable Read only memory (EPROM or flash memory), optical fiber, compact disc read only memory (CD-ROM), optical storage, magnetic storage, or any suitable combination thereof may be included.

Also, although each action is presented in a particular order, it is not required that such actions be performed in the specific order presented or in sequence to achieve the desired result. , or should be understood to require that all actions shown in the figure be performed. Multitasking and parallelism can be advantageous in certain environments. Similarly, although some specific implementation details have been set forth above, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subset.

Although the subject matter has been described in language specific to structural features and/or methodological logic acts, subject matter defined in the claims is not necessarily limited to the specific features or acts described above. It should be understood that the Rather, the specific features and acts described above are merely exemplary forms of implementing the claims.

TECHNICAL FIELD Embodiments of the present disclosure mainly relate to the field of operation control, and more particularly to methods and devices, electronic devices, computer-readable storage media, operation control systems, and computer programs for operation control.

In recent years, Intelligent Transport System (ITS) is a completely new technology, adopting advanced science and technology, systematically and comprehensively considering related roads, traffic, people and environment, etc., to realize smart traffic management. and offer possibilities and hopes for solving road traffic problems. With the development of communication networks, especially with the deployment of the fifth generation (5G) communication network, ITS is expected to support "people-vehicle-road-cloud" coordinated communication and interaction, and different types of vehicles ( (including highly automated vehicles, connected cars with communication capabilities, and traditional public taxis) with different services. This will improve driving safety and traffic efficiency, and realize an intelligent transportation system. Currently, such solutions are lacking to normative collaborative interactions between vehicle-side, road-side and cloud-side.

Embodiments of the present disclosure provide a solution for operational control.

In a first aspect of the present disclosure, a method is provided for operational control. The method comprises the step of providing, in a service node, access to said functional node based on an access protocol supported by said functional node, said functional node communicating with an on-board unit OBU of a vehicle or associated with said vehicle. transmitting configuration information for said function node to said function node based on said access; and controlling operation of said vehicle via said OBU. controlling message interactions with said function node based on said configuration information to control.

In a second aspect of the disclosure, a method is provided for operational control. The method comprises the step of obtaining, in a function node, access to a service node based on an access protocol supported by said function node, said function node communicating with an on-board unit OBU of a vehicle or associated with said vehicle. receiving configuration information for said function node from said service node based on said access; and operating said vehicle via said OBU. performing message interactions with the service node based on the configuration information to control the .

In a third aspect of the present disclosure, an apparatus is provided for operational control. In a service node, an access module configured to provide access to said function node based on an access protocol supported by said function node, said function node having a communication function with an on-board unit OBU of a vehicle or to said vehicle. an access module configured to provide a computation function of related information; a configuration module configured to transmit configuration information for said function node to said function node based on said access; an interaction module configured to control message interactions with said function nodes based on said configuration information to control operation of said vehicle via an OBU.

In a fourth aspect of the present disclosure, an apparatus is provided for operational control. The apparatus is an access module configured in a function node to obtain access to a service node based on an access protocol supported by said function node, said function node communicating with an on-board unit OBU of a vehicle. an access module configured to provide computing functionality for information related to a function or said vehicle; and based on said access, configured to receive configuration information for said function node from said service node. a configuration module; and an interaction module configured to perform message interactions with the service node based on the configuration information to control operation of the vehicle via the OBU.

In a fifth aspect of the present disclosure, an electronic device comprising one or more processors and a storage device for storing one or more programs, wherein the one or more programs are stored in the one a storage device which, when executed by one or more processors, causes said one or more processors to implement the method according to the first aspect of the present disclosure.

In a sixth aspect of the disclosure, one or more processors;
A storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors receive the first program of the present disclosure. and a storage device that implements the method according to aspect 2 .

In a seventh aspect of the present disclosure, a computer readable storage medium storing a computer program, which, when executed by a processor, implements the method according to the first aspect of the present disclosure. Provide storage media.

In an eighth aspect of the present disclosure, a computer readable storage medium storing a computer program, which, when executed by a processor, implements the method of the second aspect of the present disclosure. Provide storage media.

In a ninth aspect of the present disclosure, an operational control system is provided. The system includes a central platform subsystem including an apparatus according to the third aspect. The system further includes at least one of a roadside subsystem and an edge computation subsystem including the apparatus of the fourth aspect.

In a tenth aspect of the disclosure, there is provided a computer program product which, when executed by a processor, implements a method according to the first or second aspect of the disclosure.

The content described in the Summary of the Invention is not intended to limit key or key features of the embodiments of the disclosure, nor is it intended to limit the scope of the disclosure. Other features of the invention will be readily understood from the following description.

The above as well as other features, advantages and aspects of each embodiment of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the drawings. In the accompanying drawings, same or similar reference numbers represent the same or similar elements.
1 is a schematic diagram of an exemplary environment in which some embodiments of the disclosure may be implemented; FIG. 1 is a block diagram illustrating an operational control system according to some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating an example network architecture for roadside subsystems in accordance with some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating an example network architecture for roadside subsystems in accordance with some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating an example network architecture for roadside subsystems in accordance with some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating an example network architecture for roadside subsystems in accordance with some embodiments of the present disclosure; FIG. FIG. 2 is a block diagram illustrating an example network architecture for an edge computation subsystem according to some embodiments of the present disclosure; 3 is a block diagram illustrating an example configuration of an abstract service node according to some embodiments of the present disclosure; FIG. 4 is a signaling map between service nodes and function nodes according to some embodiments of the present disclosure; 4 is a signaling map between service nodes, function nodes and an on-board unit (OBU) according to some embodiments of the present disclosure; 4 is a signaling map between service nodes, function nodes and an on-board unit (OBU) according to some embodiments of the present disclosure; FIG. 4 is a block diagram illustrating a driving control system according to some other embodiments of the present disclosure; FIG. 4 is a signaling map between service nodes, function nodes, third party platforms and OBUs according to some embodiments of the present disclosure; 4 is a signaling map between service nodes, function nodes, third party platforms and OBUs according to some embodiments of the present disclosure; 4 is a signaling map between service nodes, function nodes, third party platforms and OBUs according to some embodiments of the present disclosure; 4 is a flowchart of a method for service node side operational control according to some embodiments of the present disclosure; 1 is a schematic block diagram of an apparatus for functional node side operational control according to some embodiments of the present disclosure; FIG. 1 is a schematic block diagram of an apparatus for service node side operational control according to some embodiments of the present disclosure; FIG. 1 is a schematic block diagram of an apparatus for functional node side operational control according to some embodiments of the present disclosure; FIG. 1 is a block diagram illustrating a device in which embodiments of the present disclosure can be implemented; FIG.

Hereinafter, embodiments of the present disclosure will be described in more detail with reference to the accompanying drawings. Although several embodiments of the invention are illustrated in the drawings, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, it should be understood that these examples are provided for a clearer and more complete understanding of the invention. It should be noted that the drawings and embodiments of the present disclosure are merely exemplary and do not limit the protection scope of the present disclosure.

In describing embodiments of the present disclosure, the term "including" and like terms should be understood as a non-limiting expression, "including but not limited to." The term "based on" should be understood as "based at least in part on". The terms "one embodiment" or "the embodiment" should be understood as "at least one embodiment". It should be noted that the terms "first", "second", etc. can refer to different objects or the same object. Other explicit or implicit definitions may also be included below.

As described above, in an intelligent transportation system (ITS), driving control of a vehicle, such as a vehicle, is related to the environment sensing ability and communication ability of the vehicle itself. Vehicles are currently being made smarter and networked.

From the perspective of smartification, smartification of vehicles can be divided from assisted driving to fully automated driving. However, smart vehicles are classified according to the degree of smartness of the vehicles themselves, and the vehicles themselves do not necessarily have the ability to communicate with other devices, ie, smart vehicles are single-car smart vehicles. For example, L4/L5 self-driving vehicles require cameras, lidar, millimeter-wave radar and other devices to be installed in the vehicle to sense the surrounding environment and adjust the motion state of the unmanned vehicle in real time. . Due to the limited nature of motorcycles, even in the highest level of smart vehicles, motorcycle sensing still has problems such as shielding and limited sensing distance. It is necessary to improve the degree of smartness of low-smart vehicles by other methods.

From the point of view of networking, from the traditional networked auxiliary information interaction (such as obtaining navigation information) to networked cooperative decision and control (planned control for vehicles through vehicle-to-vehicle and road-to-vehicle cooperation) , the networking dimension of vehicles mainly focuses on the degree of communication between participants, such as vehicle-to-vehicle, road-to-vehicle, cloud-to-vehicle, and human-to-vehicle. The higher the networking level, the more complete the information that can be shared between vehicles. However, many of the vehicles (e.g. vehicles) currently on the market do not have networking or only have the earliest networking capabilities, so even low-level networking vehicles participate in high-level networking. It is necessary to realize smart control of the entire transportation system.

According to embodiments of the present disclosure, an improved driving control scheme is proposed. This scheme normalizes the interactions between service nodes and function nodes that provide communication or computational functions. A function node may be a computing function that communicates with the vehicle's on-board unit (OBU) or provides information related to the vehicle. Specifically, the service node provides access to the function node based on the access protocol, transmits configuration information for the function node to the function node based on the access, and sends messages to the function node based on the configuration information. Control interactions and facilitate driving control of the vehicle via the OBU. This realizes smart control of the entire transportation system.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

Environment example

FIG. 1 is a schematic diagram illustrating an example traffic environment 100 in which some embodiments of the disclosure may be implemented. This example environment 100 includes one or more vehicles 130-1, 130-2, . . . 130-N. . . 130-N may be collectively referred to as vehicle 130 or simply as vehicle 130 for convenience of explanation. Vehicle, as used herein, refers to any type of mobile vehicle capable of carrying people and/or goods. Vehicle 130 is illustrated as a vehicle in FIG. 1 and other drawings and descriptions herein. Vehicles may be motor vehicles or non-motor vehicles, including, but not limited to, automobiles, passenger cars, trucks, buses, electric vehicles, motorcycles, bicycles, and the like. However, it should be understood that a vehicle is only one example of a vehicle. Embodiments of the present disclosure are equally applicable to vehicles other than vehicles, such as ships, trains, and airplanes.

One or more vehicles 130 in environment 100 may be vehicles with some self-driving capabilities, also referred to as driverless vehicles. Of course, one or more of the other vehicles 130 in the environment 100 may be vehicles with no autonomous driving capabilities or vehicles with only driving assistance capabilities. Such vehicles can be controlled by a driver. Integrated or detachable devices within one or more vehicles 130 may be, for example, vehicle-to-vehicle (V2V) technologies, vehicle-to-roadside-infrastructure (V2I) technologies, vehicle-to-network (V2N) technologies, to-cellular-Network) technology, connectivity between a car and something (vehicles, pedestrians, infrastructure, networks, etc.) (V2X, Vehicle to X) technology, or any other communication technology, one or more communication technology to communicate with other devices.

Vehicle 130 may be fitted with positioning devices to determine its position, such as positioning technology based on laser point cloud data, global positioning system (GPS) technology, global navigation satellite system ( GLONASS) technology, Beidou Navigation System technology, Galileo positioning system (Galileo) technology, Quasi-Zenith Satellite System (QAZZ) technology, base station positioning technology, Wi-Fi positioning technology, etc. can.

In addition to vehicles 130, environment 100 may have other objects such as animals, plants 105-1, people 105-2, movable or non-movable objects such as transportation infrastructure. The traffic infrastructure includes objects for guiding traffic and indicating traffic rules, such as traffic lights 120, traffic signs (not shown), street lights, and the like. Objects outside the vehicle are collectively referred to as an object outside the vehicle 105 .

A driving control system 110 for a vehicle 130 is also located in environment 100 . Driving control system 110 is configured to control driving of vehicle 130 in at least environment 100 . Each vehicle 130-1, 130-2, . . . , 130-N may be provided with a corresponding OBU 132-1, 132-2, . OBUs 132-1, 132-2, . Operations control system 110 may be in signaling communication with OBU 132 . The OBU 132 can support communication with the driving control system 110 to obtain corresponding information and perform driving control of the vehicle 130 based on the obtained information. The OBU 132 also receives information from the vehicle 130 such as, for example, feedback information, sensory data collected by sensing devices (if present) on the vehicle 130, or results of processing into sensory data by computing units (if present) on the vehicle 130. can be transmitted to the operations control system 110 regarding the. According to embodiments of the present disclosure, the driving control system 110 and OBU 132 may support some or all of the driving controls for vehicles having various levels of smartening and networking.

Note that the facilities and objects shown in FIG. 1 are only examples. The type, quantity, relative placement, etc. of objects appearing in various environments may vary. The scope of the disclosure is not limited in this regard. For example, the environment 100 may have more roadside devices 110 and sensing devices 260 placed along the roadside to monitor additional geographic locations. Embodiments of the present disclosure may involve multiple distal devices or no distal devices.

Example of operation control system

FIG. 2 is a schematic block diagram illustrating the operational control system 110 of FIG. 1 according to some embodiments of the present disclosure. FIG. 2 also shows OBU 132 on vehicle 130 that interacts with driving control system 110 . Operational control system 110 includes a central platform subsystem 210 for centrally controlling and managing each subsystem within operational control system 110 . Central platform subsystem 210 may also be referred to as a center platform, central platform, centralized platform, or the like. The maneuver control system 110 may also include one or more roadside subsystems 220 and/or one or more edge computation subsystems 230, which provide sensing, configured to provide decision making and/or coordinated control.

The central platform subsystem 210 may include one or more of a roadside service node 212 , a roadside unit (RSU) service node 214 , and an edge service node 216 . The roadside service node 212 is configured to manage, control and message interact with edge computing devices within the maneuver control system 110, the RSU service node 214 manages and controls the RSU within the maneuver control system 110, Configured for data interaction. Edge service node 216 is configured to manage, control, and data interact with edge computing devices within operations control system 110 .

The roadside subsystem 220 is primarily located near the geographic area in which the vehicle 130 travels and/or parks, and may be, for example, spaced apart on both sides of a road or where the vehicle 130 is located. It may be arranged at a predetermined distance from the position to obtain. The roadside subsystem 220 may include a roadside computing module 240 , one or more RSUs 250 and one or more sensing devices 260 . The roadside computing module 240 may include a roadside computing unit 242 and an RSU service node 214 .

The RSU 250 is equipment having a communication function. RSU 250 may provide direct communication with OBU 132, which may be, for example, direct connection communication based on the Internet of Things (V2X) protocol. Alternatively or additionally, RSU 250 may also provide network communication, eg, communication over a cellular network, with RSU service nodes 214 within central platform subsystem 210 and/or roadside computing module 240 .

Sensing device 260 is configured to monitor environment 100 in which vehicle 130 is located. For example, the sensing device 260 may be configured to sense road traffic conditions, road natural conditions, weather conditions, etc. of the environment 100 within its sensing range and input the sensed data to the roadside computing module 240 . Sensing devices 260 may be located near areas in which vehicle 130 travels and/or parks. The sensing range of sensing device 260 is limited according to sensing capabilities. In some cases, the sensing ranges of multiple adjacently positioned sensing devices 260 may partially overlap. If desired, the sensing device 260 may be placed on the side of the road, on the road surface, or may be placed at a predetermined height, such as fixed at a predetermined height by a support rod. In some examples, in addition to fixing sensing device 260 at a particular location, moveable sensing device 260, such as a moveable sensing site, may also be provided.

Sensing device 260 may include one or more sensor units, which may be of the same type or different types and may be positioned at the same or different locations in sensing area 102 . Examples of sensor units in the sensing device 260 are image sensors (e.g. cameras), lidar, millimeter wave radar, infrared sensors, positioning sensors, light sensors, pressure sensors, temperature sensors, humidity sensors, wind speed sensors, wind direction sensors, air Including, but not limited to, mass sensors and the like. An image sensor can collect image information. Lidar and millimeter wave radars can collect laser point cloud data. Infrared sensors can use infrared rays to detect environmental conditions in the environment. A positioning sensor can collect position information of an object. A light sensor can collect an index value indicative of the intensity of light illumination in the environment. Pressure, temperature and humidity sensors can collect index values indicative of pressure, temperature and humidity respectively. Wind speed and wind direction sensors can collect index values indicating wind speed and wind direction, respectively. Air mass sensors can collect indicators related to air mass, such as, for example, oxygen concentration, carbon dioxide concentration, dust concentration, pollutant concentration in the air. As will be appreciated, the above listed only some examples of sensor units. Other types of sensors may exist according to actual needs.

The roadside computing unit 242 within the roadside computing module 240 is configured to provide computational functionality, particularly for information related to the vehicle 130 . The roadside computing unit 242 may be any device having computing capabilities such as one or more processors, processing devices, general purpose computers, and the like. The roadside computing unit 242 may be configured to obtain original sensing information from one or more sensing devices 260 . Data transmission between the roadside computing unit 242 and the sensing device 260 may be based on a wired line or wireless communication. Roadside computing unit 242 may further be configured to process sensory information from sensing devices 260 and generate driving-related messages for vehicle 130 based on the sensory information.

The driving-related message includes a sensing message indicating the result of sensing the environment around the vehicle 130, a decision plan message indicating a decision plan when driving the vehicle 130, and a control message indicating a specific driving operation when driving the vehicle 130. can include at least one of Viewed in turn, the information indicated by each of these three types of messages depends on the information contained in the previous type of message. For example, environmental sensing results are based on the sensing information of the sensing device 260, decision plans are based at least on the environmental sensing results, and control messages are typically created based on the decision plans or based on the environmental sensing results. Depending on the computing power and configuration of the roadside computing unit 242, the roadside computing unit 242 may generate sensing messages for the vehicle 130 by performing one or more levels of computation based on the sensing information of the sensing devices 260; Decision planning messages and/or control messages can be established. Driving-related messages determined by roadside computing unit 242 may be further processed by other computing devices or by OBUs as needed.

In some embodiments, the roadside computing unit 242 may determine environmental sensing results associated with the vehicle 130 through algorithms such as data fusion, obstacle sensing, etc., and generate sensing messages. For example, the roadside computing unit 242 may perform direct obstacle sensing processing and/or further semantic level sensing processing on the original sensing information. Obstacle sensing processing includes recognizing the size, shape, speed, etc. of obstacles on the road, and semantic level sensing processing judges vehicles abandoned on the road and special vehicles on the road based on the results of obstacle sensing. Including judging road conditions such as judging.

Depending on the source and specific content of the sensed information, the sensed message may include instructional information related to one or more other aspects of environment 100 and/or vehicle 130 within environment 100 . In some embodiments, the sensory message is for indicating at least one of: obstacle type, location information, velocity information, direction information, physical appearance description information, historical trajectory, and predicted trajectory. information about the physical conditions of the roads in the environment 100 to indicate at least one of the physical conditions of the road surfaces and the structural information of the roads; Information about traffic facilities within environment 100 to indicate conditions and/or traffic signs, and/or lane signs for roads and/or lanes within roads, traffic traffic, and/or traffic incidents. information about traffic conditions on roads within the environment 100 and information about weather conditions within the environment 100. In some embodiments, the sensed messages may also include aiding information regarding positioning of the vehicle 130, diagnostic information regarding malfunctions of the vehicle 130, information regarding software systems within the vehicle 130, and/or time information. Although some examples of content included in sense messages are listed above, it should be understood that sense messages may also include other content, including less or more content.

The decision plan message includes an indication of the road on which the decision is to be applied, start time information and/or end time information of the decision plan, start location information and/or end location information of the decision plan, identifier of the vehicle for which the decision plan is intended, Decision information on vehicle driving behavior, decision information on vehicle driving behavior, route plan trajectory point information, estimated time to reach route plan trajectory point, information on other vehicles related to the decision plan, map information and time information, etc. , may include information of one or more aspects. The map information can indicate, for example, at least one of a map identifier, a map update method, a map updated area, and location information. The map identifier may include, for example, the map version number, map update frequency, and the like. The map update strategy may indicate, for example, the map update source (from remote device 120 or other external source), update link, update time, and the like. Although some examples of content included in decision plan messages are listed above, it should be understood that decision plan messages may also include other content, including lesser or more content.

The control messages include kinematic control information related to motion of the vehicle, dynamic control information related to at least one of a power system, transmission system, braking system, and steering system of the vehicle; Information regarding one or more aspects of control information related to the boarding experience, control information related to the vehicle's traffic warning system, and time information may be included. Although some examples of content that control messages contain are listed above, it should be understood that control messages may also contain other content, including lesser or more content.

The roadside computing unit 242 may have communication with the roadside service node 212 . Communication between the roadside computing unit 242 and the roadside service node 212 may be via a wired or wireless network. The roadside computing unit 242 can transmit driving-related messages to the roadside service node 212 via communication with the roadside service node 212 . The roadside computing unit 242 may also receive control signaling, information, data, etc. from the roadside service node 212 . The roadside computing unit 242 may also forward corresponding information to the OBU 132 via the RSU 250 under the control of the roadside service node 212 . In addition to the roadside computing unit 242 , in some embodiments the roadside computing module 240 may include an RSU service node 214 for managing and controlling the RSUs 250 . RSU service node 214 may be configured to support message interaction with RSU 250 .

The edge computation subsystem 230 within the operations control system 110 may include an edge computation module 270 that includes an edge computation unit 272 and an RSU service node 214 . Edge computation subsystem 230 may also include one or more RSUs 250 and one or more sensing devices 260 . In the Edge Computing Subsystem 230 , the functionality and arrangement of the RSU Service Nodes 214 , RSUs 250 and Sensing Units 260 are similar to those in the Roadside Subsystem 220 . Edge computation unit 272 is configured to provide computational functionality, particularly computation of information related to vehicle 130 . In some embodiments, edge computing device 272 processes sensory information from sensing device 260 and, based on the sensory information, provides information for vehicle 130, such as sensing messages, decision planning messages, and/or control messages. of driving-related messages.

The edge computing device 272 can also be referred to as an edge computing node, and is a network node such as a server, a large server, an edge server, etc., a cloud-end computing device such as a virtual machine (VM), etc., and any network node that provides computing functionality. other devices. In a cloud environment, remote devices are sometimes referred to as cloud devices. In some embodiments, the edge computing device 272 may provide more powerful computing power and/or a more convenient ability to access the core network compared to the roadside computing unit 242 . Accordingly, the edge computation unit 272 can support the fusion of sensory information for a wider geographic area. The edge calculator 272 may be arranged according to the level of the road segment, for example it may be arranged in the computer room of the edge of one road segment.

The roadside subsystem 220 and edge computation subsystem 230 interacting with the central platform subsystem 210 have been described above. Each of the roadside subsystem 220 and the edge computation subsystem 230 is a small local area network responsible for environmental sensing and computation based on sensing information for a specific geographical area of the environment 100 to implement localized driving control. can be viewed. Here, the RSU 250 that provides the communication function and the roadside computing unit 242 and the edge computing device 272 that provide the computing function are collectively referred to as "function nodes". Nodes that service these functional nodes, such as 216, are collectively referred to as "service nodes".

In the driving control system 110 there may be one or more roadside subsystems 220 and one or more edge computation subsystems 230 that interact with the central platform subsystem 210 . The central platform subsystem 210 can obtain multi-segment, multi-region, even city-wide or wider geographic area multi-dimensional information related to operational control of the vehicle 130, such as environmental sensing, incidents, etc. It can be thought of as providing cloud functionality. By knowing global network information, the central platform subsystem 210 can provide more ability to expand based on global information. These abilities are discussed below.

Network construction example

The maneuver control system 110 may include one or more roadside subsystems 220 and one or more edge computation subsystems 230, both of which interact with the central platform subsystem 210. can be done. The connections between these subsystems and the central platform subsystem, and the deployment scheme within each subsystem, can be changed as needed. An example of a network construction scheme for roadside subsystems and edge computation subsystems is described below.

3A-3D show an example of a network configuration associated with the roadside subsystem 220. FIG. In general, the networking scheme within the roadside subsystem 220 may depend on the computing power of the roadside computing unit 242, the communication range supported by the RSU 250, and/or the sensing range supported by the sensing device 260.

In the example network architecture 301 shown in FIG. 3A, a central platform subsystem 210 communicates with a plurality of roadside subsystems (denoted 220-1, . includes a roadside computation module 240 , a single sensing device 260 and a single RSU 250 . Here, K is an integer of 1 or more. For example, roadside subsystem 220-1 includes, in addition to roadside computing module 240-1, a single sensing device 260-1 and a single RSU 250-1, both in communication with roadside computing module 240-1. combined. Roadside subsystem 220-K includes, in addition to roadside computing module 240-K, a single sensing device 260-K and a single RSU 250-K, both communicatively coupled with roadside computing module 240-K. be. A feature of such a network construction method is that the roadside subsystem 220 is arranged with the sensing range of the sensing device 260 as a limit. For example, if the sensing range of the sensing device 260 is 150m, the roadside subsystem 220 is placed every 150m on the road on which the vehicle 130 travels. In this example, it is assumed that the communication range of RSU 250, particularly the direct connection communication range with OBU 132, is greater than the sensing range of sensing device 260, which is normally the case. If the communication range is less than the sensing range, the roadside subsystem 220 is placed with the communication range of the RSU 250 as the limit.

In the example network architecture 302 shown in FIG. 3B , compared to the example network architecture 301 , the roadside computing unit 242 in the roadside computing module 240 has stronger computing power and can process sensing information from multiple sensing devices 260 . Thus, in FIG. 3B, roadside computing module 240-1 is connected to multiple sensing devices 260-11, . can be connected. Here, M is an integer of 1 or more. A feature of the network construction scheme of FIG. 3B is that the communication capabilities of the RSU 250 and the computational resources of the roadside computing unit 242 can be fully utilized. Therefore, assuming that the communication range supported by the RSU 250 is 500m and the sensing range of the sensing device 260 is 150m, each roadside computing module 240 supports processing into sensing information of three consecutive sensing devices 260. A roadside subsystem 220 can be provided every 500m on the road on which the vehicle 130 travels. Note that the number of sensing devices to which each roadside computing module 240 is connected may differ.

In the network construction example 303 shown in FIG. 3B, sensing devices 260 and roadside computing modules 240 are placed at respective locations according to the sensing capabilities of the sensing devices 260, and multiple roadside computing modules 240 have one RSU. The placement of sensing device 260 and roadside computing module 240 is determined based on the sensing range of sensing device 260 , and the placement of overall roadside subsystem 220 is determined based on the communication range of RSU 250 . In other words, in such a network construction method, there is no 1:1 relationship between the RSU and the roadside calculation module 240 . Thereby, the communication capability of the RSU 250 can be utilized to the maximum. As shown in FIG. 3B, the roadside subsystem 220-1 includes a single RSU 250-1, a plurality of roadside computing modules 240-11, . 260-11, ..., 260-1M. Similarly, the roadside subsystem 220-K includes a single RSU 250-K, a plurality of roadside computing modules 240-K1, . . . , 240-KM and sensing devices 260-K1, . , 260-KM.

In each roadside subsystem 220, one roadside computation module 240 may be the master roadside computation module and the other roadside computation modules 240 may be slave roadside computation modules. The master Roadside Computing Module can be established using a master backup mode or using a dynamic election strategy. The master roadside computation module 240 is responsible for fusing the results of all computation units in the sub-network, communicates directly with the RSU 250 and the central platform subsystem 210, transfers slave roadside computation module information, etc. do.

FIG. 3D is also similar to the example network architecture 303 of FIG. Another network construction example 304 is shown. As a result, the calculation resources of the roadside calculation unit 242 can be better utilized.

FIG. 4 shows an example network architecture 401 associated with edge computation subsystem 230 . In the example network architecture 401 shown in FIG. 4, a central platform subsystem 210 can communicate over a network 310 with multiple edge computing subsystems (designated 230-1, . . . , 230-K, respectively). Here, K is an integer of 1 or more. Since the edge computation module 270 typically has more powerful computational power and network coverage capability, the edge computation module 270 in each edge computation subsystem 230 is required to process sensing information from multiple sensing devices 260. It may include multiple RSUs 250 connected to multiple sensing devices 260 . For example, the edge computation subsystem 230-1 includes an edge computation module 270-1, a first set of sensing devices 260-11, . -1M, and RSU250-11 and RSU250-1M. Here, M is an integer of 1 or more. Similarly, the edge computation subsystem 230-K includes an edge computation module 270-K, a first set of sensing devices 260-K1, ..., 260-KM, a second set of sensing devices 260-K1, ... connected thereto. , 260-KM, and RSU250-K1 and RSU250-KM. In each edge computation subsystem 230, multiple RSUs 250 can provide greater communication range. Therefore, the powerful computing power of the edge computing device 272 can be fully utilized to process more sensing devices to provide driving control of the vehicle over a wider geographic area.

Several exemplary networking schemes for roadside subsystems 220 and edge computation subsystems 230 have been described above. It will be appreciated that the figures show some examples and are not intended to limit the embodiments of the present disclosure. In some embodiments, these different networking schemes may generally exist within the operations control system 110 . For example, a central platform subsystem 210 within the driving control system 110 may be connected via a network to one or more roadside subsystems 220 shown in one or more examples of FIGS. 3A-3D and/or to FIG. It may be communicatively coupled to the edge computation subsystem 230 shown.

Service node architecture and example interaction with function nodes

As noted above, RSU 250, roadside computing unit 242, and edge computing device 272 may be collectively referred to herein as "function nodes," such as roadside service node 212, RSU service node 214, and edge service node 216. , the nodes servicing these functional nodes may be collectively referred to as "service nodes". In the operation control system 110, interactions between subsystems are realized mainly by interactions between service nodes and function nodes.

Service Nodes have a corresponding architecture to support such interactions. FIG. 5 shows an exemplary architecture of service node 501 interacting with function node 502 . The service node 501 may be the roadside service node 212, the RSU service node 214, or the edge service node 216 in the operational control system 110 of FIG. In some embodiments, the functions of multiple nodes within the roadside service node 212, the RSU service node 214, and the edge service node 216 within the central platform subsystem 210 may be consolidated by a single service node 501. . Embodiments of the present disclosure are not so limited. Functional node 502 may be RSU 250, roadside computing unit 242, or edge computing device 272 of operational control system 110 of FIG.

The operation of the service node 501 shown in FIG. 5 can realize information interaction between each subsystem, provide a unified path for interaction inside the subsystem, and provide a unified protocol and interface to the outside of the subsystem. , and implement management and message interaction for function nodes.

As shown in FIG. 5, service node 501 is divided into control layer 510 , management layer 520 and access layer 550 . Access layer 550 includes an access protocol stack 552 for supporting access protocols for functional node 502 . Access layer 550 can integrate access protocol stacks corresponding to one or more access protocols suitable for each function node 502 based on the type of function node 502 . In some embodiments, function node 502 includes RSU 250 and access protocol stack 552 may be V2X-related protocols supported by RSU 250, such as lightweight V2X protocols including LwM2M protocols, mqtt protocols, and the like. A lightweight protocol can reduce node-side resource consumption. In some embodiments, functional nodes 502, such as RSU 250, roadside computing unit 242, and/or edge computing device 272, support network communications, and thus access protocol stack 552 is based on the Hypertext Transfer Protocol (HTTP) protocol. It may be a network protocol stack such as a stack, a hypertext secure transmission (HTTPS) protocol stack, a cellular communication protocol stack.

Management layer 520 relates to device management 530 and configuration management 540 . Device manager 530 includes a connection manager module 532 to function node 502 and a status monitor module 534 . Configuration manager 540 includes device configuration module 542 and policy configuration module 544 of function node 502 . Control layer 510 is used to control message collection module 512 , message delivery module 514 and message transfer module 516 of service node 501 .

Specific functions of each layer of the service node 501 will be described in detail below together with interaction with the function node 502 .

FIG. 6 shows a signaling map 600 between service nodes 501 and function nodes 502 according to some embodiments of the present disclosure. In the embodiment of FIG. 6, the service node 501 is one of the roadside service node 212, the RSU service node 214, and the edge service node 216, and the function nodes 502 are the RSU 250, the roadside computing unit 242, and the edge computing device 272. can be either

At 610 , service node 501 provides access to function node 502 based on the access protocol supported by function node 502 . Function node 502 establishes a communication link with service node 501 after accessing service node 501 . In some embodiments, in access provisioning 610, function node 502 may send an access request to service node 501 based on the corresponding access protocol. Access protocol stack 552 within access layer 550 of service node 501 processes access requests. In some embodiments, service node 501 may perform a validation to access permissions of function node 502 in response to an access request. This can be realized, for example, by the connection management module 532 within the device management section 530 . In response to the access authorization being verified, service node 501 can provide access to function node 502 . This allows the function node 502 to connect to and communicate with the service node 501 .

At 620, service node 501 transmits configuration information for the function node to function node 502 based on the access provided. Provision of the configuration information can be realized by the configuration management unit 540 of the service node 501, for example.

In some embodiments, device configuration module 542 within configuration manager 540 sends first configuration information (also called device configuration information) to function node 502 to configure communication and/or computational resources of function node 502 . called). For example, if function node 502 includes RSU 250 , the first configuration information can be used to configure RSU 250 transmit power and control RSU 250 communication range. If the functional node 502 includes a roadside computing unit 242 or an edge computing device 272, the first configuration information may allocate computing resources, e.g. pre-reserve some of the computing resources for subsequent computations. can be done.

In some embodiments, policy configuration module 544 within configuration manager 540 sends second configuration information (also referred to as policy configuration information) to function node 502 to configure message interaction policies for function node 502 . can be configured to Message interaction policies may include message collection policies, message delivery policies, and message transfer policies for function nodes 502 of service nodes 501 . For example, for message collection and message delivery, the second configuration information may configure message collection and/or delivery start time, sampling interval, data type, priority transmission, transmission frequency, and the like. In the case of message transfer, the second configuration information can set the expiration date of the message to be transferred, the start time of transmission, the repetition cycle within the transmission time, the frequency of transmission, and the like.

In some embodiments, after the function node 502 receives the configuration information, it can configure itself using the configuration information and also return feedback information to the service node 501 .

At 630, the service node 501 can control message interactions with the function node 502 based on the configuration information to cause the OBU to control the operation of the vehicle 130. FIG. Message interactions between service nodes 501 and function nodes 502 may include message collection, message delivery, and message forwarding. Message collection refers to the service node 501 receiving messages from one or more function nodes 502 and the function nodes 502 reporting messages to the service node 501 according to the message collection policy. Message delivery refers to the delivery of messages by service nodes 501 to function nodes 502 and can be controlled by message delivery policies. Message forwarding means that service node 501 performs message forwarding between function nodes when two function nodes 502 need to communicate. Message forwarding can be controlled by a message forwarding policy. The message interaction process between service node 501 and function node 502 is described in detail below.

In some possible embodiments, at 640 the service node 501 further checks the status of the function node 502 to detect whether the function node 502 is online, offline, faulty, or otherwise. perform monitoring; Status monitoring may be performed by status monitoring module 534 within service node 501 . In the status monitoring process, function node 502 can periodically report its status to service node 501 . The service node 501 can update the local state information corresponding to the function node 502 based on the received status reports to record the latest status of the function node 502 . In some embodiments, function node 502 may transmit status reports to service node 501 in response to update requests from service node 501 . For example, if a service node 501 has not received a status report from a function node 502 for an extended period of time (e.g., exceeding a certain time threshold), the service node 501 sends an update request to Status reports can be actively detected.

The message interaction process between service node 501 and function node 502 is described below with reference to FIGS. 7A and 7B, which message interaction process directs OBU 132 to support operational control of vehicle 130 on which OBU 132 is mounted. is also involved. Differences in message interaction processes relate to OBU 132 communication capabilities.

In the signaling map 701 shown in FIG. 7A, function node 502-1 is, for example, the roadside computing unit 242 or edge computing device 272 that provides computing functions, and function node 502-2 is, for example, the RSU 250 that provides communication functions. is. Function nodes 502 - 1 and 502 - 2 may be included in roadside subsystem 220 or edge computation subsystem 230 . Accordingly, service node 501 may include roadside computing unit 242 or edge computing device 272 . In this example, OBU 132 has a communication connection with function node 502-2. Such communication connections may be, for example, V2X communication connections.

At 710, function node 502-1 transmits a driving-related message for vehicle 130 to service node 501 (also referred to herein as a "first driving-related message" for convenience of explanation). The first driving-related message may be at least one of a sensing message, a decision planning message, and/or a control message for vehicle 130 established by function node 502-1. A first driving-related message is determined by function node 502 based on the sensing information of sensing device 260 in subsystem 220 or 230 .

After receiving the first driving-related message from function node 502-1, at 720 service node 501 determines another driving-related message for vehicle 130 by processing the first driving-related message (description (also referred to herein as a "second driving-related message"). The second driving-related message can be different than the first driving-related message and can include at least one of a sensing message, a decision planning message, and/or a control message for vehicle 130 . For example, the first driving-related message may be a sensing message for vehicle 130, and the second driving-related message is a decision planning message for vehicle 130 determined based on the sensing message and/or It may be a control message. As another example, the first driving-related message may be a driving planning message and the second driving-related message may be a control message for vehicle 130 . In such an example, service node 501 provides additional computing power.

In some embodiments, service node 501 receives driving-related messages for another vehicle 130 (also referred to herein as a “third driving-related message” for convenience of explanation) from another function node 502 . You can also The service node 501 can process the first driving-related message and the third driving-related message to determine the first driving-related message. Having more driving-related information, the service node 501 can implement more customized services based on such global information. This can be accomplished, for example, by a separate service module within service node 501 . For example, based on messages from multiple function nodes, the service node 501 can provide global information such as overall traffic congestion status in a specific area, road traffic flow notifications, lane adjustment status, traffic light reminders, road abnormality status, road construction status, etc. Traffic conditions can be determined. Accordingly, the service node 501 can determine whether to adjust the travel route and/or the particular driving maneuver of the particular vehicle 130 and generate a second driving-related message based thereon.

At 730 , service node 501 provides a second driving-related message to function node 502 - 1 , eg, roadside computation unit 242 in roadside subsystem 220 or edge computation unit 272 in edge computation subsystem 230 . At 740, function node 502-1 transmits a second driving-related message to function node 502-2, which may be implemented within a local area network of subsystems 220 or 230, for example. At 750 , function node 502 - 2 , eg, RSU 250 , transmits a second operational-related message to OBU 132 . In one embodiment, function node 502 - 2 may broadcast a second driving-related message to OBU 132 . Upon receiving the second driving-related message, OBU 132 may perform driving control of vehicle 130 according to the second driving-related message.

In the embodiment shown in FIG. 7B, OBU 132 is assumed to have a communication connection with service node 501 . In such an embodiment, the OBU 132 may have network capabilities, for example, the OBU 132 may access the Internet by way of an application in the user terminal or in-vehicle central control platform or the like, thereby communicating with the service node 501. Get a connection. In signaling map 702 of FIG. 7B, the operations at 710 and 720 are similar to signaling map 701 . After service node 501 determines the second driving-related message, it can transmit the second driving-related message to OBU 132 via a communication connection with OBU 132 .

In some embodiments, driving control for vehicle 130 may be implemented within roadside subsystem 220 and/or edge computation subsystem 230 in addition to interacting with service node 501 . Driving-related messages determined by roadside computing unit 242 and/or edge computing unit 272 may be provided directly to OBU 132 via RSU 250 . OBU 132 may further process the received driving-related messages or control vehicle 130 directly based on the messages. Such typical application scenarios include cooperative sensing, semantic level sensing result sharing, and so on. Cooperative sensing is the sharing of global information sensed by roadside subsystem 220 with vehicles to supplement vehicle sensing. Semantic level sensing result sharing means that the roadside subsystem sensed results are semantically identified and shared with vehicles. is shared.

Docking example with 3rd platform

In some embodiments, the driving control system 110 according to embodiments of the present disclosure can also be docked to third party platforms. Such an embodiment is shown in FIG. As shown in FIG. 8, the central platform subsystem 210 of the operational control system 110 further includes a third party docking service node 818 for docking to a third party service platform 880 . Third party service platform 880 may include one or more third party service terminals 882-1, . be called). Each third party service terminal 882 can provide a corresponding third party service, such as map services, navigation services, traffic monitoring services, and the like. Third party docking service node 818 is configured to control, manage and message interact with third party service terminal 882 . The structure of third party docking service node 818 may be similar to service node 501 shown in FIG. Central platform subsystem 210 can provide data support to third party platform 880, making interaction between third party platform 880 and vehicle 130 more flexible and convenient.

In some embodiments, OBU 132 may have network capabilities and may communicate with third party platform 880 . For example, one or more OBUs 132 can be installed with third party applications 830-1, . for convenience, collectively or singly referred to as third party applications 830). OBU 132 may communicate with third party platform 880 via third party application 830 .

FIG. 9A shows a signaling map 901 in an embodiment with communication connections between OBU 132 and third party platform 880. FIG. Signaling map 901 has actions 710 and 720 in signaling maps 701 and 702, and service node 501 performs a second operation for vehicle 130 based on the first driving-related message from function node 502-1. Confirm driving-related messages. Service node 501 preferably provides the second driving-related message to OBU 132 on corresponding vehicle 130 . In the embodiment of FIG. 9A, provision of such messages may be implemented via third party platform 880, specifically third party service terminal 882 within the third party platform. As shown in FIG. 9A , at 910 service node 501 transmits a second driving-related message to third party service terminal 882 . Service node 501 can communicate with third party service terminal 882 via a wired or wireless network. Upon receiving the second driving-related message, at 920 third party service terminal 882 forwards the second driving-related message to OBU 132 via a corresponding communication connection. This will allow third-party platforms to provide more flexible driving assistance.

As a specific example, taking the traffic light reminder function as an example, the first driving-related message uploaded by function node 502-1 includes traffic light conditions in the geographic region or driving route in which vehicle 130 is located. The service node 501 provides the traffic light status related information as a second driving related message to the third party service terminal 882 after performing no processing or corresponding message conversion. Third party service terminal 882 can then provide traffic light status to OBU 132 . For example, third party service terminal 882 may provide a map service to push traffic light status information onto a map application installed on OBU 132 . A map application can display real-time traffic light conditions in a corresponding geographic area or route.

In some other embodiments, there is no communication connection between third party platform 880 and OBU 132 . In this case, third party platform 880 , eg, third party service terminal 882 , may also provide driving-related messages to OBU 132 via driving control system 110 . Such an embodiment is shown in Figures 9B and 9C.

In signaling map 902 shown in FIG. 9B, OBU 132 has a communication connection with function node 502-2 (eg, RSU 250). At 930 , service node 501 receives driving-related messages (also referred to as “fourth driving-related messages” for convenience of explanation) of third-party service terminal 882 for vehicle 130 . A fourth driving-related message may, for example, include information related to the sensing message, but may be generated by the third party platform 880 rather than determined by the sensing information of the sensing device. In some examples, the fourth driving-related message may include information regarding the traversable state of the road, such as, for example, a temporary road closure notification by a traffic management agency. A fourth driving-related message may also include temporary adjustments to road speed limits, emergency broadcasts, and the like.

At 940, service node 501 may forward a fourth operational-related message to function node 502-2 of subsystem 220 or 230 (eg, RSU 250). The selection of function node 502-2 may relate to the geographic location where vehicle 130 is located such that OBU 132 on vehicle 130 is within communication range of function node 502-2. Function node 502-2 forwards the fourth driving-related message to OBU 132 at 950, and OBU 132 may perform corresponding driving control, such as adjusting the route, based on the fourth driving-related message.

In signaling map 903 shown in FIG. 9C , OBU 132 has a network communication connection with service node 501 . At 930 , service node 501 receives the fourth driving-related message of third-party service terminal 882 for vehicle 130 and at 960 transmits the fourth driving-related message to OBU 132 via a communication connection with OBU 132 . can be transferred.

process illustration

FIG. 10 illustrates a flow chart of an operational control method 1000 according to an embodiment of the present disclosure. Method 1000 is implemented in service node 501 of FIG. can be done. It should be understood that although shown in a particular order, some steps in method 1000 may be performed in a different order than shown or in parallel. Embodiments of the present disclosure are not so limited.

At block 1010, the service node 501 provides access to the function node based on the access protocol that the function node supports, the function node providing the ability to communicate with the vehicle's on-board unit OBU or to compute information related to the vehicle. configured to At block 1020, service node 501 transmits configuration information for the function node to the function node based on the access. At block 1030, service node 501 controls message interactions with function nodes based on the configuration information to control operation of the vehicle via OBU.

In some embodiments, the functional node includes at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide computing functionality.

In some embodiments, the function node includes a roadside unit RSU configured to provide communication functions. In some embodiments, the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform, and the RSU is a combination of at least one of the roadside computing unit and the edge computing device and an OBU. configured to provide communication between

In some embodiments, the function node selects a vehicle based on at least one of a communication range supported by the function node, a computing power of the function node, and a sensing range supported by a sensing device associated with the function node. is placed in an environment in which the sensor is placed, and the functional node is configured to process sensory information from the sensing device.

In some embodiments, providing access includes receiving an access request from the function node based on an access protocol supported by the function node and, in response to the access request, verifying permission to access the function node. and providing access in response to the access permission being verified.

In some embodiments, process 1000 includes receiving status reports from function nodes, either periodically or in response to service node update requests, and based on the status reports, generating local status information corresponding to the function nodes. and updating.

In some embodiments, transmitting configuration information for the function node includes transmitting first configuration information for the function node to configure at least one of communication resources and computational resources of the function node. and transmitting second configuration information for the function node to configure a message interaction policy for the function node.

In some embodiments, controlling message interaction with the function node includes receiving a first driving-related message for the vehicle from the function node; processing the first driving-related message; Determining a second driving-related message for the vehicle that is different from the first driving-related message.

In some embodiments, controlling message interaction with the function node may include the function node sending a second operation-related message to the OBU via a communication connection between the function node and the OBU to control operation of the vehicle. further comprising being adapted to transmit to. In some embodiments, process 1000 further includes transmitting a second operational-related message to the OBU via a communication connection between the service node and the OBU. In some embodiments, process 1000 further includes transmitting a second driving-related message to the OBU via a communication connection between the third party platform and the OBU.

In some embodiments, determining the second driving-related message includes receiving a third driving-related message for another vehicle from another functional node; and determining a second driving-related message by processing the 3 driving-related messages.

In some embodiments, the service node has a communication connection with the OBU, and process 1000 receives a fourth driving-related message for the vehicle from the third party platform via the communication connection with the third party platform. and providing a fourth driving-related message to the OBU.

In some embodiments, the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node, the at least one sensing device located in the vehicle's local environment. It is

Diagram 1100 depicts a flow chart of an operational control method 1100 in accordance with an embodiment of the present disclosure. Method 1100 may be implemented in functional node 502 of FIG. 5 , which may be RSU 250 , roadside computing unit 242 , or edge computing device 272 within maneuver control system 110 . It should be noted that although shown in a particular order, some steps in method 1100 can be performed in a different order than shown or in parallel. Embodiments of the present disclosure are not so limited.

At block 1110, the function node 502 obtains access to the service node based on the access protocol it supports, the function node providing the ability to communicate with the vehicle's on-board unit OBU or to compute information related to the vehicle. configured to At block 1120, the function node 502 receives configuration information for the function node from the service node based on the access. At block 1130, the function node 502 performs message interactions with the service node based on the configuration information to cause operational control of the vehicle via the OBU.

In some embodiments, the functional node includes at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide computing functionality.

In some embodiments, the function node includes a roadside unit RSU configured to provide communication functions. In some embodiments, the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform, and the RSU is a combination of at least one of the roadside computing unit and the edge computing device and an OBU. configured to provide communication between

In some embodiments, the function node selects a vehicle based on at least one of a communication range supported by the function node, a computing power of the function node, and a sensing range supported by a sensing device associated with the function node. is placed in an environment in which the sensor is placed, and the functional node is configured to process sensory information from the sensing device.

In some embodiments, obtaining access comprises transmitting an access request to the service node based on an access protocol supported by the function node and verifying that permission to access the function node has been verified by the service node. responding and obtaining access.

In some embodiments, the process 1100 periodically or in response to an update request from a service node to update the local state information maintained by the service node and corresponding to the function node. to the service node.

In some embodiments, receiving configuration information for the function node includes receiving first configuration information for the function node to configure at least one of communication resources and computational resources of the function node. and/or receiving second configuration information for the function node to configure a message interaction policy for the function node.

In some embodiments, performing a message interaction with the service node includes transmitting a first driving-related message for the vehicle to the service node.

In some embodiments, the function node has a communication connection with the OBU and performs message interactions with the service node to receive a first driving-related message and a third message for another vehicle by the service node. receiving from the service node a second driving-related message for the vehicle, determined based on the driving-related message of the vehicle; and forwarding the second driving-related message to the OBU via the communication connection. Including further.

In some embodiments, the service node has a communication connection with the OBU and controlling message interaction with the function node includes obtaining a fourth driving-related message for the vehicle from the service node. , a fourth driving-related message is provided by a third-party platform.

In some embodiments, the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node, the at least one sensing device located in the vehicle's local environment. It is

Examples of devices and equipment

FIG. 12 shows a schematic block diagram of an apparatus 1200 for operational control according to an embodiment of the present disclosure. The device 1200 may be included in the roadside subsystem 112 of FIGS. 1 and 2 or may be implemented as the roadside subsystem 112 . As shown in FIG. 12, the apparatus 1200 includes an access module 1210 configured in the service node to provide access to the function node based on the access protocol supported by the function node. The function node is arranged to provide functions for communication with the vehicle's on-board unit OBU or for computing information related to the vehicle. Apparatus 1200 further includes a configuration module 1220 configured to transmit configuration information for the functional node to the functional node based on the access. Apparatus 1200 further includes an interaction module 1230 configured to control message interactions with function nodes based on the configuration information to facilitate operational control of the vehicle via the OBU.

In some embodiments, the functional node includes at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide computing functionality.

In some embodiments, the function node includes a roadside unit RSU configured to provide communication functions. In some embodiments, the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform, and the RSU is a combination of at least one of the roadside computing unit and the edge computing device and an OBU. configured to provide communication between

In some embodiments, the function node selects a vehicle based on at least one of a communication range supported by the function node, a computing power of the function node, and a sensing range supported by a sensing device associated with the function node. is placed in an environment in which the sensor is placed, and the functional node is configured to process sensory information from the sensing device.

In some embodiments, access module 1210 includes a request receiving module configured to receive access requests from function nodes based on the access protocol supported by the function nodes; and a verification-based access module configured to provide access in response to the access permission being verified.

In some embodiments, apparatus 1200 includes a report receiving module configured to receive status reports from function nodes periodically or in response to service node update requests; a state update module configured to update local state information corresponding to the .

In some embodiments, the configuration module 1220 is configured to transmit first configuration information for the functional node and configure at least one of communication and computing resources of the functional node; a policy configuration module configured to transmit second configuration information for the function node and configure a message interaction policy for the function node.

In some embodiments, the interaction module 1230 includes a first message receiving module configured to receive a first driving-related message for the vehicle from the functional node and processing the first driving-related message. a first message processing module configured to determine a second driving-related message different from the first driving-related message for the vehicle.

In some embodiments, the interaction module 1230 is further configured to cause the function node to transmit a second driving-related message to the OBU via the communication connection between the function node and the OBU to control driving of the vehicle. be done. In some examples, the apparatus 1200 further includes a first message transmission module configured to transmit the second driving-related message to the OBU via the communication connection between the service node and the OBU. In some embodiments, apparatus 1200 further includes a second message transmission module configured to transmit a second driving-related message to the OBU via the communication connection between the third party platform and the OBU.

In some embodiments, the message processing module comprises a second message receiving module configured to receive third driving-related messages for other vehicles from other functional nodes; a second message processing module configured to determine a second driving-related message by processing the message and a third driving-related message.

In some embodiments, the service node has a communication connection with the OBU and the device 1200 receives fourth driving-related messages for the vehicle from the third party platform via the communication connection with the third party platform. Further includes a third message receiving module configured to receive and a message providing module configured to provide a fourth driving-related message to the OBU.

In some embodiments, the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node, the at least one sensing device located in the vehicle's local environment. It is

FIG. 13 shows a schematic block diagram of an apparatus 1300 for operational control according to an embodiment of the present disclosure. Apparatus 1300 may be included in onboard subsystem 132 of FIGS. 1 and 2 or may be implemented as onboard subsystem 132 . As shown in FIG. 13, the apparatus 1300 is an access module 13 1 0 configured in a function node to obtain access to a service node based on an access protocol supported by the function node, wherein the function node is It comprises an access module 13 1 0 which is arranged to provide communication functions with the vehicle's on-board unit OBU or calculation functions of vehicle-related information. Apparatus 1300 further includes a configuration module 1320 configured to receive configuration information for the functional node from the service node based on the access. Apparatus 1300 also further includes an interaction module 1330 configured to perform message interaction with the service node based on the configuration information to control operation of the vehicle via OBU.

In some embodiments, the functional node includes at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide computing functionality.

In some embodiments, the function node includes a roadside unit RSU configured to provide communication functions. In some embodiments, the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform, and the RSU is a combination of at least one of the roadside computing unit and the edge computing device and an OBU. configured to provide communication between

In some embodiments, the function node selects a vehicle based on at least one of a communication range supported by the function node, a computing power of the function node, and a sensing range supported by a sensing device associated with the function node. is placed in an environment in which the sensor is placed, and the functional node is configured to process sensory information from the sensing device.

In some embodiments, the access module 1320 includes a request transmission module configured to transmit an access request to the service node based on an access protocol supported by the function node, and a request transmission module configured to transmit the access request to the function node based on the access protocol supported by the function node. a verification module configured to obtain access in response to being verified.

In some embodiments, the apparatus 1300 periodically or in response to an update request from a service node to update the local state information maintained by the service node and corresponding to the function node. to the service node.

In some embodiments, the configuration module 1320 is a device configuration module configured to receive first configuration information for the function node and configure at least one of communication resources and computational resources of the function node. , and a policy configuration module configured to receive second configuration information for the function node and configure a message interaction policy for the function node.

In some embodiments, interaction module 1330 includes a message transmission module configured to transmit a first driving-related message for the vehicle to the service node.

In some embodiments, the function node has a communication connection with the OBU, and the interaction module receives from the service node based on the first driving-related message and the third driving-related message for another vehicle: a message receiving module configured to receive a second driving-related message for the vehicle established by the service node; and a message receiving module configured to forward the second driving-related message to the OBU via the communication connection. and a message transfer module.

In some embodiments, the service node has a communication connection with the OBU and the interaction module is configured to obtain from the service node a fourth driving-related message for the vehicle provided by the third party platform. including a message acquisition module configured in

In some embodiments, the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node, the at least one sensing device located in the vehicle's local environment. It is

FIG. 14 shows a schematic block diagram of an exemplary apparatus 1400 that can be used to implement embodiments of the present disclosure. Apparatus 1400 may be used to implement service node 501 or function node 502 of FIG. As shown, apparatus 1400 can perform various suitable operations by means of computer program instructions stored in read only memory (ROM) 1402 or loaded into random access memory (RAM) 1403 from storage unit 1408 . and a computing unit 1401 that can perform processing. RAM 1403 may further store various programs and data necessary for operation of device 1400 . Calculation unit 1401 , ROM 1402 and RAM 1403 are connected to each other via bus 1404 . Input/output (I/O) interface 1405 is also connected to bus 1404 .

In device 1400 there are input units 1406 such as keyboards, mice, etc., output units 1407 such as various types of displays, speakers etc., storage units 1408 such as magnetic disks, optical disks etc., network cards, modems, wireless communication transceivers etc. A number of components are connected to the I/O interface 1405 , including the communication unit 1409 . Communications unit 1409 enables device 1400 to exchange information or data with other devices over computer networks such as the Internet and/or various telecommunications networks.

Computing unit 1401 may be various general purpose and/or special purpose processing components having processing and computing capabilities. Some examples of computational units 1401 are central processing units (CPUs), graphics processing units (GPUs), various dedicated artificial intelligence (AI) computational chips, various computational units that run machine learning model algorithms, digital signal including, but not limited to, processors (DSPs), and any suitable processors, controllers, microcontrollers, and the like. Computing unit 1401 performs various methods and operations such as process 1000 or process 1100 described above. For example, in some embodiments process 1000 or process 1100 may be implemented as a computer software program tangibly contained in a machine-readable medium such as storage unit 1408 . In some embodiments, part or all of the computer program may be loaded and/or installed on device 1400 via ROM 802 and/or communication unit 1409 . A computer program, when loaded into RAM 1403 and executed by computing unit 1401, may perform one or more steps of process 1000 or process 1100 described above. Alternatively, in other embodiments, computing unit 1401 may be configured to perform process 1000 or process 1100 by any other suitable means (eg, by firmware).

The functions described herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, general-purpose hardware logic components that can be employed include Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), System on Chips (SOCs), ), Complex Programmable Logic Devices (CPLDs), and the like.

Program code to implement the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, and when executed by the processor or controller, the flowcharts and/or Alternatively, the functions or operations specified in the block diagrams may be performed. The program code may run entirely on the device, partially on the device, or partially on the device and partially on the remote device as a stand-alone software package. or can be run entirely on a remote device or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium and includes a program for use by or in conjunction with an instruction execution system, apparatus or device. or can be stored. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus or devices, or any suitable combination thereof. More specific examples of machine-readable storage media include electrical connections based on one or more cables, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable Read only memory (EPROM or flash memory), optical fiber, compact disc read only memory (CD-ROM), optical storage, magnetic storage, or any suitable combination thereof may be included.

Also, although each action is presented in a particular order, it is not required that such actions be performed in the specific order presented or in sequence to achieve the desired result. , or should be understood to require that all actions shown in the figure be performed. Multitasking and parallelism can be advantageous in certain environments. Similarly, although some specific implementation details have been set forth above, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subset.

Although the subject matter has been described in language specific to structural features and/or methodological logic acts, subject matter defined in the claims is not necessarily limited to the specific features or acts described above. It should be understood that the Rather, the specific features and acts described above are merely exemplary forms of implementing the claims.

Claims (52)

providing, in a service node, access to said function node based on an access protocol supported by said function node, said function node communicating with an on-board unit (OBU) of a vehicle or providing information relating to said vehicle; a step configured to provide a computational function;
transmitting configuration information for the function node to the function node based on the access;
and controlling message interactions with said function nodes based on said configuration information to control operation of said vehicle via said OBU. 2. The method of claim 1, wherein the function node comprises at least one of a roadside computation unit and an edge computation device, each of the roadside computation unit and the edge computation device being configured to provide the computation function. said function node includes a roadside unit (RSU) configured to provide said communication function;
the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform;
the RSU is configured to provide communication between the OBU and at least one of the roadside computing unit and the edge computing device;
The method of claim 1. The function node is
a communication range supported by the functional node;
computing power of the functional node;
a sensing range supported by a sensing device associated with the function node, wherein the function node is configured to process sensing information from the sensing device;
2. The method of claim 1, deployed in the vehicle's location environment based on at least one of: The step of providing access includes:
receiving an access request from the function node based on an access protocol supported by the function node;
performing verification of access permissions to the function node in response to the access request;
and providing the access in response to verifying the access authorization. The method includes:
receiving status reports from the function nodes, the status reports being received periodically or in response to update requests of the service nodes;
2. The method of claim 1, further comprising updating local state information corresponding to the function node based on the state report. The step of transmitting configuration information for the functional node comprises:
transmitting first configuration information for the function node to configure at least one of communication resources and computational resources of the function node;
transmitting second configuration information for the function node to configure a message interaction policy for the function node;
2. The method of claim 1, comprising at least one of: The step of controlling message interaction with said function node comprises:
receiving a first driving-related message for the vehicle from the function node;
determining a second driving-related message for the vehicle that is different from the first driving-related message by processing the first driving-related message. or the method according to item 1. The step of controlling message interaction with said function node comprises:
further comprising said function node being adapted to transmit said second driving-related message to said OBU via a communication connection between said function node and said OBU for controlling operation of said vehicle;
The method further comprises transmitting the second operation-related message to the OBU via a communication connection between the service node and the OBU; or 9. The method of claim 8, further comprising transmitting said second driving-related message to said OBU via a communication connection. Determining the second driving-related message comprises:
receiving a third driving-related message for another vehicle from another function node;
9. The method of claim 8, comprising determining the second driving-related message by processing the first driving-related message and the third driving-related message. the service node has a communication connection with the OBU;
The method comprises:
receiving a fourth driving-related message for the vehicle from the third party platform via the communication connection with the third party platform;
providing said fourth driving-related message to said OBU. the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node;
9. The method of claim 8, wherein the at least one sensing device is located in the vehicle's local environment. A method for operational control, comprising:
obtaining, in a function node, access to a service node based on an access protocol supported by said function node, said function node communicating with an on-board unit (OBU) of a vehicle or information relating to said vehicle; a step configured to provide a computational function of
receiving configuration information for the function node from the service node based on the access;
performing message interactions with said service node based on said configuration information to control operation of said vehicle via said OBU. 14. The method of claim 13, wherein the functional node comprises at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide the computing function. said function node includes a roadside unit (RSU) configured to provide said communication function;
the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform;
the RSU is configured to provide communication between the OBU and at least one of the roadside computing unit and the edge computing device;
14. The method of claim 13. The function node is
a communication range supported by the functional node;
computing power of the functional node;
a sensing range supported by a sensing device associated with the function node, wherein the function node is configured to process sensing information from the sensing device;
14. The method of claim 13, deployed in the vehicle's location environment based on at least one of: The step of obtaining access includes:
transmitting an access request to the service node based on an access protocol supported by the function node;
14. The method of claim 13, comprising obtaining said access in response to verification by said service node of access authorization to said function node. The method includes:
transmitting a status report to the service node periodically or in response to an update request from the service node to update local status information maintained by the service node and corresponding to the function node; 14. The method of claim 13, further comprising steps. The step of receiving configuration information for the function node comprises:
receiving first configuration information for the function node to configure at least one of communication resources and computational resources of the function node;
receiving second configuration information for the function node to configure a message interaction policy for the function node;
14. The method of claim 13, comprising at least one of: performing a message interaction with the function node comprises:
A method according to any one of claims 13 to 19, comprising transmitting a first driving-related message for said vehicle to said service node. the function node has a communication connection with the OBU;
The step of performing a message interaction with the service node comprises:
receiving from the service node a second driving-related message for the vehicle determined by the service node based on the first driving-related message and a third driving-related message for another vehicle; and
21. The method of claim 20, further comprising forwarding said second driving-related message to said OBU via said communication connection. the service node has a communication connection with the OBU;
The step of controlling message interaction with said function node comprises:
20. The method of any one of claims 13-19, comprising obtaining from the service node a fourth driving-related message for the vehicle provided by the third party platform. the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node;
21. The method of claim 20, wherein the at least one sensing device is located in the vehicle's local environment. In a service node, an access module configured to provide access to said function node based on an access protocol supported by said function node, said function node communicating with an on-board unit (OBU) of a vehicle or said an access module configured to provide computing capabilities for vehicle-related information;
a configuration module configured to transmit configuration information for the function node to the function node based on the access;
an interaction module configured to control message interactions with the functional nodes based on the configuration information to control operation of the vehicle via the OBU. 25. The apparatus of claim 24, wherein the function node comprises at least one of a roadside computation unit and an edge computation device, each of the roadside computation unit and the edge computation device being configured to provide the computation function. said function node includes a roadside unit (RSU) configured to provide said communication function;
the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform;
the RSU is configured to provide communication between the OBU and at least one of the roadside computing unit and the edge computing device;
25. Apparatus according to claim 24. The function node is
a communication range supported by the functional node;
computing power of the functional node;
a sensing range supported by a sensing device associated with the function node, wherein the function node is configured to process sensing information from the sensing device;
25. The device of claim 24, deployed in the vehicle's local environment based on at least one of: The access module includes:
a request receiving module configured to receive an access request from said function node based on an access protocol supported by said function node;
a verification module configured to perform verification of access permissions to said function node in response to said access request;
25. The apparatus of claim 24, comprising a verification-based access module configured to provide said access in response to said access grant being verified. The device comprises:
A report receiving module configured to receive status reports from the function nodes, wherein the status reports are received periodically or in response to update requests of the service nodes. When,
25. The apparatus of claim 24, further comprising a state update module configured to update local state information corresponding to said function node based on said state report. The configuration module includes:
a device configuration module configured to transmit first configuration information for the function node to configure at least one of communication resources and computational resources of the function node;
25. The apparatus of claim 24, comprising at least one of: a policy configuration module configured to transmit second configuration information for the function node to configure a message interaction policy for the function node. The interaction module includes:
a first message receiving module configured to receive a first driving-related message for the vehicle from the function node;
a first message processing module configured to determine a second driving-related message for the vehicle that is different from the first driving-related message by processing the first driving-related message;
A device according to any one of claims 24 to 30, comprising a The interaction module includes:
wherein the function node is configured to transmit the second driving-related message to the OBU via a communication connection between the function node and the OBU to control operation of the vehicle;
The apparatus further comprises a first message transmission module configured to transmit the second driving-related message to the OBU via a communication connection between the service node and the OBU, or 32. The second message transmission module of claim 31, further comprising a second message transmission module configured to transmit the second driving-related message to the OBU via a communication connection between a third party platform and the OBU. Device. The message processing module includes:
a second message receiving module configured to receive third driving-related messages for other vehicles from other function nodes;
and a second message processing module configured to determine the second driving-related message by processing the first driving-related message and the third driving-related message. Apparatus as described. the service node has a communication connection with the OBU;
The device comprises:
a third message receiving module configured to receive a fourth driving-related message for the vehicle from the third party platform via the communication connection with the third party platform;
and a message providing module configured to provide said fourth driving-related message to said OBU. the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node;
32. The apparatus of claim 31, wherein the at least one sensing device is located in the vehicle's local environment. A device for operation control,
an access module in a function node configured to obtain access to a service node based on an access protocol supported by said function node, said function node having a communication function with an on-board unit (OBU) of a vehicle; an access module configured to provide computing functionality for information related to the vehicle;
a configuration module configured to receive configuration information for the function node from the service node based on the access;
an interaction module configured to perform message interactions with the service node based on the configuration information to control operation of the vehicle via the OBU. 37. The apparatus of claim 36, wherein the functional node comprises at least one of a roadside computing unit and an edge computing device, each of the roadside computing unit and the edge computing device being configured to provide the computing function. said function node includes a roadside unit (RSU) configured to provide said communication function;
the service node is included in at least one of a roadside computing unit, an edge computing device, and a central platform;
the RSU is configured to provide communication between the OBU and at least one of the roadside computing unit and the edge computing device;
37. Apparatus according to claim 36. The function node is
a communication range supported by the functional node;
computing power of the functional node;
a sensing range supported by a sensing device associated with the function node, wherein the function node is configured to process sensing information from the sensing device;
37. The device of claim 36, deployed in the vehicle's location environment based on at least one of: The access module includes:
a request transmission module configured to transmit an access request to said service node based on an access protocol supported by said function node;
37. The apparatus of claim 36, comprising a verification module configured to obtain said access in response to said permission to access said function node being verified by said service node. The device comprises:
transmitting a status report to the service node periodically or in response to an update request from the service node to update local status information maintained by the service node and corresponding to the function node; 37. The apparatus of Claim 36, further comprising a report transmission module configured to: The configuration module includes:
a device configuration module configured to receive first configuration information for the function node to configure at least one of communication resources and computational resources of the function node;
and/or a policy configuration module configured to receive second configuration information for the function node to configure a message interaction policy for the function node. The interaction module includes:
Apparatus according to any one of claims 36 to 42, comprising a message transmission module configured to transmit a first driving-related message for said vehicle to said service node. the function node has a communication connection with the OBU;
The interaction module includes:
receiving from the service node a second driving-related message for the vehicle determined by the service node based on the first driving-related message and a third driving-related message for another vehicle; a message receiving module configured to:
44. The apparatus of claim 43, further comprising a message forwarding module configured to forward said second driving-related message to said OBU via said communication connection. the service node has a communication connection with the OBU;
The interaction module includes:
43. A message acquisition module as claimed in any one of claims 36 to 42, comprising a message acquisition module configured to acquire from the service node a fourth driving-related message for the vehicle provided by the third party platform. The apparatus described in . the first driving-related message is determined based on sensory information collected by at least one sensing device associated with the functional node;
44. The apparatus of claim 43, wherein the at least one sensing device is located in the vehicle's local environment. one or more processors;
A storage device for storing one or more programs, wherein when said one or more programs are executed by said one or more processors, said one or more processors are stored in said storage device. 13. A storage device that implements the method according to any one of 12;
electronic equipment. one or more processors;
A storage device for storing one or more programs, wherein when said one or more programs are executed by said one or more processors, said one or more processors store: 24. An electronic device comprising a storage device that implements the method according to claim 23. A computer readable storage medium storing a computer program,
A computer readable storage medium, implementing the method of any one of claims 1 to 12 when said program is executed by a processor. A computer readable storage medium storing a computer program,
A computer readable storage medium, implementing the method of any one of claims 13 to 23 when said program is executed by a processor. An operation control system,
a central platform subsystem comprising an apparatus according to any one of claims 1-12;
A driving control system comprising at least one of a roadside subsystem and an edge calculation subsystem including the device according to any one of claims 13-23. 52. The system of claim 51, wherein at least one of the roadside subsystem and the edge computation subsystem further includes at least one sensing device configured to collect data related to a vehicle's local environment.

Images