CN111183412B - 用于保护对控制仪器的诊断指令的设备和相应的机动车 - Google Patents

Abstract

一种用于监控对控制仪器（14）的诊断指令（16）的设备（10），其特征在于如下特征：‑设备（10）包括运行平台（18）和与运行平台（18）连接的安全装置（19），所述安全装置具有指令过滤器（21）和状态机（22，23，24），‑运行平台（18）设计成，根据预设的脚本（15）产生诊断指令（16）；‑指令过滤器（21）设计成，根据从状态机（22，23，24）的状态（25，26）中得出的条件（20）从诊断指令（16）中选出有效指令（29），并且‑安全装置（19）设计成，将指令（29）转发给控制仪器（14）。

Description

用于保护对控制仪器的诊断指令的设备和相应的机动车

技术领域

本发明涉及一种用于保护对控制仪器的诊断指令的设备。本发明此外涉及一种相应的机动车。

背景技术

为了维护机动车技术上的控制仪器，根据ISO 14229的统一诊断服务（unifieddiagnostic services，UDS）是充分已知的。借助于这种服务例如可能的是，询问各个控制仪器（electronic control units，ECUs）的错误存储器或者将其借助新的固件或应用软件更新。UDS标准对此限定在OSI参考模型的会话层（session layer）和应用层（applicationlayer）上的通信协议。

DE102016201279A1公开了一种用于监控车辆的更新的方法，所述方法具有如下步骤：将车辆转移到安全状态中；将安全状态锁定；询问车辆的能量状态；与能量状态相关地，更新车辆的控制仪器或者提前控制地中断该方法并且将安全车辆状态解锁。

发明内容

本发明提供根据独立权利要求的用于监控对一个或多个控制仪器的诊断指令的设备以及相应的机动车。

提出的方案在此基于如下知识：为了能够实现诊断或软件更新指令的灵活的控制进程，可以基于注释的脚本语言（例如Python）产生相应的指令序列。还使用如下语言，所述语言为虚拟机编译，所述虚拟机在其方面运行生成的字节码（例如Lua或Java）。

这样灵活的控制进程由可能不可靠的脚本处理，所述脚本由同样不太可靠的脚本解释程序运行，所述脚本解释程序又在ECU上执行，所述ECU可能不被设计用于安全应用。在安全重要的系统中，当不存在减少这种风险的机制时，这种设置风险能够通过由于有错误的控制进程而无意地干涉安全重要的控制仪器造成。

基于脚本的编程因此一方面提供高的灵活性并且是用于将来应用的动态技术。在另一方面，大多数安全标准要求静态编程，所述静态编程具有清楚限定的状态。所述问题随着经由空气接口（over the air，OTA）引入固件和软件更新而激化，其中——与在工厂中的更新相反地——可在任何时刻并且到处执行不具有限定的状态和监控的无意的动作。

为了能够实现在安全重要的系统中使用创建的诊断协议和基于脚本的处理，因此提出一种系统结构，以便将诊断指令序列产生的实施、指令的监控和进行接收的安全重要的ECU分离。附加地，引入用于监控诊断指令的方法，以便保护安全重要的嵌入的目标ECU免受无意的干涉。术语“诊断指令”在此在广义上用于任意指令序列，以便为了诊断、软件更新的目的或在其他应用的范围内控制嵌入的目标ECU。

不仅软件结构、而且监控诊断指令的方法允许将创建的诊断通信协议、如UDS用于安全重要的应用。

通过在从属权利要求中详述的措施，在独立权利要求中说明的基本构思的有利的扩展和改进是可能的。因此，可以设有指令过滤器，以便根据预设的条件从诊断指令中选出有效指令。可以调整所述条件，以便满足不同的安全标准的要求。

附图说明

本发明的实施例在附图中示出并且在下面的说明书中详细阐述。其中：

图1示出根据本发明的一个实施方式的系统结构。

图2示意地示出该实施方式的安全装置部件。

图3示出安全装置的示例性的进程。

具体实施方式

在图1中示出的用于提出的设备（10）的系统结构划分成三个部分。首先可见的是动态区域（12），所述动态区域的灵活的运行平台（18）用于基于脚本地生成诊断指令（16）、软件升级或将来的应用，并且将其转发给目标控制仪器（14）。动态区域（12）在此不一定满足如例如针对机动车中的安全重要的系统所限定那样的确定的安全要求等级（safetyintegrity level，SIL）的要求。脚本（15）因此不一定根据安全标准发展。

动态区域（12）可以——例如在OTA应用、如远程诊断、固件或软件升级的情况下——从其他域中、例如经由后端基础设施的无线连接获得脚本（15），其他域在下文中称作为连通区域（11）。所述连通区域（11）可以——但不必强制——设置在不具有安全要求的单独的ECU上。在动态区域12中处理脚本（15）并且将其转换成诊断指令（16）的序列。

此外设置有处于安全要求等级上的保护区域（13），所述安全要求等级考虑通过外部的诊断指令（16）无意地激活嵌入的目标控制仪器（14）的安全重要性。所述保护区域（13）可以被分配给具有相应的安全完整性的每个ECU。保护区域（13）尤其包括——似乎用作为防火墙的——安全装置（19），所述安全装置监控动态区域（12）中的诊断指令（16）并且仅选择性地转发给目标控制仪器（14），以便防止无意地干涉目标控制仪器的功能。

目标控制仪器（14）的应答（30）在常规情况下向回提供给动态区域（12）并且由保护区域（13）监控。在错误反馈的情况下，安全装置（19）可以分析所述错误反馈以用于阻挡诊断指令（16）。

从安全装置（19）到动态区域（12）或连通区域（11）的信息例如可以是关于被阻挡的指令（29）的信息或安全装置（19）的运行状态。

如图2表明的，所述“防火墙”部件根据限定的条件（20）仅将有效指令（29）转发给嵌入的目标控制仪器（14）。所述条件（20）可以是设备（10）之内的不同层上的一个或多个有限状态机（finite state machines，FSM 22，23，24）的结果。尤其考虑应用状态（25）——例如用于远程诊断或升级——或总设备状态（26）。所述状态（25，26）可以——但不必强制地——彼此相关，例如在信息交换（27）的过程中或者通过相互间的封锁关系（28）。也期望设有用于在外部规定条件（20）或条件（20）与目标控制仪器（14）的应答（30）的相关性的接口。

借助所述条件（20）在研发期间就已经可以定义设备（10）的受保护的运行状态。根据条件（20），优选地存在有效指令（29）的白名单，所述有效指令允许通过指令过滤器（21），而抑制无效指令。过滤和阻挡可以根据安全装置（19）的不同的配置规定进行。例如可设想：

1.阻挡任意诊断指令（16），

2.阻挡如下诊断指令（16），所述诊断指令出自确定的ECU或者被发送到确定的控制仪器（14），

3.在各个诊断指令（16）的层面上检查和过滤，以便在确定的状态（25，26）下允许确定的有效指令（29）并且此外抑制安全干涉、复位（重置）或其他不允许的诊断指令（16），

4.检查诊断指令（16）和其参数，以便根据确定的参数来辨识有效指令（29）并且防止其他的干涉，例如写到控制仪器（14）的确定的存储器地址上，

5.阻挡如下诊断指令（16），所述诊断指令的出现超过规定的频繁性，以便避免在专业术语中用“blubbering idiot”改写的失效模式。同样地，可以阻挡如下诊断指令（16），所述诊断指令具有失真、延迟或高于确定极限的无意的重复，或者

6 在如下情况下阻挡对控制仪器（14）的诊断指令（16）：所述控制仪器以确定的错误码（30）应答。

具有错误过滤器（21）的安全装置（19）的一个实施方式尤其包含在图3中图解说明的活动。在具体的实施方式中，全部活动不必总是区分在实际的实施方案中的运行部件：

1.固件、应用软件或其他服务借助于诊断指令的更新仅允许在如下情况下实施：总设备（例如车辆）处于安全状态中。这种状态在车辆的情况下例如是具有拉紧的制动的停车。不允许离开所述状态，直至服务成功结束、例如检查到固件或应用软件的更新。对此，由服务从动态区域中要求（41）状态封锁。其他结构形式也是可能的，其中状态封锁（41）的要求例如在保护区域（13）中提出。

基于关于保护区域（13）中的仪器状态、关于可靠性方面的规则（40）的信息（31）检查状态阻挡（41）的要求。如果满足规则（40），那么实行状态封锁。状态封锁（42）本身通过总设备中的另外的保护措施来实现，例如通过阻止发动机启动或者操作驻车制动器。

2.根据状态封锁（41）的要求，在动态区域（12）中的运行平台（18）发送诊断指令（16）的序列。

3.诊断指令（16）在保护区域中被扫描并且在指令过滤器（21）中根据条件（20）检查其可靠性。条件（20）又可以与例如关于应用状态（25）、总设备状态（26）、状态封锁（40，84）的状态、驾驶员操作的信息或传感器信息和其他信息相关。

4.评估为可靠的诊断指令可以在序列过滤器中关于有效顺序或频率予以检查（60）。如果满足（61）用于诊断指令序列的规则（60），那么将有效诊断指令（29）转发给控制仪器（14）。不具有所述序列过滤器的结构形式也是可能的。

5. 将在指令过滤器（21，50）或序列过滤器（60，61）中识别为不可靠的诊断指令（16）阻挡并且不转发给控制仪器（14）。关于错误处理（90）提供关于被阻挡的指令的信息（17），这例如可以是负响应码（Negative Response Codes，NRC）。

6.随后，由控制仪器（14）询问（30）并且分析（70）瞬时状态。如果尚未更新全部软件块，那么服务继续进行。

如果全部软件块更新完，那么对更新的软件进行验证（80，83）。验证例如由动态区域要求（82）。这种验证例如可以包括检查更新的软件版本、有关的错误存储器记录或其他控制仪器的软件版本的相关性。更新的软件版本的验证例如根据元信息（81）进行，所述元信息例如描述在成功更新之后控制仪器（14）的软件的期望版本或者其他的控制仪器的相关性。借此可能的是，执行对一致性和完整性的检查，例如其方式为：是否更新（71）服务所需要的全部控制仪器（14）。元信息在此例如不可变地出自连通区域（11）或动态区域（12）。在总设备的层面上采取措施，所述措施防止经由空气接口直至到保护区域中操纵所述元数据。

7.在成功验证（80，83）更新的软件之后，其中所述软件可以涉及全部由服务所涉及的控制仪器（14），那么再次撤除（84，85）开始颁发的状态封锁。借此服务成功地完成。哪些控制仪器（14）应参与到验证中通过所述元信息（81）来确定。

如果ECU（14）的验证不成功（83），那么将验证的结果输送给错误处理（90），在所述错误处理的范围中将相应的信息（17）输出。

Claims (10)

1.一种用于监控对控制仪器（14）的诊断指令（16）的设备（10），

其特征在于如下特征：

- 所述设备（10）包括运行平台（18）和与所述运行平台（18）连接的安全装置（19），所述安全装置具有指令过滤器（21）和状态机（22，23，24），

- 所述运行平台（18）设计成，根据预设的脚本（15）产生所述诊断指令（16），

- 所述指令过滤器（21）设计成，根据从所述状态机（22，23，24）的状态（25，26）中得出的条件（20）从所述诊断指令（16）中选出有效的指令（29），并且

- 所述安全装置（19）设计成，将所述指令（29）转发给所述控制仪器（14）或阻挡所述指令（29）。

2.根据权利要求1所述的设备（10），

其特征在于如下特征：

- 所述设备（10）具有动态区域（12）和保护区域（13），

- 所述动态区域（12）包括所述运行平台（18），并且

- 所述保护区域（13）包括所述安全装置（19）。

3.根据权利要求2所述的设备（10），

其特征在于，

- 所述设备（10）还具有连通区域（11），并且

- 所述运行平台（18）还设计成，从所述连通区域（11）中接收所述脚本（15）。

4.根据权利要求3所述的设备（10），

其特征在于如下特征：

- 所述运行平台（18）还设计成，将信息（17）从所述保护区域（13）向回提供到所述动态区域（12）或所述连通区域（11）中。

5.根据权利要求1至4中任一项所述的设备（10），

其特征在于如下特征：

- 选出所述有效指令（29）还根据目标控制仪器（14）的确定的应答（30）来进行。

6.根据权利要求1至4中任一项所述的设备（10），

其特征在于如下特征：

- 为了更新所述控制仪器（14）的软件，根据对于要求（41）的预设的规则（40）实行状态封锁（42），并且

- 在成功验证（83）更新的软件之后，撤除（84，85）所述状态封锁（42）。

7.根据权利要求1至4中任一项所述的设备（10），

其特征在于如下特征：

- 所述安全装置（19）还包括序列过滤器，并且

- 所述序列过滤器设计成，根据另外的关于允许的顺序或频率的规则（60）检查（61）所述有效指令。

8.根据权利要求1至4中任一项所述的设备（10），

其特征在于至少一个如下特征：

- 所述状态（25，26）包括应用状态（25）或

- 所述状态（25，26）包括设备状态（26）。

9.根据权利要求1至4中任一项所述的设备（10），

其特征在于至少一个如下特征：

- 所述状态机（22，23，24）在于相互间的信息交换（27），或者

- 所述状态（25，26）在于相互间的封锁关系（28）。

10.一种机动车，所述机动车具有根据权利要求1至9中任一项所述的用于监控对控制仪器（14）的诊断指令（16）的设备（10）。