广告
软件定义汽车落地实践案例：联合汽车电子
SOA 软件架构设计方面
联合汽车电子：
在某客户项目中，整车厂规划基于新一代中央域控+区域接入的电子电气架构实现整车功能服务化，联合电子应用业务驱动型开发方法帮助整车厂完成整车服务架构设计。
图 6-3 SOA 服务架构设计过程展开
业务驱动型指从业务用例出发，以服务为导向，正向设计 SOA 汽车软件的开发方法。在设计过程中，通过“业务过程分析”、“服务操作分析”、“候选服务分析”三个步
骤，解决“应该构建哪些服务？”、“每个服务应该封装什么逻辑？”两个核心问题。
以雨刮子系统为例，客户提出雨刮低速、雨刮高速、雨刮点动等多个场景用例，分析过程如下：
业务过程分析：
采用用例驱动的方法来分析业务需求和过程。用例驱动指从用户使用的角度而非开发人员的角度考量功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和服务操作之间清晰的追溯关系，为抽象和封装服务提供充足的语境信息。
雨刮低速
雨刮高速
雨刮点动
服务操作分析：
服务封装的业务逻辑，由服务操作实现。服务操作代表了服务所执行的特定动作，可类比软件中的方法或函数。
服务操作分析过程
候选服务分析：
“SOA 汽车软件分层模型”为候选服务分析提供了有价值的参考。根据重用性和自主性的面向服务设计原则，参考三层模型设计元服务和基础服务。对元服务和基础服务的设计，SOA 鼓励即使没有立即重用的要求，也要根据服务导向的设计原则促进重用，因此潜在的重用也要考虑在内。通过良好的 SOA 设计，当业务用例增加，或原有业务用例发生变更时，良好的基础服务和元服务设计，保证了重用性和较少的软件变更，从而实现更快速高效的功能迭代和清晰明确的版本管理。
候选服务分析结果
服务接口设计：
服务接口设计是服务架构设计过程中的重要一环，在候选服务分析完成后，大致暴露的服务接口会被确定，服务接口决定了服务之间的动态数据交互，决定了业务逻辑的行为和功能，需要在迭代中不断完善，反复更新。
此处，值得一提的是原子服务和设备抽象服务接口的设计和定义), 设备抽象服务解决电子电气架构中不同执行器/传感器暴露统一的接口问题，原子服务则对传感/执行器的语义做统一的规划和定义。联合电子将对原子服务和设备抽象服务接口的设计定义为平台驱动型(由下至上)设计方法下的工作产出。
当前，软件定义汽车工作组发布的API 参考文档为定义智能汽车软硬件接口标准化的规范性文件。工作组通过对 API 接口的标准化定义，为各领域带来全新的体验，联合电子也正在参与 API 接口定义工作，并在项目上进行应用实践。
服务部署：
在 SOA 软件开发过程中，服务的部署涉及到整车电子电气架构的信号矩阵。对于业务驱动型分析方法，功能需求导向是设计原则，对于Tier1 熟知的业务逻辑领域，推荐Tier1 提供具体服务模块的部署信息， 这些部署信息作为正向设计的产物，会体现在后续的整车厂整车软件架构之中，是整车厂设计整车信号通讯矩阵不可或缺的重要一环。
在 SOA 软件架构下，整车厂整体把握软件架构的总集成方，Tier1 作为各个业务领域(车控、底盘、动力、高级辅助驾驶系统等)的合作伙伴，将作为组件负责人向整车厂提供对应的架构描述文档，最终系统级的架构设计文档由整车厂输出，并结合软件模块和基础软件部分，完成各个子系统的集成。
图 6-4 SOA 架构在软件中的实现过程
联合电子认为， 面向服务化的软件架构，未来将促进多个供应商体系下软件集成互相协同。在这样的方案里， Tier1 会充当 Component Designer 的角色，是Component 的“专家”，对组件内部的架构设计和业务逻辑有着主导权；组件与组件之间的接口则由整车厂来承担和定义，Tier1/软件供应商在严格遵照该定义后，将软件架构和软件模块以固定的形式持续向整车厂推送。未来逐步迭代和成熟的接口也将是软件定义汽车的标准接口，其一定程度的抽象可以形成行业内的标准规范。
- 下一篇：软件定义汽车落地实践案例：岚图汽车
- 上一篇：软件定义汽车落地实践案例：一汽集团
广告
最新资讯
-
CATC-ITEC专题工作组会议在慕尼黑成功举办
2024-05-01 21:29
-
初创加速计划 | AI 赋能水面自动驾驶技术，
2024-05-01 21:25
-
“反人类”的隐藏式门把手，新能源车为什么
2024-05-01 18:30
-
加速战略创新，采埃孚与富士康完成底盘系统
2024-05-01 18:17
-
某新能源商用车制动疲软问题的改进分析
2024-05-01 17:50
广告
广告
