车辆诊断装置

1.一种车辆诊断装置（12），该车辆诊断装置（12）用于从车辆（14）外部与安装在该车辆（14）上的电子控制单元（40）进行通信并且基于从该电子控制单元（40）发送的各种数据来确定该车辆（14）是否通过了多个诊断项，该车辆诊断装置（12）包括：
用于执行第一诊断程序的第一诊断单元；
用于执行不同于第一诊断程序的第二诊断程序的第二诊断单元；和
用于与该电子控制单元（40）进行通信的通信单元；
其中，在该通信单元从第一诊断单元接收到请求该电子控制单元（40）发送第一数据的请求之后，当该通信单元从第二诊断单元接收到请求该电子控制单元（40）发送第二数据的请求时，
如果第一数据和第二数据的类型相同，则该通信单元请求该电子控制单元（40）发送该相同类型的数据，并且向第一诊断单元和第二诊断单元发送从该电子控制单元（40）接收到的该相同类型的数据，而
如果第一数据和第二数据的类型不同，则该通信单元请求该电子控制单元（40）发送第一数据和第二数据，从该电子控制单元（40）一起接收第一数据和第二数据，向第一诊断单元发送所接收的第一数据，并且向第二诊断单元发送所接收的第二数据。
2.根据权利要求1所述的车辆诊断装置（12），其中，在所述通信单元从第一诊断单元接收到请求所述电子控制单元（40）发送第一数据的请求之后，当所述通信单元没有在预定时段内从第二诊断单元接收到请求所述电子控制单元（40）发送第二数据的请求时，所述通信单元请求所述电子控制单元（40）发送第一数据，并且
在接收到第一数据之后，当所述通信单元从第二诊断单元接收到请求所述电子控制单元（40）发送第二数据的请求时，所述通信单元请求所述电子控制单元（40）发送第二数据。
3.根据权利要求1所述的车辆诊断装置（12），其中，第一数据和第二数据的类型相同，在所述通信单元从第一诊断单元接收到请求所述电子控制单元（40）发送第一数据的请求之后，当所述通信单元没有在预定时段内从第二诊断单元接收到请求所述电子控制单元（40）发送第二数据的请求时，所述通信单元请求所述电子控制单元（40）发送第一数据；
并且
在请求所述电子控制单元（40）发送第一数据之后、接收到第一数据之前，当所述通信单元从第二诊断单元接收到请求所述电子控制单元（40）发送第二数据的请求时，所述通信单元在接收到第一数据之后向第一诊断单元和第二诊断单元发送第一数据。
4.根据权利要求1所述的车辆诊断装置（12），其中，第一数据和第二数据的类型不同；
在所述通信单元从第一诊断单元接收到请求所述电子控制单元（40）发送第一数据的请求之后，当所述通信单元没有在预定时段内从第二诊断单元接收到请求所述电子控制单元（40）发送第二数据的请求时，所述通信单元请求所述电子控制单元（40）发送第一数据及第二数据；并且
在请求所述电子控制单元（40）发送第一数据及第二数据之后、接收到第一数据及第二数据之前，当所述通信单元从第二诊断单元接收到请求所述电子控制单元（40）发送第二数据的请求时，所述通信单元在接收到第一数据及第二数据之后向第一诊断单元发送第一数据并向第二诊断单元发送第二数据。

车辆诊断装置\n技术领域\n[0001] 本发明涉及一种车辆诊断装置，其用于从车辆外部与安装在车辆上的电子控制单元进行通信并基于从电子控制单元发送的各种数据来确定车辆是否通过了多个诊断项。\n背景技术\n[0002] 在制造其中安装有电子控制单元(ECU)的车辆时，在组装车辆之后，在最终的检查处理中对它们进行诊断以检查与之电连接的ECU和各种设备是正确地工作。通过与位于车辆外部并且连接到车辆中的ECU的车辆诊断装置(测试器)进行通信来执行这种对车辆的诊断处理(例如参见日本特开专利公报No.2000-121684(以下称作JP 2000-121684 A)和日本特开专利公报09-210865(以下称作JP 09-210865 A))。\n[0003] 根据JP 2000-121684 A，为了使所公开的检查系统缩短它的检查时间，将ECU(10)检测到的数据临时存储在RAM(23)中然后一起输出到检查测试器(100)(参见JP \n2000-121684 A的摘要)。更具体来讲，根据JP 2000-121684 A，检查系统响应于从检查测试器发送到ECU的通信请求而进入检查模式(参见段落[0017])，并且ECU在RAM中存储各种数据(参见段落[0028]、[0030]到[0032])。响应于来自检查测试器的通信请求，将RAM中存储的数据从ECU发送到检查测试器(参见段落[0039]、[0043])。\n[0004] 根据JP 2000-121684 A，如上所述，响应于来自检查测试器的通信请求，ECU将要检查的数据发送到检查测试器。然而，来自检查测试器的通信请求仅对于使检查系统进入检查模式而言有效(参见段落[0017])，但是不能请求ECU发送任何特定的检测数据(detected data)。\n[0005] 因此，在检查测试器要执行彼此同时发生的多个诊断程序并且每个诊断程序都要从ECU获取检测数据的情况下，JP 2000-121684 A中公开的检查系统就不适用了。\n[0006] JP 2000-121684 A中公开的检查系统被设计为将RAM中存储的检测数据从ECU发送到检查测试器，即，在将检测数据从ECU发送到检查测试器时减少通信负载。然而，所公开的检查系统没有考虑在将数据从检查测试器发送到ECU时减少通信负载的任何尝试。\n发明内容\n[0007] 本发明的一个目的是提供一种车辆诊断装置，其即使在多个诊断程序请求电子控制单元发送数据时也能够减少车辆诊断装置和电子控制单元所需要的通信负载。\n[0008] 本发明提供了一种车辆诊断装置，其用于从车辆外部与安装在车辆上的电子控制单元进行通信并基于从电子控制单元发送的各种数据来确定车辆是否通过了多个诊断项，该车辆诊断装置包括用于执行第一诊断程序的第一诊断单元、用于执行不同于第一诊断程序的第二诊断程序的第二诊断单元，和用于与电子控制单元进行通信的通信单元，其中在通信单元从第一诊断单元接收到了请求电子控制单元发送第一数据的请求之后，当通信单元从第一诊断单元接收到请求电子控制单元发送第二数据的请求时，如果第一数据和第二数据的类型相同，则通信单元请求电子控制单元发送相同类型的数据，并且向第一诊断单元和第二诊断单元发送从电子控制单元接收的相同类型的数据，而如果第一数据和第二数据的类型不同，则通信单元请求电子控制单元发送第一数据和第二数据，从电子控制单元一起接收第一数据和第二数据，向第一诊断单元发送所接收的第一数据，并且向第二诊断单元发送所接收的第二数据。\n[0009] 使用上面的配置，当车辆诊断装置执行的诊断程序从电子控制单元请求数据时，这些数据请求可以同时被一起发送到电子控制单元，并且可以同时从电子控制单元接收数据。因此，相比于诊断程序从电子控制单元分别请求数据的情况，该车辆诊断装置和电子控制单元上的通信负载可以更小并且处理序列可以执行得更有效率。\n[0010] 在通信单元从第一诊断单元接收到了请求电子控制单元发送第一数据的请求之后，当通信单元没有在预定时段内从第二诊断单元接收到请求电子控制单元发送第二数据的请求时，通信单元可以请求电子控制单元发送第一数据，并且在接收到第一数据之后，当通信单元从第二诊断单元接收到请求电子控制单元发送第二数据的请求时，通信单元可以请求电子控制单元发送第二数据。因此，如果在接收到第一数据之前没有对于第二数据的请求，则与第一数据分离地请求第二数据，从而防止数据请求之间的间隔过长，并且第一数据和第二数据保持为最新。\n[0011] 如果第一数据和第二数据的类型相同，则在通信单元从第一诊断单元接收到了请求电子控制单元发送第一数据的请求之后，当通信单元没有在预定时段内从第二诊断单元接收到请求电子控制单元发送第二数据的请求时，通信单元可以请求电子控制单元发送第一数据，并且在请求电子控制单元发送第一数据之后和在接收到第一数据之前，当通信单元从第二诊断单元接收到请求电子控制单元发送第二数据的请求时，通信单元可以在接收到第一数据之后向第一诊断单元和第二诊断单元发送第一数据。因此，数据可以快速地被发送到第二诊断单元，并且可以减少车辆诊断装置和电子单元上的通信负载。\n[0012] 如果第一数据和第二数据的类型不同，则在通信单元从第一诊断单元接收到了请求电子控制单元发送第一数据的请求之后，当通信单元没有在预定时段内从第二诊断单元接收到请求电子控制单元发送第二数据的请求时，通信单元可以请求电子控制单元发送第一数据和第二数据，并且在请求电子控制单元发送第一数据和第二数据之后和接收到第一数据和第二数据之前，当通信单元从第二诊断单元接收到请求电子控制单元发送第二数据的请求时，通信单元可以在接收到第一数据和第二数据之后向第一诊断单元发送第一数据并向第二诊断单元发送第二数据。因此，数据可以快速地被发送到第二诊断单元，并且可以减少车辆诊断装置和电子单元上的通信负载。\n[0013] 结合附图阅读以下说明书后，本发明的上面和其它目的、特征、和优点将变得更加明显，附图中以例示的方式示出了本发明的优选实施方式。\n附图说明\n[0014] 图1是根据本发明实施方式的具有作为车辆诊断装置的测试器的车辆诊断系统的框图；\n[0015] 图2是根据该实施方式由测试器的CPU执行的驾驶员软件程序的处理序列的流程图；\n[0016] 图3是示出根据比较例的驾驶员软件程序的处理序列的示例的说明图；\n[0017] 图4是根据该实施方式的示出驾驶员软件程序的处理序列的第一示例的说明图；\n[0018] 图5是根据该实施方式示出驾驶员软件程序的处理序列的第二示例的说明图；\n[0019] 图6是示出图4中示出的处理序列的第一示例的第一变型的说明图；\n[0020] 图7是示出图4中示出的处理序列的第一示例的第二变型的说明图；\n[0021] 图8是图2中示出的处理序列的第一变型的流程图；\n[0022] 图9是图2中示出的处理序列的第二变型的流程图；\n[0023] 图10是示出实现图9中示出的第二变型的驾驶员软件程序的处理序列的示例的说明图。\n具体实施方式\n[0024] [根据本发明实施方式的车辆诊断装置的构造]\n[0025] 图1以框图的形式示出了根据本发明实施方式的具有作为车辆诊断装置的测试器12的车辆诊断系统10。如图1中所示，除了测试器12以外，车辆诊断系统10还包括要以各种方式由测试器12诊断的车辆14和主机计算机16。尽管图1中未示出，但是车辆诊断系统10包括测试器12和车辆14的多种组合。在每种组合中，测试器12和车辆14都通过线缆18相互连接，以便在它们之间进行通信。测试器12可以经由无线链路与主机计算机16进行通信。\n[0026] 测试器12包括输入单元20、显示单元22、扬声器24、中央处理器(CPU：第一诊断单元、第二诊断单元、通信单元)26、只读存储器(ROM)28、随机存取存储器(RAM)30、通信接口32和连接器34。\n[0027] 车辆14包括电子控制单元(ECU)40、点火开关(IGSW)42、引擎机44和引擎转速传感器(NE传感器)46。ECU 40包括中央处理器(CPU)50、只读存储器(ROM)52、随机存取存储器(RAM)54、通信接口56和连接器58。\n[0028] 测试器12的ROM 28中存储了多个用于各种检查的检查程序，和用于管理从检查程序到ECU 40的数据请求的驾驶员软件程序。检查程序和驾驶员软件程序由测试器12的CPU 26来执行。驾驶员软件程序可以是与CAN(控制器区域网络)或KWP2000一起使用的程序。\n[0029] 主机计算机16从测试器12获取车辆14的诊断数据，并将所获取的诊断数据存储为数据库。\n[0030] 车辆诊断系统10的基本构造可以与JP 09-210865 A中示出的相同。\n[0031] [驾驶员软件程序的处理序列]\n[0032] 图2是根据本实施方式的由测试器12的CPU 26执行的驾驶员软件程序的处理序列的流程图。图2中示出的处理序列的步骤S1到S4表示了由测试器12的CPU 26向车辆\n14的ECU 40请求数据的处理(数据请求处理)，而其步骤S5、S6表示了由CPU 26从ECU \n40接收数据的处理(数据接收处理)。例如，步骤S1到S6在从几十纳秒到几十微秒的时段内执行并且重复许多次。\n[0033] 在步骤S1中，测试器12的CPU 26(驾驶员软件程序)从每个检查程序接收针对车辆14的ECU 40的数据请求。根据驾驶员软件程序，所接收的数据请求连同已经发送了数据请求的检查程序的标识符一起被临时存储在RAM 30中。\n[0034] 在步骤S2中，CPU 26(驾驶员软件程序)确定计时器值TMR[μsec]是否大于等于阈值TH_TMR[μsec]。计时器值TMR由计时器(未示出)来计数，并且在图2中示出的处理序列开始之后立即随着时间而增大。根据本实施方式，阈值TH_TMR定义了CPU 26向ECU 40发送数据请求的时段(数据请求时段)，并且是一个固定值。\n[0035] 如果计时器值TMR并非大于等于阈值TH_TMR(S2：否)，则控制跳到步骤S5。如果计时器值TMR大于等于阈值TH_TMR(S2：是)，则在步骤S3中CPU 26(驾驶员软件程序)将在当前数据请求时段中从每个检查程序接收的数据请求发送到车辆14的ECU 40。此时，数据请求被临时地存储在RAM 30中并且已经发送了数据请求的检查程序的标识符仍然存储在RAM 30中。在步骤S4中，CPU 26(驾驶员软件程序)重置计时器值TMR。\n[0036] 在步骤S5中，CPU 26(驾驶员软件程序)确认它是否从ECU 40接收到了数据。\n数据对应于先前数据请求时段中的数据请求。如果CPU 26从ECU 40接收到了数据(S5：\n是)，则在步骤S6中CPU 26(驾驶员软件程序)将所接收的数据发送给请求了该数据的检查程序(目标检查程序)。接收到该数据的检查程序基于所接收的数据来检查车辆14。如果CPU 26没有从ECU 40接收到数据(S5：否)，则CPU 26(驾驶员软件程序)结束图2中示出的处理序列。重复图2中示出的处理序列，直到每个检查程序都结束其检查处理为止。\n[0037] [本实施方式和比较例之间的比较]\n[0038] 图3是示出根据比较例的驾驶员软件程序的处理序列的示例的图。当任何一个检查程序发出数据请求时，根据该比较例的驾驶员软件程序立即向ECU 40发送数据请求(发送数据传输命令)，并且驾驶员软件程序在接收到对应于该数据请求的数据之前保持(hold)下一个数据请求。图4是示出根据该实施方式的驾驶员软件程序的处理序列的第一示例的图，图5是示出根据该实施方式的驾驶员软件程序的处理序列的第二示例的图。第一示例表示在某个数据请求时段中存在两个数据请求Rne1、Rne2的处理，第二示例表示在各个不同的数据请求时段中存在数据请求Rne1、Rne2的处理。\n[0039] 根据比较例，如图3中所示，当驾驶员软件程序(在图3以及图4到7和10中简单地描述为“驾驶员”)从检查程序1(在图3以及图4到7和10中简单地描述为“检查1”)接收到针对引擎转速NE[rpm]的数据请求Rne1时，驾驶员软件程序立即向ECU 40发送与数据请求Rne1相对应的数据传输命令Cne1。此后，即使根据比较例的驾驶员软件程序从检查程序2(在图3以及图4到7和10中简单地描述为“检查2”)接收到针对引擎转速NE的数据请求Rne2，驾驶员软件程序也不向ECU 40发送与数据请求Rne2相对应的数据传输命令Cne2，直到驾驶员软件程序接收和处理了与数据传输命令Cne1相对应的引擎转速Ne的数据Dne1为止。\n[0040] 当驾驶员软件程序接收到与数据传输命令Cne1相对应的引擎转速NE的数据Dne1时，驾驶员软件程序向检查程序1发送数据Dne1。此后，根据比较例的驾驶员软件程序向ECU 40发送与已保存的数据请求Rne2相对应的数据传输命令Cne2。当驾驶员软件程序接收到与数据传输命令Cne2相对应的引擎转速NE的数据Dne2时，驾驶员软件程序向检查程序2发送数据Dne2。\n[0041] 根据图3中示出的比较例，如上所述，即使驾驶员软件程序从检查程序2接收到了数据请求Rne2，它也会保持数据传输命令Cne2，直到它接收和处理了数据Dne1为止。因此，对数据请求Rne2的处理被延迟了。而且，测试器12向ECU 40发送了两个数据传输命令，并且ECU 40向测试器12发送了两次数据。\n[0042] 根据图4中示出的本实施方式，即使驾驶员软件程序从检查程序1接收到了数据请求Rne1，驾驶员软件程序也还在同一数据请求时段中接收到了其它数据请求。更具体来讲，在图4中，驾驶员软件程序在与从检查程序1接收到数据请求Rne1相同的数据请求时段中从检查程序2接收到了数据请求Rne2。然后，驾驶员软件程序从测试器12向ECU 40发送与数据请求Rne1、Rne2两者相对应的数据传输命令Cne。\n[0043] 当根据本实施方式的驾驶员软件程序接收到与数据传输命令Cne相对应的引擎转速NE的数据Dne时，驾驶员软件程序向检查程序1、2两者发送所接收的数据Dne。\n[0044] 如图5中所示，在根据本实施方式的驾驶员软件程序从检查程序1接收到数据请求Rne1之后，如果它在同一数据请求时段中没有接收到其它数据请求，则它发送仅与数据请求Rne1相对应的数据传输命令Cne1。当驾驶员软件程序响应于来自ECU 40的数据传输命令Cne1而接收到数据Dne1时，它向检查程序1发送所接收的数据Dne1。\n[0045] 然后，当驾驶员软件程序在另一个数据请求时段中接收到另一个数据请求Rne2时，它向ECU 40发送不同于数据传输命令Cne1的数据传输命令Cne2。当驾驶员软件程序响应于来自ECU 40的数据传输命令Cne2而接收到数据Dne2时，它向检查程序2发送所接收的数据Dne2。\n[0046] 根据图4中示出的本实施方式的第一示例，驾驶员软件程序将数据请求Rne1、Rne2一起作为数据传输命令Cne从测试器12发生给CPU 40。ECU 40响应于数据传输命令Cne向测试器12发送数据Dne。因此，数据处理Rne2的处理被加速。驾驶员软件程序从测试器12向ECU 40发送了一个数据传输命令，并且从ECU 40向测试器12发送了一次数据。\n因此，减少了测试器12和ECU 40上的通信负载，并且使得测试器12和ECU 40执行的处理有效率。\n[0047] 根据图5中示出的本实施方式的第二示例，如果在与数据请求Rne1相同的数据请求时段中没有接收到数据请求Rne2，而是在随后的数据请求时段中接收到了数据请求Rne2，则驾驶员软件程序分离地发送与数据请求Rne1相对应的数据传输命令Cne1和与数据请求Rne2相对应的数据传输命令Cne2。因此，防止了数据传输命令之间的间隔变得过大，并且数据Dne1、Dne2保持为最新。\n[0048] [本实施方式的优点]\n[0049] 根据图4中示出的本实施方式的第一示例，如上所述，当测试器12执行的检查程序1、2都向ECU 40请求引擎转速NE的数据时，驾驶员软件程序可以同时向ECU 40发送数据传输命令Cne并同时从ECU 40接收数据。因此，相比于检查程序1、2分别向ECU 40发送各个请求来发送引擎转速NE的数据的情况，测试器12和ECU 40上的通信负载变得更小，测试器12和ECU 40执行的处理变得更加有效率。尽管测试器12和ECU 40之间的通信处理可用的标准有多种，例如CAN、KWP2000等，但是因为驾驶员软件程序执行上面的处理序列，所以不管使用了什么通信处理标准和通信速率，本发明的原理都是适用的。\n[0050] 根据图5中所示的本实施方式的第二示例，如上所述，如果已经从检查程序1接收到数据请求Rne1的测试器12的CPU 26(驾驶员软件程序)在与数据请求Rne1相同的数据请求时段中没有从检查程序2接收到数据请求Rne2，则CPU 26(驾驶员软件程序)向ECU \n40发送与数据请求Rne1相对应的数据传输命令Cne1，然后向ECU 40发送与数据请求Rne2相对应的数据传输命令Cne2。如果在与数据请求Rne1相同的数据请求时段中未接收到数据请求Rne2，而是在随后的数据请求时段中接收到数据请求Rne2，则CPU 26(驾驶员软件程序)分离地发送与数据请求Rne1相对应的数据传输命令Cne1和与数据请求Rne2相对应的数据传输命令Cne2。因此，防止了数据传输命令之间的间隔变得过长，并且数据Dne1、Dne2保持为最新。\n[0051] [变型]\n[0052] 本发明不限于上面的实施方式，而是可以在本发明的范围内做出各种变型和修改。下面将描述这些变型和修改的示例。\n[0053] 在上面的实施方式中(图4和5)描述了来自两个检查程序1、2的数据请求Rne1、Rne2。然而，如图6中所示，可以处理来自三个或更多个检查程序1、2、...、n的数据请求Rne1、Rne2、...、Rnen。\n[0054] 在上面的实施方式中，数据请求Rne1、Rne2均请求引擎转速NE的数据。然而，如图7中所示，CPU 26(驾驶员软件程序)可以接收请求引擎转速NE的数据请求Rne和针对水温Tw[℃]的数据请求Rtw，并且从测试器12向ECU 40发送与数据请求Rne、Rtw两者相对应的数据传输命令Cd。\n[0055] 在上面的实施方式中，执行了图2中示出的处理序列。然而，可以如图8中所示来执行处理序列的第一变型。根据第一变型，数据请求时段不是以恒定间隔来提供的，而是在第一数据请求之后的给定时刻(阈值TH_THR2)接收到另外的数据请求。在图8中示出的第一变型中，例如，步骤S11到S19在从几十纳秒到几十微秒的时段中执行并且重复许多次。\n[0056] 在步骤S11中，测试器12的CPU 26(驾驶员软件程序)确定它是否从任何一个检查程序接收到了数据请求。如果CPU 26(驾驶员软件程序)接收到了数据请求(S11：是)，则控制到达步骤S12。如果CPU 26(驾驶员软件程序)没有接收到数据请求(S11：否)，则控制跳到步骤S17。\n[0057] 在步骤S12中，CPU 26(驾驶员软件程序)开始对计时器值TMR2[μsec]计数。\n计时器值TMR2由计时器(未示出)来计数，并且从步骤S12开始随着时间增大。当在步骤S16中进行重置时，计时器值TMR2停止增大。\n[0058] 在步骤S13中，CPU 26(驾驶员软件程序)从检查程序接收数据请求。具体来讲，CPU 26(驾驶员软件程序)从包括已经在步骤S11中发送了数据请求的检查程序在内的检查程序接收另外的数据请求。已经在步骤S11中发送了数据请求的检查程序是包括在步骤S13中的检查程序中的，因为已经在步骤S11中发送了数据请求的检查程序可以有不同类型的数据请求要发送。\n[0059] 在步骤S14中，CPU 26(驾驶员软件程序)确定计时器值TMR2是否大于等于阈值TH_TMR2。阈值TH_TMR2对应于根据上面实施方式的数据请求时段，但是与数据请求时段的不同在于，它定义了从第一数据请求或者在数据传输命令已经发送到ECU 40之后从第一数据请求开始的时段(以下，两个数据请求都将被称为“第一数据请求”)。如果计时器值TMR2大于等于阈值TH_TMR2(S14：是)，则控制到达步骤S15。如果计时器值TMR2不大于等于阈值TH_TMR2(S14：否)，则控制跳到步骤S17。\n[0060] 在步骤S15中，CPU 26(驾驶员软件程序)向ECU 40发送与步骤S11、S13中接收到的所有数据请求相对应的数据传输命令。在步骤S16中，CPU 26(驾驶员软件程序)重置计时器值TMR2并将它保持为零。CPU 26(驾驶员软件程序)将计时器值TMR2保持为零，直到在下一次循环中控制经过步骤S12为止。因此，计时器值TMR2可以保持为零，直到在CPU \n26(驾驶员软件程序)向ECU 40发送了数据传输命令之后接收到了第一数据请求为止。\n[0061] 步骤S17、S18与图2中示出的步骤S5、S6相同。\n[0062] 在步骤S19中，CPU 26(驾驶员软件程序)确定计时器值TMR2是否为零。如果计时器值TMR2不为零(S19：否)，则意味着计时器TMR2已经在步骤S12中开始被计数，而还没有在步骤S16中被重置。因此，CPU 26(驾驶员软件程序)在步骤S14中并非处于“是”的状态，即，在重复步骤S13和步骤S14时CPU 26处于接收另外的数据请求的状态(否)。\n为了接收另外的数据请求，控制返回到步骤S13。如果计时器值TMR2为零(S19：是)，则意味着CPU 26(驾驶员软件程序)正在接收第一数据请求。因此，图8中示出的处理序列结束。重复图8中示出的处理序列，直到每个检查程序都结束它的检查处理为止。\n[0063] 根据第一变型，接收另外的数据请求的时段是从第一数据请求开始的。因此，当第一数据请求和另外的数据请求在时间上相互靠近时，能够可靠地向ECU 40发送与两个数据请求相对应的数据传输命令。\n[0064] 图9是图2中示出的处理序列的第二变型的流程图，其可以用于代替图8中示出的第一实施方式。第二变型与图2中示出的处理序列基本上相同，但是不同在于，在与某个数据请求(第一数据请求)相对应的数据传输命令刚从测试器12发送到ECU 40之后，当存在请求与第一数据请求所请求的数据类型相同的数据的数据请求(第二数据请求)时，将与第一数据请求相对应的数据(第一数据)沿用(divert)为响应于第二数据请求的数据。在图9中示出的第二变型中，例如，步骤S21到S28在从几十纳秒到几十微秒的时段中执行并且重复许多次。\n[0065] 图10是示出实现图9中示出的第二变型的驾驶员软件程序的处理序列的示例的图。\n[0066] 图9中示出的步骤S21到S25与图2中示出的步骤S1到S5相同。如果没有从ECU 40接收到数据(S25：否)，则本次循环结束，并且控制返回步骤S21。如果从ECU 40接收到了数据(S25：是)，则控制到达步骤S26。\n[0067] 在步骤S26中，CPU 26(驾驶员软件程序)确定从ECU 40接收的数据是否可以沿用。术语“沿用”意味着，在与某个数据请求(图10中的第一数据请求Rne1)相对应的数据传输命令Cne1刚从测试器12发送到ECU 40之后，当存在请求与第一数据请求Rne1所请求的引擎转速NE相同的引擎转速NE的第二数据请求Rne2时，与第一数据请求Rne1相对应的数据(第一数据Dne1)被用作响应于第二数据请求Rne2的数据。\n[0068] 如果数据(图10中示出的第一数据Dne1)可以沿用(S26：是)，则在步骤S27中CPU 26(驾驶员软件程序)沿用数据并将数据发送到目标检查程序。例如，在图10中，CPU \n26(驾驶员软件程序)不向ECU 40发送与第二数据请求Rne2相对应的数据传输命令，而是向检查程序1、2发送第一数据Dne1。\n[0069] 如果数据(图10中示出的第一数据Dne1)不能沿用(S26：否)，则CPU 26(驾驶员软件程序)不沿用数据，而是在步骤S28中向目标检查程序发送数据。具体来讲，CPU \n26(驾驶员软件程序)将从ECU 40接收的数据仅发送到已经发送了数据传输命令Cne1所基于的数据请求的检查程序，即，在图10中，已经发送了第一数据请求Rne1的检查程序1。\n[0070] 在第二变型中，来自检查程序1的数据请求Rne1和来自检查程序2的数据请求Rne2都请求引擎转速NE的数据。在测试器12的CPU 26(驾驶员软件程序)从检查程序1接收到数据请求Rne1之后，如果在与数据请求Rne1相同的数据请求时段中CPU 26(驾驶员软件程序)没有从检查程序2接收到数据请求Rne2，则CPU 26(驾驶员软件程序)向ECU \n40发送与数据请求Rne1相对应的数据传输命令Cne1。在将数据传输命令Cne1发送到ECU \n40之后，当CPU 26(驾驶员软件程序)在响应于数据传输命令Cne1而接收数据Dne1之前从检查程序2接收到数据请求Rne2时，CPU 26(驾驶员软件程序)在接收到数据Dne1之后向检查程序1、2发送数据Dne1。因此，数据可以快速地发送到检查程序2，并且减少了测试器12和ECU 40上的通信负载。\n[0071] 图9中示出的第二变型可应用于针对不同类型数据的数据请求。例如，如果存在针对引擎转速NE和水温Tw中任何一个的数据请求，则CPU 26(驾驶员软件程序)向ECU \n40发送针对引擎转速NE和水温Tw两者的数据传输命令。当CPU 26(驾驶员软件程序)从ECU 40接收到引擎转速NE和水温Tw时，CPU 26(驾驶员软件程序)可以沿用引擎转速NE和水温Tw中的任何一个。\n[0072] 尽管已经详细示出和描述了本发明的优选实施方式，但是应当理解，可以在其中做出各种变化和修改，而不会偏离所附权利要求的范围。