CN117459552A - Communication method, device and storage medium based on vehicle cloud integrated architecture - Google Patents
Communication method, device and storage medium based on vehicle cloud integrated architecture Download PDFInfo
- Publication number
- CN117459552A CN117459552A CN202311470862.6A CN202311470862A CN117459552A CN 117459552 A CN117459552 A CN 117459552A CN 202311470862 A CN202311470862 A CN 202311470862A CN 117459552 A CN117459552 A CN 117459552A
- Authority
- CN
- China
- Prior art keywords
- vehicle
- cloud
- gateway
- data
- edge node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000004891 communication Methods 0.000 title claims abstract description 73
- 238000000034 method Methods 0.000 title claims abstract description 53
- 238000013523 data management Methods 0.000 claims abstract description 9
- 230000010354 integration Effects 0.000 claims description 8
- 238000009434 installation Methods 0.000 claims description 6
- 230000004044 response Effects 0.000 claims description 6
- 230000001360 synchronised effect Effects 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 12
- 230000005540 biological transmission Effects 0.000 description 8
- 238000012545 processing Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 5
- 101100491335 Caenorhabditis elegans mat-2 gene Proteins 0.000 description 4
- 102100033121 Transcription factor 21 Human genes 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 101150109289 tcf21 gene Proteins 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000000354 decomposition reaction Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000012827 research and development Methods 0.000 description 2
- 101000957299 Homo sapiens Coronin-7 Proteins 0.000 description 1
- 101000800546 Homo sapiens Transcription factor 21 Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 210000004556 brain Anatomy 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000008602 contraction Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Small-Scale Networks (AREA)
Abstract
The application relates to the field of vehicle cloud communication, and discloses a communication method, a device and a storage medium based on a vehicle cloud integrated architecture, wherein the method comprises the following steps: transmitting a message with the cloud gateway based on a vehicle-end gateway in data connection with the cloud gateway; based on a deployment edge node in data connection with a vehicle-side gateway, deploying a containerized application program, and receiving and responding to a starting command from a cloud end to start the application program; interacting with hardware according to the event center; based on a client side running in the edge node, receiving a cloud service request, interacting with a server running in the edge side, and responding to the cloud service to access the server of the edge side to form a communication channel; creating a membership between an event center and an edge node, and synchronizing the state of hardware equipment to a cloud through the edge node and a vehicle-side gateway; the edge node is connected with the vehicle-end gateway based on the data management service, the information of the vehicle-end gateway is forwarded to the edge node, and the information is cached, so that the communication rate and the service expansibility are improved.
Description
Technical Field
The present disclosure relates to the field of vehicle cloud communication, and in particular, to a communication method, device and storage medium based on a vehicle cloud integrated architecture.
Background
The traditional electronic and electric architecture is a distributed computing architecture, adopts a CAN/LIN bus architecture and distributed hardware, and distributes computing resources inside each ECU in a soft and hard integrated mode, so that the electronic and electric architecture is a signal-oriented architecture.
The current mainstream architecture has a domain centralized controller architecture, which is an SOA architecture. The SOA is Service-Oriented Architecture, namely a Service-oriented architecture, which is a method for designing, developing, deploying and managing discrete models in a computer environment, and network communication of the architecture is a mixed mode of Ethernet and CAN/LIN. The ECU integrates to form a plurality of domain controllers divided by service. Such as a body area, a power area, an entertainment area, etc.
However, the current domain centralized control architecture uses a communication architecture combining CAN and LIN to communicate, the communication rate is slow, and the expansibility is often poor within 1M.
Disclosure of Invention
In order to improve communication speed and service expansibility, the application provides a communication method, device and storage medium based on a vehicle-cloud integrated architecture.
On one hand, the application provides a communication method based on a vehicle-cloud integrated architecture, which adopts the following technical scheme:
a communication method based on a vehicle cloud integrated architecture, the method being applied to a vehicle end and comprising the steps of:
transmitting a message with a cloud gateway based on a vehicle-end gateway in data connection with the cloud gateway;
deploying a containerized application program based on a deployment edge node in data connection with the vehicle-side gateway, wherein the application program receives a starting command from the cloud and responds to the starting command to start;
interacting with hardware according to the event center;
based on a client side running in the edge node, receiving a request from the cloud service, interacting with a server running in the edge side, and forming a communication channel in response to the cloud service accessing the server of the edge side through a set protocol;
creating membership between the event center and the edge node, and synchronizing the equipment state of the hardware to a cloud through the edge node and the vehicle-side gateway;
and connecting the edge node with the vehicle-side gateway based on a data management service, forwarding the message of the vehicle-side gateway to the edge node, and caching the message.
By adopting the technical scheme, the vehicle end and the cloud end are connected, so that a message transmission channel is formed between the vehicle and the cloud end; deploying edge nodes and applications: and deploying the containerized application program by using a deployment edge node connected with the vehicle-side gateway. The application programs can receive a starting command from the cloud and start running after receiving the starting command. Event centers interact with hardware: the application may interact with the vehicle hardware based on the event center. For example, when a sensor state of a vehicle changes, the change may trigger an event, and an application program may interact with hardware according to the event to obtain the latest device state. Creating a communication channel: at a client running in an edge node, a request from a cloud service may be received. The client interacts with a server running on the edge, and responds to the request of the cloud service. And accessing the server at the edge end by setting a protocol so as to form a communication channel. Synchronizing device states: and creating a membership between the event center and the edge node, and synchronizing the state information of the hardware equipment to the cloud through the edge node and the vehicle-side gateway. Thus, the cloud end can acquire the state information of the vehicle hardware in real time. The data management service connects the edge node and the vehicle-side gateway: and connecting the edge node with the vehicle-side gateway through a data management service. In this way, the message of the head-end gateway can be forwarded to the edge node and cached. The method can realize collaborative development, calculation, program deployment and data synchronization of the two ends of the vehicle cloud; and the communication rate and the expansibility of the service are improved.
Optionally, the step of deploying an edge node module further includes the following sub-steps:
registering the first set of containers on a registration configuration center;
acquiring an IP address and a service address of a second container group registered in the registration configuration center by a cloud; and establishing a calling relation between the first container group and the second container group through the IP address and the service address.
By adopting the technical scheme, the load balancing and fault tolerance processing of the service are realized.
Optionally, the method further comprises the sub-steps of:
defining a trunk network message and a branch network message at a vehicle end;
and the trunk network messages are transmitted among the application programs of the vehicle terminals by using Ethernet, and the branch network messages are transmitted among the hardware of the vehicle terminals by using field buses.
By adopting the technical scheme, the data communication of the vehicle can be managed and optimized more effectively by defining the trunk network message and the branch network message and transmitting the messages between the application program and the hardware of the vehicle by using different communication protocols. This approach also helps to improve the interoperability between the various parts of the vehicle, thereby improving the overall performance and safety of the vehicle.
Optionally, the method further comprises the sub-steps of:
if the current residual bandwidth of the Ethernet is smaller than the current residual bandwidth of the field bus;
the backbone network message is transmitted between the application programs of the vehicle end by using the field bus, and the branch network message is transmitted between the hardware of the vehicle end by using the Ethernet.
By adopting the technical scheme, the dynamic adjustment can better utilize the resources of two communication protocols, and ensure that the data communication of the vehicle can be efficiently carried out under various conditions. At the same time, this flexibility also helps to increase the adaptability and scalability of the vehicle for further upgrades or expansion in the future.
Optionally, the method further comprises the sub-steps of:
defining a trunk network message and a branch network message at a vehicle end;
transmitting the backbone network message using ethernet and the branch network message using fieldbus;
decomposing an application program into the backbone network data and the branch network data according to the storage space size of the application program to be transmitted;
the ratio of the main network data to the branch network data is adapted to the ratio of the current residual bandwidth of the Ethernet to the current residual bandwidth of the field bus;
and sending the backbone network data to the Ethernet as the backbone network message, and sending the branch network data to the field bus as the branch network message.
By adopting the technical scheme, the resources of the two communication protocols can be better utilized, and the data transmission can be dynamically adjusted according to the actual requirements. This flexibility helps to improve the interoperability between the various parts of the vehicle, thereby improving the overall performance and safety of the vehicle. At the same time, this strategy also helps ensure that data communication of the vehicle is performed efficiently under a variety of conditions.
Optionally, the method further comprises the sub-steps of:
defining a trunk network message and a branch network message at a vehicle end;
transmitting the backbone network message using ethernet and the branch network message using fieldbus;
decomposing an application program into the backbone network data and the branch network data according to the built-in component quantity of the application program required to be transmitted; the backbone network data are the data of the built-in components with the preset number in the installation sequence, and the data of the rest built-in components in the branch network data installation sequence;
and sending the backbone network data to the Ethernet as the backbone network message, and sending the branch network data to the field bus as the branch network message.
By adopting the technical scheme, the data transmission requirements of the application program can be better met based on the decomposition and transmission modes of the number of the built-in components of the application program, and the resource utilization of different communication protocols is optimized. In actual operation, the value of the set number can be adjusted according to the need to adapt to different application programs and vehicle environments. The decomposition and transmission mode can ensure the data integrity and improve the efficiency and the flexibility of data transmission. Therefore, the communication method based on the vehicle-cloud integrated architecture has high efficiency and reliability when processing a large amount of data, and can be flexibly adjusted according to actual requirements.
On the other hand, the application provides a communication method based on a vehicle-cloud integrated architecture, which adopts the following technical scheme:
a communication method based on a vehicle cloud integrated architecture, the method being applied to a cloud and comprising the steps of:
based on a cloud gateway in data connection with a vehicle-end gateway, transmitting data with the vehicle-end gateway, and acquiring a message and equipment state of the vehicle-end gateway;
registering a cloud program on an application server;
arranging and rewriting the cloud program;
and generating an instruction for controlling hardware on the vehicle side or reading data of the hardware on the vehicle side based on the cloud program.
On the other hand, the application provides a communication device based on a vehicle cloud integrated architecture, which adopts the following technical scheme:
communication device based on car cloud integration framework includes following module:
the vehicle-end gateway is in data connection with the cloud gateway and is used for transmitting messages with the cloud gateway;
the edge node is in data connection with the vehicle-side gateway and is used for deploying a containerized application program, the application program receives a starting command from the cloud and is started in response to the starting command;
an event center for interacting with hardware;
the service center is a client side running in the edge node and is used for receiving a request from the cloud service, interacting with a server running in the edge side and accessing a communication channel of the server of the edge side through a set protocol as the cloud service; the server of the edge end is not connected with the vehicle-end gateway in a data way;
the equipment twin service is in data connection with the event center, a membership is created between the event center and the edge node, and the equipment state of the hardware is synchronized with the vehicle-side gateway to the cloud through the edge node;
and the data management service is used for connecting the edge node with the vehicle-end gateway, forwarding the information of the vehicle-end gateway to the edge node and caching the information.
On the other hand, the application provides a communication device based on a vehicle cloud integrated architecture, which adopts the following technical scheme:
communication device based on car cloud integration framework includes following module:
the cloud gateway is in data connection with the vehicle-end gateway and is used for transmitting data interacted between the vehicle-end and the cloud;
the application server is used for registering cloud programs;
the core controller is in data connection with the application server and the cloud gateway and is used for programming and rewriting the cloud program;
and the equipment controller is in data connection with the cloud gateway and is used for generating an instruction for controlling hardware on the vehicle end or reading the data of the hardware on the vehicle end based on the cloud program.
In another aspect, the present application provides a storage medium, which adopts the following technical scheme:
a storage medium storing a program of the communication method based on the vehicle-cloud integrated architecture described in any one of the above.
In summary, the present application includes at least one of the following beneficial technical effects:
1. collaborative development, calculation, program deployment and data synchronization of the two ends of the vehicle cloud are realized;
2. the vehicle end uses a micro-service architecture and uses a containerized architecture to deploy the application program;
3. the existing mature technology of the Internet is reused, so that the realization difficulty of basic capability is reduced, the research and development efficiency is higher and more stable;
4. the operation and maintenance are simple, and the deployment and online upgrade are flexible;
5. the vehicle-end software has flexible elastic expansion capability;
6. the method is not only suitable for unmanned vehicles, but also is widely suitable for other vehicles such as passenger vehicles, commercial vehicles and the like.
Drawings
FIG. 1 is a structural diagram of the vehicle cloud integrated architecture of the present application;
fig. 2 is a step diagram of a communication method based on a vehicle-cloud integrated architecture and applied to a vehicle end;
fig. 3 is a step diagram of deploying an edge node module in a communication method based on a vehicle-cloud integrated architecture;
FIG. 4 is a schematic diagram showing a sub-step of a communication method based on a vehicle-cloud integrated architecture according to the present application;
FIG. 5 is a diagram of another sub-step in a communication method based on a vehicle-cloud integrated architecture according to the present application;
FIG. 6 is a diagram of another sub-step in a communication method based on a vehicle-cloud integrated architecture according to the present application;
FIG. 7 is a diagram of another sub-step in a communication method based on a vehicle-cloud integrated architecture according to the present application;
fig. 8 is a step diagram of a communication method based on a vehicle-cloud integrated architecture, applied to a cloud;
FIG. 9 is a communication diagram of a vehicle side service and a cloud side service;
FIG. 10 is a step diagram of deployment and update of a vehicle end program;
FIG. 11 is a diagram of one of the central computing architectures employing micro services in the present application;
FIG. 12 is another architecture diagram of a central computing architecture employing micro-services in the present application.
Detailed Description
Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings.
In the description of the present specification, reference to the terms "certain embodiments," "one embodiment," "some embodiments," "an exemplary embodiment," "an example," "a particular example," or "some examples" means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiments or examples. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
The embodiment of the application creates a vehicle-cloud integrated distributed computing platform based on an open source project KubeEdge. KubeEdge is an open platform based on Kubernetes and provides infrastructure support for web applications, as well as deployment and metadata synchronization between cloud and vehicle ends. KubeEdge can extend the native containerized application programming functionality to the vehicle end node, and the implementation is based on Kubernetes implementation.
Among them, kubernetes (K8 s) is a container cluster management system by open source. The method is based on the technology of a device and provides a series of functions such as deployment operation, resource scheduling, service discovery, dynamic expansion and contraction and the like for the containerized application.
KubeEdge is divided into three parts, cloud, edge, end. The cloud is responsible for checksum issuing of applications and configurations, consists of k8s components and CloudCore, and is the central brain of the whole system. The edge is responsible for running applications and managing access equipment, consists of an edge core and a database SQLite, and is a functional node with certain autonomous capability in the system. The end represents the device. All the components and instructions of Kubernetes can be executed in KubeEdge, including kubectllogs, kubectlcreate and deployment, daemonset, statefulset, crd resource objects, and can be used in KubeEdge.
Referring to fig. 1, the vehicle-cloud integrated architecture in this embodiment includes two parts, namely a cloud end and a vehicle end, and a cloud end module and a vehicle end module of kubeeedge need to be deployed respectively.
The embodiment of the application discloses a communication method based on a vehicle cloud integrated architecture, and referring to fig. 2, the method is applied to a vehicle end and comprises the following steps:
transmitting a message with the cloud gateway based on a vehicle-end gateway in data connection with the cloud gateway; the gateway of the vehicle end adopts EdgeHub, edgeHub which corresponds to CloudHub of the cloud, is a gateway for transmitting the vehicle end information, and is the information transmission and routing of the service vehicle end part.
Based on a deployment edge node in data connection with a vehicle-side gateway, deploying a containerized application program, receiving a starting command from a cloud, and responding to the starting command to start; edge nodes employ edge d, a containerized environment, in kubeeedge, edge d. Edge is an edge node module that manages the pod lifecycle. It deploys the containerized workload or application at the edge node (domain control). These workloads may perform any operation, from simple telemetry data operations to analytics or ML reasoning, and so on. Using the kubectl command line interface of the cloud, a user can issue a command to launch a workload. Pod consists of one or more tightly coupled containers that share network, storage, etc. resources between them, which is the smallest unit of deployment in Kubernetes, which is a collection of containers that share network and storage resources.
Interacting with hardware according to the event center; the event center-EventBus, eventBus is used to interact with specific devices, such as an ECU. All data on the vehicle end domain control and interacted with the ECU pass through EventBus.
Based on the client side running in the edge node, a request from the cloud service is received, the server running in the edge node interacts with the cloud service, and a communication channel is formed in response to the cloud service accessing the server of the edge node through a set protocol. Through the service center-ServiceBus, serviceBus is an HTTP client running on the edge, receives a request from cloud service, interacts with an HTTP server running on the edge, and provides the capability of the cloud service to access the HTTP server on the edge through the HTTP protocol.
Creating a membership between an event center and an edge node, and synchronizing the equipment state of hardware to a cloud through the edge node and a vehicle-side gateway; through the devicetain module in KubeEdge, the device state, the processing device attribute, the processing device twinning and other operations are responsible, membership is created between the edge device and the edge node, and the device state is synchronized to the cloud.
And connecting the edge node and the vehicle-end gateway based on the data management service, forwarding the information of the vehicle-end gateway to the edge node, and caching the information. In the method, the MetaManager in the Kubeeedge is used as a bridge for interaction between the edge module and the edge hub module, and besides the message of the edge hub is forwarded to the edge, some necessary data are cached through SQLite, so that the offline mode of the Kubeeedge is realized to a certain extent.
Referring to fig. 3, the step of deploying an edge node module further includes the following sub-steps:
registering the first set of containers on a registration configuration center;
acquiring an IP address and a service address of a second container group registered in a registration configuration center by a cloud; and establishing a calling relationship between the first container group and the second container group through the IP address and the service address.
Referring to fig. 4 and 11, the method further comprises the sub-steps of:
defining a trunk network message and a branch network message at a vehicle end;
the backbone network information is transmitted between application programs of the vehicle terminals by using the Ethernet, and the branch network information is transmitted between hardware of the vehicle terminals by using the field bus.
Referring to fig. 5 and 12, the method further comprises the sub-steps of:
if the current residual bandwidth of the Ethernet is smaller than the current residual bandwidth of the field bus;
the application programs at the vehicle end use the field bus to transmit the trunk network information, and the hardware at the vehicle end uses the Ethernet to transmit the branch network information.
Referring to fig. 6, the method further comprises the sub-steps of:
defining a trunk network message and a branch network message at a vehicle end;
transmitting backbone network messages using ethernet and branch network messages using fieldbus;
decomposing the application program into backbone network data and branch network data according to the size of the storage space of the application program to be transmitted;
the duty ratio of the trunk network data and the branch network data is adapted to the duty ratio of the current residual bandwidth of the Ethernet and the current residual bandwidth of the field bus;
the backbone network data is sent to the ethernet as backbone network messages and the branch network data is sent to the fieldbus as branch network messages.
Referring to fig. 7, the method further comprises the sub-steps of:
defining a trunk network message and a branch network message at a vehicle end;
transmitting backbone network messages using ethernet and branch network messages using fieldbus;
decomposing the application program into backbone network data and branch network data according to the built-in component quantity of the application program to be transmitted; the main network data are the data of the built-in components with the preset number in the installation sequence, and the data of the rest built-in components in the branch network data installation sequence;
the backbone network data is sent to the ethernet as backbone network messages and the branch network data is sent to the fieldbus as branch network messages.
Both the vehicle end service and the cloud service are Pod running on Kubernetes. Kubernetes itself has service discovery and registration functions. The interactive call of the vehicle cloud is simplified into service call among Pod in the Kubernetes cluster, and a unified call mode and protocol are provided. Calls between vehicle clouds are as simple and efficient as calls between micro services.
The cooperative computing among the vehicle clouds is an important problem solved by the vehicle cloud integrated computing platform, and the cooperative computing among the vehicle clouds is specifically realized by the following steps:
generally, the vehicle clouds are not in the same network, a gateway is arranged in each vehicle cloud and is linked through the gateway, and the IP of the cloud is different from the IP of the vehicle end; services between the vehicle clouds are mutually unknown and inaccessible and are forwarded through the gateway.
After the KubeEdge is used, the two ends of the vehicle cloud are just like a network, the IP addresses are all in one network segment and can be accessed to each other, and the vehicle cloud is just like a local area network and does not need to be forwarded by a gateway.
Referring to fig. 8, communication between the vehicle-side service and the cloud service, that is, communication between PODs, is the same as call between cloud micro services; such as POD1 and POD3 interactions,
the initialization of pod1 and pod3 are registered in registration configuration center;
pod1 may obtain the IP address and service address of pod3 from the registration configuration center;
the pod1 can call http or rpc through an IP address and a service address, and the specific calling mode depends on the access mode provided by the pod 3; as with the cloud micro-service.
After using the KubeEdge scheme, the domain control of the vehicle end is a node of Kubernetes. The procedure therein is entirely governed and orchestrated by the unification of Kubernetes. Meanwhile, the production efficiency of the vehicle end programmer can be greatly improved. Based on the running and deployment scheme behind the container, extra debugging and testing time caused by different software and hardware environments in the actual vehicle test by research and development and testing personnel is reduced.
Services within the vehicle end domain are not a constant one. After using the kubenetes-based KubeEdge solution, the online service will be upgraded very simply. The vehicle-end developer basically does not need to develop deployed or upgraded codes, and can be easily realized by directly using the service deployment schemes provided by the Kubernetes and the KubeEdge. And also provides deployment policies such as cyan deployment, scrolling, gray scale deployment, etc.
Referring to fig. 9, when deployment or upgrade is required, the mirror image of the container is issued to the vehicle end through the cloud end, and finally deployment and upgrade are completed by the vehicle end edge. The edge of the vehicle end creates a mirrored Pod just like a Kubernetes node, and then runs the program. In this embodiment, the purpose of using KubeEdge makes service deployment in domain control consistent with cloud service deployment, so as to realize vehicle cloud integration.
The embodiment of the application also discloses a communication method based on the vehicle-cloud integrated architecture, referring to fig. 10, the method is applied to the cloud and comprises the following steps:
based on a cloud gateway in data connection with a vehicle-end gateway, transmitting data with the vehicle-end gateway, and acquiring information and equipment state of the vehicle-end gateway; the cloud gateway adopts CloudHub, cloudHub as a gateway for transmitting cloud information and is responsible for a channel for transmitting data with a vehicle end. All vehicle cloud interacted data is routed here.
Registering a cloud program on an application server;
editing and rewriting the cloud program; the method is realized by a core controller, kubeEdge, kubeEdge is based on Kubernetes, and the core controller is used for interacting with a KubernetestApi-Server to realize the arrangement and management of containers.
And generating an instruction for controlling the hardware on the vehicle side or reading the data of the hardware on the vehicle side based on the cloud program. The device management is realized by the device controller, which in this embodiment can be understood as an ECU on the vehicle.
The embodiment of the application discloses a communication device based on car cloud integration framework, including following module:
the vehicle-end gateway is in data connection with the cloud gateway and is used for transmitting messages with the cloud gateway; the gateway of the vehicle end adopts EdgeHub, edgeHub which corresponds to CloudHub of the cloud, is a gateway for transmitting the vehicle end information, and is the information transmission and routing of the service vehicle end part.
The edge node is in data connection with the vehicle-side gateway and is used for deploying the containerized application program, the application program receives a starting command from the cloud and is started in response to the starting command. Edge nodes employ edge d, a containerized environment, in kubeeedge, edge d. Edge is an edge node module that manages the pod lifecycle. It deploys the containerized workload or application at the edge node (domain control). These workloads may perform any operation, from simple telemetry data operations to analytics or ML reasoning, and so on. Using the kubectl command line interface of the cloud, a user can issue a command to launch a workload.
An event center for interacting with hardware; the event center-EventBus, eventBus is used to interact with specific devices, such as an ECU. All data on the vehicle end domain control and interacted with the ECU pass through EventBus.
The service center is a client side running in the edge node and is used for receiving a request from the cloud service, interacting with a server running in the edge side and accessing a communication channel of the server of the edge side through a set protocol as the cloud service; the server at the edge end is not connected with the vehicle-end gateway data. The service center-ServiceBus, serviceBus is an HTTP client running on the edge, receives a request from the cloud service, interacts with an HTTP server running on the edge, and provides the cloud service with the ability to access the edge HTTP server through the HTTP protocol.
The equipment twin service is connected with the event center data, creates membership between the event center and the edge node, and synchronizes the equipment state of the hardware to the cloud through the edge node and the vehicle-side gateway. The device twinning service adopts a deviceTain module in the Kubeedge, is responsible for storing device states, processing device attributes, processing device twinning and other operations, creates membership between edge devices and edge nodes, and synchronizes the device states to the cloud. It also provides a query interface for the application program, and the device twinning consists of four sub-modules (namely a member module, a communication module, a device module and a device twinning module).
And the data management service is used for connecting the edge node with the vehicle-end gateway, forwarding the information of the vehicle-end gateway to the edge node and caching the information. The MetaManager in the KubeEdge is used as a bridge for interaction between the EdgeD module and the Edgehub module, and besides forwarding the message of the Edgehub to the EdgeD, some necessary data are cached through SQLite, so that the offline mode of the KubeEdge is realized to a certain extent.
The embodiment of the application also discloses a communication device based on the vehicle-cloud integrated architecture, which comprises the following modules:
the cloud gateway is in data connection with the vehicle-end gateway and is used for transmitting data interacted between the vehicle-end and the cloud; the cloud gateway adopts CloudHub, cloudHub as a gateway for transmitting cloud information and is responsible for a channel for transmitting data with a vehicle end. All vehicle cloud interacted data is routed here.
The application server is used for registering cloud programs;
the core controller is in data connection with the application server and the cloud gateway and is used for programming and rewriting the cloud program; the core controller adopts KubeEdge, kubeEdge to be based on Kubernetes, and the core controller is used for interacting with Kubernetesapi-Server to realize the arrangement and management of containers.
The device controller is in data connection with the cloud gateway and is used for generating an instruction for controlling hardware on the vehicle side or reading data of the hardware on the vehicle side based on a cloud program. The device controller is suitable for device management and can be understood as an ECU on the vehicle in this embodiment.
The new vehicle cloud integrated architecture needs to be modified by combining an electronic and electric architecture of a vehicle end with a KubeEdge; the architecture recommended by the proposal is a central computing architecture adopting micro services. The network communication is mainly Ethernet, and CAN/LIN is auxiliary. The software functions of the ECU are uniformly completed by a calculation cluster at the vehicle end. The entire computing cluster can be completed by 1 or more computing nodes, and the deployment of services is deployed in an EdgeHub manner.
The advantage of this scheme lies in: the software is quickly and iteratively upgraded, and the development period is shorter; software is highly multiplexed and accumulated; the cost of software development is reduced; reducing the entry threshold of the hardware vendor; providing a hardware integration level; the hardware utilization rate is improved; the complexity of hardware integration is reduced; the communication efficiency is high, which is up to 1Gbi or even 10Gbi; the expansion is easy; the network structure is simple.
The method mainly comprises the following steps:
1. an Ethernet-based network topology and a communication architecture are designed, and CAN/LIN is an auxiliary. Ethernet is used for backbone network communication and CAN/LIN is used only for simple communication between ECUs.
2. Define and normalize the ethernet interfaces and protocols that each ECU communicates with.
3. The vehicle end designs a central computing module, and provides computing power and storage capacity.
4. And designing a central computing module and carrying a Linux operating system, and deploying the edge end of the Kubeedge on the operating system.
5. The service of each domain is split into micro services with finer granularity without distinguishing the domains, deployed in a central computing module through a docker and registered on a Kubeedge. The cloud terminal service system has the advantages that all the vehicle terminal services can communicate with each other and can communicate with the cloud Kubeedge, so that the functions of publishing and subscribing are realized.
The embodiment of the application discloses a storage medium which stores a program of the communication method based on the vehicle-cloud integrated architecture.
Although embodiments of the present application have been shown and described above, it will be understood that the above embodiments are illustrative and not to be construed as limiting the application, and that variations, modifications, alternatives, and variations may be made to the above embodiments by one of ordinary skill in the art within the scope of the application.
Claims (10)
1. The communication method based on the vehicle cloud integrated architecture is characterized by being applied to a vehicle end and comprising the following steps of:
transmitting a message with a cloud gateway based on a vehicle-end gateway in data connection with the cloud gateway;
deploying a containerized application program based on a deployment edge node in data connection with the vehicle-side gateway, wherein the application program receives a starting command from the cloud and responds to the starting command to start;
interacting with hardware according to the event center;
based on a client side running in the edge node, receiving a request from the cloud service, interacting with a server running in the edge side, and forming a communication channel in response to the cloud service accessing the server of the edge side through a set protocol;
creating membership between the event center and the edge node, and synchronizing the equipment state of the hardware to a cloud through the edge node and the vehicle-side gateway;
and connecting the edge node with the vehicle-side gateway based on a data management service, forwarding the message of the vehicle-side gateway to the edge node, and caching the message.
2. The vehicle-cloud integrated architecture-based communication method according to claim 1, wherein the step of deploying an edge node module further comprises the sub-steps of:
registering the first set of containers on a registration configuration center;
acquiring an IP address and a service address of a second container group registered in the registration configuration center by a cloud; and establishing a calling relation between the first container group and the second container group through the IP address and the service address.
3. The vehicle-cloud integrated architecture-based communication method according to claim 1, further comprising the sub-steps of:
defining a trunk network message and a branch network message at a vehicle end;
and the trunk network messages are transmitted among the application programs of the vehicle terminals by using Ethernet, and the branch network messages are transmitted among the hardware of the vehicle terminals by using field buses.
4. The vehicle-cloud integrated architecture-based communication method according to claim 1, further comprising the sub-steps of:
if the current residual bandwidth of the Ethernet is smaller than the current residual bandwidth of the field bus;
the backbone network message is transmitted between the application programs of the vehicle end by using the field bus, and the branch network message is transmitted between the hardware of the vehicle end by using the Ethernet.
5. The vehicle-cloud integrated architecture-based communication method according to claim 1, further comprising the sub-steps of:
defining a trunk network message and a branch network message at a vehicle end;
transmitting the backbone network message using ethernet and the branch network message using fieldbus;
decomposing an application program into the backbone network data and the branch network data according to the storage space size of the application program to be transmitted;
the ratio of the main network data to the branch network data is adapted to the ratio of the current residual bandwidth of the Ethernet to the current residual bandwidth of the field bus;
and sending the backbone network data to the Ethernet as the backbone network message, and sending the branch network data to the field bus as the branch network message.
6. The vehicle-cloud integrated architecture-based communication method according to claim 1, further comprising the sub-steps of:
defining a trunk network message and a branch network message at a vehicle end;
transmitting the backbone network message using ethernet and the branch network message using fieldbus;
decomposing an application program into the backbone network data and the branch network data according to the built-in component quantity of the application program required to be transmitted; the backbone network data are the data of the built-in components with the preset number in the installation sequence, and the data of the rest built-in components in the branch network data installation sequence;
and sending the backbone network data to the Ethernet as the backbone network message, and sending the branch network data to the field bus as the branch network message.
7. The communication method based on the vehicle cloud integrated architecture is characterized by being applied to a cloud and comprising the following steps of:
transmitting data generated by the communication method based on the vehicle-cloud integrated architecture according to any one of claims 1-6 with the vehicle-side gateway based on a cloud gateway in data connection with the vehicle-side gateway, and acquiring a message and a device state of the vehicle-side gateway;
registering a cloud program on an application server;
arranging and rewriting the cloud program;
and generating an instruction for controlling hardware on the vehicle side or reading data of the hardware on the vehicle side based on the cloud program.
8. Communication device based on car cloud integration framework, characterized by comprising the following modules:
the vehicle-end gateway is in data connection with the cloud gateway and is used for transmitting messages with the cloud gateway;
the edge node is in data connection with the vehicle-side gateway and is used for deploying a containerized application program, the application program receives a starting command from the cloud and is started in response to the starting command;
an event center for interacting with hardware;
the service center is a client side running in the edge node and is used for receiving a request from the cloud service, interacting with a server running in the edge side and accessing a communication channel of the server of the edge side through a set protocol as the cloud service; the server of the edge end is not connected with the vehicle-end gateway in a data way;
the equipment twin service is in data connection with the event center, a membership is created between the event center and the edge node, and the equipment state of the hardware is synchronized with the vehicle-side gateway to the cloud through the edge node;
the data management service is used for connecting the edge node with the vehicle-end gateway, forwarding the information of the vehicle-end gateway to the edge node and caching the information;
a program of a communication method based on a vehicle-cloud integrated architecture as claimed in any one of claims 1 to 6 is run in the above module.
9. Communication device based on car cloud integration framework, characterized by comprising the following modules:
the cloud gateway is in data connection with the vehicle-end gateway and is used for transmitting data interacted between the vehicle-end and the cloud;
the application server is used for registering cloud programs;
the core controller is in data connection with the application server and the cloud gateway and is used for programming and rewriting the cloud program;
the device controller is in data connection with the cloud gateway and is used for generating an instruction for controlling hardware on a vehicle end or reading data of the hardware on the vehicle end based on the cloud program;
a program of a communication method based on a vehicle-cloud integrated architecture as set forth in claim 7 is run in the above module.
10. A storage medium storing a program of the communication method based on the vehicle cloud integrated architecture according to any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311470862.6A CN117459552A (en) | 2023-11-06 | 2023-11-06 | Communication method, device and storage medium based on vehicle cloud integrated architecture |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311470862.6A CN117459552A (en) | 2023-11-06 | 2023-11-06 | Communication method, device and storage medium based on vehicle cloud integrated architecture |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117459552A true CN117459552A (en) | 2024-01-26 |
Family
ID=89585128
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311470862.6A Pending CN117459552A (en) | 2023-11-06 | 2023-11-06 | Communication method, device and storage medium based on vehicle cloud integrated architecture |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117459552A (en) |
-
2023
- 2023-11-06 CN CN202311470862.6A patent/CN117459552A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107426034B (en) | Large-scale container scheduling system and method based on cloud platform | |
| CN109889551B (en) | Method for accessing intelligent hardware to Internet of things cloud platform | |
| CN112383416A (en) | Kubeedge and EdgeX fountain based intelligent edge device control platform | |
| CN107493191B (en) | Cluster node and self-scheduling container cluster system | |
| CN113467436A (en) | SOA service layering-based complete vehicle function implementation method and system | |
| CN108737463A (en) | A kind of software deployment method, server and system | |
| Antonini et al. | Fog computing architectures: A reference for practitioners | |
| CN102647319A (en) | Application service system for monitoring power charging-exchanging station and interprocess communication method | |
| CN109159125A (en) | Cloud service system based on ROS system robot | |
| US20220150317A1 (en) | Universal software communication bus | |
| CN114546445B (en) | Whole-vehicle OTA controller upgrading system and method based on micro-service architecture | |
| CN114938371A (en) | Cloud edge cooperative data exchange service implementation method and system based on cloud originality | |
| CN111193610B (en) | Intelligent monitoring data system and method based on Internet of things | |
| CN113937894A (en) | Cloud edge cooperation-based electric intelligent terminal management system and method | |
| CN110011984B (en) | REST and RPC-based distributed cluster system and method | |
| CN115242565B (en) | System architecture, communication method and equipment for realizing DDS communication based on AUTOSAR | |
| CN117459552A (en) | Communication method, device and storage medium based on vehicle cloud integrated architecture | |
| CN115755810A (en) | Distributed control device based on cooperative control | |
| CN112783049B (en) | Lamp networking remote control system based on little service | |
| CN111491186B (en) | Video control method in vehicle electronic information system | |
| CN114979144A (en) | Cloud edge communication method and device and electronic equipment | |
| CN109117146A (en) | Automatic deployment method, device, storage medium and the computer equipment of cloud platform duoble computer disaster-tolerance system | |
| CN114371938B (en) | Space-based intelligent networking edge computing framework | |
| Pandey et al. | Middleware for Edge Devices in Mobile Edge Computing | |
| Schmidt et al. | Dynamic resource allocation of switched Ethernet networks in embedded real-time systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |