引言
第一篇一、互联网与传统汽车人的碰撞二、从电子电气架构的演进看软件开发分工的变化2.1 传统的分布式的电子电气架构的问题
2.2 不同架构主机厂扮演的角色
2.3基于中央计算电子电气架构的优点
三、车载环境下的操作系统3.1操作系统的定义3.2内核分类3.3选择操作系统的核心因素如果业务有实时性要求,必然需要使用 RTOS,比如航天军工用的比较多的 VxWorks,车载用的比较多的 QNX。 芯片类型: 使用什么操作系统,往往取决于选择的芯片支持什么,没有芯片厂商的支持,一个操作系统走不远。嵌入式领域是ARM 的天下,处理器类型也决定了使用的操作系统类型,Cortex-A/M/R 用于应用处理器、低功耗、实时处理三个方面。 系统生态: 面向C 端用户的操作系统,应用生态决定了生死。面向行业的操作系统,比如汽车仪表、自动驾驶系统、网关,C 端用户是无法感知到底用了什么操作系统,开发者的态度决定了使用什么系统,没有人愿意在一个工具、库都支持不全的系统上开发软件。 3.4车载场景的操作系统选择四 中央计算电子电气架构下的基础软件平台4.1 问题描述4.2 核心诉求
这就是我想说的第二点,互联网的开发流程虽然不能直接套用在车上,但是其在软件工程领域的实践经验对于解决车载软件领域的问题还是很有帮助的。看起来是汽车电子软件开发的门槛高,其实是因为封闭和从业人员少。当前的机遇就是,大家都想往这个方向走,但是也都是摸着石头过河,可以有机会将这些理论经验用于实践。 以产品设计为驱动力,但目前同质化现象比较严重,主要以硬件差异为基础,只能利用先发优势,无法形成技术与产品壁垒! 基于用户画像,使用AI技术,构建具有情景感知能力的引擎,是智能座舱产生质变的前提,但技术上短期无法突破(行业普遍问题,不是车行业特有)。 多设备协同、多模态融合交互,是消费电子IOT场景下大家探索的方向,对于车载环境有很强的借鉴意义。 以算法与数据的积累为核心驱动力,可以在技术上形成壁垒,但是需要巨额的研发投入,能否快速落地主要受制于数字系统架构。短期来讲大家可能都差不多,但是积累到一定时间,后发玩家可能就再也追不上了。 以架构设计与资源整合为核心驱动力,其包含了传统意义上的电子电气架构,但需要横向整合多个软硬件架构部门,才能定义完整的系统架构。是否采用新架构从根本上决定了,智能座舱与自动驾驶究竟能走多快走多远。
一、智能电动汽车软件范畴动力与底盘控制器车身控制器中央计算单元二、软件+硬件皆可升级的基础
三、面向服务的架构设计
结语
一、SOA 基础软件框架
二、SOA 参考实现从Adaptive AutoSAR 和 ROS 当中,能够看到德系与美系架构设计思想之间鲜明的差别。我的第一感受是,美系架构设计更加简洁、灵活,追求开源。而德国人喜欢把简单的问题复杂化,喜欢过度设计,搞很深的抽象层次,喜欢搞代码生成,喜欢强绑定 IDE,这可能与他们工程师思维的严谨性有关系,总之搞得看起来门槛特别高,相关的公司还可以卖标准,卖工具,赚的盆满钵满。
三、DDS 与 SOME/IP
结语作者: 链接: |
|