汽车软件开发流程,汽车软件开发流程 入门
汽车上VCU什么意思?
VCU是实现整车控制决策的核心电子控制单元，一般仅新能源汽车配备、传统燃油车无需该装置。
VCU通过采集油门踏板、挡位、刹车踏板等信号来判断驾驶员的驾驶意图；通过监测车辆状态(车速、温度等)信息，由VCU判断处理后，向动力系统、动力电池系统发送车辆的运行状态控制指令，同时控制车载附件电力系统的工作模式；VCU具有整车系统故障诊断保护与存储功能。
如何检测汽车零部件？
以动力电池为例介绍一下新能源汽车动力系统部件的测试，欢迎开发测试工程师一起交流、指正：
动力电池系统作为硬件本体和控制系统结合极为紧密的系统，其测试大致可以划分为两大部分：电池包本体（Pack）测试、电池管理系统（BMS）测试，下面分别介绍这两部分的测试情况；
1. 电池包本体（Pack）测试
电池包本体测试一般在DV/PV（设计验证/生产验证）阶段进行，目的是为了验证电池包的设计/生产是否符合设计要求。其中包含温度测试、机械测试、外部环境模拟测试、低压电气测试、电磁兼容测试、电气安全测试、电池性能测试、滥用试验测试等等。因为大伙都比较关心电池安全问题，在这里主要介绍一下电池包滥用试验的测试方法：
1) 针刺测试
模拟电池遭到尖锐物体刺穿时的场景，因为异物刺入有可能导致内部短路，试验要求不起火不爆炸
2) 盐水浸泡
5%盐水长时间浸没测试，电池功能正常
目前新能源汽车电池包防水防尘等级推荐是IP67（即1米深的水浸泡半小时无损坏，上汽、蔚来的电池包都是IP67）。汽车的使用环境恶劣，再怎么做防水防尘保护也不过分（上海有一年暴雨导致车库积水，传统车都淹挂了，而电动车完好无损）。
3) 外部火烧：
590摄氏度火烧持续130秒电池无爆炸、起火、燃烧并且无火苗残留。
4) 跌落：
1m高度自由落体在钢板上电池壳体完整功能正常
5）振动测试
高频振动模拟测试，要求电池包功能正常。做电池包的同事应该知道，这个也很难通过。
2. 电池管理系统（BMS）测试
电池管理系统的测试更多侧重软件测试，一般在软件功能开发过程中进行。
与尚未量产的自动驾驶系统偏向于使用C语言实现软件设计不同，现今成熟的电动汽车控制系统（如整车控制器、电机控制器、电池管理系统）软件都是以模型为基础的软件开发（Model-Based-Design）。MBD开发相比C的优点是能够以图形化的方式表达复杂的逻辑、代码可读性、可移植性、开发调试便利程度都大大增强，同时利用成熟的代码生成工具链，也避免了手工代码容易产生的低级错误。在基于模型的软件开发环节中规定了MIL/SIL/HIL等多项测试：
1) MIL(Model-In-Loops)既模型在环测试，就是验证软件模型是否可以实现软件功能，测试依据是由系统需求分解而来的软件需求。
2) SIL(Software-In-Loops)软件在环测试，对比模型自动生成的C代码和模型本身实现的功能是否一致，使用Simulink自身工具就可以进行Sil测试。
3) PIL(Processer-In-Loops)处理器在环测试，目的是测试自动生成的代码写入控制器后，功能实现上是否与模型有偏差。PIL看似无关紧要，但不做重视也会引起一些不良后果（如调度问题、CPU Load，堆栈溢出等）
4) HIL(Hardware-In-Loops)硬件在环测试，测试控制器完整系统功能，一般会搭建控制器所在系统的测试台架，使用电气元件模拟传感器（如温度）和执行器（如风扇负载）的电气特性，验证完整的系统功能。
这些测试环节的用例来源于系统需求。在汽车软件开发流程中，开发和测试成V字型进行，俗称软件开发V模型，感兴趣的同学可以查看汽车软件开发流程ASPICE。
统开发流程中非常强调测试软件环节的。要知道手机软件出问题最多也就是秒退而已，车辆软件出问题影响的是人命。
当年丰田刹车门事件，美国政府就派了嵌入式软件专家和卡耐基梅隆的计算机教授详细审查了发动机控制系统的软件代码，丰田对全局变量的滥用（上万个）以及软件安全机制的混乱就遭到了巨额处罚。如果丰田重视软件测试工作的话，这件事也许不会发生。
最后再聊下零部件在整车极限环境下的测试情况：整车耐久测试这部分工作一般是整车厂的测试标定工程师负责。整车耐久试验的花销很大，造工程样车（每辆100万左右）、租用测试场地、工程师团队花销，很考验厂家的资金实力，没有强大的资金池根本无法运行起来。但在极寒、高温、高湿度等各种极限环境下的测试进行的越多，越能充分的验证零部件的功能、性能以及耐久表现，越早发现问题，解决修复所耗费的成本越低。
1. 低温耐久测试，主要测试冷起动性能，一般在黑河/牙克石进行。电池包的低温充放电能力、低温保护策略、电池包加热功能在该项测试中都会进行考核。
2. 高温耐久测试，一般在格尔木进行。主要测试电池包在高温下充放电能力、电池包冷却功能和过热保护策略。下图是蔚来在澳大利亚墨尔本进行高温测试，为了整车开发整车厂都是不惜成本。
3. 高温+高湿环境耐久测试，一般在海南进行，海水环境会加速部件腐蚀，零部件的耐久会经受严格考验。（Ps：传统车还有重要的高原测试，主要测试在低气压下发动机的性能表现。电动车一般不需要进行此项测试。）
电池包做的比较好的都会承诺使用寿命内的电池衰减，比如蔚来ES8就承诺10年30万公里电池容量衰减不超过20%，做电池开发的都知道做到这个水平是非常不容易的。敢公开承诺也说明他们的电池包耐久测试做到了非常优秀的水平。
汽车软件客户端的安全防护措施有哪些？
我认为，汽车软件客户端的安全防护措施主要有以下几点：
1.客户端安全防护
移动应用往往基于通用架构进行开发设计，安全逆向技术成熟，常成为攻击者进行协议分析和发起网络攻击的突破口。在应用正式发布之前，对主配文件Android Manifest.xml进行合理地配置，关闭Debuggable、allowBackup属性，同时关闭不需要与外界进行数据交互组件的exported属性，防止因为不合理地配置，造成移动应用安全风险。
同时，与国内外专业安全公司开展合作，通过代码混淆、字符串加密、变量名数字化、反调试等方式对车联网移动APP进行安全加固，防止移动应用被恶意破解、二次打包、逆向分析等。此外，在应用发布之前，邀请安全团队对车联网移动APP开展安全渗透测试，寻找漏洞并进行修复，借助安全厂商的力量提升车联网移动APP的安全。
2.通信安全防护
车联网环境中的车辆不再是一个独立的机械个体，而是借助各种通信手段和对外接口实现与外部终端进行数据交互。因此保证车联网移动APP自身安全以及提供安全可靠的对外通信策略对车辆与外部终端的连接和通信安全至关重要。
在车联网移动APP与TSP服务平台通信的过程中，使用HTTPS的安全通信协议，增加攻击者窃听破解的难度，同时使用基于公钥架构(Public Key Infrastructure,PKI)[5]的身份认证机制在每次通信时对车联网移动APP与TSP服务平台进行双向认证，保证通信双方的合法性。此外，在通信的过程中对关键数据流量进行加密处理，防止中间人攻击和重放攻击。
3. 数据安全防护
车联网移动APP在使用的过程中，会在本地手机端存储部分用户敏感信息，例如手机号、登录密码、车辆Vin码等。采用加密的方式对移动端的文件、数据库等多种格式数据内容进行安全存储，以免数据在移动终端存储不当造成数据泄露。同时，防止密钥被泄露，避免将密钥硬编码到代码中，采用密钥分散技术和白盒密钥加密技术，提高密钥的安全性。
4.业务安全防护
开发者应遵循移动应用的安全开发流程以及安全开发规范，将安全意识融入到软件开发生命周期的每个阶段。同时，开发人员应积极参加软件安全开发生命周期(S-SDLC)[6-7]培训，强化开发者的安全开发意识，严格按照安全开发规范进行开发。
新能源WVU怎么检测？
新能源汽车是指纯电动汽车、插电式混合动力汽车和燃料电池汽车。我们常说的新能源汽车指的是混合动力汽车和纯电动汽车。
新能源汽车和燃油汽车相比最大的不同就在于不使用燃油或使用非常少的燃油，既然不使用燃油，那么就是零排放，那么，新能源汽车就不用年检了吗？答案是否定的，新能源汽车也需要年检的。
车辆年检，尾气排放检验只是其中一项，安全技术检验是很重要的环节，新能源汽车也不例外。环检与安检“两检合一后”，环检是安检的前提，环检不达标，不能进行后续的安检。
纯电动汽车因没有尾气排放，故不用进行尾气检测，只用进行安全技术检测即可。
混合动力汽车是要进行尾气排放检测的，有手动行驶模式选择的混合动力汽车应切换到最大燃料消耗模式进行测试，如无最大燃料消耗模式，应采用混合动力模式测试，如测试过程中发动机自动熄火切换到纯电模式 ，无须中止测试，可进行到测试结束。
根据现行的GB21861-2014，新能源汽车的安检项目、方法和技术要求基本与燃油汽车没有区别，但是新能源汽车尤其自身的特点，其电路系统是关键，漏电保护装置是否有效、电压是否稳定、续航能力是否满足要求，GB21861-2014中并没有具体要求，这点已经不能满足要求。
但是，新的GB21861修订工作早已启动，对新能源汽车的安全技术检验项目和方法会更详细和明确，更具有针对性。
纯电动汽车的标志
所以说，在新的GB21861版本发布前，新能源汽车还是按照燃油汽车的安检项目和方法进行。新标准发布后，才会有新能源汽车量身定做的安全检测标准。
怎么样开发一个软件
1、软件开发的第一个流程是项目开发目的分析与确定，主要是在软件开发商将开发项目确定下来之后，需要与需求方进行讨论，确定需求方对于软件开发的需要实现目标及其具体需要的功能等等，并确定是否可达成；
2、接下来就是需求分析，这个步骤也是为软件开发的正常进行确定具体思路的阶段。在确定软件开发可进行后，必须要对客户需要实现的软件功能需求进行具体详细的分析。同时应当考虑在开发过程中可能出现的变化情况，制定需求变更计划随时应对特殊情况的发生，保证软件开发流程的顺畅进行；
3、接下来就是软件设计。软件设计要根据上一阶段对软件功能需求分析的结果，来设计软件系统的框架结构、功能模块和数据库等等。它主要分为总体设计和详细设计两个部分；
4、接下来就是编程实施步骤。编程也是根据对软件设计，将软件设计的各部分需求通计算机程序代码来实现运行，编程有统一、规范的程序编写规则，保证软件程序的易懂性、易维护性；
5、接下来就是软件测试步骤。也就是在根据设计将客户软件需用编程代码来实现之后，也就是软件程序完成之后，需要对编写的程序，形成整体构架、功能进行单元、组装、系统三阶段的测试，以测试程序编写的正确性，以及对客户需求功能满足的充分性，以此来确定软件是否达到开发要求，同时也是一个发现问题、纠正问题的过程；
6、通过以上核心环节完成了软件开发，接下来就是在软件开发达到客户需求之后，开发者将软件系统交予客户，并将软件安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等产物交付给客户，同时指导客户进行软件安装、以及安装技巧，提醒客户注意软件运行状况、环境、服务器及相关中间件的检测与注意事项，知道客户软件的实际操作方法、使用流程等等问题，实现合同规定任务；
7、用户在接受开发商交付的软件开发结果，并进行实际操作、测试运行，实现满意结果之后，对开发出来的软件进行验收；
8、定制开发的软件通常都需要提供售后服务，定期对软件进行维护，或者根据用户出现的新需求，进行应用软件程序的修改，使之不断满足客户实际需求。
软件定义汽车，架构定义软件
编者按：本文转载自微信公众号： 汽车 电子与软件。 汽车 之心经授权转载。
8月26日，江铃 汽车 CTO兼总裁助理黄少堂受邀出席 “SAE 2020 汽车 电子与软件技术论坛”，发表《软件定义汽车，架构定义软件》的主旨演讲。系统地阐述了软件定义 汽车 的背景、机会和挑战，并分析了顶层设计和实际执行中的痛点。
汽车 圈内人士更习惯称他黄堂主，笔者听过很多CTO的演讲，很少有黄堂主这样，纯干货、零带货的。听众评价他的演讲，不仅有掌声，还有笑声，掌声代表礼貌和敬意，笑声才是内心的共鸣。
*本文是根据现场演讲整理而写，尚不能领悟黄堂主精髓是万一，仅供交流、参考。
01
为什么强调软件定义 汽车 ？
今天所处的 汽车 时代，我们前人从来没有这么幸运过，也从来没有这么焦虑过，更没有体验过。每一天都不一样，即使我这样有几十年 汽车 电子经验的老行家，面对今天这样从未经历过的世界，又能好到哪去了？
最近，我们一直在思考，为什么业内突然兴起软件定义 汽车 ，而且如此红火。事实上，过去几年，如发动机的点火、喷油、排放，已经是软件控制了，底盘的AEB，还有自动刹车控制，包括自动转向。其实从底盘、传动、动力、车身，软件已经渗透到了几乎所有的 汽车 系统。但过去从没有像今天这样强调软件定义 汽车 。
为什么今天突然间强调软件？最近我拿了一台华为的P40，内存到达516G，相当于一台电脑。因为得益于芯片、互联网、大数据等技术的发展，在硬件的基础上，我们才得以在小的空间内做很多的事情。
另外，消费电子对 汽车 行业的冲击，人们的消费习惯和生活方式已经发生变化，促使人们的期望值不断的增加，人们不再忍受开一个豪华车，还用一个手机去导航。特别是90后、00后的消费者，他不再像我们这一代人买个宝马、奔驰，做点小生意，他们更强调个性化的展现。而当我们打开 汽车 行业的软件库时，发现我们的软件代码量已经超过了飞机，并不在其他行业之下。
02
特斯拉效应
记得2003年特斯拉成立的时候，当时我们在美国通用，对它不屑一顾，觉得它就像小孩玩玩具，闹不了几年的。时至今日，还有哪一个老牌 汽车 企业敢轻视特斯拉？人家只卖36万辆车，还不用赚钱，而大众、宝马、奔驰、通用、福特，这些传统车企加起来卖2000多万辆，但他们加起来的市值却抵不过特斯拉。说明 社会 不认可传统车企在创造价值。包括国内的新势力，别看车子只卖几万辆，甚至亏本，但与国内领头的销售几百万辆的车企，市值相差并不多。
在国外，上市企业经营的目的就是为股票的拥有者创造价值，经营者的工资是以股价来论的。你可以想象传统车企的管理者的压力，当初的通用贱卖土星、庞蒂亚克、悍马也是不得以而为之，华尔街的人坐在你办公室，你不卖，就得自己下岗。克莱斯勒当初也是因为股票不景气，迫使被菲亚特接收。
像我这样早期对特斯拉不屑一顾的，今天再来看他们，Model S的网络架构拓扑图，非常规矩，这样的拓扑图很好，拿到一个拓扑图，用一个CANoe或者Vehicle Spy工具可以立项他的原始结构。第二代适当加了一个集成，到了第三代，你再用传统的电子电气拓扑图去画，画不了，也立项不了，简直就是杂乱扔在一起的。它的能力在域控制器里面，在软件里面，你从外表去仿画他的架构，很难做到。 特斯拉重新换了一种不遵守 汽车 行业传统法则的方式，自己单跑了 。杂乱中，其实彰显了它的软件能力。
03
架构定义软件
我们注意到，最近各大车企成立软件中心，但很难招到人，IT的人做嵌入式软件是一个鸿沟，虽然都是软件，但不用的平台，不同的应用，有着相当大的差异。从架构到云管端，因为结构不同，控制方法不一样。我们通常讲结构下的软件。我们先要定义软件架构本身，再定义功能，再建立通讯网路。
首先要定义好架构，然后针对场景的设计，比如自动驾驶的场景、路面， 娱乐 系统，商用车、物流车的场景跟乘用车又不一样，场景定义就不一样。回顾 汽车 网络架构，以前只有电器架构，没有什么电子和软件。比如发动机点火就是用一个高压线圈，开关一弹，能量释放，产生火花，点火。油是共轨的，哪个阀门开了，就滴到哪个油缸里。后来才有了基于发动机的电子模块，也就有了电子电器架构。现在，随着智能网联 汽车 的发展，特别是自动驾驶以后，将演变成车、路、人协同电子架构。
在传统 汽车 人看来，Model 3 的架构简直是一个大杂烩，而传统的车企，如大众MEB的架构就比较规矩，很难说谁的更好。但用户其实并不关心你背后的设计，这就是我们需要思考的。
打通任督二脉的关键恰恰在于整体架构，而软件是架构的关键要素，软件实现是战术，架构是战略。
车云一体电子架构是我们今后要做的事情，我们以前总是在做车上测试、网络测试、模块之间的测试。既然车云已经形成了，为什么不把车网跟后端网一起进行测试呢，每个信息传到后面如何保证是正确的。我们的测试流程里并没有涵盖ISO 26262，IOS 26262只是定义到车上的，如今的 汽车 哪里只是车上的呢？
所以你说特斯拉完全不遵守26262和AUTOSAR，也有一定的道理。 当他发现传统标准局限的时候，就需求创造出自己的路。
同样，车云一体的电子架构，他们各模块之间的协同，有哪个现有的标准可以参考呢？标准体系并没有完全跟上行业发展和产品的需要。我曾经当过两年ISO的编委，召集一帮人讨论两三年，究到每一个0和1, 严肃性是有的，但你可想而知，每个企业派出去的人，一般也不是最有价值、最忙的，我们不必将标准当成是圣经。我们需要尊重标准，但如果仅是知其然不知其所以然的使用，消费者并不会为这个买单。在传统的主机厂，上万人，最顶端的很难知道下面的事情。
我们的中央计算器，一定程度上要感谢芯片商的能力， 芯片能力的提升，促使电子架构向区域架构发展，从而为软件功能迭代提供硬件平台。 我们最早做ADAS，一个机械式的毫米波雷达的成本是3000美元，只有凯迪拉克上能配，今天已经下降到了两三百人民币。硬件成本的大幅度下降，才让智能 汽车 成为现实。我们今天谈智能，并不是我们的前辈很蠢，而是没有如今的整个技术环境支撑。
Model 3 的中央计算模块，采取区域控制，不是功能域控制，有人说是为了节省线束的成本。我的理解是，它把模块、智能配电、传统保险，都用电子保险控制了。而我们传统的网络架构，控制0和1，起步、唤醒、休眠。如果把电源都控制了，就不存在休眠、唤醒了，一通电都醒了，一断电都休了。既然把电分开了，就必须有前、左、右控制，如果把所有的保险都放一个盒子里，就变成烤箱了，所以有几级分电。这是基于功能的需要进行这样的定义。
传统的软件架构，有以下特点：
如果我要更新一个ABS，那关联的BCM、仪表、网关都要改，而且都分属于不同的供应商，代码也是别人写的。从这一点也应证传统车企被供应商绑架了。
新的软件架构下：
今天，在域控制器的概念下，关键的模块都是自己开发的，你要改一个节点，或者要改不同的节点，可以通过功能定义，不再以模块去刷新一个，而是以服务包的形式进行更新。而且软件还可以进行整个生命周期的收费，改变车企的运行模式。原来 汽车 卖出去以后，跟车厂就没有多大关系了。
当我们具备软件基础能力，软件模块需要做什么，车企的应用软件如何建立？
按传统思维，我们总希望通过智能驾驶一个方案做所有的，很多模块是一个公司做。按新的模式，做感知的、做定位的、做决策的、还有做执行的，用一个渐进的方式，不需要大，这样供应商就不是做一个模块，而是重复的流水线。我们所合作的企业并不一定要大，但是要精，然后不断地完善。这个时候软件就变成了一个标准化的工具。但我们需要把层级定义清楚，把接口定义清楚。
同样，智能座舱领域也是一样，我么把它分成几个模块，把底层定义清楚，主机厂有能力的多做一下，能力弱的少做一些。
软件的另一个核心是OTA，没有OTA软件的更新，软件也无法定义 汽车 。通过更新，可以不断地满足用户的体验，重新定义数据形态，根据软件更新的范围，内容，安全度，让 汽车 在生命周期内有再生命力。具体体现在：
OTA结合5G，再加上车路协同，整个生态链和供应链也将被重新定义。在这个全新的产业生态中，4S店的模式可能会发生颠覆。当你有大数据，有GPS定位，可以通过线上诊断、线下换件的形式。如果是涉及到软件更新，在家里就可以通过OTA修复BUG。
04
软件定义 汽车
我理解的软件定义 汽车 是： 软件深度参与整个 汽车 的定义、开发和验证流程，并不断优化客户体验，持续创造价值。
传统车企开发一个车往往需要三年，包括概念设计、定义方案，再冻结、下车体制做、样车制造、三高测试、标定等。如果软件定义 汽车 还在这样的流程下进行，三年前开发的软件，在三年后可能就已经被淘汰了。因此，软件定义 汽车 要颠覆整个 汽车 开发流程。这将是很多车企巨大的挑战，大公司制定流程往往是很大的梯队，而管理层中，基本都是做底盘、车身等传统部件的出身的，他们的软件的概念还比较缺乏。固化的流程让传统 汽车 人很安全、很可靠。这就制约了组织的更新和发展。
要实现软件定义 汽车 ，要没有一个革命性的，从组织架构，CEO层面变革，只可能被淘汰。
我读MBA的时候，去过芬兰的诺基亚。当时，整个芬兰为诺基亚自豪，这么小的国家，诞生如此成功的企业，它的手机以质量著称，充电可以用一个星期。苹果出来的时候，我们都笑了，不小心掉地上，屏碎了，每天还要跟祈祷一样，把电源插上去充电。其实诺基亚并没有做错事，当初MBA的范例都是它的成功。如果我现在再去读MBA的话，范例会不会是它如何失败的。时代在变，即使你没有做错事，但别人做的比你更好。
很多机械类的东西，要改一个字，开一个模，到今天仍然需要上千万成本。而软件只需要一次开发费。并且可以个性化的定制，借用其他行业的生态。 软件定义 汽车 的驱动因素 具体表现在：
用户层面：
OEM层面：
舒适的驾乘环境，改变未来出行方式
软件定义 汽车 赋能整个生命周期内，可以学习用户、车辆自身、周围环境并适时作出适应性调整。
05
软件定义 汽车 的要素
传统开发模型：
面向软件 汽车 的开发模型：
有人问，可不可以一步到位？虽然我们想这样，但一方面是自己没有这个能力，另一方面是供应商不是这么排的，而且这个过程是要跟供应商及整个供应链讨论的。你有多大的市场？怎么玩？谁有权力去定义这个规则？有权力定义规则的人生活已经很舒服了，为什么要颠覆自己呢？对于大多数传统车企，比较现实的策略是渐进式变革。
电气架构、远程升级、网络安全、大数据是软件定义 汽车 的基石。
智能互联和智能驾驶推动了 汽车 行业的升级。需要全新的网络架构，寻找新的合作伙伴，更广泛的生态系统和平台。比如芯片厂商、运营商、BAT等互联网公司，过去这些与 汽车 没有联系的企业都渗透到了 汽车 行业。再往后，公路局、收费站，国家检测局都将加入 汽车 生态圈。
06
软件定义 汽车 带来的挑战
随着软件越来越多，越来越复杂，软件之间的交互、测试，需要行业的共同努力，如果每个车厂都搞个自己的操作系统，都认为自己是最牛的，打开一看，其实都是抄了别人的，就改了两个字，把一个完美的东西改成了不完美的东西。
软件开发模式仍然 苦难重重 ：
短期阵痛：
软件定义 汽车 中长期挑战：
07
结语
我们今年所经历的时代是 汽车 行业前所未有的，在软件定义 汽车 层面，中国与世界同步甚至走在前列，没有对标与参考，在焦虑的同时，也是幸运的。需要行业同仁齐心协力、共同努力，我们要共享、讨论、坦诚布公，才可能取得共同的、共有的进步！
最后借用一句七绝：
百舸争流千帆竞
借海扬帆奋者先