CN111600765A - Communication fault recording method and gateway controller - Google Patents
Communication fault recording method and gateway controller Download PDFInfo
- Publication number
- CN111600765A CN111600765A CN202010523929.8A CN202010523929A CN111600765A CN 111600765 A CN111600765 A CN 111600765A CN 202010523929 A CN202010523929 A CN 202010523929A CN 111600765 A CN111600765 A CN 111600765A
- Authority
- CN
- China
- Prior art keywords
- processing step
- message
- target
- target processing
- key event
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000006854 communication Effects 0.000 title claims abstract description 77
- 238000004891 communication Methods 0.000 title claims abstract description 75
- 238000000034 method Methods 0.000 title claims abstract description 28
- 238000012545 processing Methods 0.000 claims abstract description 257
- 230000006870 function Effects 0.000 description 9
- 230000001960 triggered effect Effects 0.000 description 9
- 230000008569 process Effects 0.000 description 7
- 230000005856 abnormality Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40208—Bus networks characterized by the use of a particular bus standard
- H04L2012/40215—Controller Area Network CAN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40267—Bus for use in transportation systems
- H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Small-Scale Networks (AREA)
Abstract
The embodiment of the invention provides a communication fault recording method and a gateway controller, wherein the method comprises the following steps of based on the message processing logic of a preset key event: processing steps, operation sequence of each processing step, and message characteristics (message identification and network segment) related to each processing step. The method comprises the following steps: the gateway controller judges whether the target processing step of the key event is successfully executed; if the target processing step fails to be executed, determining that the key event generates a communication fault, and recording a fault record corresponding to the communication fault; if the target processing step is successfully executed, judging whether the target processing step is the last processing step according to the message processing logic; if yes, determining the first step of processing in the message processing logic as a target processing step; if not, executing the next processing step of the target processing step, determining the next processing step as the target processing step, and returning to the step of judging whether the target processing step of the key event is executed successfully and the subsequent steps.
Description
Technical Field
The invention relates to the field of automotive electronics, in particular to a communication fault recording method and a gateway controller.
Background
A plurality of controllers are installed in the automobile, and different controllers are connected through a bus to establish a whole automobile network. The gateway controller divides the whole vehicle network into a plurality of network segments, each network segment is composed of a variable number of ECUs (also called nodes), the network segments are physically isolated from each other, and a message is routed from one network segment to another network segment by using a routing function so as to realize information interconnection.
Each ECU including the gateway controller can judge whether a communication fault occurs according to the state of the received bus message, when the fault occurs, a corresponding fault code can be recorded, whether the fault exists in the whole vehicle can be analyzed according to the fault code, and the controller causes the abnormality of the whole vehicle.
The definition of the communication fault generally includes that if some messages are not received by a receiving node after a certain time, the receiving node records that the messages are overtime, and when a plurality of messages belonging to one sending node are overtime and are not received, the receiving node records that the sending node works abnormally, a gateway is used as a core node for data forwarding, and the recorded main faults are all communication faults of the type.
However, the above fault recording strategy is only applicable to nodes that periodically send and receive messages, and cannot cover the entire vehicle scenario, because most of the messages in the vehicle are triggered by events, for example, a vehicle user operates the sending node to send the messages, and then forwards the messages to a target receiving node through a gateway, and the target receiving node executes operations after receiving the messages, or performs responses to some information. The communication process at least relates to 3 controllers, namely a sending node, a gateway controller and a receiving node, the abnormality of the time can be generated when any one controller fails, and the message triggered by the event cannot predict the time of the occurrence in advance and cannot be monitored by the receiving node to judge whether the time is overtime or not.
Disclosure of Invention
In view of this, embodiments of the present invention provide a communication fault recording method and a gateway controller to locate a fault occurrence location.
In order to achieve the above purpose, the embodiments of the present invention provide the following technical solutions:
a communication fault recording method is based on a preset message processing logic of a key event, wherein the message processing logic of the key event comprises the following steps: processing steps, operation sequence of each processing step, message characteristics of the message related to each processing step, wherein the message characteristics at least comprise: message identification and the network segment where the message identification is located;
the method comprises the following steps:
the gateway controller judges whether the target processing step of the key event is successfully executed; the target processing step includes: in the processing logic of the critical event, the order of operations is at the next processing step after the processing step that was successfully executed;
if the target processing step fails to be executed, determining that the key event generates a communication fault, and recording a fault record corresponding to the communication fault; wherein the fault record at least comprises: the identification of the key event, the operation sequence of the target processing step, the message characteristics, the failure times of the key event and the fault occurrence time; the failure times in the fault record corresponding to the communication fault at the current time are calculated according to the failure times in the fault record corresponding to the communication fault at the last time of the key event;
if the target processing step is successfully executed, judging whether the target processing step is the last processing step according to the message processing logic;
if yes, determining the first step of processing in the message processing logic as a target processing step;
if not, executing the next processing step of the target processing steps, determining the next processing step as the target processing step, and returning to the step of judging whether the target processing step of the key event is successfully executed and the subsequent steps.
Optionally, when the target processing step is a message receiving step, the determining whether the target processing step of the key event is executed successfully includes: receiving a message; matching the message characteristics of the received message with the message characteristics of the target processing step; if the matching is successful, judging that the target processing step is successfully executed; if the matching fails, judging whether the vehicle stops working or not; if yes, judging that the target processing step fails to be executed; if not, returning to the step of receiving the message and the subsequent steps.
Optionally, when the target processing step is a packet forwarding step, the determining whether the target processing step of the key event is successfully executed includes: after the message related to the key event is forwarded to the CAN bus, whether the forwarding is successful is judged according to the notification of the callback function at the bottom layer; if the forwarding is successful, the target processing step is represented to be successfully executed, otherwise, the target processing step is failed to be executed.
Optionally, the failure times in the failure record corresponding to the last communication failure are target failure times; the recording of the fault record corresponding to the communication fault comprises the following steps: judging whether the target failure times are smaller than a preset maximum failure time or not; if so, performing incremental processing on the target failure times to serve as failure times corresponding to the communication failure; and if not, setting the failure times corresponding to the communication fault at the time to be 1.
Optionally, the packet feature further includes a source node and a target node.
A gateway controller, based on the preset message processing logic of the key event, the message processing logic of the key event includes: processing steps, operation sequence of each processing step, message characteristics of the message related to each processing step, wherein the message characteristics at least comprise: message identification and the network segment where the message identification is located;
the gateway controller includes:
the judging unit is used for judging whether the target processing step of the key event is successfully executed or not; the target processing step includes: in the processing logic of the critical event, the order of operations is at the next processing step after the processing step that was successfully executed;
an execution unit to:
if the target processing step fails to be executed, determining that the key event generates a communication fault, and recording a fault record corresponding to the communication fault; wherein the fault record at least comprises: the identification of the key event, the operation sequence of the target processing step, the message characteristics, the failure times of the key event and the fault occurrence time; the failure times in the fault record corresponding to the communication fault at the current time are calculated according to the failure times in the fault record corresponding to the communication fault at the last time of the key event;
if the target processing step is successfully executed, judging whether the target processing step is the last processing step according to the message processing logic;
if yes, determining the first step of processing in the message processing logic as a target processing step;
if not, executing the next processing step of the target processing steps, determining the next processing step as the target processing step, and executing the step of judging whether the target processing step of the key event is successfully executed by the judging unit.
Optionally, when the target processing step is a message receiving step, in the aspect of determining whether the target processing step of the key event is successfully executed, the executing unit is specifically configured to: receiving a message; matching the message characteristics of the received message with the message characteristics of the target processing step; if the matching is successful, judging that the target processing step is successfully executed; if the matching fails, judging whether the vehicle stops working or not; if yes, judging that the target processing step fails to be executed; if not, returning to the step of receiving the message and the subsequent steps.
Optionally, when the target processing step is a packet forwarding step, in the aspect of determining whether the target processing step of the key event is successfully executed, the executing unit is specifically configured to: after the message related to the key event is forwarded to the CAN bus, whether the forwarding is successful is judged according to the notification of the callback function at the bottom layer; if the forwarding is successful, the target processing step is represented to be successfully executed, otherwise, the target processing step is failed to be executed.
Optionally, the failure times in the failure record corresponding to the last communication failure are target failure times; in the aspect of recording the fault record corresponding to the communication fault, the determining unit is specifically configured to: judging whether the target failure times are smaller than a preset maximum failure time or not; if so, performing incremental processing on the target failure times to serve as failure times corresponding to the communication failure; and if not, setting the failure times corresponding to the communication fault at the time to be 1.
Optionally, the packet feature further includes a source node and a target node.
Therefore, in the embodiment of the present invention, the gateway controller may determine whether the target processing step of the key event is successfully executed, and if the execution fails, the failure record may be updated. The message characteristics in the fault records include message identifiers and network segments where the message identifiers are located. Because the sending node and the receiving node are positioned in different network segments, the sending node, the gateway controller or the receiving node can be determined to have faults according to the network segments, the operation sequence and the message processing logic of the key events, and therefore the fault occurrence position can be positioned.
Drawings
Fig. 1 is a schematic diagram of a vehicle network according to an embodiment of the present invention;
FIG. 2 is a schematic diagram illustrating the processing steps involved in key events provided by an embodiment of the present invention;
fig. 3 is an exemplary flowchart of a communication fault recording method according to an embodiment of the present invention;
FIG. 4 is an exemplary data structure for a fault record provided by embodiments of the present invention;
fig. 5 is another exemplary flow of a communication fault recording method according to an embodiment of the present invention;
fig. 6 is an exemplary structure of a gateway controller according to an embodiment of the present invention.
Detailed Description
A plurality of controllers are installed in the automobile, and different controllers are connected through a bus (CAN represents the bus) to establish a whole automobile network. Referring to fig. 1, the gateway controller divides the entire vehicle network into a plurality of network segments, such as CAN1-CAN5, and the network segments are physically isolated from each other. And routing a message from one network segment to another network segment by using a routing function so as to realize data interaction among different controllers.
Most messages in the vehicle are triggered by events, for example, a sending node is triggered to send a message due to operation of a vehicle user, and then the message is forwarded to a target receiving node through a gateway, and the target receiving node executes operation after receiving the message or responds to certain information.
The message triggered by the operation of the vehicle user usually appears once after one operation, if an abnormality occurs at a certain time, the operation is unsuccessful, for example, the whole vehicle starts related functions, the nodes on the vehicle body CAN bus and the nodes on the power CAN bus are required to be matched and verified, if the communication is abnormal in the process, the whole vehicle cannot be started, and the user cannot use the vehicle.
The communication process at least involves 3 controllers, namely a sending node, a gateway controller and a receiving node, any one controller is possible to generate the abnormality when a fault occurs, and the message triggered by the event cannot predict the occurrence time in advance and cannot be monitored by the receiving node.
However, the gateway controller is only responsible for forwarding messages and is not responsible for recording the logical relationship between a certain frame of message and subsequent messages, so that great troubles are brought to the problem troubleshooting and positioning reasons, particularly for the gateway controller, the gateway controller is used as a controller which is most easily disassembled on a vehicle, if a communication fault occurs, the gateway controller is often judged as a responsible party of the fault, and a large amount of time and resources are consumed to reproduce the problem or prove the gateway controller is normal.
In order to solve the above problem, embodiments of the present invention provide a communication fault recording method and a gateway controller, so as to locate a fault occurrence location.
The core idea of the embodiment of the invention is as follows: based on the physical connection advantages of the gateway controller (capable of receiving and forwarding the messages of all CAN network segments), the key events which are easy to send faults are counted and sorted, the message processing logic related to the key events is synchronized to the gateway controller, the gateway controller CAN record the faults according to the message processing logic, and the fault record CAN judge whether the position where the faults occur is at a sending node, a gateway or a receiving node, so that the problem position CAN be quickly positioned.
The statistically consolidated key events are customized by the car factory or the developer of the controller.
In one example, the critical event may include an event that must be triggered during vehicle start or operation, including but not limited to at least one of keyless start, vehicle ignition, security check.
The message processing logic of any key event comprises: processing steps, operation sequence of each processing step, and message characteristics of messages related to each processing step. Wherein, the message characteristics at least include: message identification and the network segment where the message is located.
For example, referring to fig. 2, it is assumed that a certain key event involves 4 processing steps (i-iv), the first step is to send a sending node (source node) to a gateway controller (gateway for short), a network segment in the message characteristics is a network segment a where the sending node is located, and the message identifier is assumed to be 00001; step 2, the network controller forwards the message to a receiving node (target node), wherein the network segment in the message characteristics is the network segment B where the target node is located, and the message identifier is still assumed to be 00001; step 3, replying a message by the target node, wherein the network segment in the message characteristic is the network segment B where the target node is located, and the message identifier is assumed to be 00010; and step 4, forwarding a reply message to the source node by the gateway controller, wherein the network segment in the message characteristic is the network segment A where the original node is located, and the message identifier is supposed to be 00010.
Fig. 3 shows an exemplary flow of a communication failure logging method performed by a gateway controller, based on critical event based message processing logic, comprising:
s1: and the whole vehicle is awakened, and the gateway controller enters a working state.
S2: the gateway controller determines whether the target processing step of the key event is successfully executed, if so, the process proceeds to step S3, and if not, the process proceeds to step S4.
The target processing step includes: in the processing logic of the critical event, the order of operations is at the next processing step after the processing step that was successfully executed.
The target processing step may be a receiving step or a forwarding step. Taking the above-mentioned fig. 2 as an example, when the working state is started, the processing step (i) is the target processing step. After the processing step (i) is successfully executed, the processing step (ii) becomes a target processing step. If the processing step (c) is successfully executed, the step (c) becomes the target processing step, and so on, which is not described in detail.
S3: determining that the critical event generates a communication failure, updating a failure record of the critical event, and proceeding to S5.
In one example, the fault record includes at least: the identification of the key event, the operation sequence of the target processing step, the message characteristics, the failure times of the key event and the failure occurrence time.
The message characteristics may include the identity of the message and the network segment in which it is located. In other examples, the message characteristics may also include a source node and a target node.
According to the message ID and the network segment where the message is located, the message can be distinguished to be the message sent to the gateway controller by the source node or the message returned to the gateway controller by the target node.
Fig. 4 shows an exemplary data structure of a fault record, occupying 6 bytes and 48 bits.
Table 1 below is a data description of the data structure shown in fig. 4.
TABLE 1
Every time a communication fault occurs in a critical event, a fault record is recorded.
Considering that the storage space is not infinite, the maximum number of failures can be set for the same critical event. The person skilled in the art has the flexibility to set the maximum number of failures, for example to 7.
Therefore, 42 bytes can be allocated to the same key event according to the maximum failure times of the same key event, and the minimum data storage space owned by the current gateway products is generally larger than 1 Kbyte and is enough to carry fault records of various key events.
More specifically, the failure times in the failure record corresponding to the current communication failure are calculated according to the failure times (which may be referred to as target failure times) in the failure record corresponding to the last communication failure of the critical event.
In one example, the number of failures in the current communication failure record may be recorded by:
judging whether the target failure times are smaller than the maximum failure times;
if so, performing incremental processing on the target failure times to serve as failure times corresponding to the communication failure; and if not, setting the failure times corresponding to the communication fault at the time to be 1.
Taking the maximum failure frequency as 7 as an example, if the failure frequency in the last communication failure record of the key event a is 5 and is less than 7, the failure frequency in the current communication failure record of the key event a is 6 (increment by 1); on the contrary, if the failure frequency in the last communication failure record of the key event a is 7, the failure frequency in the current communication failure record of the key event a is 1, and the failure record with the last failure frequency of 1 is covered.
It should be noted that, taking an automobile ignition event as an example, when the automobile ignition event is executed, the fault record may be initialized first, and specifically includes:
assigning a value to the critical event (e.g., taking table 1 as an example, the ignition event corresponds to 000, and the critical event in the fault record is recorded as 000);
let the operation order equal to 1 (at initialization, let the operation order equal to 1, since it always starts from the first step of processing from the beginning);
let the operation result be 0 (according to the description of table 1, use "0" to identify unsuccessful or unexecuted, so let the operation result be equal to 0 at initialization);
assigning values to the source node and the target node;
let time equal the current time.
And then, the fault records can be updated along with the execution of the processing steps, and the fault records are saved after the fact that a certain processing step is not successfully executed is confirmed.
For example, the step 1 processing step (generally, receiving a message) is successfully executed, and the corresponding operation result is updated to "1".
And then, executing the step 2 processing step (generally, forwarding), changing the operation sequence of the fault record into 2, updating the operation result into "0", updating the time into the current time, and if the step is not executed successfully, updating the failure times and storing the failure times (because the forwarding does not change the source node and the target node, the source node and the target node are not required to be updated).
S4: and determining that the target processing step is successfully executed, judging whether the target processing step is the last processing step according to the message processing logic, if so, entering step S5, and if not, entering step S6.
S5: determining the first step processing step in the message processing logic as a target processing step, and returning to S2;
or, it goes back to the step of performing the initial fault logging.
S6: the next processing step is determined as the target processing step, and the flow returns to S2.
For example, assuming that the target processing step is the 3 rd processing step, which is successfully executed, but is not the last processing step (there is also the fourth processing step), the 4 th processing step (which is determined as the target processing step) is executed, the fault log operation order is changed to 4, the operation result is updated to "0", and the time is updated to the current time.
Therefore, in the embodiment of the present invention, the gateway controller may determine whether the target processing step of the key event is successfully executed, and if the execution fails, the failure record may be updated. The message characteristics in the fault records include message identifiers and network segments where the message identifiers are located. Because the sending node and the receiving node are positioned in different network segments, the sending node, the gateway controller or the receiving node can be determined to have faults according to the network segments, the operation sequence and the message processing logic of the key events, and therefore the fault occurrence position can be positioned.
The message processing steps involved in critical events, particularly from the perspective of the gateway controller, typically include receiving messages and forwarding.
Therefore, when the target processing step is specifically a message receiving step (which may be referred to as a target receiving step), the step S1 of determining whether the target processing step of the critical event is successfully executed may include:
step A: receiving a message;
and B: matching the message characteristics of the received message with the message characteristics of the target receiving step;
in addition to messages triggered by critical events, periodic messages are transmitted on the CAN bus, and therefore, the received message characteristics need to be matched with the message characteristics of the target receiving step.
And C: if the matching is successful, judging that the target receiving step is successfully executed;
if the matching is successful, the message which is received by the target receiving step is successfully received, so that the receiving step is successful.
Step D: if the matching fails, judging whether the vehicle stops working, if so, entering a step E, otherwise, returning to the step A;
step E: and if so, judging that the target receiving step fails to be executed.
If the vehicle stops working and does not receive the matched message, the message is not received all the time, and the target receiving step can be judged to be failed to execute.
It should be noted that the first processing step involved in the critical event is generally to receive a message. The foregoing mentions that the key events may be defined as including: events that must be triggered during vehicle start-up or operation. If the vehicle stops working, the message which should be received in the first step of processing is not received all the time, and the execution failure of the key event can be judged.
When the target processing step is a message forwarding step (which may be referred to as a target forwarding step), the step S1 of determining whether the target processing step of the critical event is successfully executed may include:
step F: after the message related to the key event is forwarded to the CAN bus, whether the forwarding is successful is judged according to the notification of the callback function at the bottom layer;
and if the forwarding is successful, the representation target forwarding step is successfully executed, otherwise, the target forwarding step is failed to be executed.
After the message is forwarded, the callback function at the bottom layer informs whether the message is successfully sent, and according to the notice, the target forwarding step can be known whether the message is successfully executed.
In the following, the communication fault recording method is described in more detail with respect to one critical event, and it should be noted that if a plurality of critical events are defined, the communication fault recording of different critical events can be performed with reference to the present flow. Please refer to fig. 5, which may include the following steps:
s501: the whole vehicle is awakened by the user, and the gateway controller enters a working state.
S502: the gateway controller initializes the corresponding fault record of the key event after the awakening.
Note that the initialization here is not to initialize the stored failure record. Instead, for the current start, an initial fault record is established for each key event to prepare for subsequent recording.
Taking the automobile ignition event as an example, assuming that 4 fault records are stored before the start, the 4 fault records are not initialized, and only one fault record is newly created.
Wherein the initialization operation may include:
assigning values to the key events (for example, taking table 1 as an example, the ignition event corresponds to 000, and 3 bit positions corresponding to the "key event" in the fault record corresponding to the current start are recorded as 000);
let the operation order equal to 1 (at initialization, let the operation order equal to 1, since it always starts from the first step of processing from the beginning);
let the operation result be 0 (according to the description of table 1, use "0" to identify unsuccessful or unexecuted, so let the operation result be equal to 0 at initialization);
assigning values to the source node and the target node;
making the time equal to the current time;
and judging whether the communication fault is the first work, if so, setting the failure times to be 0, otherwise, making the failure times equal to the failure times in the fault record corresponding to the last communication fault.
Other flag bits are arranged in the gateway controller to indicate whether the gateway controller is powered on for the first time.
In other embodiments of the present invention, the failure times may also be directly equal to the failure times in the fault record corresponding to the last communication fault, and if the power-on operation is performed for the first time, the failure times in the fault record corresponding to the last communication fault are defaulted to be 0.
S503: judging whether the message related to the target receiving step is received, if so, entering a step S504, otherwise, entering a step S505;
since the first processing step is to receive the message, after the initialization is completed, it is determined whether the message related to the key event is received.
Taking the operation order of 1 as an example, the receiving step corresponding to the operation order of 1 will be the target receiving step.
Specifically, with the operation order being 1, the message characteristics of the received message may be matched with the message characteristics of the target receiving step, if matching is successful, it is determined that the target receiving step is successfully executed, and if matching is failed, S505 may be entered;
s504: and determining that the target receiving step is successfully executed, modifying the fault record and entering the step S510.
For example, the step 1 processing step (generally, receiving a message) is successfully executed, and the corresponding operation result is updated to "1".
S505: judging whether the vehicle stops working, if so, entering S506, otherwise, returning to S503;
s506: judging whether the current failure times are smaller than the maximum failure times, if so, entering S507, and if not, entering S508;
if the vehicle stops working and does not receive the matched message, the message is not received all the time, and the target receiving step can be judged to be failed to execute.
S507: the number of failures is incremented and the process proceeds to S509.
S508: the number of failures is set to 1, and the process proceeds to S509.
Of course, the operation may be terminated as it is when the vehicle stops operating.
It should be noted that, since the operation result defaults to 0, the operation result does not need to be modified here.
S509: the failure record is stored, and the process returns to S502.
S505-S509 are the detailed refinement flow of the aforementioned step S3.
S510: the next processing step is determined as the target forwarding (processing) step and the fault record is modified.
The next processing step is the 2 nd processing step (generally, forwarding), the operation order of the fault record may be changed to 2, the operation result is updated to "0", and the time is updated to the current time.
S511: judging whether the target forwarding step is successfully executed, if so, entering step S512, otherwise, entering step S506;
after the message is forwarded, the callback function at the bottom layer informs whether the message is successfully sent, and according to the notice, the target forwarding step can be known whether the message is successfully executed.
S512: and determining that the target forwarding step is successfully executed, and modifying the fault record.
For example, the target forwarding step is the step 2 processing step, the execution of which is successful, and the corresponding operation result is updated to "1".
S513: and judging whether the target forwarding step is the last step according to the message processing logic, if so, returning to the S502, and otherwise, entering the S514.
S514: the next processing step is determined as the target transmission step, the fault record is modified, and the process returns to S503.
Let the operation order equal to 1 (at initialization, let the operation order equal to 1, since it always starts from the first step of processing from the beginning);
let the operation result be 0 (according to the description of table 1, use "0" to identify unsuccessful or unexecuted, so let the operation result be equal to 0 at initialization);
assigning values to the source node and the target node;
let time equal the current time.
It should be noted that, taking the forwarding step of step 2 as an example, if the maximum execution step is not reached after the step 2 is executed, the gateway controller needs to wait for the reply message of the target node, if the reply message is successfully received, it is identified that the processing step of step 3 is successfully executed, the gateway controller needs to perform the forwarding operation (the processing step of step 4), if the transmission is successful, it is characterized that the processing step of step 4 is successfully executed, at this time, it is determined whether the maximum execution step is reached again, if the maximum execution step is reached, the initialization is returned, otherwise, the execution is continued.
Because the gateway is required to transmit once in each operation, the operation times corresponding to the last step of processing step is a double number, if the source node has not sent the message or the target node has not replied the message, the gateway is in a state of waiting all the time, and the failure is recorded when the whole vehicle stops working.
Fig. 6 illustrates an exemplary architecture of a gateway controller, which may include:
the judging unit 1 is used for judging whether the target processing step of the key event is successfully executed.
Wherein the target processing step comprises: in the processing logic of the critical event, the order of operations is at the next processing step after the processing step that was successfully executed.
The message processing logic of the key event comprises the following steps: processing steps, operation sequence of each processing step, message characteristics of the message related to each processing step, wherein the message characteristics at least comprise: message identification and the network segment where the message is located.
Optionally, the packet feature further includes a source node and a target node.
An execution unit 2 for: and if the target processing step fails to be executed, determining that the key event generates a communication fault, and recording a fault record corresponding to the communication fault.
Wherein the fault record at least comprises: the identification of the key event, the operation sequence of the target processing step, the message characteristics, the failure times of the key event and the fault occurrence time; the failure times in the fault record corresponding to the communication fault at the current time are calculated according to the failure times in the fault record corresponding to the communication fault at the last time of the key event;
if the target processing step is successfully executed, judging whether the target processing step is the last processing step according to the message processing logic;
if yes, determining the first step of processing in the message processing logic as a target processing step;
if not, executing the next processing step of the target processing steps, determining the next processing step as the target processing step, and executing the step of judging whether the target processing step of the key event is successfully executed by the judging unit.
For related matters, please refer to the above description, which is not repeated herein.
In another embodiment of the present invention, when the target processing step is a message receiving step, in terms of determining whether the target processing step of the key event is successfully executed, the executing unit 2 in all the embodiments is specifically configured to:
receiving a message;
matching the message characteristics of the received message with the message characteristics of the target processing step;
if the matching is successful, judging that the target processing step is successfully executed;
if the matching fails, judging whether the vehicle stops working or not;
if yes, judging that the target processing step fails to be executed;
if not, returning to the step of receiving the message and the subsequent steps.
For related matters, please refer to the above description, which is not repeated herein.
In other embodiments of the present invention, when the target processing step is a packet forwarding step, in terms of determining whether the target processing step of the key event is successfully executed, the execution unit 2 in all the embodiments is specifically configured to:
after the message related to the key event is forwarded to the CAN bus, whether the forwarding is successful is judged according to the notification of the callback function at the bottom layer; if the forwarding is successful, the target processing step is represented to be successfully executed, otherwise, the target processing step is failed to be executed.
For related matters, please refer to the above description, which is not repeated herein.
In other embodiments of the present invention, the failure times in the failure record corresponding to the last communication failure are target failure times; in the aspect of recording the fault record corresponding to the communication fault, the determining unit 1 in all the embodiments is specifically configured to: judging whether the target failure times are smaller than a preset maximum failure time or not; if so, performing incremental processing on the target failure times to serve as failure times corresponding to the communication failure; and if not, setting the failure times corresponding to the communication fault at the time to be 1.
For related matters, please refer to the above description, which is not repeated herein.
Those of skill would further appreciate that the various illustrative components and model steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The steps of a method or model described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, WD-ROM, or any other form of storage medium known in the art.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. A communication fault recording method is characterized in that based on a preset message processing logic of a key event, the message processing logic of the key event comprises the following steps: processing steps, operation sequence of each processing step, message characteristics of the message related to each processing step, wherein the message characteristics at least comprise: message identification and the network segment where the message identification is located;
the method comprises the following steps:
the gateway controller judges whether the target processing step of the key event is successfully executed; the target processing step includes: in the message processing logic of the key event, the operation sequence is positioned in the next processing step after the successfully executed processing step;
if the target processing step fails to be executed, determining that the key event generates a communication fault, and recording a fault record corresponding to the communication fault; wherein the fault record at least comprises: the identification of the key event, the operation sequence of the target processing step, the message characteristics, the failure times of the key event and the fault occurrence time; the failure times in the fault record corresponding to the communication fault at the current time are calculated according to the failure times in the fault record corresponding to the communication fault at the last time of the key event;
if the target processing step is successfully executed, judging whether the target processing step is the last processing step according to the message processing logic;
if yes, determining the first step of processing in the message processing logic as a target processing step;
if not, executing the next processing step of the target processing steps, determining the next processing step as the target processing step, and returning to the step of judging whether the target processing step of the key event is successfully executed and the subsequent steps.
2. The method of claim 1,
when the target processing step is a message receiving step, the determining whether the target processing step of the key event is successfully executed includes:
receiving a message;
matching the message characteristics of the received message with the message characteristics of the target processing step;
if the matching is successful, judging that the target processing step is successfully executed;
if the matching fails, judging whether the vehicle stops working or not;
if yes, judging that the target processing step fails to be executed;
if not, returning to the step of receiving the message and the subsequent steps.
3. The method of claim 1,
when the target processing step is a message forwarding step, the determining whether the target processing step of the key event is successfully executed includes:
after the message related to the key event is forwarded to the CAN bus, whether the forwarding is successful is judged according to the notification of the callback function at the bottom layer;
if the forwarding is successful, the target processing step is represented to be successfully executed, otherwise, the target processing step is failed to be executed.
4. The method according to any one of claims 1 to 3,
the failure times in the fault record corresponding to the last communication fault are target failure times;
the recording of the fault record corresponding to the communication fault comprises the following steps:
judging whether the target failure times are smaller than a preset maximum failure time or not;
if so, performing incremental processing on the target failure times to serve as failure times corresponding to the communication failure; and if not, setting the failure times corresponding to the communication fault at the time to be 1.
5. The method of claim 1, wherein the message characteristics further comprise a source node and a destination node.
6. A gateway controller is characterized in that based on a preset message processing logic of a key event, the message processing logic of the key event comprises: processing steps, operation sequence of each processing step, message characteristics of the message related to each processing step, wherein the message characteristics at least comprise: message identification and the network segment where the message identification is located;
the gateway controller includes:
the judging unit is used for judging whether the target processing step of the key event is successfully executed or not; the target processing step includes: in the message processing logic of the key event, the operation sequence is positioned in the next processing step after the successfully executed processing step;
an execution unit to:
if the target processing step fails to be executed, determining that the key event generates a communication fault, and recording a fault record corresponding to the communication fault; wherein the fault record at least comprises: the identification of the key event, the operation sequence of the target processing step, the message characteristics, the failure times of the key event and the fault occurrence time; the failure times in the fault record corresponding to the communication fault at the current time are calculated according to the failure times in the fault record corresponding to the communication fault at the last time of the key event;
if the target processing step is successfully executed, judging whether the target processing step is the last processing step according to the message processing logic;
if yes, determining the first step of processing in the message processing logic as a target processing step;
if not, executing the next processing step of the target processing steps, determining the next processing step as the target processing step, and executing the step of judging whether the target processing step of the key event is successfully executed by the judging unit.
7. The gateway controller of claim 6,
when the target processing step is a message receiving step, in the aspect of determining whether the target processing step of the key event is successfully executed, the execution unit is specifically configured to:
receiving a message;
matching the message characteristics of the received message with the message characteristics of the target processing step;
if the matching is successful, judging that the target processing step is successfully executed;
if the matching fails, judging whether the vehicle stops working or not;
if yes, judging that the target processing step fails to be executed;
if not, returning to the step of receiving the message and the subsequent steps.
8. The gateway controller of claim 6,
when the target processing step is a packet forwarding step, in the aspect of determining whether the target processing step of the key event is successfully executed, the execution unit is specifically configured to:
after the message related to the key event is forwarded to the CAN bus, whether the forwarding is successful is judged according to the notification of the callback function at the bottom layer;
if the forwarding is successful, the target processing step is represented to be successfully executed, otherwise, the target processing step is failed to be executed.
9. The gateway controller of any one of claims 6-8,
the failure times in the fault record corresponding to the last communication fault are target failure times;
in the aspect of recording the fault record corresponding to the communication fault, the determining unit is specifically configured to:
judging whether the target failure times are smaller than a preset maximum failure time or not;
if so, performing incremental processing on the target failure times to serve as failure times corresponding to the communication failure; and if not, setting the failure times corresponding to the communication fault at the time to be 1.
10. The gateway controller of claim 6, wherein the message characteristics further comprise a source node and a destination node.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010523929.8A CN111600765B (en) | 2020-06-10 | 2020-06-10 | Communication fault recording method and gateway controller |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010523929.8A CN111600765B (en) | 2020-06-10 | 2020-06-10 | Communication fault recording method and gateway controller |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111600765A true CN111600765A (en) | 2020-08-28 |
| CN111600765B CN111600765B (en) | 2022-08-19 |
Family
ID=72190081
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010523929.8A Active CN111600765B (en) | 2020-06-10 | 2020-06-10 | Communication fault recording method and gateway controller |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111600765B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112445201A (en) * | 2020-11-19 | 2021-03-05 | 东风汽车集团有限公司 | Remote troubleshooting and fault positioning method and device |
| CN113485291A (en) * | 2021-06-29 | 2021-10-08 | 东风汽车集团股份有限公司 | Method for monitoring communication fault of CAN bus node by vehicle-mounted gateway and gateway equipment |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104914849A (en) * | 2015-05-12 | 2015-09-16 | 安徽江淮汽车股份有限公司 | Fault recording device and method |
| WO2017203902A1 (en) * | 2016-05-27 | 2017-11-30 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | Gateway device, in-vehicle network system, transfer method, and program |
| CN109164795A (en) * | 2018-11-23 | 2019-01-08 | 安徽江淮汽车集团股份有限公司 | A kind of intelligent automobile fault diagnosis method and system |
| CN110177032A (en) * | 2019-07-08 | 2019-08-27 | 北京经纬恒润科技有限公司 | Message routing quality monitoring method and gateway controller |
| CN110278103A (en) * | 2018-03-16 | 2019-09-24 | 长城汽车股份有限公司 | Fault detection method, system and the vehicle of vehicle |
-
2020
- 2020-06-10 CN CN202010523929.8A patent/CN111600765B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104914849A (en) * | 2015-05-12 | 2015-09-16 | 安徽江淮汽车股份有限公司 | Fault recording device and method |
| WO2017203902A1 (en) * | 2016-05-27 | 2017-11-30 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | Gateway device, in-vehicle network system, transfer method, and program |
| CN110278103A (en) * | 2018-03-16 | 2019-09-24 | 长城汽车股份有限公司 | Fault detection method, system and the vehicle of vehicle |
| CN109164795A (en) * | 2018-11-23 | 2019-01-08 | 安徽江淮汽车集团股份有限公司 | A kind of intelligent automobile fault diagnosis method and system |
| CN110177032A (en) * | 2019-07-08 | 2019-08-27 | 北京经纬恒润科技有限公司 | Message routing quality monitoring method and gateway controller |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112445201A (en) * | 2020-11-19 | 2021-03-05 | 东风汽车集团有限公司 | Remote troubleshooting and fault positioning method and device |
| CN113485291A (en) * | 2021-06-29 | 2021-10-08 | 东风汽车集团股份有限公司 | Method for monitoring communication fault of CAN bus node by vehicle-mounted gateway and gateway equipment |
| CN113485291B (en) * | 2021-06-29 | 2022-11-18 | 东风汽车集团股份有限公司 | Method for monitoring communication fault of CAN bus node by vehicle-mounted gateway and gateway equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111600765B (en) | 2022-08-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111600765B (en) | Communication fault recording method and gateway controller | |
| US8165013B2 (en) | Networked computer with gateway selection | |
| US7499987B2 (en) | Deterministically electing an active node | |
| EP2104274B1 (en) | Method, system, dm client and dm server for installing software component | |
| CN109194521B (en) | Flow forwarding method and equipment | |
| CN108846085B (en) | ID generation method, device, electronic equipment and system | |
| CN112437155B (en) | Service data processing method and device and server device | |
| JP5802829B2 (en) | Method, node, and system for determining fault indication state | |
| JP4411344B2 (en) | A method for recognizing incompatibility in a bus system with multiple control devices | |
| JP3744537B2 (en) | Backup method for device setting | |
| CN111131198B (en) | Updating method and device for network security policy configuration | |
| CN115002195A (en) | Service registration discovery method, system and medium in self-adaptive peer-to-peer mode | |
| CN112770277B (en) | Forwarding number verification method and device, mobile terminal and computing equipment | |
| CN109428752B (en) | Verification method and device | |
| CN112860449A (en) | Method, system, equipment and medium for preventing restart caused by message overtime | |
| JP4851994B2 (en) | Operation monitoring device, operation monitoring method, and operation monitoring program | |
| KR100274848B1 (en) | Network management method for network management system | |
| CN111541719B (en) | Authentication method and device and information processing equipment | |
| CN115150031B (en) | Distributed system message response method and device based on distributed message | |
| CN107295540B (en) | Network element configuration method and device | |
| CN112422502A (en) | Method, device, computer equipment and storage medium for retransmitting data | |
| CN112600738B (en) | Method and device for verifying connectivity of network port | |
| KR102060774B1 (en) | System and method of handling troubles of electronic device | |
| CN112054961B (en) | Data transmission system, method and device | |
| JP4231810B2 (en) | Groupware server and groupware server program |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 4 / F, building 1, No.14 Jiuxianqiao Road, Chaoyang District, Beijing 100020 Applicant after: Beijing Jingwei Hirain Technologies Co.,Inc. Address before: 8 / F, block B, No. 11, Anxiang Beili, Chaoyang District, Beijing 100101 Applicant before: Beijing Jingwei HiRain Technologies Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |