整个议题有四块：1、关于SOA。2、基于AP的SOA软件开发方法。3、基于AP的SOA软件开发工具。4、基于AP搭建开发式软件平台。

第一点是SOA，我们都知道SOA现在大家有各种各样的文章去讨论，SOA是一种设计模式和思想，其产物就是面向服务的架构，在这个架构之中服务会具备如下特点。它是典型的结果导向的东西，符合如下主要特点就认为这个软件架构就是面向服务的软件架构，特点包含了这么几个：可重用，松耦合，隐藏逻辑，可组合，自主（独立运行），可被发现。

HowSOA，怎么样做SOA这个事情？下面已经给了一个标准型的答案，这也不是完整的答案，但是这是一个基础，也就是说我们引入了AP中间件，面向服务的组件之后，整个软件架构会符合面向服务的架构的情况。我们做一个对比，传统嵌入式软件，如果我们狭义定义的话，是基于CP的软件架构，右侧是AP软件架构。在CP软件架构上面是一个整体软件，在整体软件下面是否符合SOA刚才提到的那些特性呢？基本符合，但是有些没有办法做到，比如说自主（可独立运行），依托于不同的平台完成自身的逻辑。还有可被发现，我们认为它是静态可被发现的组件单元。右手边当引入AP之后，我们发现SOA特性能够完全被满足和覆盖。

为了便于理解，我们看一个场景，也就是说在这个场景之下，在整车EE架构上面现在有三个ECU。第一个是开发了ECU1（A和B），ECU2和3开发了C和E两个模块，我们先看一下它的开发过程，如图所示。在开发上面都是以单独的SW-C进行设计，在编译和集成环境下面会为整个ECU进行编译，我们称之为Monolithic，在部署层面我们会把SW-C融入到底层应用，是固定在某一个特定的ECU环境下面，也要做一些相应的配置。

在这种场景下面，当我们走到SOP之后，当我们需要新增一个软件的时候，我们把它叫做WSW-C D，当然我们要去开发这个软件，接下来要重新编辑整车CAN拓扑，为D提供相应的输入，之后在开发阶段重新配置ECU的RTE层。在集成编译阶段以整体ECU控制器软件为单元再整体编译1和2上面整体软件，在部署上面也需要部署整体ECU软件。

第二个场景是我们想SW-C D这个软件移植到ECU3控制器平台上面，我们要做的事情就是重新编辑整车CAN矩阵，重新进行OTA相关的软件到2和3控制器上面。

对比看一下，在引入了AP之后，在SOA话题上面怎么去做这样一个事情，面对同样的场景。首先在ECU上面叫做服务组件，在AA上面会向中间件发布已有的服务组建，在设计阶段，包括设计和编译，集成部署，整体过程中都是独立的软件，自主的，它可以独立的进行编译以及独立的动态的进行部署，当我们新增一个消费端的时候，我们会在ECU2上面快速OTA这个键单独可编译这个键并且完成可开发，整体是即插即用的。同样在第二个场景下面，当想把AA功能新的功能移植到ECU3的时候，实际上可以看到在开发和编译阶段没有work，在部署阶段可以通过动态配置文件做到软件模块的移植，体现了热插拔的状态，也就是插上即可以用。

总结一下整体的好处或者应用在汽车里面SOA会发生什么。左手是我们认为正在进行的，也是联合电子正在尝试的，无论是开发阶段，开发过程，开发流程，还是软件的更新迭代周期。在开发流程上面，我们发现未来的工具令会趋于同质，厂商定制化程度会更加低，这是比较明确的感受。开发环境会更加开放，趋于IT企业的开发模式。在软件迭代和更新周期方面，刚才大家也看到了更新软件成本会降低，无论是开发阶段，还是批产之后，具体体现在不需要改动信号矩阵和相关软件，在批产后支持软件快速独立更新，新功能是即插即用，就像我们手机下载一个APP直接是可以运行的。

右手边我们叫赋能软件定义汽车，SOA分层架构赋能以场景为导向的模块化进行开发，在整车级实现软件复用。原子服务可以开放汽车各领域的系统能力，我们认为SOA这件事情在Potential这里是有真正价值和意义的。

刚才我们说到了SOA好处，接下来看一下流程方法和工具。SOA是面向用户驱动型的场景，怎么样经过服务架构的设计，软件架构的设计，最后部署于各个预控制器甚至传感执行层的控制器，再进入到传统软件开发的过程。整体介绍还是会从场景开始到最后软件部署的阶段。

每一个小箭头代表着中间的过程，中间的过程分了三步（工作流程，过程中使用的工具，产出）。首先第一步是从场景到业务过程的状态，其实我们要将一件事情讲清楚，其实最重要的点是对汽车系统能力的认识。我举一个语音雨刮的例子，我们要知道这个雨刮是怎么运动的，语音输入在哪里，这个系统能力是非常重要的。联合电子在这块非常有经验，尤其在动力和车身领域有丰富的业务场景的知识和经验，做过非常多的批产项目。

第二块是从业务过程到服务架构的设计，这也是现在各个OEM的焦点，服务究竟是怎么划分的？服务划分的结果如何评价它的好坏？它的价值是如何体现的？这个后面会有一个展开的介绍。我们认为在能力点这个角度来讲，它同样需要一个系统能力，也就是对这个业务背景的认知，以及对SOA这件事情的了解程度。

再往下从服务到服务组件，我们都知道面向服务是一种开发概念，它开发出来的这些接口和服务都是我们自己面向业务过程的想法，这些想法怎么落地呢？怎么变成真正可以在控制器里面运行的软件单元，我们认为是在这一步去做执行，从Service到Service Component。我们要去定义SWC的范围, SWC与服务接口的绑定关系，以及SWC和可执行单元的绑定关系等。

最后一步没有展开讲，因为我们都知道它的划分过程是从整车开始的，从整车业务场景开始的，最后一步讲的是服务的部署。在整车级服务的复用架构和软件架构完成设计之后，我们会将服务放在域控制器里面。这个步骤, OEM是具有主导权的. 在最后服务部署方面的内容，我们认为EEA的成分非常高，所以就不在这里做具体的展开了。

第三点是稍微分享一下面向服务的软件开发环境。在刚才开发方法结束之后，其实我们已经得到了各个预控制器或者子系统上面服务开发的内容，这些内容需要在真实的各个子系统上面去做相应落地的过程。它和传统的软件开发过程，我们说的CP上面SW-C开发上面没有本质的区别，但是会有一些小点上面的不同，比如说怎么样用大家熟知的MATLAB算法开发单元，甚至于手写，这些功能组件如何具体的落地到，做成类似于手机上面可以运行的APP，这块内容可能是传统软件目前还没有面对到的问题。在这块联合电子还是提供了一整套的软件实现的工具，帮助从架构阶段，产生文件之后的内容到最后软件实现测试并且部署在域控制上面，稍微值得一提的是中间这个部分，联合电子面对服务化的软件还是没有用传统的项目管理方式去做管理，是搬了安卓的思想和概念，在这样一个思考下面，我们将每个服务单元都做成了一个仓库，每个服务单元都是自身的一个仓库，这也是和传统软件比较大的不同点。

最后介绍一下目前正在搭建的软件开放平台，这个搭建过程。

我们内部将这个软件平台叫做联合电子软件平台，专注于为汽车合作伙伴提供互联软件创新的开发以及相关的软件产品。它大概分成三段内容：车端优质应用，车辆功能中间件，面向服务开发方法（环境）便于大家快速应用落地的工具。

看一下软件平台从下至上的层级，首先我们是应用了AUTOSAR软件，在这上面会提供AUTOSAR服务，这里介绍了通信中间件.它相当于是完成了CP到AP的协同，在未来预控制器架构下面，这里举了区域性控制器架构，在这上面部署CP操作系统在计算单元上面部署CP和AP系统，总体来讲将AP中间件组件布置在MPU上面，这样区域性环境上面都可以有相应的简单的静态式的服务和我们的AP进行相应的打通，和我们的AP进行相应的服务呼应和打通，方便基于不同的电子电气架构去做不同的部署。

在这个基础件之上，我们可以提供原子服务。传统我们提供ECU，TCU和BMS等部件，未来我们不光提供控制器，还提供核心技术，举个例子比如说电池变速箱控制，雨刮的控制逻辑，包括车辆动力系统纵向横向模型等等，这些传统的功能都会通过使用AUTOSAR中间件向外开放相应的系统能力，将它做成标准的服务接口，向不同的合作伙伴甚至于第三方合作伙伴开放。

第二块我们同样会提供优质的应用，像开发方法论上面看到的，我们在车控，也就是在车辆动力和车身领域两块优质的应用场景和优质的面向服务，提升用户体验的场景，我们会有相应的考量，并且以SOA服务的方式展现。这里有一个语音雨刮的功能，我们通过语音雨刮场景的分解得到雨刮模式仲裁和决策，由此基于面向服务调用下方的原子服务的接口。

右手边也是联合电子正在和各个OEM合作的功能模块，像预测性的动力域的行驶里程解决驾驶员里程焦虑的问题，还有整车能量分配（能量管理），这些都涉及到方方面面的元素，包括地图，预测的信息，车辆动力系统执行单元，算法策略等等，我们也会通过预控制器软件平台架构以服务形式展开，并且与OEM一起部署在相应的服务提供方，也就是域控制器上面。

最后我们想说整个应用场景，从上至下随着软件定义汽车序幕拉开，随着我们不断迭代场景的延伸以及扩展，我们希望建立在车控领域的小生态，这个小生态可以帮助第三方伙伴以及OEM等合作伙伴, 通过提供厚厚的车辆功能的中间件。这个中间件可以以快速灵活敏捷的架构和方式去满足企业对不同场景迭代的需求，快速的去响应这样的需求。