pdca循环的四个阶段，聊聊汽车功能安全系统开发阶段系统安全架构

很多朋友对pdca循环的四个阶段，聊聊汽车功能安全系统开发阶段系统安全架构不是很了解，每日小编刚好整理了这方面的知识，今天就来带大家一探究竟。

详细介绍了系统开发阶段、TSR、安全机制、TSC、安全性分析等相关内容。今天我们就来说说系统开发阶段的最后一部分，也就是系统安全架构：系统架构相关安全机制系统安全架构01系统架构是一门艺术，在车辆系统、软件和硬件的开发中，尤其是基于模型的系统开发(MBSE)中非常重要，架构是整个开发过程的核心之一。

一般来说，系统架构一般在相关架构开发软件中开发，如Enterprise Architect、Cameo等。通过使用通用建模语言UML或SysML。但遗憾的是，目前大部分车企都没有一个完整的系统架构或者基于PowerPoint等形式的简单架构描述。

在功能安全第三部分的概念开发和第四部分的系统开发过程中，需要系统架构作为输入条件。借助于系统架构，导出安全需求(FSR)和技术安全需求(TSR)，并将相应的安全需求分配给系统架构。

但在系统开发阶段，需要进一步开发系统架构的功能安全相关内容，将架构相关的安全机制融入系统架构，形成系统安全架构，从而勾勒出实现系统技术安全需求所需的核心技术框架，为后续软硬件架构的详细设计提供依据。02系统架构相关安全机制很多朋友一直有一个疑问，不同的ASIL级别应该采用哪些具体的安全机制？

为功能安全技术实施的多样性提供更多空间和选择，便于不同企业根据自身技术积累和发展条件实施。为技术升级提供可能性。随着技术的发展，许多新的安全机制已经在汽车工业中实现或应用。如果ASIL水平与安全机制挂钩并强制执行，很多车企可能无法上市(你懂的)。我们先来看看没有安全机制的系统架构是什么样子的。

系统架构旨在描述相关项目的组成、交互和约束。根据ISO 26262的定义，相关物品由一个或多个系统组成，一个系统至少应包括一个传感器、一个控制单元和一个执行器。当然，一个系统也可以包含多个子系统。那么最简单的系统架构如下：有哪些系统级的安全机制可以集成到系统架构中，形成系统安全架构？

由于最简单的系统由三个部分组成，所以与系统级别和架构相关的安全机制也必须与这三个部分以及它们之间的通信安全相关。我们先来看看系统层面与架构相关的常见安全机制：传感器-传感器硬件冗余-独立供电-多路冗余采集-信号质量检测控制单元-在线诊断-比较器-执行器硬件冗余-执行器控制信号质量检测通信。

-冗余发送-信息冗余(CRC)-时间监控-问答机制需要说明的是，安全机制在系统阶段的主要作用是勾勒出实现系统功能安全所需的核心技术框架，明确应采用哪些技术手段来实现相应的安全目标，不涉及具体的实现细节，将在后续的软硬件开发阶段进一步明确。从上面的安全机制可以看出，虽然安全机制的种类很多，但都来自于以下三个角度：1。

冗余：使用相同的功能组件(多指硬件)，减少硬件的随机故障，增加功能安全的可靠性，如传感器和执行器冗余。2多重性：多用于故障关断路径，多条关断路径或保护装置用于针对单个装置的故障提供保护。多样性：使用不同类型的设备或软件进行多样化设计，以降低共因失效的可能性。03系统安全架构设计

了解与系统架构相关的安全机制，然后我们会将这些安全机制整合到原来的系统架构中，分别看系统的不同组件。集成安全机制后形成的系统安全架构是什么样子的？3.1传感器部分首先，我们将传感器部分安全机制集成到系统中。应当注意，这里的传感器表示广义的输入信息，其可以是特定的传感器信号或其他类型的通信信息，例如CAN和SENT。

传感器的硬件冗余(当然传感器必须独立供电)大多适用于对ASIL电平要求非常高的信号，如ASIL C、D，尤其是D，其主要目的是通过信号的相互验证，避免传感器硬件的随机失效，增加系统输入信息的可靠性。

这里的传感器硬件冗余采集可以是用相同的两个传感器重复采集相同的信号(如踏板信号)，也可以是两个相关性强的信号(如制动踏板位置和压力信息等)。)通过使用不同类型的传感器。

当然，传感器输入的冗余信息必须在控制单元的多个通道中收集。除了传感器本身提供的诊断信息外，还需要对其信号的有效性进行检测，包括数值有效范围检测、在线监测、测试模式、输入比较、相关性和合理性检测。3.2控制单元控制单元是整个系统中最重要的部分，与控制单元相关的安全机制实际上很大程度上决定了系统的安全架构和复杂程度。

说到控制单元相关的安全机制，很多朋友的第一反应是控制器软件分层，控制器硬件冗余(双控制器，双核锁步双核锁步等。)、看门狗、程序流监控等。尽管这些是控制单元常用的安全机制，但从系统的角度来看，它们相对来说过于具体。它们只是针对某一类故障设计的软件或硬件安全机制，需要在系统安全架构的基础上具体明确。

接下来，从系统的角度，我们先来看系统级的安全架构，然后我们会逐步将具体的软硬件安全机制应用到系统架构中。一般来说，所有的安全机制本质上都服务于两种类型的安全架构：失效到安全失效到可操作3.2.1失效到安全。

目前，Fail-safe是汽车行业中应用最广泛的安全架构，最典型的应用是在线监控。整个控制单元分为两部分，即所谓的1oo1D型系统，如下图所示。其中，功能实现部分一般按照正常的开发流程进行开发，主要实现系统的功能需求，不考虑功能安全需求(即全部QM)。

监控单元用于实现系统功能安全相关的需求，主要目的在于对功能实现部分进行安全监控，在线监测功能实现部分是否按照预期运行。一旦发现问题，就将系统导入安全状态，停止提供系统原有功能或者维持最必要的功能。

需要注意的是，监控单元非功能层全部功能的多样化复现，不能独立于功能实现部分单独存在，ASIL等级则直接决定了监控单元的硬件及软件复杂度。

对于ASIL等级要求较高的系统，监控单元软件一般独立于功能层。为实现有效监控，在监控单元不仅需要对功能层中，和功能安全相关的输入和输出进行诊断，还需要对功能安全相关的计算逻辑进行监控，计算执行器关键控制信号的安全输出范围，并和功能层计算结果进行对比，甚至需要对控制器硬件进行额外的硬件监控。

如下图所示，发动机控制单元最常见的E-Gas三层安全架构就属于典型的1oo1D的应用，包括功能应用层，功能监控层，控制器监控层。

E-Gas三层安全架构，虽然是针对发动机控制单元，但属于非常经典安全架构，广泛应用于传统控制系统(例如传动，整车控制)当中，三层分层架构本质为原有ASIL等级的分解，即QM (ASILD)+ X(ASILX):

1

功能层：功能实现部分，使得较为复杂的功能实现部分得以按照QM开发，无需考虑功能安全需求，专注于复杂功能软件的开发和复用。

2

功能监控层：按照原有ASIL等级进行独立开发，对功能层中功能安全相关部分进行监控，包括输入输出诊断，逻辑监控，故障分类及故障优先级仲裁等。

3

控制器监控层：对功能控制器，尤其是功能监控层控制器硬件进行监控，一般采用独立的监控单元(一般采用ASIC基础芯片)对功能控制器中内存，CPU，通讯，定时器等进行监测和保护。

目前E-Gas三层安全架构已经更新了很多版，强烈建议朋友们多读几遍，一定会深受启发，之后有机会也可以给朋友们专门介绍一下。

当然，分层安全架构只是1oo1D其中一种实现方式，对于ASIL等级要求不高或者功能简单的控制系统，不一定非得采用分层架构，监控层也可以相应简化。

3.2.2 Fail to operational

Fail to operational 属于相对高级的安全架构，比较器和多数投票器都属于这类安全架构，整个系统由相对独立的两条或多条功能链路构成，每条功能链路都有拥有自己独立的传感器，控制单元，甚至执行器。当其中一条功能链路出现异常，控制系统可以切换到其他功能链路，保证系统继续正常工作或者降级运行。

独立功能链路的实现需要大量的硬件冗余和多样化的软件设计，直接提高了系统成本，所以Fail to operational在汽车产品一般最多有两个独立功能链路，主要应用在对功能安全要求极高或者功能极为复杂的系统，例如自动驾驶。其中最典型的是1oo2架构，如果每个功能链路拥有独立的诊断单元(和在线监控类似)，则可以实现1oo2D安全架构，如下图所示：

其中：

两条功能链路功能可以保持一致，通过多样化软件设计保证系统安全，或者形成主副功能链路，主功能链路利用高性能计算单元实现复杂的功能计算，副功能链路对控制器硬件安全性及可靠性要求高，承担系统功能安全任务，只实现系统功能安全相关的功能，一旦主功能链路出现故障，则系统切换至副功能链路。

3.3 执行器

执行器属于系统功能实现终端，执行器冗余会极大增加系统成本，一般在Fail to operational 安全架构中才会采用。例如EPS系统，制动系统等，除电动执行单元外，还必须保留机械执行路径。这也是目前自动驾驶系统，为什么还必须保留驾驶员自主驾驶所需要的全部执行输入(例如，踏板，方向盘)的根本原因。

3.4 通信安全

系统组件之间以及组件内部的通信安全，也是系统功能安全的重要内容，一般都采用信息冗余(CRC)，时间监控，问答机制等安全保护机制，主要应用就是AUTOSAR中的E2E保护，利用数据控制信息，保证信息通讯安全。

审核刘清

以上知识分享希望能够帮助到大家！