汽车V模型开发流程、ASPICE、汽车功能安全的基石是国际标准 ISO 26262

1、V模型简介

V字形开发流程，即V模型，是在快速应用开发 (RAD，Rap Application Development)模型基础上演变而来，V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。

V流程分为需求分析、系统设计、软件设计、软件实现、HIL测试、台架测试、实车标定、产业化 等等步骤。

1.1、需求文档化

分析客户需求，研究受控对象，明确控制功能及系统配置，形成需求描述文档。

2)开发流程及规范建立

开发流程及规范建立

命名规范建立

模块测试流程/专家检查流程建立

建模规范建立

测试规范建立

1.1、系统设计

主要工作内容:

创建各模块控制思想的数学化/工程化描述文档 SDD(Software Design Document)

创建各模块数据传递接口文档 DD(Data Dictionary)

确定控制器IO 和通讯接口

设计文档建立标准:

SDD 设计文档图形化、逻辑化，且易于理解

DD 文档输入输出定义清楚、全面

控制器接口电路图规范清晰

1.2、软件设计

3.1控制功能建模

使用模型化的编程工具 Matlab/Simulink 软件,完成整车控制器控制功能各模块模型搭建。

3.2软件检查

为了保证软件模型的质量，完成模型之后完成模型的 MAAB 规范检查和 Model DesignVerifier，同时确保模型生成代码之后，做 Miscr C 和 PolySpace。

3.3 模型测试

控制策略完成后，进行模型在环测试(MiL)，用于在生成代码之前保证控制逻辑的正确性与准确性。根据目标车辆特性搭建车辆模型(或在已有模型基础上修改，车辆模型不作为本项目提交物)，并设计测试用例，对控制策略模型进行测试，提供详细的测试报告。

1.3、软件实现

基于第三方的控制器硬件，通过控制器硬件识别的编译器,将 simulink 模型软件编译成 C 代码，然后把 C 代码与控制器底层软件打包集成编译成可执行代码，下载到对应的控制器中，为后续测试环节做准备。

1.4、HiL 测试

内容主要包括以下内容:

整车控制器核心控制算法功能测试;

诊断功能测试;

网络通信测试;

极限工况模拟测试

编写 HiL 测试报告；

1.5、台架测试

台架测试主要针对整车控制器、与电机台架联合调试。台架测试主要工作内容如下:试验前准备工作，

上电及基本初始化标定，各工况下系统功能测试及标定，控制参数/特征值优化，控制算法验证/测试，系统行为评定整理测试数据，撰写测试报告。

1.6、实车测试

硬件平台在装车时，需在实车上进行整车控制器的标定，采用基于硬件供应商所支持协议的方式测试。在提供的国内试验场地进行，标定工作达到功能需求和性能要求，工程师负责程序调整和标定参数调整。标定工作在本项目指定的目标车型上进行，实现整车控制器的参数优化。

1.7、高低温测试

在厂区基本测试和标定之后，进行低温和高温试验，低温试验具体在环境仓中进行或者在实地测试场进行:根据 SOP 的时间，高温测试可以考虑环境仓或反委试验进行，制定整车控制器高低温测试工作。

2、ASPICE

Automotive Software Process Improvement and Capacity dEtermination，中文名是汽车软件过程改进及能力评定。

3、功能安全

汽车功能安全是一个体系化、流程驱动、基于风险的工程学科。它通过ISO 26262等标准，将"安全第一"的理念贯穿于车辆电子电气系统开发的每一个环节，从最高层面的安全目标，到具体的硬件诊断和软件代码，最终目标是让汽车在日益复杂和智能化的进程中，依然值得信赖。

对于从业者来说，理解ASIL、HARA、安全概念、安全机制以及V模型流程，是进入这个领域的关键。

3.1、核心定义

汽车功能安全指的是避免由电子电气系统功能失效引起的不合理风险 。它关注的是，当系统发生故障时，如何确保系统仍能维持在安全状态，或者安全地过渡到安全状态，从而不会导致人身伤害、死亡或严重的财产损失。

它不是指"功能能否正常工作"（那是性能问题），而是指"功能失效时，如何保证安全"。

3.2、核心理念与标准：ISO 26262

汽车功能安全的基石是国际标准 ISO 26262 ------《道路车辆功能安全 》。它不是一个技术方案，而是一套覆盖整个汽车产品生命周期（从概念、研发、生产到报废）的管理、开发和流程体系。

3.2.1、ISO 26262的核心思想：

故障导向安全：预先识别可能的故障，并设计安全机制来应对。
V模型开发流程 ：强调从左到右的开发（需求、设计、实现）和从右到左的验证/确认 ，确保每一步的可追溯性和充分验证。
基于风险：安全措施的严格程度取决于风险的高低。

3.2.2、核心概念：ASIL

ASIL 是ISO 26262的灵魂，全称是汽车安全完整性等级。它用于量化风险，决定了开发过程中需要投入的严格程度。

ASIL等级由四个参数评估确定：

严重度：伤害的严重程度（S0-S3）
暴露率：驾驶场景发生的概率（E0-E4）
可控性：驾驶员或其他人员避免伤害的可能性（C0-C3）

ASIL等级分为：

QM：质量管理。风险最低，仅需遵循一般质量管理流程（如IATF 16949）。
ASIL A：最低的安全等级要求。
ASIL B / ASIL C：中等安全等级要求，常见于底盘、动力系统等。
ASIL D：最高安全等级要求，常见于转向系统、制动系统、高级驾驶辅助系统等直接影响车辆动态控制的功能。

示例：电动助力转向系统失效，可能导致车辆失控，严重度高、暴露率中、可控性低，因此通常被定义为 ASIL D。

3.3、功能安全开发的核心活动

以ISO 26262 V模型为例：

3.3.1、概念阶段

项目定义：明确功能范围。

危害分析与风险评估：识别系统潜在的危险，并确定其ASIL等级。这是所有安全工作的起点。

制定功能安全目标：为每个重大危害提出顶级安全要求（如："当主制动ECU失效时，冗余备份系统应在XX毫秒内接管并提供至少YY%的制动力"）。

制定功能安全概念：定义如何通过系统架构和外部措施实现安全目标。

3.3.2、系统级开发

技术安全需求：将功能安全概念转化为具体的技术要求。

系统架构设计：设计满足安全需求的系统架构，包括硬件和软件的划分。

安全分析：使用FMEA、FTA等方法，分析架构能否满足安全需求，识别单点故障、潜在故障。

3.3.3、硬件开发

硬件安全需求：从技术安全需求中导出。

硬件设计与实现。

硬件架构度量：计算单点故障度量和潜伏故障度量，量化硬件的随机失效是否满足ASIL目标。这是ISO 26262的难点之一。

硬件集成与测试。

3.3.4、软件开发

软件安全需求：从技术安全需求中导出。

软件架构设计。

单元设计与实现：通常有严格的编码规范（如MISRA C）。

单元测试、集成测试、软件安全测试。

3.3.5、生产、运行、服务与报废

确保生产制造过程不会引入安全缺陷。

定义车辆运行、维护和报废阶段的安全要求。

3.4、实现功能安全的措施

为实现功能安全，常用以下技术：

诊断与监控：传感器、控制器、执行器的自检和互检。
冗余设计 ：

同构冗余：两个相同的通道（如双核锁步）。

异构冗余：采用不同原理/技术的两个通道（如ESP液压制动 + EPB电子驻车制动作为备份制动）。
安全机制：看门狗、故障注入测试、内存保护、程序流监控等。
安全状态：定义系统故障后应进入的状态（如"缓慢靠边停车"、"维持最小风险状态"）。
安全通信：如使用带有CRC、序列号、时间戳的AUTOSAR SecOC协议，防止通信错误或攻击。

3.5、汽车开发v模型来自于ISO 26262吗？

不，汽车开发中的V模型并非源自ISO 26262。恰恰相反，V模型是一种通用的、经典的系统与软件开发模型，其历史远早于ISO 26262。ISO 26262是采纳并专门化了V模型 ，将其作为实现功能安全目标的最佳实践框架。

3.6、在功能安全中，软件工作者需要做什么？

首先，软件工作者必须建立 "安全第一"的思维：

1、从"功能实现"到"安全保证"：不仅思考"如何实现功能"，更要持续思考"如果这个功能/组件失效了，会发生什么？"以及"我如何防止它引发危险？"

2、接受流程约束：理解严格的流程、文档和追溯性不是官僚主义，而是确保安全性的必要手段。

下面是核心工作内容（按V模型阶段）：

3.6.1、需求阶段

1、理解与分析安全需求：与系统工程师紧密合作，深入理解分配下来的 "软件安全需求" 。这些需求可能非常具体，如"当检测到内存校验错误时，应在X毫秒内关闭Y功能并报告故障"。

2、制定详细的软件需求：将高层安全需求分解为可执行、可测试的详细软件需求。

3.6.2、架构设计阶段

1、设计安全软件架构：

分层与模块化：设计清晰的层次（如应用层、基础软件层、复杂驱动层），隔离安全关键和非安全关键模块。

2、安全机制设计：在架构中设计具体的安全机制，例如：

监控机制：程序流监控、死线监控、逻辑监控。

冗余与校验：关键数据的冗余存储与校验、通信的CRC和序列号检查。

故障处理单元：设计统一的故障检测、处理、上报和恢复策略。

3、遵循安全编码指南：为后续编码制定或遵循特定的安全子指南（如对MISRA C的扩展）。

3.6.3、单元设计与实现（编码）

1、安全编码：

严格遵守 MISRA C/C++ 等编码规范，避免未定义行为、内存泄漏等可能导致不可预测故障的代码。

实现架构阶段设计的安全机制。

代码必须简洁、可读、可验证，避免过度复杂的逻辑。

2、使用合格的工具链：编译器、调试器、静态分析工具等通常需要具备功能安全认证或经过严格的工具置信度评估，以证明它们不会在开发过程中引入系统性错误。

3.6.4、测试与验证阶段（这是工作量最大的一部分）

1、单元测试 ：对每个安全相关的软件单元进行充分测试，确保其行为符合设计，并能正确处理正常和异常输入。

2、集成测试：逐步集成模块，测试模块间的接口和交互是否符合安全架构设计。

3、软件安全测试：这是验证软件安全需求的专门测试，包括：

基于需求的测试 ：确保每一条软件安全需求都有对应的测试用例覆盖。测试用例覆盖

故障注入测试 ：主动模拟硬件故障 、内存错误、信号错误等，验证软件的安全机制（如看门狗、故障处理程序）能否正确响应，使系统进入安全状态。

背靠背测试：对比模型（如Simulink）生成的代码与手写代码的行为是否一致。

4、覆盖率分析：

语句覆盖率、分支覆盖率：通常要求达到100%。

MC/DC覆盖率：对于ASIL C/D的软件，通常要求达到100%。这是功能安全软件测试中最严格、最具挑战性的要求之一，旨在证明每个条件的真假都独立地影响决策的输出。

3.6.5、支持安全分析

1、为FMEA（失效模式与影响分析）、FTA（故障树分析）等提供软件失效模式和数据。

2、参与分析软件中的单点故障、潜在故障，并评估所设计的安全机制是否足以覆盖这些风险。

3.6.6、关键产出物

软件工作者需要生成并维护一系列交付物，这些是功能安全审核的关键证据：

1、软件安全需求规范

2、软件架构设计文档（描述安全机制）

3、详细设计文档（如单元设计）

4、源代码（附带符合规范的证明）

5、软件验证计划与报告

6、单元/集成/安全测试用例、测试脚本及测试结果

7、代码覆盖率报告（特别是MC/DC报告）

8、工具链的置信度评估报告

3.7、代码覆盖率报告（Code Coverage Report）是什么？

定义：代码覆盖率是一种结构化的测试度量标准，用于衡量测试用例对程序源代码的执行覆盖程度。它回答了一个问题："我们的测试有多充分？代码的哪些部分被测试了，哪些部分没有被测试？"

核心目的：不仅仅是"跑通了测试"，而是系统地证明没有遗留未经测试的代码"死角"。未经测试的代码可能包含隐藏的缺陷或非预期的行为，这在安全关键系统中是不可接受的。

常见覆盖率级别（从低到高）：

语句覆盖率：代码中的每个语句（每行）是否至少被执行一次？

分支覆盖率：程序中的每个控制流分支（如 if-else， case 语句的每个分支）是否至少被执行一次？

条件覆盖率：每个布尔子表达式（条件）的真、假结果是否至少被评估一次？

MC/DC覆盖率：这是功能安全的黄金标准。

3.7.1、MC/DC

MC/DC 的全称是 Modified Condition/Decision Coverage，中文可译为 "修正条件/判定覆盖"。

它主要用于测试包含复杂逻辑条件的代码 （例如 if (A && (B || C)) ），并确保这些条件的逻辑是完整且正确地被测试的。