通过CAN总线进行安全可靠UDS刷新_牛喀网-智能网联汽车开发者社区

通过CAN总线进行安全可靠UDS刷新

专栏作者 2023-07-24

内容提要：本文根据汽车标准ISO 26262和ASPICE，使用V模型开发周期的改编，描述了通过CAN总线进行UDS引导加载程序的开发，并考虑以下部分：需求、架构、设计和实现、测试和集成。为了进行系统验证，软件和系统测试是在受控环境中执行的。

摘要

引导加载程序是帮助更新微控制器单元的应用程序的固件。在汽车行业，必须考虑确保系统质量控制的标准来实施安全可靠的引导加载程序。本文根据汽车标准ISO 26262和ASPICE，使用V模型开发周期的改编，描述了通过CAN总线进行UDS引导加载程序的开发，并考虑以下部分：需求、架构、设计和实现、测试和集成。为了进行系统验证，软件和系统测试是在受控环境中执行的。下一步涉及使用汽车环境执行测试。

1.简介

在汽车行业中，引导加载程序经常用于对任何汽车电子控制单元(ECU)进行诊断和重新编程。引导加载程序是一种固件，独立于系统开机时开始运行的用户应用程序。该固件允许与ECU及其组件（例如传感器或执行器）进行通信。必须根据每个微控制器的内存架构设计总线控制区域网络(CAN)引导加载程序，以识别将上传新固件的部分。主机（将提供新固件）和ECU之间的通信可以定义安全和指令管理等问题。此外，必须定义引导加载程序固件的架构，以便与微控制器和ECU系统的多个部分进行通信。系统分步骤定义，包括其架构、设计和实现；即，从项目概念描述系统以解释产品的功能。

例如，一辆汽车平均可能有40台计算机，但有些甚至多达100台，其中包括不同类型的传感器；车身控制模块（BCM）就是一个例子。BCM负责诊断和管理车辆的车身传感器和执行器，例如转向灯、光学喇叭和远光灯。BCM必须满足质量标准，以维护符合汽车安全完整性等级(ASIL)的安全系统。

ASIL是汽车固件中的决定性因素；因此，它必须符合特定级别的质量控制，具体取决于汽车系统的组件。如果固件符合ISO 26262标准，则被认为是安全的；这是对产品开发通用IEC 61508功能安全标准的解释。根据ISO 26262，固件开发应该分段，在每个阶段都遵守可以缓解软件问题和错误的指南。软件开发所需的步骤分为5类：需求、架构、设计和实现、测试和集成。

开发符合汽车标准的有质量保证的引导加载程序固件是业界的必要系统，但是没有提供免费或完整文档的固件。为此，本文描述了基于遵循汽车标准的统一诊断服务(UDS)协议的总线CAN引导加载程序的开发，以提供安全可靠的系统。

本文的结构如下：第2节描述了方法。第3节展示了原型组件。第4节提出了要求。第5节描述了系统和固件架构。第6节详细介绍了固件的开发和实现。最后，第7节证明固件是安全的。

2.系统开发生命周期

使用的方法是V开发周期（V模型）；该模型建立了产品开发的各个阶段，从系统的概念理念开始，到系统的工作方式及其实际功能结束。该开发模型的各个部分在“图1”中进行了描述。

图片1.png

图1.V模型的通用开发周期

原型开发采用了ISO 26262和Automotive SPICE标准。这两个标准都提供了基于V模型周期的开发模型。

A.ISO 26262

这是车辆功能安全标准，为汽车系统的开发制定了限制和指南；它考虑了产品的硬件和软件开发阶段。“如图2”介绍了标准中考虑的部分。

图片2.png

图2.根据ISO:26262阶段的V模型周期

B.Automotive SPICE

该标准用于对嵌入式汽车系统的开发进行过程评估。它包含用于解释标准的指标。该标准分为3个过程：主要生命周期、组织生命周期和支持生命周期。每个流程均按流程类别划分，并包含根据每个类别的活动。主要生命周期过程和以下类别：系统和软件工程如图3所示。

图片3.png

图3.根据Automotive SPICE 3.1阶段的V模型周期

根据这两个标准，该项目开发过程中实施的生命周期被定义为5个阶段，如图4所示。该模型表示考虑完整系统的阶段，即每个步骤都集成了硬件和软件，因此，系统和软件阶段将一起表示，但它们将单独设计。

图片4.png

图4.采用并实施的V模型循环

3.原型描述

引导加载程序应能够通过指定类型的数据传输（例如，CAN、以太网、UART）对微控制器单元（MCU）的程序存储器（即闪存）进行重新编程；因此，引导加载程序应该是与应用程序分开的固件，并且应该存储在专门为此固件保留的闪存区域中。

提供三种类型的嵌入式系统启动：闪存启动、ROM启动和SRAM启动。第一种是通用启动模式，其中程序或应用程序位于闪存中。第二种类型，当应用程序初始化需要配置时使用ROM引导。

在一些嵌入式系统中，用于存储引导加载程序固件的内存空间没有定义，因此存储应用程序的闪存必须由固件分割，并且需要具体定义引导加载程序和应用程序将在哪里启动内存区域。“图5”显示了如何为引导加载程序划分相同的内存区域；在其他MCU中，供应商定义的用于引导加载程序存储的专用区域（存储区域暴露在每个微控制器的数据表中）。这种类型的MCU可以在“图6”中看到。

图片5.png

图5.分段闪存。以Texas Instruments的Hercules系列MCU作为参考

图片6.png

图6.分段闪存。以SAM系列的Microchip MCU作为参考

原型引导加载程序可以通过汽车系统中的标准连接更新BCM的ECU固件。引导加载程序可以更改控制车辆照明顺序的应用程序。

对于原型，使用了表1中描述的硬件组件和工具；这些组件是通用的，对于任何需要CAN总线引导加载程序的系统都是必需的。因此，这些可能会根据实施的系统而有所不同。具体组件的选择将在第5节中解释。

表1.png

表1.部件的原型

4.要求

第一阶段是需求分析；这是根据利益相关者的需求、物理可能性以及与产品概念的映射来建立需求的过程。该过程应在架构设计过程初始化之前结束。

在此过程中，定义了系统和软件的需求。这些要求是根据国际系统工程理事会(INCOSE)编写的。尽管描述了两种类型的需求，但它们并不是在一个实例中构建的；它们的开发如“图3”所示。

根据INCOSE，这些要求应遵循以下特征：

1）必要的

2) 独立实现

3）明确

4）完整

5）单一

6）可行

7）可验证

8）正确

9) 确认的

表2是符合写作要求指南特征的需求与写得不正确的需求之间的比较。这两个需求都用于定义引导加载程序。

表2.png

表2.好与坏需求的比较

A.系统需求

系统需求分析包括根据利益相关者的需求构建系统，这些需求将引导系统的设计。需求特定的预期行为、系统和组件的限制。

需求可以表达硬件或软件目标。表3显示了为系统开发提出的一些需求；这些是根据INCOSE指南进行分析的，其规范符合ISO 26262和ASPICE。表3表明该需求是否可以通过硬件、软件或两者来验证。

表3.png

表3.系统需求 (SYSREQ)

B.软件要求

软件需求是系统软件开发的指南。这些需求是与软件相关的系统需求的翻译；如果系统需求与硬件和软件都相关，则仅定义满足软件所需的需求。

软件需求应证明它们与系统需求的关系；每个软件需求应至少追溯到一个系统需求。表4提供了软件需求的示例，这些需求可以追溯到表3中与软件相关的需求。表4的最后一列指示与软件需求相关的系统需求。

表4.png

表4.软件需求(SWREQ)

5.架构

架构阶段的目的是设计和确定哪些需求对应于系统和软件元素。这个过程的步骤是：

1) 定义架构元素

2) 为元素指定位置

3）元素行为分析

A.系统架构

架构系统设计是根据系统需求定义的。按照建议的步骤，根据系统要求确定系统要素；之后，将元素放置在组件图中（图7），其中显示了元素之间的关系以及它们在系统中的位置。

图片7.png

图7.系统架构

然后，使用P图来分析系统元素的行为。通过此图，架构开发人员可以建立系统的理想行为：

1) 需求级别（例如性能）

2) 输入

3）理想输出和误差输出

“图8”是系统中使用的LED元件的示例P图。该图显示了根据系统需求所需的元件特性。

图片8.png

图8. LED图

B.软件架构

软件架构设计基于AUTOSAR架构模型，该模型在汽车行业中用作软件开发标准。根据AUTOSAR结构，所提出的架构在层之间建立了限制，如图9所示。

图片9.png

图9.层限制矩阵

根据AUTOSAR层开发的软件架构如图10所示。

图片10.png

图10.软件架构

6.设计与实施

根据“图4”中的生命周期，下一阶段是设计和实现。在此步骤中，必须创建两个产品：软件设计规范和软件实现。

A.CAN

这是一种多主通信协议，例如，一个设备可以向网络中的所有设备发送或接收消息；如果多个设备同时发送消息，则根据消息ID确定最高优先级消息；如果消息ID更接近0x0h，则该消息的优先级较低。

CAN消息发送不超过8个字节的数据。当设备需要发送超过8个字节数据的消息时，必须将驱动程序配置为发送和接收多帧消息。表5根据消息的类型描述了前三个字节，其中类型在消息的第一个字节中指示。SN字段保存一个滚动计数器，从0x21h开始，到0x2F结束；如果有必要，翻转到0x20h。对于消息类型“FlowControl”，FS字段指示接收驱动器的状态，并且该字段具有树状状态：继续发送、等待和溢出。帧的块大小（图11）保存在BS字段中。最后，STmin指定两个消息之间允许的最小时间间隔。

表5.png