整车SOA系统设计

引言：

《浅谈整车SOA架构》系列分为四大部分，层层递进，干货满满，千万不要错过哦：

1. 背景介绍（已发表，点击可看）

2.大家眼中的SOA（已发表，点击可看）

3.我眼中的SOA（已发表，点击可看）

4.《整车SOA系统设计》(本篇)

01

SOA架构

1）架构是什么

首先，SOA架构师在整车项目开发过程中，承担着整车SOA系统设计的职责，而系统设计过程，需秉承一套可以被分享，可以被评审，可以被记录，可以被流程化的设计思路，这就是“架构”，它是一套如何以服务的形式组织整车功能的决策集合。

架构师要确保设计好的架构风格可以指导整车功能的组织和划分，并确保整个功能架构在汽车生命周期中可持续进化，此外架构设计需要关注功能性，复用性，性能，兼容性，经济和技术限制，商业等，而系统的具体功能信号和算法并不在架构的职责范围内，这些必须留给专业的功能架构团队。

2）为什么需要SOA架构

和任何其他复杂架构一样，整车软件必须建立在坚实的基础上，如果不考虑关键方案，不识别出常见问题，或者没有意识到好的决策能够带来长期受益，这些都将使整车应用架构面临高风险，整车功能变得不稳定，不易扩展，也很难适应不断变化的用户需求。

当前汽车发展面临着两大难题，如下图，一个是不断增加的汽车数量，预计到2025年，网联汽车可达到4.7亿量级，这其中8百万辆将是自动驾驶汽车，由此可见，云端互联和自动驾驶需求急剧增加。

自动驾驶需求，导致汽车内软件代码到达几亿行，整车软件代码出现井喷式的增长，这样整车相当于20台个人电脑以每小时超过25G的数据在运行，而传统CAN等网络极大的限制了汽车行业的发展，因此以太网作为车内主干网是必然趋势；云端互联需求，使汽车成为数字世界的一部分成为可能，这样智能汽车可以像手机一样，即使销售后，依然可以持续升级性能，整车功能可以持续创新，让汽车成为一种服务平台，这才是软件定义汽车的真正价值。

当前整车电子电器架构，功能不集中，分散到不同ECU，使得功能和信号交互异常复杂，代码和逻辑冗余相当严重，而互联网思路不断涌入汽车行业，汽车电子电器开发也必须要拥抱变革，并尽快适应变革，与时俱进。

SOA架构理念，来源于软件技术，在互联网行业已经应用了很多年，是一种非常成熟的技术，从全球角度，中国互联网的水平已经可以说全球领先，而汽车引入SOA理念，是一种全新的尝试，如果在汽车内落地好SOA，同样能够让中国汽车弯道超车，赶超世界先进车企。另一方面，各大互联网企业蜂拥而上进入汽车行业，也验证SOA引入汽车行业的必然，说明SOA的发展趋势是对的，也是大有可为，毕竟资本都是趋利。

为了和云端能够很好的互联，车端软件、通信、信息安全等必须能和云端环境很好的协同，实现一整套车云生态环境，因此车端采用可扩展到云端的基于服务通信SOA是最有效的落地方案，而设计SOA架构时需要先关注以下问题：

• 应用需要如何应用到产品中？
• 用户需要如何使用这些应用？
• 服务如何做到松耦合，以允许复用性和扩展性？
• 性能属性需求有哪些？

• 考虑现在或者未来的架构发展趋势，需要提前兼顾未来发展趋势，如果不兼容未来架构，那这个架构就不具复用性，从而违背SOA架构设计初衷。
  

3）SOA架构的目标是什么

架构是产品需求和技术需求之间的一座桥梁，必须准确理解产品需求，理解应用用例，并将对于产品需求的理解通过最合适的方法，落实到软件上，以实现这些应用用例，因此架构需要识别影响应用结构的需求。好的设计是在软硬件技术发生变革，用户需求发送变化的情况下，依然能够保持架构的灵活性。那什么是好的设计呢？好的设计是可以公开系统结构，隐藏实现的详细信息，可以实现所有用例方案，并协调解决和落实各个利益相关方的关注点，兼顾功能和质量需求，并保持架构可持续的被复用，同时能够支持不断进化。

4）架构设计方法

首先，SOA架构设计首先应该识别整车都有哪些类型的应用，以及理解这些应用将如何实施，只有这样才能将架构理念落实到实际的架构风格和技术，最后还得关注一些全局设置，比如场景，性能属性，需求，限制，安全等。

比较抽象的是架构风格和性能属性，其中架构风格就是一整套设计原则和规则，比如设定需要集成的系统所用到的服务类型，服务交互关系，以及交互限制，又如基于规划策略，协议栈限制，资源限制等待选择合适的技术和协议，简言之，架构风格就是限定如何集成系统。性能属性，主要涉及认证、安全，和易维护性，重点关注架构中涉及的严重问题，并和需求进行综合评估和权衡，同时性能属性要和功能系统完全独立，从架构角度来说，实施性能属性规划可以极大的提升系统性能。

架构设计原则大致有包含：

• 从最上层分解整车和功能，将系统划分为不同的子系统
• 整车功能完全独立不重叠，一个子系统只承担特定的一个功能特性，同时一个功能特性也只能在一个子系统中，不能在其他系统中重复定义
• 子系统通过接口来交互从而不关心其他子系统的内部功能逻辑
• 在功能细节不明确，或者功能不断进化的情况下，需要避免过早的进行大量设计工作
• 服务进行分层管理，将相同类型的服务打包到相同的服务层，决不允许将不同类型的服务放到同一逻辑层，尽可能做到服务组合，而非迭代继承服务
• 在严格服务分层下，服务之间不能跨层调用，同时要保持服务的独立性
• 不同服务分层中，避免数据类型格式的转换，比如频繁的物理值和信号值之间转换是必须要避免的
• 性能属性代码必须尽可能的从应用功能逻辑代码中抽离，如果将两种代码混杂在一起，会导致架构难以扩展和维护，性能属性代码的更新，需要同步修正功能逻辑代码

• 建模分析和可视化仿真工具分析：提前识别风险和漏洞，尽可能简化软件开发

02

SOA架构设计

整车开发过程中，SOA架构师需要参与的阶段如下：

1）电子电器架构

SOA架构依托于车载以太网，以太网拓扑是所有SOA设计工作的前提条件，必须在项目启动时，首先确保是可落地SOA的电子电器架构，因此SOA架构师需要结合产品部门提供的产品特性，梳理出整车以太网架构的需求，从架构关注点、功能需求、兼容性和发展趋势等方方面面出发，和产品，功能架构、平台软件等相关同事共同确认电子电器架构，确定以太网主控芯片、通道数量、带宽等信息，现阶段，讨论最多的是域控制器架构或者Zonal架构，如下图所示，至于如何选择，这边就不介绍了，毕竟不同的OEM有自己的不同考量，关注点区别很大，但如果OEM暂时还没有域控制器架构或者Zonal架构的需求，也可以在座舱域率先落地局部SOA服务设计。

域控架构图(来自网络)

Zonal架构图(来自网络)

2）协议栈和软件架构

当整车SOA架构通信协议完成既定的以太网拓扑和选定的SOA服务协议，SOA架构师需要参与协议栈和软件架构的设计，通信关注点主要有：

• 整车软件架构设计
• 通信协议相关软件选择
• 是否需要AUTOSAR系统

• 工具选择

SOA架构师主导的过程如下：

1）SOA协议选择

作为整车SOA策略设计者，需要根据实际应用和条件选定合适的SOA服务通信协议，制定初步的服务通道策略，当下可供选择的SOC(Service-Oriented Communication)协议有SOME/IP，DDS，MQTT，HTTP，协议区别如下：

当然协议的选择，很大程度上依赖供应商能够提供哪些SOC协议，这其中涉及很多妥协，因此最好在零部件定点前完成协议选择，以便针对所选择的SOC协议，对供应商提出一些具体的需求，同时作为定点供应商的依据。

2）SOA架构设计

SOA架构设计是整车开发的中间过程，需要遵循严格的输入输出模式，形成流程，确保刷选出所有影响架构的因素，提前规避架构风险和漏洞，同时在重新设计架构时，设计流程可以循环使用。

SOA架构设计的输入主要有：

• Use case和应用场景
• 功能需求描述文档
• 非功能需求，如性能，安全，详细软件架构等文档
• 以太网系统设计
• CAN网络拓扑和系统设计
• 云端资源

SOA架构设计输出主要有：

• SOA架构重新定义后的use case文档

• SOA架构重新定义后的功能描述文档

• SOA架构策略规范

• 服务定义文档

• 服务开发文档

架构设计步骤，每个步骤都可以分开细化成更详细的过程，并支持不断迭代，最终产生最优化的应用架构：

I）梳理整车功能：将整车功能按照SOA架构思路，设计成独立可复用的服务，重构功能体系II）规划SOA架构：根据梳理后的整车功能，设计详细的SOA架构，设置性能属性，比如服务升级策略、安全策略、异常处理III）服务定义：定义不同类型的服务、服务接口、数据类型等IV）服务矩阵和Arxml设计：针对不同服务协议，定义服务之间的交互和通信行为，创建服务通信模型V）服务验证和仿真：服务矩阵和Arxml释放前，需要保证正确性，因此必须进行服务验证和仿真

在整个SOA架构设计过程中，SOA架构师需要将自己的设计思路，设计成果不断的同步和分享给相关方，从5个不同角度——4+1，不断评审和修正SOA架构：

4个角度落地SOA架构：

• 从功能逻辑角度，梳理后的SOA服务架构提供真实的软件框架
• 从过程角度，从服务设计到服务落地
• 从物理角度，将对应的服务和服务架构分配到对应的硬件ECU中
• 从开发角度，矩阵可明确指导开发，同时Arxml可以大大缩短服务开发时间

1个角度规划未来：

• 对服务进行开放，为未来应用提供可能

3）服务实现 

完成SOA架构设计之后，SOA架构师的工作并没有就此结束，需要同步规划服务实现、联调和测试计划，制定和发布合理的时间计划，组织不同部门同事和供应商确认细节，不断的介绍、解释、分析自己的设计，直至所有相关工程师理解和认可释放的服务和策略，同时跟踪解决SOA架构和服务实现问题，指导服务软件开发，把控整个实现进度。