CN116931988A - OTA upgrading method and device, electronic equipment and storage medium - Google Patents
OTA upgrading method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN116931988A CN116931988A CN202310854791.3A CN202310854791A CN116931988A CN 116931988 A CN116931988 A CN 116931988A CN 202310854791 A CN202310854791 A CN 202310854791A CN 116931988 A CN116931988 A CN 116931988A
- Authority
- CN
- China
- Prior art keywords
- upgrade
- file
- group
- gateway
- ota
- 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
- 238000000034 method Methods 0.000 title claims abstract description 50
- 238000004590 computer program Methods 0.000 claims description 17
- 230000008569 process Effects 0.000 claims description 6
- 230000000977 initiatory effect Effects 0.000 claims description 4
- 238000004891 communication Methods 0.000 abstract description 22
- 230000009286 beneficial effect Effects 0.000 abstract description 5
- 230000003993 interaction Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 230000001680 brushing effect Effects 0.000 description 4
- WXZOXVVKILCOPG-UHFFFAOYSA-N bis(2-ethylhexyl) benzene-1,3-dicarboxylate Chemical compound CCCCC(CC)COC(=O)C1=CC=CC(C(=O)OCC(CC)CCCC)=C1 WXZOXVVKILCOPG-UHFFFAOYSA-N 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 239000002131 composite material Substances 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
- H04W8/24—Transfer of terminal data
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Stored Programmes (AREA)
Abstract
The application relates to the field of new energy automobiles, and provides an OTA upgrading method, an OTA upgrading device, electronic equipment and a storage medium. The method comprises the following steps: submitting a first upgrade service application to an OTA upgrade master control; when a first upgrade file transmitted by an OTA upgrade master control is received, upgrade refreshing is carried out by using the first upgrade file, and a broadcast message is issued; receiving a second upgrade service application sent by other upgrade requiring parties; and determining the first upgrade file corresponding to the second subscription content as a target upgrade file, and sending the target upgrade file to other upgrade requesters so that the other upgrade requesters use the target upgrade file to update and write. The application breaks the traditional passive mode of receiving upgrade and writing, realizes the active upgrade and writing, adopts the subscription-release communication mode to be beneficial to saving a large amount of network bandwidth, has more flexible and diversified OTA upgrade modes, and can improve upgrade efficiency.
Description
Technical Field
The present application relates to the field of new energy automobiles, and in particular, to an OTA upgrading method, an OTA upgrading device, an electronic device, and a storage medium.
Background
OTA (Over the Air Technology), i.e., space download technology, an automobile OTA upgrade refers to a firmware upgrade and/or software upgrade to an automobile using over-the-air technology.
The current OTA upgrades basically perform upgrade brushing on the upgraded components (such as ECU) by the OTA master control, and each upgraded component receives the upgrade brushing "passively". Because the 'passive' upgrading and writing mode can upgrade and write the upgraded parts no matter whether the upgraded parts have upgrading and writing requirements, the OTA master control can upgrade and write the upgraded parts, so that a large amount of network bandwidth is required to be consumed, the potential of OTA upgrading is difficult to fully develop, and the upgrading efficiency is low.
Disclosure of Invention
In view of the above, the embodiments of the present application provide an OTA upgrading method, device, electronic apparatus and storage medium, so as to solve the problems that the existing OTA upgrading method needs to consume a large amount of network bandwidth, is difficult to fully develop the potential of OTA upgrading, and has low upgrading efficiency.
In a first aspect of the embodiment of the present application, an OTA upgrading method is provided, including:
submitting a first upgrade service application to an OTA upgrade master control, wherein the first upgrade service application comprises first identification information and a first subscription event group corresponding to the first identification information, and the first subscription event group comprises at least one first subscription content;
When receiving a first upgrade file corresponding to each first subscription content transmitted by an OTA upgrade master control, using the first upgrade file to carry out upgrade refreshing and issuing a broadcast message, wherein the broadcast message at least comprises first version information of the first upgrade file;
receiving a second upgrade service application sent by other upgrade requesters, wherein the second upgrade service application comprises second identification information and a second subscription event group corresponding to the second identification information, and the second subscription event group comprises at least one second subscription content;
and determining the first upgrade file corresponding to the second subscription content as a target upgrade file, and sending the target upgrade file to other upgrade requesters so that the other upgrade requesters use the target upgrade file to update and write.
In a second aspect of the embodiment of the present application, an OTA upgrading device is provided, including:
the application initiating module is configured to submit a first upgrade service application to the OTA upgrade master control, wherein the first upgrade service application comprises first identification information and a first subscription event group corresponding to the first identification information, and the first subscription event group comprises at least one first subscription content;
the message broadcasting module is configured to use the first upgrade files to carry out upgrade and refresh when receiving the first upgrade files corresponding to each first subscription content transmitted by the OTA upgrade master control, and to issue a broadcast message, wherein the broadcast message at least comprises first version information of the first upgrade files;
The application receiving module is configured to receive a second upgrade service application sent by other upgrade requiring parties, the second upgrade service application comprises second identification information and a second subscription event group corresponding to the second identification information, and the second subscription event group comprises at least one second subscription content;
the file sending module is configured to determine a first upgrade file corresponding to the second subscription content as a target upgrade file, and send the target upgrade file to other upgrade requesters so that the other upgrade requesters use the target upgrade file to update and write.
In a third aspect of the embodiments of the present application, there is provided an electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the above method when executing the computer program.
In a fourth aspect of the embodiments of the present application, there is provided a computer readable storage medium storing a computer program which, when executed by a processor, implements the steps of the above method.
Compared with the prior art, the embodiment of the application has the beneficial effects that: in one aspect, an upgrade requiring party (e.g., a certain ECU) may serve as an upgrade service requiring party, submit a first upgrade service application to an OTA upgrade master to obtain a first upgrade file corresponding to a first subscription content in the first upgrade service application from the OTA upgrade master; then, when the first upgrade file is used for upgrade and refresh, a broadcast message can be issued to inform other upgrade requiring parties (such as other ECUs and the like) of upgrade services which can be provided by the first upgrade file at present, including upgrade file versions, upgrade files and the like; on the other hand, the upgrade requesting party can serve as an upgrade service provider, and when receiving a second upgrade service application sent by other upgrade requesting parties, the upgrade requesting party determines a first upgrade file corresponding to second subscription content in the second upgrade service application as a target upgrade file, and sends the target upgrade file to other upgrade requesting parties, so that the other upgrade requesting parties use the target upgrade file to update and write. That is, the upgrade requester may be either an upgrade service requester or an upgrade service provider. When the upgrade demand party is used as an upgrade service demand party, the upgrade demand party can actively apply for the first upgrade file required by the upgrade demand party to the OTA upgrade master control when the upgrade demand is met, the traditional mode of 'passive' receiving upgrade refreshing is broken, the 'active' upgrade refreshing is realized, and the 'subscription-release' communication mode is beneficial to saving a large amount of network bandwidth. When the upgrade requiring party is used as an upgrade service provider, upgrade services (including upgrade file downloading and other services) can be provided for other upgrade requiring parties, so that the mode of OTA upgrade is more flexible and diversified, and the potential of OTA upgrade is fully exerted. By the method, one upgrade requiring party can upgrade a plurality of different applications at the same time, and the same application can be upgraded at the same time by the plurality of different upgrade requiring parties, so that the upgrade efficiency is effectively improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic view of an application scenario according to an embodiment of the present application;
fig. 2 is a schematic diagram of a system architecture of an OTA upgrade system according to an embodiment of the present application;
fig. 3 is a flow chart of an OTA upgrading method according to an embodiment of the present application;
fig. 4 is a schematic diagram of a system architecture of another OTA upgrade system according to an embodiment of the present application;
fig. 5 is a flowchart of another OTA upgrading method according to an embodiment of the present application;
fig. 6 is a schematic diagram of an OTA upgrading device according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
An OTA upgrading method and device according to an embodiment of the present application will be described in detail below with reference to the accompanying drawings.
Fig. 1 is a schematic view of an application scenario according to an embodiment of the present application. The application scenario may include an OTA upgrade master 101, an upgrade requester 102, other upgrade requesters 103, a server 104.
The OTA upgrade master 101 may be an OTA upgrade master (abbreviated as "UMC") carried in VBOX (Vehicle BOX).
The upgrade requesting party 102 and the other upgrade requesting party 103 may be a whole Vehicle Gateway (VGW), or may be an ECU (Electronic Control Unit ) unit suspended under the whole vehicle gateway, or may be IVI (In-vehicle info ainment, in-vehicle infotainment system) or the like. The upgrade demanded party 102 and the other upgrade demanded party 103 are different upgrade demanded parties, for example, when the upgrade demanded party 102 is the ECU1 hung under the whole vehicle gateway 1, the other upgrade demanded party 103 may be other ECU components or whole vehicle gateways (such as VGW2, VGW3 … …), IVI, and the like besides the ECU 1.
The whole vehicle gateway carries an OTA upgrade agent (UA for short); each ECU carries an OTA upgrade slave (abbreviated as "US").
The OTA upgrade master control 101, the upgrade requiring party 102 and the server 104 can be respectively connected through 100M/1000M Ethernet (EHT); the upgrade required party 102 and the other upgrade required parties 103 may be connected via 100M/1000M ethernet.
The server 104 may be a server, a server cluster formed by a plurality of servers, or a cloud computing service center, which is not limited in this embodiment of the present application.
Fig. 2 is a schematic diagram of a system architecture of an OTA upgrade system according to an embodiment of the present application. For convenience of description, only parts related to the embodiments of the present application are shown in the drawings.
As shown in fig. 2, the OTA upgrade system includes an OTA upgrade master 101, an upgrade requester 102, other upgrade requesters 103, and a server 104.
The OTA upgrade master 101 includes a remote control/V2X (vehicle to vehicle)/OTA master service layer, an atomic service layer, a device abstraction layer, middleware, an operating system, and a hardware layer. The atomic service layer comprises a plurality of atomic services, such as request downloading, version pushing, version detecting, request upgrading, file signature checking, communication algorithm, release upgrading, file (self) upgrading, encryption and decryption and the like. The middleware comprises SOMEIP/MQTT/DOIP/UDS protocol stack. Each atomic service corresponds to a single function interface.
As an example, the upgrade requester 102 is the ECU1-1 hooked under the whole vehicle gateway 1 (VGW 1), and the other upgrade requesters 103 are IVIs connected with the whole vehicle gateway 1 (VGW 1). The upgrade required party 102 includes a composite service layer (implementing the composite functionality of multiple atomic services), an atomic service layer, a device abstraction layer, middleware (including SOMEIP/MQTT/DOIP/UDS protocol stacks), an operating system, and a hardware layer. Other upgrade requesters 103 include an audio-visual entertainment/OTA service layer, an atomic service layer (including multiple atomic services such as human-machine interaction, music playing, file downloading, file (self) upgrade, request download, subscription upgrade, etc.), a device abstraction layer, middleware (including a SOMEIP/MQTT/DOIP/UDS protocol stack), an operating system, and a hardware layer.
The OTA upgrade master 101, the upgrade requesters 102, the other upgrade requesters 103, and the server 104 may implement "subscription-publish" communication through a SOME/IP (Scalable service-Oriented Middle ware over IP) protocol. SOME/IP is one of the protocols implementing SOA (Service-oriented architecture). The in-vehicle ethernet includes an application layer, a transport layer, a network layer, a data link layer, and a physical layer. The SOME/IP is based on the UDP/TCP protocol of the transmission layer, has a specific service interaction mechanism, broadcasts and informs other nodes in the domain after the service is on line, and requests or subscribes to related service interfaces after the other nodes receive the service broadcast, which is different from the communication mode of the traditional vehicle-mounted network, when the request is sent, the SOME/IP only sends data, otherwise, the SOME/IP does not send the data, so that unnecessary data is not needed on the bus, and the system load is reduced. With the continuous development of an automobile communication bus and an entire automobile electronic and electric architecture, a signal-oriented communication mode based on a CAN bus cannot meet the development requirement of an intelligent automobile SOA architecture, and an SOME/IP protocol is one of the communication protocols for realizing the SOA architecture at present.
The SOME/IP protocol manages data information in units of service elements, which can be classified into Event, method, field three types. Event is a unidirectional data transmission mode, and Server publishes service Event to subscriber; method is a communication mode of remote function call; fields, like a combination of Event and Method, allow clients to obtain/set/subscribe to state information for Server-side events. The transmission and sharing of the data information is realized through Service Interface.
It should be noted that, the specific types, numbers, combinations, and the like of the OTA upgrade master control 101, the upgrade requester 102, the other upgrade requesters 103, and the server 104 may be adjusted according to the actual requirements of the application scenario, and the present application is not limited in this disclosure.
Fig. 3 is a flow chart of an OTA upgrading method according to an embodiment of the present application. The OTA upgrade method of fig. 3 may be performed by the upgrade requester 102 of fig. 1. As shown in fig. 3, the OTA upgrading method includes:
step S301 submits a first upgrade service application to an OTA upgrade master control, where the first upgrade service application includes first identification information and a first subscription event group corresponding to the first identification information, and the first subscription event group includes at least one first subscription content.
The first identification information refers to identification information of the upgrade requiring party 102, and may be, for example, an ID, a digital code, or the like.
The first subscription content generally refers to content such as an upgrade software name and an upgrade version number that the upgrade requester 102 wants to subscribe to according to actual requirements.
The first subscription event group, which is a collection that includes respective first subscription content, is used to characterize all upgrade services that the upgrade requester 102 wants to subscribe to.
For example, if the upgrade requester 102 wants to subscribe to the latest upgrade versions of the four types of software, "QQ", "WeChat", "headline" and "firmware upgrade update", the first subscription event group includes [ (a, up-to-date), (B, up-to-date), (C, up-to-date), (D, up-to-date) ], for a total of four first subscription contents. Wherein (A, up-to-date) is a first subscription content, A represents "QQ", up-to-date represents the latest version; (B, up-to-date) is a first subscription content, B represents "WeChat", up-to-date represents the latest version; (C, up-to-date) is a first subscription content, C represents a 'header', and up-to-date represents the latest version; (D, up-to-date) is a first subscription content, D represents "firmware upgrade update", and up-to-date represents the latest version.
In step S302, when receiving the first upgrade file corresponding to each first subscription content transmitted by the OTA upgrade master control, the upgrade and refresh are performed using the first upgrade file, and a broadcast message is issued, where the broadcast message at least includes the first version information of the first upgrade file.
To facilitate understanding, continuing with the above example, the first upgrade file corresponding to the first subscription content (a, up-to-date) is the latest upgrade version file of "QQ"; the first upgrade file corresponding to the first subscription content (B, up-to-date) is the latest upgrade version file of WeChat; the first upgrade file corresponding to the first subscription content (C, up-to-date) is the latest upgrade version file of the 'headline'; the first upgrade file corresponding to the first subscription content (D, up-to-date) is the latest upgrade version file of "firmware upgrade update".
In an embodiment, after the upgrade demander 102 obtains the first upgrade files of the four first subscription contents, the first upgrade files may be temporarily stored in a preset storage space, and then, according to practical situations (such as network bandwidth, user request, etc.), the four software applications including "QQ", "WeChat", "header" and "firmware upgrade update" may be optionally upgraded by using the four first upgrade files at the same time, or one or two or three of the first upgrade files may be used to upgrade the corresponding software applications in batches at different time periods, so as to implement that one upgrade demander upgrades a plurality of different software applications at the same time.
In another embodiment, after receiving the first subscription event group of the upgrade requester 102, if the server 104 is confirmed to have the first upgrade file corresponding to the first subscription content in the first subscription event group, the OTA upgrade master control 101 may directly upgrade and write the corresponding software of the upgrade requester 102, without transmitting the first upgrade file to the upgrade requester 102, and then the upgrade requester 102 performs upgrade and write by itself, thereby simplifying the intermediate transmission flow of the first upgrade file and improving the upgrade efficiency.
Step S303, receiving a second upgrade service application sent by the other upgrade requiring party, where the second upgrade service application includes second identification information and a second subscription event group corresponding to the second identification information, and the second subscription event group includes at least one second subscription content.
The second identification information refers to identification information of other upgrade required parties 103, and may be, for example, an ID, a digital code, etc.
The second subscription content generally refers to the content such as the name of the upgrade software and the upgrade version number that the other upgrade requester 103 wants to subscribe to according to its actual requirement.
The second subscription event group, which is a collection including respective second subscription contents, is used to characterize all upgrade services that other upgrade requesters 103 want to subscribe to.
For example, if the other upgrade requester 103 wants to subscribe to the latest upgrade versions of both "QQ" and "WeChat" software applications, the second subscription event group includes [ (A, up-to-date), (B, up-to-date) ], for a total of two second subscriptions. Wherein (A, up-to-date) is a second subscription content, A represents "QQ", up-to-date represents the latest version; (B, up-to-date) is a second subscription content, B represents "WeChat", and up-to-date represents the latest version.
Step S304, determining the first upgrade file corresponding to the second subscription content as a target upgrade file, and sending the target upgrade file to other upgrade requesters so that the other upgrade requesters use the target upgrade file to update and write.
As an example, assuming that the upgrade requester 102 receives the second subscription event group of the other upgrade requester 103 as [ (a, up-to-date) ], the upgrade requester 102 may first search whether the "QQ" latest version file corresponding to the second subscription content (a, up-to-date) and the "WeChat" latest version file corresponding to the second subscription content (B, up-to-date) are stored in its storage space. If so, the "QQ" latest version file and the "WeChat" latest version file acquired from the OTA upgrade master 101 are determined as target upgrade files, and these target upgrade files are sent to other upgrade requesters 103.
If the upgrade requester 102 searches to find that there is no "QQ" latest version file corresponding to the second subscription content (a, up-to-date) in its storage space, a message of unsuccessful subscription may be returned to the other upgrade requester 103. Thereafter, the other upgrade requester 103 may itself issue a third upgrade service application to the OTA upgrade master 101, where the third upgrade service application includes a second subscription content (a, up-to-date) to obtain a corresponding "QQ" latest version file.
According to the technical scheme provided by the embodiment of the application, the upgrading requirement party can be used as an upgrading service requirement party and also can be used as an upgrading service provider. When the upgrade demand party is used as an upgrade service demand party, the upgrade demand party can actively apply for the first upgrade file required by the upgrade demand party to the OTA upgrade master control when the upgrade demand is met, the traditional mode of 'passive' receiving upgrade refreshing is broken, the 'active' upgrade refreshing is realized, and the 'subscription-release' communication mode is beneficial to saving a large amount of network bandwidth. When the upgrade requiring party is used as an upgrade service provider, upgrade services (including upgrade file downloading and other services) can be provided for other upgrade requiring parties, so that the mode of OTA upgrade is more flexible and diversified, and the potential of OTA upgrade is fully exerted. By the method, one upgrade requiring party can upgrade a plurality of different applications at the same time, and the same application can be upgraded at the same time by the plurality of different upgrade requiring parties, so that the upgrade efficiency is effectively improved.
In some embodiments, in the step S301, submitting the first advanced service application to the OTA upgrade master, including:
acquiring an upgrade service message, upgrade index information and first identification information issued by an OTA upgrade master control, wherein the upgrade service message comprises at least one upgrade event, and each upgrade event comprises upgrade identification information and upgrade file version information corresponding to the upgrade identification information;
Determining at least one first subscription content according to the upgrade index information, the upgrade identification information and the upgrade file version information;
and submitting a first advanced service application to the OTA upgrade master control based on the first subscription content and the first identification information.
The upgrade Service message generally refers to an office Service message that is actively issued by an upgrade Service provider (such as an OTA upgrade master control) after the upgrade Service provider is ready for the upgrade Service and the upgrade Service meets the issue condition. The office Service message at least comprises upgrade identification information (such as a software name, a software ID, etc.), and upgrade file version information (such as a software version number, etc.) corresponding to the upgrade identification information.
The upgrade index information mainly refers to firmware or software which the upgrade requester wants to upgrade and software version information thereof. For example, the upgrade requiring party (e.g. IVI) wants to upgrade the two types of software of "QQ" and "WeChat" to the current latest version, and the upgrade index information includes at least the software names of "QQ" and "WeChat" and their current latest version numbers.
As an example, the OTA upgrade master 101 may actively issue an Offer Service message (i.e., an upgrade Service message) to inform other nodes in the multicast that the Service has been started after the upgrade Service is ready and the Service meets the issue condition, and may create a Service connection. The upgrade requester 102 may submit a first upgrade Service application to the OTA upgrade master 101 when it receives an Offer Service message for the relevant Service in the network and wants to access the upgrade Service.
If the upgrade requiring party 102 does not receive or temporarily does not receive the upgrade Service message issued by the OTA upgrade master control 101 in the network, the Find Service message may be sent to actively search for the Service, and if the OTA upgrade master control 101 is ready for the upgrade Service, the Offer Service message may be replied.
When the OTA upgrade master control 101 finds that the upgrade service is not available and does not meet the service release condition, it actively sends Stop Offer Service message to inform other nodes in the multicast that the upgrade service is not available, and stops service support.
As an example, assume that the upgrade requester 102 wants to subscribe to the latest upgrade versions of the four types of software, "QQ", "WeChat", "headline", and "firmware upgrade update", i.e., upgrade index information includes the software names and latest version numbers of "QQ", "WeChat", "headline", and "firmware upgrade update"; if the upgrade service message received by the upgrade requester 102 includes the software names and the latest version numbers of the four types of software, four first subscription contents (A, up-to-date), (B, up-to-date), (C, up-to-date), (D, up-to-date) may be determined. Afterwards, the upgrade requester 102 may assemble the four first subscription contents and the identity information (i.e. the first identity information) thereof into a subscription message (i.e. a subscription message), where the subscription message includes the first subscription event group [ (a, up-to-date), (B, up-to-date), (C, up-to-date), (D, up-to-date) ], and propose the first upgrade service application to the OTA upgrade master 101.
After receiving the subscription message of the upgrade requiring party 102, the OTA upgrade master control 101 needs to first determine whether the upgrade requiring party 102 meets subscription conditions (for example, determine whether the upgrade requiring party is a member user, whether the upgrade requiring party has permission to Subscribe to the service, etc.), if yes, determine that the upgrade requiring party 102 meets the event group subscription conditions, send a subscore ACK (subscription acknowledgement character), and inform the upgrade requiring party 102 that subscription is successful. After the events within the first event group are ready (i.e., the first upgrade file corresponding to the first subscription content is ready), the OTA upgrade master 101 sends the relevant events in a contracted form to the upgrade requester 102 who successfully subscribes. If the upgrade requester 102 does not meet the event group subscription condition, the OTA upgrade master 101 directly replies to the subscription ack (negative acknowledgement character) informing that the subscription was unsuccessful.
After the upgrade requester 102 subscribes to a certain event group, it finds that the following event group is not data that needs the event group, and may send a Stop Subscribe message to the OTA upgrade master 101 to unsubscribe from the corresponding event.
In some embodiments, in the step S304, the determining the first upgrade file corresponding to the second subscription content as the target upgrade file, and sending the target upgrade file to other upgrade requesters specifically includes:
If the first upgrading file corresponding to the second subscription content does not exist, forwarding the second upgrading service application to an OTA upgrading master control;
and receiving a second upgrade file corresponding to the second subscription content and issued by the OTA upgrade master control, and forwarding the second upgrade file to other upgrade requesters.
As an example, assuming that the upgrade requester 102 receives the second subscription event group of the other upgrade requester 103 as [ (a, up-to-date), (B, up-to-date) ], if the upgrade requester 102 searches to find that there is no "QQ" latest version file corresponding to the second subscription content (a, up-to-date) in its storage space, only there is a "WeChat" latest version file corresponding to the second subscription content (B, up-to-date), the "WeChat" latest version file may be determined as the target upgrade file and sent to the other upgrade requester 103. At the same time, the upgrade requester 102 may submit a fourth upgrade service application to the OTA upgrade master 101, the fourth upgrade service application including the second subscription content (a, up-to-date). After acquiring the "QQ" latest version file corresponding to the second subscription content (a, up-to-date) transmitted by the OTA upgrade master control 101, the upgrade requester 102 determines the "WeChat" latest version file as a target upgrade file and sends the target upgrade file to other upgrade requesters 103.
If neither the OTA upgrade master 101 nor the server 104 has a "QQ" latest version file corresponding to the second subscription content (a, up-to-date), then a message of unsuccessful subscription may be returned by the OTA upgrade master 101 to the other upgrade required party 103. The OTA upgrade master 101 may issue the "QQ" latest version file corresponding to the second subscription content (a, up-to-date) to the other upgrade requiring party 103 after the "QQ" latest version file corresponding to the second subscription content (a, up-to-date) exists according to the conventions of the other upgrade requiring party 103.
In some embodiments, in the step S304, the sending the target upgrade file to other upgrade requesters includes:
applying for obtaining intra-group member information from an intra-group network;
judging whether other upgrading demand parties are in-group upgrading demand parties according to in-group member information;
and if the other upgrading requirement party is the in-group upgrading requirement party, sending the target upgrading file to the other upgrading requirement party.
Referring to fig. 4, as an example, assuming that the upgrade requiring party 102 is the ECU1-1 hooked under the entire vehicle gateway VGW1, and the other upgrade requiring party 103 is the ECU1-n hooked under the entire vehicle gateway VGW1, the ECU1-1 may first send an acquisition request of the intra-group member information to the intra-group gateway (i.e., VGW 1); after receiving the intra-group member information (including identification information of the intra-group members, etc.) returned by VGW1, the ECU1-1 judges whether the identification information of the ECU1-n exists in the intra-group member information; if the identification information of the ECU1-n exists, it may be determined that the ECU1-n is a member of the VGW1 group, that is, is an in-group upgrade requiring party, and then the ECU1-1 may directly send the target upgrade file to the ECU1-n.
In other embodiments, if the other upgrading demand party is an off-group upgrading demand party, acquiring information of an off-group gateway and membership members thereof, and determining the off-group gateway to which the other upgrading demand party belongs according to the information of the off-group gateway and membership members thereof;
if the gateway outside the group and the gateway inside the group are the same-vehicle gateway group, the target upgrade file is sent to the gateway inside the group, so that the gateway inside the group sends the target upgrade file to the gateway outside the group, and the target upgrade file is sent to other upgrade demanding parties through the gateway outside the group.
Referring to fig. 4, as an example, assume that the upgrade requiring party 102 is an ECU1-1 hooked under the whole vehicle gateway VGW1, and the other upgrade requiring party 103 is an ECU2-1 hooked under the whole vehicle gateway VGW2, and the ECU1-1 finds out the intra-group member information provided by the whole vehicle gateway VGW1, where the intra-group member information does not include the identification information of the ECU2-1, so that it can be determined that the ECU2-1 and the ECU2-1 belong to different whole vehicle gateways respectively, and it can be determined that the ECU2-1 is an out-of-group upgrade requiring party. At this time, the ECU1-1 may acquire information of the outside gateway and its membership members via the whole vehicle gateway VGW1, and determine to which outside gateway the ECU2-1 belongs by searching for the information of the outside gateway and its membership members.
Assuming that the ECU2-1 is found to be the ECU member affiliated to the entire vehicle gateway VGW2, it is further confirmed whether the entire vehicle gateway VGW2 and the entire vehicle gateway VGW1 are the same vehicle gateway group (i.e., the gateways belonging to the same vehicle). If VGW2 and VGW1 are the same gateway group, the target upgrade file can be sent to VGW1, then the target upgrade file is forwarded to VGW2 through VGW1, and finally the target upgrade file is forwarded to the hooked ECU2-1 through VGW 2.
In some embodiments, if the out-of-group gateway and the in-group gateway are different vehicle gateway groups, detecting a network connection state of a network channel between the out-of-group gateway and the in-group gateway;
if the network connection state is normal, the target upgrade file is sent to the gateway in the group, so that the gateway in the group sends the target upgrade file to the gateway outside the group, and the target upgrade file is sent to other upgrade requesters through the gateway outside the group.
As an example, assume that the upgrade requiring party 102 is the ECU1-1 hooked under the whole gateway VGW1 of the first vehicle, the other upgrade requiring party 103 is the ECU3' -1 hooked under the whole gateway VGW3' of the second vehicle, and the whole gateway VGW1 and the whole gateway VGW3' are different vehicle gateway groups (i.e. gateways respectively belonging to different vehicles). Then, the ECU1-1 may detect the network connection state of the network channel between the whole vehicle gateway VGW1 and the whole vehicle gateway VGW3', for example, may determine whether the network connection state of the network channel between the whole vehicle gateway VGW1 and the whole vehicle gateway VGW3' is normal by acquiring the network card state value of the network card interface externally connected to the whole vehicle gateway VGW3' on the whole vehicle gateway VGW 1. Generally, when the network card status value is linkup, the network connection status is normal, and when the network card status value is linkdown, the network connection status is abnormal. If the network connection state is normal, the target upgrade file is sent to the whole gateway VGW1, the target upgrade file is forwarded to the whole gateway VGW3' of the second vehicle through the whole gateway VGW1, and then the target upgrade file is forwarded to the ECU3' -1 through the whole gateway VGW3 '.
Through the method, the subscription-release service communication interaction between the upgrading demand side and other upgrading demand sides of the gateways in the group, the upgrading demand side and other upgrading demand sides of the same car gateway group and the upgrading demand side and other upgrading demand sides of the different car gateway group can be realized, so that the OTA upgrading mode is more flexible and diversified, and the OTA upgrading potential is fully exerted. In addition, the upgrade service communication between the gateway in the group and the gateway in the same vehicle CAN be realized by using Ethernet or CAN bus, which CAN save a great deal of network bandwidth.
When the gateway affiliated to the upgrading demand side and other upgrading demand sides is a different vehicle gateway group, whether the distance difference value of the vehicles affiliated to the upgrading demand side and other upgrading demand sides meets the preset distance range can be further judged, if the distance difference value meets the preset distance range, the transmission of the upgrading file is realized by means of near field communication interaction, bluetooth communication interaction and the like, so that the traffic required by transmission can be saved, and the OTA upgrading cost can be reduced.
For example, assume that the upgrade requiring party 102 is an ECU1-1 hooked under the whole gateway VGW1 of the first vehicle, the other upgrade requiring party 103 is an ECU3' -1 hooked under the whole gateway VGW3' of the second vehicle, and the whole gateway VGW1 and the whole gateway VGW3' are different gateway groups. The ECU1-1 may further acquire first position information of the own vehicle (i.e., the first vehicle) and second position information of the second vehicle, and then confirm a distance difference between the two vehicles according to the first position information and the second position information; if the distance difference value meets a preset distance range (for example, less than or equal to 5 meters), the communication interaction between the whole gateway VGW1 and the whole gateway VGW3 'CAN be switched to a near field communication mode or a Bluetooth communication mode, and based on the near field communication interaction or the Bluetooth communication interaction, the whole gateway VGW1 transmits the target upgrade file to the whole gateway VGW3', and then the target upgrade file is forwarded to the ECU3'-1 through the whole gateway VGW3' through an Ethernet/CAN bus.
In some embodiments, the above OTA, the method for upgrading may further include the following steps:
after the broadcast message is issued, when the accumulated time reaches the preset duration and a second upgrade service application sent by other upgrade requiring parties is not received yet, judging whether the upgrade refreshing flow using the first upgrade file to carry out upgrade refreshing is finished completely;
and if the updating and refreshing process of the updating and refreshing by using the first updating file is completely finished, all the first updating files are emptied.
The preset duration can be flexibly set according to practical situations, for example, can be set to 24 hours, 48 hours and the like.
As an example, assuming that the preset duration is 24 hours, the upgrade requiring party 102 starts to count after issuing the broadcast message, and when the accumulated time reaches 24 hours and the second upgrade service application sent by other upgrade requiring parties is not yet received, it is firstly determined whether the brushing flow of brushing by using the first upgrade file is completely finished; if it has been completely finished, all the first upgrade files in its storage space are emptied to release the occupied content.
Any combination of the above optional solutions may be adopted to form an optional embodiment of the present application, which is not described herein.
Fig. 5 is a flowchart of another OTA upgrading method according to an embodiment of the present application.
Taking an upgrade service demand side as an ECU, an upgrade service provider as a UMC as an example, the OTA upgrade process on the ECU side is approximately as follows: firstly, an ECU subscribes the upgrade service of the ECU to UMC by calling a SOME/IP service interface; then, judging whether the subscription is successful or not according to the response ACK returned by the UMC; if the subscription is successful, judging whether an upgrade version pushed by the UMC exists or not; if the updated version pushed by the UMC exists, further confirming whether the new version is updated or not; if the updated version is confirmed, calling a request file downloading service in an atomic service layer to download a corresponding ECU file (namely an updated version file pushed by the UMC) from the UMC; then, judging whether an ECU file downloading completion notification sent by the UMC is received or not; if the ECU file downloading completion notification sent by the UMC is received, calling a file updating and refreshing service in an atomic service layer to update the file; then, inquiring whether the ECU file installation is completed or not; if the installation is completed, the method exits.
The TSP (server) serves as an OTA service provider and mainly provides an upgrade version and a file of the ECU, manages upgrade files of each ECU, and can acquire related upgrade files from the server via VBOX when each ECU needs to be upgraded.
For UMC/UA/US they both act as service providers as well as service requesters. Between UMC and TSP, UMC is service demander, and version information and file upgrade package of ECU to be upgraded are needed to be obtained from TSP.
UMC, UA, US, UMC/UA/US can be used as both a service provider and a service requester to upgrade and refresh the files of OTA according to the upgrade service of OTA provided by the own system.
The SOA SOMEIP OTA upgrade service content includes, but is not limited to, "remind the user of new version update, ask the user to confirm", "download instruction to control the download", "upgrade instruction to control the upgrade", "request the download", etc.
In one embodiment, assuming that the upgrade requestor 102 is IVI, VI subscribes to the OTA upgrade master 101 for the upgrade event group (i.e., subscribes to these upgrades) requirements of "QQ, weChat, headline" and "firmware upgrade update" at the same time, the OTA upgrade master 101 synchronizes these subscription requirements to the TSP. If the TSP has these services, the upgrade files will be downloaded to the IVI (or VBOX temporary) part via the OTA upgrade master 101 channel for upgrade swiping, so that different applications can be upgraded simultaneously at one upgrade requester 102. If not, the subscription message is saved, and if the new version and file exist, the subscription component is notified with the notification published message.
In another embodiment, assume that the upgrade required party 102 is the entire gateway VGW1, VGW2, VGW3, and VGW4, which subscribe to the OTA upgrade master 101 for the upgrade event group (i.e. subscribe to the upgrade) requirements of "TCP/IP END" and the like, at the same time, the OTA upgrade master 101 synchronizes these subscription requirements to the TSP. If the TSP has these services, the OTA upgrade master control 101 downloads these upgrade files to VGW1, VGW2, VGW3 and VGW4 for upgrade and writing, so that the same upgrade file data packet can be upgraded on multiple upgrade requiring sides. If not, the subscription message is saved, and if the new version and file exist, the subscription component is notified with the notification published message.
Through the mode, each upgrade requiring party can realize that one upgrade requiring party upgrades a plurality of different application programs simultaneously by publishing or subscribing the same or different OTA upgrade services, and can also realize that a plurality of upgrade requiring parties upgrade the same application program in parallel, so that the 'thousands of people and thousands of sides' OTA customized upgrade service can be realized.
The following are examples of the apparatus of the present application that may be used to perform the method embodiments of the present application. For details not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the method of the present application.
Fig. 6 is a schematic diagram of an OTA upgrading device according to an embodiment of the present application. As shown in fig. 6, the OTA upgrading device includes:
the application initiation module 601 is configured to submit a first upgrade service application to the OTA upgrade master control, where the first upgrade service application includes first identification information and a first subscription event group corresponding to the first identification information, and the first subscription event group includes at least one first subscription content;
the message broadcasting module 602 is configured to, when receiving the first upgrade file corresponding to each first subscription content transmitted by the OTA upgrade master control, use the first upgrade file to perform upgrade and refresh, and issue a broadcast message, where the broadcast message includes at least first version information of the first upgrade file;
the application receiving module 603 is configured to receive a second upgrade service application sent by another upgrade requiring party, where the second upgrade service application includes second identification information and a second subscription event group corresponding to the second identification information, and the second subscription event group includes at least one second subscription content;
the file sending module 604 is configured to determine the first upgrade file corresponding to the second subscription content as a target upgrade file, and send the target upgrade file to other upgrade requesters, so that the other upgrade requesters use the target upgrade file to perform upgrade and refresh.
According to the technical scheme provided by the embodiment of the application, the upgrading requirement party can be used as an upgrading service requirement party and also can be used as an upgrading service provider. When the upgrade demand party is used as an upgrade service demand party, the upgrade demand party can actively apply for the first upgrade file required by the upgrade demand party to the OTA upgrade master control when the upgrade demand is met, the traditional mode of 'passive' receiving upgrade refreshing is broken, the 'active' upgrade refreshing is realized, and the 'subscription-release' communication mode is beneficial to saving a large amount of network bandwidth. When the upgrade requiring party is used as an upgrade service provider, upgrade services (including upgrade file downloading and other services) can be provided for other upgrade requiring parties, so that the mode of OTA upgrade is more flexible and diversified, and the potential of OTA upgrade is fully exerted. By the method, one upgrade requiring party can upgrade a plurality of different applications at the same time, and the same application can be upgraded at the same time by the plurality of different upgrade requiring parties, so that the upgrade efficiency is effectively improved.
In some embodiments, the application initiation module 601 includes:
the information acquisition unit is configured to acquire an upgrade service message, upgrade index information and first identification information which are issued by the OTA upgrade master control, wherein the upgrade service message comprises at least one upgrade event, and each upgrade event comprises upgrade identification information and upgrade file version information corresponding to the upgrade identification information;
A subscription determining unit configured to determine at least one first subscription content according to the upgrade index information, the upgrade identification information, and the upgrade file version information;
and the submitting unit is configured to submit the first advanced service application to the OTA upgrade master control based on the first subscription content and the first identification information.
In some embodiments, the file sending module 604 includes:
the file forwarding unit is configured to forward the second upgrading service application to the OTA upgrading master control if the first upgrading file corresponding to the second subscription content does not exist;
the receiving unit is configured to receive a second upgrade file corresponding to the second subscription content and issued by the OTA upgrade master control, and forward the second upgrade file to other upgrade requesters.
In some embodiments, the file sending module 604 includes:
the acquisition unit is configured to apply for acquiring intra-group member information from the intra-group gateway;
the judging unit is configured to judge whether other upgrading demand parties are in-group upgrading demand parties according to the in-group member information;
the first sending unit is configured to send the target upgrade file to the other upgrade requesters if the other upgrade requesters are in-group upgrade requesters.
In some embodiments, the file sending module 604 further includes:
the determining unit is configured to acquire information of the extragroup gateway and membership members thereof if other upgrading demand parties are extragroup upgrading demand parties, and determine extragroup gateways affiliated by other upgrading demand parties according to the information of the extragroup gateway and membership members thereof;
the second sending unit is configured to send the target upgrade file to the gateway in the group if the gateway outside the group and the gateway inside the group are the same-vehicle gateway group, so that the gateway outside the group sends the target upgrade file to the gateway outside the group, and the target upgrade file is sent to other upgrade requesters through the gateway outside the group.
In some embodiments, the file sending module 604 further includes:
the detection unit is configured to detect the network connection state of a network channel between the gateway outside the group and the gateway inside the group if the gateway outside the group and the gateway inside the group are different-vehicle gateway groups;
and the forwarding unit is configured to send the target upgrade file to the gateway in the group if the network connection state is normal, so that the gateway in the group sends the target upgrade file to the gateway outside the group, and the target upgrade file is sent to other upgrade requesters through the gateway outside the group.
Through the method, the subscription-release service communication interaction between the upgrading demand side and other upgrading demand sides of the gateways in the group, the upgrading demand side and other upgrading demand sides of the same car gateway group and the upgrading demand side and other upgrading demand sides of the different car gateway group can be realized, so that the OTA upgrading mode is more flexible and diversified, and the OTA upgrading potential is fully exerted. In addition, the upgrade service communication between the gateway in the group and the gateway in the same vehicle CAN be realized by using Ethernet or CAN bus, which CAN save a great deal of network bandwidth.
In some embodiments, the OTA upgrading device further includes:
the judging module is configured to judge whether the updating and refreshing flow using the first updating file is completely finished when the accumulated time reaches the preset duration and the second updating service application sent by other updating demand parties is not received after the broadcasting message is issued;
and the emptying module is configured to empty all the first upgrade files if the updating and refreshing process of the upgrade and the refreshing by using the first upgrade files is determined to be finished.
It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application.
Fig. 7 is a schematic diagram of an electronic device 7 according to an embodiment of the present application. As shown in fig. 7, the electronic device 7 of this embodiment includes: a processor 701, a memory 702 and a computer program 703 stored in the memory 702 and executable on the processor 701. The steps of the various method embodiments described above are implemented by the processor 701 when executing the computer program 703. Alternatively, the processor 701, when executing the computer program 703, performs the functions of the modules/units of the apparatus embodiments described above.
The electronic device 7 may be a desktop computer, a notebook computer, a palm computer, a cloud server, or the like. The electronic device 7 may include, but is not limited to, a processor 701 and a memory 702. It will be appreciated by those skilled in the art that fig. 7 is merely an example of the electronic device 7 and is not limiting of the electronic device 7 and may include more or fewer components than shown, or different components.
The processor 701 may be a central processing unit (Central Processing Unit, CPU) or other general purpose processor, digital signal processor (Digital Signal Processor, DSP), application specific integrated circuit (Application Specific Integrated Circuit, ASIC), field programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like.
The memory 702 may be an internal storage unit of the electronic device 7, for example, a hard disk or a memory of the electronic device 7. The memory 702 may also be an external storage device of the electronic device 7, for example, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like provided on the electronic device 7. The memory 702 may also include both internal storage units and external storage devices of the electronic device 7. The memory 702 is used to store computer programs and other programs and data required by the electronic device.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit.
The integrated modules/units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiment, or may be implemented by a computer program to instruct related hardware, and the computer program may be stored in a computer readable storage medium, where the computer program, when executed by a processor, may implement the steps of each of the method embodiments described above. The computer program may comprise computer program code, which may be in source code form, object code form, executable file or in some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth. It should be noted that the content of the computer readable medium can be appropriately increased or decreased according to the requirements of the jurisdiction's jurisdiction and the patent practice, for example, in some jurisdictions, the computer readable medium does not include electrical carrier signals and telecommunication signals according to the jurisdiction and the patent practice.
The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.
Claims (10)
1. An OTA upgrade method, comprising:
submitting a first upgrade service application to an OTA upgrade master control, wherein the first upgrade service application comprises first identification information and a first subscription event group corresponding to the first identification information, and the first subscription event group comprises at least one first subscription content;
when receiving a first upgrade file corresponding to each first subscription content transmitted by the OTA upgrade master control, using the first upgrade file to carry out upgrade and refresh, and issuing a broadcast message, wherein the broadcast message at least comprises first version information of the first upgrade file;
Receiving a second upgrade service application sent by other upgrade requesters, wherein the second upgrade service application comprises second identification information and a second subscription event group corresponding to the second identification information, and the second subscription event group comprises at least one second subscription content;
and determining a first upgrade file corresponding to the second subscription content as a target upgrade file, and sending the target upgrade file to the other upgrade requesters so that the other upgrade requesters use the target upgrade file to update and write.
2. The method of claim 1, wherein sending the target upgrade file to the other upgrade demander comprises:
applying for obtaining intra-group member information from an intra-group network;
judging whether the other upgrading demand parties are upgrading demand parties in the group according to the intra-group member information;
and if the other upgrading requirement party is the in-group upgrading requirement party, the target upgrading file is sent to the other upgrading requirement party.
3. The method of claim 2, further comprising, after determining whether the other upgrade required party is an intra-group upgrade required party based on the intra-group member information:
If the other upgrading demand party is an off-group upgrading demand party, acquiring information of an off-group gateway and membership members thereof, and determining the off-group gateway to which the other upgrading demand party belongs according to the information of the off-group gateway and membership members thereof;
and if the outside gateway and the inside gateway are the same-vehicle gateway group, the target upgrade file is sent to the inside gateway so that the inside gateway sends the target upgrade file to the outside gateway, and the target upgrade file is sent to other upgrade requesters through the outside gateway.
4. The method of claim 3, further comprising, after determining the extragroup gateway to which the other upgrade requiring party belongs based on the extragroup gateway and the information of the membership members thereof:
if the gateway outside the group and the gateway inside the group are different-vehicle gateway groups, detecting the network connection state of a network channel between the gateway outside the group and the gateway inside the group;
and if the network connection state is normal, sending the target upgrade file to an intra-group gateway so that the intra-group gateway sends the target upgrade file to the outer-group gateway, and sending the target upgrade file to the other upgrade requesters through the outer-group gateway.
5. The method according to claim 1, characterized in that the method further comprises:
after the broadcast message is issued, when the accumulated time reaches the preset duration and a second upgrade service application sent by other upgrade requiring parties is not received yet, judging whether the upgrade refreshing flow using the first upgrade file to carry out upgrade refreshing is finished completely;
and if the updating and refreshing process of the first updating file is completely finished, all the first updating files are emptied.
6. The method of claim 1, wherein submitting the first advanced service application to the OTA upgrade master comprises:
acquiring an upgrade service message, upgrade index information and first identification information issued by an OTA upgrade master control, wherein the upgrade service message comprises at least one upgrade event, and each upgrade event comprises upgrade identification information and upgrade file version information corresponding to the upgrade identification information;
determining at least one first subscription content according to the upgrade index information, the upgrade identification information and the upgrade file version information;
and submitting a first upgrade service application to the OTA upgrade master control based on the first subscription content and the first identification information.
7. The method of claim 1, wherein determining a first upgrade file corresponding to the second subscription content as a target upgrade file and transmitting the target upgrade file to the other upgrade demander comprises:
if the first upgrading file corresponding to the second subscription content does not exist, forwarding the second upgrading service application to the OTA upgrading master control;
and receiving a second upgrade file corresponding to the second subscription content and issued by the OTA upgrade master control, and forwarding the second upgrade file to the other upgrade requesters.
8. An OTA upgrading device, comprising:
the application initiating module is configured to submit a first upgrade service application to the OTA upgrade master control, wherein the first upgrade service application comprises first identification information and a first subscription event group corresponding to the first identification information, and the first subscription event group comprises at least one first subscription content;
the message broadcasting module is configured to use the first upgrade files to update and write when receiving the first upgrade files corresponding to each first subscription content transmitted by the OTA upgrade master control, and to issue a broadcast message, wherein the broadcast message at least comprises first version information of the first upgrade files;
The application receiving module is configured to receive a second upgrade service application sent by other upgrade requesters, wherein the second upgrade service application comprises second identification information and a second subscription event group corresponding to the second identification information, and the second subscription event group comprises at least one second subscription content;
and the file sending module is configured to determine a first upgrade file corresponding to the second subscription content as a target upgrade file, and send the target upgrade file to the other upgrade requesters so that the other upgrade requesters use the target upgrade file to update and write.
9. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the steps of the method according to any of claims 1 to 7 when the computer program is executed.
10. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the steps of the method according to any one of claims 1 to 7.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310854791.3A CN116931988A (en) | 2023-07-12 | 2023-07-12 | OTA upgrading method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310854791.3A CN116931988A (en) | 2023-07-12 | 2023-07-12 | OTA upgrading method and device, electronic equipment and storage medium |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116931988A true CN116931988A (en) | 2023-10-24 |
Family
ID=88378312
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310854791.3A Pending CN116931988A (en) | 2023-07-12 | 2023-07-12 | OTA upgrading method and device, electronic equipment and storage medium |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116931988A (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117459190A (en) * | 2023-12-20 | 2024-01-26 | 中汽研(天津)汽车工程研究院有限公司 | OTA communication method of heterogeneous central computing architecture |
-
2023
- 2023-07-12 CN CN202310854791.3A patent/CN116931988A/en active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117459190A (en) * | 2023-12-20 | 2024-01-26 | 中汽研(天津)汽车工程研究院有限公司 | OTA communication method of heterogeneous central computing architecture |
CN117459190B (en) * | 2023-12-20 | 2024-04-02 | 中汽研(天津)汽车工程研究院有限公司 | OTA communication method of heterogeneous central computing architecture |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2547040B1 (en) | Group communication method and device for use in group communication | |
CN111478897A (en) | OTA (over the air) upgrading method and system for vehicle ECU (electronic control Unit) | |
US20080155112A1 (en) | System and method for updating information feeds | |
CN107404512B (en) | Resource subscription method, resource subscription device and resource subscription system | |
CN104378391A (en) | Software updating method, system and device | |
KR20230067691A (en) | Vehicle upgrade method and device | |
JP6654738B1 (en) | Processing telemetry data based on the operating state of the data source | |
CN116931988A (en) | OTA upgrading method and device, electronic equipment and storage medium | |
CN112368997B (en) | Resource management method and device | |
JP2017220220A (en) | Electronic control units and service management system for vehicles | |
JP2023544123A (en) | Data transmission system, data transmission method, intelligent vehicle, and device | |
CN111464642A (en) | Method and device for pushing messages of vehicle machine | |
CN111638891B (en) | Equipment upgrading method and device, terminal equipment and storage medium | |
US10638418B2 (en) | Method and apparatus for data transfer connection management | |
KR20220139759A (en) | System for managing update of ecu in vehicle and method thereof | |
CN110417905B (en) | Contract issuing method, device, equipment and union chain system | |
CN109981778B (en) | Method, device, equipment and storage medium for realizing service of content distribution network | |
CN116915816A (en) | CAN signal data customized acquisition method and device | |
US7587752B2 (en) | Methods and apparatus for providing a control channel in a data network | |
WO2009014911A2 (en) | Providing network connectivity and service state information to application servers | |
CN114670764B (en) | Method and device for controlling whole electric automobile to sleep and electronic control unit | |
US11558205B2 (en) | Scalable certificate revocation truth distribution and verification using a bloom filter set and a false positive set for PKI-based IoT scenarios | |
EP4451113A1 (en) | Method and system for remote software update | |
CN115190165B (en) | Vehicle OTA system and method based on subscription and release mode | |
EP4258620A1 (en) | Invoking service method, device, and computer readable storage medium |
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 |