关于汽车SOA的思考
文章平均质量分 85
关于汽车SOA的思考
昊叔说车
记录智能汽车混沌时代的历史变迁
展开
-
关于汽车SOA的思考(五)
再说开发,还是上面这个例子,有了SOA后,这个场景应用其实就是简单的服务组合,对于开发人员来说,只要把需求设计按逻辑梳理明白,开发非常简单,甚至有很多软件供应商提供的“拖、拉、拽”式的工具即可简单完成。最后说说部署,由于这种脚本化的应用只要车端有个相当于“解释器”的运行环境即可更新,很多供应商提出了不用OTA,“在线热更”的概念,区别于OTA的“刷机”,“传脚本”的方式的确更简单。然而,通常固定在前排椅背上的大屏,距离被“绑”在儿童座椅中的娃是那么远,小朋友很难自己去操作,还是得闹着开着车的妈妈切换节目。原创 2024-04-19 13:30:16 · 993 阅读 · 1 评论 -
关于汽车SOA的思考(四)
各种整车SOA解决方案/产品不断地在各个行业会议中疯狂地刷着流量,似乎通过“SOA+工具链”实现“千人千面”“海量应用”成为了汽车行业决胜的关键,然后在花样繁多的POC展示后,“汽车人”们发现了一个问题:整车API一说就是上千个、工具链一整就是可视化配置所见即所得、演示效果就是啥“女神模式”……完了,软件供应商进入盲区了,不懂车啊!咱就会“云”“大屏”“智能语音”“AI”这些消费电子里的概念,对了,反正车上的功能都变成API了,调用呗,那就干脆“云”控车、“屏”控车、“语音”控车、“AI”控车……原创 2024-04-18 07:07:39 · 636 阅读 · 0 评论 -
关于汽车SOA的思考(三 )
不同域控,可能M核芯片都不一样,这样技术就碎片化了,技术成本与管理成本都提高了。由于控制的内容基本就是门锁、车窗、空调之类,所以产生了统一的对外服务需求,同时这些基本功能也是大部分的实现方式是把这些服务放在车机里(SDK形式),但车机还是存在熄火下电的问题,每次在调用服务前还需要通过蓝牙或短信唤醒车机,从而产生了延迟大、失败率高等不良体验。所以,OEM应该根据管理体制,去决策服务是放在M核还是放A核,但服务管理本身,放A核更合理,那这个A核负责部门,就要去做这个服务管理,然后对接不同M核部门来注入服务。原创 2024-04-17 07:00:07 · 386 阅读 · 0 评论 -
关于汽车SOA的思考(二 )
服务”是面向应用开发者的,传统的信号让大量的开发者陷入控制一个功能需要去思考很多个信号的组合(比如,空调需要“上电”“开关”“压缩机启停”等不同信号),但应用开发者其实主要精力是考虑什么样的场景去控制空调,需要的是一个简单易用的“空调服务”,通过简单的“温度”“风力”“风向”参数即可实现调用操作。整车应用有很多个,比如100个吧,每个应用能分解出10个“最小集功能”,将分解出的“最小集功能”做“合并同类项”操作,最后就只剩55个,那么这55个理所当然的就是“原子服务”了。咱们下期再聊聊这个话题。原创 2024-04-16 07:03:07 · 675 阅读 · 0 评论 -
关于汽车SOA的思考(一)
在传统的企业级应用领域,面对这种困境,就诞生了以SOA为理论基础的ESB(企业服务总线)技术,简单点儿说,就是各业务系统本身都是独立业务(功能)单元,对外只提供有限的、标准化的服务接口,而这种服务接口统一在一个“服务总线”内进行管理,任何业务流程中,如果需要什么功能,就在这个“服务总线”内去调用相关的服务接口。恰巧2017年的时候AUTOSAR发布了AP,区别于CP的面向信号通信,面向服务的通信使得车端软件设计发生了巨大变革,而“汽车服务总线”的概念也随着AP的推广与普及,逐渐进入到车端软件开发者的眼中。原创 2024-04-15 15:54:28 · 864 阅读 · 1 评论