河南省住房城乡和建设厅网站首页,建设工程查询系统,深圳市建设,wordpress著名网站汽车软件开发属于较为复杂的系统工程#xff0c;经常让来自不同知识背景的工程师在观点交锋时出现分歧。在解决复杂性和对齐讨论基准时#xff0c;可以通过勾勒出讨论对象最关键的几个特征来树立典型概念。本文旨在通过5个典型特点的抽取#xff0c;来勾勒出汽车软件开发模式…
汽车软件开发属于较为复杂的系统工程经常让来自不同知识背景的工程师在观点交锋时出现分歧。在解决复杂性和对齐讨论基准时可以通过勾勒出讨论对象最关键的几个特征来树立典型概念。本文旨在通过5个典型特点的抽取来勾勒出汽车软件开发模式的特殊性和变迁性。 01.车载与非车载软件的分类及差异
汽车软件是非常复杂的种类繁多自是预料之内首先需要解决分类这个最基本的问题。 1.1 带物理盒子的车载软件
最正宗的汽车软件当属ECUElectronic Control Unit电子控制器单元里的软件也就是车载软件。直观来看就是固定在车上并通过线束与电气系统或其他ECU连接起来的物理盒子。
ECU已经在汽车行业存在了近60年但直到现在ECU仍然是谈论汽车软件时的主要对象。只不过随着汽车电子电气架构的演变ECU的功能越来越集中化——即现在炒得热火朝天的域控或中央计算。
无论如何形式上来看ECU或DCUDomain Controller Unit域控制器都是嵌入在物理盒子里的车载软件产品。 1.2 车载软件的内涵
除了形式再看功能内涵。首先基于这两年广泛流传的博世五域划分可以将车上的电子软件功能进行分区即动力域车辆运动、底盘域安全、车身域车身电子、座舱域娱乐信息和自动驾驶域驾驶辅助。 这五域划分可以给出大框架的参考但对于区分开发模式来说并不够友好。进一步的车载软件可以划分为四类
第一类与整车高度耦合或安全等级较高的模块如发动机控制、电机控制、刹车控制、电子助力转向控制、车身稳定控制系统ESP、混动系统控制、安全气囊控制、电池热管理等。第二类功能独立且安全等级较低的车身控制模块如网关、照明控制、雨刮控制、车门车窗控制、无钥匙启动、天窗控制、座椅记忆控制、后视镜控制、功放控制等。第三类智能驾驶ADAS、AD及附属的雷达或摄像头传感器等。第四类智能座舱或说车机主要是以各类大屏为承载的软件。 1.3 非车载软件
除了车载软件非车载类软件也广泛地存在于汽车行业的各个领域。包括云平台如数据埋点后台、电池状态远程监控、OTA运营平台、工具链软件、生产用下线电检软件EOLEnd Of Line以及手机车联app和车机上的第三方app。
其中云平台与app和互联网软件比较接近车载软件和互联网软件则是完全不同类别的东西谈论主体的不一致经常是两个行业背景的人产生分歧的原因之一。
当然现在这些非车载软件还没有形成稳定及具规模的生态所以本文仍然主要基于车载软件展开但是V2XVehicle to Everything车用无线通信技术作为热点趋势仍值得被关注。 02.从代码到整车的5层集成
汽车软件种类繁多、模块众多而且需要装在整车上跨模块、跨域体现功能所以只要电子电气架构的集中化没有走到中央计算和云计算只要供应链各方的软硬件自主权没有被收归一统多层集成就不可避免。 按照当下的架构发展阶段可以把汽车软件的集成分为5个层次
将软件单元集成到一起将软件集成到硬件上将硬件集成到机械壳体上将ECU 集成到子系统中将子系统集成到整车上 03.联调与整车级评价
汽车软件开发是个各模块或功能域协作的过程。一直以来大家习惯于在各自的电脑上、台架上完成开发与验证然后在集成点处进行确认。“各人自扫门前雪”的协作惯例能让分工清晰也会让几乎不可避免的问题延后暴露。
因此部分与整车环境依赖关系比较紧密的模块第一类会提前进行联调比如说安全气囊控制器整车碰撞试验会花费高额的成本一旦试验失效会造成时间和金钱的巨大浪费前期的联调非常必要比如安装方向、传感器位置、线束连接、电阻范围、DTC状态、软件版本及对手件响应等的联调确认。当然安全气囊太成熟、太传统软硬耦合程度太深了对于与其他模块或整车耦合程度没那么高的模块第二类其联调必要性就会减弱比如简单的天窗控制模块和方向盘加热模块可能台架上连接一个电机和加热垫就绰绰有余。智驾和座舱逐渐脱离了传统汽车软件开发模式而二者之间也有些不同。
智驾的开发验证可以依赖一部分仿真模拟但终归需要整车的调试标定尤其需要运动控制部分的功能完善。智舱集成了大量的人机交互内容无论是控制指令的发出还是反馈信息的投屏大屏正在变成人与车的I/O口这让座舱的开发颇为困难所谓联调或者协同验证的意义和必要性也十分显著。
总之这一趋势正逐渐显现联调正伴随着架构的集成化逐渐演变为对整车整体的评价。 04.开发验证受制于实车环境
仿真是个非常古老的概念其发展看起来始终有些缓慢汽车开发的各层级开发验证都难以离开真实的物理环境也就是车。车很贵工程车尤其贵退而求其次大家用模拟信号与负载、用简易台架加ECU、用白车身、用拼凑的实车......而求其次自然会求来软件版本不对齐、验证负载不充分、暴露问题不及时等等各类次的问题。
受制于样件和实车的环境是汽车开发的特点特别地在架构融合的过渡阶段更耦合的功能、更多的交互会让这种单一仿真环境凸显出更大的问题。 05.考虑生产
一切软件都需要进入整车从整车层面解决客户需求而进入的第一步和主要步骤还是通过生产装配特别是对于第一类与整车高度耦合或安全等级较高的模块软件所以汽车软件要关注制造、关注生产。原因有二
OTA技术、流程和监管还不足够成熟还不能自由OTA。现有的标准化生产方式仍然足够安全可靠。
同时ASPICE还会一定程度地回归会随着行业生态的恢复和产品方案的成熟逐渐体现出其必要的规范性意义其分层意义可能会随着架构集中的进一步发展而减弱。 06.全文小结
本文因汽车软件所在行业与产品特殊性首先区分了汽车软件的分类最典型的当属车载软件按照开发模式的差异性分成了4类而行业的方向正在向非车载软件延展。
对于分布式架构和协同供应链下的车载软件多层集成是其非常直接的特点大体来看从代码到整车可分为5层。
每个集成点都是一个接口接口之间需要联调尤其对于跨模块、多接口的复杂系统。而随着架构的集中化这种趋向整车级的评价会是越来越突出的趋势。
在仿真足够真实之前出于成本的考虑开发始终会受制于实车环境。同样的在OTA足够可靠之前汽车软件不得不考虑其对生产的影响和生产对其的影响。
总得来说汽车软件的特点与两个概念密切相关软件架构的软硬耦合和整车电子电气架构的分布式。而伴随着软硬解耦和架构集中化汽车软件的特异性会逐渐地演变乃至消亡。
原文链接汽车软件开发模式的7个特点
