Vehicle-mounted equipment state acquisition method and device, vehicle and storage medium

Abstract

The invention discloses a vehicle-mounted equipment state obtaining method and device, a vehicle and a storage medium, and relates to the technical field of vehicles. The method comprises the steps that after a vehicle is powered on, a local device tree file of each first device node is loaded to determine a subordinate device node of each first device node, a root node of all the device nodes is a central control unit of the vehicle, and the local device tree file comprises device state parameters and node names of the subordinate device nodes; each first device node obtains at least part of file content in a local device tree file of a subordinate device node of the first device node, wherein the part of file content at least comprises device state parameters; and updating the file content in the local device tree file of the central control unit based on at least part of the file content acquired by each first device node to obtain a complete vehicle-mounted device tree file. Therefore, the central control unit can dynamically construct and maintain a complete vehicle-mounted equipment tree, and further more efficiently realize state management of the vehicle-mounted equipment.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a method, device, vehicle and storage medium for acquiring the status of an on-vehicle device. Background Art

[0002] The automotive electronic and electrical architecture is developing in the direction of centralized computing and regional control. More and more on-board devices such as controllers, sensors and actuators in various fields of the vehicle are being connected. How to effectively manage these on-board devices has become a problem that needs to be solved urgently. Summary of the invention

[0003] The present application proposes a method, device, vehicle and storage medium for acquiring the status of an on-board device, so as to more efficiently manage the status of the on-board device.

[0004] In a first aspect, an embodiment of the present application provides a method for obtaining the status of a vehicle-mounted device, the method comprising: after the vehicle is powered on, loading the local device tree file of each first device node to determine the subordinate device nodes of each first device node, the first device node being a device node having subordinate device nodes among all device nodes in the vehicle, the root node of all device nodes being the central control unit of the vehicle, the local device tree file including at least device status parameters and node names of subordinate device nodes; each first device node obtains at least part of the file content in the local device tree file of its subordinate device node, the part of the file content including at least the device status parameters; based on at least part of the file content obtained by each first device node, updating the file content in the local device tree file of the central control unit to obtain a complete vehicle-mounted device tree file.

[0005] In the second aspect, the embodiment of the present application provides a device for acquiring the status of a vehicle-mounted device, the device comprising: a subordinate device determination module, a device status acquisition module and a device tree file update module. The subordinate device determination module is used to load the local device tree file of each first device node after the vehicle is powered on to determine the subordinate device node of each first device node, the first device node is a device node with a subordinate device node among all device nodes in the vehicle, the root node of all device nodes is the central control unit of the vehicle, and the local device tree file includes at least device status parameters and node names of subordinate device nodes; the device status acquisition module is used for each first device node to acquire at least part of the file content in the local device tree file of its subordinate device node, the partial file content includes at least the device status parameters; the device tree file update module is used to update the file content in the local device tree file of the central control unit based on at least part of the file content acquired by each first device node, so as to obtain a complete vehicle-mounted device tree file.

[0006] In a third aspect, an embodiment of the present application provides a vehicle, comprising: one or more processors; a memory; one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the above-mentioned method.

[0007] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a program code is stored. The program code can be called by a processor to execute the above method.

[0008] In the solution provided by the present application, after the vehicle is powered on, the local device tree file of each first device node is loaded to determine the subordinate device node of each first device node, the first device node is a device node with subordinate device nodes among all device nodes in the vehicle, the root node of all device nodes is the central control unit of the vehicle, and the local device tree file includes at least device status parameters and node names of subordinate device nodes; each first device node obtains at least part of the file content in the local device tree file of its subordinate device node, and the part of the file content includes at least device status parameters; based on at least part of the file content obtained by each first device node, the file content in the local device tree file of the central control unit is updated to obtain a complete vehicle-mounted device tree file. In this way, by loading the local device tree file of each first device node, the device status of each hierarchical device node is recursively obtained in turn, so that the central control unit can obtain the latest device status of all device nodes in a timely manner, realize dynamic construction and maintenance of a complete vehicle-mounted device tree, and then more efficiently realize the status management of vehicle-mounted devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0010] Figure 1 A flow chart of a method for acquiring the status of an in-vehicle device provided in an embodiment of the present application is shown.

[0011] Figure 2 A schematic diagram of the hierarchy of the vehicle-mounted equipment provided in an embodiment of the present application is shown.

[0012] Figure 3 A flow chart of a method for acquiring the status of an in-vehicle device provided in another embodiment of the present application is shown.

[0013] Figure 4Shows Figure 3 A flowchart of the sub-steps of step S270 in one implementation manner.

[0014] Figure 5 A system architecture diagram of the vehicle-mounted device provided in an embodiment of the present application is shown.

[0015] Figure 6 It is a block diagram of a device for acquiring the status of a vehicle-mounted device provided according to an embodiment of the present application.

[0016] Figure 7 It is a block diagram of a vehicle according to an embodiment of the present application for executing a method for acquiring a vehicle-mounted device status according to an embodiment of the present application.

[0017] Figure 8 It is a storage unit of an embodiment of the present application for storing or carrying program codes for implementing a method for acquiring the status of a vehicle-mounted device according to an embodiment of the present application. DETAILED DESCRIPTION

[0018] In order to enable those skilled in the art to better understand the present application, 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. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0019] It should be noted that in some processes described in the specification, claims and the above-mentioned drawings of the present application, multiple operations that appear in a specific order are included, and these operations may not be executed or executed in parallel in the order in which they appear in this article. The sequence numbers of operations such as S110, S120, etc. are only used to distinguish different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or less operations, and these operations may be executed in sequence or in parallel. And, the terms "first", "second", etc. in the specification, claims and the above-mentioned drawings of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or server that includes a series of steps or sub-modules is not necessarily limited to those steps or sub-modules explicitly listed, but may include other steps or sub-modules that are not explicitly listed or that are inherent to these processes, methods, products, or devices.

[0020] The inventor proposes a method, device, vehicle and storage medium for obtaining the status of an on-board device. The method for obtaining the status of an on-board device provided in an embodiment of the present application is described in detail below.

[0021] Please refer to Figure 1 , Figure 1 A flowchart of a method for obtaining the status of a vehicle-mounted device provided in an embodiment of the present application is provided below. Figure 1 The method for obtaining the status of the vehicle-mounted device provided in the embodiment of the present application is described in detail. The method for obtaining the status of the vehicle-mounted device may include the following steps:

[0022] Step S110: After the vehicle is powered on, load the local device tree file of each first device node to determine the subordinate device nodes of each first device node, wherein the first device node is a device node having subordinate device nodes among all device nodes in the vehicle, and the root node of all device nodes is the central control unit of the vehicle, and the local device tree file includes at least device status parameters and node names of subordinate device nodes.

[0023] In this embodiment, all device nodes in the vehicle may include the central control unit (CCU), electronic control unit (ECU), sensor and actuator of the vehicle, and the central control unit includes a central gateway (CGW) or a centralized computing platform. Among them, the electronic controller may include a regional controller, a domain controller and a general controller. The regional controller is divided according to the physical location, and a regional controller is set corresponding to different areas, so that the sensors and actuators in the area are directly connected to the nearest regional controller, thereby providing better scalability for the vehicle; for example, the front area controller of the vehicle body, the rear area controller of the vehicle body, the left area controller of the vehicle body and the right area controller of the vehicle body. The domain controller is generally divided according to the functional domain, that is, different domain controllers are responsible for different functions of the vehicle, for example, the power domain controller, the chassis domain controller, the cockpit domain controller and the automatic driving domain controller; the power domain controller is mainly responsible for regulating the power of the vehicle, and the chassis domain controller is mainly responsible for the chassis-related functions of the vehicle, such as suspension and braking. General controllers generally refer to some traditional controllers, such as brake controllers, air conditioning controllers and engine controllers.

[0024] Before the vehicle leaves the factory, it can be pre-organized with the central control unit as the center and the vehicle network segmented, and all controllers, actuators and sensors in the vehicle can be hierarchically organized. For example, CANFD1 represents the CANFD channel No. 1 of the central control unit, EthernetPort1 represents the Ethernet port No. 1, and LIN1 represents the LIN channel No. 1, so as to obtain the root node and multiple levels of child nodes. In addition, each device node under each level of child nodes stores a local device tree file with itself as the root node, and the local device tree file at least includes its own node attribute parameters and the node name of the lower-level device node, and the node attribute parameters at least include the node name and the device status (status) parameter; in layman's terms, the device node can learn which device its lower-level device node is by loading the local device tree file stored in itself. Among them, the device status parameter can include multiple states such as normal operation (ok), disabled (disable), absent (absent), fault (fail), unknown (unknown) and update (update).

[0025] For example, Figure 2 As shown in the figure, all controllers, actuators and sensors in the vehicle are organized hierarchically, and the central control unit as the root node, the first-level child node, the second-level child node and the third-level child node can be obtained; the first-level child node includes the regional controller and the domain controller, the second-level child node includes the common controller, the sensor and the actuator 2; the third-level child node includes the actuator 1. That is to say, after the vehicle is powered on, Figure 2 The central control unit, regional controller, domain controller and common controller in the above can all be regarded as the first device node mentioned above. That is to say, the central control unit can learn that its subordinate device nodes are the regional controller and the domain controller by loading the local device tree file stored in itself; similarly, the domain controller can also learn that its subordinate device nodes are the sensor and actuator 2 by loading the local device tree file stored in itself; the common controller can also learn that its subordinate device node is actuator 1 by loading the local device tree file stored in itself.

[0026] Based on this, after the vehicle is powered on, each first device node can load its own local device tree file and determine the subordinate device node of the first device node by reading the node name of the subordinate device node, so as to subsequently obtain the device status parameters of the subordinate device node.

[0027] Optionally, the aforementioned node attribute parameters may include, in addition to the device status parameter, a device type parameter, a manufacturer parameter, a model parameter, and a version parameter. Among them, the device type parameter may include a general device type and a special device type. Devices under the general device type may use a set of uniformly defined interactive interfaces for device control and data interaction, and devices under the special device type need to use a proprietary interface for control and data interaction. The manufacturer parameter is the name of the device supplier, the model parameter includes the device part number and the device model, and the type of the device can be accurately distinguished by comparing the model parameter. The version parameter is used to characterize the specific version of the device.

[0028] Of course, for different devices, the local device tree file may also include the device's proprietary attribute parameters. For example, the local device tree file of a camera may include proprietary attribute parameters such as pixels and maximum frame rate. For another example, the local device tree file of a storage device may include proprietary attribute parameters such as storage type and storage capacity. For another example, the local device tree file of a display device may include proprietary attribute parameters such as resolution.

[0029] It should be noted that the central control unit, domain controller and regional controller generally store local device tree files in the form of files, while ordinary controllers generally do not support file storage and store local device tree files in the form of structured data.

[0030] Step S120: Each first device node obtains at least a portion of the file content in the local device tree file of its subordinate device node, wherein the portion of the file content at least includes the device status parameter.

[0031] Specifically, each first device node can send a target request message to its subordinate device node in accordance with the target communication protocol; correspondingly, the subordinate device node of each first device node responds to the received target request message and generates a target reply message based on at least part of the file content in its local device tree file, and then feeds back the target reply message to the first device node corresponding to the subordinate device node.

[0032] Optionally, for the first device node that supports Ethernet, the Hypertext Transfer Protocol (HTTP) under Ethernet can be followed, and an HTTP request message can be sent to its subordinate device node through the GET method to the subordinate device node corresponding to the first device node. Similarly, the subordinate device node can respond to the HTTP request message, and generate an HTTP reply message based on at least part of the file content in the requested local device tree file, and then feed the HTTP reply message back to its corresponding first device node. It should be noted that the subordinate device node also needs to support Ethernet. For example, the central control unit, domain controller, and regional controller in this vehicle all support Ethernet, such as Figure 2 As shown, the central control unit serves as the first device node, and the subordinate device nodes of the central control unit include the regional controller and the domain controller. Therefore, the aforementioned target request message and target reply message can be transmitted between the central control unit and the regional controller, and between the central control unit and the domain controller based on the HTTP protocol.

[0033] Optionally, for the first device node that does not support Ethernet, a CAN / CANFD request message with a specified identifier (IDentifier, ID) can be sent to its subordinate device node in accordance with the Controller Area Network (CAN) protocol or the CAN with Flexible Data Rate (CANFD) protocol. Similarly, the subordinate device node can respond to the CAN / CANFD request message and generate a CAN / CANFD reply message based on at least part of the file content in the requested local device tree file, and then feed the CAN / CANFD reply message back to its corresponding first device node.

[0034] In some implementations, if the length of at least part of the file content in the local device tree file requested by the CAN / CANFD request message is less than or equal to the message length of a single CAN / CANFD message, a single-frame CAN / CANFD reply message is generated based on at least part of the file content in the requested local device tree file. If the length of at least part of the file content in the local device tree file requested by the CAN / CANFD request message is greater than the message length of a single CAN / CANFD message, a multi-frame CAN / CANFD reply message is generated based on at least part of the file content in the requested local device tree file, and the multi-frame CAN / CANFD reply message is fed back to the corresponding first device node in sequence. Specifically, determine the effective data length of a CAN / CANFD message frame after adding the fragment sequence number, and then determine the target number of CAN / CANFD messages based on the length of at least part of the file content and the effective data length of a CAN / CANFD message frame; then, fill the data in at least part of the file content into the target number of CAN / CANFD messages in sequence according to the fragment sequence number order and the byte stream order, and the end of the byte stream is represented by adding ASCII code 03 (ETX), and fill the unfilled byte positions in the target number of CAN / CANFD messages with 00.

[0035] Exemplarily, the above-mentioned at least part of the file content is 40 bytes, a single-frame CAN message supports a maximum of 8 bytes, and a CANFD message supports a maximum of 64 bytes. The first byte is used to store the fragmentation sequence number (starting from 0 and increasing by 1 in sequence). It can be seen that since the fragmentation sequence number needs to occupy 1 byte, the single-frame CAN message after adding the fragmentation sequence number can store up to 7 bytes, and then it can be determined that at least 6 frames of CAN messages need to be generated to complete the transmission of at least part of the file content of 40 bytes. Thus, at least part of the file content of 40 bytes is filled into 6 frames of CAN messages in sequence according to the fragmentation sequence number order and the byte stream order, and ASCII code 03 (ETX) is added at the end of the byte stream of the 6th frame message. If there is an unfilled byte position in the last frame message, fill it with 00.

[0036] In some embodiments, when the vehicle receives a power-on instruction, each first device node can obtain all file contents in the local device tree file of the lower-level device node in response to the power-on instruction. That is, when the vehicle is just powered on, each first device node at each level will completely obtain the device state parameters, node attribute parameters, and proprietary attribute parameters of its lower-level device.

[0037] In other embodiments, during the operation of the vehicle after it is powered on, since some fixed parameters (such as device type parameters, version parameters, manufacturer parameters, and manufacturer parameters, etc.) have been obtained when the vehicle responds to the power-on command, and device status parameters may change during the operation of the vehicle, each first device node can only obtain the device status parameters in the local device tree file of its subordinate device node, thereby improving the efficiency of parameter acquisition.

[0038] In this way, each first device node obtains at least part of the file content in the local device tree file of its subordinate device node every target duration. The target duration can be determined based on the node address of each first device node and the preset duration. Specifically, the target duration = (node ​​address - fixed constant) * 20 milliseconds. In this way, real-time update of the device status in the complete vehicle-mounted device tree file can be achieved; and, since different first device nodes have different node addresses, different first device nodes have different corresponding target durations, that is, different first device nodes are set with different delay durations to avoid short-term communication conflicts.

[0039] Optionally, each first device node may simultaneously obtain at least part of the file content in the local device tree file of its subordinate device node. Of course, it may also be possible to start from each first device node at the second-to-last level and sequentially obtain the local device tree file of its subordinate device node in sections from bottom to top, and so on.

[0040] Step S130: Based on at least part of the file content obtained by each of the first device nodes, the file content in the local device tree file of the central control unit is updated to obtain a complete vehicle-mounted device tree file.

[0041] It can be understood that the initial local device tree file of the central control unit only contains its own device status parameters and the node names of all device nodes that are first-level child nodes. After passing step S120, each first device node will at least obtain the device status parameters of its subordinate device nodes, so that the device status parameters obtained by each first device node are integrated with the file content in the local device tree file in the central control unit according to the network segmentation and node name, and a complete vehicle-mounted device tree file can be obtained. Among them, the complete vehicle-mounted device tree file at least includes the node names and device status parameters of all device nodes in the vehicle.

[0042] In this embodiment, by loading the local device tree file of each first device node, the device status of each level device node is recursively obtained in turn, so that the central control unit can obtain the latest device status of all device nodes in a timely manner, dynamically build and maintain a complete vehicle-mounted device tree, and then more efficiently realize the status management of vehicle-mounted devices.

[0043] Please refer to Figure 3 , Figure 3 A flowchart of a method for obtaining the status of a vehicle-mounted device is provided in another embodiment of the present application. Figure 3 The method for obtaining the status of the vehicle-mounted device provided in the embodiment of the present application is described in detail. The method for obtaining the status of the vehicle-mounted device may include the following steps:

[0044] Step S210: After the vehicle is powered on, load the local device tree file of each first device node to determine the subordinate device nodes of each first device node, wherein the first device node is a device node having subordinate device nodes among all device nodes in the vehicle, and the root node of all device nodes is the central control unit of the vehicle, and the local device tree file includes at least device status parameters and node names of subordinate device nodes.

[0045] Step S220: Each first device node obtains at least a portion of the file content in the local device tree file of its subordinate device node, where the portion of the file content at least includes the device status parameter.

[0046] Step S230: Based on at least part of the file content obtained by each of the first device nodes, the file content in the local device tree file of the central control unit is updated to obtain a complete vehicle-mounted device tree file.

[0047] In this embodiment, the specific implementation of steps S210 to S230 can refer to the contents of the aforementioned embodiments and will not be described in detail here.

[0048] Step S240: Generate a vehicle-mounted device topology map according to the complete vehicle-mounted device tree file.

[0049] Step S250: displaying the vehicle-mounted device topology map, wherein the vehicle-mounted device topology map includes a plurality of device status icons, and the plurality of device status icons correspond one-to-one to all the device nodes.

[0050] In this embodiment, in order to facilitate users to more intuitively and quickly obtain the properties and device status of each device node in the vehicle, after obtaining the complete vehicle device tree file, a corresponding vehicle device topology map can be generated, and the generated vehicle device topology map can be displayed in the visualization interface. In this way, users can timely obtain the topological relationship between the current device nodes of the vehicle, the properties of each device node and the real-time device status through the displayed vehicle device topology map.

[0051] In some implementations, a vehicle-mounted device status display application may be installed in the vehicle, and the vehicle-mounted device topology map may be displayed in the application interface corresponding to the vehicle-mounted device status display application. In this way, the vehicle driver or vehicle maintenance personnel can quickly obtain the attributes and device status of each device node through the vehicle-mounted device status display application on the vehicle screen, so that when a fault occurs in the vehicle, the maintenance personnel can be directly guided to carry out fault inspection work.

[0052] In other embodiments, the terminal device used by the user may also be installed with a corresponding vehicle-mounted device status display application, and the terminal device includes but is not limited to a smart phone, a tablet computer, a laptop computer, and a desktop computer. Based on this, the vehicle-mounted device topology map in the vehicle may also be synchronously transmitted to the cloud, and transmitted to the terminal device used by the user through the cloud, and the complete vehicle-mounted device topology map is displayed on the application interface of the vehicle-mounted device status display application of the terminal device. In this way, in the event of a failure in the vehicle, remote maintenance personnel can also promptly obtain the device status of each device node of the vehicle through the terminal device.

[0053] Specifically, the displayed vehicle-mounted device topology diagram includes a device status icon corresponding to each device node in the vehicle, and the device status icons under different device status parameters are displayed separately. Exemplarily, the device status icons under different device status parameters are displayed separately in different colors; the device status icon with a device status parameter of ok is displayed in green, the device status icon with a device status parameter of fail is displayed in red, the device status icon with a device status parameter of disable is displayed in gray, the device status icon with a device status parameter of absent is displayed in black, the device status icon with a device status parameter of unknown is displayed in orange, and the device status icon with a device status parameter of update is displayed in blue. In this way, the differences between the device statuses of each device node can be more intuitively displayed.

[0054] Optionally, the local device tree file of each device node may also include a device failure type parameter (failure). Based on this, when the device status parameter of any device node is fail, the failure type parameter of the device node with the failure will be displayed on the vehicle-mounted device topology map. In this way, the user no longer needs to send a diagnostic command through the diagnostic device to obtain the device failure, but can directly view the device status of each device node through the application display interface of the vehicle-mounted device status display application, so that the device node with the failure and the specific failure type can be intuitively and quickly understood.

[0055] Step S260: In response to a state adjustment operation for a target icon, adjusting a device state parameter of a device node corresponding to the target icon to a corresponding target state parameter, the target icon being any one of the plurality of device state icons.

[0056] In this embodiment, a state adjustment function for the device state is also provided, that is, the user can adjust the device state parameters of any device node. Specifically, the user can input a state adjustment operation for the device state icon (i.e., the target icon) corresponding to the device node that he wants to adjust. Correspondingly, the vehicle can respond to the state adjustment operation and adjust the device state parameters of the device node corresponding to the target icon to the corresponding target state parameters; at the same time, the target icon will also be adjusted from the current display state to the corresponding display state after adjusting to the target state parameters. For example, the target icon currently displays the green color corresponding to the device state parameter being ok. If the user adjusts the device parameter from ok to update through the state adjustment operation, the target icon is adjusted from green to blue accordingly. Similarly, for device nodes that support Ethernet, the device state parameters can be changed through the PUT method in the HTTP protocol. For device nodes that do not support Ethernet, the device state parameters of the device node whose state needs to be changed are transmitted through the specified ID message of CAN / CANFD.

[0057] Step S270: If the second device node detects that the port status of its input port or output port has changed, the port status parameters in the local device tree file are updated based on the changed port status, and the updated port status parameters are reported to the superior device node of the second device node. The second device node is any device node among all the device nodes except the central control unit.

[0058] In this embodiment, the local tree device file in each device node may also include port parameters of the input port and the output port. Among them, the port parameters may include the connector model (connector), the connector number (PIN), the port function (function), the port status parameter and the port fault type parameter. Similarly, in the above-mentioned complete vehicle-mounted device topology diagram, the port parameters of each device node will also be visualized; that is, in the application interface of the above-mentioned vehicle-mounted device status display application, the function of each device node in the vehicle and the relationship between the connector and the PIN pin can be directly displayed according to the parameters such as the connector, PIN and function of the input port and the output port of the device. In this way, if there is a fault in the port, the after-sales maintenance personnel can be directly prompted to check the corresponding connector circuit, which can replace the function of the existing maintenance manual.

[0059] In some embodiments, see Figure 4 , step S340 may include the contents of step S341 to step S343:

[0060] Step S271: if the second device node detects that the port status of its input port or output port is faulty, the port status parameter of the second device node is updated to a faulty state.

[0061] Step S272: Determine the fault type of the fault, and update the port fault type parameter of the second device node based on the determined fault type.

[0062] In this embodiment, the device node may include an IO driver and a diagnostic module. Based on this, the IO driver and the diagnostic module can be used to continuously check whether the port status of all input ports and output ports has changed. If the second device node detects that the port status of the input port or the output port fails, the port status parameter of the second device node will be updated to a failure state. In addition, the fault type of the port with the fault will be further determined through the IO driver and the diagnostic module, and then the port fault type parameter of the second device node will be adjusted to the determined fault type. In other words, the second device node will update the port status parameter and the port fault type parameter in its own local device tree file.

[0063] Step S273: reporting the updated port status parameter and the updated port fault type parameter to the upper-level device node of the second device node.

[0064] Furthermore, when the second device node detects that the port status of its own input port or output port has changed, it will actively report the updated content in the local device tree file to its own superior device node, that is, report the updated port status parameters and the updated port fault type parameters to its own superior device node.

[0065] For example, Figure 5 As shown, the regional controller, domain controller and common controller all contain IO drivers and diagnostic modules, so they can diagnose the status of their own IO ports in real time. If the common controller is the second device node mentioned above, and the common controller detects that there is a fault in the input port and determines that it is the target fault type, then the management module of the common controller can update its own port status parameters to fail status in the local device tree file, and will update its own port fault type parameters to the target fault type in the local device tree file. In addition, the common controller will actively report the updated content in the local device tree file to the regional controller through the bus, and correspondingly, the regional controller will update its own local device tree file according to the received content; similarly, the regional controller will also actively report the updated content in the local device tree file to the central control unit through the bus.

[0066] In other embodiments, if the second device node detects that an IO port with a port status parameter of absent has an externally connected device, the port status parameter of the IO port is updated to unknown; and the IO driver and diagnostic module in the second device node calls the corresponding driver to drive the externally connected device to work according to the type of the IO port. If the IO port is found to be in a normal state after the driver is driven, the port status parameter of the IO port is updated to ok. Similarly, the updated port status parameter is also reported to the upper-level device node of the second device node.

[0067] That is to say, during the operation of the vehicle after it is powered on, each device node in the vehicle will actively trigger the reporting of the local device tree file when it detects that the local IO has a status update. In order to save transmission time, only the device information with a status update in the local device tree file will be reported.

[0068] Step S280: based on the updated port status parameters reported by all the second device nodes, updating the file content in the complete vehicle-mounted device tree file.

[0069] Obviously, the number of second device nodes in the vehicle can be one or more, but whether it is one second device node or multiple device nodes, the port status parameters will be uploaded to the central control unit of the vehicle step by step through the topological network structure in this embodiment. In this way, the central control unit can update the file content in the complete vehicle device tree file based on the updated port status parameters reported by all second device nodes. Of course, if the aforementioned updated port status parameters are in a fault state, in addition to reporting the updated port status parameters, the updated fault type parameters will also be reported at the same time.

[0070] Step S290: Based on the updated complete vehicle-mounted device tree file, update the displayed vehicle-mounted device topology map.

[0071] Finally, based on the updated complete vehicle device tree file, the vehicle device topology map can be updated and displayed, so as to realize the real-time update and display of the device status of each device node, so that the user can observe the changes in the working status of each device node in real time.

[0072] In this embodiment, the status of the vehicle-mounted equipment can be managed in a unified structured manner, and a complete vehicle-mounted equipment topology diagram for characterizing the vehicle network topology, electrical topology status, and equipment working status can be obtained instantly, and the complete vehicle-mounted equipment topology diagram can be displayed in a visual manner, so that users can view and modify the properties and status of each device node. In addition, the abnormal status of the equipment does not need to be read and parsed through the diagnostic protocol, and can be queried based on the displayed complete vehicle-mounted equipment topology diagram. In addition, the equipment enablement status does not need to be through the configuration code, and the abnormal status does not need to be through the diagnostic fault code. It can be managed directly based on the device attribute value and displayed in the visual interface, eliminating the configuration code and fault code parsing and maintenance process, and can also directly guide maintenance personnel to carry out fault inspections based on the device attribute information.

[0073] Please refer to Figure 6 , which shows a structural block diagram of a vehicle-mounted device status acquisition device 300 provided in an embodiment of the present application. The device 300 may include: a lower-level device determination module 310, a device status acquisition module 320, and a device tree file update module 330.

[0074] The lower-level device determination module 310 is used to load the local device tree file of each first device node after the vehicle is powered on to determine the lower-level device nodes of each first device node. The first device node is a device node with lower-level device nodes among all device nodes in the vehicle. The root node of all device nodes is the central control unit of the vehicle. The local device tree file includes at least device status parameters and node names of lower-level device nodes.

[0075] The device status acquisition module 320 is used for each first device node to acquire at least part of the file content in the local device tree file of its subordinate device node, and the part of the file content at least includes the device status parameter.

[0076] The file management module 330 is used to update the file content in the local device tree file of the central control unit based on at least part of the file content obtained by each of the first device nodes, so as to obtain a complete vehicle-mounted device tree file.

[0077] In some embodiments, the local device tree file of each device node also includes the port status parameters of the input port and the output port of each device node. The vehicle-mounted device status acquisition device 300 may also include: a port monitoring module. Among them, the port monitoring module can be used to update the file content in the local device tree file of the central control unit based on at least part of the file content acquired by each first device node, and after obtaining the complete vehicle-mounted device tree file, if the second device node detects that the port status of its input port or output port has changed, then based on the changed port status, the port status parameters in the local device tree file are updated, and the updated port status parameters are reported to the upper device node of the second device node, and the second device node is any device node among all the device nodes except the central control unit.

[0078] In this manner, the file management module 330 may be specifically configured to update the file content in the complete vehicle-mounted device tree file based on the updated port status parameters reported by all the second device nodes.

[0079] In some implementations, the local device tree file of each device node also includes a port fault type parameter. The port monitoring module can be specifically used to: if the second device node detects that the port state of its input port or output port fails, update the port state parameter of the second device node to a fault state; determine the fault type of the fault, and update the port fault type parameter of the second device node based on the determined fault type; report the updated port state parameter and the updated port fault type parameter to the upper device node of the second device node.

[0080] In some embodiments, the device status acquisition module 320 can be specifically used for: each of the first device nodes sends a target request message to its subordinate device node according to the target communication protocol; each subordinate device node of the first device node generates a target reply message in response to the target request message based on at least part of the file content in its local device tree file; and feeds back the target reply message.

[0081] In some other implementations, the device status acquisition module 320 may also be specifically configured to: each first device node acquires at least a portion of the file content in the local device tree file of its subordinate device node at target time intervals.

[0082] In some embodiments, the vehicle-mounted device status acquisition device 300 may further include: a topology map generation module and a display module. The topology map generation module may be used to update the file content in the local device tree file of the central control unit based on at least part of the file content acquired based on each first device node, and after obtaining a complete vehicle-mounted device tree file, generate a vehicle-mounted device topology map according to the complete vehicle-mounted device tree file. The display module may be used to display the vehicle-mounted device topology map.

[0083] In this manner, the vehicle-mounted device status acquisition device 300 may further include: a device status adjustment module. The device status adjustment module may be specifically configured to adjust the device status parameter of the device node corresponding to the target icon to the corresponding target status parameter in response to a status adjustment operation for a target icon after displaying the vehicle-mounted device topology map, wherein the target icon is any device status icon among the multiple device status icons.

[0084] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0085] In several embodiments provided in the present application, the coupling between modules may be electrical, mechanical or other forms of coupling.

[0086] In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or software functional modules.

[0087] In summary, the present application can manage the status of vehicle-mounted devices in a unified structured manner, can instantly obtain a complete vehicle-mounted device topology diagram used to characterize the vehicle network topology, electrical topology status, and device working status, and display the complete vehicle-mounted device topology diagram in a visual manner, so that users can view and modify the properties and status of each device node. In addition, the abnormal status of the device does not need to be read and parsed through the diagnostic protocol, and can be queried based on the displayed complete vehicle-mounted device topology diagram, and can prompt maintenance personnel to troubleshoot according to fault information and related attributes.

[0088] The following will be combined Figure 7A vehicle provided in the present application is described.

[0089] Reference Figure 7 , Figure 7 A structural block diagram of a vehicle 400 provided in an embodiment of the present application is shown, and the above method provided in an embodiment of the present application can be executed by the vehicle 400.

[0090] The vehicle 400 in the embodiment of the present application may include one or more of the following components: a processor 401, a memory 402, and one or more applications, wherein the one or more applications may be stored in the memory 402 and configured to be executed by one or more processors 401, and the one or more programs are configured to execute the method as described in the aforementioned method embodiment.

[0091] The processor 401 may include one or more processing cores. The processor 401 uses various interfaces and lines to connect various parts of the entire vehicle 400, and executes various functions and processes data of the vehicle 400 by running or executing instructions, programs, code sets or instruction sets stored in the memory 402, and calling data stored in the memory 402. Optionally, the processor 401 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 401 can integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem is used to process wireless communications. It can be understood that the above-mentioned modem can also be integrated into the processor 401 and implemented separately through a communication chip.

[0092] The memory 402 may include a random access memory (RAM) or a read-only memory (ROM). The memory 402 may be used to store instructions, programs, codes, code sets or instruction sets. The memory 402 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the following various method embodiments, etc. The data storage area may also store data created by the vehicle 400 during use (such as the various corresponding relationships described above), etc.

[0093] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0094] In several embodiments provided in the present application, the coupling or direct coupling or communication connection between the modules shown or discussed may be an indirect coupling or communication connection through some interfaces, devices or modules, which may be electrical, mechanical or other forms.

[0095] In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or software functional modules.

[0096] Please refer to Figure 8 , which shows a structural block diagram of a computer-readable storage medium provided in an embodiment of the present application. The computer-readable medium 500 stores program codes, which can be called by a processor to execute the method described in the above method embodiment.

[0097] The computer readable storage medium 500 may be an electronic memory such as a flash memory, an EEPROM (electrically erasable programmable read-only memory), an EPROM, a hard disk, or a ROM. Optionally, the computer readable storage medium 500 includes a non-transitory computer-readable storage medium. The computer readable storage medium 500 has storage space for program code 510 that performs any method step of the above method. These program codes can be read from or written to one or more computer program products. The program code 510 can be compressed, for example, in an appropriate form.

[0098] In some embodiments, a computer program product or computer program is provided, the computer program product or computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device performs the steps in the above-mentioned method embodiments.

[0099] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. 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 cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for obtaining the status of a vehicle-mounted device, characterized in that: The method comprises: After the vehicle is powered on, a local device tree file of each first device node is loaded to determine a subordinate device node of each first device node, wherein the first device node is a device node having a subordinate device node among all device nodes in the vehicle, the root node of all device nodes is a central control unit of the vehicle, and the local device tree file includes at least a device state parameter and a node name of a subordinate device node; Each first device node obtains at least part of the file content in the local device tree file of its subordinate device node, wherein the part of the file content at least includes the device status parameter; Based on at least part of the file content acquired by each of the first device nodes, the file content in the local device tree file of the central control unit is updated to obtain a complete vehicle-mounted device tree file.

2. The method according to claim 1, characterized in that: The local device tree file of each device node also includes port status parameters of the input port and output port of each device node; After updating the file content in the local device tree file of the central control unit based on at least part of the file content obtained by each first device node to obtain a complete vehicle-mounted device tree file, the method further includes: If the second device node detects that the port state of its input port or output port has changed, the port state parameter in the local device tree file is updated based on the changed port state, and the updated port state parameter is reported to the upper-level device node of the second device node, where the second device node is any device node among all the device nodes except the central control unit; Based on the updated port status parameters reported by all the second device nodes, the file content in the complete vehicle-mounted device tree file is updated.

3. The method according to claim 2, characterized in that The local device tree file of each device node also includes a port fault type parameter; If the second device node detects that the port state of its input port or output port has changed, the port state parameter in the local device tree file is updated based on the changed port state, and the updated port state parameter is reported to the upper-level device node of the second device node, including: If the second device node detects that the port status of its input port or output port fails, the port status parameter of the second device node is updated to a failure status; Determining a fault type of the fault, and updating a port fault type parameter of the second device node based on the determined fault type; The updated port status parameter and the updated port fault type parameter are reported to the upper-level device node of the second device node.

4. The method according to claim 1, characterized in that: Each first device node obtains at least part of the file content in the local device tree file of its subordinate device node, including: Each of the first device nodes sends a target request message to its subordinate device node according to the target communication protocol; Each subordinate device node of the first device node generates a target reply message in response to the target request message based on the at least part of the file content in its local device tree file; Feedback the target reply message.

5. The method according to claim 1, characterized in that Each first device node obtains at least part of the file content in the local device tree file of its subordinate device node, including: Each first device node obtains at least a portion of the file content in the local device tree file of its subordinate device node at every target time length.

6. The method according to any one of claims 1 to 5, characterized in that: After updating the file content in the local device tree file of the central control unit based on at least part of the file content obtained by each first device node to obtain a complete vehicle-mounted device tree file, the method further includes: Generate a vehicle-mounted device topology map according to the complete vehicle-mounted device tree file; The vehicle-mounted equipment topology diagram is displayed.

7. The method according to claim 6, characterized in that The vehicle-mounted device topology diagram includes a plurality of device status icons, and the plurality of device status icons correspond one-to-one to all the device nodes; After displaying the in-vehicle device topology map, the method further includes: In response to a state adjustment operation for a target icon, a device state parameter of a device node corresponding to the target icon is adjusted to a corresponding target state parameter, and the target icon is any one of the multiple device state icons.

8. A vehicle status acquisition device, characterized in that: The device comprises: A lower-level device determination module is used to load the local device tree file of each first device node after the vehicle is powered on to determine the lower-level device node of each first device node, wherein the first device node is a device node having a lower-level device node among all device nodes in the vehicle, the root node of all device nodes is the central control unit of the vehicle, and the local device tree file includes at least device status parameters and node names of lower-level device nodes; A device status acquisition module, configured for each first device node to acquire at least part of the file content in the local device tree file of its subordinate device node, wherein the part of the file content at least includes the device status parameter; The device tree file update module is used to update the file content in the local device tree file of the central control unit based on at least part of the file content obtained by each of the first device nodes to obtain a complete vehicle-mounted device tree file.

9. A vehicle, characterized in that: The vehicle comprises: one or more processors; Memory; One or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program code, which can be called by a processor to execute the method according to any one of claims 1 to 7.

Images