夜雨聆风本 文 目 录
1
什么是基于V模型的产品开发？
2
基于V模型的产品硬件开发（一）
3
基于V模型的产品硬件开发（二）
4
新能源汽车V字形开发流程
5
汽车V模型开发模式
一、什么是基于V模型的产品开发？
（原创 邪道长 觉知汽车）
二、基于V模型的产品硬件开发（一）
（原创 邪道长 觉知汽车）
本文主要介绍的是产品的硬件开发，旨在为诸君辨析硬件的开发如何满足功能安全相应目标。该部分内容位于ISO 26262系列架构的第五部分，由架构图可知硬件开发的主要章节共有六章，由于篇幅原因，本文介绍前三章。
该章节内容是对硬件开发的整体流程进行梳理。满足功能安全的硬件开发的必要活动和过程在ISO26262-2《安全生命周期管理流程》中已经进行了规划。硬件开发的必要过程如下图：
这些活动和过程包含以下内容：
a）硬件实现的安全理念；
b）潜在的硬件失效和影响分析；
c）与软件开发的协调合作。
该章节内容主要是对硬件开发的规范进行了要求。
6.4.1规范应来源于分配给硬件的技术安全要求（源自ISO 26262-4:2018，6.5.2）。
6.4.2规范应包含如下信息：
a）硬件安全要求和用于控制硬件内部失效的相关安全机制特性，包括内部安全机制。例如，看门狗的计时与检测能力。
b）硬件安全要求和用于控制硬件外部失效的相关安全机制特性。例如ECU输入开路的外部故障的功能行为。
c）硬件安全要求和与其他安全需求的元素之间相匹配的安全机制特性。例如，传感器与执行器之间的诊断。
d）硬件安全要求和检测内/外部故障并发出信号的相关安全特性。
注意：对于内外部故障的检测与指示还包括防止潜在故障的安全机制，比如故障的反应时间与容错时间的间隔需要一致。
e）硬件安全要求未指明的安全机制。
注意：安全机制可以单独在硬件或者软件中实现，也可以两者结合实现。
6.4.5硬件安全要求在ISO 26262-8:2018第六章中进行了规定。
这一章节开始，进入硬件设计的主题。在进行设计之前我们需要先了解硬件设计的目的，再依循目的进行产品的设计。
a）建立如下硬件：
——支持安全导向分析；
——考虑安全导向分析的结果；
——满足硬件安全需求；
——满足软硬件接口规范；
——符合系统结构设计规范；
——满足硬件需求的属性。
b）特定需求并且提供在生产、运行期间硬件的功能安全信息；
c）验证：
——满足硬件安全要求和软硬件接口规范；
——有效性；
——功能安全相关的特殊特性。
7.2 硬件设计包括硬件架构设计和硬件详细设计。
硬件架构设计指：所有硬件组件及其相互之间的交互关系；
硬件详细设计指：在原理图层次上，表示元件之间的相互连接关系。
7.4.1硬件架构设计
7.4.1.7在硬件架构设计期间，应考虑与安全相关的硬件组件的非功能性失效原因，如温度、振动、水、灰尘、EMI、噪声或来自硬件架构的其他硬件组件或其环境的串扰。
7.4.2硬件详细设计
7.4.2.1为避免常见的设计失效，应按照ISO 26262-2:2018，5.4.2.6应用相关经验教训。
7.4.2.2在硬件详细设计时，应考虑与安全相关的硬件部件的非功能性失效原因，包括以下影响：温度、振动、水、灰尘、EMI、噪声或来自硬件部件的其他硬件部件或其环境的串扰。
7.4.2.3应考虑硬件部件或它的任务概况和运行条件，以确保在其规范内运行，以避免因预期使用而发生故障。
7.4.2.4应该考虑稳健的设计原则。
注：稳健的设计原则可以通过使用硬件设计指南来显示。
7.4.3安全分析
7.4.3.1对于硬件设计的安全分析，应按照表2和ISO 26262-9:2018第8条进行。
注: 分析的细节程度与设计的细节程度是相称的。在某些情况下，这两种方法可以在不同的细节级别上执行。 例如：FMEA在硬件组件级上完成，并提供给更高抽象级上进行的FTA的基本事件。 |
注：验证评审的范围是关于HW安全要求的技术正确性和完整性。 a: 方法1a和1b是对硬件设计中硬件安全要求的完整和正确执行的检查。 B：方法3a和3b用于检查硬件设计的特定点，对于这些点，分析方法1和2被认为是不够的。 |
三、基于V模型的产品硬件开发（二）
（原创 邪道长 觉知汽车）
本文继续“（一）”未完的部分，主要介绍ISO2626-5后三章，其内容主要有：硬件架构指标评估、随机硬件故障评估、硬件集成与验证。
PS：这部分内容挺枯燥，可根据需要查阅相关内容！！！
正文开始：
8 硬件架构指标评估
本章节内容的目的是提供基于硬件架构指标评估的证据，证明项目的硬件架构设计在检测和控制安全相关的随机硬件故障方面的适用性。
硬件架构指标评估旨在实现以下目标：
——客观可评估性：指标是区分不同架构是否可被理解的方法；
——支持对最终设计的评估（即根据选定的详细硬件设计进行评估）；
——提供依赖于ASIL的通过/失败标准，以评估硬件架构的充分性；
——揭示安全机制的覆盖范围是否足够，以防止硬件架构中单点或残留故障风险（单点故障指标）；
——揭示安全机制的覆盖范围是否足够，以防止硬件架构中潜在故障带来的风险（潜在故障指标）；
——解决单点故障、残留故障和潜在故障；
——确保硬件故障率不确定性的鲁棒性；
——限于与安全相关的元素；
——支持在不同元素级别上的使用，例如可以将目标值分配给供应商。
8.4需求建议
8.4.1此要求适用于安全目标ASIL (B)、C和D。
注：即ASIL A的目标可不参照该章节。下文类似地方同理。
8.4.2安全机制对与安全相关的硬件元件的诊断覆盖范围应根据残留故障和相关潜在故障进行估计。
8.4.3应确定分析中使用的硬件部件的预估故障率。
8.4.4如果无充足证据证明硬件故障率，应有替代方案，若该替代方案只包括增加安全机制，则：
a）硬件部分对残留故障的诊断覆盖率应等于或高于该项SPFM（单点故障指标）目标值；
b）硬件部分对潜在故障的诊断覆盖率应等于或高于该项LFM（潜在故障指标）目标值。
8.4.5对于每个安全目标，ISO 26262-4:2018, 6.4.5中要求的单点故障指标（SPFM）的定量目标值应基于以下参考目标值：
a）从硬件架构指标出发，应用于类似的可靠设计；
注意：两个相似的设计具有相似的功能和相似的安全目标，但分配的ASIL相同。
b）参考表4.
注意：该量化指标旨在提供：
——设计指导；
——设计符合安全目标的证据。
8.4.6对于每个安全目标，ISO 26262-4:2018 6.4.5中要求的潜在故障指标(LFM)的定量目标值应基于以下参考目标值：
a）从硬件架构指标出发，应用于类似的可靠设计；
b）参考表5.
9 硬件故障评估
9.4.1.2此需求适用于ASIL C/D。硬件部件的单点故障只有在以下选项之一提供了其发生概率足够低的论证时才被认为是可接受的：
a）采取专用措施；
b）对于ASIL D的安全目标，需满足以下标准：
——使用可信的数据源；
——仅有一小部分故障率（如一种特定的失效模式）会违反安全目标；
——单点故障率小于第一类故障率对应值的十分之一。
c）对于ASIL C的安全目标，需满足以下标准：
——使用可信的数据源；
——仅有一小部分故障率（如一种特定的失效模式）会违反安全目标；
——单点故障率小于2类故障率对应值的十分之一。
注：基于这一要求，微控制器、ASIC或类似的SoC可以被视为硬件部件。
上面提到的“专用措施”包括：
a）设计特征，例如硬件部分过度设计（例如电或热应力额定值）或物理分离（例如印刷电路板上的触点间距）；
b）对来料进行特殊的样品测试，以减少发生这种失效模式的风险；
c）老化测试；
d）作为控制计划一部分的专用控制集；
e）与安全有关的特殊特性的分配。
9.4.1.3适用于ASIL C/D。
残留故障与单点故障类似，此处不再赘述，可查阅原标准。
9.4.1.4此条适用于ASIL B、C和D。分析中使用的硬件部件的故障率应根据8.4.3进行估计。
9.4.2随机硬件故障指标评估(PMHF)。
9.4.2.2此条适用于ASIL B、C和D。
ASIL | 随机硬件故障指标值 |
D | <10−8 h−1 |
C | <10−7 h−1 |
B | <10−7 h−1 |
注：所述的量化目标值可按4.2中所述进行调整，以适应项目的特定用途（例如，如果项目违反安全目标的时间超过乘用车的典型使用时间）。 |
9.4.3.5只有在相应的硬件故障率等级排序符合表7所示目标的情况下，硬件发生的单点故障才被认为是可以接受的。
表7硬件单点故障故障率分类目标
9.4.3.6只有故障率等级排序符合表8给出的硬件残留故障诊断覆盖率的目标，硬件中发生的残留故障才被认为是可接受的。
9.4.3.11适用于ASIL C/D。如果相应的硬件部件符合表9所示的故障率类别和诊断覆盖率（关于潜在故障）的目标，则发生在硬件部件上的多点故障并导致可能的多点故障应被认为是可接受的。
10.4.4硬件测试用例应使用表10中所列方法的适当组合来派生。
10.4.5硬件集成和验证活动应验证硬件安全要求实施的完整性和正确性。为了实现这些目标，应考虑表11所列的方法。
10.4.6硬件集成和验证活动应针对环境和操作应力因素，验证硬件的耐久性和鲁棒性。为了实现这些目标，应考虑表12所列的方法。
四、新能源汽车V字形开发流程
（原创 王小奎 新能源汽车电控开发与测试）
V字形开发流程，即V模型，是在快速应用开发(RAD，Rap Application Development)模型基础上演变而来，V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。
V流程分为需求分析、系统设计、软件设计、软件实现、HIL测试、台架测试、实车标定、产业化等等步骤。
V字形开发流程阶段
1、需求分析
本阶段主要内容如下:
1)需求文档化
分析客户需求，研究受控对象，明确控制功能及系统配置，形成需求描述文档。
2)开发流程及规范建立
开发流程及规范建立
命名规范建立
模块测试流程/专家检查流程建立
建模规范建立
测试规范建立
2、系统设计
主要工作内容:
创建各模块控制思想的数学化/工程化描述文档 SDD(Software Design Document)
创建各模块数据传递接口文档 DD(Data Dictionary)
确定控制器IO 和通讯接口
设计文档建立标准:
SDD 设计文档图形化、逻辑化，且易于理解
DD 文档输入输出定义清楚、全面
控制器接口电路图规范清晰
3、软件设计
3.1控制功能建模
使用模型化的编程工具 Matlab/Simulink 软件,完成整车控制器控制功能各模块模型搭建。
3.2软件检查
为了保证软件模型的质量，完成模型之后完成模型的 MAAB 规范检查和 Model DesignVerifier，同时确保模型生成代码之后，做 Miscr C 和 PolySpace。
3.3 模型测试
控制策略完成后，进行模型在环测试(MiL)，用于在生成代码之前保证控制逻辑的正确性与准确性。根据目标车辆特性搭建车辆模型(或在已有模型基础上修改，车辆模型不作为本项目提交物)，并设计测试用例，对控制策略模型进行测试，提供详细的测试报告。
4、软件实现
基于第三方的控制器硬件，通过控制器硬件识别的编译器,将 simulink 模型软件编译成 C 代码，然后把 C 代码与控制器底层软件打包集成编译成可执行代码，下载到对应的控制器中，为后续测试环节做准备。
5、HiL 测试
内容主要包括以下内容:
整车控制器核心控制算法功能测试;
诊断功能测试;
网络通信测试;
极限工况模拟测试
编写 HiL 测试报告；
6、台架测试
台架测试主要针对整车控制器、与电机台架联合调试。台架测试主要工作内容如下:试验前准备工作，
上电及基本初始化标定，各工况下系统功能测试及标定，控制参数/特征值优化，控制算法验证/测试，系统行为评定整理测试数据，撰写测试报告。
7、实车测试
硬件平台在装车时，需在实车上进行整车控制器的标定，采用基于硬件供应商所支持协议的方式测试。在提供的国内试验场地进行，标定工作达到功能需求和性能要求，工程师负责程序调整和标定参数调整。标定工作在本项目指定的目标车型上进行，实现整车控制器的参数优化。
8、高低温测试
在厂区基本测试和标定之后，进行低温和高温试验，低温试验具体在环境仓中进行或者在实地测试场进行:根据 SOP 的时间，高温测试可以考虑环境仓或反委试验进行，制定整车控制器高低温测试工作。
五、汽车V模型开发模式
（原创 汽车技术Wind 软件赋能汽车）
也许，会有同学好奇，汽车也有软件吗？是的！以前的汽车凭靠机械系统/液压系统就能实现汽车的基本功能。而现在的汽车所需要的功能越来越复杂，车身重量也越来越轻，传统的机械系统和液压系统已经不能满足这些需求了。
因此现在的汽车不仅仅有软件，而且软件的重要性在汽车身上发挥的作用越来越大。特别是汽车行业正在经历的变革：自动化，电气化（新能源），车联网，数字化。
学过计算机软件的同学，应该都知道软件开发的模型有很多：瀑布模型，V模型，螺旋模型，快速原型模型，增量模型，喷泉模型等。而汽车软件的开发模型是怎样的呢？
汽车软件传统的开发模型——瀑布模型/V模型
汽车软件，就目前而言，是嵌入式软件。如果看过以前写的一篇文章《汽车为什么会跑——汽车电气架构简介》，那你能知道，目前的汽车电气架构主要是分布式的电器架构。意思就是将汽车的功能分解到各个功能模块，由每个功能模块负责一部分功能。因此，汽车的软件复杂度，相比于IT软件，并没有那么大，但质量要求相对非常高。
汽车行业为了解决软件开发过程中的各种问题，先后引入了瀑布模型，V模型。
什么是瀑布模型？
瀑布模型是于1970年温斯顿·罗伊斯（Winston Royce）提出的，其将软件生命周期分为若干阶段和固定的顺序，形如瀑布流水，最终得到软件产品。直到80年代早期，瀑布模型一直是唯一被广泛采用的软件开发模型。瀑布模型是软件开发模型的始祖，在软件工程中占有举足轻重的地位，提供了软件开发的基本框架。后续的V模型，螺旋模型，快速原型模型，增量模型，喷泉模型等都是在瀑布模型的基础上改进或借鉴。
瀑布模型的核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型示意
从以上图可以看出，瀑布模型的过程是自上而下，下一工序基于上一工序的工作结果完成任务输出结果。在开始下一工序之前，需确认上一工序的工作结果。若确认上一工序的工作结果，才继续下一步工序。否则返回前一工序，甚至更前面的工序。
瀑布模型有以下优点：
· 按阶段划分的检查审核，保证质量。
· 分工明确，每个工序中的人只需要关注当前工序。
· 瀑布模型可用于迭代模型。
每次迭代都是一个小的瀑布模型，经过每次迭代，不断完善完成整个系统的功能。
· 模板化，标准化。系统分析、设计、编码、测试和支持等工序在相同的模板和标准下，朝着相同的方向前进。
瀑布模型有以下缺点
· 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
· 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
· 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
· 瀑布模型的突出缺点是不适应用户需求的变化。
什么是V模型？
V模型，即RAD（Rapid Application Development，快速应用开发），是由瀑布模型演变而来的，也是目前汽车行业运用最广的软件开发模型。
从上图可以看到，V模型是从上到下，从左到右，也是从下到上的开发流程。从上到下依次分为系统需求，系统架构，软件需求，软件架构，软件详细设计，软件单元（代码）。从上到下的流程是不是看着很像瀑布模型的流程？从左到右是指每一层级都有相对应的测试，如系统需求对应的系统测试。如当系统需求完成，下层级的系统架构，软件需求就会开始工作，于此同时，系统测试也将开始编写测试用例和搭建测试环境。而从下到上是指测试从下往上一层层的测试。如系统测试的开始条件是系统集成测试/软件测试完成且无无重大bug。
总的来讲，V模型是对瀑布模型的细化和完善。相对瀑布模型，V模型的优势在于：
· 解决瀑布模型中严格分离很难实现的困境。
· 软件回溯较为方便快捷。
· 测试提前，及早发现问题，解决问题。
· 问题追溯性更强。
· 提高了开发效率/降低开发成本。
不过V模型和瀑布模型一样，过程中产生大量文档，项目反应速度也越来越不能满足当前汽车日新月异的需求和快速的更新换代的节奏。
但不能不承认，V模型在汽车行业的深刻影响。汽车行业的公司其技术部门组织架构/研发体系几乎都是参照V模型设置。而且很多的汽车行业标准和规范的基石都是V模型。比如，汽车行业很火的ASPICE，ISO26262（道路汽车功能安全规范），都是参照V模型的。《ASPICE在汽车行业越来越“火”，那么什么是ASPICE呢？》，《汽车功能安全简介——ISO26262》
当车联网，OTA，域控制器，普及之后，汽车软件质量要求可能就不用这么高了。汽车软件开发模型将逐渐向Agile（敏捷开发）模型转变。
尽管V模型优势不再那么明显，但相信它在汽车行业依旧会存在。特别是其良好的可追溯性和软件质量的把控，是不能被Agile（敏捷开发）等新的开发模式所完全取代的。而且，只要ASPICE，ISO26262没有被其他标准取代，那么V模型就一定还会存在，且发挥很大的作用。
来源：汽车企业项目管理大会
---汽车行业业务---
汽车行业产品开发兼职顾问（对公）
FMEA培训、辅导、审核、润笔、软件
问题解决/8D方法培训、辅导、支持
汽车行业工程师培训（招聘、培训，推荐）
汽车行业工作中问题解决支持（对私）
大四毕业论文指导（对私）
汽车行业专业书籍/知识代寻
----欢迎联系咨询---
【寻求合伙人】：汽车行业工程师培训（招人、培人、推人）
感兴趣者扫码联系：
更多信息链接：
