引言
在软件定义汽车的浪潮中，中国的主机厂面对的第一道考题，就是如何建设自主独立的软件平台。进而达到软硬件分离，软件定义汽车的目的。作为传统的汽车人如何张开环抱拥抱互联网的冲击，学习精华尽快完成转型是不容易的。
作为一个传统汽车人，叠加消费电子产品经理，不只是工作，也是爱好和一份思考，将所思所想所学所知整理成文章。才疏学浅，请各路大咖指正，参与讨论。
一，SOA架构相关
设计与开发SOA的流程，从描述到代码。
从头说起吧，整个从系统到代码的大致流程应该是这样的：
1,首先需要整理出整车功能配置列表，这个步骤需要输出整车级别的逻辑架构与功能需求文档；
2,接下来子系统和功能的网络架构，输出功能的拓扑图和具体布置到那个硬件中，类似电子电器架构的输出物；
3,做系统架构，在子系统内部定义出服务和公共的接口的设置；
4,系统中的服务架构和服务的网络关系，输出配置方案；
以上四步都是用系统的视角在推进工作，从第四步开始进入了软件的内容定义，算是进入了软件领域。
5,HPC内的架构，输出是将内容模块化，以及写码的规则方法；
6,最后就是做具体的软件架构生成二进制代码。
后面我会用具体案例和比较说明如何定义一个服务，这里想先预先说明
1，对于定义服务或服务体系结构，没有通用的标准方法。SOA是一种逻辑推导，而不是一种技术。
2，服务定义基于特定的功能和特性体系结构，和需求相关和硬件相关，因此通常在产品的设计和生命周期中不断变化。
3，为了优化服务架构，通常会进行多次迭代，例如将SW功能切换到服务(在集群或应用程序级别)。
4，服务架构设计可以与软件架构工作相比较:抽象级别和技术不同，对工程师的要求也是相似的。
二，关于Service的颗粒度是逻辑推导，没有简单定义
比较晦涩难懂，举个例子吧。
所谓服务是一个个独立的，可以反复利用的，并且易于链接的函数，可大可小。基于这个定义那么，独立性，低耦合性，接口通用性就成为服务的三个特性。
如果我们把信号流看做最小的服务，那么硬件能实现的最小功能就是最基础的服务，如何来定义的颗粒度呢？比如我们把“远程召唤”作为一个要实现的场景，其中的服务设定为“发动”+“行驶到指定位置”+“自动泊车”，为什么要把这三项分开，而不是把“远程召唤”定义为一个服务？原因很明显“发动”和“自动泊车”是高频使用的功能，他们非常的独立，又有可以重复使用的部分。
那么如果我们增加了“循迹泊车”的功能，服务设定为“行驶到指定位置”+“自动泊车”，那么也许再结合“完成锁定通知”就可以重新我们就会把“跑步”独立成一个服务。最终“健身运动”=“跑步”+“机跑步”+“俯卧撑”+“洗澡”；“夜跑”=“操场”+“跑步”+“洗澡”。
用这个比喻就是想说明，所谓服务的定义，没有统一的原则方法，是一种逻辑推导，需要有很强的逻辑能力，需要对工程有深刻的理解，需要对整车功能的关联性有深刻的理解。所以经验对于SOA的设计是至关重要的。如果展开说去，服务的排列顺序，服务的选择组合都和对车的理解有关，尤其再加深一步到时序相关，牵涉到强实时性的信号流与服务流的结合，就需要对车的功能有更深一步的了解了。这可能也是很多纯粹的互联网企业，拥有强大的软件实力，确难以很好的完成整车软件平台的原因之一。
三，用一个具体的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.
再有逻辑性的功能描述之后，有必要的移步是手绘出完整的这个功能的逻辑走向，将之前细化分析出的影响功能的相关像都包含在内，并且显示出输入纯属出的逻辑关系。也有的开发者会运用熟悉的工具例如Freevision直接就做了。但我认为这一步还是非常有必要的，任何工具都没有办法完整的满足现在日益曾都哦对功能需求的需要，并且存在配置的不完备之处。在计划的初期就能对整套功能有完整的解构，并且存档，无论是对新来者的理解帮助，还是对主机厂自身知识体系的建设都有很大的帮助。如下图。
接着可以用熟悉的工具加速开发，在AOUTOSAR的架构下，对函数进行打包，形成完整的功能函数。那么也就完成了对一个Feature的开发，其实潜移默化中也完成了对这个Feature中Service的定义。
在逻辑结构的基础上，对一些复用价值低的，不能独立成型的函数进行打包整合，形成SOA的架构设计如下图，并对接口做好定义就完成。
例如我们要做环境感知下雨关窗户这个操作，那么如下图调用感知环境和关窗户两个服务，整个调用服务的流程解构如下图
以上就是一个简单功能的正向SOA开发流程，是对功能的理解，也是对逻辑的推导。里面还有很多细节值得深挖，在做几张图的时候其中的根本逻辑和几大项目都是一致的有连贯性的。甚至如果是在没有前面的思想逐步推导，直接拿到任何一张SOA架构图，都会觉得晦涩难懂。更别说如果直接拿到的是代码了。
对于主机厂来说曾经的FDD,FDS是整车需求的发起点，那么在软件定义汽车的新时代里，尽快的做出属于自己的有自主产权的从描述到架构到代码的推导过程，并在此之上进行软件迭代和硬件增加，功能增加等等，才能够有条不紊，底气十足的砥砺前行。