“联合汽车电子施思明:基于域控制器,采用AUTOSAR Adaptive构建SOA软件平台”

由格斯坦汽车、汽车公司、上海车展三方共同主办的sdvf2021第二届软件定义汽车峰会论坛暨autosar2021中国将于4月19-21日在上海举行，此次活动也将是2021上海车展的同步活动 这次会议邀请了联合汽车电子域控制器系统开发经理施思明先生，在本次论坛上，他以《域控制器为基础

整个议题有四个。 1、关于soa的事情。 2、基于ap的soa软件开发做法。 3、基于ap的soa软件开发工具。 4、基于ap构建开发型软件平台。

有几个是soa。 我知道soa现在有各种各样的文案在讨论。 soa是一种设计模式和思想，其产物是面向服务的体系结构，在这种体系结构中，服务具有以下优势: 是典型的面向结果的东西。 认为该软件架构是面向服务的软件架构。 优点包括可重用、松散耦合、隐藏逻辑、可组合、自主(独立运行)、可发现等。

howsoa，你怎么做soa这个案子？ 给出了标准型的答案。 这也不是完美的答案，但这是基础。 这意味着，在部署ap中间件、面向服务的组件后，整个软件体系结构将与面向服务的体系结构的情况相匹配。 我们以以前流传下来的嵌入式软件为对象。 从狭义上讲，它是基于cp的软件体系结构，右侧是ap软件体系结构。 虽然在cp软件体系结构上是整体软件，但在整体软件下，soa是否符合刚才所述的特征？ 基本上是符合的，但是没有自主(可以独立执行)等几种方法。 依赖不同的平台完成自己的逻辑。 另外，可以认为是可以静态发现的组件单元。 右手导入ap后，发现完全满足soa的特征，可以覆盖。

为了便于理解，让我们来看一个场景。 也就是说，在这个场景下，整车的ee框架上现在有3个ecu。 第一个是开发了ECU1(a和b )，ecu2和3开发了c和e两个模块。 首先来看看其开发过程，如图所示。 在开发上全部用单独的sw-c进行设计，在编译和集成环境下为整个ecu进行编译。 将其称为monolithic。 在部署层面，将sw-c纳入基础APP应用。 固定在某个特定的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这个事件的理解度也是必要的。

从服务到服务组件都知道面向服务是一个开发概念。 开发的这些接口和服务都是我们自己面向业务流程的想法。 这些想法怎么落地呢？ 我们认为，如何真正成为在控制器中工作的软件单元，将在这一步中执行。 从服务到服务组件。 定义swc的范围、swc和服务接口的绑定关系、swc和可执行单元的绑定关系等。

最后一步还没有展开。 因为，我们知道它的划分过程从整车开始，从整车的业务场景开始，最后一步是服务的引入。 整车级服务的复用架构和软件架构设计完毕后，我们将服务纳入域控制器。 这一步由oem掌握主动权。 最后一个服务部署的副本被认为是eea的成分非常高，所以在此省略具体的部署。

第三个要点是共享一点面向服务的软件开发环境。 在刚才的开发方法结束后，实际上是在各个预控制器或子系统上拿到了服务开发的副本。 这些副本必须在实际的各个子系统上进行适当的落地过程。 以前流传下来的软件开发流程和在cp上开发sw-c没有本质的区别，但有一点点上面的区别。 例如，如何使用大家都知道的matlab算法开发单元，用手写。 这些功能组件如何具体落地，制造出在手机上工作的APP呢？ 这个复制品可能是以前流传下来的软件现在没有遇到的问题。 这个联合电子还是提供了一系列软件实现的工具，帮助从结构阶段，从文件制作后的拷贝到最后的软件实现测试同时配置在域控制上。 值得一提的是中间的部分，联合电子面对的是服务化的软件，还是没有用之前流传下来的项目管理方法进行管理，还是搬家了安卓的思想和概念，在这样的想法下，将各个服务单元组成了一个仓库，

最后，介绍当前正在构建的软件开放平台，该构建过程。 [/s2/]

我们把这个软件平台称为联合电子软件平台，重点是为汽车合作伙伴提供互联软件创新的开发和相关软件产品。 大致分为三类，有三个副本。 面向车端高质量APP、车辆功能中间件、服务研发做法(环境)，是大家快速应用、方便落地的工具。

从软件平台的下往上看，我们首先应用autosar软件，在此基础上提供autosar服务，在此介绍通信中间件。 这完成了从cp到ap的合作，在未来的预控制器架构下，这里列举了区域控制器架构，在此基础上引入了cp操作系统在计算单元上部署了cp和ap系统，整体来说，是ap中间件 在地域环境上相应的简单静态服务和我们的ap进行相应的开通，我们的ap和相应的服务进行呼叫和开通，以便于基于不同的电子电气结构进行不同的部署。

在这个基础上，我们可以提供原子服务。 以前提供ecu、tcu、bms等部件，将来不仅提供控制器，也将提供核心技术。 例如电池、变速器控制、刮水器的控制逻辑、车辆动力系统的纵向、横向模型等。 这些从以前流传下来的功能，通过采用autosar中间件，将适当的系统能力向外部开放，使之成为标准的服务接口，向不同的合作伙伴和第三方开放。

二是同样提供高质量的APP应用。 正如我们在发展方法论上看到的那样，我们在车控，也就是车辆动力和车身行业提高高质量APP场景和高质量面向服务、顾客体验的场景，将在给予相应照顾的同时，通过soa服务的方法进行展示。 这里有语音雨刮的功能，我们通过语音雨刮场景的分解得到雨刮模式的调停和决定，由此基于服务调用下的原子面向服务的接口。

右手也是与各oem合作的联合电子的功能模块，包括预测的动力域行驶距离处理驾驶员行驶距离不安的问题、车辆整体的能量分配(能源管理)等、地图、预测的新闻、车辆动力系统执行单元、车辆动力系统执行单元 我们也通过预控制器软件平台架构作为服务展开，与oem一起配置在对应的服务提供方，即域控制器上。

最后，我想谈谈整个APP场景。 随着自上而下软件定义的汽车拉开帷幕，我们不断重复场景的扩展和扩展，希望第三方和oem等合作伙伴通过提供厚重的车辆功能中间件，在车辆控制行业建立小生态。 该中间件能够以快速、灵活、敏捷的体系结构和方法满足公司对各种场景重复的主张，并能对这样的主张迅速做出响应。