SOME/IP框架下，AUTOSAR自适应平台的容错设计与分析

具有驾驶辅助功能的现代汽车本质上是安全的。严格的安全要求和自动驾驶功能的引入，增加了对汽车内计算和通信系统的要求。汽车开放系统架构(AUTOSAR)自适应平台的目标是，通过支持高性能计算设备和高带宽通信技术来满足这些行业要求。AUTOSAR自适应平台利用了扩展的面向服务的IP中间件SOME/IP(Scalable service-Oriented MiddlewarE over IP），这是一个汽车中间件解决方案，支持在不同规模和操作系统的不同设备之间交换控制信息。通常，为了保证软件的安全运行，汽车会对关键的软件任务进行冗余处理，以容忍永久的崩溃故障。自适应 AUTOSAR 标准没有规定任何容错要求。在本文中，我们指出了当前AUTOSAR自适应平台标准（第18.10版）中的一些缺口，并提出了弥补这些缺口的建议。我们提出了一个框架，该框架中使用不同的复制策略支持AUTOSAR自适应平台的容错执行。对使用SOME/IP的应用程序，分析了我们的解决方案的故障检测和恢复时间的界限。我们对模型进行了实验验证，并给出了评价结果。

本文提出了一种部署实时软件的方法，旨在为处理器生成可行的任务分配。他们还提出了在AUTOSAR中检测故障节点和激活重新配置的概念。提出了热备和冷备处理器的R-FLOW算法，以支持具有约束恢复时间的容错。然后，他们在AUTOSAR中整合该算法，以提供可靠性。Lu等人提出了一种反射原理的方法来实现AUTOSAR中的容错。该方法引入了具有信息记录、检查和恢复功能的防御软件。该防御软件需要访问操作系统，以便监控操作系统级别的控制和数据流。提出了一个框架，支持 AUTOSAR 经典平台的容错执行。Fabre 等人提出了一种多级反射方法，以实现使用 AUTOSAR 作为中间件的容错和鲁棒性。这种功能和非功能软件的多层次结构可作为自检组件。在低级别的通信框架上也有容错的考虑，如Flexray和以太网。

另一方面，本文首次介绍了在使用SOME/IP框架的AUTOSAR自适应平台面向服务的架构中，对容错支持的系统设计和分析。

本节介绍了本文的主要贡献:AUTOSAR自适应平台容错支持系统设计。图3显示了设计的高级视图。我们为客户端和服务器端设计并实现了一个容错包装，使他们不需要考虑容错问题。在应用层中保持对容错的支持，可以在不同类型的平台和应用中实现可移植性。我们考虑对以下SOA元素/抽象的支持，这些元素/抽象组合在一起构成了所提供的服务:

1) 事件: 从服务器端向客户端发送的通知。

2) 字段: 字段抽象支持三种操作:set:为数据元素赋值，get:检索数据元素的值，notify:通知客户端数据元素值的变化。

3) 方法: 由服务器端代表客户端执行的远程过程调用。

根据服务器端和客户端之间消息交换的单向性或双向性，这些SOA抽象可以大致分为两类。

1) 基于通知的抽象：事件和字段——通知抽象只会导致从服务器到客户端的单向消息传输。

2) 基于请求-应答的抽象：字段set、字段get和方法抽象导致了服务器和客户端之间的双向消息传递。

在设计中，我们考虑了以下的复制需求，以满足系统的安全保证。

1) 服务器可能故障：多个任务必须提供相同的服务。这些服务可以是相同的副本，也可以是另一个服务的降级副本。客户端必须能够定位、订阅和使用服务的所有副本，允许隐式故障处理。

2) 客户端可能故障：多个任务必须充当客户端。服务器必须能够处理来自多个相同客户端的命令和请。

目前的自适应 AUTOSAR 标准（第18.10 版）没有规定对容错支持的要求。在标准中定义容错要求，对于平台功能集群（如执行管理和通信管理）尤其重要，因为这些组件的故障可能是灾难性的。将这些复制需求映射到上面描述的SOA抽象中，我们需要考虑以下事项：

图4: 可靠客户端抽象化

1) 客户端处理：事件、字段-get和字段-通知的抽象只在客户端修改数据，因此容错支持只适用于客户端。

2) 服务器端处理：字段-set抽象只在服务器端修改数据，因此容错支持只适用于服务器端。

3) 客户端和服务器端处理：方法抽象可以修改服务器端和客户端的数据，因此容错支持同时适用于服务器端和客户端。

A. 容错的API设计

考虑到不同的抽象需要在客户端(Client)和服务器(Server)端进行不同类型的处理，我们开发了两个新的抽象:ReliableClient和ReliableServer，客户端和服务器可以分别使用它们来支持容错操作。我们将这些抽象实现为FT库的一部分，所有软件应用程序都可以使用。FT库支持以下功能：

1) 数据时间戳：每个来自服务器端或客户端的请求和应答都被打上最新的全局时间戳。

2) 复制信息：来自服务器端或客户端的每个请求和应答都附加了对容错支持至关重要的数据，如复制类型、状态和任务以及节点id。

3) 唯一标识符接口：FT库支持一个序列号接口，该接口可由客户和服务器应用程序覆盖，为请求和应答提供唯一的序列号。在汽车方面，由于大多数应用程序都要处理来自传感器的数据，因此可以使用传感器包序列号和复制信息为每个请求或应答创建一个惟一的标识符。

我们现在来介绍可靠客户端和可靠服务器抽象，并详细描述它们。

B. 可靠客户端

ReliableClient抽象向客户端公开了以下三个API。

图5：可靠服务器抽象化

1) 服务发现接口: 该接口允许客户机发起服务发现调用，以连接到特定的服务ID。ReliableClient 使用指定的 serviceID 建立与所有服务的连接并维护它们的状态。

2) 融合接口: 这个接口允许客户端提供一个自定义的融合策略，以便在请求的服务ID存在重复的服务器时应用。如果融合策略需要，ReliableClient使用唯一标识符和时间戳基元来识别重复的输入。

3) 请求接口: 这个接口允许客户端进行单一的请求调用，并将其转发到由ReliableClient维护的所有服务器。

图4展示了一个使用ReliableClient API的客户端应用程序的例子。客户应用通过服务发现接口启动服务发现。ReliableClient连接到所有可用的服务并保持其状态。然后，客户端应用程序设置一个融合策略并通过请求接口提出请求。对于来自服务器的回复，ReliableClient会执行融合策略并返回结果。

C. 可靠服务器

ReliableServer抽象化向服务器应用程序展示了以下API。

1) 过滤器接口: 这个接口允许服务器提供一个自定义的过滤策略，以便在重复的客户端请求相同的服务时应用。如果过滤策略需要，ReliableServer使用唯一标识符和时间戳原语来识别重复的输入。

图5介绍了一个使用ReliableServer API的服务器应用程序的例子。服务器接受一个过滤策略，在收到客户端的请求时，如果有必要，就执行该过滤策略，并将输出返回给所有相同的客户端。

如前所述，副本可以是并行的，也可以是非并行的。这两种类型的复制策略都可以利用ReliableClient和ReliableServer的抽象性。有了始终处于运行状态的并发副本，API就可以不加改变地被使用。对于非并行副本，只有在主站故障时才开始运行，有必要检测主站的故障。对于服务器，我们通过让副本订阅主服务来利用 SOME-IP/SD。对于不提供服务的纯客户端，ReliableClient 提供的服务只是为了与副本交换健康消息。当主站点发生故障时，副本因此能够检测到服务的故障，从而可以开始提供服务。需要注意的是，尽管非并行副本是非操作性的，但它们确实参与了服务的发现，它们只是在主要故障之前不实施服务而已。

D. 故障检测的时间分析和服务故障的恢复

在汽车上运行的安全关键应用程序必须及时地从故障中重新获得恢复，以满足所需的安全保障。在本节中，我们分析了不同副本类型的容错行为，并确定了在出现故障时达到所需安全水平的控制旋钮。

对于给定的任务 τ ，让 Trecthres  表示在违反安全保证之前，所提供的服务可以承受的保持不可用的最长时间。对于基于请求-回复的抽象化来说，这是在提出请求到执行请求之间所能承受的最长时间。对于基于通知的抽象化来说，这是一个服务器无法产生通知的最长时间。让Trecmax代表一个任务的恢复时间的最大值。因此，如果Trecmax < Trecthres τ，我们假设系统在出现故障时满足其安全要求。

我们首先介绍了SOME-IP/SD阶段的概况，以描述一些重要的系统控制参数。在SOME-IP/SD中，服务发出供应消息以提供网络内的服务，而客户端发出查找消息以定位网络内的服务。这发生在三个阶段：初始等待阶段、重复阶段和主要阶段。

1) 初始等待阶段(IWP): 在这个阶段，客户端在控制参数 CliDelIW Pmin 和 CliDelIW Pmax 之间的随机时间内保持沉默。在控制参数SerDelIW Pmin 和 SerDelIW Pmax之间，服务器也随机保持沉默。如果客户端在这个阶段收到一个服务器的指示，它就直接跳到主阶段。

2) 重复阶段(RP): 在这个阶段，客户端开始发送查找信息。每两条查找信息之间的时间连续增加，直到CliFindMsgMax给出的最大查找信息数量。两个查找信息之间的延迟可以通过设置控制参数CliRepDel来控制。客户端在接收到供应信息时过渡到主阶段。除了对接收到的查找消息的反应外，服务器的行为几乎与客户端完全相同。在这种情况下，服务器在预定范围内等待控制参数SerDelRPmin 和 SerDelRPmax之间的一个随机量，并发出一个单程供应信息。如果达到由控制参数SerFindMsgMax设定的供应信息数量，并以SerRepDelRP给定的速度，服务将过渡到主阶段。

3) 主要阶段(MP): 在这个阶段，客户端保持沉默，服务器继续发送供应信息，以表明其在控制参数SerRepDelMP 设定的时期内的可用性。

为了分析故障恢复行为，上述SOME-IP/SD阶段可分为以下两个不同阶段。

1) 客户端和服务器之间没有建立连接：如果在建立连接之前服务失败，必须重新启动服务。

图6：提供基于通知的服务的非并行副本的恢复示例

图7: 提供基于请求-回复的服务的非并行副本的恢复实例

在自适应平台中，这可以通过平台健康管理和执行管理功能集群来完成。

平台健康管理集群在进程启动时设置一个HW看门狗程序。 

如果进程启动失败并且HW看门狗过期，执行管理被触发以重新启动进程。令 Twd为看门狗定时器的到期持续时间，令 TEM 表示执行管理集群重新启动进程所用的时间。让Tconnect表示与在服务器和客户端之间建立连接相关的启动延迟，启动延迟界限的正式推导在文献中推导。可以使用上述控制参数来控制此延迟界限。因此, 恢复所需的最长时间为，

任务可能在多次重试时未能启动。在这种情况下，如果Trecovery > Trecmax，平台健康管理（PHM）功能集群应该能够在执行管理的帮助下触发适当的操作。对PHM定义的一个重要补充是允许根据看门狗定时器过期的次数来采取不同的行动。

1) 客户端和服务器之间形成成功连接后：对于并行的副本，如果至少有一个副本成功连接，则故障的处理是隐性的。

图8: 实验装置

对于非并行复本，如果一个服务在连接后发生故障的时候，有两种可能的结果，一种是故障被处理，另一种是未被处理。

如果一个进程能够处理故障，例如通过捕捉一个SegFault信号，它可以触发适当的备份机制。如果进程无法处理故障，例如在电源故障的情况下，则无法触发任何备份操作。

图6a展示了一个基于通知的抽象的恢复例子，其中有非并行复本的未处理的故障。最坏情况下的恢复发生在服务刚刚在其主要阶段产生一个表明其可用性的供应消息之后就发生故障了。SOME-IP/SD中的每个服务供应信息都配置了一个生存时间（TTL）标志。在这个TTL标志到期时，副本可以认为主服务器失败，并作为新的服务器接管。如果Tcomm为从服务器发送数据包到副本的时间，则恢复时间为，

在处理失败的情况下，如图6b所示，服务器可以发出一个停止供应消息，向副本表明服务器即将失败，因此它可以接管执行。让Tsig代表处理异常信号所需的时间。

图7a，展示了一个基于请求-回复的抽象的恢复例子，其中有非并行副本的未处理故障。每个Reliableclient都会启动一个设置为Ttout的定时器，计时器与每个请求关联。这个定时器值的选择是允许主站处理请求并回复给客户端。如果定时器过期，客户端可以认为服务器失败，并接管新的服务器。因此，

在处理故障的情况下，如图7b所示，服务器可以发出一个停止供应消息，向副本表明服务器即将失败，这样它就可以接管执行；因此，