汽车软件开发V-model

最新推荐文章于 2025-03-01 16:59:47 发布

DAI 123

最新推荐文章于 2025-03-01 16:59:47 发布

阅读量1.4k

点赞数 3

分类专栏：汽车电子文章标签：汽车软件工程

本文链接：https://blog.csdn.net/daizhifeng123468/article/details/130559525

版权

汽车电子专栏收录该内容

1 篇文章

订阅专栏

文章介绍了汽车软件开发中的V模型和瀑布模型。瀑布模型按照严格的顺序执行，强调阶段间的文档和审查，而V模型则是在瀑布模型基础上增加并行测试，每个开发步骤都有对应的测试活动，以尽早发现和解决问题。V模型适用于汽车行业的高质要求，但也存在文档工作量大和应对变化不灵活的问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

汽车软件开发V-model

1、前言

软件开发的模型有很多：瀑布模型，V模型，螺旋模型，快速原型模型，增量模型等。汽车软件的开发模型是什么样的？

目前的汽车电气架构主要是分布式的电器架构。意思就是将汽车的功能分解到各个功能模块，由每个功能模块负责一部分功能。因此，汽车的软件复杂度，相比于IT软件，并没有那么大，但质量要求相对非常高。

汽车行业为了解决软件开发过程中的各种问题，先后引入了瀑布模型，V模型。

本篇主要介绍汽车开发中的：瀑布模型和V模型

2、瀑布模型

2.1、瀑布模型的简介

在这里插入图片描述

瀑布模型是于1970年温斯顿·罗伊斯提出的，其将软件生命周期分为若干阶段和固定的顺序，形如瀑布流水，最终得到软件产品。直到80年代早期，瀑布模型一直是唯一被广泛采用的软件开发模型。瀑布模型是软件开发模型的始祖，在软件工程中占有举足轻重的地位，提供了软件开发的基本框架。后续的V模型，螺旋模型，快速原型模型，增量模型，喷泉模型等都是在瀑布模型的基础上改进或借鉴。

从以上图可以看出，瀑布模型的过程是自上而下，下一工序基于上一工序的工作结果完成任务输出结果。在开始下一工序之前，需确认上一工序的工作结果。若确认上一工序的工作结果，才继续下一步工序。否则返回前一工序，甚至更前面的工序。

2.2、瀑布模型的优点

按阶段划分的检查审核，保证质量。
分工明确，每个工序中的人只需要关注当前工序。
瀑布模型可用于迭代模型。
每次迭代都是一个小的瀑布模型，经过每次迭代，不断完善完成整个系统的功能。
模板化，标准化。系统分析、设计、编码、测试和支持等工序在相同的模板和标准下，朝着相同的方向前进。
严格地规定了每个阶段必须提交的文档；

2.3、瀑布模型的缺点

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
瀑布模型的突出缺点是不适应用户需求的变化。
阶段间具有顺序性和依赖性

①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；

②前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果

3、V模型

3.1、V模型简介

在这里插入图片描述

“V”模式开发模型是汽车电子行业在瀑布模型的基础上做了改进，以符合汽车ECU开发需要的模型。由于模型构图类似字母V，所以又被称为V-model。

目的是为了改善早期软件开发使用的瀑布模型中，错误只有到开发后期的测试阶段才能发现的弊端，V-model将软件生命周期中的每一个开发活动，都对应一个测试活动，并且两者同时进行。所以，V-model的核心，就是一个并行的观念。

3.2、V模型使用的工具链

从系统需求到软件需求，再到软件的释放，需要工具对其进行管理，以达到可追溯，可记录的目的，目前市场主流的工具含有 Doors,ClearCase,GIT,SDOM 等，同时也有公司自己研发的一些流程工具。这些工具的运作方式都遵循需求，研发，测试的V流程。
在架构设计过程中，需要使用EA架构设计工具，isolar等AUTOSAR配置工具。
软件实现过程中，需要使用到Matlab等模型开发工具。
软件组件集成过程中需要使用到编译工具。
软件组件测试过程中需要使用到Tessy等测试工具.

3.3、V模型的开发步骤

3.1、系统需求

这部分为系统需求。需要系统工程师完成。
基于项目的整体需求，以及软硬件整体定义，对系统逻辑架构进行整体定义，这部分工作包括：硬件功能定义，控制器与其他控制器通信定义，软件简要功能定义。这个过程并不会对具体的技术实现做出定义。
通常会使用Doors等软件定义系统需求。

3.2、系统架构

通常和第一步并行，并在系统需求文档中体现。第1和第2步都是系统层级的，下面应该分软件和硬件两个分支，这里我们只关注软件这个分支。

3.3、软件需求

这部分为软件需求，需要系统工程师完成。
系统工程师根据系统相关方需求说明书、软硬件接口文件、变更通知书等输入，梳理定义软件研发需求说明书，包括操作系统需求、电源管理策略、传感器读取，执行器控制、信号特性需求、存储服务、通信服务，网络管理、故障诊断、标定、程序升级等功能需求和非功能需求。
根据项目规划，制定软件开发计划。
软件需求分析建立需求追踪矩阵，将软件需求映射到系统需求，确保软件要实现的系统需求全部覆盖，为了完成这个功能，通常我们也是使用Doors等流程软件完成。

3.4、软件架构

这部分为软件架构，需要架构工程师完成。
为了建立清晰的、结构化的软件设计，应该统一分配软件需求，然后完成软件架构设计。根据系统相关需求、软硬件接口表、软件需求确定软件架构。将每条软件需求合理分配到软件模块中，定义每个软件模块的输入输出接口、动态行为、资源消耗目标等，评估多种软件架构的优缺点等。
架构工程师需要使用EA等架构软件画出整个控制器软件所有模块的输入输出接口、以及内部动态行为。
如果项目基于AUTOSAR开发，需要架构工程师配置应用层的所有组件，并输出每个组件的ARXML描述文件。
一般来说，还需要架构工程师输出架构文档。

3.5、软件详细设计

这部分为软件单元设计，需要软件开发工程师完成。
在此阶段，需要对每个组件内部的算法逻辑进行详细的内部设计。组件功能的详细设计需要与软件需求建立有效的对应关系。
软件单元设计需要输出单元设计文档

3.6、软件单元实现

这部分为软件实现，需要软件开发工程师完成。
此阶段进行模块设计的实际编码。根据系统和架构的要求确定最合适的编程语言。
如果是算法逻辑编码，建议使用Matlab进行模型开发，如果是接近底层的复杂驱动，一般是使用手写代码。
如果项目使用AUTOSAR架构，使用模型开发时需要导入arxml生成模型框架进行开发，使用手写代码进行开发时需要使用AUTOSAR工具生成的组件代码框架进行开发。
需要将代码经过多次代码审查和优化之后，将最终版本上传至代码库，以实现最佳的可靠性和性能。