KR101135117B1 - METHOD AND APPARATUS OF COMPENSATING DELAY OF MESSAGE TRANSMISSION USING PROCESS PRIORITY ADJUSTMENT IN heterogeneous COMMUNICATION - Google Patents

Abstract

The present invention discloses a method and apparatus for compensating for delay by adjusting the priority of a process in heterogeneous protocol communication.
In the heterogeneous protocol communication according to an embodiment of the present invention, a method for compensating delay by adjusting a priority of a process may be performed by exchanging a message between nodes using heterogeneous protocols, from a first node using a first protocol. Receiving the first message and storing the message reception time, providing the first message and the message reception time to a message dispatcher in charge of sending a message to a second node of a second protocol, and the message dispatcher And transmitting the first message according to a priority, wherein the priority is calculated according to a message transmission delay of a node to be processed by the message dispatcher.

Description

METHOD AND APPARATUS OF COMPENSATING DELAY OF MESSAGE TRANSMISSION USING PROCESS PRIORITY ADJUSTMENT IN heterogeneous COMMUNICATION}

The present invention discloses a method and apparatus for compensating for delay by adjusting the priority of a process in heterogeneous protocol communication.

In modern vehicles, various electronic devices such as microprocessors, sensors, and actuators are used, and they require reliable information exchange between each other for safe driving and driver's convenience.

The most widely used in-vehicle communication is the Control Area Network (CAN), which can transmit data at data rates up to 1 Mbps. However, due to the limitations of event-triggered communication methods and relatively low data rates, they are not suitable for applications requiring high reliability and safety, such as x-by-wire systems. As an alternative, FlexRay has been developed, which has the property of deterministic communication and allows periodic data exchange with little jitter. FlexRay is designed to provide the flexibility of applying TDMA and event-based communication methods that provide determinism by time-triggered. However, in case of a time delay in the process of transmitting data, FlexRay operates due to time synchronization, and the receiving side receives the delayed data, and this delay may affect the transmission of other data. have.

'In-vehicle networks' faced a growing number of network domains, increased complexity in inter-domain communications and resulting transmission delays. In particular, 'Gateway function' is required for communication between heterogeneous domains (CAN, LIN, CAN, FlexRay, etc.). In providing this gateway function, reliable data transfer can be completed in a timely manner. It is necessary to ensure communication.

The present invention is to propose a technique for adjusting the priority of the process of controlling the message transmission to solve the delay in the process of transmitting and receiving messages in FlexRay communication.

The present invention intends to quantitatively measure the transmission delay in the gateway, and to propose a method that can overcome this when the transmission delay time exceeds the allowable limit of the system.

In particular, the present invention controls the processing priority of the message dispatcher that controls message transmission for the delay occurring in the CAN-FlexRay heterogeneous message transmission, thereby quantifying the complex transmission delay so as not to change the priority of the message itself. This can be compensated for, and when applied to the in-vehicle gateway, the reliability of the in-vehicle network can be maximized.

In order to achieve the above object, a method of compensating delay by adjusting a priority of a process in heterogeneous protocol communication according to an embodiment of the present invention may include a first method of exchanging messages between nodes using heterogeneous protocols. Receiving a first message from a first node using a protocol and storing the message reception time; providing the first message and the message reception time to a message dispatcher in charge of sending a message to a second node of a second protocol And the message dispatcher transmits the first message according to a priority, wherein the priority is calculated according to a message transmission delay of a node to be processed by the message dispatcher.

An apparatus for compensating for delay by adjusting a priority of a process in heterogeneous protocol communication according to an embodiment of the present invention may be used to exchange messages between nodes using heterogeneous protocols. A first controller for controlling the second, a second controller for controlling the transmission and reception of messages using a second protocol, receives a first message from the first node using the first protocol to store the message reception time, message A task scheduler for selecting a dispatcher, and a message dispatcher for storing the first message in a memory buffer controlled by the second controller, wherein the message dispatcher transmits the first message according to a priority and the priority. Is the message transmission destination of the node that will be processed by the message dispatcher. It characterized in that the calculation according to occur.

The present invention can quantitatively measure the transmission delay in the gateway to prevent delays in message transmission and to flexibly adapt to changes in the message flow of the entire network. In particular, the present invention adjusts the priority of a process in charge of message transmission, thereby effectively responding to message delay.

1 is a diagram illustrating a structure of a CAN-FlexRay gateway to which an embodiment of the present specification is applied.
2 is a view showing a general structure of a gateway referred to herein.
3 is a diagram illustrating a software or functional structure of a gateway according to one embodiment of the present specification.
4 is a diagram illustrating a configuration of a gateway and a message transfer process performed in each configuration according to an embodiment of the present specification.
FIG. 5 is a diagram illustrating a process of processing a message delay occurring while a CAN message is transmitted to a FlexRay node according to one embodiment of the present specification.

Hereinafter, some embodiments of the present invention will be described in detail with reference to the accompanying drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are assigned to the same components as much as possible even though they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In addition, in describing the component of this invention, terms, such as 1st, 2nd, A, B, (a), (b), can be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. If a component is described as being "connected", "coupled" or "connected" to another component, that component may be directly connected or connected to that other component, but between components It will be understood that may be "connected", "coupled" or "connected".

Proposed methods for exchanging messages between CAN and FlexRay buses include matching the ID of the CAN message with the FlexRay slot or converting the message. On the other hand, we can propose a mapping table for exchanging messages between CAN and FlexRay buses, and apply filtering techniques and message queues for storing messages. However, with this approach, transmission delays can occur during message delivery within gateways located between different (heterogeneous) buses, such as CAN and FlexRay. In particular, if a message transmitted from a node on one bus does not quantitatively measure the transmission delay added to the time to reach a node connected to the other bus, the transmission delay exceeds the allowable limit of the entire network system. As a result, the efficiency of the network can be drastically reduced. Hereinafter, a method and apparatus for measuring a transmission delay in a gateway to prevent a decrease in network efficiency due to the transmission delay will be described.

In addition, the present specification will quantitatively measure the transmission delay in the gateway, and look at the process and apparatus that can overcome this when the transmission delay time exceeds the allowable limit of the system.

1 is a diagram illustrating a structure of a CAN-FlexRay gateway to which an embodiment of the present specification is applied. The CAN-FlexRay gateway 150 of FIG. 1 is connected to a plurality of CAN buses (1, ..., N) and one or more FlexRay buses. Multiple CAN buses (1, ..., N) carry a number of messages received from multiple CAN nodes (111, 112, 113, 114), and many CAN messages simultaneously delivered are delayed and the FlexRay bus May be delivered. In other words, since there are a large number of CAN buses, messages can be sent at the same time, but the gateway function cannot process them at the same time, so when the CAN nodes 111, 112, 113, and 114 all generate and transmit messages, FlexRay nodes It may be delayed and transmitted to (121, 122, 123, 124).

2 is a view showing a general structure of a gateway referred to herein.

The CAN-FlexRay gateway 200 is generally connected to a plurality of CAN buses 221 and 229 and one or more FlexRay buses 231. Under this configuration, a situation where a large number of CAN messages may be delivered to a gateway through a plurality of CAN buses, and in extreme cases, it is required to deliver a large number of CAN messages that are delivered almost simultaneously to the FlexRay bus with minimal transmission delay. Can be.

Each CAN bus connected to the gateway is assigned a 'CAN Message Receive Queue' to temporarily store CAN messages received through it. CAN message transmission queue 'is assigned. The two queues will be referred to collectively as the 'CAN message queue'. The FlexRay message buffer 235 is used to temporarily store data when transmitting and receiving FlexRay data, and a plurality of message buffers are used in advance for transmission and reception. In FIG. 2, only message A, which is the data of the message 'c_A' of the CAN bus 1 in the CAN message receiving queue, is received. This is stored in the FlexRay buffer 235 as A, it can be seen that is converted to 'F_A' in the FlexRay bus 231 is included in the frame and transmitted. Message exchange between these heterogeneous buses is achieved by controlling each CAN controller 220 and FlexRay controller 230 in the main CPU core 210.

Although the method proposed in this specification is applicable to various bus connection situations, it will be described assuming a general situation as shown in FIG.

3 is a diagram illustrating a software or functional structure of a gateway according to one embodiment of the present specification.

When the CAN controller 320 receives the message A through the CAN bus 321, it generates an interrupt and extracts data (referred to as payload) from the CAN message through an interrupt service routine (ISR). To be stored in the CAN message reception queue 325. When the new data is stored in the CAN message receiving queue 325, an interrupt is generated, and the interrupt service routine calls the job scheduler (Job Scheduler, Job Manager, 350) and hands over control. Alternatively, the periodic task operated by the main CPU core 210 illustrated in FIG. 2 may periodically check the CAN bus 321 through the CAN controller 320 and confirm receipt of a message. The task confirms that the data is extracted from the CAN message and stored in the CAN message receiving queue, and then the job scheduler 350 is called to transfer control.

On the contrary, when data transmitted from the FlexRay side is stored in the CAN message transmission queue 328, an interrupt occurs, and the interrupt service routine causes the CAN controller 320 to transmit a message stored in the queue 328 to the CAN bus 321. Will be sent via). Alternatively, the periodic task operated by the main CPU core 210 illustrated in FIG. 2 may periodically check the CAN message transmission queue 328 and check the arrival of the message. In this case, the periodic task may include the CAN controller 320. You will be asked to send the messages stored in the queue over the CAN bus.

Among the functions of the gateway provided by one embodiment of the present specification, the message dispatcher (351, 355) is responsible for transferring data between the CAN message queue and the FlexRay message buffer as a message dispatcher (351, 355). This is a task. The message dispatcher sends and receives data by referring to a look-up table (LUT) 340 in which the relationship between the ID of the CAN message, the address of the CAN message queue, the address of the FlexRay message buffer, and the number of the FlexRay slot is defined. You can pinpoint directions and destinations. Since a plurality of messages are delivered to various buses in the gateway, a plurality of message dispatchers 351 and 355 may be driven. These tasks are prioritized by the job scheduler 350 and the execution order is determined. The job scheduler 350 is entitled to adjust the priority of the interrupt service routine or periodic task in addition to the message dispatchers 351 and 355.

When the data on the CAN bus side is stored in the FlexRay message buffer 335 through the message dispatchers 351 and 355 of the gateway, an interrupt is generated. In the service routine (ISR) for the interrupt, the FlexRay controller 330 causes the message buffer. The data stored in 335 is requested to be transmitted through the FlexRay bus 331. In addition, the periodic task operated by the main CPU core 210 described in FIG. 2 may periodically check the FlexRay message buffer 335 through the FlexRay controller 330 and check the arrival of the message. Requests the FlexRay controller 330 to send a message stored in the message buffer through the FlexRay bus 331.

Conversely, FlexRay controller 330 and when it receives a message via the FlexRay bus 331, extracts data (C) in the FlexRay frame (F_ C) through the ISR to generate an interrupt and processes the interrupt occurred FlexRay message buffers Will be stored in. When data is stored in the message buffer, an interrupt is generated, and its interrupt service routine calls the task scheduler and transfers control. Alternatively, the periodic task operated by the main CPU core periodically checks the FlexRay bus through the FlexRay controller and confirms receipt of the message. In this case, the confirmed task extracts data from the FlexRay frame and extracts data from the FlexRay message buffer 335. It will be stored in the job scheduler 350 will be called later to give control.

4 is a diagram illustrating a configuration of a gateway and a message transfer process performed in each configuration according to an embodiment of the present specification.

The overall configuration is added to the structure shown in Figures 2 and 3, the task scheduler (task manager, 450) is added, these task scheduler 450 using the message dispatcher (451, 452, 453, 454) CAN controller and FlexRay It performs the task of exchanging messages between controllers. In addition, when the message is delayed, the task scheduler 450 adjusts the task priority of the message dispatchers 451, 452, 453, and 454 to compensate for the message delay. Looking in more detail as follows. For the convenience of explanation, the flow of messages and tasks is indicated as (S1, S2, ..., S12), and each step will be described as S1, S2, and these flows and order are partially used in applying the invention. The priority may be changed, a new process may be added, or some processes may be omitted. The task scheduler may include a task management function.

The CAN controller 420 generates an interrupt for the message c_A received through the CAN bus 421 (S1). Alternatively, although not shown in the figure instead of the interrupt function, it is possible to check whether a CAN message is received by performing periodic polling by a specific task (receive processing task). After storing the arrival time of the CAN message notified by the corresponding interrupt service routine 429 or the reception processing task, data (A) is extracted from the received message and the identifier information (ID) of the CAN node is stored in the CAN message reception queue 425. After storing it together, it transfers control to the task scheduler (S2). After that, the task scheduler The message dispatcher selects a message dispatcher to transfer the arrival time and the control right using the work management function (S3). That is, the task scheduler 450 allocates and prioritizes a task to the message dispatcher # 1 451 to transmit the corresponding data, and transmits the arrival time of the message to the message dispatcher # 1 451. The message dispatcher # 1 451 receiving the message extracts the message ID of the CAN message receiving queue 425 (S4), and compares the extracted message ID with the reference table (LUT) 440 (S5). The slot number and the address of the FlexRay message buffer 435 associated with the slot number in the corresponding FlexRay cycle are found, and data and arrival time are written in the FlexRay message buffer (S6).

An interrupt may be generated when new data is written to the FlexRay message buffer (S7). Thereafter, an interrupt service routine 439 may be generated to request the FlexRay controller to process the message arrival. In addition, as described above in the CAN message receiving process, it may be confirmed that data has arrived in the message buffer 435 by periodic polling by a specific task. That is, the transfer request is requested to the FlexRay controller in order to transfer the data in the message buffer in the interrupt service routine 439 or a specific task (S8).

The FlexRay controller processes the data (A) in the message stored in the message buffer 435 and the message arrival time (giving the meaning of the timestamp) sent from the CAN bus side into a FlexRay frame (F_A) and inserts it into the corresponding slot. Transmission is performed by using 431 (S9).

The node 480 receiving the message sent from the CAN bus side on the FlexRay bus 431 extracts data and time stamps from the FlexRay frame (S10), and the arrival time and timestamp of the FlexRay frame are received from the receiving FlexRay node 480. The difference is calculated and if the time difference exceeds the allowable threshold, a protest message is transmitted to the gateway (S11). The gateway 400 receiving the protest message from the FlexRay node 480 notifies the task scheduler 450, and the task scheduler 450 evaluates the message delay after receiving the protest message (message priority escalation factor). , The Message Priority Raising Factor (MPRF) It is instructed to raise the task priority by one step to the message dispatcher that will process the outgoing message (S12). Thereafter, the message dispatcher whose task priority is increased is increased (for example, message dispatchers # 1 and 451) in accordance with the instructions of the job scheduler 450, in order to process a message that a specific node of the CAN bus subsequently sends. Work can be done according to the adjusted task priority. As a result, the job scheduler 450 may first process the message dispatcher # 1 451.

On the other hand, the job scheduler 450 repeats the process of S1 ~ S12 and observes the MPRF to see if it is below the allowable limit. If it falls below the allowable limit, the task scheduler 450 fixes the task dispatcher's task priority to the current state. In this case, you can increase the task priority step by step and observe the trend. In addition, according to another embodiment of the present disclosure, when the MPRF is lowered below a certain level, the task priority of the corresponding message dispatcher may be lowered to the initial state.

On the other hand, if the priority of the message dispatcher is maximized, but the MPRF of the message does not fall below the allowable value, the vehicle diagnostic module can be notified of this fact and can store confirmation data that can be modified later. Provide an opportunity.

In FIG. 4, only the message transmission from the CAN bus side to the FlexRay bus side is shown, but a similar function is performed in the message transmission in the reverse direction. In other words, in the reverse direction of message transmission, the task scheduler transmits a message stored in the FlexRay message buffer 435 to the CAN message transmission queues 426 and 428 in controlling the message dispatcher. The MPRF is calculated using the message arrival time recorded by the FlexRay controller 430 or the arrival time when the message is recorded in the FlexRay message buffer 435, and the protest message generated from the CAN nodes. If the transmitted message is delayed beyond the acceptance criteria, the priority of the message dispatcher may be increased to solve this problem.

By the configuration shown in Figure 4, it is possible to quantitatively measure the transmission delay in the gateway, it can be overcome when the transmission delay time exceeds the allowable limit of the system. Fig. 4 illustrates the configuration of the CAN-FlexRay gateway when a message is transferred from the CAN bus to the FlexRay bus, in which transmission delay is a problem. However, this can also be used as the configuration of Figure 4 in the message forwarding process in the reverse direction.

That is, in the configuration of FIG. 4, the job scheduler 450 or the message dispatchers 451, 452, 453, and 454 may transmit a CAN message to the gateway to quantitatively measure the transmission delay occurring during the message conversion and delivery process in the gateway. Keep track of when it arrives, and insert it as a time stamp when sending a FlexRay frame to send. The FlexRay node 480 receiving such a frame compares the timestamp value with the current time to determine whether the frame arrives within an allowable limit. If the allowable limit is exceeded, the node 480 transmits a complaint message to the gateway.

The gateway receiving the protest message gives a higher priority when processing a message transmitted by a node of a CAN bus that transmits a delayed CAN message so that it is processed before other messages. The method of prioritizing a particular message within the gateway can be implemented by giving higher priority to the specific task and interrupt service routine (ISR) that processes the message. That is, as described above, the node of the CAN bus that transmits the delayed CAN message can raise the priority of the message dispatcher to process the message to be transmitted later, so that the operation can be prioritized over other message dispatchers. have.

Although not shown in FIG. 4, in the interrupt service routine, when a message is transmitted from a node of the corresponding CAN bus, the priority of the interrupt may be increased to allow faster processing.

Regarding the transmission of the message, the allowable threshold which is a criterion for checking whether the message transmission is delayed is as follows.

According to the basic function of the gateway, a FlexRay frame containing a timestamp arrives at the destination node, and the destination node compares the timestamp with the current time to calculate the time difference and compares it with the tolerance. The allowable threshold must be determined at the system design stage in advance and has a range as in Equation 1.

[Equation 1]

The allowable threshold must be less than the sum of the delay caused by the gateway (gateway latency) and the FlexRay Cycle cycle (FlexRay Cycle Time), and if exceeded, the protest message is sent to the gateway.

The gateway receiving the protest message notifies the task scheduler 450, and the task scheduler 450 executes the execution of the message dispatcher tasks 451, 452, 453, and 454 and the interrupt service routine 429 which it manages. The Message Priority Raising Factor (MPRF) is calculated to adjust the priority.

The MPRF includes the message priority of the CAN message, which is determined by the ID of the CAN message, and indicates the priority of a task that processes the message. The MPRF is calculated by Equation 2 below.

[Equation 2]

In the above formula, Complaints Counter is the number of protest messages received by the task scheduler. When this is more than one, the MPRF is calculated by adding the priority of CAN messages.

Priority of messages sent from the CAN bus is determined by their own IDs, but if they are delivered delayed by the operation of the gateway, the delay of higher priority messages is higher than that of lower priority messages. This will have a significant impact, and to reflect this, the priority of the CAN message is added to the calculation of the MPRF.

The MPRF threshold must be determined at the system design stage and treated as zero if there is no protest message. The range in which the priority of the message dispatcher tasks 451, 452, 453, 454 and the periodic task and interrupt service routines 429 can be varied must also be determined at the system design stage and is the highest priority without being affected by the MPRF. You must also decide in advance which ISRs and message dispatchers you need to maintain.

Within a gateway, the process of translating messages and moving them between message repositories to deliver multiple messages received on one bus to the other bus is interrupted by multiple message dispatcher tasks 451, 452, 453, and 454. Implemented by the execution of service routines 429 or periodic tasks. These message dispatcher tasks 451, 452, 453, and 454 and the interrupt service routines 429 or periodic tasks are executed in a high order of priority by the priority given by the operating system and the task scheduler 450. Message dispatcher tasks, interrupt service routines, or periodic tasks are executed before other message dispatcher tasks, interrupt service routines, or periodic tasks, resulting in the effect that messages delivered through them are transmitted faster than other messages. From the task scheduler's point of view, the task scheduler runs on the main core CPU and is entitled to change the priority of all message dispatcher tasks, interrupt service routines, or periodic tasks except those controlled solely by the CAN controller or FlexRay controller. This is implemented by requesting a priority change from an operating system running in the processor.

The task scheduler 450 according to an embodiment of the present disclosure may change the priority of a task transmitting a message when a delay occurs in message transmission between CAN and FlexRay, and in this process, may not change the priority of the CAN message itself. Does not. In addition, as shown in FIGS. 2, 3, and 4, when a plurality of CAN buses are connected to a gateway and numerous CAN nodes are connected to each CAN bus, a plurality of CAN messages that follow the priority scheme of each CAN bus are generated. Changing the priority of a task that handles it according to the priority of a CAN message can be violated by the principle that the message that arrives first must be processed first, thus minimizing transmission delay.

Therefore, in the exemplary embodiment of the present specification, the message should be processed first according to the order of arrival of each message, except that a message dispatcher task, an interrupt service routine, or a periodic task that handles a limited amount of messages that arrive excessively delayed. By increasing the priority of, we try to compensate for the delay in message transmission with minimal impact on system operation. That is, the task scheduler allows the interrupt service routine, periodic task, or message dispatcher to run in the order in which the messages are received over the CAN bus by default, but changes the execution priority for CAN nodes that send messages beyond the MPRF threshold. Given. The same behavior occurs for message transfer from the FlexRay bus side to the CAN bus side.

The task scheduler sets the priority of the message dispatcher and interrupt service routine or periodic task to process this for messages sent by the CAN node after the MPRF is sending a message that exceeds the acceptable threshold, one step above other tasks or interrupt service routines. The results will be confirmed by recalculating the MPRF.

The process of increasing the execution priority can be repeated by repeating a) and b) below.

a) increase the priority of the task and calculate the MPRF;

b) If the value of MPRF does not fall below the permissible limit under a), the MPRF is calculated by raising the priority for the associated interrupt and its interrupt service routine.

The ordering of a) and b) is due to the fact that changing the priority of general tasks has less impact on the overall system operation than changing the priority of interrupts and interrupt service routines.

If the priority of the task and interrupt service routine is lowered below the MPRF tolerance limit, the priority is fixed at the current state. Otherwise, the priority is increased repeatedly until it falls below the tolerance limit.

If the MPRF is not improved so that the priority of the task and interrupt service routines reaches the highest priority they can have, the delivery of the message is avoided by passing the message dispatcher to shorten the transmission time.

There have been several data exchanges between CAN message queues and FlexRay message buffers several times in the meantime, so that the message dispatcher can store the address of the other message buffer in advance in a global variable or pointer that can be used by the interrupt service routine, even if the message dispatcher does not intervene. Enable direct data transfer. However, the direct transfer of data by the interrupt service routine is only enabled in these emergency situations and is disabled in everyday situations, allowing for faster interrupt processing. To do this, the task scheduler sets a specific flag (flag, flag) to let the interrupt service routine know that it is an emergency. The interrupt service routine checks that the flag is set and executes the transfer routine accordingly. The order in which the contents described above are executed is as follows.

i) Set a flag to indicate that the task scheduler is in an emergency

ii) an interrupt occurs when a CAN message is received and its data is stored in the message queue by its ISR

iii) An interrupt occurs as a result of ii).

iv) Check the flag in the ISR of the interrupt that occurred in iii).

v) If the flag is set, check the global variable that stores the address of the other side of the message buffer and then transfer the data stored in the message queue directly to the destination message buffer.

vi) an interrupt occurs in the message buffer as a result of v)

vii) The message buffer ISR requests the FlexRay controller to send a frame immediately.

If the MPRF value does not fall below the acceptable limit during the above steps i) to vii), the diagnosis module is notified of such a situation so that the developer can make room for improvement later. Conversely, if the MPRF falls below the allowable threshold, the task is prioritized by one step, the MPRF is measured, and the task is given the lowest priority that the MPRF does not exceed the allowed threshold.

The process of lowering the execution priority ai) first calculates the MPRF by lowering the priority of the ISR, and then a-ii) calculates the MPRF by lowering the priority for the associated message dispatcher when the value of the calculated MPRF becomes less than the allowable limit. do. And this process (ai, a-ii) can be repeated repeatedly. The reason for specifying this order is that changing the priority of interrupts and ISRs has a greater impact on overall system operation than changing the priority of general tasks.

FIG. 5 is a diagram illustrating a process of processing a message delay occurring while a CAN message is transmitted to a FlexRay node according to one embodiment of the present specification. Looking at each process, first, a message is received from the CAN bus, the interrupt is generated by the CAN controller (S502). After extracting data from the CAN message in the interrupt service routine for processing the generated interrupt, the data is stored in the CAN message queue and the message arrival time is stored separately (S510). After saving, the interrupt service routine invokes the job scheduler and returns (S512). The interrupt service routine can then wait to process another interrupt. In order to transmit the received message, the job scheduler allocates a job to a specific message dispatcher and transmits the arrival time (time stamp) of the message (S520). The message dispatcher checks the address of the FlexRay message buffer with reference to the LUT (S522). After checking, the message dispatcher writes data and arrival time in the FlexRay message buffer of the corresponding address (S524). Thereafter, an interrupt is generated in the FlexRay message buffer (S530). The interrupt service routine for processing the generated interrupt requests the FlexRay controller to transmit the data in the buffer (S532). After receiving the request, the FlexRay controller processes the data and arrival time into frames, processes the data and arrival times into frames, and sends them through the intended slots so that the FlexRay node can receive the intended message. (S534). The frame arrival time is compared with the time stamp at the receiving node (S540), and as a result, it is checked whether the time difference is larger or smaller than the allowable limit (S550). If it is less than the allowable limit, the message has not been delayed and the next process proceeds.

On the other hand, if the time difference is greater than the allowable limit, the receiving node transmits a protest message to the gateway (S560). The gateway delivers a protest message to the task scheduler and calculates an MPRF (S562). If the MPRF is larger than the allowable limit (S570), the priority of the message dispatcher is adjusted, and the priority of the dispatcher of the corresponding message is checked (S580). If not, the priority of the message dispatcher is increased (S582). Thereafter, the message dispatcher can process the message faster when the message is received through the node. On the other hand, if the MPRF is less than the allowable limit in S570, the message is delayed, but it is not the level to increase the priority of the dispatcher to proceed to the next process. After that, if the delay accumulates, it may be checked again whether the dispatcher is adjusted upward in step S570. On the other hand, if the message dispatcher ranks best in S580, since it can no longer be adjusted, it notifies the diagnosis module (S590). This is to be applied later when designing the system or changing the system.

Conventionally, in the process of simply exchanging a message between the ID of the CAN message and the FlexRay slot, the transmission delay occurring in the process of delivering a message in a gateway located between heterogeneous buses is not considered. In particular, it does not consider a method of quantitatively measuring the transmission delay added to the time until a message transmitted from a node on one bus reaches a node connected to the other bus. It does not provide countermeasures for cases beyond.

In the method and apparatus for adjusting the priority of a process in heterogeneous protocol communication according to an embodiment of the present disclosure to compensate for the delay, a method and a transmission delay time for quantitatively measuring a transmission delay in a gateway that conventional methods do not consider In case of exceeding the allowable limit of the system, it is suggested how to overcome it. Therefore, if the proposed method is applied to in-vehicle gateway, the reliability of in-vehicle network can be maximized.

The above description is merely illustrative of the technical idea of the present invention, and those skilled in the art to which the present invention pertains may make various modifications and changes without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas falling within the scope of the same shall be construed as falling within the scope of the present invention.

300, 400: CAN-FlexRay Gateway 420: CAN Controller
430: FlexRay Controller

Claims (12)

In exchanging messages between nodes using heterogeneous protocols,
Receiving a first message from a first node using a first protocol and storing the message reception time;
Providing the first message and the message reception time to a message dispatcher responsible for sending a message to a second node of a second protocol; And
The message dispatcher includes transmitting the first message according to priority.
The priority is the execution order of each of the message dispatchers,
And calculating the priority of the process in the heterogeneous protocol communication.
The method of claim 1,
After transmitting the first message,
Receiving a protest message informing of a message transmission delay from the second node; And
And determining whether to adjust the priority of the message dispatcher using the received protest message. The method of claim 1, further comprising adjusting a priority of a process in heterogeneous protocol communication.
The method of claim 1,
After receiving the first message from the first node using the first protocol, notifying the task scheduler of the reception of the first message through an interrupt; And
And assigning, by the task scheduler, the task of sending the first message to the message dispatcher, adjusting the priority of the process in the heterogeneous protocol communication to compensate for the delay.
The method of claim 1,
After receiving the first message from the first node using the first protocol, a process that regularly monitors receipt of the message notifies the task scheduler of the receipt of the first message; And
And assigning, by the task scheduler, the task of sending the first message to the message dispatcher, adjusting the priority of the process in the heterogeneous protocol communication to compensate for the delay.
The method of claim 1,
The first protocol and the second protocol is one of the CAN protocol or FlexRay protocol, the method of compensating delay by adjusting the priority of the process in heterogeneous protocol communication.
The method of claim 1,
The message dispatcher transmitting the first message according to priority;
Storing the first message in a memory buffer used by a second node of the second protocol; And
Informing the controller controlling the second protocol of storing the first message. The method of claim 1, further comprising adjusting a priority of a process in heterogeneous protocol communication.
In exchanging messages between nodes using heterogeneous protocols,
A first controller controlling message transmission and reception of a node using a first protocol;
A second controller controlling message transmission and reception of a node using a second protocol;
A task scheduler that receives a first message from a first node using the first protocol, stores the message reception time, and selects a message dispatcher; And
A message dispatcher for storing the first message in a memory buffer controlled by the second controller,
The message dispatcher transmits the first message according to priority,
The priority is an execution order of each of the message dispatchers, and is calculated according to a message reception delay occurring when the first message is received by a node using the second protocol by the message dispatcher. Device that compensates for delay by adjusting the priority of a process in communication.
8. The method of claim 7,
The task scheduler receives a protest message indicating a message transmission delay from the second node, and then determines whether to adjust the priority of the message dispatcher using the received protest message. Device that compensates for delay by adjusting.
8. The method of claim 7,
An interrupt service routine for processing an interrupt informing a task scheduler of receipt of the first message after receiving a first message from a first node using the first protocol,
And the task scheduler assigns a task to send the first message to the message dispatcher by the interrupt, thereby adjusting the priority of the process in heterogeneous protocol communication to compensate for the delay.
8. The method of claim 7,
It further includes a process for regularly monitoring the reception of messages,
The process informs a job scheduler of the receipt of the first message from a first node using the first protocol,
And the task scheduler assigns a task to send the first message to the message dispatcher to compensate for delay by adjusting the priority of the process in heterogeneous protocol communication.
8. The method of claim 7,
And the first protocol and the second protocol are one of a CAN protocol or a FlexRay protocol.
8. The method of claim 7,
The message dispatcher stores the first message in a memory buffer used by a second node of the second protocol and informs a controller controlling the second protocol of storing the first message. Device that compensates for delays by adjusting the priority of processes in protocol communications.

Images