CN103248514B - 用于车内lan网络管理的故障检测和缓解 - Google Patents
用于车内lan网络管理的故障检测和缓解 Download PDFInfo
- Publication number
- CN103248514B CN103248514B CN201310046815.9A CN201310046815A CN103248514B CN 103248514 B CN103248514 B CN 103248514B CN 201310046815 A CN201310046815 A CN 201310046815A CN 103248514 B CN103248514 B CN 103248514B
- Authority
- CN
- China
- Prior art keywords
- communication
- activation
- virtual network
- ecu
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000004891 communication Methods 0.000 claims abstract description 170
- 230000004913 activation Effects 0.000 claims abstract description 100
- 238000000034 method Methods 0.000 claims abstract description 58
- 238000001514 detection method Methods 0.000 claims abstract description 19
- 230000004044 response Effects 0.000 claims description 33
- 230000003213 activating effect Effects 0.000 claims description 15
- 230000000116 mitigating effect Effects 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 9
- 230000005059 dormancy Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 5
- 238000012544 monitoring process Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000004888 barrier function Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000019771 cognition Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 239000010949 copper Substances 0.000 description 1
- 229910052802 copper Inorganic materials 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 235000013399 edible fruits Nutrition 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000007958 sleep Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000002618 waking effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40006—Architecture of a communication node
- H04L12/40039—Details regarding the setting of the power status of a node according to activity on the bus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0681—Configuration of triggering conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40267—Bus for use in transportation systems
- H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
Abstract
本发明涉及用于车内LAN网络管理的故障检测和缓解。一种检测和缓解车内通信网络的无意激活状态的方法。所述车内通信网络包括经过控制器局域网络总线系统通信的多个电子控制单元(ECU)。每个ECU都包括发射和接收能力,并且配置有提供用于与通信系统内的其它ECU交换信息的准则的通信协议。每个ECU都进入通信内核激活状态用于在总线上通信。识别所述通信系统内的虚拟网络。每个虚拟网络都包括一信号集合,该信号集合包括其发射和接收共同作为一个单元开始和停止的相应ECU。检测因故障激活的各虚拟网络。去激活各故障激活虚拟网络。
Description
技术领域
实施例总的涉及车内通信诊断。
背景技术
车内通信系统利用车辆的多路复用总线允许电子控制单元(ECU)及其它装置彼此通信。车辆系统和子系统具有控制致动器或从感测装置接收车辆操作数据的多个ECU,该数据在通信ECU之间共享。
通信协议是在网络内通信装置之中或之间交换这些信息的数字信息格式和规则的系统。车内通信系统包括发射节点、至少一个接收节点、以及将所述发射节点连接至所述至少一个接收节点的网络通信总线。所述发射节点及所述至少一个接收节点中的每个都包括用于服务车内通信系统中各节点内的信息的多个通信层。所述多个通信层通常通过提供如何格式化信息及如何交换信息的规则来控制信息传输。
通信网络当通信正在进行时通常是激活的(即,被供电的),当在通信总线上没有通信在传输时是非激活的。当处于非激活状态时,通信网络进入休眠模式以节省电力。这通常发生在车辆关闭时。如果系统中出现在假定所有网络装置处于非激活之后网络保持激活的错误,那么由于系统被意外地供电,会发生不期望的电池消耗。
发明内容
故障检测和缓解系统的优点在于检测LAN通信网络内的无意激活通信,并缓解LAN通信网络内通信装置的电源中断,用以防止因无意激活通信网络内的装置引起的电池消耗。该检测和缓解系统检测激活的虚拟网络(VN)或激活的通信内核,并确定所述VN是否被无意地激活或所述通信内核是激活的而无激活的VN。如果该确定是存在无意的激活,那么LAN通信网络利用缓解技术以使激活装置断电。这样的缓解技术可包括通过主关闭线路强制关闭,或者如果确定所述主关闭路线故障无法去激活(即去除激活)所述通信网络则通过另一关闭路线强制关闭。
实施例构想了一种检测和缓解车内通信网络的无意激活状态的方法。所述车内通信网络包括经过控制器局域网络总线系统通信的多个电子控制单元(ECU)。每个ECU都包括发射和接收能力,并且配置有提供用于与通信系统内的其它ECU交换信息的准则的通信协议。每个ECU都进入通信内核激活状态用于在总线上通信。识别所述通信系统内的虚拟网络。每个虚拟网络都包括一信号集合,该信号集合包括其发射和接收共同作为一个单元开始和停止的相应ECU。检测因故障激活的各虚拟网络。去激活各故障激活虚拟网络。
本发明提供以下技术方案:
1. 一种检测和缓解车内通信网络的无意激活状态的方法,所述车内通信网络包括经过控制器局域网络总线系统通信的多个电子控制单元(ECU),每个ECU都包括发射和接收能力,并且配置有提供用于与通信系统内的其它ECU交换信息的准则的通信协议,每个ECU都进入通信内核激活状态用于在总线上通信,所述方法包括下列步骤:
识别所述通信系统内的虚拟网络,每个虚拟网络都包括一信号集合,该信号集合包括其发射和接收共同作为一个单元开始和停止的相应ECU;
检测因故障激活的各虚拟网络;以及
去激活各故障激活的虚拟网络。
2. 如方案1的方法,其中检测无意激活的虚拟网络还包括如下步骤:
检测激活的虚拟网络;
确定该虚拟网络不是网络激活的虚拟网络;
确定该激活的虚拟网络不是由本地ECU激活;以及
确定该激活的虚拟网络不是由本地应用程序激活。
3. 如方案2的方法,其中检测所述无意激活的虚拟网络还包括如下步骤:
确定所述虚拟网络不是共享输入激活的虚拟网络。
4. 如方案3的方法,其中检测所述无意激活的虚拟网络还包括如下步骤:
确定在预期时间段期间所述虚拟网络未接收到虚拟网络管理帧信息。
5. 如方案4的方法,其中所述预定时间段使用计时器测量,其中所述预定时间段基于所述计时器超时的次数。
6. 如方案5的方法,其中所述计时器被设定为8秒。
7. 如方案5的方法,其中所述计时器超时的次数为3。
8. 如方案4的方法,其中响应于确定有意的虚拟网络,在网络管理模块内设置至少两个比特位用于识别出所述激活的虚拟网络,其中设置至少两个比特位避免因单一位翻转情形引起的虚拟网络激活的错误报告。
9. 如方案1的方法,还包括向与所述激活虚拟网络相关的应用程序报告所述故障激活虚拟网络的步骤。
10. 如方案1的方法,还包括如下步骤:
检测所述通信网络内无激活虚拟网络;
检测所述通信网络内的激活通信内核;
响应于检测到激活的通信内核和检测到无激活虚拟网络,去激活所述通信网络内的所述激活通信内核。
11. 如方案10的方法,其中去激活所述激活通信内核还取决于确定当所述通信内核激活时预定时间段内无虚拟网络激活。
12. 如方案11的方法,其中所述预定时间段使用计时器测量,其中所述预定时间段基于所述计时器超时的次数。
13. 如方案12的方法,其中所述计时器功能被设定为8秒。
14. 如方案12的方法,其中所述计时器超时的次数为6。
15. 如方案12的方法,其中当没有虚拟网络激活时通信内核激活是由于错误的主关闭路线,其中去激活所述激活通信内核利用另一关闭路线来执行。
16. 如方案15的方法,还包括如下步骤:
确定与所述激活通信内核相关的应用程序是否确认关闭,其中响应于确定在第二预定时间段内所述另一关闭路线无法去激活所述激活通信内核而检测应用程序故障。
17. 如方案16的方法,其中所述第二预定时间段基于与所述激活通信内核相关的应用程序无法确认关闭的次数。
18. 如方案17的方法,其中响应于所述第二预定时间段内所述应用程序不确认关闭,并进一步响应于通信系统配置要求关闭是所述应用程序的责任,而通过与所述激活通信内核相关的应用程序去激活所述激活通信内核。
19. 如方案18的方法,其中响应于在所述第二预定时间段期满之后所述激活通信内核保持激活,并响应于通信系统配置需要通过所述另一关闭路线关闭,通过所述另一关闭路线去激活所述激活通信内核。
20. 如方案19的方法,其中响应于系统配置需要提供给所述应用程序的报告,向所述应用程序提供与所述应用程序不确认关闭相关的报告。
附图说明
图1为LAN网络通信系统的框图;
图2为LAN网络通信系统中用于故障检测和缓解对策的故障树的框图;
图3a为LAN网络监测模块的故障检测和缓解技术的流程图;
图3b为LAN网络监测模块的故障检测和缓解技术的流程图。
具体实施方式
图1中示出示例性LAN网络通信系统10。该LAN网络通信系统10包括连接至至少一个通信总线20的多个电子控制单元(ECU)12-18,所述通信总线20允许ECU彼此通信。在另一示例性LAN网络通信系统10中,可具有三类通信总线:低速总线、中速总线和高速总线。所述总线利用控制器局域网络(CAN)通信协议。
高速总线通常用于共享实时数据,包括但不限于,驾驶员指令扭矩数据、实际发动机扭矩数据、转向角数据。
中速总线通常用于信息娱乐应用,例如显示器、电话和导航装置,其中系统响应时间需要在相对短的时间内传递大量的数据。
低速总线通常用于操作员控制的功能,其中系统响应时间需求大约为100-200ms。
所述多个ECU 12-18中的每个都连接至一个或多个传感器、致动器或控制装置(例如,应用部件)。应用部件并不直接连接至通信总线20,而是通过各自的ECU连接。应用部件也可为ECU中的软件部件。单个控制特征可跨越多个应用组件,并包括通过连接至相同通信总线的一个或多个中间处理/控制ECU从源到目标ECU的控制信息。为本发明的目的,应理解这样的系统是本领域已知的,并且ECU、应用装置、控制器和收发器被称为节点,其构成的细节本文并不详细描述。另外,可使用网关在不同总线之间建立通信接入点。
每个节点都包括用于服务从其它节点接收到的或准备发送至其它节点的信息的多个通信层。各ECU的多个通信层包括应用层22、交互层24、网络层26、数据链层28、物理层30、节点管理层32和网络管理层34。多个通信层中的每个都提供了用于服务信息的功能。
应用层22与用于实施通信装置的各自软件应用相交互。应用层22识别这样的通信实体:用于确定其身份;用于确定资源可用性,包括确定是否存在通信网络;和用于同步需要合作通信的应用之间的通信。
交互层24用作应用程序接口。交互层24独立于总线协议向应用提供通信服务,并使用用于在通信网络上通信的传输层的服务。
网络层26使用数据链层28的服务传输数据包。网络层26提供未确认的传输服务。网络层26还提供连接设置和流量控制。
数据链层28提供车内通信网络中各ECU之间传输数据的功能和程序过程、协议及规范。
物理层30提供用于将由数据链层产生的数字数据符号(1和0)转换为在通信媒介上传输的电子信号。物理层阐明了通信装置的电子和物理硬件及规范。物理层定义了传输模式(例如,光纤、铜缆)、连接器类型、连接器形状、电气引脚配置、电压、线缆规范、网络适配器和总线适配器。
节点管理层32被节点用于控制节点的启动、关闭和错误处理,这些功能并不包括与网络的其它节点的交互,因此可被局部地管理。
网络管理层34用于控制节点网络的启动、关闭和错误处理,这些功能包括节点之间的交互,因此必须被全局地管理。
节点管理层32和网络管理层34与应用层22交互用于控制网络上ECU的启动和关闭。节点和网络管理进一步负责通信内核的启动和关闭、从节点检测到的通信错误条件恢复、和管理特殊应用控制的通信模式。不期望的电池消耗会由这样的条件导致:假定LAN通信网络通过整个网络ECU是未激活的之后,LAN通信网络保持激活。存储器错误,例如位翻转、卡位或通信信息错误(例如,信息的重复或遗失)只是其中操作状态应当未激活但保持激活的失配的可能原因中的一些。本文所述技术为上面的错误情形提供了用于LAN网络管理的故障检测和缓解。
LAN网络管理基于ECU参与网络的功能激活/未激活标准来启用/禁用要被传输、接收以及错误管理的信号(帧)的收集。LAN网络管理允许网络ECU的子集通过所谓“虚拟网络”(VN)的概念通信,该虚拟网络执行车辆控制操作,同时其它网络ECU通过使它们的通信能力未激活而保持在低功率状态。VN定义为仅含有其传输和接收作为一个单位开始和停止的的那些ECU的信号的集合。
由于ECU加电、ECU重置、总线唤醒信息的接收、或来自节点本地应用的虚拟网络(VN)激活请求,启用通信内核。在ECU加电或ECU重置之后,ECU初始化其通信能力(例如,通信内核),并保持在能够通信状态至少8秒。不管ECU是否检测到要求其通信的本地情形,都执行通信内核至少8秒的激活。如此执行,所以ECU可监测通信总线的网络管理信息,所述网络管理信息指示其它ECU是否要求其通信,以支持要求其它ECU执行的控制操作。
LAN通信网络允许一些ECU停留在其通信能力未激活的低功率状态,同时其它ECU激活地通信以执行车辆控制操作。激活在分布的一组ECU上的通信是网络管理层的责任,并且其基于形成 VN以执行具体控制操作的ECU的集合。通常,ECU检测需要开始一些控制操作从而需要激活适当VN的情形。对于ECU通知其它ECU需要它们的参与,它必须首先启动它自己的通信内核,然后使总线上的其它ECU启动它们的通信内核。然后所有ECU必须都保持它们的通信内核激活预定量时间(例如,8秒),使得可传输网络信息。这些消息允许ECU确定它们是否被请求参与到VN中。形成VN的ECU保持它们的通信内核激活,并开始通信控制信息。当没有VN需要与其它ECU共享数据时,ECU内的通信内核将关闭。在预定量时间之后,如果其它ECU没有其它控制任务,可关闭它们的通信内核,并回复到低功率状态。不再需要通信的决定由网络管理基于虚拟网络的本地和远程需求做出。一旦做出不再需要通信的决定,就请求包含在通信中的应用程序确认通信内核的关闭。响应于该应用程序的确认,与ECU相关的通信内核被关闭。
如前所述,分布的一组ECU的VN的激活和未激活由网络管理控制。在激活VN之前,各自的ECU必须首先过渡至允许激活或未激活的状态(即,ECU可通过通信信息主动地参与到车辆控制的状态)。这称作通信激活状态(即,Comm_Kernel_Active状态的Comm_Active子状态)。仅在ECU处于ECUComm_Kernel_Active状态时,ECU内核可激活。各自的ECU内核必须最少检测总线唤醒广播、起动VN的服务应用请求、在接收总线唤醒或请求VN时起动通信内核、并在应用程序确认不再需要通信能力时关闭通信内核。
当本地ECU应用程序请求本地VN激活或者通过从远程ECU接收到虚拟网络管理帧(VNMF)而指示远程VN激活时,可进入Comm_Active 状态。VNMF消息是由远程ECU传输的总线可见消息,以发送VN激活请求至其它网络ECU,以便参与到VN中。在本地和远程VN激活都被取消之后,退出Comm_Active状态,并且所有激活的VN都变得未激活至少预定时间段(例如,8秒)。
为了进入通信状态,激活的ECU(其检测到给定的控制操作应当开始)还负责启动使能所有必要通信的VN。在进入Comm_Active之后,激活的ECU会广播总线唤醒信号,引起其它ECU激活它们的通信内核。总线唤醒信号被激活的ECU广播,引起在同一子网上的全部ECU初始化它们的通信内核。
广播唤醒信号的激活ECU还广播VNMF消息,其通知其它ECU要初始化哪个VN。配置成参与VN的ECU将开始通信,并且只要在各自预定时间段内各自的VNMF被连续地接收从而指示VN是激活的,就继续通信。如果ECU接收指示VN应当未激活的VNMF消息或者在预定时间段内ECU不再接收VNMF消息时,那么所有ECU都必须关闭VN(即,VN变得未激活)。
发射用于激活和继续VN的VNMF消息的ECN称为VN的激活主体。VN激活主体必须周期性地发射它们的VNMF消息,以保持VN激活。当VN激活主体不再需要通信来控制或接收应用数据时,激活主体将去激活VNMF消息中的VN比特。该比特通过VNMF消息向所有其它网络ECU提供通知,关闭VN是可接受的。在所有网络ECU接收到表示VN要被去激活的VNMF消息并且不再接收额外的VNMF消息之后,VN应被认为去激活。
VN如何进行启动和关闭具有三种变化:最常见的过程包括激活的ECU广播总线唤醒信号,以引起其它ECU激活它们的通信内核。这类VN称为网络激活的VN。激活的ECU发射通知其它ECN初始化哪个VN的VNMF消息。只要接收到VNMF消息,那么被配置成参与VN对话的ECU就将继续通信。包含在VN中的由ECU接收的VNMF消息指示,VN对话应当保持激活。如果没有这样的VNMF被发射/接收8秒,那么所有的ECU关闭VN。
如果关注与启动VN相关的时间延迟,则使用第二过程。如果关注对于开始通信的时间延迟,那么VN可配置在要被初始地激活的所有VN ECU上。即,对于这些VN,ECU处理总线唤醒信号作为(1)启动通信内核的唤醒信号和(2)将ECU初始化至VN的VNMF消息。通过无需等待将ECU初始化至VN的VNMF消息传输来减少启动时间。保持VN激活的过程和关闭VN的过程仍基于在周期性基础上(即,在预定时间周期内)的重新广播VNMF传输。
第三过程包括共享输入激活VN,其中应用程序直接激活VN。在共享激活VN中,既无主体激活ECN,也无发射用于激活VN的VNMF。相反,其是通过应用程序的直接激活。当VN中的所有ECU共享开始控制操作的输入时,它们各自的通信内核响应于该输入同时启动。由于各ECU都具有响应于该输入转变而启动VN的认知,所以总线唤醒广播信号及后续VNMF传输信号都是不必要的。相反,VN基于从应用程序到所有ECU的共享输入来启动。另外,VN并不基于超时来关闭。可能因为共享的输入已经改变状态,当由应用程序请求这样做时,VN立即关闭。
在包含用于关闭网络的网络管理的操作中,会发生不同的故障,例如软件干扰、定时误差(如循环溢出)、随机硬件误差(如存储位翻转)、由突发总线拥堵或线连接松动引起的消息重复或遗失、消息达到长时间地延迟,等等。这类故障会在通过整个网络ECU假定LAN通信网络未激活之后导致LAN通信网络保持激活。结果,由于LAN通信网络模块保持激活,可能发生不期望的电池消耗。为了防止LAN通信网络保持激活,通过网络管理模块对LAN通信网络执行故障检测和缓解。
图2示出了用于LAN网络管理的故障检测和缓解策略的故障树的框图。使用自上而下的方法识别要检测和缓解的故障情形,然后为LAN网络管理模块提供故障检测和缓解算法。
如图2中所示,框40中,对于检测和缓解识别到“非预期Comm_Kernel_Active”故障,这是由于LAN通信网络应当未激活时却激活的结果。会引起非预期Comm_Kernel_Active故障的两个子条件包括:(1)错误的激活VN 41和(2)没有VN激活,但是Comm_Kernel保持激活 42。错误的激活VN被定义为被系统错误激活的或者在满足关闭VN的标准之后VN保持激活的虚拟网络。
如上所述,错误的激活VN 41可由应用程序由于错误而激活VN或者VN在其激活之后没有被去激活而引起,由框43表示。这是因应用程序的故障,必须由应用程序本身检测和缓解。
错误的激活VN 41也可由指示其处于未激活但是没有实际VN激活的VN状态引起,由框44表示。该故障通过一致性检验来检测,可通过将VN状态重置为零(即,显示未激活)并且将VN处理为未激活以防止其保持通信内核激活来缓解。
对于没有VN激活但是Comm_Kernel保持激活42的故障情形,有两个引起该故障发生的子条件。该故障发生于防止Comm_Kernel关闭的网络管理关闭路线中或者发生在因故障保持Comm_Kernel激活的网络管理激活路线中,由框45表示。该故障通过使用计时器监测系统状态来检测。通过利用备用的关闭路线并且同时防止关闭之后错误的Comm_Kernel激活来执行缓解。因为主关闭路线无法关闭系统,所以利用另一关闭路线。
第二子条件包括在比预定时间段长的时期内没有激活的VN时应用程序不确认关闭,由框46表示。即,在比预定时间段长的时期没有激活的VN时,应用程序并不确认所述关闭。这可通过使用计时器监测系统来检测。缓解包括在系统被网络开发人员标定成这样做时强制网络关闭;否则,该缓解是应用程序的责任。
图3a,3b示出了通过LAN网络监测模块提供故障检测和缓解的流程图。
参考图3a,在步骤50处开始。步骤51中,进行是否中止网络中的典型通信的确定。如果确定中止典型通信,那么在步骤52中终止检测和缓解技术。所述检测和缓解技术仅在典型通信期间执行。如果确定不中止典型通信,那么程序进行至步骤53。
步骤53中,虚拟网络激活指示器被设置为零(Has_Vn_Activation=0),指数计数器被设置为第一VN指数( )。Has_Vn_Activation指示各自的VN是否激活。因此,Has_Vn_Activation=0指示VN未激活。Has_Vn_Activation起始被设置为零,直到检测到激活的VN。
步骤54中,进行检查,以确定是否已经检查了所有的VN指数。如果确定已经检查所有的VN指数,那么程序进行至图3b中的步骤69。如果确定未检查所有的VN指数,那么程序进行至步骤55。
步骤55中,确定网络监测VN状态是否未激活(nm_vn_State(i)=0)。其检查VN是激活还是未激活。如果确定当前状态是未激活的,那么程序进行至步骤56,否则,如果确定VN激活(nm_vn_State(i)=1),那么程序进行至步骤59。
步骤56中,响应于当前VN是未激活的确定,当前VN的缓解状态被设定为零(vn_State_Mitigated=0)。即,如果VN被确定为未激活(如步骤55中所检测的),那么对该VN指数不执行缓解,缓解指示器被设定为零。
步骤57中,VN激活计数器被初始化。该计数器用作确定VN保持激活多长时间的计时器。
步骤58中,所述指数被增加,用以分析下一VN指数。返回步骤54,以确定是否检查了所有VN,用以检测故障激活状态。
再说步骤55,响应于当前VN指数为激活的确定,程序进行至步骤59。随后的步骤确定是否想要VN被网络激活或是否存在无意的VN激活。步骤59中,确定VN是否恰当地激活基于下列标准:(1)激活为网络激活VN;(2)ECU是VN激活主体;和(3)本地应用程序激活它。如果这三个标准的每个的答案都是“是”,那么程序进行本地ECU执行网络激活的确定,并且程序进行至步骤60。如果三个标准中的任何一个的答案是“否”,那么程序进行至步骤61。
步骤60中,响应于在本地ECU请求时VN被激活的确定,设定激活指示器,确认存在VN被恰当地激活(Has_Vn_Activation=0x11)。当设定用于识别VN激活的激活指示器时,与单一比特位相反,使用三个比特位,以避免会提供错误结果的位翻转。比特位标注可为表示十六进制的0x11。必须设定三个比特位中的至少两个,以报告VN为激活。程序进行至步骤56,用以设定缓解指示器,并增加计数和指数。
再说步骤59,响应于步骤59中标准的任何一个导致“否”的答复,程序进行至步骤61。步骤61中,进行关于激活是否由于共享输入激活的确定。确定是否发生共享输入激活的标准基于下列因素:(1)激活是共享输入激活的结果;和(2)应用程序激活VN。共享输入激活是当没有VN激活主体时。即,没有ECU启动VN激活。相反,VN被激活为从共享输入线路到所有ECU的直接通信。结果,由于没有控制ECU,并且VN的启动和关闭不被任何VNMF消息控制,所以所有的ECU共享所述输入。如果确定VN为共享输入激活并且应用程序激活VN,那么程序进行至步骤60,指示恰当激活VN的指数。如果确定VN不是共享输入激活或者应用程序没有激活VN,那么程序进行至步骤62。
步骤62中,进行VN是否为网络激活VN并且是否已经为其接收到VNMF消息的确定。这识别出VN激活是否为从远程ECU的远程激活。如果确定VN为网络激活VN并且已经为对话接收到VNMF,那么程序进行至步骤63,否则,程序进行至步骤64。
步骤63中,接收的指示器被重设为零。这指示已经接收到VNMF消息。程序进行至步骤60,设定VN激活指示器,并识别VN被正确地激活。
再说步骤62,响应于VN未被网络激活或未接收到VNMF的确定,程序进行至步骤64。步骤64中,进行有关VN故障是否缓解的检查。在VN没有激活但是通信不是完全未激活时使用该步骤。如果VN故障被缓解,那么故障缓解指示器被设定为1,指示关于VN已经发生缓解(vn_State_Mitigated(i)=1)。然后程序进行至步骤58,这里VN指数被增加。如果VN未缓解,那么程序进行至步骤65。
步骤65中,VN激活计数器加1(vn_Active_Cnt(i)= vn_Active_Cnt(i)+1)。
步骤66中,进行计数器是否达到预定VN激活时间阈值的确定(vn_Active_Cnt(i)>3*NM_VN_TIMER_CNT),其中NM_VN_TIMER_CNT表示在没有故障的情形下VN去激活之后VN被激活的预定时间极限(例如,8秒),在该实例中,对于故障检测的阈值使用正常值的三倍。注意,所述检测和缓解算法周期性地执行。如果时间计数器vn_Active_Cnt(i)具有X值,那么实际消耗时间为X*P,其中P为算法的执行周期。应当理解, VN激活时间阈值的参数为三是示例性,该参数可以比三大或比三小。如果计数未超过VN激活时间阈值,那么程序进行至增加VN指数的步骤58,否则程序进行至步骤67。
步骤67中,报告VN激活故障,并执行缓解。VN缓解故障状态的指示器被设置为1(vn_State_Mitigation(i)=1)。这指示,对各自的VN指数已经执行了缓解。由于在执行关闭动作之后VN状态应当不是激活的,所以VN状态被设置为零(nm_vn_State (i)=0)。执行必要的VN关闭动作,并且通知应用程序VN关闭。程序进行至步骤57,其中VN激活计时器被重置为零(vn_Active_Cnt(i)=0),在步骤58中,指数增加至下一VN。
再说步骤54,响应于所有VN指数都已经被分析的确定,程序进行至图3b的步骤69。
参考图3b,步骤68中,进行(1)网络中是否有任何的激活VN(Has_Vn_Activation≠0)或(2)是否进入网络休眠模式的确定。如果确定有激活的VN或者进入网络休眠模式,那么程序进行至步骤69;否则,程序进行至步骤70。
步骤69中,响应于VN激活或者进入网络休眠模式,网络激活计时器计数器被设置为零(vn_Active_Cnt(i)=0)。为了避免由于错误故障(例如位翻转)引起的进入网络休眠模式的错误报告,对进入网络休眠模式的指示使用三个比特位。仅在设置两或三个比特位时报告网络正在休眠。然后程序进行至步骤52,结束算法的当前循环执行。
再说步骤68,响应于没有VN激活并且没有进入网络休眠模式,程序进行至步骤70。步骤70中,进行网络激活计时器计数器是否达到网络激活时间阈值的确定(nw_ActiveCnt>= nm_Wakeup_Sleep_Cnt * 6)。在该实例中,所述阈值是网络监测唤醒休眠计数的六倍。如果确定所述计数未超过阈值,那么程序进行至步骤71,网络激活计时器计数器加1(nw_ActiveCnt(i)= nw_ActiveCnt(i)+1)。然后程序进行至步骤52,结束算法执行的当前循环。应当理解,为六的网络激活时间阈值的参数是示例性的,该参数可以比六大或比六小。
步骤70中,如果确定所述计数超过阈值,那么报告网络激活故障,并且程序进行至步骤72以缓解。
步骤72中,为缓解网络激活故障,由于主关闭路线未恰当地操作,所以利用另一关闭路线。该另一关闭路线利用新定义的变量来替代主关闭路线中的关键变量。另外,为防止因卡死故障引起的网络激活反复故障,在通过另一关闭路线关闭网络之后不再执行LAN网络任务,使得不会发生错误的新激活。注意,如果满足所有的正常激活条件,网络仍可激活。
步骤73中,进行应用程序是否确认关闭的确定。即,与主关闭路线相类似,当利用另一关闭路线时,应用程序必须确认关闭。如果应用程序确认关闭,那么程序进行至步骤74;否则,程序进行至步骤76。
步骤74中,应用程序确认计数器被重置为零(Appl_Cfm_Cnt=0)。维持确认计数器,保持所述倍数的计数,应用程序不确认休眠请求。由于该确定是应用程序确认关闭,所以计数器被重置为零。
步骤75中,继续另一关闭,直到关闭发生。在关闭之后,程序进行至步骤52,结束算法的当前循环执行。
再说步骤73,如果应用程序并不确认关闭,那么程序进行至步骤76。步骤76中,进行计数器是否大于可标定阈值的确定(Appl_Cfm_Cnt > Appl_Cfm_Call_Num)。如果计数不大于所述阈值,那么程序进行至步骤77;否则,程序进行至步骤78。
步骤77中,应用程序确认计数加1(Appl_Cfm_Cnt = Appl_Cfm_Cnt+1)。然后程序进行至步骤52,结束算法的当前循环执行。
步骤78中,响应于应用程序计数大于可标定阈值,进行是否需要应用程序故障报告的确定。如果系统构造需要各自的故障,则报告应用程序故障报告。如果系统构造需要各自故障的报告,那么程序进行至步骤79;否则,程序进行至步骤80。
步骤79中,响应于系统构造要求报告各自故障,向应用程序报告无休眠确认的应用程序故障。程序进行至步骤80。
步骤80中,进行是否需要缓解应用程序故障的确定。如果需要缓解应用程序故障,那么程序进行至步骤74;否则,程序进行至步骤52,结束算法的当前循环执行。即,如果不需要缓解应用程序故障,那么故障缓解是应用程序的责任,程序终止。
步骤74中,响应于要求的应用故障缓解,应用程序确认计数器被重置为零,并在步骤75中利用另一关闭路线执行关闭。
尽管已经详细描述了本发明的特定实施例,但是本发明相关领域的技术人员会认识到用于实施由所附权利要求限定的本发明的各种替代设计和实施方式。
Claims (19)
1.一种检测和缓解车内通信网络的无意激活状态的方法,所述车内通信网络包括经过控制器局域网络总线系统通信的多个电子控制单元(ECU),每个ECU都包括发射和接收能力,并且配置有提供用于与通信系统内的其它ECU交换信息的准则的通信协议,每个ECU都进入通信内核激活状态用于在总线上通信,所述方法包括下列步骤:
(a)识别所述通信系统内的虚拟网络,每个虚拟网络都包括一信号集合,该信号集合包括其发射和接收共同作为一个单元开始和停止的相应ECU;
(b)检测激活的虚拟网络;
(c)确定该虚拟网络不是网络激活的虚拟网络;
(d)确定该激活的虚拟网络不是由本地ECU激活;
(e)确定该激活的虚拟网络不是由本地应用程序激活;
(f)响应于步骤(c)、(d)和(e)中的每个确定,识别出该激活的虚拟网络是由故障激活的;以及
(g)去激活各故障激活的虚拟网络。
2.如权利要求1所述的方法,其中检测所述无意激活的虚拟网络还包括如下步骤:
确定所述虚拟网络不是共享输入激活的虚拟网络。
3.如权利要求2所述的方法,其中检测所述无意激活的虚拟网络还包括如下步骤:
确定在预定时间段期间所述虚拟网络未接收到虚拟网络管理帧信息。
4.如权利要求3所述的方法,其中所述预定时间段使用计时器测量,其中所述预定时间段基于所述计时器超时的次数。
5.如权利要求4所述的方法,其中所述计时器被设定为8秒。
6.如权利要求4所述的方法,其中所述计时器超时的次数为3。
7.如权利要求3所述的方法,其中响应于确定有意激活的虚拟网络,在网络管理模块内设置至少两个比特位用于识别出所述激活的虚拟网络,其中设置至少两个比特位避免因单一位翻转情形引起的虚拟网络激活的错误报告。
8.如权利要求1所述的方法,还包括向与所述激活虚拟网络相关的应用程序报告所述故障激活虚拟网络的步骤。
9.一种检测和缓解车内通信网络的无意激活状态的方法,所述车内通信网络包括经过控制器局域网络总线系统通信的多个电子控制单元(ECU),每个ECU都包括发射和接收能力,并且配置有提供用于与通信系统内的其它ECU交换信息的准则的通信协议,每个ECU都进入通信内核激活状态用于在总线上通信,所述方法包括下列步骤:
识别所述通信系统内的虚拟网络,每个虚拟网络都包括一信号集合,该信号集合包括其发射和接收共同作为一个单元开始和停止的相应ECU;
检测所述通信网络内无激活虚拟网络;
检测所述通信网络内的激活通信内核;
响应于检测到激活的通信内核和检测到无激活虚拟网络,去激活所述通信网络内的所述激活通信内核。
10.如权利要求9所述的方法,其中去激活所述激活通信内核还取决于确定当所述通信内核激活时预定时间段内无虚拟网络激活。
11.如权利要求10所述的方法,其中所述预定时间段使用计时器测量,其中所述预定时间段基于所述计时器超时的次数。
12.如权利要求11所述的方法,其中所述计时器功能被设定为8秒。
13.如权利要求11所述的方法,其中所述计时器超时的次数为6。
14.如权利要求11所述的方法,其中当没有虚拟网络激活时通信内核激活是由于错误的主关闭路线,其中去激活所述激活通信内核利用另一关闭路线来执行。
15.如权利要求14所述的方法,还包括如下步骤:
确定与所述激活通信内核相关的应用程序是否确认关闭,其中响应于确定在第二预定时间段内所述另一关闭路线无法去激活所述激活通信内核而检测应用程序故障。
16.如权利要求15所述的方法,其中所述第二预定时间段基于与所述激活通信内核相关的应用程序无法确认关闭的次数。
17.如权利要求16所述的方法,其中响应于所述第二预定时间段内所述应用程序不确认关闭,并进一步响应于通信系统配置要求关闭是所述应用程序的责任,而通过与所述激活通信内核相关的应用程序去激活所述激活通信内核。
18.如权利要求17所述的方法,其中响应于在所述第二预定时间段期满之后所述激活通信内核保持激活,并响应于通信系统配置需要通过所述另一关闭路线关闭,通过所述另一关闭路线去激活所述激活通信内核。
19.如权利要求18所述的方法,其中响应于系统配置需要提供给所述应用程序的报告,向所述应用程序提供与所述应用程序不确认关闭相关的报告。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/366,453 | 2012-02-06 | ||
US13/366453 | 2012-02-06 | ||
US13/366,453 US8665700B2 (en) | 2012-02-06 | 2012-02-06 | Fault detection and mitigation for in-vehicle LAN network management |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103248514A CN103248514A (zh) | 2013-08-14 |
CN103248514B true CN103248514B (zh) | 2016-12-28 |
Family
ID=48794779
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310046815.9A Active CN103248514B (zh) | 2012-02-06 | 2013-02-06 | 用于车内lan网络管理的故障检测和缓解 |
Country Status (3)
Country | Link |
---|---|
US (1) | US8665700B2 (zh) |
CN (1) | CN103248514B (zh) |
DE (1) | DE102013201596B4 (zh) |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5451705B2 (ja) * | 2011-09-21 | 2014-03-26 | 日立オートモティブシステムズ株式会社 | 自動車用電子制御装置及びデータ通信方法 |
US8786424B2 (en) * | 2012-02-15 | 2014-07-22 | Infineon Technologies Ag | Error signal handling unit, device and method for outputting an error condition signal |
US9218236B2 (en) * | 2012-10-29 | 2015-12-22 | Infineon Technologies Ag | Error signal handling unit, device and method for outputting an error condition signal |
DE102012017386B4 (de) * | 2012-09-01 | 2020-10-15 | Volkswagen Aktiengesellschaft | Verfahren zum Überwachen einer mit einem Kommunikationskanal verbundenen Vorrichtung |
US9524222B2 (en) * | 2013-09-16 | 2016-12-20 | GM Global Technology Operations LLC | Method and apparatus for fault detection in a controller area network |
DE102013219291A1 (de) * | 2013-09-25 | 2015-03-26 | Robert Bosch Gmbh | Verfahren zum Speichern eines Fehlers eines Zellenüberwachungsschaltkreises und Lithium-Ionen-Akkumulator |
US9522682B2 (en) * | 2014-01-30 | 2016-12-20 | Blackberry Limited | System and method for mitigating unintended operation |
US9827924B2 (en) * | 2015-01-21 | 2017-11-28 | Ford Global Technologies, Llc | Methods and systems for loss of communication detection in a vehicle network |
US9912267B1 (en) * | 2015-05-26 | 2018-03-06 | Marvell International Ltd. | Rotor lock detection |
DE102016100680A1 (de) * | 2016-01-16 | 2017-07-20 | Ssb Wind Systems Gmbh & Co. Kg | Windkraftanlage |
CN106230648B (zh) * | 2016-09-14 | 2023-02-17 | 南京康尼机电股份有限公司 | 集成数据采集传输装置的门控器及其处理传输方法 |
JP6881231B2 (ja) * | 2017-10-25 | 2021-06-02 | トヨタ自動車株式会社 | 車載中継装置、情報処理方法、プログラム、中継装置、及び情報処理システム |
CN108111317A (zh) * | 2017-12-14 | 2018-06-01 | 上汽通用五菱汽车股份有限公司 | 基于节点内部状态转换的通信控制方法 |
EP3570130B1 (en) * | 2018-05-15 | 2020-12-16 | Siemens Industry Software NV | Ring-closures in fault trees |
DE102018216953B3 (de) * | 2018-10-02 | 2020-02-20 | Conti Temic Microelectronic Gmbh | Bussystem, Busknoten und Verfahren |
US11618340B2 (en) | 2020-01-15 | 2023-04-04 | Ford Global Technologies, Llc | Missing receiver power sustain deactivation |
CN111865744B (zh) * | 2020-07-08 | 2021-12-31 | 北京软安科技有限公司 | 一种车辆can总线数据分类方法及装置 |
CN113472618A (zh) * | 2021-06-03 | 2021-10-01 | 一汽奔腾轿车有限公司 | 一种基于软件的canpn网络管理方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6484082B1 (en) * | 2000-05-24 | 2002-11-19 | General Motors Corporation | In-vehicle network management using virtual networks |
CN201769766U (zh) * | 2010-08-06 | 2011-03-23 | 浙江吉利汽车研究院有限公司 | 一种新能源汽车can总线控制系统 |
CN102143011A (zh) * | 2010-08-23 | 2011-08-03 | 华为技术有限公司 | 一种实现网络保护的装置及方法 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3709769B2 (ja) * | 2000-07-27 | 2005-10-26 | 株式会社デンソー | 異常検出システム |
US7113860B2 (en) * | 2004-01-30 | 2006-09-26 | General Motors Corporation | Cruise control warning system |
JP4600158B2 (ja) * | 2005-06-01 | 2010-12-15 | トヨタ自動車株式会社 | 車両の電子制御装置 |
CN101828158A (zh) * | 2007-10-22 | 2010-09-08 | 沃尔沃拉斯特瓦格纳公司 | 用于改变车辆组件的状态的系统和方法 |
US8467324B2 (en) * | 2010-11-03 | 2013-06-18 | Broadcom Corporation | Managing devices within a vehicular communication network |
-
2012
- 2012-02-06 US US13/366,453 patent/US8665700B2/en active Active
-
2013
- 2013-01-31 DE DE102013201596.8A patent/DE102013201596B4/de active Active
- 2013-02-06 CN CN201310046815.9A patent/CN103248514B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6484082B1 (en) * | 2000-05-24 | 2002-11-19 | General Motors Corporation | In-vehicle network management using virtual networks |
CN201769766U (zh) * | 2010-08-06 | 2011-03-23 | 浙江吉利汽车研究院有限公司 | 一种新能源汽车can总线控制系统 |
CN102143011A (zh) * | 2010-08-23 | 2011-08-03 | 华为技术有限公司 | 一种实现网络保护的装置及方法 |
Also Published As
Publication number | Publication date |
---|---|
US8665700B2 (en) | 2014-03-04 |
DE102013201596A1 (de) | 2013-08-08 |
US20130201817A1 (en) | 2013-08-08 |
CN103248514A (zh) | 2013-08-14 |
DE102013201596B4 (de) | 2016-10-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103248514B (zh) | 用于车内lan网络管理的故障检测和缓解 | |
EP4053654A1 (en) | Data management method, apparatus and device, and intelligent vehicle | |
CN103780432B (zh) | 停车场运维方法、车道控制机、服务器、移动终端及系统 | |
KR101749198B1 (ko) | 팬-틸트-줌 장치 식별 방법, 팬-틸트-줌 장치, 카메라 및 팬-틸트-줌 장치용 제어 시스템 | |
CN109278674B (zh) | 无人驾驶汽车系统安全检测方法、装置、设备及存储介质 | |
US20030128111A1 (en) | Multiplex communication apparatus for vehicle | |
KR101526413B1 (ko) | 트랜시버 ic 및 그 동작 방법 | |
CN102298436A (zh) | 识别具有冗余电源的计算机系统中的电力连接的系统和方法 | |
CN101196739A (zh) | 冗余配置的自控系统及配置方法 | |
CN106652527A (zh) | 一种交通信号控制器的故障诊断方法和系统 | |
US8018867B2 (en) | Network system for monitoring operation of monitored node | |
EP2408141A1 (en) | Communication system for use in a vehicle, vehicle comprising a communication system and method for communicating between nodes | |
EP3761568B1 (en) | Method of controlling communication over a local interconnect network bus | |
US9325567B2 (en) | Communication system, method for operating such a communication system, and communication module | |
CN103858105B (zh) | 连接方法 | |
CN110071846A (zh) | 电子控制单元、监视方法及非暂态计算机可读介质 | |
US20230148115A1 (en) | Dynamically reconfigurable battery management architecture | |
CN105027455A (zh) | 列车信息管理装置 | |
CN103916230A (zh) | 传感器识别方法、上位机、传感器及传感器识别系统 | |
CN109660420A (zh) | 通信中继装置 | |
CN203054562U (zh) | 设备状态信息传送系统 | |
CN116094865A (zh) | 一种车辆中的通信系统、数据的通信方法及终端设备 | |
EP2824585B1 (fr) | Système de pilotage d'un équipement de réseau de type châssis modulaire à lames interconnectées, notamment de type ATCA | |
US10372361B2 (en) | Data storage device including multiple memory modules and circuitry to manage communication among the multiple memory modules | |
EP2879399B1 (en) | Wireless monitoring method and device thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |