Sensor software changing method and device and intelligent driving equipment

Abstract

The invention discloses a sensor software changing method. The method is applied to the intelligent driving equipment and comprises the following steps: after a sensor is connected to the intelligent driving equipment, acquiring a first software version number of the sensor; then, a second software version number of a first software package corresponding to the sensor is obtained, and the first software package is pre-stored in the intelligent driving equipment; and finally, if the first software version number is inconsistent with the second software version number, a first software package is sent to the sensor, and the first software package is used for the sensor to carry out software change. Therefore, the sensor software can be quickly changed without networking through the pre-stored software package.

Description

Sensor software changing method, device and intelligent driving equipment

[0001] The present application relates to the field of intelligent driving, and in particular to a sensor software change method, device and intelligent driving equipment.

[0002] The advancement of automobile intelligence is inseparable from the development of sensors. As the level of intelligence increases, the environment that needs to be perceived becomes more and more complex, and the number of sensors installed on cars also increases. Currently, cars with assisted driving functions sold on the market are often equipped with multiple sensors, such as lidar, millimeter-wave radar, etc. The data collected by the sensors will be transmitted to the on-board computing platform, which will perform various processing. Therefore, the software version of the on-board computing platform and the software version of the sensor must be consistent.

[0003] In the scenario where a sensor needs to be replaced due to a fault or hardware update, if the software version of the connected sensor is inconsistent with the software version running on the smart driving device, the function of the sensor will become unusable. In this scenario, in order to ensure the normal use of the sensor, the sensor software needs to be changed in a timely manner.

[0004] Currently, the software update method of sensors mainly includes over-the-air (OTA) update. However, the OTA update method depends on the quality of network communication and requires Internet access to download software packages. The process of downloading software packages is time-consuming and wastes traffic.

[0005] Summary of the invention

[0006] The present application provides a sensor software change method, device and intelligent driving equipment, which can realize rapid change of sensor software without networking.

[0007] The first aspect of the present application provides a sensor software change method, which is applied to an intelligent driving device. After the sensor is connected to the intelligent driving device, the intelligent driving device will query and obtain the first software version number of the sensor. Then, the intelligent driving device will obtain the second software version number of the first software package corresponding to the sensor, and the first software package is pre-stored in the intelligent driving device. Subsequently, the intelligent driving device compares the first software version number with the second software version number. If the two are inconsistent, the first software package is sent to the sensor so that the sensor performs software changes according to the first software package.

[0008] In this application, after detecting that a sensor is connected, the intelligent driving device will actively query and obtain the first software version number of the sensor to realize automatic version query after the sensor is inserted without manual intervention. After obtaining the first software version number of the sensor, the intelligent driving device will obtain the second software version number of the first software package corresponding to the sensor from the local, and compare the second software version number with the first software version number to check the software version of the sensor. If it is determined that the first software version number and the second software version number are inconsistent, the first software package is sent to the sensor so that the sensor can make software changes according to the first software package, thereby ensuring that the software version of the sensor is consistent with that of the intelligent driving device, so that the function of the sensor can be used normally. By adopting this method, by pre-storing the software package corresponding to the sensor locally, it is possible to realize the rapid change of the sensor software without networking when the software version of the sensor needs to be changed, thereby eliminating the operation of downloading online, and also eliminating the participation of maintenance personnel, thereby improving the efficiency of maintenance.

[0009] In a possible implementation, the first software package may be stored in the intelligent driving device in the following manner:

[0010] First, a second software package of the intelligent driving device is obtained from the network; then, the intelligent driving device obtains M software packages corresponding to M types of sensors from the second software package, where M is a positive integer greater than or equal to 1; when a storage condition is met, N software packages are obtained and stored from the M software packages, where N is less than or equal to M, and the N software packages include the first software package.

[0011] In this possible implementation, before the software version of the connected sensor is detected and changed, the intelligent driving device stores the software package corresponding to the sensor locally in advance to achieve offline upgrade of the sensor, thereby avoiding network problems when the software package is downloaded online and achieving rapid software changes without networking. In addition, after the intelligent driving device obtains the corresponding software upgrade package, that is, the second software package, it generally stores the complete second software package. However, in order to avoid the problem of the cached software package being too large and occupying the remaining storage space of the intelligent driving device, the type and number of software packages cached in the remaining storage space of the memory can be flexibly adjusted to improve the utilization of the storage space. When the storage conditions are met, only N software packages that can meet the requirements are cached, and the N software packages include the first software package corresponding to the sensor, thereby avoiding the problem of wasting storage space.

[0012] In a possible implementation, the storage condition includes: a relationship between the sizes of the N software packages and the remaining storage space of the memory of the intelligent driving device satisfies a preset condition.

[0013] In this possible implementation, in order to avoid wasting storage space, by comparing the sizes of N software packages among the M software packages with the remaining storage space of the memory, the N software packages are stored only when preset conditions are met, thereby avoiding the problem of excessive cache space occupation and achieving full utilization of the remaining storage space in the memory of the intelligent driving device.

[0014] In a possible implementation, before obtaining the first software version number of the sensor, access authentication is performed on the sensor, and after the access authentication passes, a communication connection is established with the sensor.

[0015] In this possible implementation, by authenticating the access of the sensor, it can be ensured that the connected sensor and the intelligent driving device can communicate normally, and when the communication failure is eliminated, the subsequent automatic change of the sensor software can be ensured.

[0016] In a possible implementation, the main steps of obtaining the first software version number of the sensor include: sending a version query request to the sensor, and receiving the first software version number fed back by the sensor.

[0017] In this possible implementation, after the intelligent driving device detects that a sensor is connected, it will actively send a version query request to the sensor to realize automatic query of the version after insertion, and complete the rapid upgrade after insertion if the version change is met, without the need for maintenance personnel to participate in the software change process.

[0018] The second aspect of the present application provides a sensor software change device. The beneficial effects can be found in the description of the first aspect and will not be repeated here. The device has the function of implementing the behavior in the method example of the first aspect. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the device is applied to an intelligent driving device, including:

[0019] An acquisition module, used to acquire a first software version number of the sensor after the sensor is connected to the intelligent driving device;

[0020] The acquisition module is further used to acquire a second software version number of a first software package corresponding to the sensor, where the first software package is pre-stored in the intelligent driving device;

[0021] The communication module is used to send a first software package to the sensor if the first software version number is inconsistent with the second software version number, and the first software package is used for the sensor to perform software changes.

[0022] In a possible implementation, the acquisition module is further used to acquire a second software package of the intelligent driving device;

[0023] The acquisition module is further used to acquire M software packages corresponding to the M types of sensors from the second software package, where M is a positive integer greater than or equal to 1;

[0024] The acquisition module is further configured to acquire and store N software packages from the M software packages when a storage condition is met, where N is less than or equal to M, and the N software packages include the first software package.

[0025] In a possible implementation, the storage condition includes: a relationship between the sizes of the N software packages and the remaining storage space of the memory of the intelligent driving device satisfies a preset condition.

[0026] In a possible implementation, the communication module is further used for:

[0027] After detecting that the sensor is connected to the intelligent driving device, the sensor is authenticated, and after the access authentication is passed, a communication connection is established with the sensor.

[0028] In a possible implementation, the acquisition module is specifically used for:

[0029] After sending a version query request to the sensor through the communication module, the first software version number fed back by the sensor is received through the communication module.

[0030] The modules described herein can perform the corresponding functions in the method example of the first aspect mentioned above. Please refer to the detailed description in the method example for details, which will not be repeated here.

[0031] A third aspect of the present application provides a sensor software change device, comprising at least one memory and a processor, the memory storing code, and the processor being configured to execute the code so that the sensor software change device executes the method in the above-mentioned first aspect or any possible implementation of the first aspect.

[0032] The fourth aspect of the present application provides an intelligent driving device, comprising at least one sensor and a controller, wherein the controller executes computer-executable instructions to implement the method in the above-mentioned first aspect or any possible implementation manner of the first aspect, or the controller is the sensor software change device of the above-mentioned second aspect or third aspect.

[0033] A fifth aspect of the present application provides a computer storage medium storing a computer program. When the program is executed by a computer, the computer implements the method in the first aspect or any possible implementation of the first aspect.

[0034] A sixth aspect of the present application provides a computer program product, which, when executed by a computer, implements the method in the above-mentioned first aspect or any possible implementation manner of the first aspect.

[0035] In a seventh aspect, the present application provides a chip system, which includes a processor for implementing the functions of the intelligent driving device in the above-mentioned methods. In a possible design, the chip system also includes a memory for storing program instructions and / or data. The chip system can be composed of a chip, or it can include a chip and other discrete devices.

[0036] The solutions of the second to seventh aspects mentioned above are used to implement or cooperate with the method of the first aspect or any possible implementation method thereof, and therefore can achieve the same or corresponding beneficial effects as the first aspect, and will not be repeated here.

[0037] FIG1 is an application scenario diagram of a sensor software modification method provided in an embodiment of the present application;

[0038] FIG2 is a flow chart of an OTA software upgrade method provided in an embodiment of the present application;

[0039] FIG3 is a schematic diagram of a flow chart of a method for upgrading local software provided in an embodiment of the present application;

[0040] FIG4 is a flow chart of a sensor software modification method provided in an embodiment of the present application;

[0041] FIG5 is a schematic diagram showing an operation display of a sensor software modification method provided in an embodiment of the present application;

[0042] FIG6 is a flow chart of another sensor software modification method provided in an embodiment of the present application;

[0043] FIG7 is a schematic diagram of the structure of a sensor software changing device provided in an embodiment of the present application;

[0044] FIG8 is a schematic diagram of the structure of another sensor software changing device provided in an embodiment of the present application;

[0045] FIG9 is a schematic diagram of the structure of an intelligent driving device provided in an embodiment of the present application.

[0046] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0047] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only partial embodiments of the present invention, not all embodiments. Based on the embodiments in the present invention, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present invention. It is known to those skilled in the art that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0048] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or modules is not necessarily limited to those steps or modules that are clearly listed, but may include other steps or modules that are not clearly listed or inherent to these processes, methods, products or devices.

[0049] The term "and / or" in this application can be a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this application generally indicates that the associated objects before and after are in an "or" relationship.

[0050] It should also be noted that, in some alternative implementations, the functions / acts noted may occur out of the order of the drawings. For example, two figures shown in succession may in fact occur substantially simultaneously or may sometimes be performed in the reverse order, depending on the functions / acts involved.

[0051] In the embodiments of the present application, unless otherwise specified, the meaning of "at least one" refers to one or more, and the meaning of "plurality" refers to two or more. It is understood that in the present application, "when", "if" and "if" all refer to the device making corresponding processing under certain objective circumstances, and do not limit the time, nor do they require that there must be a judgment action when the device is implemented, nor do they mean that there are other limitations. In addition, the special word "exemplary" means "used as an example, embodiment or illustrative". Any embodiment described as "exemplary" is not necessarily interpreted as being superior or better than other embodiments.

[0052] For ease of understanding, the following describes the scenarios in which the sensor software change method provided in the embodiments of the present application is applied. The sensor software change method is applied to an intelligent driving device. It should be noted that the types and application scopes of the intelligent driving device are relatively wide and are not limited to intelligent vehicles. The intelligent driving device can be an intelligent vehicle, or an intelligent machine device independent of the vehicle, a mobile terminal, etc., such as an intelligent robot or other intelligent device that can run a computer program of the sensor software change method.

[0053] Taking the intelligent driving device as an example of an intelligent vehicle, the application scenario of the sensor software change method provided in the embodiment of the present application is illustrated. Referring to Figure 1, Figure 1 is an application scenario diagram of the sensor software change method provided in the embodiment of the present application, and the method is applied to an intelligent driving device 100, which is provided with at least one sensor 200 and at least one controller 300. Sensors 200 and sensors 200, sensors 200 and controllers 300, and controllers 300 and controllers 300 can be connected to each other by wire or wireless. It should be understood that Figure 1 is only a schematic diagram, and the connection relationship between the sensor 200 and the controller 300 is not drawn in Figure 1. The intelligent driving device 100 may also include other devices, which are also not drawn in Figure 1.

[0054] Sensors are consumables. The sensor 200 installed on the intelligent driving device 100 is very likely to be damaged due to collisions, failures, and other reasons, as well as hardware replacement, which may lead to the need to replace one or more sensors. In this case, after the replaced sensor 200 is connected to the intelligent driving device 100, if the software version of the sensor 200 is inconsistent with the software version of the intelligent driving device 100, it is very likely that the version inconsistency will cause the function of the sensor 200 to be unavailable. For example, the intelligent driving device 100 has been upgraded to the first version. If the sensor is damaged and unavailable, the replaced sensor 200 is connected, and the software version of the sensor 200 is the second version, then the first and second versions are very likely to be incompatible, resulting in the unavailability of the sensor 200 function. Therefore, it is necessary to change the software of the replaced sensor 200.

[0055] The intelligent driving device 100 is a comprehensive system that integrates environmental perception, planning and decision-making, multi-level assisted driving and other functions. It is equipped with advanced sensing systems, decision-making systems, and execution systems, and uses new technologies such as information communication, the Internet, big data, cloud computing, and artificial intelligence. It has partial or full automatic driving functions and is a new generation of vehicles that gradually transform from simple transportation tools to intelligent mobile spaces. In the embodiments of the present application, the functions of the intelligent driving device 100 can also be performed by a module (such as a chip) in the intelligent driving device 100, or by a control subsystem that includes an intelligent driving function. The embodiments of the present application do not limit the specific technology and specific device form used by the intelligent driving device 100.

[0056] The sensor 200 may be a laser radar, a millimeter wave radar, an ultrasonic radar, a camera, an inertial navigation system, etc. The intelligent driving device 100 with assisted driving capability is generally equipped with a variety of sensors. Among them, the sensor 200 may specifically be a single-port device, that is, the sensor 200 includes only one data transmission port, and the sensor 200 transmits data to the controller 300 through the data transmission port. Optionally, in addition to a single-port device, the sensor 200 may also be a multi-port device, which is not limited here. The embodiments of the present application do not limit the specific technology and specific device form adopted by the sensor 200.

[0057] In the embodiment of the present application, only a single connected sensor is used as an object for description. In actual operation, the type and quantity of the at least one sensor 200 connected to the intelligent driving device 100 can be set according to actual conditions.

[0058] The controller 300 is the core electronic control unit for implementing vehicle control decisions. In the embodiment of the present application, the software version of the sensor 200 is queried by the controller 300, and when the versions do not match, the software package is sent to the sensor 200 to implement the software change of the sensor 200. The embodiment of the present application does not limit the specific technology and specific device form adopted by the controller 300.

[0059] Optionally, the intelligent driving device 100 may include two or more controllers 300, and a redundant design may be formed between the two or more controllers 300. When any one of the controllers fails, another controller may assist in completing the data processing process, thereby avoiding single-point failure of the controller 300 and affecting the safety and reliability of the intelligent driving device 100.

[0060] It should be noted that two or more controllers 300 may be devices of the same type, or in some cases, devices of different types. Furthermore, the controller 300 is only an example of the present application, and other possible implementations may include other types of controllers, such as a vehicle controller, and sensors corresponding to the controller.

[0061] It is understandable that the above-mentioned components or devices can communicate via a controller area network (CAN) or an in-vehicle Ethernet, etc., and this application does not limit this. In addition, the installation positions of the sensor 200 and the controller 300 on the intelligent driving device 100 shown in FIG1 are only for illustration and are not limited.

[0062] In an extended application scenario, the application scenario also includes a cloud server 400 or a host computer 500 .

[0063] The cloud server 400 is a software platform that uses application virtualization technology, integrating multiple functions such as software search, download, use, management, and backup. Corresponding to the embodiment of the present application, the first software package corresponding to the sensor pre-stored in the intelligent driving device 100 can be obtained from the cloud server 400. When the cloud server 400 provides, for example, a software upgrade service to the intelligent driving device 100, the intelligent driving device 100 can obtain the entire software upgrade package corresponding to the intelligent driving device from the cloud server 400. The embodiments of the present application do not limit the specific technology and specific device form adopted by the cloud server 400.

[0064] The host computer 500 refers to a computer or single-chip microcomputer that can directly send operating instructions, generally providing a user operation interactive interface and displaying feedback data to the user. Typical device types include computers, mobile phones, tablets, panels, touch screens, etc. Corresponding to the embodiment of the present application, the first software package corresponding to the sensor pre-stored in the intelligent driving device 100 can be obtained from the host computer 500. When the host computer 500 provides, for example, a software upgrade service to the intelligent driving device 100, the host computer 500 sends a software upgrade package containing the first software package to the intelligent driving device 100. Figure 1 illustrates that the host computer 500 (taking a personal computer as an example) communicates with the controller 300 in the intelligent driving device 100 via the CAN bus. The embodiment of the present application does not limit the specific technology and specific device form adopted by the host computer 500.

[0065] It is understandable that the entire software upgrade package corresponding to the intelligent driving device 100 can be obtained from the cloud server 400 or the host computer 500, or can be obtained from other devices. It can be set according to actual needs or experiments. This is only for example and not limited.

[0066] The above introduces the application scenarios of the sensor software change method provided in the embodiment of the present application. The following will introduce in detail the implementation process of the sensor software change method provided in the embodiment of the present application.

[0067] First of all, in order to better understand the solutions of the embodiments of the present application, the relevant terms and concepts that may be involved in the embodiments of the present application are introduced below.

[0068] (1) Intelligent driving equipment

[0069] Intelligent driving equipment may include intelligent vehicles, and may also include intelligent machine equipment independently developed for various specific business scenarios, such as intelligent robots and other intelligent devices that can run computer programs of sensor software change methods. Among them, taking intelligent vehicles as an example, intelligent driving equipment may include intelligent devices such as on-board computers, on-board controllers, and vehicle driving control systems. Due to the rapid development of intelligent driving, intelligent vehicles can currently include the following levels: Level L1, assisted driving. It can help drivers complete certain driving tasks, and can only help complete one driving operation. At the same time, the driver needs to monitor the driving environment and be ready to take over at any time. Representative technologies include: lane keeping system, cruise control system. Level L2, partial automation. It can automatically accelerate, decelerate and turn at the same time, which means that the adaptive cruise system and lane keeping system can work at the same time. Level L3, conditional automation. In a specific environment, the vehicle can achieve automatic acceleration, deceleration and steering without the need for driver operation, and there is no need to monitor the surrounding environment of the vehicle body. However, it is necessary to be ready to take over the vehicle at any time to deal with situations that the autonomous driving system cannot handle. Level L4, highly automated. It can achieve driving without a driver throughout the entire process, but there are also restrictions. For example, the vehicle speed is limited to a certain value and the driving area is relatively fixed. And after achieving this level of autonomous driving, there is no need to install brake and accelerator pedals. Level 5 is fully automated. It can fully adaptively drive and adapt to any driving environment.

[0070] (2) Sensor

[0071] A sensor is a detection device that can sense the information being measured and can transform the sensed information into electrical signals or other required forms of information output according to certain rules to meet the requirements of information transmission, processing, storage, display, recording and control. The characteristics of sensors include: miniaturization, digitization, intelligence, multi-function, systematization and networking. It is the first link to achieve automatic detection and automatic control. Through sensors, self-driving cars can identify roads, vehicles on the road, pedestrians, obstacles and / or basic transportation facilities.

[0072] The advancement of intelligence is inseparable from the development of sensors. As the level of intelligence increases, the environment that needs to be sensed becomes more and more complex, and the number of sensors will further increase. Cars with assisted driving capabilities are often equipped with multiple sensors, such as lidar, millimeter-wave radar, ultrasonic radar, camera, inertial navigation system, etc.

[0073] (3) Unified diagnosis service (UDS)

[0074] The development, adjustment, implementation and maintenance of different diagnostic communication protocols will bring unnecessary costs to vehicle manufacturers and system suppliers. In order to solve this problem, different technical protocols and data communication principles are compiled into an international standard, usually called UDS. UDS is a universal automotive diagnostic protocol that is independent of the data link. UDS is oriented to the application layer in the Open System Interconnection (OSI) model and can be implemented on different automotive buses.

[0075] In UDS, the diagnostic session control service is used to enable the diagnostic session of the server. The diagnostic session is associated with a series of diagnostic services or diagnostic functions. Only the diagnostic services supported by the currently activated diagnostic session can be responded to. There are usually more than two diagnostic sessions, including: a default session and several non-default sessions. Only one diagnostic session is active at the same time, and the server can associate diagnostic services by responding to the diagnostic session.

[0076] (4) Host computer

[0077] The host computer refers to a computer device that can directly issue control commands, for example, smart handheld terminal devices such as personal computers, mobile phones, and tablet computers, as well as smart wearable devices such as smart bracelets and smart watches. The host computer, corresponding to the lower computer, is used to send instructions to the lower computer and receive feedback data from the lower computer. Conceptually, the controller and the service provider are the host computer, and the controlled and served are the lower computers. In the embodiment of the present application, the host computer is mainly used to realize the proximal upgrade of the sensor software.

[0078] (5) Cloud

[0079] The cloud is a software platform that uses application virtualization technology, integrating multiple functions such as software search, download, use, management, and backup. Through this platform, various commonly used software can be encapsulated in an independent virtualized environment, so that the application software will not be coupled with the system, achieving the purpose of green software use. In the embodiment of the present application, the cloud is mainly used to store the software package of the sensor and change the software version of the sensor. The cloud usually includes a cloud server.

[0080] The professional terms provided in the embodiments of the present application are introduced above. In order to better understand the technical solutions provided in the embodiments of the present application, the software upgrade method used in the prior art is introduced below by taking the intelligent driving device as an example of an intelligent vehicle.

[0081] (1) OTA upgrade

[0082] OTA technology is a technology for downloading data through a wireless network. It refers to the technology of upgrading the system or application by downloading the upgrade package on the remote server through the wireless network. It is usually used in the upgrade process of the fixed version of the system software of terminal devices such as mobile phones and tablets. The current upgrade method mainly adopts the single package upgrade strategy. Specifically, the terminal device initiates a software version detection, and the server returns a download path to the terminal device, so that the terminal device obtains an OTA upgrade package according to the download path, and then upgrades the version according to the OTA upgrade package.

[0083] Corresponding to the application scenario of this solution, the intelligent driving device can query the sensor version, and when it recognizes that the new sensor version can be updated, trigger the OTA upgrade method, and download the updated software package from the cloud to the local storage for upgrading. Please refer to Figure 2, which is a flow chart of the OTA upgrade method provided in the embodiment of the present application. The OTA upgrade method includes the following steps 201 to 206.

[0084] Step 201: After detecting that the old sensor needs to be replaced, a new sensor is connected to the intelligent driving device.

[0085] Step 202: After the new sensor access authentication is passed, the intelligent driving device queries the software version number of the new sensor to detect whether the software version of the new sensor is consistent with the software version of the intelligent driving device.

[0086] Step 203: The intelligent driving device verifies whether the version number of the new sensor is a matching version number.

[0087] Step 204 , if there is no match, request an upgrade package corresponding to the target version of the new sensor from the cloud.

[0088] Step 205 , downloading the upgrade package of the target version corresponding to the new sensor from the cloud to the intelligent driving device.

[0089] Step 206: The intelligent driving device sends an upgrade package corresponding to the target version to the new sensor to upgrade the new sensor to the target software version.

[0090] It is understandable that the above method first downloads the latest software upgrade package from a software platform, such as the cloud, through a wireless communication network, and then upgrades the software based on the software upgrade package. However, with the diversification of software functions, OTA technology has the following disadvantages:

[0091] a) The software upgrade packages that need to be downloaded through the wireless network will become larger and larger, and the number of downloads will increase, which is not only time-consuming and wastes traffic, but also makes the data traffic overhead faced by users increase.

[0092] b) In an environment with poor network signals, the communication signal of the intelligent driving device itself is poor and unstable, and it is impossible to successfully download multiple software packages in a short period of time, and thus it is impossible to implement software upgrades in a timely manner.

[0093] c) In actual maintenance scenarios, after connecting a new sensor, there are many reasons why the sensor function may become unavailable. Maintenance personnel cannot immediately determine whether the unavailability is caused by a mismatch in the sensor software version. Therefore, they will not immediately connect to the network and upgrade, which further increases the maintenance time and communication and learning costs.

[0094] (2) Local upgrade of the host computer

[0095] Proximal upgrade mainly refers to the maintenance personnel pre-flash the new sensor to the target version, and then replace the new sensor with the smart driving device to achieve version matching. Please refer to Figure 3, which is a flow chart of the proximal software upgrade method provided in the embodiment of the present application, and the main steps are as follows:

[0096] Step 301: Maintenance personnel query the current software version of the intelligent driving device.

[0097] Step 302: The intelligent driving device feeds back the current software version number to the maintenance personnel.

[0098] Step 303 : The maintenance personnel downloads a software package of the new sensor that matches the software version of the smart driving device from the cloud.

[0099] Step 304: The maintenance personnel upgrades the version of the new sensor using a sensor-specific flash tool.

[0100] Step 305: Connect the upgraded new sensor to the intelligent driving device.

[0101] However, this technology has the following disadvantages:

[0102] a) Special equipment is required to refresh the sensor's firmware, which is a relatively complicated operation;

[0103] b) It requires high skills from maintenance personnel and requires the assistance of maintenance personnel in software upgrades.

[0104] In order to overcome the defects of the sensor upgrade method shown in Figures 2 and 3, the present application provides a sensor software change method. For ease of understanding, the following is a specific description of a sensor software change method provided in an embodiment of the present application in conjunction with the accompanying drawings and application scenarios. It can be understood that the intelligent driving device shown in Figure 1 is only one of the application scenarios, and the sensor software change method can also be applied to intelligent driving devices such as intelligent robots, which is not specifically limited here.

[0105] Please refer to FIG. 4 , which is a flow chart of a sensor software change method provided in an embodiment of the present application. In one optional embodiment, the sensor software change method shown in FIG. 4 can be applied to the intelligent driving device shown in FIG. 1 . As shown in FIG. 4 , the sensor software change method includes steps 401 to 403.

[0106] Before step 401, in a possible implementation, the method includes steps 401a to 401c:

[0107] Step 401a: Obtain a second software package of the intelligent driving device.

[0108] In an embodiment of the present application, the intelligent driving device can obtain its corresponding second software package from the cloud, a host computer or other means. The second software package is generally a complete software package corresponding to the intelligent driving device, which is used to change all software in the intelligent driving device.

[0109] It is understandable that after the intelligent driving device leaves the factory or undergoes a software / hardware upgrade, the software program running on the intelligent driving device is generally upgraded again. At this time, the intelligent driving device can obtain the upgraded second software package from the cloud or a host computer and other devices to upgrade its own software program according to the second software package.

[0110] Step 401b: The intelligent driving device obtains M software packages corresponding to M different types of sensors from the second software package, where M is a positive integer greater than or equal to 1.

[0111] In the embodiment of the present application, in order to avoid wasting storage space, after the intelligent driving device obtains the corresponding software upgrade package, that is, the second software package, it does not directly store the second software package in its own memory. Instead, it obtains M software packages corresponding to M types of sensors from the second software package, that is, only one software package is cached for each type of sensor, thereby avoiding the problem of excessive cache occupying storage space.

[0112] It is understandable that, in order to avoid wasting storage space, the storage method of caching only one software package for each type of sensor is only one of the optional storage methods, which is not limited here. In addition, the types of sensors can be divided according to functions, application scenarios and other rules, and the value rules of M and the corresponding sensor division criteria can be set according to actual needs, which are not limited here.

[0113] Step 401c: when the storage condition is met, obtain and store N software packages from the M software packages, where N is less than or equal to M, and the N software packages include the first software package.

[0114] In an embodiment of the present application, after obtaining M software packages corresponding to M different types of sensors, it is necessary to judge the remaining storage space of the intelligent driving device's own memory. If the remaining storage space of the memory meets the corresponding storage condition, N software packages are obtained and stored from the M software packages, where the N software packages include the first software package.

[0115] It is understandable that in order to avoid wasting the storage space of the memory, in the actual operation process, N software packages can be cached in a specific scenario based on the actual application scenario, the damage probability of the sensor and its internal components, and the life cycle, wherein the N software packages include the first software package, and N is less than or equal to M, so as to further achieve full utilization of the storage space. For example, sensors installed outside the intelligent driving device are generally more susceptible to damage, or, in high temperature scenarios, sensors that are more sensitive to high temperatures are more susceptible to damage. In these scenarios, only sensors with a higher probability of damage can be cached to save the remaining storage space of the memory. However, in general, the M software packages will be directly stored (i.e., when N is equal to M) to ensure that randomly damaged sensors can be adapted to the appropriate sensor type from the M software packages, and then the first software package corresponding to the sensor is obtained.

[0116] It should be noted that by pre-storing the first software package corresponding to the sensor in the memory of the intelligent driving device, when the software of the sensor needs to be changed later, the software of the sensor can be changed by directly obtaining the locally stored software package, thereby realizing a rapid upgrade of the sensor without networking. In addition, the method of steps 401a to 401c is only one implementation method of obtaining and storing the first software package. Based on this embodiment, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0117] Further, steps 401 to 403 are specifically as follows:

[0118] Step 401: After the sensor is connected to the intelligent driving device, a first software version number of the sensor is obtained.

[0119] In an embodiment of the present application, after an old sensor is removed from an intelligent driving device due to a failure or hardware replacement, if a newly connected sensor is detected by a controller in the intelligent driving device, the first software version number corresponding to the software package of the sensor will be actively queried and obtained.

[0120] Exemplarily, the software version number generally consists of two to four parts, including: major version number (major), minor version number (minor), internal version number (build) and revision number, among which the major version number and minor version number are required, and the internal version number and revision number are optional. The major version number generally increases when the software has a major upgrade, the minor version number generally increases when the software has new functions, and the internal version number generally increases when there are smaller changes such as bug fixes. When a new version is released, the major, minor or build (if any) version number should be updated, depending on the size of the change. When there is a huge update, the major version number will be increased. When there is a big update, but not to the extent of updating the major, the minor version number will be updated. If the update is relatively small, such as just a bug fix, the build version number will be updated. Usually, the official version is numbered "1.0", and the software version number upgrade process is, for example: "1.0" to "1.0.1", "1.0.1" to "1.0.2", "1.0.2" to "1.1". It should be understood that the composition of the software version number, the numbering rules and the specific numbering content can be set according to actual needs. This is only an example and not a limitation. It is understandable that when the sensor is connected through the corresponding hardware interface, a notification mechanism will be triggered. Therefore, the controller in the intelligent driving device can detect that a sensor is connected and can locate the specific port of the connection. It should be understood that for the same type of sensor and the same type of hardware port, it is applicable to select any port for access.

[0121] Optionally, in a possible implementation, in step 401, the main steps of obtaining the first software version number of the sensor include:

[0122] Send a version query request to the sensor;

[0123] Receive a first software version number fed back by a sensor.

[0124] In this possible implementation, after the controller of the intelligent driving device detects that a new sensor is connected, it will actively send a version query request to the sensor and store the first software version number received from the sensor feedback in the memory.

[0125] It is understandable that in the prior art, active query operations are not performed immediately after hardware insertion is detected. In the embodiment of the present application, after the sensor is connected to the intelligent driving device, the intelligent driving device will actively send a version query request to the software version of the connected sensor to obtain the software version number corresponding to the sensor, thereby realizing automatic version query after insertion, and completing rapid upgrade after insertion when the version change is met, without the need for maintenance personnel to participate in the software change process.

[0126] Optionally, in a possible implementation, before obtaining the first software version number of the sensor, the method further includes:

[0127] Perform access authentication on the sensor, and after the access authentication is passed, establish a communication connection with the sensor.

[0128] In this possible implementation, after the controller of the intelligent driving device detects that a sensor is connected, it will first authenticate the sensor to ensure that the connected sensor and the intelligent driving device can maintain normal communication, and ensure the automatic change of subsequent sensor software when troubleshooting.

[0129] Exemplarily, the access authentication method may include a UDS diagnostic method. A diagnostic request is sent to the sensor through the controller of the intelligent driving device. Based on the UDS protocol, when the sensor receives a diagnostic request, it will first verify whether the current session can execute this request. For example, if the service corresponding to the request is of a high level, then it is also necessary to ensure that the session is at a corresponding high security level. If the sensor is in an inactivated default session state, it will switch the session according to the request, establish a session with the intelligent driving device, and execute the corresponding diagnostic service.

[0130] Step 402: Obtain a second software version number of a first software package corresponding to the sensor, where the first software package is pre-stored in the intelligent driving device.

[0131] In the embodiment of the present application, after detecting that a sensor is connected, the controller in the intelligent driving device will obtain the second software version number corresponding to the first software package from the memory of the intelligent driving device, and the first software package corresponding to the sensor is pre-stored in the memory of the intelligent driving device and can be directly obtained locally. Optionally, one of the methods for obtaining the first software package can refer to the above steps 401a to 401c.

[0132] It is understandable that a big difference between intelligent driving devices and traditional devices is that the frequency of software upgrades for intelligent driving devices is generally more frequent. In order to obtain the latest functions, the software needs to be upgraded frequently, such as OTA upgrades or proximal upgrades. At this time, the sensors supporting the intelligent driving device also need to be upgraded. Therefore, after each shipment or upgrade of the intelligent driving device, the software package corresponding to the intelligent driving device can be obtained from the cloud or the host computer, thereby completing the software update of the intelligent driving device. The use of OTA upgrades depends on the quality of network communication, and the software package needs to be downloaded online. The process of downloading the software package is time-consuming and wastes traffic. The use of proximal upgrades relies more on maintenance personnel and special equipment, and the operation is complicated. In an embodiment of the present application, by pre-storing the software package in the intelligent driving device, the first software package of the sensor and its corresponding second software version number can be quickly obtained without the need for networking, thereby realizing rapid changes to the sensor software.

[0133] Optionally, in a possible implementation, the storage condition includes: a relationship between the sizes of the N software packages and the remaining storage space of the memory of the intelligent driving device satisfies a preset condition.

[0134] In this possible implementation, it is understandable that the size of a software package of a single sensor is generally small, and the cache does not occupy a large storage space. However, in order not to waste storage space, by obtaining the remaining space in the memory of the intelligent driving device, and by comparing the size of N software packages among the M software packages with the remaining storage space of the memory, the N software packages are stored only when the preset conditions are met, thereby avoiding the problem of excessive cache space occupation and achieving full utilization of the remaining storage space in the memory of the intelligent driving device.

[0135] Exemplarily, the preset condition may be a multiple condition. Since the size of the software package corresponding to the sensor is generally small, K times the size of the sensor can be reserved in the remaining storage space, for example, 10 times, to achieve storage of the sensor software package when there is sufficient storage space in the memory. It should be noted that the specific content of the preset condition can be set according to actual needs or experiments, and is not limited here.

[0136] Step 403: If the first software version number is inconsistent with the second software version number, a first software package is sent to the sensor, where the first software package is used for the sensor to perform software changes.

[0137] In the embodiment of the present application, if the intelligent driving device determines that its own software version number is inconsistent with the software version number of the newly connected sensor, the software of the connected sensor needs to be changed. The specific operation process is to send a locally stored first software package to the sensor through the intelligent driving device, so that the sensor changes the software according to the first software package.

[0138] It is understandable that software changes include two situations: software upgrade and software rollback. Corresponding to the embodiment of the present application, similarly, the inconsistency between the first software version number and the second software version number corresponds to two situations. In the actual operation process, if the first software version number is higher than the second software version number, the software version of the sensor needs to be rolled back to the second software version number to complete the software change of the sensor. If the first software version number is lower than the second software version number, the software version of the sensor needs to be upgraded to the second software version number to complete the software change of the sensor.

[0139] In addition, in the embodiment of the present application, the first software package corresponding to the sensor is pre-stored in the memory of the intelligent driving device, and when the version comparison is inconsistent, the first software package stored locally is directly sent to the sensor through the controller of the intelligent driving device to make the sensor software change. It can be understood that, without the need for networking, data can be transmitted between the sensor and the controller of the intelligent driving device through a hardware communication link, such as CAN bus, Ethernet, etc., which can be determined according to specific circumstances.

[0140] Optionally, in a possible implementation, the software change process of the sensor is displayed on a designated screen.

[0141] In this possible implementation, the upgrade process can be displayed on a designated screen through an external computer or display screen. When the intelligent driving device needs to make a software change to the sensor, the staff can be informed of the current working status of the sensor and the corresponding operation of the intelligent driving device through the display screen to understand the software change process of the sensor.

[0142] For example, please refer to FIG. 5, which is a schematic diagram of the operation display of a sensor software change method provided by an embodiment of the present invention. After the sensor is connected to the intelligent driving device and passes the access authentication, the content of "device connected" can be displayed on the screen to inform the staff that the sensor has been successfully connected, and the possibility of hardware access failure is eliminated through this content. When it is detected that the software version of the sensor is inconsistent with that of the intelligent driving device, the software version of the sensor is changed, and the content of "software changing" is displayed on the screen to inform the staff that the current sensor is in a state of software change. After the software of the sensor is changed, the content of "software change completed" can be displayed on the screen to inform the staff that the software change operation of the sensor has been completed. By reminding the staff of the current working state of the sensor, redundant maintenance operations in the process of changing the sensor software are reduced. Optionally, the words "software change" can also be refined into words "software upgrade" or "software rollback" to enable the team members to further and more intuitively understand the software change process of the sensor.

[0143] It is understandable that the specific content displayed on the display screen and the device type of the display screen can be set according to actual needs. The schematic diagram shown in FIG5 is only one optional implementation method, which is not limited here.

[0144] It is understandable that in the embodiment of the present application, after detecting that a sensor is connected, the intelligent driving device will actively query and obtain the first software version number of the sensor to realize automatic version query after the sensor is inserted without manual intervention. After obtaining the first software version number of the sensor, the intelligent driving device will obtain the second software version number of the first software package corresponding to the sensor from the local, and compare the second software version number with the first software version number to check the software version of the sensor. If it is determined that the first software version number and the second software version number are inconsistent, the first software package is sent to the sensor so that the sensor can make software changes according to the first software package, thereby ensuring that the software version of the sensor is consistent with that of the intelligent driving device, so that the function of the sensor can be used normally. The method of this embodiment is adopted, by pre-storing the software package corresponding to the sensor locally, it is possible to realize the rapid change of the sensor software without networking when the software version of the sensor needs to be changed, thereby eliminating the operation of downloading online, and also eliminating the participation process of maintenance personnel, thereby improving the efficiency of maintenance.

[0145] Please refer to FIG6 , which is a flowchart of another sensor software change method provided in an embodiment of the present application. The sensor software change method shown in FIG6 can be applied to the intelligent driving device shown in FIG1 . As shown in FIG6 , the sensor software change method includes the following steps 601 to 603 .

[0146] Before step 601, optionally, in a possible implementation, the method further includes steps 601a to 601c:

[0147] Step 601a: Obtain a second software package of the intelligent driving device.

[0148] It should be noted that step 601a is similar to the above-mentioned step 401a. For specific implementation methods and technical details, please refer to the above-mentioned step 401a, which will not be repeated here.

[0149] Step 601b: The intelligent driving device obtains M software packages corresponding to M different types of sensors from the second software package, where M is a positive integer greater than or equal to 1.

[0150] It should be noted that step 601b is similar to the above-mentioned step 401b. For specific implementation methods and technical details, please refer to the above-mentioned step 401b, which will not be repeated here.

[0151] Step 601c, when the storage condition is not met, end the operation.

[0152] In the embodiment of the present application, the controller of the intelligent driving device obtains M software packages corresponding to M types of sensors from the second software package, that is, only one software package is cached for each type of sensor. If it is determined that the storage condition is not met, it means that the remaining storage space in the memory of the intelligent driving device cannot cache the software package corresponding to the sensor, and therefore, it is impossible to pre-store the first software package corresponding to the sensor.

[0153] Further, steps 601 to 603 are specifically as follows:

[0154] Step 601: After the sensor is connected to the intelligent driving device, a first software version number of the sensor is obtained.

[0155] It should be noted that step 601 is similar to the above-mentioned step 401. For specific implementation methods and technical details, please refer to the above-mentioned step 401, which will not be repeated here.

[0156] Step 602: Obtain a second software version number of a first software package corresponding to the sensor.

[0157] In the embodiment of the present application, when the storage condition is not met, the operation is completed by obtaining the first software package corresponding to the sensor and the second software version number of the first software package in real time. Optionally, the second software version number of the first software package corresponding to the sensor can be obtained by downloading and obtaining the second software version number of the first software package corresponding to the sensor online from the cloud or the host computer, or by other methods.

[0158] It is understandable that in order to avoid wasting storage space, the controller of the intelligent driving device obtains M software packages corresponding to M types of sensors from the second software package, that is, only one software package is cached for each type of sensor. If it is determined that the storage condition is not met, it means that the remaining storage space of the memory of the intelligent driving device cannot cache the software packages corresponding to each type of sensor. At this time, it is impossible to use the method shown in Figure 4 to obtain the first software package corresponding to the sensor and its corresponding second software version number. The second software version number of the first software package corresponding to the sensor can only be obtained in real time. Optionally, the second software version number of the first software package corresponding to the sensor can be obtained in real time from the cloud, a host computer or other devices.

[0159] Optionally, in a possible implementation, the storage condition includes:

[0160] The relationship between the sizes of the N software packages and the remaining storage space of the memory of the intelligent driving device satisfies a preset condition.

[0161] Step 603: If the first software version number is consistent with the second software version number, a first software package is sent to the sensor, where the first software package is used for the sensor to perform software changes.

[0162] It should be noted that step 603 is similar to the above step 403. For specific implementation and technical details, please refer to the above step 403, which will not be repeated here.

[0163] It is understandable that when the storage conditions are not met, the first software package corresponding to the sensor cannot be pre-stored in the local memory of the intelligent driving device, and the first software package corresponding to the sensor can only be obtained in real time through the cloud, a host computer, or other methods relying on the quality of network communication.

[0164] Please refer to FIG. 7 , which is a schematic diagram of the structure of a sensor software changing device provided in an embodiment of the present application, and the sensor software changing device is applied to the intelligent driving device shown in FIG. 1 . The sensor software changing device 7000 includes:

[0165] An acquisition module 7001 is used to acquire a first software version number of the sensor after the sensor is connected to the intelligent driving device;

[0166] The acquisition module 7001 is further used to acquire a second software version number of a first software package corresponding to the sensor, where the first software package is pre-stored in the intelligent driving device;

[0167] Among them, the specific description of the acquisition module 7001 can refer to the description of step 401 and step 402 in the above embodiment, and will not be repeated here.

[0168] The communication module 7002 is used to send a first software package to the sensor if the first software version number is inconsistent with the second software version number, and the first software package is used for the sensor to perform software changes.

[0169] Among them, the specific description of the communication module 7002 can refer to the description of step 403 in the above embodiment, and will not be repeated here.

[0170] Optionally, in a possible implementation,

[0171] The acquisition module 7001 is further used to acquire a second software package of the intelligent driving device;

[0172] The acquisition module 7001 is further used to acquire M software packages corresponding to the M types of sensors from the second software package, where M is a positive integer greater than or equal to 1;

[0173] The acquisition module 7001 is further configured to acquire and store N software packages from the M software packages when a storage condition is met, where N is less than or equal to M, and the N software packages include the first software package.

[0174] Optionally, in a possible implementation, the above storage condition includes:

[0175] The relationship between the sizes of the N software packages and the remaining storage space of the memory of the intelligent driving device satisfies a preset condition.

[0176] Optionally, in a possible implementation, the communication module 7002 is further used to:

[0177] After detecting that the sensor is connected to the intelligent driving device, the sensor is authenticated, and after the access authentication is passed, a communication connection is established with the sensor.

[0178] Optionally, in a possible implementation, the acquisition module 7001 is specifically used for:

[0179] After sending a version query request to the sensor through the communication module 7002 , the first software version number fed back by the sensor is received through the communication module 7002 .

[0180] Optionally, in a possible implementation manner, the sensor software changing device also includes a display module.

[0181] In this implementation, the display module is mainly used to display the operation process of the sensor software change method, so that the staff can understand the sensor software change process more intuitively.

[0182] In this embodiment, after the sensor is connected to the intelligent driving device, the first software version number of the sensor is obtained by the acquisition module 7001. Then, the second software version number of the first software package corresponding to the sensor is obtained by the acquisition module 7001, and the first software package is pre-stored in the intelligent driving device. Finally, when the first software version number is inconsistent with the second software version number, the first software package is sent to the sensor through the communication module 7002, and the first software package is used for the sensor to make software changes. Therefore, by pre-storing the software package corresponding to the sensor locally, when the software version of the sensor needs to be changed, the sensor software can be quickly changed without networking, thereby eliminating the operation of downloading online, and also eliminating the participation of maintenance personnel, thereby improving the efficiency of maintenance.

[0183] In this embodiment, the operations performed by each unit in the sensor software change device 7000 are similar to those described in the method embodiment shown in Figure 4 above, and can be used to implement the functions of the intelligent driving device in the above method embodiment, and can also achieve the beneficial effects of the above method embodiment, which will not be repeated here.

[0184] Please refer to Fig. 8, which is a schematic diagram of the structure of another sensor software change device provided in an embodiment of the present application. As shown in Fig. 8, the sensor software change device 8000 is implemented by a general bus architecture.

[0185] The sensor software changing device 8000 includes at least one processor 8001 , a communication bus 8002 , a memory 8003 , and at least one communication interface 8004 .

[0186] The processor 8001, the memory 8003, and the communication interface 8004 communicate via the communication bus 8002, and may also communicate via other means such as wireless transmission. The memory 8003 is used to store instructions, and the processor 8001 is used to execute the instructions stored in the memory 8003. The memory 8003 stores program codes, and the processor 8001 may call the program codes stored in the memory 8003 to execute steps 401 to 403 in the embodiment shown in FIG. 1. For specific implementation, please refer to the specific description of steps 401 to 403 in the embodiment shown in FIG. 4, which will not be repeated here.

[0187] Optionally, the processor 8001 is a general-purpose central processing unit (CPU), and may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices (PLD), transistor logic devices, hardware components, or any combination thereof. The above-mentioned PLD is a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0188] The communication bus 8002 is used to transmit information between the processor 8001, the memory 8003 and the communication interface 8004. The communication bus 8002 is divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0189] Alternatively, the memory 8003 is a read-only memory (ROM) or other types of static storage devices that can store static information and instructions. Alternatively, the memory 8003 is a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions. Alternatively, the memory 8003 is an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited to this. Optionally, the memory 8003 exists independently and is connected to the processor 8001 through the communication bus 8002. Optionally, the memory 8003 and the processor 8001 are integrated together.

[0190] The communication interface 8004 uses any transceiver-like device for communicating with other devices or communication networks. The communication interface 8004 includes a wired communication interface. Optionally, the communication interface 8004 also includes a wireless communication interface. Among them, the wired communication interface is, for example, an Ethernet interface. The Ethernet interface is an optical interface, an electrical interface or a combination thereof. The wireless communication interface is a wireless local area network (WLAN) interface, a cellular network communication interface or a combination thereof, etc.

[0191] In a specific implementation, as an embodiment, the processor 8001 includes one or more CPUs, such as CPU0 and CPU1 shown in FIG. 8 .

[0192] In a specific implementation, as an embodiment, the sensor software changing device 8000 includes multiple processors, such as processor 8001 and processor 8005 shown in FIG8 . Each of these processors is a single-core processor (single-CPU) or a multi-core processor (multi-CPU). The processor here refers to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0193] In some embodiments, the memory 8003 is used to store program codes for executing the solution of the present application, and the processor 8001 executes the program codes stored in the memory 8003. That is, the sensor software changing device 8000 implements the above-mentioned embodiment of the sensor software changing method through the processor 8001 and the program codes in the memory 8003.

[0194] It is understandable that the method steps in the embodiments of the present application can be implemented in hardware or in software instructions that can be executed by the processor 8001. The software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. In addition, the scope of the device described in the present application is not limited to this, and the structure of the device may not be limited by Figure 8. The device can be an independent device or can be part of a larger device. For example, the device can be:

[0195] (1) Independent integrated circuit IC, or chip, or chip system or subsystem;

[0196] (2) having a set of one or more ICs, and optionally, the IC set may also include a storage component for storing data and / or instructions;

[0197] (3) Modules that can be embedded in other devices;

[0198] (4) Receivers, terminals, intelligent terminals, wireless devices, handheld devices, mobile units, vehicle-mounted devices, artificial intelligence devices, machinery and equipment, household equipment, medical equipment, industrial equipment, etc.;

[0199] (5)Others

[0200] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0201] Please refer to FIG. 9, which is a schematic diagram of the structure of an intelligent driving device provided in an embodiment of the present application. As shown in FIG. 9, the intelligent driving device 9000 includes at least one sensor 9001 and at least one controller 9002. As one optional implementation, the controller 9002 may correspond to the controller 300 shown in FIG. 1, and the sensor 9001 may correspond to the sensor 200 shown in FIG. 1. The controller 9002 executes computer executable instructions to implement the various operating steps of the sensor software change method shown in FIG. 4, or the controller 9002 includes a sensor software change device as shown in FIG. 7.

[0202] The embodiment of the present application also provides a computer program product, which, when executed by a computer, implements the functions of any of the above method embodiments.

[0203] The embodiment of the present application also provides a chip system, which includes a processor for implementing the functions of the intelligent driving device in the above-mentioned methods. In one possible design, the chip system also includes a memory for storing program instructions and / or data. The chip system can be composed of a chip, or it can include a chip and other discrete devices.

[0204] It is understood that the devices and methods described in the present application can also be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0205] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from other embodiments.

[0206] The naming or numbering of the steps in this application does not mean that the steps in the method flow must be executed in the time / logical sequence indicated by the naming or numbering. The named or numbered process steps can change the execution order according to the technical purpose to be achieved, as long as the same or similar technical effects can be achieved. The division of the units in this application is a logical division. There may be other division methods when it is implemented in actual applications. For example, multiple units can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between each other shown or discussed can be through some interfaces, and the indirect coupling or communication connection between units can be electrical or other similar forms, which are not limited in this application. In addition, the unit or subunit described as a separate component may or may not be physically separated, may or may not be a physical unit, or may be distributed in multiple circuit units, and some or all of the units can be selected according to actual needs to achieve the purpose of the present application solution.

[0207] The above is only a specific implementation mode of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or replacements within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. The various digital numbers involved in the embodiments of the present application are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. The size of the sequence number of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic.

[0208] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

A sensor software changing method, characterized in that: Applied to an intelligent driving device, the method includes: after a sensor is connected to the intelligent driving device, obtaining a first software version number of the sensor; obtaining a second software version number of a first software package corresponding to the sensor, the first software package being pre-stored in the intelligent driving device; if the first software version number is inconsistent with the second software version number, sending the first software package to the sensor, the first software package being used for the sensor to perform software changes. The method according to claim 1, characterized in that The method also includes: obtaining a second software package of the intelligent driving device; obtaining M software packages corresponding to M types of sensors from the second software package, where M is a positive integer greater than or equal to 1; and when a storage condition is met, obtaining and storing N software packages from the M software packages, where N is less than or equal to M, and the N software packages include the first software package. The method according to claim 2, characterized in that The storage condition includes: a relationship between the sizes of the N software packages and the remaining storage space of the memory of the intelligent driving device satisfies a preset condition. The method according to any one of claims 1 to 3, characterized in that Before obtaining the first software version number of the sensor, the method further includes: performing access authentication on the sensor, and establishing a communication connection with the sensor after the access authentication passes. The method according to any one of claims 1 to 4, characterized in that The obtaining the first software version number of the sensor includes: sending a version query request to the sensor; and receiving the first software version number fed back by the sensor. A sensor software changing device, characterized in that: Applied in an intelligent driving device, the device includes: an acquisition module, used to acquire a first software version number of the sensor after the sensor is connected to the intelligent driving device; the acquisition module is also used to acquire a second software version number of a first software package corresponding to the sensor, the first software package being pre-stored in the intelligent driving device; and a communication module, used to send the first software package to the sensor if the first software version number is inconsistent with the second software version number, the first software package being used for the sensor to perform software changes. The device according to claim 6, characterized in that The acquisition module is further used to acquire a second software package of the intelligent driving device; the acquisition module is further used to acquire M software packages corresponding to M types of sensors from the second software package, where M is a positive integer greater than or equal to 1; the acquisition module is further used to acquire and store N software packages from the M software packages when a storage condition is met, where N is less than or equal to M, and the N software packages include the first software package. The device according to claim 7, characterized in that The storage condition includes: a relationship between the sizes of the N software packages and the remaining storage space of the memory of the intelligent driving device satisfies a preset condition. The device according to any one of claims 6 to 8, characterized in that The communication module is also used to: after the sensor is connected to the intelligent driving device, perform access authentication on the sensor, and establish a communication connection with the sensor after the access authentication passes. The device according to any one of claims 6 to 9, characterized in that The acquisition module is specifically used to: send a version query request to the sensor through the communication module; and receive the first software version number fed back by the sensor through the communication module. A sensor software changing device, characterized in that: The device comprises a memory and a processor, wherein the memory stores codes, and the processor is configured to execute the codes so as to enable the sensor software changing device to perform the method according to any one of claims 1 to 5. An intelligent driving device, characterized in that: The method comprises a sensor and a controller, wherein the controller executes computer executable instructions to implement the method according to any one of claims 1 to 5, or the controller is the device according to any one of claims 6 to 11. A computer storage medium, characterized in that The computer storage medium stores a computer program, which, when executed by a computer, enables the computer to implement the method according to any one of claims 1 to 5. A computer program product, characterized in that When the computer product is executed by a computer, the method according to any one of claims 1 to 5 is implemented.

Images