互联网架构的软件架构是否会对车用软件等传统嵌入式领域的系统架构产生影响
目前大多数车用ECU基础软件架构还是OSEK/VDX，正在朝AUTOSAR架构方向发展。AUTOSAR是多数主流主机厂和零部件厂对今后车用软件架构发展方向的共识，其核心思想就是统一车用软件平台，达到应用软件复用的目的。理论上应该不会再推其他架构，比如你说的EB的多核系统（EB本身就是做AUTOSAR的）。目前汽车上还是采用以CAN总线为骨干网的分布式系统，未来几年内最有可能替代CAN的可能是CANFD（CAN的升级版）。汽车上越来越多使用以太网是一个发展趋势，但无论从成本、实时性来说，以太网还取代不了CAN。以太网目前主要用在ECU的诊断、标定和软件刷新上。题主说的网络架构我不太了解，至少目前来说不太可能实现。一个ECU上跑多核多系统本身就增加了系统的复杂性，而且汽车ECU讲究的是可靠、安全，不需要太复杂，但必须可靠、可预测。如果你这个ECU故障了需要更换的话，也可能增加了车主的维修成本。
■网友
以下是个人观点：1. domain controller的概念听说有些时间了，拿底盘上的ABS、ESP、转向控制器、悬架这几个控制器来说，那个实时性要求低？不太有可能把大部分功能集中放到一个控制器上实现，每个控制器责任少不了太多的话，成本也不会降太多，做域控没太大必要。 实时性要求低的车身、T-BOX、娱乐类的为了cost down，有可能做成域控制器。2. 现在tier1对各自模块的软件实现自由度较大，主机厂渴望从整车角度把握整体软件的实现（比如 底盘上几个控制器各自实现一定程度的车辆动态控制逻辑，模块间的影响较弱），即需要更深入的从整车角度控制车上软件的实现，特别是对tier1控制较弱的主机厂，这种渴望有可能在autosar的广泛应用带来的互操作能力（inter operability）下得到满足（现在的tier1和整车厂开发上的深度合作方式不能满足这种渴望），将来汽车软件工程师更多的在主机厂工作，开发完的软件零部件供应商集成到各自控制器中。这种开发方式和架构上的改变 相比一个控制器上集中大部分控制的架构 更有可能成为现实。3. 分久必合 合久必分 这种说法对架构的改变并不是因果关系。架构、技术趋势的改变更多来源于工程体验，市场体验中产生的痛苦和渴望。
■网友
问题提得挺到位，单从实时性和安全性上来讨论有点偏实现了，或者说本末倒置。IT系统和嵌入式控制系统首先是产品系统架构不一样，然后才是软件架构的差别。先系统，再硬件软件，才是分析的正路子。具体到软件架构层面，我认为几个趋势是一致的：1. 首先是接口服务化。AUTOSAR在RTE里面引入的重要概念就是cs和sr接口。这在IT里面普遍使用的socket几乎是老掉牙的东西了。嵌入式稍不同的是，底下很多还没走到tcpip。2. 计算并行化。分布式控制和云计算本质上是一个东西，但是上面提到的服务接口成熟度很不一样，所有嵌入式的应用还没运行过程中的部署一说，都是事先的设计和安装的，灵活性上差了好多。3. 动态组网。IT的整个基础设施是完备的，层层路由器和网管，各类厂商各安其位。汽车和家电在域内组网，各域再组网，涉及的关键网络部件都还不成熟。上述3个背景趋势下再来看hypervisor和异构平台所表现出的嵌入式软件虚拟化的趋势，就觉得嵌入式软件的成熟度和IT相比，还有好长路要走。毕竟从业人数都不在一个数量级上。
■网友
嵌入式领域换个单片机重新改代码,底层驱动和开发环境就折腾死人还会导致不可预估的风险,你和我说要换架构...没极大的成本和需求驱动谁会去做...都是现在用下来没问题,只要不是成本能省下来特别多,就继续凑合着用,因为研发也是要钱的...从需求上来说,汽车领域里可以预见的比较复杂的逻辑运算也就一个自动驾驶了,但是也并没有到必须更改架构的地步.而且用一个微控制器来大包大揽的做法,安全性必然不如分布式控制器.
推荐阅读
- 长春评选“网络奋斗者”：互联网成更多普通人创业工具
- 互联网怎样解决“家政服务上门速度慢”的问题
- 银行的数据中心可以跳槽去互联网公司吗
- 大学再有三个月就结束了，没学到知识，参加一个软件测试培训机构好吗
- 互联网在线音乐行业有哪些可能的盈利模式
- |常信院在第六届中国国际互联网+大赛中再夺金
- 互联网科技公司技术投入占比(占收入)?
- 大部分黑客或安全研究员读的是啥「大学专业 」
- 软件公司为啥频繁地在培训机构批量招人
- 京东的客服+网络安全啥水平