汽车行业SOA架构对服务的定义

ZHAOHUI 2022-12-08 发布于上海

展开全文

写在最前面：

在软件定义汽车的浪潮中，中国的主机厂面对的第一道考题，就是如何建设自主独立的软件平台。进而达到软硬件分离，软件定义汽车的目的。作为传统的汽车人如何张开环抱拥抱互联网的冲击，学习精华尽快完成转型是不容易的

作为一个传统汽车人，叠加消费电子产品经理，不只是工作，也是爱好和一份思考，将所思所想所学所知整理成文章。才疏学浅，请各路大咖指正，参与讨论。

01.

SOA架构相关

设计与开发SOA的流程，从描述到代码。

从头说起吧，整个从系统到代码的大致流程应该是这样的：

首先需要整理出整车功能配置列表，这个步骤需要输出整车级别的逻辑架构与功能需求文档；
接下来子系统和功能的网络架构，输出功能的拓扑图和具体布置到那个硬件中，类似电子电器架构的输出物；
做系统架构，在子系统内部定义出服务和公共的接口的设置；
系统中的服务架构和服务的网络关系，输出配置方案；以上四步都是用系统的视角在推进工作，从第四步开始进入了软件的内容定义，算是进入了软件领域。
HPC内的架构，输出是将内容模块化，以及写码的规则方法；
最后就是做具体的软件架构生成二进制代码。

后面我会用具体案例和比较说明如何定义一个服务，这里想先预先说明

对于定义服务或服务体系结构，没有通用的标准方法。SOA是一种逻辑推导，而不是一种技术。
服务定义基于特定的功能和特性体系结构，和需求相关和硬件相关，因此通常在产品的设计和生命周期中不断变化。
为了优化服务架构，通常会进行多次迭代，例如将SW功能切换到服务(在集群或应用程序级别)。
服务架构设计可以与软件架构工作相比较:抽象级别和技术不同，对工程师的要求也是相似的。

02.

关于Service的颗粒度是逻辑推导，没有简单定义

比较晦涩难懂，举个例子吧。

所谓服务是一个个独立的，可以反复利用的，并且易于链接的函数，可大可小。基于这个定义那么，独立性，低耦合性，接口通用性就成为服务的三个特性。

如果我们把信号流看做最小的服务，那么硬件能实现的最小功能就是最基础的服务，如何来定义的颗粒度呢？比如我们把“远程召唤”作为一个要实现的场景，其中的服务设定为“发动”+“行驶到指定位置”+“自动泊车”，为什么要把这三项分开，而不是把“远程召唤”定义为一个服务？原因很明显“发动”和“自动泊车”是高频使用的功能，他们非常的独立，又有可以重复使用的部分。

那么如果我们增加了“循迹泊车”的功能，服务设定为“行驶到指定位置”+“自动泊车”，那么也许再结合“完成锁定通知”就可以重新我们就会把“跑步”独立成一个服务。最终“健身运动”=“跑步”+“机跑步”+“俯卧撑”+“洗澡”；“夜跑”=“操场”+“跑步”+“洗澡”。

用这个比喻就是想说明，所谓服务的定义，没有统一的原则方法，是一种逻辑推导，需要有很强的逻辑能力，需要对工程有深刻的理解，需要对整车功能的关联性有深刻的理解。所以经验对于SOA的设计是至关重要的。如果展开说去，服务的排列顺序，服务的选择组合都和对车的理解有关，尤其再加深一步到时序相关，牵涉到强实时性的信号流与服务流的结合，就需要对车的功能有更深一步的了解了。这可能也是很多纯粹的互联网企业，拥有强大的软件实力，确难以很好的完成整车软件平台的原因之一。

03.

用一个具体的feature来说说SOA

首先，我们假设有如下这样一个功能需求的描述作为输入.

Feature Description: Park Buckler

Part_1:定位停车车辆的GPS位置，利用当地的天气信息(暂定为雨)控制所有的窗户(包括天窗)，在窗户没有完全关闭的情况下自动关闭。同时，在关闭所有窗口之前，用户应该能够通过安装的前摄像头检查天气状况，以验证是否下雨。

Part_2:车辆停放并上锁后，如发现车辆未经授权进入，系统应通过智能手机APP以录制或直播视频数据或消息的形式通知用户。

可以看到这里对功能需求的定义是非常粗略的，远远没有达到完整的详细的水平，那作为一个平台级的功能的开发，是如何将一段描述一步步拆解为可以打包成服务的代码的呢，我们一步步来看。

首先，进行函数树的分析，类似于思维导图，弱逻辑强发散，旨在把所有和功能的相关项目进行罗列。如下图，对用户设置的检测，通知用户，预设条件检测，周围环境检测，内部座舱检测，确认车锁，确认车窗，确认车的定位，确认时间，确认下雨...在这些一级条件之下，还有更多的二级条件，三级条件...最终形成下图

那么在有了发散的函数树型图之后，接下来基于弱逻辑的图，对功能需求形成有逻辑的描述。

Design Requirements (REQ-General):

1.先决条件检查(即:硬件安装和健康状态，电源模式，电池水平)在启用Park Buckler功能之前.

2.故障的判断机制----为了避免故障事件数据通过车辆状态的组合发送给用户(例如:门的关闭和锁，窗的位置，公园，小屋和报警状态)作为算法设计的一部分。

3.用户体验-手动(或默认)启用/禁用的选项和灵敏度的调整，给定的功能应该提供给用户通过车内娱乐系统或智能手机应用程序。还包括三个级别的灵敏度设置(低，中，高)。

4.连通性——为了避免网络连接不良，系统应该能够在本地录制视频数据，然后在连接恢复正常时将数据传输到云/用户。

Design requirements (REQ-Automatic Windows Close if Raining):

5.准确性:除了REQ-General外，检测算法还应包含GPS数据(确定位置)、导航和光数据(确定室外或室内)、雨传感器数据(利用红外光数据确定雨)和相机数据(利用视频或图像数据确定雨)。

6.在满足REQ1, 2, 3, 5设置的条件后，激活Windows。

Design Requirements (REQ-Unauthorized Access):

7. 准确性:除了REQ-General之外，检测算法还应包括接近数据(确定入侵者接近车辆的方向和区域，以初始化预触发阶段)、客舱摄像数据(确定乘员)或/和客舱体积数据(确定乘员)。

8.在满足REQ1, 2, 3, 7设置的条件后，激活Windows.

再有逻辑性的功能描述之后，有必要的移步是手绘出完整的这个功能的逻辑走向，将之前细化分析出的影响功能的相关像都包含在内，并且显示出输入纯属出的逻辑关系。也有的开发者会运用熟悉的工具例如Preevision直接就做了。但我认为这一步还是非常有必要的，任何工具都没有办法完整的满足现在日益增加功能需求，并且存在配置的不完备之处。在计划的初期就能对整套功能有完整的解构，并且存档，无论是对新来者的理解帮助，还是对主机厂自身知识体系的建设都有很大的帮助。如下图。