下一代自动驾驶开发平台理论原理与实践（一）

当前，智能驾驶汽车软件研发过程中，孤岛中的应用程序众多，由于技术平台和数据模型的差异，这些应用程序之间很难共享信息。在基于企业流程管理BPM(Business Process Management)的应用程序的情况下，集成技术和单个业务应用程序之间存在紧密耦合。每当业务流程发生变化时，集成技术就会发生变化，从而增加运营成本。这种紧密耦合也使这种方法更难改变。当某个流程在影响所有应用程序的多个应用程序中遭到破坏时，必须修改这些受影响的应用程序和接口才能适应更改的业务流程。这涉及庞大的工作量，并不是我们所期望看到的。

SOA (服务导向架构，Service Oriented Architecture)  作为一种架构范式，展示了技术中立的最佳实践。其建立在标准之上，可在供应商的广泛支持下在全球范围内实现经济高效的实施。以在企业内部和跨企业创建新业务功能方面重用和重新组合服务，SOA很好的做到了“粗粒度”和“松散耦合”的特点，相较于当前分布式物理架构具有更大的灵活性。SOA 最佳实践创建包含业务流程的设计 —— 并增强将流程外包和扩展给业务合作伙伴的能力。此外，SOA也可以复用已有的系统和流程，与传统的基于孤岛的应用程序开发更具战术性的本质形成对比，可以保留和增强现有投资承建的架构、软件等实现的部分有用性。

SOA流程开发在自动驾驶车企中布局

在 SOA 中，由一组与业务相关的 IT 服务组成，其中的资源（即跨越企业内或跨多个企业的多个应用程序）可供价值网络、企业或业务线的参与者使用，这些服务共同实现了组织的业务流程和目标。

当然，企业在应用 SOA 的解决方案时也会面临一些比较大的业务挑战，主要包含如下：

a) 定义和验证服务、管理重用和分配成本 ；

b) 在企业的软件开发方法中适应 SOA 方法 ；

c) 设计支持 SOA 的底层基础设施并选择支持 SOA 的技术 ；

d) 管理服务集合并将服务编排到业务流程中；

e) 处理任何缺乏 SOA 专业知识和经验的问题。

对于主机厂未来的研发布局来说，其开发SOA的战略目标可概括如下：

– 增加内在互操作性

– 增加各子单元之间的关联性，SOA 支持设计可互操作的服务来交换数据

– 增加业务和技术一致性

– 增加供应商多样化选择

– 提高投资回报率

– 提高组织敏捷性

– 减少 IT 系统管理负担

如下图所示，表示了四家主流车企的SOA架构开发布局。其中，宝马和奥迪希望将汽车硬件与软件分开，两家领先的汽车制造商正在带头开发新的电子架构。

GuardKnox、NXP 和 Green Hills Software 合作开发先进、安全的汽车平台……实现软件定义和面向服务的车辆的商业部署。大陆集团的新服务器概念是在高度连接的 ID 电动汽车中转换为面向服务的电子架构的核心要素。华为认为SDV（软件定义汽车）的成果对汽车产业的革命起到关键作用。

如上也是整个SOA开发的基本重点，这将在我们后续序列文章中进行一一阐述。

企业管理开发流程BPM

与SOA软件架构开发之间的关系

目前在多数主机厂汽车软件过程开发中，采用开发方法论/工具基本适配于BPM技术，BPM解决了组织如何识别、建模、开发、部署和管理其业务流程，包括涉及 IT 系统和人机交互的流程。这使企业能够指定渐进性业务流程。当然需要说明的是，没有服务的 BPM 需要流程层直接访问底层业务应用程序。这个过程会使用有关当前应用程序、它们提供的 API、它们的内部数据模型以及实现它们的技术中不必要的详细信息。

SOA可以在没有 BPM 的情况下存在，而 BPM 在没有对 SOA 的深刻理解的情况下是无法蓬勃发展的，SOA 和 BPM 的组合比单独使用更强大。实现 SOA 的主要目的是提供一个松散耦合的集成平台，允许应用程序实例在不影响核心集成技术的情况下改变和发展。SOA 提供了创建流，确保SOA 与 BPM 松散耦合，自动创建可以跨企业以多种方式重用的服务，以及可以持续改进的多个流程。通过整合可以将 BPM 和 SOA 相关联，以创造更大的业务敏捷性。因此，SOA 公开了服务，BPM 需要建立相应的流程完成使用服务。SOA 为 BPM 打开了大量服务清单，以便“结合”成一个综合流。不管这是否是复合的，都可以处理关键业务流程。

下图描绘了 BPM和SOA之间的关系。其中BPM 负责对流程进行建模、模拟和重新设计，SOA基础架构则协调业务流程并协调服务提供商。

同样，需要不同应用程序相互通信的流程修改，则不应改变核心集成技术以及应用程序实例。这种流程和服务的独立性有助于建立业务流程建模和应用程序实现之间的关系。当服务被公开时，用于各种进程，此时服务的更改将不应影响流程。流程更改将根据需要重用各种服务。流程变更将在企业升级中更快地实现，因为 SOA 同时也将流程与应用程序实现解耦，流程和应用程序之间的通信仅通过SOA集成发生。这种 SOA 集成将最大限度地减少了流程建模和应用程序实现之间的差距。

BPM 有助于融合流程服务以构建复合业务流。BPM 功能是使用状态机构建的，状态机有助于保持业务流程的完整性并跟踪调用许多服务的流程。

通过使用 BPM，SOA 被绑定到流程服务以开发复合业务流。BPM 为服务组合增加了额外的运行时能力和修改流以换取更多运行时复杂性的能力。BPM 还可以确保执行长时间运行的流程稳定性，并在出现故障时运行任何必要的补偿事务。BPM 通过向 SOA 公开的服务添加灵活、敏捷的运行时层来利用和扩展 SOA 的功能。

BPM 和 SOA 为企业的车端软件开发提供了完美的组合。BPM 为定义业务流程以及监控和管理这些流程的其他重要功能提供了更高级别的抽象，而SOA服务则为这些过程的能力提供支持。SOA 可以提供用于组合服务以及支持和创建敏捷、灵活的流程开发模式提供帮助。没有 SOA 的 BPM 可用于构建应用程序，但难以扩展到企业。没有 BPM 的 SOA 可用于创建可重用且一致的服务，但缺乏将这些服务转变为敏捷、有竞争力的企业的能力。

SOA 为定义可重用业务功能提供了理想的抽象级别，完全封装了 BPM 系统中的底层应用程序和技术平台。SOA 生成封装业务逻辑和普遍接受的接口的模块化业务组件。这些模块可以轻松地执行流程中的步骤。SOA 是 BPM 的重要基础，支持将流程服务快速组装和编排成更大的端到端流程。

SOA的两种不同开发模式原理

在汽车领域软件开发工程实践中，结合 SOA 汽车软件分层模型，定义了基于SOA的汽车软件两种典型的开发方法，其一是基于“业务驱动型”的开发方法，其二是基于“平台驱动型”的开发方法，两种方法适用于不同的应用场景。

1、业务驱动型开发

即整个服务的开发的前提是项目通过各种手段获取业务用例，从用户使用案例出发，以服务用户为设计导向，基于SOA采用正向流程对汽车软件进行设计。由用例驱动的开发活动，可以建立需求和服务操作之间清晰的追溯关系，为抽象和封装服务提供充足的语境信息。 整个设计过程主要解决两个问题：即需要构建服务内容有哪些，每个服务应该实现封装的逻辑有哪些。

如前所述的企业流程管理BMP中，通常与业务驱动型流程方法论相结合。通过将这些服务编排成复合应用程序并通过标准协议调用它们。业务流程管理和面向服务的架构的结合将使 IT 专业人员和业务用户受益。没有业务流程管理基础设施，面向服务的架构就无法发挥作用。BPM 是面向服务的应用程序开发 (SODA) 的核心元素。它通常用于组装新的应用程序，因为 SOA 和 BPM 在这种情况下作为天然的合作伙伴携手合作。每个业务流程都被建模为一组单独的处理任务，这些任务通常作为企业内的服务来实现。BPM 有助于创建流程模型，流程自动化，以调用服务的形式。

SOA的服务层为业务驱动的流程层提供了理想的平台，具有以下优化特征：

业务服务线提供映射到业务流程中不同粗粒度的任务；

业务流程不负责了解底层应用程序和技术平台的任何细节，因为业务服务线的服务协议为访问服务提供了定义明确的接口信息；

服务层提供的服务注册和服务设施确保业务流程层可以动态定位和访问服务；

服务级别数据模型是基于业务领域定义的，独立于任何特定应用程序使用的数据模型；

服务级安全模型提供单点登录和基于角色的访问控制，以确保流程任务被授权使用服务。

构建服务内容实际就是业务过程的分析过程，即由系统设计人员和测试评价人员从用户角度考虑功能需求和系统实现。实现服务封装的过程实际是通过服务操作operation实现，该操作在实现过程中相当于软件函数或方法。整个封装过程需要通过操作分析实现系统用例的分析细化，得到系统与参与者、系统与外部系统的界限及信息交互，提出对系统的功能需求，并由此作为各个构建服务的操作类型。随后，通过业务逻辑抽象和封装，从开发角度实现最优化服务部署，其中需要考虑重用性和自主性的面向服务设计原则。SOA需要设计良好的基础服务和元服务，当业务用例增加，原有业务用例发生变更时，可以很好的保证重用性，减少软件变更量，从而实现更快速高效的版本管理。

如下图所示，表示了一种服务层由与特定业务领域对齐的业务服务线，该服务线可以跨多个业务领域共享可重用的技术服务，同时允许定义和利用服务平台组成以一种独立于底层应用程序和技术平台的组织方式。

最近，越来越多的公司开始专注于使用更具战略性和实用性得实例化业务驱动型开发的流程工具链。例如，微软在新版本的 Visual Studio 中添加了一些进程管理功能。IBM 以其 WebSphere 品牌提供了一套业务流程工具。Oracle 通过其新的融合中间件平台专注于流程，SAP 通过与 IDS Sheer 的强大合作伙伴关系重新关注业务流程。

那么我们将如何利用SOA的思想增强业务流程设计呢？

SOA 创建模块化业务组件，这些组件使用了接口封装业务逻辑和数据，其创建的模块用于执行流程中的各个步骤。业务流程中的所有流程步骤可能与 SOA 服务相关，也可能不相关。BPM 可以将 SOA 派生服务、对集成的代理和其他非 SOA 服务的调用相结合。

SOA 是一种用于设计业务流程的工具。可以加入服务以提供复合业务功能或业务流程。可以在以下上下文中重用单个服务或多个业务流程。SOA 帮助业务所有者设计支持业务流程的 IT 系统。这提高了过程变更的适应性，增加了重用性，并提高了过程一致性。SOA 方法会影响 IT 运营的整体效率，特别是在多个流程中以重用公共、共享业务服务的形式对应用程序进行开发。由于大型组织，业务流程、业务规则和策略管理都是不一致的，并且为每个新应用程序和流程重新定义。SOA 就有助于减少创建定义明确和管理的业务服务形式的不一致性，确保这些业务服务在多个系统之间共享，而实现则与底层技术实现无关。

后面系列文章，我们将针对业务驱动型SOA的完整开发流程，以实例分章节进行详细描述和分析。

2、平台驱动型开发

针对已经完成平台化开发的量产项目，其物理逻辑已经完成构建，我们只需要将物理逻辑封装为SOA中的底层元服务，这些物理逻辑必须是已经成型，并且相对较为成熟的，如制动系统中一些关于基础制动控制相关的功能控制（ABS、HBA、HDC等），也可以将部分元服务进一步组合为基础服务。

下面说明下平台驱动开发的好处。

对于SOA的软件开发来说，其核心内容是如何将以前的信号级别通信更新为以服务为包的通信模式。其中服务与信号之间的转换点可以位于从云端到传感器/执行器级别的某个位置，需要在信号到服务转换级别之间的做出权衡。如下图表示了一种典型的平台驱动型SOA整车开发架构模式。

如上图所示，如果在当前架构上完全重新开发SOA架构，至底向上会有较多的信号向服务的转化过程，这可能不是最好的方法。在很多情况下，是不需要重新发明轮子的。因此，在我们实际开发过程根据实际用例逐步添加东西，这样可以逐渐满足当前的解决方案，可能是更好的方法。

服务由应用程序组件通过网络上的通信协议提供。汽车以太网通过开放的标准化车辆接口（例如，GENIVI CVII）实现硬件软件抽象。对于SOA开发来说，应该是逐渐插入的，即在处理 SOA 实现的遗留组件过程中，具有较高的复杂性。目前为止，仍然没有关于服务名称和属性的标准通用定义。对于讨论的接口定义可参考开放标准（例如 AUTOSAR、GENIVI VSS VSC、ENSORIS、SOME/IP）的组合，其在多个方面具有制定统一服务标准的可能性。

运行时环境的时序会影响基于信号的效果链的性能。对于SOA的堆栈过程，将信号迁移到服务会增加延迟/抖动。但是，没有必要迁移整个信号效果链。可以在服务级别尽最大努力分离功能，而在信号级别进行硬控制循环。

总结

面向服务的架构 (SOA) 概念基于开发可重用业务服务和构建应用程序的原则，而不是在孤岛中构建单体应用程序。SOA 不是产品，它是关于通过使用一组设计原则、模式和技术的一组与业务对齐的 IT 服务来弥合业务和 IT 之间的差距。