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

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

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

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

2.1 功能的划分

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

2.2 通用的ECU需求

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

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

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

2.4 ECU特定的优化

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

2.5 高性能处理器的引入

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

2.6 缺少可计算的架构模型

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

03实施SOA的挑战

实施SOA的挑战可以归结为以下几个方面：

SoA的挑战可以以下面这张图来概括：

首先的重用，重用真的发生过么？从我个人的经验上来说，嵌入式系统架构上的重用，或者多媒体中间件的重用是真实存在并且发生过的。但这些更多的是基于经验和技术的一些总结和抽象，应用在一些小型的系统或者某个子系统中，的确能起到比较好的效果。对于服务可否采用同样的思路呢？毕竟，我是把系统中容易发生变化的部分剥离到外部去了。服务的重用，不取决于采用了什么样的技术，主要的障碍在于组织上的、方法论上的和政策上的问题。因此对于重用，在技术平台的架构上，有如下的需求：

高效的开发意味着在尽可能短的时间内，以尽可能少的成本，完成尽可能多的功能。达成这个目标依赖多种因素，包括重用已有的服务以及基于这些服务，快速的构建应用程序。对于一些团队或组织来说，引入不同的开发方法可能更方便达成这个目标。比如通过引入明确定义的过程模型（如，参考ASPICE），方便相关人员查找必要的服务相关的基本信息；或者，使用新的系统设计方法论（如，MBSE），关注构建业务模型，而不是过多的把注意力放到服务本身上。然后，通过层次化分解，在不同的级别和范围，关注如何实现业务模型。MBSE中，还可以提供分析方法，用于明确服务之间的交互、 接口及涉及到实现上的一些决策手段。另外，有必要的话，还需要对组织架构进行必要的优化，如前面银行的例子，分为服务的使用者与服务的提供者。对于高效的开发这个挑战，技术架构上至少要满足下面这些需求：

应用和数据的集成是一件特别容易让人迷糊的事儿。老的系统应用和数据之间有可能采用了一些点对点协议，比如DBus，ProtoBuf之类，或者是一些自定义的RPC/IPC协议（通常可维护性、可扩展性渣得一坨）。基于Web Service的SoA给出了数据通信实现的一些参考，但技术只占SoA的一小部分，关键还在于对于业务模型的思考。比如，不能再使用点对点的通信，而是考虑采用将所有独立的应用/服务，连接到整体的业务模型上。另外，对于暴露接口的过程，也得考虑，是否还要基于原先老接口来实现，是不是应该采用最新的技术手段更新接口实现。对于数据的集成来说，需要关注的点也不是数据列表中的数据结构该如何定义，而是哪些数据要通过接口共享出去，内部数据的定义和维护，由应用自己来管理就行了。对于集成来说，如下的架构需求需要考虑在内：

敏捷性和灵活性可以通过快速高效的使用已有服务创建新的业务模型来表现，这要求我们能方便的查找已有的功能和数据，并且能够高效的利用这些功能和数据。一致性要求开发过程中，业务架构相关的信息、应用及技术能够体现出来。这就要求：

创建和维护参考架构是SoA应用中的重点，通常的非形式化的一些过程很难保障SoA的成功应用。SoA参考模型中，比较重要的几个活动及其关系整理如下图：

其中：

设计过程要采用通用的设计语义，比如SysML和SoaML，结合MBSE及MBD方法。过程模型也必不可少，定义人员角色，指南，模板，检查项，管理开发过程中的成果物并分发给相关的人员。

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

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来进行部署及执行。

文章来源 公众号 汽车电子与软件