智能驾驶汽车软件研发过程中，SOA流程开发在自动驾驶车企中

作者|Jessie

出品|焉知

当前，智能驾驶车辆软件研制过程中，孤岛中的应用程序诸多，因为技术平台和数据模型的差别，这种应用程序之间很难共享信息。在基于企业流程管理BPM(BusinessProcessManagement)的应用程序的情况下，集成技术和单个业务应用程序之间存在紧密耦合。每每业务流程发生变化时，集成技术都会发生变化，进而降低营运成本。这些紧密耦合也使这些技巧更难改变。当某个流程在影响所有应用程序的多个应用程序中受到破坏时，必须更改那些受影响的应用程序和接口才能适应修改的业务流程。这涉及庞大的工作量，并不是我们所期望听到的。

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

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

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

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

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

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

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

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

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

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

–增加内在互操作性

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

–增加业务和技术一致性

–增加供应商多元化选择

–提高投资回报率

–提高组织敏捷性

–减少IT系统管理负担

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

GuardKnox、NXP和GreenHillsSoftware合作开发先进、安全的车辆平台……实现软件定义和面向服务的汽车的商业布署。台湾集团的新服务器概念是在高度联接的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可用于建立应用程序系统oem信息修改工具，但无法扩充到企业。没有BPM的SOA可用于创建可重用且一致的服务，但缺少将这种服务转变为敏捷、有竞争力的企业的能力。

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

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

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

1、业务驱动型开发

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

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

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

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

业务流程不负责了解底层应用程序和技术平台的任何细节，由于业务服务线的服务合同为访问服务提供了定义明晰的插口信息；

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

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

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

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

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

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

这么我们将怎样借助SOA的思想提高业务流程设计呢？

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

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

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

2、平台驱动型开发

针对早已完成平台化开发的量产项目，其数学逻辑早已完成建立，我们只须要将数学逻辑封装为SOA中的底层元服务，这种数学逻辑必须是已然成形，但是相对较为成熟的，如刹车系统中一些关于基础刹车控制相关的功能控制（ABS、HBA、HDC等），也可以将部份元服务进一步组合为基础服务。

下边说明下平台驱动开发的用处。

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

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

服务由应用程序组件通过网路上的通讯合同提供。车辆以太网通过开放的标准化汽车插口（比如，GENIVICVII）实现硬件软件具象。对于SOA开发来说，应当是逐步插入的，即在处理SOA实现的遗留组件过程中，具有较高的复杂性。目前为止，一直没有关于服务名称和属性的标准通用定义。对于讨论的插口定义可参考开放标准（比如AUTOSAR、GENIVIVSSVSC、ENSORIS、SOME/IP）的组合，其在多个方面具有制订统一服务标准的可能性。

运行时环境的时序会影响基于讯号的疗效链的性能。对于SOA的堆栈过程，将讯号迁移到服务会降低延后/晃动。并且，没有必要迁移整个讯号疗效链。可以在服务级别尽最大努力分离功能，而在讯号级别进行硬控制循环。

总结

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

SOA可以没有BPM而存在，BPM在没有对SOA的深刻理解的情况下蓬勃发展。SOA和BPM的组合比二者本身都更强悍。服务联接在一起以产生复合业务流程，SOA最大限度地降低了业务剖析和IT开发工作之间的差别。因为对应用程序和数据库的访问，可以同时考虑和设计业务流程和数据。