为啥是SoA?（一）

1. 前言

最近领导让看SoA。
话说这东西出现了应该也有20来年了，记得早先有Web Service，可以基于WebSphere部署（不知道现在怎么样了，好像是在IBM手里？）。还有J2EE，基于EJB设计服务。自从改行做嵌入式之后，就不太关注这些东西了。不过由于车载领域是最大的嵌入式系统，这些年的发展，不可避免的会引入（受影响？）一些成熟的商务模式。目前看，车载应用的服务化不可避免的会成为未来几年的趋势。所以本文整理一些SoA的基本概念，讨论下车载领域该如何引入SoA。

2. 当前车载领域的现状

先看一下宝马的一张流程图：

传统的开发流程从客户的需求开始。选定了供应商之后，客户的需求需要进行规范化（Specify），因为大部分的原始需求可能是不清晰，不明确的。尤其是这些大厂，它们集成的ECU众多，所以一开始几乎没有针对特定ECU的需求规范，我接触过了俩家欧洲的、一家日本的车厂的原始需求都是这样的输入。接下来系统架构师对需求进行分析，同客户就需求理解达成一致（包括功能安全需求和信息安全需求），就进入到系统架构设计过程，也就是V模型的下降部分。这个过程中，各家的打法可能就不一样了，包括同一家不同的时间点，不同的项目可能都不一样，比如考虑到系统架构的静态及动态部分，有用SysML的，有用Visio的，有用Word的，日本人还喜欢用Excel。系统架构设计输出系统的主要逻辑组件，分析各种需求到组件上，包括功能的和非功能的需求，之后就进入到软硬件架构设计阶段。软件架构设计可能会用到UML，基于AUTOSAR的系统静态架构的设计还会用到相关的AUTOSAR工具。如果是设计的SWC是用于信号处理或算法的，可以直接使用Simulink来进行建模开发，这就是单元设计阶段了，当然也可以手工编写SWC中的Runnable。接下来就是V模型的上升阶段，单元测试（MIL，SIL，HIL），集成测试及系统测试。详细的过程模型我们可以参考ASPICE及ISO 26262，需要考虑贯穿整个开发过程的追溯性及一致性问题。

至少目前这个过程很好，大家都比较熟悉具体的流程和实施细节，各个大厂也愿意付出相应的过程成本（大量的文档），用于保障产品质量。但事情总是在发展，至少目前，针对这些已经比较成熟的模型出现了几朵乌云。

3. 当前车载流程中所遇到的几个问题

整理了下目前车载电子领域中遇到的几个问题：

3.1 功能的划分

传统的车载电子功能的划分多基于ECU的计算能力进行。如做仪表的ECU就干不了IVI的活；而上了全液晶仪表后，IVI的GPU能力可能还不如仪表。座舱系统虽然在硬件上省了一部分资源，但省下来看成本基本上被软件增加的成本抵消掉了。而车上还有一众其它的ECU，这些独立的ECU由于涉及到单独的布线（电源、通信、传感器及驱动器等），极大的增加了整车的开发成本。目前，ECU有着高度集成化的趋势，因此，未来车身各功能的重新划分及其灵活性和可替换性，是需要认真考虑的。

3.2 通用的ECU需求

像前面提到的，各个OEM通常提供的是通用ECU需求。通用ECU需求节省了编写需求的时间，但引入的问题是供应商们有时根本搞不清哪些需求要做，哪些不要做，导致最后的ECU出来过度设计的情况。

3.3 项目特定或者供应商特定开发方法

特定的项目及供应商，可能会采用不同的过程模型与开发方法，这增加了成果物管理的难度。

3.4 ECU特定的优化

供应商在进行ECU设计时，往往只能看到自己分担的部分，这导致特定的优化不足以满足整车的非功能性指标，需要一个全局的协调。

3.5 高性能处理器的引入

目前高主频，多核心及异构的处理器逐渐增加。除了内置的高性能GPU、视觉处理器外，高性能的实时核心也加入到了SoC内部，这使得SoC的集成度进一步增加。原有的如IVI或仪表的双芯片架构逐渐被单芯片取代，成本也随之下降。如何对高性能处理器的利用，则是一个新的课题。

3.6 缺少可计算的架构模型

这个问题体现在整个系统或整车的集成测试阶段。正常来说，在这个阶段架构设计早已完成，产品已经进入到了测试阶段，但架构设计的一些潜在问题只有在这个阶段才能体现出来。如，整车的网络的延时，带宽的使用，ECU内部消息、随机事件的延时，CPU的使用等等。架构设计过程中使用的语言，如SysML，UML等，缺少仿真的能力，就会导致这些问题不能在架构设计过程中发现。

4. 问题的解决思路

针对上面出现的这些问题，可能需要从以下几个方面来考虑：

4.1 无缝的需求管理过程

为了保障客户需求能够正确的实施，从需求分析，到架构设计阶段，要严格贯彻一致性与追溯性原则。这在基于功能安全设计与信息安全设计的产品尤其重要。部分项目采用文档（Word、Excel等）追加ID，并采用第三方工具进行追溯性管理，目前这种方式比较原始。基于MBSE方法论的项目，可以使用SysML/UML进行需求规范化和架构设计，并使用设计工具自动生成追溯性矩阵及覆盖度的检证，比较适合进行无缝的需求管理。

4.2 整体的基于SoA的架构设计

考虑到ECU的整合，未来汽车电子各功能的定义不再以ECU划分，那么各功能部署的灵活性就需要考虑。由于高带宽的网络，高性能的处理器的引入，使得基于服务发现及远程访问的SoA架构在嵌入式领域得到实施成为可能。基于SoA架构的应用可以很容易的集成到系统的生态中，服务的迁移及撤消对于服务的使用者来说，也是透明的。同时，对于一些传统网络总线的支持，如CAN、Flexray、Lin等，可以实现平滑的兼容，使用网络拓扑的扩展也很容易。
汽车系统是一个整体，一些非功能性需求，如性能指标、安全目标等等，需要参与到整个链条的ECU、传感器及驱动器共同来达成。那么，从整车架构层来考虑整体的性能指标及优化策略，则是一种行之有效的方法。SoA部署的灵活性可以有效支持这种架构级的调整。
系统架构阶段，如果缺少可计算的模型，一些性能指标、资源使用指标等，无法在架构设计阶段可视化的表达出来，这就要求我们考虑一种可行的架构仿真手段。基于DES的仿真模型，可以提供架构仿真的一种实现，在这里，可以把服务具体化成一个个的消息处理节点。前提条件是，我们需要通过历史数据获得尽可能真实的输入。

4.3 分布式的开发

服务化的一个好处是，分配给各个服务的需求是明确的，这就使得供应商们更清楚自己要做的事情。为了应对各供应商不同的开发过程，可以考虑使用SAFe模型，即一种大规模敏捷的实现方法。SAFe在Team敏捷的基础上，增加了Program、Large Solution、Portfolio等级别的敏捷及实践，可以满足OEM统一过程，快速精确实现产品的需求。

4.4 敏捷的开发过程

在Team级，可以考虑采用常用的敏捷方法，如Scrum, TDD, Kanban等等。但无论哪种方法，都需要客户的参与，如Product Owner或者Function Owner的角色。在涉及到功能安全及信息安全的项目，在项目开发过程中的每个迭代，相关审计人员的也需要执行必要的审计流程，确保成果物的质量。

4.5 持续集成及测试

作为敏捷的一个手段，持续集成（CI）是保障项目质量很重要的技术。持续集成包括自动化的静态代码检查、自动化的单元测试、覆盖率测试，自动化的集成测试、接口、控制/数据流的覆盖率测试等等。针对功能安全产品，还需要进行故障注入测试；如果是信息安全产品，需要进行自动化的模糊测试等等。对于基于模型开发的产品，MIL/SIL/HIL需要加入到单元测试的过程中。这些可以考虑使用Jenkins来进行部署及执行。

这个部分暂时写到这里，下篇文章讨论下SoA的基本概念。