CN113227967A - Software upgrading method and device - Google Patents

Software upgrading method and device Download PDF

Info

Publication number
CN113227967A
CN113227967A CN202180000695.1A CN202180000695A CN113227967A CN 113227967 A CN113227967 A CN 113227967A CN 202180000695 A CN202180000695 A CN 202180000695A CN 113227967 A CN113227967 A CN 113227967A
Authority
CN
China
Prior art keywords
function
upgrade
vehicle
software
upgrading
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
Application number
CN202180000695.1A
Other languages
Chinese (zh)
Inventor
马涛
周铮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN113227967A publication Critical patent/CN113227967A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

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)
  • Stored Programmes (AREA)

Abstract

The application relates to the technical field of Internet of vehicles, in particular to a software upgrading method and device. The method comprises the following steps: obtaining upgrading strategy information, wherein the upgrading strategy information is used for indicating at least two functions corresponding to a vehicle, and the at least two functions comprise a first function and a second function, wherein the first function is in a forbidden state, and the second function is in an available state; and sending the upgrading strategy information to the vehicle. In the method, during the software upgrading of the vehicle, the first function of the vehicle is in a disabled state, and the second function is in an available state, so that the user can still use the second function during the software upgrading of the vehicle, and the vehicle using experience of the user is improved.

Description

Software upgrading method and device
Technical Field
The application relates to the technical field of Internet of vehicles, in particular to a software upgrading method and device.
Background
The Over-the-Air (OTA) technology mainly refers to a method for updating terminal software through remote management of an Air interface, an operating system of equipment, system configuration and the like can be updated through OTA upgrading, and the method has the advantages of being convenient and fast, not needing a manufacturer to find a vehicle back for upgrading, greatly saving cost and further improving user experience.
In the OTA upgrading process, some software of the automobile can not work normally due to upgrading. If an abnormal exit event occurs, the upgrade will fail. Meanwhile, the functions of the automobile can be disabled in the OTA software upgrading process.
Disclosure of Invention
The embodiment of the application provides a software upgrading method and device, which can enable part of functions of a vehicle to be used by a user in a vehicle software upgrading process, and improve vehicle using experience of the user.
In a first aspect, an embodiment of the present application provides a software upgrading method, which is applicable to a server, and the method includes: obtaining upgrading strategy information, wherein the upgrading strategy information is used for indicating at least two functions corresponding to a vehicle, and the at least two functions comprise a first function and a second function, wherein the first function is in a forbidden state, and the second function is in an available state; and sending the upgrading strategy information to the vehicle.
In one possible implementation, the first function may include one or more functions, and the second function may also include one or more functions.
By the method, during the upgrading period of the vehicle, the first function of the vehicle is in the forbidden state, and the second function of the vehicle is in the usable state, so that the user can still use the second function during the upgrading period of the vehicle, and the vehicle using experience of the user is improved.
In one possible implementation, the upgrade policy information is used to indicate that the first function is disabled and the second function is available when the vehicle upgrades the first function.
That is to say, in this implementation, when upgrading to the first function, the first function is in a disabled state, and the second function is in an available state, so that during upgrading of the vehicle, while ensuring the safety performance of the vehicle, the user can use the second function, and the vehicle using experience of the user is improved.
In a possible implementation manner, the upgrade policy information is further used to indicate that the first function and the third function are both in a disabled state, and the third function is associated with the first function.
That is, in this implementation, when the first function is in the disabled state, the third function associated with the first function is also in the disabled state, thereby ensuring the safety performance of the vehicle during the upgrade.
In one possible implementation, the upgrade policy information is further used to indicate that the second function is disabled when the vehicle is upgrading the second function.
That is, in this implementation, the second function may be disabled when upgraded to the second function, thereby ensuring the safety of the vehicle during the upgrade.
In one possible implementation, the upgrade policy information is further used to instruct the vehicle to upgrade the first function and the second function in sequence, and the first function is in a usable state when the second function is upgraded.
That is, in this implementation, when the second function is upgraded, the first function that was previously in the disabled state may be made available again, thereby further improving the user experience with the vehicle.
In one possible implementation, the upgrade policy information is further used to instruct the vehicle to provide a first prompt message through the human machine interface HMI when upgrading the first function, the first prompt message being used to prompt the user that the first function is in a disabled state and/or to prompt the user that the second function is in an available state.
That is, in this implementation, during the software upgrade of the vehicle, the user may be prompted that the first function is unavailable and/or that the second function is unavailable, which further improves the vehicle using experience of the user.
In a second aspect, an embodiment of the present application provides a software upgrading method, which is applicable to a vehicle, and includes: obtaining upgrading strategy information, wherein the upgrading strategy information is used for indicating at least two functions corresponding to a vehicle, and the at least two functions comprise a first function and a second function, wherein the first function is in a forbidden state, and the second function is in an available state; and upgrading the first function according to the upgrading strategy information.
In one possible implementation, the first function may include one or more functions, and the second function may also include one or more functions.
In one possible implementation, the upgrade policy information is used to indicate that the first function is disabled and the second function is available when the vehicle upgrades the first function.
In a possible implementation manner, the upgrade policy information is further used to indicate that the first function and the third function are both in a disabled state, and the third function is associated with the first function.
In one possible implementation, the upgrade policy information is further used to indicate that the second function is disabled when the vehicle upgrades the second function.
In one possible implementation, the upgrade policy information is further used to instruct the vehicle to upgrade the first function and the second function in sequence, and the first function is in a usable state when the second function is upgraded.
In one possible implementation, the upgrade policy information is further used to instruct the vehicle to provide a first prompt message through the human machine interface HMI when upgrading the first function, the first prompt message being used to prompt the user that the first function is in a disabled state and/or to prompt the user that the second function is in an available state.
In a third aspect, an embodiment of the present application provides a software upgrading apparatus, including: the system comprises an acquisition unit, a processing unit and a display unit, wherein the acquisition unit is used for acquiring upgrading strategy information which is used for indicating at least two functions corresponding to a vehicle, the at least two functions comprise a first function and a second function, the first function is in a forbidden state, and the second function is in an available state; and the sending unit is used for sending the upgrading strategy information to the vehicle.
In one possible implementation, the upgrade policy information is used to indicate that the first function is disabled and the second function is available when the vehicle upgrades the first function.
In a possible implementation manner, the upgrade policy information is further used to indicate that the first function and the third function are both in a disabled state, and the third function is associated with the first function.
In one possible implementation, the upgrade policy information is further used to indicate that the second function is disabled when the vehicle upgrades the second function.
In one possible implementation, the upgrade policy information is further used to instruct the vehicle to upgrade the first function and the second function in sequence, and the first function is in a usable state when the second function is upgraded.
In one possible implementation, the upgrade policy information is further used to instruct the vehicle to provide a first prompt message through the human machine interface HMI when upgrading the first function, the first prompt message being used to prompt the user that the first function is in a disabled state and/or to prompt the user that the second function is in an available state.
In a fourth aspect, an embodiment of the present application provides a software upgrading apparatus, including: the system comprises an acquisition unit, a processing unit and a display unit, wherein the acquisition unit is used for acquiring upgrading strategy information which is used for indicating at least two functions corresponding to a vehicle, the at least two functions comprise a first function and a second function, the first function is in a forbidden state, and the second function is in an available state; and the upgrading unit is used for upgrading the first function according to the upgrading strategy information.
In one possible implementation, the upgrade policy information is used to indicate that the first function is disabled and the second function is available when the vehicle upgrades the first function.
In a possible implementation manner, the upgrade policy information is further used to indicate that the first function and the third function are both in a disabled state, and the third function is associated with the first function.
In one possible implementation, the upgrade policy information is further used to indicate that the second function is disabled when the vehicle upgrades the second function.
In one possible implementation, the upgrade policy information is further used to instruct the vehicle to upgrade the first function and the second function in sequence, and the first function is in a usable state when the second function is upgraded.
In one possible implementation, the upgrade policy information is further used to instruct the vehicle to provide a first prompt message through the human machine interface HMI when upgrading the first function, the first prompt message being used to prompt the user that the first function is in a disabled state and/or to prompt the user that the second function is in an available state.
In a fifth aspect, an embodiment of the present application provides a server, including a processor, a memory, and a communication interface; wherein the memory is used for storing a computer program; the processor is configured to execute the computer program to implement the method provided by the first aspect or any possible implementation manner of the first aspect.
In a sixth aspect, an embodiment of the present application provides an in-vehicle device, including a processor, a memory, and a communication interface; the communication interface is used for receiving or sending information; the memory is used for storing a computer program; the processor is configured to execute the computer program to implement the method provided by the second aspect or any possible implementation manner of the second aspect.
In a seventh aspect, an embodiment of the present application provides a software upgrading system, including: the software upgrading device provided by any possible implementation manner of the third aspect or the third aspect and the software upgrading device provided by any possible implementation manner of the fourth aspect or the fourth aspect; alternatively, the server provided by the fifth aspect and the in-vehicle apparatus provided by the sixth aspect.
In an eighth aspect, an embodiment of the present application provides a processor, including: for performing the method provided by any one of the possible implementations of the first or second aspect; or alternatively, to perform the method provided by the second aspect or any possible implementation manner of the second aspect.
In a ninth aspect, the present application provides a chip system comprising at least one processor configured to support the implementation of the functionality referred to in any of the first or second aspects above, e.g. to receive or process data and/or information referred to in the above methods.
In one possible design, the system-on-chip further includes a memory to hold program instructions and data, the memory being located within the processor or external to the processor. The chip system may be constituted by a chip, or may include a chip and other discrete devices.
In a tenth aspect, an embodiment of the present application provides an integrated circuit for software upgrade, including: a memory for storing computer instructions; and a processor coupled with the memory for executing the computer instructions to implement the method provided by any of the first or second aspects.
In an eleventh aspect, the present application provides a computer storage medium having a computer program stored thereon, where the computer program is executed by a processor to implement the method described in any one of the first to second aspects (or any one of its possible implementation manners).
In a twelfth aspect, embodiments of the present application provide a computer program product, which when run on one or more processors, implements the method described in any one of the first to second aspects (or implements any one of its possible implementations).
Drawings
Fig. 1 is a schematic structural diagram of a system architecture according to an embodiment of the present application;
fig. 2 is a flowchart of a software upgrading method according to an embodiment of the present application;
fig. 3A is a schematic diagram of update policy information provided in an embodiment of the present application;
fig. 3B is a schematic diagram of update policy information provided in an embodiment of the present application;
fig. 4 is a flowchart of a software upgrading method according to an embodiment of the present application;
FIG. 5 is a schematic diagram of a function disabling and software upgrading provided by an embodiment of the present application;
FIG. 6 is a schematic diagram of a function disabling and software upgrading provided by an embodiment of the present application;
FIG. 7 is a schematic illustration of an HMI interface provided in accordance with an embodiment of the present application;
FIG. 8 is a schematic diagram of a function disable and software upgrade provided by an embodiment of the present application;
FIG. 9 is a schematic illustration of an HMI interface provided in accordance with an embodiment of the present application;
FIG. 10 is a flowchart of a software upgrading method according to an embodiment of the present application;
fig. 11 is a flowchart of a software upgrading method according to an embodiment of the present application;
FIG. 12 is a schematic diagram of a function disable and software upgrade provided by an embodiment of the present application;
fig. 13 is a schematic structural diagram of a software upgrading apparatus according to an embodiment of the present application;
fig. 14 is a schematic structural diagram of a software upgrading apparatus according to an embodiment of the present application;
fig. 15 is a schematic block diagram of a server according to an embodiment of the present application
Fig. 16 is a schematic block diagram of an in-vehicle device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings. It should be apparent that the embodiments described in this specification are only some embodiments of the present application, and not all embodiments.
Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the specification. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise.
Wherein in the description of the present specification, "/" indicates a meaning, for example, a/B may indicate a or B; "and/or" herein is merely an association describing an associated object, and means that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present specification, "a plurality" means two or more.
In the description of the present specification, the terms "first", "second" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implying any number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.
Currently, for a solution to upgrade the corresponding software of a vehicle through OTA, almost all functions are disabled once the vehicle starts the software upgrade. And the whole OTA has longer duration time for upgrading the software corresponding to the vehicle, so that the user can not use the functions of the vehicle for a longer time.
The embodiment of the application provides a software upgrading method, which comprises the following steps: acquiring first upgrading strategy information, wherein the first upgrading strategy information is used for indicating at least two functions corresponding to a first vehicle, and the at least two functions can comprise a first function and a second function, wherein the first function is in a forbidden state, and the second function is in an available state; the first vehicle may upgrade the first function according to the first upgrade policy information. By the method, when the first function of the first vehicle is upgraded, the second function can be ensured to be in the available state, so that a user can still use the second function corresponding to the first vehicle in the software upgrading process of the vehicle, and the vehicle using experience of the user is greatly improved.
It is understood that in the embodiments of the present application, Software may refer to Software in a general sense, that is, related functions corresponding to Software upgrade by Software-over-the-air (SOTA). The software may be, but is not limited to, an application (app). Besides software upgrade, Firmware upgrade is also available, that is, related Firmware can be upgraded according to Firmware-over-the-air (FOTA). Hereinafter, unless otherwise specified, software may be software in a general sense or firmware.
Next, in different embodiments, a software upgrading method provided by the embodiments of the present application is developed and described.
Fig. 1 illustrates an exemplary system architecture diagram provided by an embodiment of the present application. The system architecture may include a vehicle 100 and an upgrade server 200. It is understood that the number of vehicles 100 and the number, types, etc. of upgrade servers 200 are not limited in the embodiments of the present application.
The vehicle 100 may be an automobile or other types of motor vehicles. By way of example, the vehicle may be in the form of a car, bus, truck, farm vehicle, recreational vehicle, game vehicle in an amusement park, or the like.
As shown in fig. 1, the vehicle 100 may include an upgrade control device 110, which may obtain an upgrade data packet sent by the upgrade server 200, and control the vehicle 100 to perform software upgrade using the upgrade data packet, where a specific implementation process will be described below and will not be described herein again. The upgrade control apparatus 110 may be a computing device having a data processing function. In one example, the upgrade control apparatus 110 may be a telematics Box (T-Box). For example, the upgrade control device 110 may be one or more Electronic Control Units (ECUs) of the vehicle 100.
In some embodiments, the upgrade control device 110 may be connected to a wireless communication device on the vehicle 100, or the upgrade control device 110 may be integrated with a wireless communication component (not shown). The wireless communication device or wireless communication components may include one or more antennas, modems, baseband processors, etc., and may communicate with a communication entity external to vehicle 100, such as upgrade server 200. In general, the wireless communication device or wireless communication component may be configured to communicate according to one or more communication technologies, such as mobile communication technologies like 4G/5G, and Wireless Local Area Networks (WLANs) such as wireless fidelity (Wi-Fi) networks, Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and other communication technologies, which are not listed here.
In some embodiments, the upgrade control device 110 may connect to and control a Human Machine Interface (HMI) of the vehicle 100 (not shown) to provide prompt information to a user through the HMI. Illustratively, the human-machine interface may include a display screen for displaying text, symbols, images, video, and the like. The display screen includes a display panel. The display panel may be a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a quantum dot light-emitting diode (QLED), etc., which is not limited in the embodiments.
In some embodiments, the upgrade control device 110 may connect to and control audio devices of the vehicle 100, such as speakers. The audio device may convert the electrical audio signal to a sound signal so that the upgrade control device 110 may provide the prompt information in the form of sound through the audio device.
With continued reference to FIG. 1, the vehicle 100 may include a plurality of ECUs. For one of the ECUs, it may have various hardware components, such as one or more processors (e.g., a Micro Controller Unit (MCU)), one or more memories, and so on. The ECU may have hardware components that impart data computation and data storage capabilities to the ECU, whereby the ECU may run one or more software (e.g., applications, firmware) to implement the functionality corresponding to the one or more software. In particular, the processor of the ECU may be configured to execute code or computer instructions of software stored in the memory of the ECU to implement the functionality of the one or more software routines. In some embodiments, an ECU may independently run one or more software to implement the corresponding functions of the one or more software. That is, one or more functions of the vehicle 100 may be independently implemented by one ECU. In other embodiments, two or more ECUs may run one or more pieces of software in combination or otherwise to achieve the functionality corresponding to the one or more pieces of software. That is, one or more functions of the vehicle 100 may be performed jointly or collectively by two or more ECUs. In the embodiment of the present application, the types of functions that can be realized by a single ECU and the number of ECUs for realizing a certain function are not limited.
In some embodiments, as shown in fig. 1, the vehicle 100 may include an ECU120 that may run software for controlling door locks, implementing a central lock function. The ECU120 may be one ECU on the vehicle 100, or may be constituted by a plurality of ECUs on the vehicle 100.
In some embodiments, as shown in fig. 1, the vehicle 100 may include an ECU130 that may run software for managing heating and/or cooling devices (e.g., air conditioning compressors) of the vehicle 100 to implement air conditioning management functions. For example, cooling or heating is performed in response to an operation by a user. The ECU130 may be one ECU on the vehicle 100, or may be constituted by a plurality of ECUs on the vehicle 100.
In some embodiments, as shown in fig. 1, the vehicle 100 may include an ECU140 that may run software for implementing Adaptive Cruise Control (ACC) functionality. Specifically, the ECU140 running software for implementing the ACC function may detect other vehicles on the road ahead of the vehicle 100 (i.e., the preceding vehicle of the vehicle 100) using a vehicle distance sensor (e.g., a radar) on the vehicle 100. While collecting the speed of the vehicle 100. When the distance between the vehicle 100 and its front is too small, the vehicle 100 may be instructed to slow down (e.g., the vehicle 100 is instructed to brake an appropriate amount) such that there is a safe distance between the vehicle 100 and its front. The ECU140 may be one ECU on the vehicle 100, or may be constituted by a plurality of ECUs on the vehicle 100.
In some embodiments, as shown in fig. 1, vehicle 100 may include an ECU150 that may run software for implementing a highway driving assist (HWA) function. Specifically, the ECU150 running software for realizing the HWA function may detect the vehicle in front of the vehicle 100 and the speed of the vehicle in front using sensors such as radar and a camera on the vehicle 100, and detect lane lines and the like to determine whether lane change is necessary or possible, and the like. The implementation of HWA functionality depends on ACC functionality. The ECU150 may be one ECU on the vehicle 100, or may be constituted by a plurality of ECUs on the vehicle 100.
The ECUs and functions described above are merely examples. The vehicle 100 may include more, fewer, or other ECUs, and may implement more, fewer, or other functions.
Additionally, for certain functions of the vehicle 100, its implementation may be implemented by one or more software running on the ECU. In the embodiment of the present application, the one or more software may be referred to as control software or a control program of the function. I.e. the function is controlled by the one or more software. In the case where a plurality of pieces of software control a function, each piece of software of the plurality of pieces of software participates in the implementation of the function, and therefore, each piece of software of the plurality of pieces of software may be referred to as control software or a control program of the function.
The upgrade server 200 may be an OTA cloud server that may obtain upgrade data packets from the manufacturer or developer of the vehicle 100. The upgrade data package may be configured by a manufacturer or developer of the vehicle 100, which may include an upgrade file for one or more software on the vehicle 100. The upgrade file for the software refers to an upgrade file or an upgrade package of the software, and is used for updating or upgrading the software, so that the software is more complete. For example, the security of the software is improved, the functions of the software are increased, and the like.
The software upgrading method provided by the embodiment of the application can be executed by the upgrading server 200. As shown in fig. 2, the method may include the following steps.
Step 201, obtaining first upgrade strategy information, where the first upgrade strategy information is used to indicate at least two functions corresponding to the vehicle 100, where the at least two functions include a first function and a second function, the first function is in a disabled state, and the second function is in an available state.
The upgrade server 200 may acquire first upgrade policy information, which may be used to instruct the vehicle 100 to upgrade at least two functions including the first function and the second function. Wherein during the upgrade, the upgrade policy information may indicate that the first function is in a disabled state and the second function is in an available state. Wherein a first function may refer to one or more functions and a second function may refer to another one or more functions.
In some embodiments, the first upgrade policy information may be used to indicate that the vehicle 100 is in a disabled state and the second function is in an available state when the first function is upgraded.
The first upgrade policy information may be used to indicate an upgrade order between the first function and the second function, where the first function precedes the second function in the upgrade order. That is, the first upgrade policy information may instruct the vehicle 100 to upgrade the first function first and then upgrade the second function. Also, the vehicle 100 may be instructed that the first function is in a disabled state and the second function is in an available state during the upgrade of the first function.
In some embodiments, the upgrade order between the first function and the second function may specifically be an upgrade order between the first upgrade file and the second upgrade file. In other words, the first upgrade policy information may be used to indicate an upgrade order between the first upgrade file and the second upgrade file. The first upgrading file corresponds to a first function, and the second upgrading file corresponds to a second function. The first upgrade file may include one or more upgrade files, and the second upgrade file may include one or more upgrade files.
In one possible implementation, the first upgrade policy information may be pre-configured. For example, a manufacturer or developer of the vehicle 100 may configure the first upgrade policy information.
Illustratively, the first upgrade policy information may include configuration information a 1. Configuration information a1 may record the identity of each of a plurality of upgrade files. The identification of the upgrade file may be used to distinguish the upgrade file. In one example, the identification of the upgrade file may consist of a software name or version number. In one example, the identification of the upgrade file may be a set number, and the number may be composed of numbers and/or letters, which is not limited in this embodiment.
Optionally, the configuration information a1 also records the location of the identity of each of the plurality of upgrade files in the upgrade order. The configuration information a1 may be presented as a list. In the list, the files in the plurality of upgrade files are sequentially ordered to obtain an upgrade order. The relative positions of the different upgrade files in the upgrade order represent the upgrade precedence relationship between the different upgrade files. For example, when the vehicle 100 is upgraded according to the upgrade data packet, the vehicle 100 first performs software upgrade using the first upgrade file in the upgrade sequence, then performs software upgrade using the second upgrade file in the upgrade sequence, and so on.
It is understood that the upgrade sequence may also be understood as an upgrade step, and the upgrade file at the nth position in the upgrade sequence is upgraded by the vehicle 100 at the nth step in the whole upgrade process. It should be noted that, one position in the upgrade sequence may have an identifier of one upgrade file, or may have identifiers of two or more upgrade files. Wherein the vehicle 100 may perform the upgrade operation of two or more upgrade files simultaneously when the identifications of the two or more upgrade files are at the same position in the upgrade sequence.
Thus, the configuration information a1 in the first upgrade policy information may indicate an upgrade order between the first upgrade file and the second upgrade file. Wherein the first upgrade file corresponds to a first function and the second upgrade file corresponds to a second function, and therefore, the configuration information a1 indicates an upgrade order between the first function and the second function.
In some embodiments, the first upgrade policy information is further used to indicate that the first function and the third function are both disabled, the third function being associated with the first function.
The first upgrade policy information may also indicate that the third function is associated with the first function. For example, the first function may be an ACC function and the third function may be an HWA function. Since the implementation of the HWA function depends on the ACC function, when the ACC function is in the disabled state, the HWA function is also in the disabled state, and it is possible to improve the safety performance of the vehicle 100 during software upgrade.
In some embodiments, the first upgrade policy information is also used to indicate that the second function is disabled when the vehicle 100 is upgrading the second function.
The configuration information a1 included in the first upgrade policy information indicates the order of upgrading the first function and the second function. That is, the first upgrade policy information instructs the vehicle 100 to upgrade the first function and the second function, respectively, at different times. Thus, the first upgrade policy information may indicate that the vehicle 100 is in a disabled state when the second function is upgraded.
In some embodiments, the first upgrade policy information is further used to instruct the vehicle 100 to upgrade the first function and the second function in sequence, and the first function is in a usable state while the second function is upgraded.
The configuration information a1 included in the first upgrade policy information indicates the order of upgrading the first function and the second function, and the first function precedes the second function in the order of upgrading. That is, the upgrade of the first function is completed when the second function is upgraded, and at this time, the first function may be restored to an available state. Thus, the first upgrade policy information may indicate that the first function is available while the vehicle 100 is upgrading the second function.
In some embodiments, the first upgrade policy information is further configured to instruct the vehicle 100 to provide a first prompt via a Human Machine Interface (HMI) when upgrading the first function, the first prompt being configured to prompt a user that the first function is disabled and/or to prompt the user that the second function is available.
When the vehicle 100 is upgrading the first function, the first function is in a disabled state, and the first upgrading strategy information may instruct the human-machine interface of the vehicle 100 to display prompt information, where the prompt information is used to indicate that the first function is in the disabled state, so that the user may be informed that the first function is unavailable, and vehicle using experience of the user is improved.
When the vehicle 100 upgrades the first function, the second function is in the available state, the first upgrade strategy information may instruct the human-machine interface of the vehicle 100 to display prompt information for indicating that the second function is in the available state,
that is, the first upgrade policy information may indicate which function may be in a disabled state, thereby making it available to inform the user that the second function is available, improving the user's experience with the vehicle.
In some embodiments, the first upgrade policy information may also include configuration information A2, which may include an identification of a plurality of software. The identification of software is used to distinguish the software from other software. In one example, the identification of the software may be a package name (package name) of the software. In another example, the identification of the software may be a set number, which may be composed of numbers and/or letters. The identification of the software in the configuration information a2 and the upgrade file in the upgrade data package have a correspondence relationship. The configuration information a2 includes a plurality of software identifications for disabling the corresponding software to disable the corresponding functions at the same time or before the software upgrade of the vehicle. Will be described in detail below, and will not be described in detail herein.
For example, the identification of one or more of the plurality of software included in the configuration information a2 may correspond to an upgrade file. For one function of the vehicle 100, it may be controlled by one or more software. If the upgrade file is used to update the software or software of the one or more software. A correspondence between the upgrade file and the one or more software may be established. The correspondence may be recorded in the configuration information a 2.
For example, the identification of one of the software in configuration information a2 may correspond to one or more upgrade files. It will be appreciated that one piece of software may correspond to one or more upgrade files. That is, one or more upgrade files are used to update a piece of software.
In one illustrative example, configuration information A2 may be configured by the manufacturer or developer of vehicle 100 and included in the first upgrade policy information.
In one illustrative example, the upgrade server 200 automatically generates the configuration information A2. Specifically, the upgrade server 200 may determine target software of an upgrade file according to the upgrade file, and then may determine a function controlled by the target software. If the function is controlled by a plurality of pieces of software, other pieces of control software for the function may be determined based on the function. The correspondence of the upgrade file with the target software and other control software may be established, thereby obtaining the configuration information a 2. The target software of the upgrade file refers to software used for upgrading the upgrade file. For example, if an upgrade file is used to upgrade software B1, software B1 may be referred to as the target software for the upgrade file. In this case, the manufacturer or developer of the vehicle 100 may include the configuration information a2 in the first upgrade policy information when configuring the first upgrade policy information.
In some embodiments, the first upgrade policy information may include both configuration information a2 and configuration information a 1. Fig. 3A illustrates an example of first upgrade policy information. In fig. 3A, S1, S2, and S3 respectively indicate the positions of the respective corresponding upgrade files in the upgrade order. SW1, SW2, SW3, SW4 and SW5 are respectively identifiers of different upgrade files. FC1, FC2, FC3 are identifications of different software, respectively. The software corresponding to the FC1, FC2 and FC3 is the software which needs to be disabled in the corresponding upgrading process.
In some embodiments, the first upgrade policy information may also include configuration information a3, which includes an identification of a plurality of ECUs. The identity of the ECU is used to distinguish the ECUs. In one example, the identification of the ECU may be a Unique Identification (UID). The identification of the ECU in the configuration information a3 and the upgrade file in the upgrade data package have a correspondence relationship. The configuration information a3 includes identifiers of a plurality of pieces of software, and the identifiers are used for disabling corresponding functions by disabling corresponding ECUs at the same time or before the software upgrade of the vehicle. Will be described in detail below, and will not be described in detail herein.
In some embodiments, it is understood that software may run on one or more ECUs, and if an upgrade file is used to update the software, a correspondence between the identity of the one or more ECUs and the upgrade file may be established. The correspondence may be recorded in the configuration information a 3. Therefore, the identification of one or more ECUs among the identifications of the plurality of ECUs included in the configuration information a3 may correspond to one upgrade file.
It is understood that one ECU may run one or more software. For an OTA upgrade, software in the one or more software on the ECU may have one or more upgrade files. Therefore, there may be a case where there is only one upgrade file for upgrading the software on the ECU in the upgrade data package, and there may be a case where there are a plurality of upgrade files for upgrading the software on the ECU in the upgrade data package. Thus, the identification of one of the plurality of ECUs included in the configuration information a3 may correspond to one or more upgrade files.
In one illustrative example, configuration information A3 may be configured by the manufacturer or developer of vehicle 100 and included in the first upgrade policy information.
In one illustrative example, the upgrade server 200 automatically generates the configuration information A3. Specifically, the upgrade server 200 may determine target software of an upgrade file from the upgrade file, and may further determine an ECU for running the target software. Thereby, the correspondence relationship between the ECU and the upgrade file can be established. In this case, the manufacturer or developer of the vehicle 100 may include the configuration information a3 in the first upgrade policy information when configuring the first upgrade policy information.
In some embodiments, the first upgrade policy information may include both configuration information A3 and configuration information a 1. Fig. 3B illustrates an example of first upgrade policy information. In fig. 3B, S1, S2, and S3 respectively indicate the positions of the respective corresponding upgrade files in the upgrade order. SW1, SW2, SW3, SW4 and SW5 are respectively identifiers of different upgrade files. ECU1, ECU2, and ECU3 are identifiers of different ECUs, respectively.
Returning to fig. 2, the upgrade server 200 may perform step 202 of transmitting first upgrade policy information to the vehicle 100.
In some embodiments, the upgrade server 200 may issue the first upgrade policy information to the vehicle 100 through a wireless communication network. Reference may be made specifically to the above description of the wireless communication device or the wireless communication component, which is not described herein again.
The above example describes the operations performed by upgrade server 200. Next, an operation performed by the vehicle 100 is described as an example.
Referring to fig. 4, the vehicle 100 may perform the following steps. Step 401, obtaining first upgrade strategy information, where the first upgrade strategy information is used to indicate at least two functions corresponding to the vehicle 100, where the at least two functions include a first function and a second function, the first function is in a disabled state, and the second function is in an available state.
For the first upgrade policy information, reference may be made to the above description of step 201 shown in fig. 2, which is not described herein again.
The vehicle 100 may obtain the first upgrade policy information from the upgrade server 200, which may specifically refer to the description of step 202 shown in fig. 2, and will not be described herein again.
Step 402, upgrading the first function according to the first upgrading strategy information.
The vehicle 100 may set the first function to the disabled state and upgrade the first function according to the first upgrade policy information.
Next, a specific scheme of upgrading the relevant function by the vehicle 100 according to the upgrade policy information will be described.
The vehicle 100 may obtain the upgrade data package from the upgrade server 200. The upgrade data may include an upgrade file SW1, an upgrade file SW2, an upgrade file SW3, an upgrade file SW4, and an upgrade file SW 5. Among them, the upgrade file SW1 and the upgrade file SW2 may belong to a first upgrade file, that is, the upgrade file SW1 and the upgrade file SW2, for upgrading the first function. The upgrade file SW3 and the upgrade file SW4 may belong to a second upgrade file, i.e., the upgrade file SW3 and the upgrade file SW4, for upgrading the second function. As shown in fig. 3A, the first upgrade policy information is used to instruct the vehicle 100 to perform the upgrade operation of the upgrade file SW1, the upgrade file SW2, to perform the upgrade operation of the upgrade file SW3, the upgrade file SW4, and to perform the upgrade operation of the upgrade file SW 5.
In the embodiment of the present application, the upgrade operation of the upgrade file refers to an operation of upgrading target software using the upgrade file. For convenience of expression, the upgrade file to be upgraded for the vehicle, i.e., the upgrade file to be upgraded first in the vehicle, may be referred to as the file to be upgraded. For example, the vehicle has not performed the upgrade operations of the upgrade files 1, 2, 3. In the three upgrade files, the vehicle executes the upgrade operation of the upgrade file 1 first, and the upgrade file 1 is the file to be upgraded.
In some embodiments, when the upgrade package includes a plurality of upgrade files and the first upgrade policy information includes the configuration information a1, the upgrade control device 110 may determine a file to be upgraded among the plurality of upgrade files according to the configuration information a 1. Specifically, for two upgrade files that are adjacent in position in the upgrade order, the vehicle 100 may determine the latter upgrade file as the file to be upgraded at or after the completion of the upgrade operation of the former upgrade file, in preparation for the upgrade operation of the latter upgrade file. Wherein when two or more upgrade files are in the same position of the upgrade order, that is, when two or more upgrade files are juxtaposed in the upgrade order, the two or more upgrade files may be simultaneously determined as files to be upgraded.
In some embodiments, when the upgrade package includes a plurality of upgrade files but the first upgrade policy information does not include the configuration information a1, the upgrade control device 110 may determine a file to be upgraded from the plurality of upgrade files according to a preset rule. For example, the files to be upgraded may be determined sequentially according to the sequence in which the vehicle 100 finishes receiving the upgrade files. And receiving the finished upgrade file firstly, and determining the upgrade file as a file to be upgraded. And after the file to be upgraded is upgraded, receiving the upgraded file which is completely upgraded and determining the upgraded file as a new file to be upgraded. For example, when the vehicle 100 downloads the upgrade data package, the download completion time of the upgrade file 1 is earlier than the download completion time of the upgrade file 2. The vehicle 100 determines the upgrade file 1 as the file to be upgraded before determining the upgrade file 2 as the file to be upgraded. And when or after the upgrading operation of the upgrading file 1 is completed, determining the upgrading file 2 as the file to be upgraded.
After determining the file to be upgraded, the function corresponding to the file to be upgraded may be disabled. Other functions may not be disabled, or selectively disabled. The following specifically describes the process.
One applicable scenario of the solution provided by the embodiment of the present application is that a plurality of functions of the vehicle 100 are in an available state before the vehicle 100 starts software upgrade. For example, the vehicle is in an engine start state, and functions of the vehicle 100 such as an air conditioning management function and a central lock function are available. For another example, the vehicle is in a driving state, and functions of the vehicle 100, such as an air conditioning management function, a central lock management function, an ACC function, and an HWA function, are available.
In some embodiments, after determining the file to be upgraded, if the function C1 controlled by the target software of the file to be upgraded is in an available state, the function C1 may be disabled. Wherein function C1 may be the first function in the embodiment shown in fig. 2. While other functions in the available state may not be disabled. Wherein the other function may be or comprise the second function in the embodiment shown in fig. 2. For example, the air conditioning function and the center lock function of the vehicle 100 may be set in the available state, where the center lock function is controlled by the software B1 and the air conditioning function is controlled by the software B2. The vehicle 100 may disable the central lock function without disabling the air-conditioning function after determining that the upgrade file of the software targeted for software B1 is the file to be upgraded.
In some embodiments, after determining the file to be upgraded, if the function C1 controlled by the target software of the file to be upgraded is in an available state, the function C1 may be disabled. If the implementation of function C2 of vehicle 100 relies on function C1 (e.g., the implementation of function C2 requires the use of data generated by function C1), function C2 may be disabled when or after function C1 is disabled. Wherein the function C2 may be the third function in the embodiment shown in fig. 2. For example, the implementation of HWA functionality relies on ACC functionality, which may be disabled when or after the vehicle's ACC functionality is disabled. For a function that does not depend on the function C1 and is in an available state, the disabling process may not be performed.
In some embodiments, the functionality may be disabled by disabling the control software for the functionality. The functions are realized by the operation of software. When the software is closed, the corresponding function also enters an unavailable state. By way of example, the disabling of the software may be understood as a shutting down of the software.
In one illustrative example, target software for a file to be upgraded may be closed to disable functionality controlled by the target software.
In an illustrative example, for a function controlled by a plurality of pieces of software, if the target software of the file to be upgraded corresponding to the function is part of the software in the plurality of pieces of software, only the target software of the file to be upgraded may be closed to disable the function. The plurality of software may also be shut down to disable the functionality.
In one illustrative example, the first upgrade policy information may include configuration information a 2. The configuration information a2 indicates the correspondence between the upgrade file and the software. When or after determining the file to be upgraded, the upgrade control device 110 may determine the software corresponding to the file to be upgraded according to the configuration information a2, and may further close the software.
Taking the example shown in fig. 5 as an example, when or after the upgrade file SW1 and the upgrade file SW2 are determined to be files to be upgraded, the software FC1 corresponding to the upgrade file SW1 and the upgrade file SW2 may be turned off to disable the functions controlled by the software FC 1. Then, the upgrade operations of the upgrade file SW1 and the upgrade file SW2 may be performed. When the upgrade operations of the upgrade file SW1 and the upgrade file SW2 are finished and it is determined that the upgrade file SW1 and the upgrade file SW2 are the latest files to be upgraded, the software FC2 may be turned off. Then, the upgrade operations of the upgrade file SW3 and the upgrade file SW4 may be performed.
In one illustrative example, the first upgrade policy information may include configuration information a 3. The configuration information a3 indicates the correspondence between the upgrade file and the ECU. When or after determining the file to be upgraded, the upgrade control device 110 may determine the ECU corresponding to the file to be upgraded according to the configuration information a 3. The identity of the ECU may then be mapped to the identity of the software and the software may be shut down based on the identity of the software.
In one illustrative example, the software shutdown may be implemented via a software shutdown instruction. Specifically, the upgrade control device 110 may send a shutdown instruction, which may include an identification of software, to the ECU in which the software is located, when or after determining that the software needs to be shutdown. The ECU may be operable to shut down the software in response to the shut down instruction.
In some embodiments, the functionality may be disabled by disabling the ECU. The function is realized by the running of software by the ECU. I.e. the ECU is the hardware basis for the function. When the ECU is disabled, the ECU-based functionality also becomes unavailable, i.e., disabled. Wherein disabling the ECU may refer to the ECU entering a communication silence state.
Illustratively, the ECU in the communication silence state does not respond to the instruction of the user other than the instruction to upgrade the control device 110.
For example, the functions that the ECU can perform can be divided into business functions and ECU's own management functions.
The service function may refer to a function other than the ECU's own management function, such as an air conditioner management function, a central lock management function, an ACC function, and an HWA function.
The ECU's own management function may refer to a function in which the ECU manages itself. Such as drawing power from a power source to maintain its functioning. As another example, the communication silence state is entered in response to a trigger condition (e.g., a disable instruction sent by the upgrade control device 110) to enter the communication silence state. As another example, the communication silence state is removed according to a trigger condition (e.g., a disable instruction sent by the upgrade control device 110) for removing the communication silence state. Etc., which are not listed here. Wherein the ECU entering the communication silence state no longer performs the aforementioned service function, but can still perform the aforementioned ECU self-management function.
When or after the file to be upgraded is determined, the ECU corresponding to the file to be upgraded can be determined. The ECU may refer to an ECU where target software of a file to be upgraded is located. The ECU may then be disabled.
In one illustrative example, the first upgrade policy information may include configuration information a 3. The configuration information a3 indicates the correspondence between the upgrade file and the ECU. When or after the file to be upgraded is determined, the upgrade control device 110 may determine, according to the configuration information a3, an ECU corresponding to the file to be upgraded, and then control the ECU to enter the disabled state.
In one illustrative example, the ECU entering the disabled state may be implemented via a software shutdown instruction. Specifically, the upgrade control device 110 may transmit the disabling instruction to the ECU when or after determining that the ECU needs to be disabled. The ECU may enter a disabled state in response to the disable instruction. In one example, the disabled state may refer to a communication silence state. Specifically, reference may be made to the above description, which is not repeated herein.
In some embodiments, the upgrade control device 110 may provide a prompt message to prompt or indicate that the functionality is unavailable when or after the functionality is disabled.
For example, referring to fig. 6, at or after the time of shutting down the software FC1, the upgrade control device 110 may provide a notice D1, which notice D1 is used to notice that the function controlled by the software FC1 is unavailable. The upgrade control device 110 may also provide a notice information D2 when or after the software FC2 is turned off, the notice information D2 being used to notice that the function controlled by the software FC2 is not available.
Illustratively, the upgrade control device 110 may interface with and control the human machine interface of the vehicle 100, as described above with reference to the embodiment shown in FIG. 1. The prompt message can be a text message or a symbol message. The upgrade control device 110 provides prompt information, and may specifically control the human-machine interface to display the prompt information for the upgrade control device 110. Taking the prompt message for prompting that the central locking function is unavailable as an example, the human-computer interface may display an interface as shown in fig. 7 to prompt the user that the central locking function is unavailable.
For example, referring to the above description of the embodiment shown in fig. 1, the upgrade control device 100 may connect and control the audio devices of the vehicle 100. The prompt may be a voice message. The upgrade control device 110 provides a prompt message, which may specifically be used for the upgrade control device 110 to control the audio device to play the prompt message. Taking the example of the prompt information for prompting that the air conditioner management is unavailable, the audio device may play "the current air conditioner is unavailable".
After disabling the function related to the file to be upgraded, the upgrade control device 110 may perform an upgrade operation of the file to be upgraded.
For example, the upgrade control device 110 may transmit a file to be upgraded to the target ECU. The target ECU refers to the ECU where the target upgrading software of the file to be upgraded is located. The target ECU may update or upgrade the target software with the file to be upgraded upon or after receiving the file to be upgraded.
For example, the upgrade control device 110 may transmit the file to be upgraded to the target ECU in advance, for example, before disabling the relevant function. Upon determining that the upgrade operation of the file to be upgraded is performed, the upgrade control device 110 may transmit an upgrade instruction to the target ECU. The target ECU may upgrade the target software using the file to be upgraded in response to the upgrade indication.
In some embodiments, at the end of or after the operation of upgrading the target software using the file to be upgraded, the upgrade control device 110 may control the function controlled by the target software to re-enter the available state. Therefore, the method can be used in the upgrading process, gradually forbids the upgraded function, and further improves the user experience.
In one illustrative example, with reference to fig. 8, after the end of the upgrade operations of the upgrade files SW1, SW2, the upgrade control device 110 may turn on the software FC1 so that the functions controlled by the software FC1 may be re-entered into an available state.
In one illustrative example, as shown in fig. 8, the first upgrade policy information may include indication information indicating a correspondence relationship of the prohibited software and the upgrade file. When or after the upgrade operation of the file to be upgraded is completed, the upgrade control device 110 may determine the software that needs to be disabled according to the indication information, and then start the software.
In one illustrative example, software that requires disablement may be turned on with a disablement instruction. Specifically, the upgrade control device 110 may send a disable instruction including an identification of software to the ECU in which the software is located when it is determined that the software needs to be disabled. The ECU may turn on the software in response to the disable instruction.
In one illustrative example, after the upgrade operation of the upgrade file is ended, the upgrade control device 110 may disable the ECUs corresponding to the upgrade file. The ECU corresponding to the upgrade file may specifically refer to the above description of the configuration information a3, and will not be described herein again.
In one illustrative example, the ECU may be brought out of the disabled state by the disable instruction. Specifically, the upgrade control device 110 may transmit the prohibition instruction to the ECU when it is determined that the ECU requires prohibition. The ECU may be brought out of the disabled state in response to the disable instruction to restore the relevant function.
In some embodiments, the upgrade control device 110 may provide a prompt to indicate that the functionality is available when or after the functionality is disabled or re-entered into an available state.
In one illustrative example, referring to FIG. 8, a prompt D2' may be provided at or after the time that software FC1 is turned on. The prompt message D2' is used at least to prompt that a function controlled by the software FC1 is available.
For example, the prompt message D2' may be a text message or a symbol message. The upgrade control device 110 provides the prompt information D2 ', and may specifically control the human-machine interface to display the prompt information D2' for the upgrade control device 110. Taking the example that the prompt message D2' is used to prompt that the air conditioner management is not available and the central lock function is available, the human-computer interface may display an interface as shown in fig. 9.
Illustratively, the prompt message D2' may be a voice message. The upgrade control device 110 provides the prompt information D2 ', and may specifically control the audio device to play the prompt information D2' for the upgrade control device 110. Taking the example that the prompt message D2' is used to prompt that the air-conditioning management is not available and the central lock function is available, the audio device may play "the air-conditioning management is not available and the central lock is available".
According to the software upgrading method provided by the embodiment of the application, the function needing to be forbidden can be forbidden along with the software upgrading in the software upgrading process of the vehicle, so that a user can use part of functions in the OTA process, and the vehicle using experience of the user is improved.
It will be appreciated that vehicles are typically software upgraded in a parked state for the safety of the driver, passengers and the vehicle itself. By the software upgrading method provided by the embodiment of the application, the vehicle can only disable the function needing to be disabled during upgrading, and other functions can still be in a usable state. Therefore, the software upgrading method provided by the embodiment of the application can be applied to the vehicle in a parking state and can also be applied to the vehicle in a moving state under some conditions. The parking state refers to that the vehicle is not moving currently and is stationary relative to the ground. The state of motion is opposite or opposite to the state of parking, and refers to the state in which the vehicle is moving relative to the ground on which it is located.
Next, a process of upgrading software of a vehicle in a moving state by using the software upgrading method provided in the embodiment of the present application will be described as an example.
In some embodiments, the functions of the vehicle can be divided into three types, namely a basic function, an auxiliary function and an unrelated function according to the dependence degree of the vehicle in the motion state on the functions. The basic function is a function that is necessary or highly dependent on the movement or travel of the vehicle, and is directly related to, for example, power control, direction control, speed control, and the like of the vehicle. More specifically, the basic functions may be, for example, a power battery management function, an electric power steering function, and the like. The assist function refers to a function that can assist the movement or travel of the vehicle, but is not a function on which the movement of the vehicle must be relied upon. For example, the backward collision warning function RCW, the forward collision warning function FCW, LKA functions. Irrelevant functions refer to functions that are not relevant to movement or driving of the vehicle, and the turning on or off of which does not or hardly affect the movement of the vehicle. Such as entertainment functions, etc.
The manufacturer of the vehicle may specify or set which functions of the vehicle are basic functions, which functions are auxiliary functions, and which functions are unrelated functions. For example, the manufacturer of the vehicle may also configure the configuration information a4 for different types of functions. The configuration information a4 is used to indicate in which state the vehicle is in for upgrading the function corresponding to the configuration information a4, or suggest in which state the vehicle is in for upgrading the function corresponding to the configuration information a 4. Specifically, the configuration information a4 of the basic function is used to instruct the upgrading of the basic function when the vehicle is in a parking state. The configuration information a4 of the auxiliary function is used to recommend that the auxiliary function be upgraded with the vehicle in a parked state. The configuration information a4 of the unrelated function is used to indicate that the vehicle can upgrade the unrelated function in the parking state and also upgrade the unrelated function in the driving state.
In some embodiments, when the determined file to be upgraded is used for upgrading the control software of the basic function, if the vehicle is in a moving state, the vehicle may automatically leave the moving state, enter a parking state, disable the basic function, and upgrade the control software of the basic function.
In some embodiments, when the determined file to be upgraded is used to upgrade the control software of the basic function, if the vehicle is in motion, the upgrade control device 110 may control the human-machine interface to display the prompt message D3, where the prompt message D3 is used to prompt the user to actively stop the vehicle in order to upgrade the basic function.
In some embodiments, when the determined file to be upgraded is used for upgrading the control software of the auxiliary function, if the vehicle is in a moving state, the upgrade control device 110 may control the human-machine interface to display the prompt information D4, where the prompt information D4 is used to prompt the user that upgrading the auxiliary function may cause a risk during the movement of the vehicle. For example, the rear collision warning function is upgraded so that the vehicle cannot provide the rear collision warning any more, thereby possibly causing the risk of the rear collision. The user may choose to bear this risk without actively stopping so that the vehicle upgrades the auxiliary function in motion. The user may also actively park so that the auxiliary function is upgraded while the vehicle is parked.
In some embodiments, the software upgrading method provided by the embodiment of the present application may include the steps as shown in fig. 10. The details are as follows.
In step 1001, the upgrade server 200 may obtain an upgrade data package, where the upgrade data package may include at least one upgrade file and upgrade policy information. The upgrade file and the upgrade policy information may refer to the above description, and are not described herein again.
In one illustrative example, the upgrade server 200 may obtain the upgrade data package from a manufacturer or developer of the vehicle 100. In other words, the manufacturer or developer of the vehicle 100 may input the upgrade data package into the upgrade server 200. In this example, the upgrade file and the upgrade policy information in the upgrade data package may each be configured by the manufacturer or developer of the vehicle 100.
In one illustrative example, upgrade server 200 may obtain upgrade files from a manufacturer or developer of vehicle 100. Then, the upgrade server 200 may determine, according to the upgrade file, software or an ECU corresponding to the upgrade file to generate upgrade policy information. Specifically, reference may be made to the above description, which is not repeated herein.
At step 1002, the upgrade server 200 may issue an upgrade data package to the vehicle 100.
For example, the upgrade server 200 may send the upgrade data package to the vehicle 100 whenever or after the upgrade server 200 obtains the upgrade data package from a manufacturer or developer of the vehicle 100. For example, the upgrade server 200 may generate the upgrade policy information according to the upgrade file obtained from the manufacturer or developer of the vehicle 100, and when or after the upgrade file and the upgrade policy information are packaged into a data packet, the upgrade server 200 may send the upgrade data packet to the vehicle 100. It should be noted that, the above description is only made by way of example of the issuing timing or the trigger condition for the upgrade server 200 to issue the upgrade data package to the vehicle 100, and is not limited thereto. In other embodiments, the upgrade server 200 may issue the upgrade data package in response to a software update request sent by the vehicle 100. Alternatively, the upgrade server 200 may periodically detect whether there is a new upgrade data packet to be issued, and if so, the upgrade server 200 issues the upgrade data packet to the vehicle 100. Etc., which are not listed here.
In step 1003, the vehicle 100 performs software upgrade using the at least one upgrade file according to the upgrade policy information, and disables a function corresponding to the at least one upgrade file. Taking the upgrade policy information shown in fig. 3A as an example, when the vehicle 100 is about to update the software FC1 using the upgrade file SW1 and the upgrade file SW1, the vehicle 100 may disable the software FC1 to disable the functions controlled by the FC 1. But the vehicle 100 does not disable the functions controlled by software FC2 and the functions controlled by software FC 3. The step of disabling the software means that the software is closed and is not in a working state any more. Taking the upgrade policy information shown in fig. 3B as an example, when vehicle 100 is about to update software on ECU1 using upgrade file SW1 and upgrade file SW1, vehicle 100 may disable ECU1, and not ECU2 and ECU 3. Thus, software controlled functionality on ECU1 may be disabled without affecting software controlled functionality on ECU2 and ECU 3. Wherein disabling the ECU may refer to causing the ECU to enter a communication silence state. The ECU in communication silence no longer receives the service message and no longer sends the service message to the outside, but may receive the message sent by the upgrade control device 110 or may send the message to the upgrade control device 110.
The embodiment of the present application also provides another software upgrading method, which may be executed by the upgrade control device 110. Referring to fig. 11, the method may include the following steps.
Step 1101, receiving an upgrade data packet from an upgrade server, the upgrade data packet including at least one upgrade file.
Step 1102, under the condition that the first function and the second function of the vehicle are in the available state, controlling the first function to enter a forbidden state, and maintaining the available state of the second function; the first function is controlled by at least target software of the at least one upgrade file, and the second function is controlled by second software other than the target software.
In step 1102, the function disable corresponding to the upgrade file included in the upgrade data package may be disabled, but other functions are not disabled. Then, the upgrade operation of the upgrade file is performed. That is, step 1102 does not require that after determining the file to be upgraded, the related functionality is disabled according to the file to be upgraded. But rather, the functions controlled by the target software of all the upgrade files in the upgrade data package are disabled at or before the start of the upgrade operation on the first upgrade file in the upgrade data package. While other functions in the available state may not be disabled.
In some embodiments, the upgrade data package may include upgrade policy information including an identification of at least one piece of software. The upgrade policy information is used to upgrade the control device 110, disabling the at least one software. The upgrade policy information may be configured by the manufacturer or developer of the vehicle 100, or may be automatically generated by the upgrade server 200. Specifically, reference may be made to the above description, which is not repeated herein.
In one illustrative example, as shown in fig. 12, the upgrade policy information may include an identification of software FC1, an identification of software FC2, and an identification of software FC 2. Software FC1, software FC2, software FC3 may be disabled prior to performing an upgrade operation for an upgrade file. The software can be specifically disabled by referring to the above description, and details are not described herein.
In the embodiments, when the vehicle performs software upgrade, the functions controlled by the software indicated by the upgrade strategy information can be disabled, and other functions in the available state are not disabled, so that the vehicle using experience of the user is improved.
In some embodiments, the upgrade data package may include upgrade policy information including an identification of at least one ECU. The upgrade policy information is used to upgrade the control device 110, disabling the at least one ECU. The upgrade policy information may be configured by the manufacturer or developer of the vehicle 100, or may be automatically generated by the upgrade server 200. Specifically, reference may be made to the above description, which is not repeated herein.
In the embodiments, when the vehicle performs software upgrade, the function of the ECU depending on the upgrade strategy information indication can be disabled, and other functions in the available state are not disabled, so that the vehicle using experience of the user is improved.
In some embodiments, with continued reference to fig. 12, a prompt message D3 may be provided while or after the software FC1, the software FC2, the software FC3 are disabled. Reference may be made in particular to the above description of the embodiment shown in fig. 7 or 9.
Step 1103, upgrading the target software using at least one upgrade file. Specifically, reference may be made to the above description of the upgrade operation, which is not described herein again. For example, referring to fig. 12, when the at least one upgrade file includes a plurality of upgrade files, an upgrade operation of one or more upgrade files may be performed at one time. At yet another time, another upgrade operation of one or more upgrade files is performed.
The software upgrading method provided by the application embodiment not only simplifies the function disabling operation in the upgrading process, but also disables the functions related to the upgrading process, and does not disable other functions, so that a user can use part of functions in the OTA process, and the vehicle using experience of the user is improved.
Referring to fig. 13, an embodiment of the present application provides a software upgrading apparatus. The apparatus may be configured with the upgrade server 200. As shown in fig. 13, the apparatus includes:
an obtaining unit 1310 configured to obtain first upgrade policy information, where the first upgrade policy information is used to indicate at least two functions corresponding to the vehicle 100, where the at least two functions include a first function and a second function, where the first function is in a disabled state, and the second function is in an available state;
a transmitting unit 1320, configured to transmit the first upgrade policy information to the vehicle 100.
The functions of the functional units of the software upgrading device provided in the embodiment of the present application may be implemented by referring to the embodiments shown in fig. 2, which are not described herein again.
The device provided by the embodiment of the application can disable the function required to be disabled along with the software upgrading in the software upgrading process of the vehicle, so that a user can use partial functions in the OTA process, and the vehicle using experience of the user is improved.
Referring to fig. 14, an embodiment of the present application provides a software upgrading apparatus. The apparatus may be configured for the vehicle 100. As shown in fig. 14, the apparatus includes:
an obtaining unit 1410, configured to obtain first upgrade policy information, where the first upgrade policy information is used to indicate at least two functions corresponding to the vehicle 100, where the at least two functions include a first function and a second function, where the first function is in a disabled state, and the second function is in an available state;
an upgrading unit 1420 configured to upgrade the first function according to the first upgrade policy information.
The functions of the functional units of the software upgrading device provided in the embodiment of the present application may be implemented by referring to the embodiments shown in fig. 4, which are not described herein again.
Referring to fig. 15, an embodiment of the application provides a server 1500. The server 1500 may include a processor 1510, memory 1520, a communications interface 1530; the memory 1620 is used to store computer programs. When the computer program stored by the memory 1520 is executed by the processor 1510, the server 1500 may implement the operations of the upgrade server 200 in the embodiments illustrated in FIG. 2 above.
Referring to fig. 16, an embodiment of the present application provides an in-vehicle apparatus 1600. In-vehicle device 1600 may include a processor 1610, memory 1620, and a communication interface 1630; the memory 1620 is used to store computer programs. The in-vehicle device 1600 may perform the operations of the vehicle 100 in the embodiments shown in fig. 4 above when the computer program stored in the memory 1620 is executed by the processor 1610.
The embodiment of the application provides a software upgrading system which can comprise a server 1500 and an in-vehicle device 1600.
The embodiment of the present application provides a chip system, which may include: a processor and an interface circuit; the processor is in circuit connection with the interface for performing the operations of the upgrade server 200 in the embodiments shown in fig. 2 or the vehicle 100 in the embodiments shown in fig. 4 above.
In some embodiments, the chip system further comprises a memory. The memory has stored therein instructions executable by the processor. When executed by the processor, the chipset system may perform the operations of the upgrade server 200 in the embodiments shown in fig. 2 or the vehicle 100 in the embodiments shown in fig. 4.
The embodiment of the application provides an integrated circuit for software upgrading. The integrated circuit includes a memory, a processor coupled to the memory. The memory may store instructions. The processor may execute the instructions stored by the memory to implement the functionality of the upgrade server 200 in the embodiments shown in fig. 2 or the vehicle 100 in the embodiments shown in fig. 4.
Embodiments of the present application provide a computer storage medium storing a computer program, which when executed by a processor, can implement the functions of the upgrade server 200 in the embodiments shown in fig. 2 or the vehicle 100 in the embodiments shown in fig. 4.
Embodiments of the present application provide a computer program product that, when run on one or more processors, may implement the functionality of the upgrade server 200 in the embodiments shown in fig. 2 or the vehicle 100 in the embodiments shown in fig. 4.
Embodiments of the present application provide a processor, which may be configured to perform the method shown in fig. 2 or the method shown in fig. 4.
The method steps in the embodiments of the present application may be implemented by hardware, or may be implemented by software instructions executed by a processor. The software instructions may consist of corresponding software modules that may be stored in Random Access Memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), Erasable Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, a hard disk, a removable hard disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be integral to the processor. The processor and the storage medium may reside in an ASIC.
In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in or transmitted over a computer-readable storage medium. The computer instructions may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.
It is to be understood that the various numerical references referred to in the embodiments of the present application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of the present application.

Claims (30)

1. A method of upgrading software, the method comprising:
acquiring first upgrading strategy information, wherein the first upgrading strategy information is used for indicating at least two functions corresponding to a first vehicle, the at least two functions comprise a first function and a second function, the first function is in a forbidden state, and the second function is in an available state;
sending the first upgrade policy information to the first vehicle.
2. The method of claim 1, wherein the first upgrade policy information is used to indicate that the first function is disabled and the second function is available when the first vehicle upgrades the first function.
3. The method of claim 1 or 2, wherein the first upgrade policy information is further used to indicate that the first function and a third function are both disabled, and wherein the third function is associated with the first function.
4. The method of any of claims 1-3, wherein the first upgrade policy information is further used to indicate that the second function is disabled when the first vehicle is upgrading the second function.
5. The method of claim 4, wherein the first upgrade policy information is further used to instruct the first vehicle to upgrade the first function and the second function in sequence, and wherein the first function is available when the second function is upgraded.
6. The method according to any one of claims 1-5, wherein the first upgrade policy information is further used to instruct the first vehicle to provide first prompt information through a Human Machine Interface (HMI) when upgrading the first function, the first prompt information being used to prompt a user that the first function is in a disabled state and/or to prompt a user that the second function is in an available state.
7. A method of upgrading software, the method comprising:
acquiring first upgrading strategy information, wherein the first upgrading strategy information is used for indicating at least two functions corresponding to a first vehicle, the at least two functions comprise a first function and a second function, the first function is in a forbidden state, and the second function is in an available state;
and upgrading the first function according to the first upgrading strategy information.
8. The method of claim 7, wherein the first upgrade policy information is used to indicate that the first function is disabled and the second function is available when the first vehicle upgrades the first function.
9. The method of claim 7 or 8, wherein the first upgrade policy information is further used to indicate that the first function and a third function are both disabled, and wherein the third function is associated with the first function.
10. The method of any of claims 7-9, wherein the first upgrade policy information is further used to indicate that the second function is disabled when the first vehicle is upgrading the second function.
11. The method of claim 10, wherein the first upgrade policy information is further used to instruct the first vehicle to upgrade the first function and the second function in sequence, and wherein the first function is available when the second function is upgraded.
12. The method of any of claims 7-11, wherein the first upgrade policy information is further configured to instruct the first vehicle, when upgrading the first function, to provide a first prompt via a Human Machine Interface (HMI), the first prompt being configured to prompt a user that the first function is disabled and/or to prompt a user that the second function is available.
13. A software upgrading apparatus, characterized in that the apparatus comprises:
an obtaining unit, configured to obtain first upgrade policy information, where the first upgrade policy information is used to indicate at least two functions corresponding to a first vehicle, where the at least two functions include a first function and a second function, the first function is in a disabled state, and the second function is in an available state;
and the sending unit is used for sending the first upgrading strategy information to the first vehicle.
14. The apparatus of claim 13, wherein the first upgrade policy information is to indicate that the first function is disabled and the second function is available when the first vehicle upgrades the first function.
15. The apparatus of claim 13 or 14, wherein the first upgrade policy information is further configured to indicate that the first function and a third function are both disabled, and wherein the third function is associated with the first function.
16. The apparatus of any of claims 13-15, wherein the first upgrade policy information is further to indicate that the second function is disabled when the first vehicle is upgrading the second function.
17. The apparatus of claim 16, wherein the first upgrade policy information is further configured to instruct the first vehicle to upgrade the first function and the second function in sequence, and wherein the first function is available when the second function is upgraded.
18. The apparatus of any of claims 13-17, wherein the first upgrade policy information is further configured to instruct the first vehicle, when upgrading the first function, to provide a first prompt via a Human Machine Interface (HMI), the first prompt being configured to prompt a user that the first function is disabled and/or to prompt a user that the second function is available.
19. A software upgrading apparatus, characterized in that the apparatus comprises:
an obtaining unit, configured to obtain first upgrade policy information, where the first upgrade policy information is used to indicate at least two functions corresponding to a first vehicle, where the at least two functions include a first function and a second function, the first function is in a disabled state, and the second function is in an available state;
and the upgrading unit is used for upgrading the first function according to the first upgrading strategy information.
20. The apparatus of claim 19, wherein the first upgrade policy information is to indicate that the first function is disabled and the second function is available when the first vehicle upgrades the first function.
21. The apparatus of claim 19 or 20, wherein the first upgrade policy information is further configured to indicate that the first function and a third function are both disabled, and wherein the third function is associated with the first function.
22. The apparatus of any of claims 19-21, wherein the first upgrade policy information is further configured to indicate that the second function is disabled when the first vehicle is upgrading the second function.
23. The apparatus of claim 22, wherein the first upgrade policy information is further configured to instruct the first vehicle to upgrade the first function and the second function in sequence, and wherein the first function is available when the second function is upgraded.
24. The apparatus of any of claims 19-23, wherein the first upgrade policy information is further configured to instruct the first vehicle, when upgrading the first function, to provide a first prompt via a Human Machine Interface (HMI), the first prompt being configured to prompt a user that the first function is disabled and/or to prompt a user that the second function is available.
25. A server comprising a processor, a memory, and a communication interface; wherein the memory is for storing a computer program; the processor is adapted to execute the computer program to implement the method of any of claims 1-6.
26. The vehicle-mounted equipment is characterized by comprising a processor, a memory and a communication interface; wherein the memory is for storing a computer program; the processor is adapted to execute the computer program to implement the method of any of claims 7-12.
27. A chip system comprising a processor, a memory and interface circuitry, the memory for storing computer instructions; the processor is configured to execute the computer instructions to implement the method of any one of claims 1-6 or the method of any one of claims 7-12.
28. An integrated circuit for software upgrade, comprising:
a memory for storing computer instructions;
and a processor coupled with the memory for executing the computer instructions to implement the method of any of claims 1-6 or the method of any of claims 7-12.
29. A computer storage medium, characterized in that the computer storage medium has stored thereon a computer program which, when executed by a processor, carries out the method of any one of claims 1-6 or the method of any one of claims 7-12.
30. A computer program product, characterized by a computer program for implementing the method of any one of claims 1-6 or the method of any one of claims 7-12, when the computer program product is run on one or more processors.
CN202180000695.1A 2021-04-02 2021-04-02 Software upgrading method and device Pending CN113227967A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/085370 WO2022205443A1 (en) 2021-04-02 2021-04-02 Software upgrade method and apparatus

Publications (1)

Publication Number Publication Date
CN113227967A true CN113227967A (en) 2021-08-06

Family

ID=77081308

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180000695.1A Pending CN113227967A (en) 2021-04-02 2021-04-02 Software upgrading method and device

Country Status (2)

Country Link
CN (1) CN113227967A (en)
WO (1) WO2022205443A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024011617A1 (en) * 2022-07-15 2024-01-18 华为技术有限公司 Upgrade method and device

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106227561A (en) * 2016-07-20 2016-12-14 杭州华三通信技术有限公司 A kind of cloud operating system update method and device
CN108845562A (en) * 2018-06-09 2018-11-20 铠龙东方汽车有限公司 A kind of intelligent vehicle-carried service system based on car networking
CN110032382A (en) * 2019-03-25 2019-07-19 深圳猛犸电动科技有限公司 A kind of vehicle electronic control unit upgrade method, system and terminal device
CN110234074A (en) * 2018-03-06 2019-09-13 通用汽车环球科技运作有限责任公司 The behavioral characteristics availability of vehicle maps
CN110955444A (en) * 2019-12-04 2020-04-03 福尔达车联网(深圳)有限公司 Vehicle ECU upgrading method, system, terminal and storage medium
CN112099829A (en) * 2020-09-21 2020-12-18 华人运通(上海)云计算科技有限公司 Vehicle upgrade control method and system, OTA background and vehicle
WO2020253404A1 (en) * 2019-06-21 2020-12-24 华为技术有限公司 Software upgrade method, device and system
CN112306524A (en) * 2020-10-19 2021-02-02 上海仙塔智能科技有限公司 System upgrading method, electronic device and computer storage medium
CN112463190A (en) * 2020-11-24 2021-03-09 广州橙行智动汽车科技有限公司 Vehicle upgrading method and device

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109558161A (en) * 2018-11-27 2019-04-02 北京车和家信息技术有限公司 Upgrade packet processing method, device and OTA cloud server
JP7200708B2 (en) * 2019-01-31 2023-01-10 富士通株式会社 In-vehicle system and ECU
CN112134940A (en) * 2020-09-17 2020-12-25 广州汽车集团股份有限公司 OTA upgrade task life cycle strategy management method

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106227561A (en) * 2016-07-20 2016-12-14 杭州华三通信技术有限公司 A kind of cloud operating system update method and device
CN110234074A (en) * 2018-03-06 2019-09-13 通用汽车环球科技运作有限责任公司 The behavioral characteristics availability of vehicle maps
CN108845562A (en) * 2018-06-09 2018-11-20 铠龙东方汽车有限公司 A kind of intelligent vehicle-carried service system based on car networking
CN110032382A (en) * 2019-03-25 2019-07-19 深圳猛犸电动科技有限公司 A kind of vehicle electronic control unit upgrade method, system and terminal device
WO2020253404A1 (en) * 2019-06-21 2020-12-24 华为技术有限公司 Software upgrade method, device and system
CN110955444A (en) * 2019-12-04 2020-04-03 福尔达车联网(深圳)有限公司 Vehicle ECU upgrading method, system, terminal and storage medium
CN112099829A (en) * 2020-09-21 2020-12-18 华人运通(上海)云计算科技有限公司 Vehicle upgrade control method and system, OTA background and vehicle
CN112306524A (en) * 2020-10-19 2021-02-02 上海仙塔智能科技有限公司 System upgrading method, electronic device and computer storage medium
CN112463190A (en) * 2020-11-24 2021-03-09 广州橙行智动汽车科技有限公司 Vehicle upgrading method and device

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024011617A1 (en) * 2022-07-15 2024-01-18 华为技术有限公司 Upgrade method and device

Also Published As

Publication number Publication date
WO2022205443A1 (en) 2022-10-06

Similar Documents

Publication Publication Date Title
US11036484B2 (en) Software update management
CN111284428A (en) Upgradable vehicle
WO2018142751A1 (en) Control device, program update method, and computer program
JP6702269B2 (en) Control device, control method, and computer program
US10970063B2 (en) Relay apparatus, transfer method, and computer program
US20100138080A1 (en) Remote management of vehicle modules based on geographic location
US20200272455A1 (en) Vehicle controller configuration backup and restoration using data snapshots
US20220158898A1 (en) Determining whether a vehicle should be configured for a different region
CN108008964B (en) Vehicle-mounted network system, management method of vehicle-mounted software and vehicle
US20240069906A1 (en) Server, software update system, distribution method, and non-transitory storage medium
US20130103230A1 (en) Control device
CN115543395A (en) Vehicle-mounted ECU upgrading method and device, electronic equipment and storage medium
CN113227967A (en) Software upgrading method and device
EP4160391A1 (en) Systems and methods for safe over-the-air update of electronic control units in vehicles
US20210105321A1 (en) Vehicle software check
KR20180086907A (en) System and method for updating firmware of blackbox for vehicle
US20240201977A1 (en) Server, vehicle, and software management method
US20240118885A1 (en) User equipment, software update system, control method, and non-transitory storage medium
US20240118886A1 (en) Mobile equipment and software distribution system
EP3933572B1 (en) Software update device, software update method, non-transitory storage medium, and vehicle
US20220334821A1 (en) Ota master, update control method, non-transitory storage medium, and ota center
US20240126535A1 (en) Vehicle and software update system
US20240143311A1 (en) Mobile terminal and software update system
US20220005292A1 (en) Center device, data communication system, and program product for controlling data distribution
US20240103839A1 (en) Mobile terminal and software distribution system

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