Vehicle state detection method, device and equipment and readable storage medium
By deploying Ethernet OAM for multiple components of the vehicle and obtaining status information through Ethernet OAM, the problem of low vehicle detection efficiency under CAN communication is solved, and more efficient status and fault detection is achieved, improving the safety and reliability of the vehicle.
Patent Information
- Application Number
- CN202411635838.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-15
- Publication Date
- 2025-03-07
AI Technical Summary
When a vehicle using CAN communication detects the functional state of each component on the vehicle and detects the communication state between each component, the detection efficiency is low.
Ethernet OAM is deployed for multiple components of a vehicle that requires status detection, and status information of multiple components of the vehicle and communication status between the multiple components are obtained through Ethernet OAM.
Through the Ethernet OAM mechanism, the status information of multiple components of the vehicle and the communication status between the multiple components can be quickly obtained, which has higher status and fault detection efficiency compared to vehicles that use CAN communication, improving the safety and reliability of the vehicle.
Smart Images

Figure CN119583401A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle safety technology, and in particular to a vehicle status detection method, device, equipment and readable storage medium. Background Art
[0002] Vehicles are composed of many parts. It is self-evident that ensuring the good condition of each part and the normal communication between each part is important for vehicle safety. Therefore, it is necessary to timely detect the functional status of each part of the vehicle and the communication status between each part in order to timely control the safety status of the vehicle. CAN communication is widely used in the automotive field. CAN, the full name of Controller Area Network in English, is a serial communication protocol specially designed for high-speed real-time data transmission. It is used for communication between various electronic control systems inside the car.
[0003] However, vehicles using CAN communication have a problem of low detection efficiency when performing functional status detection on various components on the vehicle and communication status detection between various components. Summary of the invention
[0004] The present application provides a vehicle status detection method, device, equipment and readable storage medium, aiming to solve the technical problem that a vehicle using CAN communication has low detection efficiency when performing functional status detection on various components on the vehicle and communication status detection between various components.
[0005] In a first aspect, an embodiment of the present application provides a vehicle state detection method, the vehicle state detection method comprising:
[0006] Deploy Ethernet OAM for multiple components of the vehicle that require status monitoring;
[0007] The status information of multiple components of the vehicle and the communication status between multiple components are obtained through Ethernet OAM.
[0008] Optionally, the deploying Ethernet OAM for multiple components of a vehicle that require status detection includes:
[0009] Deploy Ethernet OAM communication protocols for multiple components of the vehicle that require status detection;
[0010] Create maintenance domains for multiple vehicle components that require condition monitoring;
[0011] Configure maintenance sets for maintenance domains;
[0012] Configure maintenance endpoints for a maintenance set, one for each vehicle component.
[0013] Optionally, the obtaining of status information of multiple components of the vehicle and communication status between the multiple components through Ethernet OAM includes:
[0014] The connectivity status between the maintenance endpoints is detected by sending continuity detection messages between the maintenance endpoints to determine the communication status between the vehicle components corresponding to the maintenance endpoints.
[0015] Optionally, the obtaining of status information of multiple components of the vehicle and communication status between the multiple components through Ethernet OAM further includes:
[0016] The source maintenance endpoint sends a loopback message to the target maintenance endpoint to detect the link status between the source maintenance endpoint and the target maintenance endpoint, so as to determine the communication status between the vehicle components respectively corresponding to the source maintenance endpoint and the target maintenance endpoint.
[0017] Optionally, the obtaining of status information of multiple components of the vehicle and communication status between the multiple components through Ethernet OAM further includes:
[0018] The status information of the vehicle component corresponding to the maintenance endpoint is obtained through the status flag bit carried in the message sent by each maintenance endpoint.
[0019] Optionally, after obtaining the status information of multiple components of the vehicle and the communication status between the multiple components through Ethernet OAM, the method further includes:
[0020] Displays status information of multiple components to the vehicle instruments.
[0021] Optionally, the vehicle state detection method further includes:
[0022] Enable or disable the Ethernet OAM function according to the received instructions.
[0023] In a second aspect, an embodiment of the present application provides a vehicle state detection device, the vehicle state detection device comprising:
[0024] A deployment module for deploying Ethernet OAM for multiple components of a vehicle that require status detection;
[0025] The acquisition module is used to obtain the status information of multiple components of the vehicle and the communication status between the multiple components through Ethernet OAM.
[0026] In the third aspect, an embodiment of the present application provides a vehicle status detection device, which includes a processor, a memory, and a vehicle status detection program stored in the memory and executable by the processor, wherein when the vehicle status detection program is executed by the processor, the steps of the vehicle status detection method described above are implemented.
[0027] In a fourth aspect, an embodiment of the present application provides a readable storage medium, on which a vehicle status detection program is stored, wherein when the vehicle status detection program is executed by a processor, the steps of the vehicle status detection method as described above are implemented.
[0028] The beneficial effects brought by the technical solution provided in the embodiments of the present application include:
[0029] In the embodiment of the present application, Ethernet OAM is deployed for multiple components of the vehicle that need to be checked for status; the status information of multiple components of the vehicle and the communication status between multiple components are obtained through Ethernet OAM. Through the embodiment of the present application, multiple components of the vehicle deployed with Ethernet OAM can be connected to each other, and the status information of multiple components of the vehicle and the communication status between multiple components can be quickly obtained through the Ethernet OAM mechanism. Compared with vehicles using CAN communication, it has higher status and fault detection efficiency, which is of great significance for improving the safety and reliability of the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS
[0030] Figure 1 This is a flow chart of an embodiment of a vehicle status detection method of the present application;
[0031] Figure 2 For this application Figure 1 A detailed flow chart of step S10;
[0032] Figure 3 Another flowchart of an embodiment of the vehicle status detection method of the present application;
[0033] Figure 4 This is a functional module diagram of an embodiment of a vehicle state detection device of the present application;
[0034] Figure 5 This is a schematic diagram of the hardware structure of the vehicle status detection device involved in the embodiment of the present application. DETAILED DESCRIPTION
[0035] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution 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 creative work are within the scope of protection of this application.
[0036] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.
[0037] In a first aspect, an embodiment of the present application provides a vehicle status detection method.
[0038] In one embodiment, referring to Figure 1 , Figure 1 This is a flow chart of an embodiment of a vehicle status detection method of the present application. Figure 1 As shown, the vehicle state detection method includes:
[0039] Step S10: deploy Ethernet OAM for multiple components of the vehicle that require status detection.
[0040] In this embodiment, the multiple components of the vehicle refer to the software and hardware with independent functions in the entire vehicle system, including but not limited to the engine, transmission, suspension, braking system and air-conditioning system. In order to ensure the safety and reliability of the vehicle, it is necessary to timely detect the functional status of each component of the vehicle and the communication status between each component. OAM (Operation Administration and Maintenance), Ethernet OAM is the operation management and maintenance for Ethernet. Ethernet OAM is a tool for monitoring network faults. Its main functions include: link performance monitoring: monitoring various performance of the link, including measurement of packet loss, delay and jitter, as well as statistics of various types of traffic; fault detection and alarm: detecting the connectivity of the link by sending detection messages, and notifying the network administrator in time when a link fails; loop test: detecting link failures by looping back non-Ethernet OAM protocol messages. In this embodiment, Ethernet OAM is deployed for multiple components of the vehicle that need to perform status detection. The chips of the corresponding vehicle components need to support the relevant protocols for deploying Ethernet OAM. The protocols mainly include the Y.1731 protocol of the ITU-T organization and the 802.1ag protocol of the IEEE organization. If multiple components of the vehicle need to support Ethernet OAM and CAN communication at the same time, the chips of the corresponding vehicle components need to support the Y.1731 protocol, the 802.1ag protocol and the CAN communication protocol at the same time. Among them, 802.1ag is a standard proposed by IEEE for error management in Carrier Ethernet networks, also known as Connectivity Fault Management (CFM), which provides five functions such as path discovery, fault detection, fault confirmation and location, fault notification and fault recovery. Y.1731 is an OAM protocol proposed by the ITU-T standards organization. It not only includes the content specified by IEEE 802.1ag, but also adds more OAM message combinations, including AIS (Alarm Indication Signal), RDI (Remote Defect Indication), LCK (Locked Signal), test signal, APS (Automatic Protection Switching), MCC (Maintenance Communication Channel), EXP (Experimental OAM), vendor-specific VSP (Vendor Specific OAM) fault management, and packet loss management and delay evaluation for performance monitoring.
[0041] Step S20, obtaining status information of multiple components of the vehicle and communication status between the multiple components through Ethernet OAM.
[0042] In this embodiment, the status information of multiple components of the vehicle and the communication status between multiple components are obtained based on Ethernet OAM, for example, the status information of the component is obtained through the status flag bit carried in the message sent by each component, and the link status between multiple components is determined through the continuity detection function and loopback function of Ethernet OAM. Compared with vehicles using CAN communication, vehicles using Ethernet OAM can flexibly adopt various Ethernet network architectures to establish communication connections between various components of the vehicle. Through the mechanism of Ethernet OAM, the status information of multiple components of the vehicle and the communication status between multiple components can be quickly obtained. Compared with vehicles using CAN communication, it has higher status and fault detection efficiency, which is of great significance for improving the safety and reliability of the vehicle.
[0043] In this embodiment, Ethernet OAM is deployed for multiple components of the vehicle that need to be state-detected. The chip of the corresponding vehicle component needs to support the relevant protocols for deploying Ethernet OAM. The protocols mainly include the Y.1731 protocol of the ITU-T organization and the 802.1ag protocol of the IEEE organization. If multiple components of the vehicle need to support Ethernet OAM and CAN communication at the same time, the chip of the corresponding vehicle component needs to support the Y.1731 protocol, the 802.1ag protocol and the CAN communication protocol at the same time. For example, the status information of the component is obtained through the status flag bit carried in the message sent by each component, and the link status between multiple components is determined by the continuity detection function and loopback function of Ethernet OAM. Compared with vehicles using CAN communication, vehicles using Ethernet OAM can flexibly adopt various Ethernet network architectures to establish communication connections between various components of the vehicle. Through the mechanism of Ethernet OAM, the status information of multiple components of the vehicle and the communication status between multiple components can be quickly obtained. Compared with vehicles using CAN communication, it has higher status and fault detection efficiency, which is of great significance for improving the safety and reliability of the vehicle.
[0044] Further, in one embodiment, referring to Figure 2 , Figure 2 For this application Figure 1 The detailed flow chart of step S10 is as follows: Figure 2 As shown, step S10 includes:
[0045] Step S101, deploying Ethernet OAM communication protocols for multiple components of a vehicle that need to be checked for status;
[0046] Step S102, creating a maintenance domain for multiple components of the vehicle that need to be checked for status;
[0047] Step S103, configuring a maintenance set for the maintenance domain;
[0048] Step S104, configuring maintenance endpoints for the maintenance set, wherein each vehicle component corresponds to a maintenance endpoint.
[0049] In this embodiment, Ethernet OAM communication protocols are deployed for multiple components of the vehicle that need to be state-detected, and the protocols mainly include the Y.1731 protocol of the ITU-T organization and the 802.1ag protocol of the IEEE organization. In this embodiment, the Ethernet OAM mechanism can be implemented based on CFD (Connectivity Fault Detection). CFD follows the CFM (Connectivity Fault Management) protocol of IEEE802.1ag and the Y.1731 protocol of ITU-T. It is an end-to-end OAM mechanism for a layer 2 network, which is mainly used to detect link connectivity in a layer 2 network, and to confirm and locate faults when faults occur. Applicable layer 2 networks include Ethernet networks based on VLAN (Virtual Local Area Network) and layer 2 VPN (Virtual Private Network) networks based on MPLS (Multi-Protocol Label Switching). Specifically, a maintenance domain MD (Maintenance Domain) is created for multiple components of the vehicle that need to be checked for status. The maintenance domain MD refers to a network or a part of a network covered by connectivity error detection, and is identified by the "MD name". Then, a maintenance association MA (Maintenance Association) is configured for the maintenance domain MD. The maintenance association MA is a part of the maintenance domain MD. A maintenance domain MD can be divided into one or more maintenance association MAs, which are identified by "MD name + MA name". In an Ethernet network, a maintenance association MA can serve a specified VLAN or not serve any VLAN, which are respectively called maintenance association MAs with VLAN attributes and maintenance association MAs without VLAN attributes. In a Layer 2 VPN network, a maintenance association MA can only serve a specified cross-connection or virtual switching instance.Then configure the maintenance association End Point (MEP) for the MA. The MEP belongs to the maintenance point (MP). The maintenance point MP is configured on the interface and belongs to a maintenance association MA. The maintenance point MP also includes the maintenance intermediate point (MIP). The MEP determines the boundary of the MA. The maintenance endpoint MEP is identified by the "ID". In the Ethernet network, the maintenance set MA to which the maintenance endpoint MEP belongs determines the VLAN to which the message sent by the maintenance endpoint MEP belongs. In the Layer 2 VPN network, the maintenance set MA to which the maintenance endpoint MEP belongs determines the cross-connection or virtual switching instance to which the message sent by the maintenance endpoint MEP belongs. The maintenance endpoint MEP has directionality and is divided into two types: inward MEP and outward MEP: the inward MEP will not send CFD protocol messages through the interface where it is located. In the Ethernet network, the inward MEP broadcasts CFD protocol messages through all other interfaces in the VLAN served by the MA to which it belongs. In the Layer 2 VPN network, the inward MEP broadcasts CFD protocol messages through all other interfaces in the cross-connection or virtual switching instance to which it belongs, and the outward MEP directly sends CFD protocol messages outward through the interface where it is located. The maintenance intermediate point MIP is located inside the maintenance set MA and cannot actively send CFD protocol messages, but can process and respond to CFD protocol messages. The maintenance intermediate point MIP is automatically created by the device and can cooperate with MEP to complete functions similar to ping (Packet Internet Groper) and tracert (route tracking). The maintenance set MA to which the maintenance intermediate point MIP belongs determines the VLAN to which the message that the maintenance intermediate point MIP can receive belongs. The maintenance intermediate point MIP configuration is only effective in the Ethernet network and not in the Layer 2 VPN network. The maintenance endpoint MEP list is a collection of local MEPs that are allowed to be configured and remote MEPs that need to be monitored in the same maintenance set MA. It limits the selection range of the maintenance endpoint MEP in the maintenance set MA. All maintenance endpoint MEPs in the same maintenance set MA on different devices should be included in this list, and the MEP IDs are not repeated. If the maintenance endpoint MEP receives a CCM (Continuity Check Message) message from a remote device and the MEP carried by the message is not in the MEP list of the same MA, the message is discarded. Among them, when configuring the communication of each maintenance endpoint MEP, the physical address of the device is configured to represent the corresponding vehicle component, so that each vehicle component corresponds to a maintenance endpoint.
[0050] Furthermore, in one embodiment, step S20 includes:
[0051] The connectivity status between the maintenance endpoints is detected by sending continuity detection messages between the maintenance endpoints to determine the communication status between the vehicle components corresponding to the maintenance endpoints.
[0052] In this embodiment, the connectivity failure between the maintenance endpoint MEPs may be caused by equipment failure or configuration error. The continuity check (CC) function is used to detect the connectivity status between the maintenance endpoint MEPs. The implementation of this function is as follows: the maintenance endpoint MEP periodically sends CCM messages, and other maintenance endpoint MEPs in the same maintenance set MA receive the messages and thereby learn the remote status. If the maintenance endpoint MEP does not receive the CCM message sent by the remote MEP within 3.5 CCM message sending cycles, it is considered that there is a problem with the link and a log report will be output. When multiple maintenance endpoint MEPs in the maintenance domain MD send CCM messages, multi-point to multi-point link detection is implemented, where the CCM message is a multicast message. Since each vehicle component corresponds to a maintenance endpoint, the connectivity status between the maintenance endpoints is detected by sending continuity check messages between the maintenance endpoints, so that the communication status between the vehicle components corresponding to the maintenance endpoints can be determined.
[0053] Furthermore, in one embodiment, step S20 further includes:
[0054] The source maintenance endpoint sends a loopback message to the target maintenance endpoint to detect the link status between the source maintenance endpoint and the target maintenance endpoint, so as to determine the communication status between the vehicle components respectively corresponding to the source maintenance endpoint and the target maintenance endpoint.
[0055] In this embodiment, the loopback (LB) function of Ethernet OAM is similar to the ping function of the IP (Internet Protocol) layer, which is used to verify the connection status between the source maintenance endpoint MEP and the target maintenance endpoint MP. The implementation method of this function is: the source maintenance endpoint MEP sends an LBM (Loopback Message) message to the target maintenance endpoint MP, and checks the link status based on whether the LBR (Loopback Reply) message fed back by the other end can be received. The LBM message is divided into two types of messages: multicast and unicast. The device supports sending and processing unicast LBM messages, but does not support sending but can process multicast LBM messages. LBR is a unicast message. Therefore, the source maintenance endpoint sends a loopback message to the target maintenance endpoint to detect the link status between the source maintenance endpoint and the target maintenance endpoint, so as to determine the communication status between the vehicle components corresponding to the source maintenance endpoint and the target maintenance endpoint.
[0056] Furthermore, in one embodiment, step S20 further includes:
[0057] The status information of the vehicle component corresponding to the maintenance endpoint is obtained through the status flag bit carried in the message sent by each maintenance endpoint.
[0058] In this embodiment, during the Ethernet OAM communication process of each maintenance endpoint, each maintenance endpoint may carry a status flag in the message sent, where the status flag is used to indicate the current functional status of the maintenance endpoint, such as whether the current functional status is normal or abnormal or is in a certain type of fault. Since each vehicle component corresponds to a maintenance endpoint, the status information of the vehicle component corresponding to the maintenance endpoint can be determined by parsing the status flag carried in the message.
[0059] Further, in one embodiment, referring to Figure 3 , Figure 3 Another flow chart of an embodiment of the vehicle status detection method of the present application is as follows: Figure 3 As shown, after step S20, the following steps are included:
[0060] Step S30, displaying status information of multiple components on a vehicle instrument panel.
[0061] In this embodiment, the status information of multiple components is displayed on the vehicle instrument panel, so that the driver can understand and grasp the safety status of the vehicle in real time.
[0062] Furthermore, in one embodiment, the vehicle state detection method further includes:
[0063] Enable or disable the Ethernet OAM function according to the received instructions.
[0064] In this embodiment, the Ethernet OAM function is turned on or off according to the received instructions, which means that the Ethernet OAM function can be turned on or off according to the instructions, where the instructions can come from the driver and the network administrator, and can be sent to the Ethernet OAM in the form of a command line. After receiving the instructions, the Ethernet OAM controls the turning on or off of its own functions.
[0065] In a second aspect, an embodiment of the present application also provides a vehicle status detection device.
[0066] In one embodiment, referring to Figure 4 , Figure 4 This is a functional module diagram of an embodiment of a vehicle status detection device of the present application, such as Figure 4 As shown, the vehicle state detection device includes:
[0067] A deployment module 10, for deploying Ethernet OAM for a plurality of components of a vehicle that require status detection;
[0068] The acquisition module 20 is used to acquire status information of multiple components of the vehicle and the communication status between the multiple components through Ethernet OAM.
[0069] Furthermore, in one embodiment, the deployment module 10 is used to:
[0070] Deploy Ethernet OAM communication protocols for multiple components of the vehicle that require status detection;
[0071] Create maintenance domains for multiple vehicle components that require condition monitoring;
[0072] Configure maintenance sets for maintenance domains;
[0073] Configure maintenance endpoints for a maintenance set, one for each vehicle component.
[0074] Furthermore, in one embodiment, the acquisition module 20 is used to:
[0075] The connectivity status between the maintenance endpoints is detected by sending continuity detection messages between the maintenance endpoints to determine the communication status between the vehicle components corresponding to the maintenance endpoints.
[0076] Furthermore, in one embodiment, the acquisition module 20 is further configured to:
[0077] The source maintenance endpoint sends a loopback message to the target maintenance endpoint to detect the link status between the source maintenance endpoint and the target maintenance endpoint, so as to determine the communication status between the vehicle components respectively corresponding to the source maintenance endpoint and the target maintenance endpoint.
[0078] Furthermore, in one embodiment, the acquisition module 20 is further configured to:
[0079] The status information of the vehicle component corresponding to the maintenance endpoint is obtained through the status flag bit carried in the message sent by each maintenance endpoint.
[0080] Furthermore, in one embodiment, the vehicle state detection device further includes a display module, which is used to:
[0081] Displays status information of multiple components to the vehicle instruments.
[0082] Furthermore, in one embodiment, the vehicle state detection device further includes a control module, which is used to:
[0083] Enable or disable the Ethernet OAM function according to the received instructions.
[0084] Among them, the functional implementation of each module in the above-mentioned vehicle state detection device corresponds to the various steps in the above-mentioned vehicle state detection method embodiment, and its functions and implementation processes are no longer repeated here one by one.
[0085] In a third aspect, an embodiment of the present application provides a vehicle status detection device.
[0086] Reference Figure 5 , Figure 5 Schematic diagram of the hardware structure of the vehicle state detection device involved in the embodiment of the present application. In the embodiment of the present application, the vehicle state detection device may include a processor, a memory, a communication interface and a communication bus.
[0087] The communication bus may be of any type and is used to interconnect the processor, the memory, and the communication interface.
[0088] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces, which are used to interconnect the devices inside the vehicle state detection device, and interfaces used to interconnect the vehicle state detection device with other devices (such as other computing devices or user devices). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.; the user device can be a display, a keyboard, etc.
[0089] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.
[0090] The processor may be a general-purpose processor, and the general-purpose processor may call the vehicle state detection program stored in the memory and execute the vehicle state detection method provided in the embodiment of the present application. For example, the general-purpose processor may be a central processing unit (CPU). The method executed when the vehicle state detection program is called may refer to the various embodiments of the vehicle state detection method of the present application, and will not be repeated here.
[0091] Those skilled in the art will understand that Figure 5 The hardware structure shown in the figure does not constitute a limitation on the present application, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.
[0092] In a fourth aspect, an embodiment of the present application also provides a readable storage medium.
[0093] A vehicle status detection program is stored on the readable storage medium of the present application, wherein when the vehicle status detection program is executed by the processor, the steps of the vehicle status detection method as described above are implemented.
[0094] Among them, the method implemented when the vehicle status detection program is executed can refer to the various embodiments of the vehicle status detection method of the present application, and will not be repeated here.
[0095] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.
[0096] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit "first", "second" and "third" to different types.
[0097] In the description of the embodiments of the present application, "exemplary", "for example" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary", "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.
[0098] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; the “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.
[0099] In some processes described in the embodiments of the present application, multiple operations or steps that appear in a specific order are included, but it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of the present application or in parallel, and the sequence number of the operation is only used to distinguish the different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.
[0100] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.
[0101] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.
Claims
1. A vehicle state detection method, characterized in that: The vehicle state detection method comprises: Deploy Ethernet OAM for multiple components of the vehicle that require status monitoring; The status information of multiple components of the vehicle and the communication status between multiple components are obtained through Ethernet OAM.
2. The vehicle state detection method according to claim 1, characterized in that: The deployment of Ethernet OAM for multiple components of a vehicle requiring status detection includes: Deploy Ethernet OAM communication protocols for multiple components of the vehicle that require status detection; Create maintenance domains for multiple vehicle components that require condition monitoring; Configure maintenance sets for maintenance domains; Configure maintenance endpoints for a maintenance set, one for each vehicle component.
3. The vehicle state detection method according to claim 2, characterized in that: The obtaining of status information of multiple components of the vehicle and communication status between multiple components through Ethernet OAM includes: The connectivity status between the maintenance endpoints is detected by sending continuity detection messages between the maintenance endpoints to determine the communication status between the vehicle components corresponding to the maintenance endpoints.
4. The vehicle state detection method according to claim 2, characterized in that: The obtaining of status information of multiple components of the vehicle and communication status between multiple components through Ethernet OAM also includes: The source maintenance endpoint sends a loopback message to the target maintenance endpoint to detect the link status between the source maintenance endpoint and the target maintenance endpoint, so as to determine the communication status between the vehicle components respectively corresponding to the source maintenance endpoint and the target maintenance endpoint.
5. The vehicle state detection method according to claim 2, characterized in that: The obtaining of status information of multiple components of the vehicle and communication status between multiple components through Ethernet OAM also includes: The status information of the vehicle component corresponding to the maintenance endpoint is obtained through the status flag bit carried in the message sent by each maintenance endpoint.
6. The vehicle state detection method according to claim 1, characterized in that: After obtaining the status information of the multiple components of the vehicle and the communication status between the multiple components through the Ethernet OAM, the method includes: Displays status information of multiple components to the vehicle instruments.
7. The vehicle state detection method according to claim 1, characterized in that: The vehicle state detection method further includes: Enable or disable the Ethernet OAM function according to the received instructions.
8. A vehicle state detection device, characterized in that: The vehicle state detection device comprises: A deployment module for deploying Ethernet OAM for multiple components of a vehicle that require status detection; The acquisition module is used to obtain the status information of multiple components of the vehicle and the communication status between the multiple components through Ethernet OAM.
9. A vehicle status detection device, characterized in that: The vehicle state detection device includes a processor, a memory, and a vehicle state detection program stored in the memory and executable by the processor, wherein when the vehicle state detection program is executed by the processor, the steps of the vehicle state detection method as described in any one of claims 1 to 7 are implemented.
10. A readable storage medium, characterized in that: The readable storage medium stores a vehicle state detection program, wherein when the vehicle state detection program is executed by a processor, the steps of the vehicle state detection method according to any one of claims 1 to 7 are implemented.