汽车软件开发车载与非车载软件分类及差异雷火电竞
既然汽车软件是非常复杂的，种类繁多自是预料之内，我们先来解决这个最基本的问题。
最正宗的汽车软件当属ECU里的软件，也就是车载软件。直观来看，就是固定在车上，并通过线束与电气系统或其他ECU连接起来的物理盒子。
ECU已经在汽车行业存在了近60年，但直到现在，ECU仍然是谈论汽车软件时的主要对象。
只不过，随着汽车电子电气架构的演变，ECU的功能越来越集中化，也即现在炒得热火朝天的域控或中央计算。
无论如何，形式上来看，ECU或DCU都是嵌入在物理盒子里的车载软件产品。
首先，基于这两年广泛流传的博世五域划分，可以将车上的电子软件功能进行分区，即动力域（车辆运动）、底盘域（安全）、车身域（车身电子）、座舱域（娱乐信息）和自动驾驶域（驾驶辅助）。
这五域划分可以给我们一个大框架的参考，但对于我们区分开发模式来说，并不够友好。
第一类：与整车高度耦合或安全等级较高的模块，如发动机控制、电机控制、刹车控制、电子助力转向控制、车身稳定控制系统ESP、混动系统控制、安全气囊控制、电池热管理等。
第二类：功能独立且安全等级较低的车身控制模块，如网关、照明控制、雨刮控制、车门车窗控制、无钥匙启动、天窗控制、座椅记忆控制、后视镜控制、功放控制等。
除了车载软件，还有一部分是非车载类软件，他们也广泛地存在于汽车行业的各个领域。
包括云平台（如数据埋点后台、电池状态远程监控、OTA运营平台）、工具链软件、生产用下线电检软件（EOL，End Of Line）以及手机车联app和车机上的第三方app。
其中，云平台与app和互联网软件比较接近，车载软件和互联网软件则是完全不同类别的东西，谈论主体的不一致经常是两个行业背景的人进行鸡同鸭讲的原因之一。
当然呢，现在这些非车载软件还没有形成稳定及具规模的生态，所以本文后面部分仍然主要基于车载软件展开。
以上软件种类的划分会直接影响到后面6个特点的分布与侧重，阅读时可做关注。
所以，只要电子电气架构的集中化没有走到中央计算和云计算，只要供应链各方的软硬件自主权没有被收归一统，多层集成就不可避免。
一直以来，大家习惯于在各自的电脑上、台架上完成开发与验证，然后在集成点处进行确认。
“各人自扫门前雪”的协作惯例能让分工清晰，也会让几乎不可避免的问题延后暴露。
整车碰撞试验会花费高额的成本，一旦试验失效，时间和金钱都是巨大浪费，前期的联调非常必要。
比如，安装方向、传感器位置、线束连接、电阻范围、DTC状态、软件版本及对手件响应等的联调确认。
与其他模块或整车耦合程度没那么高的模块（第二类），联调必要性就会减弱。比如，简单的天窗控制模块和方向盘加热模块，可能台架上连接一个电机和加热垫就绰绰有余。
智驾的开发验证可以依赖一部分，但终归需要整车的调试标定，尤其需要运动控制部分的功能完善。
智舱集成了大量的人机交互内容，无论是控制指令的发出，还是反馈信息的投屏，大屏正在变成人与车的I/O口，这让座舱的开发颇为困难，所谓联调或者协同验证的意义和必要性也十分显著。
总之，我们已经看到了这样的趋势，联调正伴随着架构的集成化逐渐演变为对整车整体的评价。
仿真也是个非常古老的东西，但它的发展看起来始终有些缓慢，汽车开发的各层级开发验证，都难以离开真实的物理环境，也就是车。
车很贵，工程车尤其贵，退而求其次，大家用模拟信号与负载、用简易台架加ECU、用白车身、用拼凑的实车......
而求其次自然会求来软件版本不对齐、验证负载不充分、暴露问题不及时等等各类次的问题。
受制于样件和实车的环境是汽车开发的特点，特别地，在架构融合的过渡阶段，更耦合的功能、更多的交互，会让现在这种单一仿真环境凸显出更大的问题。
一切的软件都需要进入整车，从整车层面解决客户需求，而进入的第一步和主要步骤还是通过生产装配，特别是对于第一类软件。
ASPICE也曾被人捧上神坛，最近一两年，大约是因为全行业灰头土脸，精致昂贵的ASPICE逐渐被人报以微笑。
反复思考、反复调研，我认为ASPICE还会一定程度地回归，会随着行业生态的恢复和产品方案的成熟逐渐体现出其必要的规范性意义。
但是还有一点要说明，ASPICE的分层意义可能会随着架构集中的进一步发展而减弱，比如，软硬解耦后，软件开发中一直关注的系统（软+硬+...）就没太大存在必要了。
原本呢，这部分算是传统汽车暨三大件被绕过后还剩余的技术门槛，但是，新势力进来后，先是一波高薪，两三年就培养出一大批功能安全工程师，人才多少是有点饱和了。
年初，特斯拉又掀起一波价格战，多米诺骨牌，各大车企还陆续开启裁员。一阵寒意后，功能安全？饭都吃不饱了，自己都不安全了，还管功能安全不安全。
很显然，特别是对于第一类（与整车高度耦合或安全等级较高的模块）和第三类（智能驾驶）软件，功能安全非常重要，只是这个魔幻的阶段暂时让它无所适从。
讨论总是需要在同一概念基础上的，所以首先区分了汽车软件的分类，最典型的当属车载软件，我们按照开发模式的差异性分成了4类，而行业的方向正在向非车载软件延展。
对于分布式架构和协同供应链下的车载软件，多层集成是其非常直接的特点，大体来看，从代码到整车可分为5层。
每个集成点都是一个接口，接口之间是需要联调的，尤其对于跨模块、多接口的复杂系统。而随着架构的集中化，这种趋向整车级的评价会是越来越突出的趋势。
同样地，在OTA足够可靠之前，汽车软件不得不考虑其对生产的影响和生产对其的影响。
ASPICE和功能安全是不同性质的要求，但都是期望将行业的躁动按住一点，将开发的混乱规范一点，将安全的地位拔高一点，但是现在的环境暂时让二者难以生存。
汽车软件的特点与两个老生常谈的概念密切相关：软件架构的软硬耦合和整车电子电气架构的分布式。
声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。举报投诉
的一系列步骤和方法。它包括以下几个主要阶段： 需求分析：在这个阶段，根据
的设计目标包括极致性能、高安全性、标准化、高实时性和简单易用，满足未来
充电器有手机充电器、笔记本电脑充电器、电动牙刷充电器等等。这些充电器在使用时需要
越来越重视性能、质量和性价比，自动驾驶口碑成为新技术应用取得市场成功的关键，而口碑的建立依赖于相关软 件
最佳实践是必要的，因为安全风险无处不在。在网络攻击盛行的时代，它们可以影响每个人，包括个人、公司和政府。因此，确保
与落地，联合电子正式发布 USP2.0（UAES SOFTWARE PLATFORM）
标准，最著名的应该是V模型。以V模型为代表的有ASPICE、 ISO 26262 和 ISO/SAE 21434。今天我们主要以ASPICE为基础，探讨V模型在当前
部分，一般是通过程序设计语言实现的，比如C/C++/JAVA/JSP/ASP等
越来越重视性能、质量和性价比，自动驾驶口碑成为新技术应用取得市场成功的关键，而口碑的建立依赖于相关
中的综合使用效果。本文揭示，从研究和产业的角度来看，如何将敏捷方法和V模型这两种方法结合起来，目前还不清楚。本文的研究结果
ASPICE全称“Automotive Software Process Improvement and Capacity Determination”，即“
的流程包含“阶段”“活动”和“任务”三个要素，它们规定了参与者需要完成的工作。不同的参与者在
的态度一直在演变。ISO 26262、MISRA 和其他标准旨在通过为在
SoC产品R-Car系列的第三代产品正在量产。2021年之后，我们将使用R-Car VPF进行新产品的
，问我需要学习什么内容。今天在这里做一个分享，希望可以帮到这位朋友以及以后想要从事
知识储备1.1 ECU/MCU相关基础知识1.2 C语言编程知识1.3 外围电路2 MCU
，都会涉及到“电源状态迁移”，这个是一个最基础的知识，但是往往在实际工作中，即使有过几年
大会（AutoSW） 诚邀来自OEM、一级供应商、科技公司的战略官、首席技术官、
支付”能力落地的车企，预计2020年第二季度打通小鹏账号、支付宝账号及小程序功能，以“
量已经达到几千万行代码，甚至超过1亿行，测试的工作量和复杂程度已远远超出了
系统有限公司今日宣布，Klocwork 已加入 QNX® ISO 26262
防盗的智能化程度。另一方面，缩小了装置的体积，提高了该装置应用的灵活性，同时也为将来进一步增强
,UNIX ，是一个强大的多用户、多任务操作系统，支持多种处理器架构，按照操作系统的
，属于分时操作系统，最早由KenThompson、DennisRitchie和DouglasMcIlroy于
随着嵌入式系统在通信、网络设施、航空、航海和航天等领域的大范围应用，需要功能强大的
导航装置芯片的升级换代，文章应用ARM 芯片HMS30C7202 和linux 操作系统
1 逻辑类问题（A类）－指设计、编码中出现的计算正确性和一致性、程序逻辑控制等雷火电竞官方网站
扫一扫关注微信公众帐号
