WO2016017088A1 - ゲートウェイ装置 - Google Patents

ゲートウェイ装置 Download PDF

Info

Publication number
WO2016017088A1
WO2016017088A1 PCT/JP2015/003512 JP2015003512W WO2016017088A1 WO 2016017088 A1 WO2016017088 A1 WO 2016017088A1 JP 2015003512 W JP2015003512 W JP 2015003512W WO 2016017088 A1 WO2016017088 A1 WO 2016017088A1
Authority
WO
WIPO (PCT)
Prior art keywords
frame
response
ecu
diagnostic tool
transmitted
Prior art date
Application number
PCT/JP2015/003512
Other languages
English (en)
French (fr)
Inventor
雄三 原田
充啓 夏目
Original Assignee
株式会社デンソー
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 株式会社デンソー filed Critical 株式会社デンソー
Publication of WO2016017088A1 publication Critical patent/WO2016017088A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]

Definitions

  • This disclosure relates to a gateway device.
  • the vehicle is equipped with a large number of ECUs for controlling the vehicle, and various data are transmitted and received between the ECUs.
  • Some vehicles include a gateway device, and an external device such as a diagnostic tool is connected to the gateway device so as to communicate with each ECU.
  • the communication between the diagnostic tool and the ECU as described above is usually performed by one-to-one communication that individually designates the physical address of the other party. Also, when a frame in which a functional address indicating simultaneous transmission to all ECUs is specified in the address area is transmitted from the diagnostic tool to the gateway device, the gateway device simultaneously transmits this frame to all ECUs. Yes (see, for example, Patent Document 1).
  • the transmission / reception of the frame between the diagnostic tool and the ECU as described above is performed according to the communication specification of CAN diagnostic communication defined in the ISO standard (for example, ISO 15765-2, ISO 15765-4).
  • CAN diagnostic communication data that can be transferred in one frame is limited to a certain number of bytes (for example, 7 bytes). If the data to be transmitted exceeds a certain number of bytes, it is necessary to transmit the frame multiple times. is there.
  • the frame transmission / reception to / from the diagnostic tool ECU is performed as shown in FIG. 12, such as a first frame (FF), a connective frame (CF), and a flow control frame (FC). It is done using.
  • FF first frame
  • CF connective frame
  • FC flow control frame
  • the first frame (FF) is the first frame of the multiframe
  • the connective frame (CF) is the second and subsequent frames of the multiframe.
  • the flow control frame (FC) is a frame for performing flow control such as the number of frames transmitted from the counterpart device and the time interval.
  • the gateway device when the gateway device receives a function address request frame of a single frame (SF) in which a function address indicating simultaneous transmission to all ECUs is designated as an address area from the diagnostic tool, the gateway device transmits the function address request frame to each ECU 30 simultaneously. Send.
  • SF single frame
  • the ECU When the ECU receives this frame, it determines whether or not the response data responding to this frame exceeds a certain number of bytes. If the response data exceeds a certain number of bytes, the first frame (FF) of the response frame is received by the diagnostic tool (reception Send it to
  • the diagnostic tool When the diagnostic tool receives the first frame (FF) of the response frame from the ECU, it transmits a flow control frame (FC) to the ECU (sender), and the number of frames transmitted from the counterpart device, the time interval, etc. Perform flow control.
  • FF first frame
  • FC flow control frame
  • the response frame of the response frame is transmitted from the ECU (transmitter) according to the instruction of the flow control frame (FC).
  • the second and subsequent connective frames (CF) are transmitted.
  • the first frame (FF) of the response frame transmitted from the counterpart device (ECU) can be subjected to flow control such as the number of frames and the time interval. Can not.
  • the gateway device when the gateway device simultaneously transmits a function address request frame to a plurality of ECUs, the data transferable amount between the gateway device and the diagnostic tool is the data transferable amount between the gateway device and each ECU. Therefore, when response frames are transmitted unconditionally from a plurality of ECUs that have received a function address request frame, the gateway device transmits frames transmitted from a large number of ECUs. There is a problem that it is missed and cannot be relayed accurately to the diagnostic tool.
  • the conventional gateway device relays the frame between the diagnostic tool and the ECU, but does not transmit various frames for flow control on behalf of the diagnostic tool. An ECU that cannot receive a frame from the diagnostic tool will time out.
  • One object of the present disclosure has been made in view of the above, and after simultaneously transmitting a frame from a diagnostic tool to each control device, a response frame from each control device can be received and relayed to the diagnostic tool. This is to prevent each control device from timing out.
  • a gateway device when receiving a request frame representing simultaneous transmission to a plurality of control devices from a diagnostic tool, a frame simultaneous transmission unit that simultaneously transmits the request frame to the plurality of control devices, and reception of the request frame
  • a response frame transmitted from a plurality of control devices is received in response to the frame
  • a frame holding unit that holds the received response frame in a holding unit
  • a relay unit that relays the response frame held in the holding unit to a diagnostic tool
  • a standby instruction frame transmission unit that transmits a standby instruction frame for instructing standby so as not to time out to the control apparatus that has transmitted the response frame.
  • a request frame representing simultaneous transmission to a plurality of control devices is received from the diagnostic tool
  • the request frame is simultaneously transmitted to the plurality of control devices, and a plurality of controls are responded to the reception of the request frame.
  • the response frame transmitted from the device is received
  • the received response frame is held in the holding unit, and the response frame held in the holding unit is relayed to the diagnostic tool.
  • the standby instruction frame for instructing standby so as not to time out is transmitted to the control device that has transmitted the response frame, each control device can be prevented from timing out.
  • FIG. 1 is a diagram illustrating a configuration of a gateway device according to an embodiment.
  • FIG. 2 is a diagram for explaining a frame between the diagnostic tool ECU and FIG.
  • FIG. 3 is a diagram for explaining the flow status of the flow control frame.
  • FIG. 4 is a diagram for explaining simultaneous transmission of function request frames and transmission of response frames.
  • FIG. 5 is a flowchart of the gateway device.
  • FIG. 6 is a flowchart of the gateway device.
  • FIG. 7 is a flowchart of the gateway device.
  • FIG. 8 is a flowchart of the gateway device.
  • FIG. 9 is a flowchart of the gateway device.
  • FIG. 10 is a flowchart of the gateway device.
  • FIG. 11 is a diagram showing a flow of a proxy transmission frame for a flow control frame.
  • FIG. 12 is a diagram for explaining frame transmission / reception with the diagnostic tool ECU.
  • FIG. 1 shows the configuration of the gateway device.
  • the gateway device 1 is a central relay that relays frames between a device such as a diagnostic tool 2 connected to the first bus side and a plurality of control devices (hereinafter referred to as ECUs) 30 connected to the second bus side. It is configured as a gateway device (CGW).
  • One bus is prepared on the first bus side, and five buses of 1 to 5 channels (ch) are prepared on the second bus side.
  • Fifteen ECUs 30 can be connected to each of the five buses on the second bus side. That is, the gateway device 1 can relay frames between an external device such as the diagnostic tool 2 connected to the first bus side and a maximum of 75 ECUs 30 connected to each of the five buses. It has become.
  • the gateway device 1 includes a computer having a CPU, RAM, ROM, I / O, and the like.
  • the CPU performs various processes in accordance with programs stored in the ROM.
  • the gateway device 1 also includes a buffer 10 that temporarily holds a response frame from each ECU 30 on the second bus side.
  • the buffer 10 is provided for each CANID assigned to each ECU 30.
  • the gateway apparatus 1 has a buffer 10 having a capacity of one frame for a total of 75 ECUs 30 that can be connected to each of five buses. That is, the gateway device 1 has a buffer 10 having a capacity of 75 frames in total.
  • frame transmission / reception between the diagnostic tool 2 and each ECU 30 is performed in accordance with the communication specification of CAN diagnostic communication defined in ISO standards (for example, ISO 15765-2, ISO 15765-4). Yes.
  • CAN diagnostic communication the data that can be transferred in one frame is limited to a certain number of bytes (for example, 7 bytes). If the data to be transmitted does not exceed a certain number of bytes, transmission is performed in a single frame. When the desired data exceeds a certain number of bytes, transmission is performed in a plurality of frames (multiframe).
  • the frame exchange between the diagnostic tool 2 and the ECU 30 is, as shown in FIG. 2, a single frame (SF), a first frame (FF), and a selective frame (CF ) And a flow control frame (FC).
  • SF single frame
  • FF first frame
  • CF selective frame
  • FC flow control frame
  • Single frame is a frame used when data to be transmitted fits in one frame.
  • the first frame (FF) is the first frame of the multiframe
  • the connective frame (CF) is the second and subsequent frames of the multiframe.
  • the flow control frame (FC) is used when there is a second and subsequent conductive frame (CF).
  • the flow control frame (FC) includes an N_PCI type indicating a frame type, a flow status (FS), a block size (BS), and a separation time (Stmin).
  • N_PCI type indicating a frame type
  • FS flow status
  • BS block size
  • Stmin separation time
  • the block size (BS) is used to inform the sender the maximum number of consecutive frames that can be received.
  • the separation time (Stmin) is used to inform the sender of the frame transmission interval.
  • CTS Create To Send
  • WT Wait
  • OVFLW Overflow
  • CTS Continue To Send
  • WT Wait
  • OVFLW Overflow
  • the gateway device 1 When the gateway device 1 receives a request frame in which the physical address of the specific ECU 30 is set in the address area from the diagnostic tool 2, the gateway device 1 individually relays the request frame to the specific ECU 30.
  • the gateway device 1 when the gateway device 1 receives a functional address request frame in which a functional address indicating simultaneous transmission to all ECUs 30 is specified in the address area from the diagnostic tool 2, the gateway device 1 displays the functional address request frame. It transmits to each ECU30 simultaneously. In this way, by simultaneously transmitting the function address request frame to each ECU 30, it is possible to significantly reduce the time required for frame transmission compared to the case where the request frame is individually relayed to a specific ECU 30. Become.
  • each ECU 30 that has received the functional address request frame from the diagnostic tool 2 transmits a response frame in response to the reception of the functional address request frame to the diagnostic tool 2 at the same time.
  • FIG. 5 shows a flowchart of this process.
  • the gateway device 1 periodically performs the processing shown in the figure.
  • the functional address request frame is a single frame (SF).
  • SF single frame
  • the received functional address request frame is transmitted to all the ECUs 30 (S102), and this process is terminated.
  • Each ECU 30 that has received the functional address request frame transmits a response frame in response to the received functional address request frame to the diagnostic tool 2. Therefore, response frames are intensively input to the gateway device 1 from each ECU 30 that has received the function address request frame.
  • the gateway device 1 When the gateway device 1 receives a response frame from each ECU 30 that has received the functional address request frame, the gateway device 1 performs a process of writing the received response frame in the buffer 10.
  • Fig. 6 shows this flowchart.
  • the gateway device 1 periodically performs the process shown in FIG. 6 in parallel with the process shown in FIG.
  • a response frame is received from the ECU 30 (S200).
  • the determination in S200 is NO, and this process is terminated.
  • first frames (FF) of response frames are transmitted intensively from each ECU 30 that has received the function address request frame.
  • the determination in S200 is YES, and the received response frames are sequentially changed.
  • Such processing is repeatedly performed, and the first frame (FF) of the response frame that is input in a concentrated manner from each ECU 30 that has received the function address request frame is held in the buffer 10.
  • a buffer 10 having a capacity (75 frames) sufficient to hold the first frame (FF) of response frames input from 75 ECUs 30 is prepared, and concentrated from a maximum of 75 ECUs 30. Thus, it is possible to hold the first frame (FF) of the response frame that is input.
  • the gateway device 1 performs a process of monitoring the buffer 10 holding the response frame so that each ECU 30 that has received the function address request frame does not time out.
  • Fig. 7 shows this flowchart.
  • the gateway apparatus 1 periodically performs the process shown in FIG. 7 in parallel with the processes shown in FIGS.
  • a response frame has been received from the ECU 30 (S300).
  • the determination in S300 is NO and this processing is terminated.
  • the count value of the counter is reset and time counting by the counter is started (S302).
  • the gateway device 1 has a counter corresponding to each ECU 30 that can be connected to the second bus side.
  • each gateway device 1 receives Start timing individually using the corresponding counter.
  • the flow control frame (FC) from the diagnostic tool 2 has been relayed to the ECU 30 (S304).
  • the first frame (FF) of the response frame from each ECU 30 is held in the buffer 10, and then the first frame (FF) of the response frame is read from the buffer 10 and transmitted to the diagnostic tool 2. It is like that.
  • the diagnostic tool 2 transmits a flow control frame (FC) to the ECU 30 that has transmitted the response frame.
  • FC flow control frame
  • the gateway apparatus 1 when the gateway apparatus 1 receives the flow control frame (FC) from the diagnostic tool 2 to the specific ECU 30, the gateway apparatus 1 performs a process of relaying the flow control frame (FC) to the specific ECU 30.
  • Fig. 8 shows this flowchart.
  • the gateway apparatus 1 periodically performs the process shown in FIG. 8 in parallel with the processes shown in FIGS.
  • the gateway device 1 reads out the response frame written in the buffer 10 and transmits the response frame to the diagnostic tool 2.
  • Fig. 9 shows this flowchart.
  • the gateway apparatus 1 periodically performs the process shown in FIG. 9 in parallel with the processes shown in FIGS.
  • the first frame (FF) of the response frame held in the buffer 10 is read (S500).
  • the priority for transmitting the response frame to the diagnostic tool 2 is determined (S502).
  • the priority is determined according to the regulations such as the ISO standard described above.
  • the priority for transmitting a response frame is defined by CANID.
  • the priority is determined according to the ISO standard.
  • the response frame read from the buffer 10 is transmitted to the diagnostic tool 2 according to the priority determined in S502 (S504).
  • the buffer 10 is empty (S506). Specifically, it is determined whether or not the response data held in the buffer 10 has been transmitted. If the response data held in the buffer 10 has not been transmitted, the determination in S506 is NO and the process returns to S500. In this way, the response frames held in the buffer 10 are sequentially transmitted to the diagnostic tool 2. When transmission of all response frames held in the buffer 10 is completed, the determination in S506 is YES, and this process ends.
  • the gateway device 1 relays a response frame from the ECU 30 that has received the function request frame to the diagnostic tool 2, and the ECU 30 cannot receive the flow control frame (FC) from the diagnostic tool 2 within a specified time.
  • a process of instructing the ECU 30 to wait is performed so as not to time out.
  • FIG. 10 shows this flowchart.
  • the gateway apparatus 1 periodically performs the process shown in FIG. 10 in parallel with the processes shown in FIGS.
  • a wait transmission determination process is performed (S600).
  • the ECU 30 determines whether to time out based on this count value, and the response frame (buffer data) held in the buffer 10 is determined. Processing for determining whether or not transmission to the diagnostic tool 2 is incomplete is performed.
  • the ECU 30 that has received the flow control frame (FC) in which the flow status (FS) is designated as a wait (WT) continues to wait for a certain period of time and does not time out. However, even if the predetermined period is exceeded, a timeout occurs if the next flow control frame (FC) is not received.
  • the determination of S602 is NO, and then the response frame (buffer data) stored in the buffer 10 is diagnosed. It is determined whether or not the transmission of has been completed (S608).
  • FIG. 11 shows a flow of a frame between the diagnostic tool 2, the gateway device 1, and the ECU 30.
  • the gateway device 1 sends the first frame (FF) of the response frame to the buffer 10. Are held sequentially.
  • the gateway apparatus 1 When the gateway apparatus 1 cannot promptly transmit the response frame held in the buffer 10 to the diagnostic tool 2, the gateway apparatus 1 responds on behalf of the diagnostic tool 2 so that the ECU 30 that has transmitted the response frame does not time out.
  • the flow control frame (FC) in which the flow status (FS) is designated as the wait (WT) is transmitted to the ECU 30 that has transmitted the frame on behalf.
  • the gateway device 1 reads the response frame held in the buffer 10 from the buffer 10 and transmits it to the diagnostic tool 2.
  • the frame (FC) is transmitted on behalf.
  • the gateway apparatus 1 transmits the response frame held in the buffer 10 to the diagnostic tool 2
  • the gateway apparatus 1 stops transmitting the flow control frame (FC) in which the flow status (FS) is designated as the wait (WT).
  • the ECU 30 When the ECU 30 receives the flow control frame (FC), the ECU 30 starts normal processing, and transmits a selective frame (CF) according to the flow control frame (FC) from the diagnostic tool 2.
  • CF selective frame
  • the gateway device 1 When the gateway device 1 receives the consequent frame (CF), the gateway device 1 relays the consequent frame (CF) to the diagnostic tool 2.
  • the gateway apparatus 1 when the gateway apparatus 1 receives the connective frame (CF) responding to the reception of the connective frame (CF) from the diagnostic tool 2, the gateway apparatus 1 relays the connective frame (CF) to the ECU 30.
  • the request frame when a request frame representing simultaneous transmission to the plurality of ECUs 30 is received from the diagnostic tool 2, the request frame is transmitted to the plurality of ECUs 30 and transmitted from the plurality of ECUs 30 in response to reception of the request frame.
  • the received response frame is received, the received response frame is held in the buffer 10, and the response frame held in the buffer 10 is relayed to the diagnostic tool 2. Therefore, the response frame from each ECU 30 is received and the diagnostic tool 2 is received. Can be relayed to. Further, since the standby instruction frame for instructing standby so as not to time out is transmitted to the ECU 30 that has transmitted the response frame, each ECU 30 can be prevented from timing out.
  • the standby instruction frame can be a flow control frame (FC) in which the wait (WT) is designated as the flow status (FS).
  • FC flow control frame
  • WT wait
  • FS flow status
  • the ECU 30 that has transmitted the response frame based on the measured time is measured, and the ECU 30 that has transmitted the response frame based on the measured time is When it is determined whether or not the ECU 30 that has transmitted the response frame times out, the standby instruction frame is transmitted to the ECU 30 that has transmitted the response frame. Therefore, the ECU 30 that does not need to transmit the standby instruction frame is It is possible to prevent an instruction frame from being transmitted.
  • the priority for transmitting the response frame to the diagnostic tool 2 is determined according to the regulations such as the ISO standard. However, the priority is determined so as to satisfy the following conditions while complying with such regulations. You can also
  • the priority is determined so as to increase the priority of the ECU that is estimated to time out if a flow control frame (FC) in which the wait (WT) is specified as the flow status (FS) is not transmitted.
  • FC flow control frame
  • WT wait
  • FS flow status
  • the priority is determined so that the priority of the ECU connected to the bus farthest from the diagnostic tool 2 is higher.
  • the ECU connected to the bus farthest from the diagnostic tool 2 can be, for example, an ECU located at the most physically separated location from the diagnostic tool 2, and is interposed between the ECU 2 and the diagnostic tool 2.
  • the ECU with the largest number of gateways can be used.
  • the priority is determined so that the priority of the ECU connected to the bus with the largest number of connected ECUs becomes high.
  • the priority is determined so that the priority of the ECU that transmitted the response frame first becomes higher.
  • the priority is determined so that the priority of the ECU that has transmitted the first frame (FF) is higher than that of the single frame (SF).
  • the priority is determined so that the priority of the ECU with a young CANID is higher.
  • the priority is determined so that the priority of the ECU connected to the young bus of the bus channel is higher.
  • a central gateway capable of connecting 15 ECUs to each of the five buses has been shown as an example of the gateway device 1.
  • the number of bus systems and one bus can be connected.
  • the number of ECUs is not limited to that shown in the above embodiment.
  • the buffer 10 is provided for each CANID assigned to each ECU 30.
  • a buffer is provided for each bus so that each buffer holds a response frame, or a large-capacity buffer is provided.
  • the response frame can be held in the large-capacity buffer so as to be centrally managed.
  • S102 corresponds to the frame broadcast unit and the frame broadcast unit
  • the buffer 10 corresponds to the holding unit and the holding unit
  • S202 corresponds to the frame holding unit and the frame holding unit
  • S504 corresponds to the relay unit and the relay unit.
  • S604 corresponds to the standby instruction frame transmission unit and the standby instruction frame transmission unit
  • S502 corresponds to the priority specifying unit and the priority specifying unit
  • S302 corresponds to the time measuring unit and the time measuring unit
  • S602 corresponds to the time-out determination. Part and time-out determination means.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

 診断ツール(2)と、複数の制御装置(30)との間のフレームを中継するゲートウェイ装置(1)を提供する。ゲートウェイ装置は、診断ツールから複数の制御装置に対する一斉送信を表す要求フレームを受信すると該要求フレームを複数の制御装置に一斉送信し、要求フレームの受信に応答して複数の制御装置から送信される応答フレームを受信すると該受信した応答フレームを保持部(10)に保持させ、保持部に保持された応答フレームを診断ツールへ中継し、応答フレームを送信した制御装置に、タイムアウトしないように待機を指示する待機指示フレームを送信するように構成される。

Description

ゲートウェイ装置 関連出願の相互参照
 本出願は、2014年7月30日に出願された日本国特許出願2014-155338号に基づくものであり、その開示をここに参照により援用する。
 本開示は、ゲートウェイ装置に関するものである。
 車両には、車両を制御する多数のECUが搭載されており、各ECU間で様々なデータの送受信が行われるようになっている。また、車両には、ゲートウェイ装置を備え、このゲートウェイ装置に診断ツール等の外部機器を接続して各ECUと通信できるようになっているものもある。
 上記したような診断ツールとECUの間の通信は、通常、相手側の物理アドレスを個別に指定する1対1の通信により行われる。また、診断ツールからゲートウェイ装置へ、全ECUへの一斉送信を表す機能アドレスをアドレス領域に指定したフレームが送信されると、ゲートウェイ装置が、このフレームを全ECUに一斉送信するようにしたものもある(例えば、特許文献1参照)。
特開2013-5156号公報
 上記したような診断ツールとECUの間のフレームの送受信は、ISO規格(例えば、ISO15765-2、ISO15765-4)に規定されたCANダイアグ通信の通信仕様に従って行われる。なお、CANダイアグ通信では、1つのフレームで転送できるデータは一定バイト(例えば、7バイト)までとなっており、送信したいデータが一定バイトを越える場合には、複数回にわたりフレームを送信する必要がある。
 上記ISO規格において、送信したいデータが一定バイトを越えない場合、診断ツールECUとの間のフレームの送受信は、シングルフレーム(SF)を用いて行われる。
 また、送信したいデータが一定バイトを越える場合、診断ツールECUとの間のフレームの送受信は、図12に示すように、ファーストフレーム(FF)、コンゼクティブフレーム(CF)およびフローコントロールフレーム(FC)を用いて行われる。
 ファーストフレーム(FF)は、マルチフレームの最初のフレームであり、コンゼクティブフレーム(CF)は、マルチフレームの2つ目以降のフレームである。また、フローコントロールフレーム(FC)は、相手側の機器から送信されるフレームの数や時間間隔等のフロー制御を行うためのフレームである。
 例えば、ゲートウェイ装置は、診断ツールから、全ECUへの一斉送信を表す機能アドレスをアドレス領域に指定したシングルフレーム(SF)の機能アドレス要求フレームを受信すると、この機能アドレス要求フレームを各ECU30へ一斉送信する。
 ECUは、このフレームを受信すると、このフレームに応答する応答データが一定バイトを超えるか否かを判定し、応答データが一定バイトを超える場合、応答フレームのファーストフレーム(FF)を診断ツール(受信者)へ送信する。
 診断ツールは、ECUからの応答フレームのファーストフレーム(FF)を受信すると、ECU(送信者)へフローコントロールフレーム(FC)を送信し、相手側の機器から送信されるフレームの数や時間間隔等のフロー制御を行う。
 このように、診断ツール(受信者)からECU(送信者)へフローコントロールフレーム(FC)を送信すると、それ以降、フローコントロールフレーム(FC)の指示にしたがって、ECU(送信者)から応答フレームの2つ目以降のコンゼクティブフレーム(CF)が送信されるようになる。
 しかし、ECUに対して機能アドレス要求フレームを送信した後、相手側の機器(ECU)から送信される応答フレームのファーストフレーム(FF)についてはフレームの数や時間間隔等のフロー制御を行うことができない。
 特に、ゲートウェイ装置が複数のECUに対して機能アドレス要求フレームを一斉送信するような場合、ゲートウェイ装置と診断ツールの間のデータ転送可能量は、ゲートウェイ装置と各ECUとの間のデータ転送可能量の合計量と比較して非常に少ないため、機能アドレス要求フレームを受信した複数のECUから無条件に集中して応答フレームが送信されると、ゲートウェイ装置は、多数のECUから送信されたフレームを取りこぼしてしまい、診断ツールに正確に中継することができなくなるといった問題が発生する。
 また、上記ISO規格において、送信者と受信者との間のフレームの送受信には各種時間規定がある。例えば、ECUが診断ツールへフレームを送信した後、規定時間を超えても診断ツールからのフレームをECUが受信できない場合、ECUはタイムアウトとなってエラーが発生してしまう。すなわち、従来のゲートウェイ装置は、診断ツールとECUの間のフレームの中継は行うが、診断ツールに代わってフロー制御のための各種フレームを送信するといったことは行わないので、規定時間を超えても診断ツールからのフレームを受信できないECUはタイムアウトとなってしてしまう。
 上記したように、多数のECUから無条件に集中して応答フレームが送信されるような場合、これらのフレームを診断ツールに中継し、このフレームに応答して診断ツールより送信されるフレームを中継して、規定時間内に各ECUに受信させるのは困難となってしまう。
 本開示の一つの目的は、上記に鑑みたもので、診断ツールからのフレームを各制御装置へ一斉送信した後、各制御装置からの応答フレームを受信して診断ツールに中継できるようにするとともに、各制御装置がタイムアウトしないようにすることにある。
 本開示の一例に係るゲートウェイ装置は、診断ツールから複数の制御装置に対する一斉送信を表す要求フレームを受信すると、該要求フレームを複数の制御装置に一斉送信するフレーム一斉送信部と、要求フレームの受信に応答して複数の制御装置から送信される応答フレームを受信すると、該受信した応答フレームを保持部に保持させるフレーム保持部と、保持部に保持された応答フレームを診断ツールへ中継する中継部と、応答フレームを送信した制御装置に、タイムアウトしないように待機を指示する待機指示フレームを送信する待機指示フレーム送信部と、を備える。
 このような構成によれば、診断ツールから複数の制御装置に対する一斉送信を表す要求フレームを受信すると、該要求フレームを複数の制御装置に一斉送信し、要求フレームの受信に応答して複数の制御装置から送信される応答フレームを受信すると、該受信した応答フレームを保持部に保持させ、保持部に保持された応答フレームを診断ツールへ中継するので、各制御装置からの応答フレームを受信して診断ツールに中継することができる。また、応答フレームを送信した制御装置に、タイムアウトしないように待機を指示する待機指示フレームを送信するので、各制御装置がタイムアウトしないようにすることもできる。
 本開示についての上記および他の目的、特徴や利点は、添付の図面を参照した下記の詳細な説明から、より明確になる。添付図面において、
図1は、一実施形態に係るゲートウェイ装置の構成を示す図である。 図2は、診断ツールECUとの間のフレームについて説明するための図である。 図3は、フローコントロールフレームのフローステータスについて説明するための図である。 図4は、機能要求フレームの一斉送信と応答フレームの送信について説明するための図である。 図5は、ゲートウェイ装置のフローチャートである。 図6は、ゲートウェイ装置のフローチャートである。 図7は、ゲートウェイ装置のフローチャートである。 図8は、ゲートウェイ装置のフローチャートである。 図9は、ゲートウェイ装置のフローチャートである。 図10は、ゲートウェイ装置のフローチャートである。 図11は、フローコントロールフレームの代行送信のフレームの流れを示した図である。 図12は、診断ツールECUとの間のフレームの送受信について説明するための図である。
 ゲートウェイ装置の構成を図1に示す。本ゲートウェイ装置1は、第1バス側に接続された診断ツール2等の機器と、第2バス側に接続された複数の制御装置(以下、ECUと称す)30とのフレームの中継を行うセントラルゲートウェイ装置(CGW)として構成されている。第1バス側には、1系統のバスが用意されており、第2バス側には、1~5チャンネル(ch)の5系統のバスが用意されている。第2バス側の5系統の各バスには、それぞれ15個のECU30を接続することが可能となっている。すなわち、本ゲートウェイ装置1は、第1バス側に接続された診断ツール2等の外部機器と、5系統の各バスに接続された最大75個のECU30とのフレームの中継を行うことが可能となっている。
 本ゲートウェイ装置1は、CPU、RAM、ROM、I/O等を備えたコンピュータを含む。CPUはROMに記憶されたプログラムに従って各種処理を実施する。また、本ゲートウェイ装置1は、第2バス側の各ECU30からの応答フレームを一時的に保持するバッファ10を備えている。なお、本実施形態において、バッファ10は各ECU30に割り当てられたCANID毎に設けられている。本ゲートウェイ装置1は、5系統の各バスに接続可能な合計75個のECU30に対し、それぞれ1フレーム分の容量のバッファ10を有している。すなわち、本ゲートウェイ装置1は、合計75フレーム分の容量のバッファ10を有している。
 本実施形態において、診断ツール2と各ECU30との間のフレームの送受信は、ISO規格(例えば、ISO15765-2、ISO15765-4)に規定されたCANダイアグ通信の通信仕様に従って行われるようになっている。なお、CANダイアグ通信では、1つのフレームで転送できるデータは一定バイト(例えば、7バイト)までとなっており、送信したいデータが一定バイトを越えない場合には、シングルフレームで送信を行い、送信したいデータが一定バイトを越える場合には、複数のフレーム(マルチフレーム)で送信を行うようになっている。
 上記ISO規格に規定されているフローコントロールにおいて、診断ツール2とECU30との間のフレームのやり取りは、図2に示すように、シングルフレーム(SF)、ファーストフレーム(FF)、コンゼクティブフレーム(CF)およびフローコントロールフレーム(FC)を用いて行われる。
 シングルフレーム(SF)は、送信するデータが1つのフレームに収まる場合に使用されるフレームである。また、ファーストフレーム(FF)は、マルチフレームの最初のフレームであり、コンゼクティブフレーム(CF)は、マルチフレームの2つ目以降のフレームである。なお、フローコントロールフレーム(FC)は、2つ目以降のコンゼクティブフレーム(CF)がある場合に使用される。
 ここで、フローコントロールフレーム(FC)について説明する。図2に示すように、フローコントロールフレーム(FC)には、フレームの種別を示すN_PCIタイプ、フローステータス(FS)、ブロックサイズ(BS)およびセパレーションタイム(Stmin)が含まれる。
 なお、ブロックサイズ(BS)は、連続フレームの受信可能最大数を送信者に伝えるために使用される。また、セパレーションタイム(Stmin)は、フレームの送信間隔を送信者に伝えるために使用される。
 また、図3に示すように、フローステータス(FS)には、Continue To Send(CTS)、Wait(WT)およびOverflow(OVFLW)が設定される。
 Continue To Send(CTS)は、フレームを受信する準備ができていることを示すものである。また、Wait(WT)は、送信者に待機を継続させるものである。また、Overflow(OVFLW)は、送信者にエラーが発生したことを示すものである。
 このように、診断ツール2からECU30へフローコントロールフレーム(FC)を送信すると、それ以降、フローコントロールフレーム(FC)の指示にしたがって、ECU30から応答フレームの2つ目以降のコンゼクティブフレーム(CF)が送信されるようになる。
 本ゲートウェイ装置1は、診断ツール2から、特定のECU30の物理アドレスをアドレス領域に設定した要求フレームを受信すると、この要求フレームを特定のECU30へ個別に中継する。
 また、図4に示すように、本ゲートウェイ装置1は、診断ツール2から、全ECU30への一斉送信を表す機能アドレスをアドレス領域に指定した機能アドレス要求フレームを受信すると、この機能アドレス要求フレームを各ECU30へ一斉送信する。このように、機能アドレス要求フレームを各ECU30へ一斉送信することで、要求フレームを特定のECU30へ個別に中継する場合と比較して、フレームの送信にかかる時間を大幅に短縮することが可能となる。
 また、診断ツール2からの機能アドレス要求フレームを受信した各ECU30は、この機能アドレス要求フレームの受信に応答する応答フレームを同時に診断ツール2へ向けて送信するようになっている。
 図5に、この処理のフローチャートを示す。本ゲートウェイ装置1は、定期的に図に示す処理を実施する。なお、機能アドレス要求フレームはシングルフレーム(SF)となっている。また、各図面のフローチャートにおける各制御ステップは、ゲートウェイ装置1が有する各種の機能部および機能実現手段を構成している。
 まず、診断ツール2から、全ECU30へ一斉送信を表す機能アドレス要求フレームを受信したか否かを判定する(S100)。ここで、機能アドレス要求フレームが受信されていない場合、S100の判定はNOとなり、本処理を終了する。
 また、診断ツール2からの機能アドレス要求フレームが受信されると、受信された機能アドレス要求フレームを全ECU30へ一斉送信し(S102)、本処理を終了する。
 なお、機能アドレス要求フレームを受信した各ECU30は、それぞれ受信した機能アドレス要求フレームに応答する応答フレームを診断ツール2へ送信するようになっている。したがって、ゲートウェイ装置1には、機能アドレス要求フレームを受信した各ECU30から集中的に応答フレームが入力される。
 なお、同一バスに接続された複数のECU30からのフレーム送信が同時に起こった場合には、周知のCAN調停により、CANIDの値の小さいものが優先されるようになっている。すなわち、同一バスに接続された複数のECU30からは、CANIDの値の小さいものから順番に集中的に応答フレームが入力される。
 本ゲートウェイ装置1は、機能アドレス要求フレームを受信した各ECU30からの応答フレームを受信すると、受信した応答フレームをバッファ10に書き込む処理を行う。
 図6に、このフローチャートを示す。本ゲートウェイ装置1は、図5に示した処理と並行に図6に示す処理を定期的に実施する。
 まず、ECU30から応答フレームを受信したか否かを判定する(S200)。本実施形態では、応答フレームのファーストフレーム(FF)を受信したか否かを判定する。ここで、応答フレームのファーストフレーム(FF)が受信されない場合、S200の判定はNOとなり、本処理を終了する。
 また、機能アドレス要求フレームを受信した各ECU30から集中的に応答フレームのファーストフレーム(FF)が送信され、これらの応答フレームを受信すると、S200の判定はYESとなり、受信した応答フレームを、順次、バッファ10に書き込み(S202)、本処理を終了する。
 このような処理を繰り返し実施して、機能アドレス要求フレームを受信した各ECU30から集中して入力される応答フレームのファーストフレーム(FF)がバッファ10に保持される。
 なお、本実施形態において、75個のECU30より入力される応答フレームのファーストフレーム(FF)を保持するだけの容量(75フレーム分)のバッファ10が用意されており、最大75個のECU30より集中して入力される応答フレームのファーストフレーム(FF)を保持することが可能となっている。
 本ゲートウェイ装置1は、機能アドレス要求フレームを受信した各ECU30がタイムアウトしないよう、応答フレームを保持しているバッファ10を監視する処理を行う。
 図7に、このフローチャートを示す。本ゲートウェイ装置1は、図5、6に示した処理と並行に図7に示す処理を定期的に実施する。
 まず、ECU30から応答フレームを受信したか否かを判定する(S300)。本実施形態では、応答フレームのファーストフレーム(FF)を受信したか否かを判定する。ここで、ECU30から応答フレームのファーストフレーム(FF)が受信されない場合、あるいは、ECU30からシングルフレーム(SF)の応答フレームを受信した場合、S300の判定はNOとなり、本処理を終了する。
 また、機能アドレス要求フレームを受信した各ECU30から応答フレームのファーストフレーム(FF)を受信すると、カウンタのカウント値をリセットしてカウンタによる計時を開始する(S302)。なお、本ゲートウェイ装置1は、第2バス側に接続可能な各ECU30に対応するカウンタを有しており、機能アドレス要求フレームを受信した各ECU30からの応答フレームを受信すると、受信した各ECU30に対応するカウンタを用いて個別に計時を開始する。
 次に、診断ツール2からのフローコントロールフレーム(FC)をECU30へ中継したか否かを判定する(S304)。本実施形態において、S202にて、各ECU30からの応答フレームのファーストフレーム(FF)をバッファ10に保持させた後、バッファ10から応答フレームのファーストフレーム(FF)を読み出して診断ツール2へ送信するようになっている。また、診断ツール2は、応答フレームのファーストフレーム(FF)を受信すると、応答フレームを送信したECU30に対してフローコントロールフレーム(FC)を送信するようになっている。ここでは、診断ツール2から応答フレームを送信したECU30に対するフローコントロールフレーム(FC)を中継したか否かを判定する。
 ここで、診断ツール2から、応答フレームのファーストフレーム(FF)を送信したECU30に対するフローコントロールフレーム(FC)を中継していない場合、S304の判定はNOとなり、S304へ戻る。したがって、カウンタによる計時が継続される。
 また、診断ツール2から応答フレームのファーストフレーム(FF)を送信したECU30に対するフローコントロールフレーム(FC)を中継すると、S304の判定はYESとなり、次に、カウンタによる計時を停止する(S306)。具体的には、カウンタのカウントアップを停止し、本処理を終了する。
 また、上記したように、本ゲートウェイ装置1は、診断ツール2から特定のECU30へフローコントロールフレーム(FC)を受信すると、このフローコントロールフレーム(FC)を特定のECU30へ中継する処理を実施する。
 図8に、このフローチャートを示す。本ゲートウェイ装置1は、図5~7に示した処理と並行に図8に示す処理を定期的に実施する。
 まず、診断ツール2から特定のECU30へのフローコントロール(FC)を受信したか否かを判定する(S400)。ここで、診断ツール2からのフローコントロール(FC)を受信していない場合、S400の判定はNOとなり、本処理を終了する。
 また、診断ツール2から特定のECU30へのフローコントロール(FC)を受信すると、S400の判定はYESとなり、このフローコントロール(FC)を特定のECU30へ中継し、本処理を終了する。
 また、本ゲートウェイ装置1は、バッファ10に書き込んだ応答フレームを読み出して診断ツール2に送信する処理を実施する。
 図9に、このフローチャートを示す。本ゲートウェイ装置1は、図5~8に示した処理と並行に図9に示す処理を定期的に実施する。
 まず、バッファ10に保持された応答フレームのファーストフレーム(FF)を読み出す(S500)。
 次に、診断ツール2へ応答フレームを送信する際の優先度を決定する(S502)。本実施形態においては、上記したISO規格等の法規に従って優先度を決定する。なお、ISO15031-4 OBDIIでは、CANIDにより、応答フレームを送信する際の優先度が規定されている。ここでは、このISO規格に従って優先度を決定する。
 次に、S502にて決定された優先度に従ってバッファ10から読み出した応答フレームを診断ツール2へ送信する(S504)。
 次に、バッファ10が空になったか否かを判定する(S506)。具体的には、バッファ10保持された応答データが送信されたか否かを判定する。ここで、バッファ10保持された応答データが未送信となっている場合、S506の判定はNOとなり、S500へ戻る。このようにして、バッファ10に保持された応答フレームが順次診断ツール2へ送信される。また、バッファ10に保持された全ての応答フレームの送信が完了すると、S506の判定はYESとなり、本処理を終了する。
 また、本ゲートウェイ装置1は、機能要求フレームを受信したECU30から診断ツール2への応答フレームを中継した後、ECU30が診断ツール2からのフローコントロールフレーム(FC)を規定時間内に受信できずにタイムアウトしないよう、このECU30にウェイトを指示する処理を実施する。
 図10に、このフローチャートを示す。本ゲートウェイ装置1は、図5~9に示した処理と並行に図10に示す処理を定期的に実施する。
 まず、ウェイト送信判定処理を実施する(S600)。本実施形態では、S302にて計時を開始するカウンタのカウント値を参照し、このカウント値に基づいてECU30がタイムアウトするか否かの判定処理と、バッファ10に保持した応答フレーム(バッファデータ)の診断ツール2への送信が未完了であるか否かの判定処理を行う。
 次に、ECU30がタイムアウトするか否かを判定する(S602)。ここで、S600のウェイト送信判定処理において、ECU30がタイムアウトするという判定結果が得られた場合、S602の判定はYESとなり、次に、診断ツール2に代わって、フローコントロールフレーム(FC)のウェイトを代行送信する(S604)。具体的には、フローステータス(FS)をウェイト(WT)に指定したフローコントロールフレーム(FC)をECU30へ送信する。
 なお、このフローステータス(FS)をウェイト(WT)に指定したフローコントロールフレーム(FC)を受信したECU30は一定期間、待機を継続し、タイムアウトしなくなる。ただし、一定期間を超えても、次のフローコントロールフレーム(FC)が受信されないとタイムアウトする。
 次に、バッファ10に保持された応答フレーム(バッファデータ)の診断ツール2への送信が完了したか否かを判定する(S606)。
 ここで、バッファ10に保持された応答フレーム(バッファデータ)の診断ツール2への送信が完了していない場合、S606の判定はNOとなり、S600へ戻る。
 また、S600のウェイト送信判定処理において、ECU30がタイムアウトしないという判定結果が得られた場合、S602の判定はNOとなり、次に、バッファ10に保持された応答フレーム(バッファデータ)の診断ツール2への送信が完了したか否かを判定する(S608)。
 ここで、バッファ10に保持された応答フレーム(バッファデータ)の診断ツール2への送信が完了していない場合、S608の判定はNOとなり、S600へ戻る。
 そして、バッファ10に保持された応答フレーム(バッファデータ)の診断ツール2への送信が完了すると、S608の判定はYESとなり、本処理を終了する。
 図11に、診断ツール2、ゲートウェイ装置1およびECU30の間のフレームの流れを示す。機能アドレス要求フレームの一斉送信に応答してECU30から集中的に応答フレームのファーストフレーム(FF)がゲートウェイ装置1に送信されると、ゲートウェイ装置1は、バッファ10に応答フレームのファーストフレーム(FF)を順次保持させる。
 ゲートウェイ装置1は、バッファ10に保持された応答フレームを診断ツール2へ速やかに送信することができない場合、応答フレームを送信したECU30がタイムアウトすることのないように、診断ツール2に代わって、応答フレームを送信したECU30へフローステータス(FS)をウェイト(WT)に指定したフローコントロールフレーム(FC)を代行送信する。
 なお、フローステータス(FS)をウェイト(WT)に指定したフローコントロールフレーム(FC)を受信したECU30は、一定期間、待機を継続する。
 また、ゲートウェイ装置1は、バッファ10に保持された応答フレームをバッファ10から読み出して診断ツール2へ送信するまで、一定期間毎にECU30へフローステータス(FS)をウェイト(WT)に指定したフローコントロールフレーム(FC)を代行送信する。
 そして、ゲートウェイ装置1は、バッファ10に保持された応答フレームを診断ツール2へ送信すると、フローステータス(FS)をウェイト(WT)に指定したフローコントロールフレーム(FC)の送信を中止する。
 そして、診断ツール2からECU30へのフローコントロールフレーム(FC)を受信すると、このフローコントロールフレーム(FC)をECU30へ中継する。
 ECU30は、このフローコントロールフレーム(FC)を受信すると、通常処理を開始し、診断ツール2からのフローコントロールフレーム(FC)に従ってコンゼクティブフレーム(CF)の送信を行う。
 ゲートウェイ装置1は、このコンゼクティブフレーム(CF)を受信すると、このコンゼクティブフレーム(CF)を診断ツール2へ中継する。
 また、ゲートウェイ装置1は、診断ツール2からこのコンゼクティブフレーム(CF)の受信に応答するコンゼクティブフレーム(CF)を受信すると、このコンゼクティブフレーム(CF)をECU30へ中継する。
 上記した構成によれば、診断ツール2から複数のECU30に対する一斉送信を表す要求フレームを受信すると、該要求フレームを複数のECU30に一斉送信し、要求フレームの受信に応答して複数のECU30から送信される応答フレームを受信すると、該受信した応答フレームをバッファ10に保持させ、バッファ10に保持された応答フレームを診断ツール2へ中継するので、各ECU30からの応答フレームを受信して診断ツール2に中継することができる。また、応答フレームを送信したECU30に、タイムアウトしないように待機を指示する待機指示フレームを送信するので、各ECU30がタイムアウトしないようにすることもできる。
 なお、待機指示フレームは、ウェイト(WT)をフローステータス(FS)に指定したフローコントロールフレーム(FC)とすることができる。
 また、バッファ10に保持された応答フレームを診断ツール2へ送信する際の優先度を特定し、この優先度に従ってバッファ10に保持された応答フレームを診断ツール2へ送信することもできる。
 また、要求フレームの受信に応答してECU30から送信される応答フレームを受信すると、該応答フレームを受信してからの時間を計測し、この計測された時間に基づいて応答フレームを送信したECU30がタイムアウトするか否かを判定し、応答フレームを送信したECU30がタイムアウトすると判定された場合、応答フレームを送信したECU30に待機指示フレームを送信するので、待機指示フレームを送信する必要のないECU30に待機指示フレームを送信してしまうといったことを防止することができる。
 (第2実施形態)
 上記第1実施形態では、診断ツール2へ応答フレームを送信する際の優先度をISO規格等の法規に従って決定したが、このような法規に従いつつ、以下の条件を満たすように上記優先度を決定することもできる。
 (1)ウェイト(WT)をフローステータス(FS)に指定したフローコントロールフレーム(FC)を送信しないとタイムアウトしてしまうと推定されるECUの優先度を高くするように上記優先度を決定する。
 (2)診断ツール2から最も離れたバスに接続されているECUの優先度が高くなるように上記優先度を決定する。ここで、診断ツール2から最も離れたバスに接続されているECUは、例えば、診断ツール2から最も物理的に離れた場所に位置するECUとすることもでき、診断ツール2との間に介在するゲートウェイ数の最も多いECUとすることもできる。
 (3)接続されているECU数の最も多いバスに接続されているECUの優先度が高くなるように上記優先度を決定する。
 (4)一番最初に応答フレームを送信したECUの優先度が高くなるように上記優先度を決定する。
 (5)シングルフレーム(SF)よりもファーストフレーム(FF)を送信したECUの優先度が高くなるように上記優先度を決定する。
 (6)CANIDの若いECUの優先度が高くなるように上記優先度を決定する。
 (7)バスチャンネルの若いバスに接続されているECUの優先度が高くなるように上記優先度を決定する。
 (他の実施形態)
 上記実施形態では、ゲートウェイ装置1として、5系統のバスの各々に15個のECUを接続することが可能なセントラルゲートウェイを例に示したが、バスの系統の数や、1つのバスに接続可能なECUの数は、上記実施形態に示したものに限定されるものではない。
 また、上記実施形態では、各ECU30に割り当てられたCANID毎にバッファ10を設けたが、例えば、バス毎にバッファを設けて各バッファに応答フレームを保持させるようにしたり、大容量のバッファを設け、一元管理するようにこの大容量のバッファに応答フレームを保持させるようにすることもできる。
 なお、S102がフレーム一斉送信部およびフレーム一斉送信手段に相当し、バッファ10が保持部および保持手段に相当し、S202がフレーム保持部およびフレーム保持手段に相当し、S504が中継部および中継手段に相当し、S604が待機指示フレーム送信部および待機指示フレーム送信手段に相当し、S502が優先度特定部および優先度特定手段に相当し、S302が計時部および計時手段に相当し、S602がタイムアウト判定部およびタイムアウト判定手段に相当する。
 以上、本開示の係る実施形態および構成を例示したが、本開示に係る実施形態および構成は、上述した各実施形態および構成に限定されるものではない。異なる実施形態および構成に開示された技術的部位を適宜組み合わせて得られる実施形態および構成も、本開示の係る実施形態および構成の範囲に含まれる。

 

Claims (3)

  1.  診断ツール(2)と、複数の制御装置(30)との間のフレームを中継するゲートウェイ装置(1)であって、
     前記診断ツールから前記複数の制御装置に対する一斉送信を表す要求フレームを受信すると、該要求フレームを前記複数の制御装置に一斉送信するフレーム一斉送信部(S102)と、
     前記要求フレームの受信に応答して前記複数の制御装置から送信される応答フレームを受信すると、該受信した応答フレームを保持部(10)に保持させるフレーム保持部(S202)と、
     前記保持部に保持された前記応答フレームを前記診断ツールへ中継する中継部(S504)と、
     前記応答フレームを送信した前記制御装置に、タイムアウトしないように待機を指示する待機指示フレームを送信する待機指示フレーム送信部(S604)と、を備えたゲートウェイ装置。
  2.  前記保持部に保持された前記応答フレームを前記診断ツールへ送信する際の優先度を特定する優先度特定部(S502)を備え、
     前記中継部は、前記優先度特定部により特定された優先度に従って前記保持部に保持された前記応答フレームを前記診断ツールへ送信する、請求項1に記載のゲートウェイ装置。
  3.  前記要求フレームの受信に応答して前記制御装置から送信される応答フレームを受信すると、該応答フレームを受信してからの時間を計測する計時部(S302)と、
     前記計時部により計測された時間に基づいて前記応答フレームを送信した前記制御装置がタイムアウトするか否かを判定するタイムアウト判定部(S602)と、を備え、
     前記待機指示フレーム送信部は、前記タイムアウト判定部により前記応答フレームを送信した前記制御装置がタイムアウトすると判定された場合、前記応答フレームを送信した前記制御装置に前記待機指示フレームを送信する、請求項1または2に記載のゲートウェイ装置。

     
PCT/JP2015/003512 2014-07-30 2015-07-10 ゲートウェイ装置 WO2016017088A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-155338 2014-07-30
JP2014155338A JP2016032274A (ja) 2014-07-30 2014-07-30 ゲートウェイ装置

Publications (1)

Publication Number Publication Date
WO2016017088A1 true WO2016017088A1 (ja) 2016-02-04

Family

ID=55217014

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/003512 WO2016017088A1 (ja) 2014-07-30 2015-07-10 ゲートウェイ装置

Country Status (2)

Country Link
JP (1) JP2016032274A (ja)
WO (1) WO2016017088A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615105A (zh) * 2022-04-02 2022-06-10 深圳市元征科技股份有限公司 数据传输方法、装置、电子设备、系统及存储介质
CN115102803A (zh) * 2022-06-22 2022-09-23 重庆长安新能源汽车科技有限公司 一种can通讯多帧传输方法、ecu
WO2024082907A1 (zh) * 2022-10-20 2024-04-25 思瑞浦微电子科技(上海)有限责任公司 一种拓扑网络及通信处理方法

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017169131A (ja) * 2016-03-17 2017-09-21 日本電信電話株式会社 画像処理装置及び画像処理方法
JP2017175453A (ja) * 2016-03-24 2017-09-28 日本電信電話株式会社 画像処理装置及び画像処理方法
JP7131475B2 (ja) 2018-05-15 2022-09-06 株式会社デンソー 電子制御装置、セッション確立プログラム及び制御プログラム
JP7192244B2 (ja) 2018-05-15 2022-12-20 株式会社デンソー 中継装置
JP7379892B2 (ja) 2018-07-25 2023-11-15 株式会社デンソー 車両用電子制御システム、車両側システム及び携帯端末
WO2020022265A1 (ja) 2018-07-25 2020-01-30 株式会社デンソー 車両用電子制御システム、プログラム更新の承諾判定方法及びプログラム更新の承諾判定プログラム
JP7159989B2 (ja) 2018-08-10 2022-10-25 株式会社デンソー 車両用マスタ装置、車両用電子制御システム、アクティベート要求の指示方法及びアクティベート要求の指示プログラム
JP7115429B2 (ja) 2018-08-10 2022-08-09 株式会社デンソー 車両用マスタ装置、ロールバックの実行制御方法及びロールバックの実行制御プログラム
JP7354658B2 (ja) 2018-08-10 2023-10-03 株式会社デンソー 車両用電子制御システム、進捗表示の画面表示制御方法及び進捗表示の画面表示制御プログラム
JP7400232B2 (ja) 2018-08-10 2023-12-19 株式会社デンソー 電子制御装置、リトライポイントの特定方法、リトライポイントの特定プログラム及び車両用電子制御システム
JP7419689B2 (ja) 2018-08-10 2024-01-23 株式会社デンソー 車両用電子制御システム、センター装置、車両用マスタ装置、表示制御情報の送信制御方法、表示制御情報の受信制御方法、表示制御情報の送信制御プログラム及び表示制御情報の受信制御プログラム
JP7003976B2 (ja) 2018-08-10 2022-01-21 株式会社デンソー 車両用マスタ装置、更新データの検証方法及び更新データの検証プログラム
JP7047819B2 (ja) 2018-08-10 2022-04-05 株式会社デンソー 電子制御装置、車両用電子制御システム、アクティベートの実行制御方法及びアクティベートの実行制御プログラム
JP7111074B2 (ja) 2018-08-10 2022-08-02 株式会社デンソー 車両用マスタ装置、セキュリティアクセス鍵の管理方法、セキュリティアクセス鍵の管理プログラム及び車両用電子制御システム
JP7427879B2 (ja) 2018-08-10 2024-02-06 株式会社デンソー 車両用マスタ装置、書換え対象のグループ管理方法及び書換え対象のグループ管理プログラム
JP6973449B2 (ja) 2018-08-10 2021-12-01 株式会社デンソー 車両用電子制御システム、配信パッケージのダウンロード判定方法及び配信パッケージのダウンロード判定プログラム
JP6973450B2 (ja) 2018-08-10 2021-12-01 株式会社デンソー 車両用マスタ装置、インストールの指示判定方法及びインストールの指示判定プログラム
JP7354631B2 (ja) 2018-08-10 2023-10-03 株式会社デンソー 電子制御装置、車両用電子制御システム、差分データの整合性判定方法及び差分データの整合性判定プログラム
JP7346956B2 (ja) 2018-08-10 2023-09-20 株式会社デンソー 車両用プログラム書換えシステム、車両用マスタ装置、進捗状態の同期制御方法及び進捗状態の同期制御プログラム
JP7439402B2 (ja) 2018-08-10 2024-02-28 株式会社デンソー 表示制御装置、書換え進捗状況の表示制御方法及び書換え進捗状況の表示制御プログラム
JP7484096B2 (ja) 2018-08-10 2024-05-16 株式会社デンソー 電子制御装置、書換えの実行制御方法及び書換えの実行制御プログラム
JP7024765B2 (ja) 2018-08-10 2022-02-24 株式会社デンソー 車両用マスタ装置、更新データの配信制御方法及び更新データの配信制御プログラム
JP7156192B2 (ja) 2018-08-10 2022-10-19 株式会社デンソー 車両用マスタ装置、非書換え対象の電源管理方法及び非書換え対象の電源管理プログラム
DE112019005132T5 (de) * 2018-12-07 2021-10-07 Robert Bosch Gesellschaft mit beschränkter Haftung Simultanes testen, ob mehrere über ein kommunikationsnetzwerk verbundene elektronische vorrichtungen ausnahmen korrekt behandeln
JP7514890B2 (ja) 2021-12-22 2024-07-11 本田技研工業株式会社 車両通信システム
CN118435567A (zh) * 2021-12-23 2024-08-02 日立安斯泰莫株式会社 传输装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013052833A (ja) * 2011-09-06 2013-03-21 Denso Corp 車載ネットワークシステム
JP2013074377A (ja) * 2011-09-27 2013-04-22 Denso Corp 車両用電子制御装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013052833A (ja) * 2011-09-06 2013-03-21 Denso Corp 車載ネットワークシステム
JP2013074377A (ja) * 2011-09-27 2013-04-22 Denso Corp 車両用電子制御装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615105A (zh) * 2022-04-02 2022-06-10 深圳市元征科技股份有限公司 数据传输方法、装置、电子设备、系统及存储介质
CN114615105B (zh) * 2022-04-02 2024-04-02 深圳市元征科技股份有限公司 数据传输方法、装置、电子设备、系统及存储介质
CN115102803A (zh) * 2022-06-22 2022-09-23 重庆长安新能源汽车科技有限公司 一种can通讯多帧传输方法、ecu
WO2024082907A1 (zh) * 2022-10-20 2024-04-25 思瑞浦微电子科技(上海)有限责任公司 一种拓扑网络及通信处理方法

Also Published As

Publication number Publication date
JP2016032274A (ja) 2016-03-07

Similar Documents

Publication Publication Date Title
WO2016017088A1 (ja) ゲートウェイ装置
JP5949416B2 (ja) 中継装置
JP5423736B2 (ja) ゲートウェイ装置
WO2014057643A1 (ja) 中継装置
JP6500123B2 (ja) 車載ゲートウェイ装置、及び車載ネットワークシステム
RU2015138478A (ru) Модуль связи для производственно-технологической сети
JP5050653B2 (ja) 電子制御装置
JP2008219555A (ja) 車載用の中継接続ユニット
JP2009253557A (ja) 車載用の中継接続ユニット
JP7133022B2 (ja) 車載通信装置及び車載システム
JP2007036907A (ja) ゲートウェイ装置
JPH05160842A (ja) 多重通信制御装置
US10176128B2 (en) Communication system for inter-chip communication
JP6200779B2 (ja) 通信制御装置
JP6569547B2 (ja) 通信方法
JP2006253922A (ja) ゲートウェイ装置及びゲートウェイ装置におけるデータ転送方法
JP2007104232A (ja) 通信ネットワークシステム及び通信端末装置
JP2009135567A (ja) データ転送装置
JP6137033B2 (ja) 車載ネットワークシステム及び車載中継装置
JP4361540B2 (ja) ゲートウェイ装置、データ転送方法及びプログラム
JP6183281B2 (ja) 通信システムおよび電子制御装置
JP6903843B2 (ja) ノード
JP2006319670A (ja) 通信システム及び中継装置
US20160227159A1 (en) Method for transmitting device indicator data in network-based av system
JP7277206B2 (ja) 通信制御装置および方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15826999

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15826999

Country of ref document: EP

Kind code of ref document: A1