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

Abstract

The application discloses a vehicle-mounted equipment state acquisition method and device, a vehicle and a storage medium, and relates to the technical field of vehicles. The method comprises the following steps: after the vehicle is powered on, loading a local device tree file of each first device node to determine the subordinate device nodes of each first device node, the root node of all device nodes being a central control unit of the vehicle, and the local device tree file comprising a device state parameter and a node name of the subordinate device node; each first device node acquires at least part of file content in the local device tree file of the subordinate device node, and the part of file content at least comprises the device state parameter; and based on the at least part of file content acquired 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 equipment tree file. In this way, the central control unit can dynamically construct and maintain a complete vehicle-mounted equipment tree, and then more efficiently implement state management on the vehicle-mounted equipment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicles, and in particular to a method and device for acquiring a state of a vehicle-mounted device, a vehicle, and a storage medium. BACKGROUND

[0002] Automotive electronic and electrical architectures are developing towards centralized computing and regional control. More and more vehicle-mounted devices such as controllers, sensors, and actuators in various fields of the vehicle are being connected. How to effectively manage these vehicle-mounted devices has become a problem to be solved. SUMMARY

[0003] The present application provides a method and device for acquiring a state of a vehicle-mounted device, a vehicle, and a storage medium, to more efficiently manage the state of the vehicle-mounted device.

[0004] In a first aspect, the present application provides a method for acquiring a state of a vehicle-mounted device. 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. The first device node is a device node having a subordinate device node among all device nodes in the vehicle. A root node of the all device nodes is a central control unit of the vehicle. The local device tree file includes at least a device state parameter and a node name of the subordinate device node. Each first device node acquires at least part of file content in the local device tree file of the subordinate device node, and the part of file content includes at least the device state parameter. Based on the at least part of file content acquired by each first device node, file content in a local device tree file of the central control unit is updated to obtain a complete vehicle-mounted device tree file.

[0005] In a second aspect, the present application provides a device for acquiring a state of a vehicle-mounted device. The device includes a subordinate device determination module, a device state acquisition module, and a device tree file update module. The subordinate device determination module is configured to load a local device tree file of each first device node after the vehicle is powered on to determine a subordinate device node of each first device node. The first device node is a device node having a subordinate device node among all device nodes in the vehicle. A root node of the all device nodes is a central control unit of the vehicle. The local device tree file includes at least a device state parameter and a node name of the subordinate device node. The device state acquisition module is configured to acquire at least part of file content in the local device tree file of the subordinate device node by each first device node, and the part of file content includes at least the device state parameter. The device tree file update module is configured to update file content in a local device tree file of the central control unit based on the at least part of file content acquired by each first device node 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; and 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 perform the method described above.

[0007] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a program code, and the program code can be invoked by a processor to perform the method described above.

[0008] In the scheme 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 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 at least includes a device state parameter and a node name of the subordinate device node; each first device node acquires at least part of the file content in the local device tree file of the subordinate device node, and the part of the file content at least includes the device state parameter; and based on the at least part of the file content acquired 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 state of each hierarchical device node is recursively acquired, so that the central control unit can timely acquire the latest device state of all device nodes, the complete vehicle-mounted device tree is dynamically constructed and maintained, and the state management of the vehicle-mounted device is more efficiently implemented. BRIEF DESCRIPTION OF DRAWINGS

[0009] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0010] Figure 1 A flowchart of a vehicle-mounted device state acquisition method provided by an embodiment of the present application is shown.

[0011] Figure 2 A hierarchical diagram of a vehicle-mounted device provided by an embodiment of the present application is shown.

[0012] Figure 3 A flowchart of a vehicle-mounted device state acquisition method provided by another embodiment of the present application is shown.

[0013] Figure 4A flowchart of sub-steps in step S270 in an embodiment is shown. Figure 3 A flowchart of sub-steps in step S270 in an embodiment is shown.

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

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

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

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

[0018] In order to make the personnel in the technical field better understand the scheme of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0019] It should be noted that in some of the processes described in the specification, claims, and above drawings, a number of operations are described in a specific order. These operations can not be performed in the order described or in parallel. The serial number of the operations, such as S110, S120, etc., is only used to distinguish different operations, and the serial number itself does not represent any execution order. In addition, these processes can include more or fewer operations, and the operations can be performed in sequence or in parallel. In addition, the terms "first", "second", etc. in the specification and claims and above drawings are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or server including a series of steps or sub-modules does not necessarily limit to those steps or sub-modules clearly listed, but can include other steps or sub-modules not clearly listed or inherent to these processes, methods, products or devices.

[0020] The present application provides a vehicle-mounted device state acquisition method, device, vehicle and storage medium.

[0021] Please refer to Figure 1 , Figure 1 A flowchart of a vehicle-mounted device state acquisition method provided by an embodiment of the present application is shown in FIG. 1. The vehicle-mounted device state acquisition method provided by an embodiment of the present application will be described in detail below. Figure 1 The vehicle-mounted device state acquisition method provided by an embodiment of the present application can 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 a subordinate device node among all device nodes in the vehicle, the root node of the all device nodes is the central control unit of the vehicle, and the local device tree file at least includes a device state parameter and a node name of the subordinate device node.

[0023] In the embodiment, all device nodes in the vehicle can include a central control unit (CCU), an electronic controller (ECU), a sensor (Sensor) and an actor (Actor) of the vehicle, and the central control unit includes a central gateway (CGW) or a centralized computing platform. The electronic controller can include a regional controller, a domain controller and a general controller. The regional controller is divided according to physical location, and a regional controller is arranged for each different region, so that the sensors and actors in the region are directly connected to the nearest regional controller, thereby providing better scalability for the vehicle; for example, a front body region controller, a rear body region controller, a left body region controller and a right body region controller. The domain controller is generally divided according to functional domain, i.e., different domain controllers are responsible for different functions of the vehicle, for example, a power domain controller, a chassis domain controller, a cabin domain controller and an automatic driving domain controller; the power domain controller is mainly responsible for regulating and controlling 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 brake. The general controller generally refers to some traditional controllers, for example, a brake controller, an air conditioner controller and an engine controller.

[0024] Before the vehicle is shipped, the vehicle can be organized in a central control unit centric manner with the vehicle network segmented, all controllers, actuators and sensors in the vehicle organized in a hierarchical manner, for example, CANFD1 represents the 1st CANFD channel of the central control unit, EthernetPort1 represents the 1st Ethernet port, and LIN1 represents the 1st LIN channel, so as to obtain a root node and multiple levels of child nodes. Moreover, 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 a node attribute parameter of itself and a node name of a subordinate device node, and the node attribute parameter at least includes a node name and a device status parameter; in simple terms, the device node can learn which device the subordinate device node of itself is by loading the local device tree file stored in itself. The device status parameter can include multiple states such as ok, disable, absent, fail, unknown and update.

[0025] Exemplarily, as shown in Figure 2 , all controllers, actuators and sensors in the vehicle are organized in a hierarchical manner, so as to obtain the central control unit as a root node, the first level of child nodes, the second level of child nodes and the third level of child nodes; the first level of child nodes includes the regional controller and the domain controller, the second level of child nodes includes the ordinary controller, the sensor and the actuator 2, and the third level of child nodes includes the actuator 1. That is, after the vehicle is powered on, Figure 2 , the central control unit, the regional controller, the domain controller and the ordinary controller in the vehicle can all be regarded as the first device node mentioned above. That is, the central control unit can learn which device the subordinate device node of itself is by loading the local device tree file stored in itself; similarly, the domain controller can also learn which device the subordinate device node of itself is by loading the local device tree file stored in itself; and the ordinary controller can also learn which device the subordinate device node of itself is 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 the local device tree file in itself, 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 parameter of the subordinate device node.

[0027] Optionally, in addition to the device status parameter, the aforementioned node attribute parameters may also include device type, manufacturer, model, and version parameters. The device type parameter can include general device types and special device types. Devices of the general device type can use a unified interface for device control and data interaction, while devices of the special device type require a proprietary interface for control and data interaction. The manufacturer parameter is the name of the device supplier, the model parameter includes the device's part number and model number (the device type can be accurately distinguished by comparing the model parameter), and the version parameter indicates the specific version of the device.

[0028] Of course, the local device tree file can also contain device-specific attribute parameters for different devices. For example, a camera's local device tree file can include specific attribute parameters such as pixels and maximum frame rate. Similarly, a storage device's local device tree file can include specific attribute parameters such as storage type and storage capacity. And a display device's local device tree file can include specific attribute parameters such as resolution.

[0029] It should be noted that central control units, domain controllers, and area controllers generally store local device tree files in file format, while ordinary controllers generally do not support file format storage and instead store local device tree files in structured data format.

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

[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, each subordinate device node of the 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 sends the target reply message back to the first device node corresponding to the subordinate device node.

[0032] Optionally, for the first device node supporting Ethernet, an HTTP request message can be sent to the subordinate device node corresponding to the first device node according to the HTTP protocol under Ethernet and through the GET method. Similarly, the subordinate device node can generate an HTTP reply message based on at least part of the file content of the requested local device tree file in response to the HTTP request message, and feed back the HTTP reply message to the 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 the vehicle all support Ethernet, as shown in FIG. 8, the central control unit as the first device node, and the subordinate device nodes of the central control unit include the regional controller and the domain controller, so the transmission of the target request message and the target reply message between the central control unit and the regional controller and between the central control unit and the domain controller can be based on the HTTP protocol. Figure 2

[0033] Optionally, for the first device node not supporting Ethernet, a CAN / CANFD request message with a specified ID can be sent to the subordinate device node according to the CAN protocol or the CANFD protocol. Similarly, the subordinate device node can generate a CAN / CANFD reply message based on at least part of the file content of the requested local device tree file in response to the CAN / CANFD request message, and feed back the CAN / CANFD reply message to the corresponding first device node.

[0034] ​In some embodiments, if the length of the 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 of CAN / CANFD reply message is generated based on the at least part of the file content requested. If the length of the 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 the at least part of the file content requested, and the multi-frame CAN / CANFD reply message is fed back to the corresponding first device node in sequence. Specifically, the effective data length of a frame of CAN / CANFD message after adding the fragment sequence number is determined, and then the target number of CAN / CANFD messages is determined based on the length of the at least part of the file content and the effective data length of a frame of CAN / CANFD message. Then, the data in the at least part of the file content is filled into the target number of CAN / CANFD messages in sequence according to the fragment sequence number and the byte stream order, and 00 is filled in the byte position not filled in the target number of CAN / CANFD messages.

[0035] Exemplarily, the at least part of the file content is 40 bytes, a single frame of CAN message supports a maximum of 8 bytes, a CANFD message supports a maximum of 64 bytes, and the first byte is used to store the fragment sequence number (increased by 1 in sequence from 0). It can be known that, since the fragment sequence number needs to occupy 1 byte, a single frame of CAN message after adding the fragment sequence number can store a maximum of 7 bytes, and it can be determined that at least 6 frames of CAN messages are needed to transmit the 40 bytes of at least part of the file content. Therefore, the 40 bytes of at least part of the file content is filled into 6 frames of CAN messages in sequence according to the fragment sequence number and the byte stream order, and ASCII code 03 (ETX) is added at the end of the byte stream of the 6th frame of message. If there is an unfilled byte position in the last frame of message, 00 is filled therein.

[0036] In some embodiments, when the host vehicle receives a power-on instruction, each first device node can acquire all file content in the local device tree file of the subordinate device node in response to the power-on instruction. That is, when the host vehicle is powered on, the first device node of each level can completely acquire the device state parameters, node attribute parameters and special attribute parameters of the subordinate device.

[0037] In some other embodiments, during the operation after the power-on of the vehicle, since part of the fixed parameters (e.g. the device type parameter, the version parameter, the manufacturer parameter, and the manufacturer parameter, etc.) have been acquired when the vehicle responds to the power-on instruction, and the device status parameter may change during the operation of the vehicle, each first device node can only acquire the device status parameter in the local device tree file of the subordinate device node thereof, thereby improving the acquisition efficiency of the parameters.

[0038] In this way, each first device node acquires at least part of the file content in the local device tree file of the subordinate device node thereof every target time length. The target time length can be determined based on the node address of each first device node and a preset time length, specifically, the target time length = (node address-fixed constant)*20 milliseconds. In this way, real-time updating of the device status in the complete vehicle-mounted device tree file can be realized; and since the node addresses of different first device nodes are different, the target time lengths corresponding to different first device nodes are different, i.e. different first device nodes are set with different delay time lengths, so as to avoid short-time communication conflicts.

[0039] Optionally, each first device node can acquire at least part of the file content in the local device tree file of the subordinate device node thereof at the same time. Of course, it can also be that each first device node located at the penultimate level is sequentially segmented to acquire the local device tree file of the subordinate device node thereof from bottom to top, and so on.

[0040] Step S130: based on the at least part of the file content acquired 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.

[0041] It can be understood that in the initial local device tree file of the central control unit, only the device status parameter of itself and the node name of all the device nodes of the first level child node are included. After step S120, each first device node acquires at least the device status parameter of the subordinate device node thereof, so that the device status parameter acquired by each first device node and the file content in the local device tree file in the central control unit are integrated according to the network segmentation and the node name, and a complete vehicle-mounted device tree file is obtained. The complete vehicle-mounted device tree file at least includes the node name and the device status parameter of all the device nodes in the vehicle.

[0042] In the embodiment, the device state of each hierarchical device node is obtained recursively by loading the local device tree file of each first device node, so that the central control unit can obtain the latest device state of all device nodes in time, and a complete vehicle-mounted device tree is dynamically constructed and maintained, and the state management of the vehicle-mounted device is more efficiently realized.

[0043] Please refer to Figure 3 , Figure 3 A flowchart of a vehicle-mounted device state acquisition method provided by another embodiment of the application is shown. The vehicle-mounted device state acquisition method provided by the embodiment of the application will be described in detail below. Figure 3 The vehicle-mounted device state acquisition method provided by the embodiment of the application can include the following steps:

[0044] Step S210: After the vehicle is powered on, the local device tree file of each first device node is loaded to determine the subordinate device nodes of each first device node, the first device node is a device node having a subordinate device node in all device nodes of the vehicle, the root node of the all device nodes is the central control unit of the vehicle, and the local device tree file at least includes a device state parameter and a node name of a subordinate device node.

[0045] Step S220: Each first device node acquires at least part of the file content in the local device tree file of the subordinate device node, and the part of the file content at least includes the device state parameter.

[0046] Step S230: Based on the at least part of the file content acquired 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.

[0047] In the embodiment, the specific implementation of steps S210 to S230 can refer to the content in the foregoing embodiments, which will not be described here.

[0048] Step S240: A vehicle-mounted device topology diagram is generated according to the complete vehicle-mounted device tree file.

[0049] Step S250: The vehicle-mounted device topology diagram is displayed, and the vehicle-mounted device topology diagram includes a plurality of device state icons, and the plurality of device state icons correspond to the all device nodes one by one.

[0050] In the embodiment, to enable the user to intuitively and quickly know the attributes of each device node in the vehicle and the device state, after obtaining the complete vehicle-mounted device tree file, a corresponding vehicle-mounted device topology graph can be generated and displayed in the visualization interface. In this way, the user can know the topology relationship between each device node in the vehicle, the attributes of each device node and the real-time device state through the displayed vehicle-mounted device topology graph.

[0051] In some embodiments, a vehicle-mounted device state display application can be installed in the vehicle, and the vehicle-mounted device topology graph can be displayed in the application interface of the vehicle-mounted device state display application. In this way, the driver of the vehicle or the maintenance personnel of the vehicle can quickly know the attributes of each device node and the device state through the vehicle-mounted device state display application on the vehicle screen, so as to directly guide the maintenance personnel to carry out fault checking work in the case of vehicle failure.

[0052] In other embodiments, a vehicle-mounted device state display application can also be installed in the terminal device used by the user, including but not limited to a smart phone, a tablet computer, a notebook computer and a desktop computer. Based on this, the vehicle-mounted device topology graph in the vehicle can also be transmitted to the cloud, transmitted to the terminal device used by the user through the cloud, and displayed in the application interface of the vehicle-mounted device state display application of the terminal device. In this way, the remote maintenance personnel can also know the device state of each device node in the vehicle through the terminal device in the case of vehicle failure.

[0053] Specifically, the displayed vehicle-mounted device topology graph contains a device state icon corresponding to each device node in the vehicle, and the device state icons under different device state parameters are displayed differently. For example, the device state icons under different device state parameters are displayed in different colors; the device state icon with an ok device state parameter is displayed in green, the device state icon with a fail device state parameter is displayed in red, the device state icon with a disable device state parameter is displayed in gray, the device state icon with an absent device state parameter is displayed in black, the device state icon with an unknown device state parameter is displayed in orange, and the device state icon with an update device state parameter is displayed in blue. In this way, the differences between the device states of each device node can be more intuitively displayed.

[0054] Optionally, the local device tree file of each device node can also include a device failure type parameter (failure). Based on this, when the device state parameter of any device node is fail, the failure type parameter of the device node with the failure will be displayed on the vehicle device topology diagram. 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 state of each device node through the application display interface of the vehicle device state display application, so as to intuitively and quickly understand the device node with the failure and the specific failure type.

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

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

[0057] Step S270: If the second device node monitors that the port state of the input port or the output port thereof changes, updating the port state parameter in the local device tree file based on the changed port state, and reporting the updated port state parameter to the upper device node of the second device node, the second device node being any device node in the all device nodes except the central control unit.

[0058] In the embodiment, the local tree device file in each device node can also include port parameters of the input port and the output port. The port parameters can include connector, PIN, port function, port status parameter, and port fault type parameter. Similarly, in the complete vehicle device topology diagram shown above, the port parameters of each device node are also visually displayed. That is, in the application interface of the vehicle device status display application, the relationship between the functions of each device node in the vehicle and the connectors and PINs can be directly displayed according to the connector, PIN, and function parameters of the input port and the output port of the device. In this way, if the port is faulty, the corresponding connector loop can be directly prompted to the after-sales maintenance personnel for checking, which can replace the function of the existing maintenance manual.

[0059] In some embodiments, referring to Figure 4 , step S340 can include the contents in steps S341-S343:

[0060] Step S271: If the second device node monitors that the port status of the input port or the output port thereof fails, the port status parameter of the second device node is updated to a failure state.

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

[0062] In the embodiment, the device node can include an IO driver and a diagnosis module. Based on this, the IO driver and the diagnosis module can be used to continuously check whether the port status of all input ports and output ports changes. If the second device node monitors that the port status of the input port or the output port fails, the port status (status) parameter of the second device node is updated to a failure (fail) state. Further, the IO driver and the diagnosis module are used to determine the fault type of the failed port, and the port fault type parameter of the second device node is adjusted to the determined fault type. That is, the second device node updates the port status parameter and the port fault type parameter in the local device tree file thereof.

[0063] Step S273: Report the updated port status parameter and the updated port fault type parameter to the superior device node of the second device node.

[0064] Further, the second device node will actively report the updated content in the local device tree file to its superior device node, i.e. report the updated port state parameter and the updated port fault type parameter to its superior device node, when detecting that the port state of its input port or output port has changed.

[0065] Exemplarily, as shown in Figure 5 If the normal controller is the second device node, when the normal controller detects that the input port has a fault and determines that the target fault type, the management module of the normal controller can update the port state parameter of the normal controller to the fail state in the local device tree file, and can update the port fault type parameter of the normal controller to the target fault type in the local device tree file. Further, the normal controller will actively report the updated content in the local device tree file to the area controller through the bus, and correspondingly, the area controller will update its local device tree file according to the received content. Similarly, the area controller will also actively report the updated content in the local device tree file to the central control unit through the bus.

[0066] In some other embodiments, if the second device node monitors that the IO port with the port state parameter of absent has an external access device, the port state parameter of the IO port will be updated to unknown correspondingly; and the IO drive and diagnosis module in the second device node will call the corresponding driver to drive the external access device to work according to the type of the IO port. If the state of the IO port is normal after driving, the port state parameter of the IO port will be updated to ok. Similarly, the updated port state parameter will also be reported to the superior device node of the second device node.

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

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

[0069] Obviously, the number of the second device nodes in the vehicle can be one or multiple, but no matter one or multiple second device nodes, the port state parameters are uploaded to the central control unit of the vehicle through the topology network structure in the 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 state parameters reported by all second device nodes. Of course, if the aforementioned updated port state parameter is a fault state, the updated fault type parameter will be reported at the same time in addition to the updated port state parameter.

[0070] Step S290: updating the displayed vehicle device topology diagram based on the updated complete vehicle device tree file.

[0071] Finally, the displayed vehicle device topology diagram can be updated based on the updated complete vehicle device tree file, so as to realize real-time updating and displaying of the device state of each device node, and the user can observe the change of the working state of each device node in real time.

[0072] In the embodiment, the vehicle devices can be managed in a unified structured manner, the complete vehicle device topology diagram for representing the network topology, electrical topology state and device working state of the vehicle can be obtained in real time, and the complete vehicle device topology diagram can be displayed in a visual manner, so as to facilitate the user to view and modify the attributes and states of each device node. Moreover, the abnormal state of the device does not need to be read and analyzed through a diagnosis protocol, the device enabled state does not need to be configured through a code, and the abnormal state does not need to be diagnosed through a fault code, so the device attributes values can be directly managed and displayed in the visual interface, and the configuration code and fault code analysis and maintenance process are saved, and the maintenance personnel can be directly guided to carry out fault inspection according to the device attribute information.

[0073] Please refer to Figure 6 Fig. 1 shows a structural block diagram of a vehicle device state acquisition apparatus 300 provided in an embodiment of the application. The apparatus 300 can include a subordinate device determination module 310, a device state acquisition module 320 and a device tree file updating module 330.

[0074] The subordinate device determination module 310 is configured 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, wherein the first device node is a device node having a subordinate device node in all device nodes of the vehicle, the root node of the all device nodes is the central control unit of the vehicle, and the local device tree file at least includes a device state parameter and a node name of the subordinate device node.

[0075] The device state acquisition module 320 is configured to acquire, by each first device node, at least part of file content in a local device tree file of a subordinate device node of the first device node, the at least part of file content including at least the device state parameter.

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

[0077] In some embodiments, the local device tree file of each device node further includes port state parameters of input ports and output ports of each device node. The vehicle-mounted device state acquisition apparatus 300 can further include a port monitoring module. The port monitoring module can be configured to, after the file content in the local device tree file of the central control unit is updated based on the at least part of file content acquired by each first device node to obtain the complete vehicle-mounted device tree file, if a second device node monitors that a port state of an input port or an output port of the second device node changes, update the port state parameters in the local device tree file based on the changed port state, and report the updated port state parameters to a superior device node of the second device node, the second device node being any device node in the all device nodes except the central control unit.

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

[0079] In some embodiments, the local device tree file of each device node further includes a port fault type parameter. The port monitoring module can be specifically configured to, if the second device node monitors that a port state of an input port or an output port of the second device node fails, update the port state parameters of the second device node to a fault state, determine a fault type of the fault, update the port fault type parameter of the second device node based on the determined fault type, and report the updated port state parameters and the updated port fault type parameter to the superior device node of the second device node.

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

[0081] In some embodiments, the device state acquisition module 320 can be further configured to acquire at least part of the file content in the local device tree file of each first device node from its subordinate device node every target time length.

[0082] In some embodiments, the vehicle device state acquisition apparatus 300 can further include a topology graph generation module and a display module. The topology graph generation module can be configured to generate a vehicle device topology graph according to the complete vehicle device tree file after updating the file content in the local device tree file of the central control unit based on the at least part of the file content acquired by each first device node to obtain the complete vehicle device tree file. The display module can be configured to display the vehicle device topology graph.

[0083] In this way, the vehicle device state acquisition apparatus 300 can further include a device state adjustment module. The device state adjustment module can be configured to adjust the device state parameter of the device node corresponding to the target icon to a corresponding target state parameter in response to a state adjustment operation on a target icon after displaying the vehicle device topology graph, the target icon being any device state icon in the plurality of device state icons.

[0084] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described apparatuses and modules can refer to the corresponding process in the foregoing method embodiments, which will not be described herein.

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

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

[0087] In summary, the present application can manage the state of the vehicle device in a unified structured manner, can acquire a complete vehicle device topology graph representing the network topology, electrical topology state and device working state of the whole vehicle in real time, and display the complete vehicle device topology graph in a visual manner, so as to facilitate the user to view and modify the attributes and states of each device node. Moreover, the abnormal state of the device does not need to be read and analyzed through a diagnosis protocol, but can be inquired based on the displayed complete vehicle device topology graph, and the maintenance personnel can be prompted for troubleshooting mode according to the fault information and associated attributes.

[0088] The above description will be further illustrated below with reference to the accompanying drawings. Figure 7A vehicle provided by the present application is described.

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

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

[0091] The processor 401 can include one or more processing cores. The processor 401 connects various parts in the vehicle 400 by using various interfaces and lines, executes various functions of the vehicle 400 and processes data 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 of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 401 can be integrated with a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU is mainly used to process an operating system, a user interface, and an application program; the GPU is used to be responsible for rendering and drawing display content; and the modem is used to process wireless communication. It can be understood that the above-mentioned modem can also be integrated into the processor 401, and be realized separately by a communication chip.

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

[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 foregoing method embodiments, which will not be described herein.

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

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

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

[0097] The computer readable storage medium 500 can 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. Alternatively, the computer readable storage medium 500 includes a non-transitory computer readable medium. The computer readable storage medium 500 has a storage space for program codes 510 for performing any of the method steps in the foregoing methods. These program codes can be read out from or written into one or more computer program products. The program codes 510 can be compressed in an appropriate form, for example.

[0098] In some embodiments, a computer program product or computer program is provided, which includes computer instructions 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 each of the above 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 limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for part of the technical features; and these modifications or replacements do not drive 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 of acquiring a state of a vehicle-mounted device, characterized by, The method comprises: loading a local device tree file of each first device node to determine the subordinate device nodes of each first device node after the vehicle is powered on, the first device node being a device node with subordinate device nodes among all device nodes in the vehicle, a root node of the all device nodes being a central control unit of the vehicle, the local device tree file at least including a device state parameter and a node name of the subordinate device node; each first device node acquires at least part of file content in the local device tree file of its subordinate device node, the part of file content at least including the device state parameter; updating file content in the local device tree file of the central control unit based on at least part of file content acquired by each first device node to obtain a complete vehicle-mounted device tree file; generating a vehicle-mounted device topology map according to the complete vehicle-mounted device tree file; displaying the vehicle-mounted device topology map, the vehicle-mounted device topology map including a plurality of device state icons, the plurality of device state icons corresponding to the all device nodes one by one; in response to a state adjustment operation on a target icon, adjusting the device state parameter of the device node corresponding to the target icon to a corresponding target state parameter, the target icon being any device state icon in the plurality of device state icons.

2. The method of claim 1, wherein, The local device tree file of each device node further includes port state parameters of an input port and an output port of each device node; after the updating of the file content in the local device tree file of the central control unit based on at least part of file content acquired by each first device node to obtain a complete vehicle-mounted device tree file, the method further comprises: if a second device node monitors a change in a port state of its input port or output port, updating the port state parameter in the local device tree file based on the changed port state and reporting the updated port state parameter to a superior device node of the second device node, the second device node being any device node among the all device nodes except the central control unit; updating the file content in the complete vehicle-mounted device tree file based on the updated port state parameters reported by all the second device nodes.

3. The method of claim 2, wherein, The local device tree file of each device node further includes a port fault type parameter; if the second device node monitors a change in a port state of its input port or output port, updating the port state parameter in the local device tree file based on the changed port state and reporting the updated port state parameter to a superior device node of the second device node, comprising: if the second device node monitors a fault in a port state of its input port or output port, updating the port state parameter of the second device node to a fault state; determining a fault type of the fault and updating the port fault type parameter of the second device node based on the determined fault type; reporting the updated port state parameter and the updated port fault type parameter to the superior device node of the second device node.

4. The method of claim 1, wherein, Each first device node acquires at least part of file content in a local device tree file of a subordinate device node of the first device node, including: Each first device node sends a target request message to a subordinate device node of the first device node according to a target communication protocol; The subordinate device node of each first device node generates a target reply message based on the at least part of file content in the local device tree file of the subordinate device node in response to the target request message; The target reply message is fed back.

5. The method of claim 1, wherein, Each first device node acquires at least part of file content in a local device tree file of a subordinate device node of the first device node, including: Each first device node acquires at least part of file content in a local device tree file of a subordinate device node of the first device node every target time length.

6. An acquisition device of a state of a vehicle, characterized by comprising: The apparatus includes: A subordinate device determination module, configured to load a local device tree file of each first device node after the vehicle is powered on, to determine a subordinate device node of each first device node, the first device node being a device node with a subordinate device node among all device nodes in the vehicle, a root node of the all device nodes being a central control unit of the vehicle, the local device tree file including at least a device state parameter and a node name of the subordinate device node; A device state acquisition module, configured to acquire at least part of file content in a local device tree file of a subordinate device node of each first device node, the part of file content including at least the device state parameter; A device tree file update module, configured to update file content in a local device tree file of the central control unit based on at least part of file content acquired by each first device node, to obtain a complete vehicle-mounted device tree file; A topology graph generation module, configured to generate a vehicle-mounted device topology graph according to the complete vehicle-mounted device tree file; A display module, configured to display the vehicle-mounted device topology graph, the vehicle-mounted device topology graph including a plurality of device state icons, the plurality of device state icons corresponding to the all device nodes one by one; A device state adjustment module, configured to adjust a device state parameter of a device node corresponding to a target icon to a corresponding target state parameter in response to a state adjustment operation on the target icon, the target icon being any device state icon in the plurality of device state icons.

7. A vehicle characterized by comprising: The vehicle includes: 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, the one or more programs being configured to perform the method of any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores program code, the program code being executable by a processor to perform the method of any one of claims 1 to 5.

Images