主观下线

• 默认情况下，Sentinel哨兵会以每秒一次的频率向所有与它创建命令连接的实例（包括主服务器、从服务器、其他Sentinel）发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。
  

• 收到的有效回复为+PONG、-LOADING、-MASTERDOWN命令，其余都是无效回复（包括没有回复的）。

• 如果在down-after-milliseconds毫秒以内，sentinel收到的都是无效回复，那么这个源sentinel就会认为实例进入主观下线状态（就是自己认为的），同时修改实例结构中的flags属性，改为SRI_S_DOWN（主观下线的标志）

down-after-milliseconds毫秒不仅会成为Sentinel判断master进入主观下线的标准，还会成为Sentinel判断master 属下所有从服务器，以及所有同样监视master 的其他Sentinel进入主观下线的标准。

• 多个Sentinel设置的主观下线时长可能不同
  down-after-milliseconds 选项另一个需要注意的地方是，对于监视同一个主服务器的多个Sentinel来说，这些Sentinel所设置的down-after-milliseconds 选项的值也可能不同，因此，当一个Sentinel将主服务器判断为主观下线时，其他Sentinel可能仍然会认为主服务器处于在线状态。举个例子，如果Sentinell载入了以下配置:
  sentinel monitor master 127.0.0.1 6379 2
  sentinel down-after-milliseconds master 50000
  而Sentinel2则载入了以下配置:
  sentinel monitor master 127.0.0.16379 2
  sentinel down-after-milliseconds master 10000
  那么当master 的断线时长超过10000毫秒之后，Sentinel2会将master 判断为主观下线，而Sentinell却认为master仍然在线。只有当master的断线时长超过50000毫秒之后，Sentinel1和 Sentinel2才会都认为master进入了主观下线状态。

客观下线

• 当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线了，它会向同样监视这一主服务器的其他Sentinel进行询问，看它们是否也认为主服务器已经进入了下线状态（可以是主观下线或者客观下线)。当Sentinel 从其他Sentinel那里接收到足够数量的已下线判断之后，Sentinel就会将从服务器判定为客观下线，并对主服务器执行故障转移操作。
• 根据其他Sentinel发回的SENTINEL is-master-down-by-addr命令回复，Sentinel将统计其他Sentinel同意主服务器已下线的数量，当这一数量达到配置指定的判断客观下线所需的数量时，Sentinel 会将主服务器实例结构flags属性的SRI_O_DOwN标识打开，表示主服务器已经进入客观下线状态，如下图
  

判断客观下线的数量是Sentinel配置参数中的quorum参数，超过这个值就会被认为客观下线。因为各个Sentinel中的quorum参数可能不同，也就是说对同一个实例，有的可能认为它已经下线了，有的认为它没有下线

选举领头Sentinel

当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头 Sentinel，并由领头Sentinel对下线主服务器执行故障转移操作。
以下是Redis选举领头Sentinel的规则和方法:

• 所有在线的Sentinel都有被选为领头Sentinel的资格，换句话说，监视同一个主服务器的多个在线Sentinel 中的任意一个都有可能成为领头 Sentinel。
• 每次进行领头Sentinel选举之后，不论选举是否成功，所有Sentinel的配置纪元( configuration epoch)的值都会自增一次。配置纪元实际上就是一个计数器，并没有什么特别的。
• 在一个配置纪元里面，所有Sentinel都有一次将某个Sentinel 设置为局部领头Sentinel的机会，并且局部领头一旦设置，在这个配置纪元里面就不能再更改。
• 每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel。
• 当一个Sentinel(源Sentinel)向另一个Sentinel (目标Sentinel）发送SENTINELis-master-down-by-addr命令，并且命令中的runid参数不是*符号而是源Sentinel的运行ID时，这表示源Sentinel要求目标Sentinel将前者设置为后者的局部领头 Sentinel。
• Sentinel设置局部领头 Sentinel的规则是先到先得:最先向目标Sentinel 发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel，而之后接收到的所有设置要求都会被目标Sentine1拒绝。
• 目标Sentinel在接收到SENTINEL is-master-down-by-addr命令之后，将向源Sentinel返回一条命令回复，回复中的leader_runid参数和leader_epoch参数分别记录了目标Sentinel的局部领头Sentinel的运行ID和配置纪元。
• 源Sentinel在接收到目标Sentinel返回的命令回复之后，会检查回复中leader_epoch参数的值和自己的配置纪元是否相同，如果相同的话，那么源Sentinel继续取出回复中的leader_runid参数，如果leader_runid参数的值和源Sentinel的运行ID一致，那么表示目标Sentinel将源Sentinel设置成了局部领头Sentinel。
• 如果有某个Sentinel被半数以上的Sentinel设置成了局部领头 Sentinel，那么这个Sentinel成为领头entinel。举个例子，在一个由10个Sentinel组成的Sentinel系统里面，只要有大于等于10/2+1=6个Sentinel将某个Sentinel设置为局部领头Sentinel，那么被设置的那个Sentinel就会成为领头Sentinel。
• 因为领头Sentinel的产生需要半数以上Sentinel的支持，并且每个Sentinel在每个配置纪元里面只能设置一次局部领头 Sentinel，所以在一个配置纪元里面，只会出现一个领头 Sentinel。
• 如果在给定时限内，没有一个Sentinel被选举为领头Sentinel，那么各个Sentinel将在一段时间之后再次进行选举，直到选出领头 Sentinel 为止。

故障转移

• 在选举产生出领头Sentinel之后，领头Sentinel将对已下线的主服务器执行故障转移操作，该操作包含以下三个步骤:

1. 在已下线主服务器属下的所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器。
2. 让已下线主服务器属下的所有从服务器改为复制新的主服务器。
3. 将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器。

新的主服务器是怎样挑选出来的
领头Sentinel会将已下线主服务器的所有从服务器保存到一个列表里面，然后按照以下规则，一项一项地对列表进行过滤:
1）删除列表中所有处于下线或者断线状态的从服务器，这可以保证列表中剩余的从服务器都是正常在线的。
2）删除列表中所有最近五秒内没有回复过领头Sentinel的INFO命令的从服务器，这可以保证列表中剩余的从服务器都是最近成功进行过通信的。
3）删除所有与已下线主服务器连接断开超过down-after-milliseconds * 10毫秒的从服务器:down-after-milliseconds 选项指定了判断主服务器下线所需的时间，而删除断开时长超过down-after-milliseconds * 10毫秒的从服务器，则可以保证列表中剩余的从服务器都没有过早地与主服务器断开连接，换句话说，列表中剩余的从服务器保存的数据都是比较新的。
之后，领头Sentinel将根据从服务器的优先级，对列表中剩余的从服务器进行排序，并选出其中优先级最高的从服务器。
如果有多个具有相同最高优先级的从服务器，那么领头Sentinel将按照从服务器的复制偏移量，对具有相同最高优先级的所有从服务器进行排序，并选出其中偏移量最大的从服务器（复制偏移量最大的从服务器就是保存着最新数据的从服务器)。
最后，如果有多个优先级最高、复制偏移量最大的从服务器，那么领头 Sentinel将按照运行ID对这些从服务器进行排序，并选出其中运行ID最小的从服务器。

• 在领头Sentinel向被选中的从服务器发送SLAVEOF no one命令之后，领头Sentinel会以每秒一次的频率(平时是每十秒一次)，向被升级的从服务器发送INFO命令，并观察命令回复中的角色( role)信息，当被升级服务器的role从原来的slave变为master时，领头Sentinel就知道被选中的从服务器已经顺利升级为主服务器了。如下图
  

修改从服务器的复制目标

• 领头Sentinel向向从服务器发送SLAVEOF命令，让他们复制新的主服务器。
  
• 最后将下线的主服务器设置为从服务器，如果重新上线，就会成为新主服务器的从服务器
  

引言

近年以来，随着整车功能复杂程度的提升，整车下线流程（EOL,End of Line） 也变得越来越复杂，除了传统的动力、车身部分的下线流程扩充外，更有智能驾驶，网络安全相关的新流程加入。而下线流程作为整车生产环节末端的一部分，一旦出现问题，则会对生产效率产生较大影响，甚至导致生产停滞。因此，在车型研发过程中，越来越需要在量产之前基于单部件和实车环境测试验证整车下线流程相关需求，确保产线装车过程中下线流程的功能稳定性。本文将结合北汇信息为多个OEM提供研发阶段下线流程测试的经验，为整车下线流程的测试提供一种可靠的解决方案。

1.背景知识

传统的下线流程主要涉及动力和车身两大部分内容，一般是车辆完成装配后，离开生产线以前进行的一系列准备工作，比如制动油液的加注、动力系统自检、门窗天窗的自学习等。近年来智能驾驶和网络安全相关功能在车内得以应用，与之相关的部分流程，例如雷达标定、安全信息写入/校验等也被加入了下线流程。得益于目前车内总线式的通信方式，目前大部分的下线流程，均可通过上位机下发诊断指令来完成，也即通过ISO-14229中定义的2F服务（输入输出控制）和31服务（例程控制）来控制对应控制器执行相关步骤。

因为下线流程涉及到产线生产，所以一旦出现严重问题往往意味着产线停止，严重影响生产效率。一些涉及到信息安全相关的功能，例如控制器之间的认证流程，一旦出现问题，车辆将无法启动；而涉及到动力和底盘的功能出现问题，也常常导致产线暂停。因此，在一款车型投产之前，对下线相关流程进行测试是很有必要的，尤其面对当今越来越复杂的下线流程，及早测试并发现问题往往意味着生产效率的大幅度提升。

就下线流程的测试而言，我们可以将其分为两部分：通过仿真上位机的指令来观察下线流程中的诊断数据流是否正确；发送相应指令后观察各执行器的动作是否正常。 这其中，数据流的测试可以通过部件级测试执行，也可以通过实车级测试执行；而后者因为涉及到相关执行器，一般在实车级测试中执行较为方便。

2.实现难点

下线流程相较于传统的诊断协议和诊断功能，更注重与控制器功能上的交互；而与功能测试相比，为了提升效率，部分流程可能会通过诊断仪或者产线设备来自动化执行。因此下线流程测试综合了传统诊断测试与功能测试，对测试上位机有更高的要求，我们在分析多个OEM的下线流程后，总结了如下常见的实现难点，并针对这些难点开发了对应的解决方案。

①多控制器兼容性： 由于下线流程往往涉及多个控制器，因此需下线设备可同时兼容对多个不同功能控制器的测试

②下线流程灵活调配： 开发阶段的下线流程往往尚处于调试过程中，可能会随需求及实际项目进度发生改变，这就要求测试设备可以灵活的增减下线流程，便于开发阶段的调试

③多控制器并行诊断： 随着目前车内网络带宽的提升，越来越多的网络架构支持并行诊断或控制器并行升级，下线流程也往往使用并行诊断的方式，这就要求下线流程测试设备也可以做到对诊断请求的并行诊断

3.方案简介

针对上文列及的测试难点，北汇信息结合项目实际开发了一套可行测试方案，并在OEM的下线流程测试中进行了实践，获得了较好的效果。 下面我们将对该解决方案做简要介绍。

该测试方案的核心为基于Vector公司CANoe软件开发的一套下线流程测试工程。如下图所示，工程主要由诊断底层模块，并行处理模块，下线流程模块及环境配置模块组成，并与其相关的外围设备，数据库等进行交互，仿真下线设备的响应指令，从而实现对下线流程的测试。接下来我们将对各个组成模块进行简单介绍：

诊断底层模块： 北汇信息基于CANoe开发环境实现的诊断应用层、TP层，目前已经涵盖了常见的CAN/CANFD/LIN/FlexRay/Ethernet等主流总线协议，并在此基础上实现了诊断应用层协议ISO-14229，可以通过配置适应不同总线的诊断数据发送需求。

并行处理模块： 提供对多控制器的诊断请求并行发送处理，并可以针对各个控制器单独计算响应时间，判断响应数据。因为模块对于每个诊断地址单独开辟处理通道，因此可以方便的添加或减少支持同时发送的诊断地址数目，具有配置灵活的特点。

下线流程模块： 包含了EOL所需要的流程，并可以通过方便地进行添加删减或排列组合。此外下线流程模块还可与数据库进行交互，从而获取各个控制器在EOL流程中需要用到的必要信息，或者刷新数据等。

环境配置模块： 在项目开发的整个周期内，往往测试环境并不相同，以EOL测试为例，在项目前期，由于系统各组成部分尚处于早期开发阶段，测试环境往往为零部件级测试或者HiL台架；而到了测试后期，更多对于整个系统的测试会集中到实车环境。环境配置模块中包含了设备对外围设备控制的指令集，可以随着开发周期及测试环境的改变而适配不同的测试设备。


从对各个模块的简介中，我们不难发现，该解决方案对上文提到的测试难点给出了一系列解决方案。

通过该测试工程，使用者可以通过数据库方便地管理整个测试流程，在项目开发过程中及时进行流程上的调整；在完善好数据库后，工程使用时也可以通过勾选配置待测试ECU；此外，可配置的并行处理模块可以方便的调整并行诊断请求发送数目，并且可以通过配置诊断底层来适应多种总线类型；最后，随着项目推进，测试工程还可以方便地配置测试环境。

4.方案实践

为了使读者对解决方案有一个更直观的了解，将以我们已经开发的EOL测试工程为例，为读者介绍该方案在实际场景中的应用。

该测试工程基于以太网DoIP的底层开发，对整车内所有控制器进行下线流程测试。如下图所示，测试工程运行后，会根据数据库中内容，将车内支持的全部控制器显示出来，以供测试人员选取测试控制器。当勾选测试控制器后，测试工程将按照预定流程向整车网关发送相应诊断数据，以仿真实际整车下线流程。

在测试过程中，工程使用并行诊断的方式，同时对多个控制器更新应用程序，且在数据库中，可以方便的配置下线流程。当测试完成后，测试模块会输出测试数据及测试报告，以供测试人员分析。

小结

整车功能的急剧扩充，预埋软硬件成为趋势，也将测试环节的重要性一再凸显，可以预见，不久的将来整车下线流程将变得越来越复杂，更多的功能需在下线流程环节实现配置，这对于整车下线流程的测试提出了更高的要求。

北汇信息长期深耕于汽车电子电器测试，为整车电子电器测试提供部件级，系统级，实车级一站式解决方案。同时，我们也更注重从需求设计出发，针对整车应用场景完善测试开发，形成闭环，以期为客户提供更高质量和更具前瞻性的测试方案。

作者：北汇信息——李靖尧