上汽软件中心孟超基于SOA服务架构的车辆数字化软件

大家都想了解一下关于上汽软件中心孟超基于SOA服务架构的车辆数字化软件和丰田suvsdv相关的话题，下面就让小编带各位了解上汽软件中心孟超基于SOA服务架构的车辆数字化软件的案。

7月22日至7月23日，由盖世汽车主办、上海汽车城特别支持的“2020首届软件定义汽车高峰论坛”正式举办。本次论坛主要旨在探讨软件定义汽车领域的最新创新理念、技术趋势、现实挑战等热点话题，探讨行业未来发展。以下是上汽软件中心首席架构师孟超在“基于SOA服务架构的汽车数字化软件”论坛上的演讲。

孟超，上汽软件中心首席架构师

尊敬的客人，早上好！我叫孟超，来自上汽软件中心。首先非常感谢盖世汽车和AUTOSEMO组委会邀请我来这里分享，今天分享的话题与其说是技术方案，不如说是跟大家分享软件定义汽车的技术趋势和发展方向。

我今天说的话题看似很复杂，但其实就是讲三个关键词SDV、SOA、SSP。第一个是SDV（软件定义车辆），第二个是SOA（面向服务的软件架构），第三个是SSP。基于软件和服务的横向；

在推动四大现代化的过程中，所有汽车企业都在谈论四大现代化（智能化、网联化、纯电动化、共享/情感化）。如今，四大现代化驱动力似乎不太受欢迎，但人们对软件定义汽车的兴趣正在与日俱增。我们开始更加关注AI的应用、场景、用户体验等。在基础技术软件变得越来越重要的今天，我想跟大家分享的主题是“基于SOA服务架构的车辆数字化软件”。

我们今天要分享的第一个主题是“什么是软件定义汽车以及我们为什么要建造一辆？”每个汽车制造商都在开发软件定义汽车，但他们的基本要求是什么？

通过对数据进行统计分析，我们整理了2018年至2019年车展上推出的所有新旧功能，发现按品牌和车型划分的功能存在明显的同质性。比如DLP智能照明、人脸识别、智能助手、智能机器人等功能，尤其是大屏，现在已经从一屏、两屏变成了八、九屏，这些功能特征已经积累起来。在各种型号.至于A、B、C这三款新型号，我们惊讶地发现它们不仅具有相同的功能，而且还使用相同的供应商。在这种情况下，我们面临的趋势是相似，但主机厂的特点是什么？就目前情况而言，该车采用了与其功能相似的堆叠式设计。

其次，我们看一下汽车整体发展趋势。过去我们刚做汽车电子业务的时候，汽车是独立的实体。自此，汽车和人开始通过车载通信技术进行互动。现在，市场上的每辆车都配备了Tbox，并且可以连接到网络，汽车和网络进行交互。但我们对未来的汽车有何看法？我认为汽车会成为整个物联网的载体，这是大家经常提到的一个词，我们应该如何发展这个载体呢？这是汽车制造商的关键一步，难道汽车也通过安装系统和自动驾驶模块而成为数字化的一部分吗？这是一个需要考虑的重要题。

第三，汽车的本质属性是什么？我们制造了一辆传统汽车，就像手机一样，这是一辆功能性汽车，并解决了从A点到B点的更多功能属性。汽车的发展增加了空间属性，比如大屏、自动驾驶，这些都是你追求的空间属性。那么未来的汽车会是什么样子呢？每个汽车制造商都在计划开发未来的汽车，我们觉得这是一个密切的关系。这是人与整个城市之间的关系，包括道路交通。与此同时，由于汽车在其整个生命周期中不断发展，因此需要探索汽车本身之外的更多内容和属性。

在这三个主要前提下，我们正在开发一款软件定义的汽车，并牢记这些题。相信在2017年之前，大众VWOS和特斯拉在规划软件布局时也考虑到了这些因素。从目前的情况来看，汽车行业的硬件现在更多地依赖于Tier1，而软件功能的开发目前都是由OEM或Tier1完成。也出现了。但作为原始设备制造商，我们需要知道我们能做什么、不能做什么，以及什么样的技术将使我们成为行业的领导者，而不是颠覆者。同时，就汽车生态而言，目前所谓的汽车生态只是供应商的组合，真正的汽车生态非常少见。我们每天都在谈论汽车引入的各种生态，比如机的生态，但实际上，分解那个生态之后，我们发现分解出来的功能实际上是手机的功能或者是手机的延伸。虽然它是手机或家电功能的延续，但它不具备汽车本身所具有的生态功能。基于安装在汽车上的500个传感器及其生成的数据的生态系统现在基本上为零。

因此，在这样的大背景下，我们提出了软件定义汽车的核心思想软件汽车在整个生命周期中不断赋能，能够了解用户、车辆本身以及周围环境并进行AI自适应调整。有。基于此，主机厂在开发软件时必须满足哪些要求？一是满足用户的需求，二是满足主机厂自身的需求。基于场景驱动、数据驱动、跨域融合三个方面，打造适合您需求的点。

开发下一代智能汽车需要像手机一样使用软件模型，每个论坛在讨论汽车软件时都会使用手机进行比较。其实Apple4刚发布的时候，可用性和销量都不好，什么时候销量突然猛增呢？之后IOS和新的APP应用通过OTA反复出现。那么我们对汽车有这样的想法吗？为了让汽车成为一个开放的，我们将把所有基础技术都内置到中，并不断扩展和维护汽车的生态系统和数据。有了这个想法，我们相信软件定义汽车可以带来诸如访汽车自身的应用服务生态系统、减少汽车软件开发周期和成本、满足成千上万用户的需求等好处。基于场景化能力的用户需求，包括满足千万级用户的需求。

电子架构在软件定义汽车的话题中已经被多次提及，但现在会有哪些变化呢？我们在这方面也做了一些探索，即从EEA到SSA。这里有一个号，过去的电子电气架构是否能够满足今天的需求。现在它已经转变为服务和软件的架构。事实上，过去传统的功能分配、传统的架构开发模式、开发思路已经不足以满足现在的需求。因此，我们正在进行SSA来满足以上所有要求。这里我就不详细说了。

另外，我们正在对车辆中的所有传感器进行封装和转换，包括车辆各个硬件的封装和IP。你可以知道你在世界的哪个地方，某辆车上的某个传感器在某个地方在做什么，这些变化是手机无法比拟的，这也是我们思考软件定义汽车的第二个方面。

三是软件重组和服务化。我该如何重新配置它？如何将软件设计为服务？包括哪些原子服务和扩展服务？如何封装它？这就是我们面临的题。因此，在这样的背景下，我们提出了技术解决方案的思路SOA的服务架构以及基于软件和服务的软件的设计，即应用可插拔的。

博世首先提出了三个阶段分布式架构、域控制器架构和中央计算，这是我们硬件存在的演变。在软件定义的汽车环境中，硬件被重新定义。所有国产软件——定义汽车实际上都是基于第二阶段，即计算重构过程来开发的，最终会发展到现在的物联网状态，所有与车辆相关的设备，包括云，都将配备协同处理和计算架构，这在两个基础上做SOA是可能的SOA的概念是很古老的一个概念，SOA是在1996年提出的，从那时起，SOA就在互联网行业发展起来，那么为什么它刚刚进入汽车行业呢？原因是时机还不成熟，但我觉得时机已经到了。基于SOA方法论将汽车和物联网集成后，我们部署并封装云、管道和最终集成，利用这种格式实现标准化接口，并以契约精神重新组织整个软件。

过去，整体开发模式耦合度高，偏向于传统的应用程序开发方式，当某些功能更新时，需要重新编译和集成整个东西。现在我们有了SSP这样的应用框架，SOA这样的集成软件框架，我们已经实现了每个应用领域都可以独立分离，通过将服务切分成小维度，单独部署，形成应用服务，找到了。我们将创建一个新的应用程序，这是我们的SOA和SSP的一个伟大想法。

让我告诉你关于SSP的事情。我们过去常常垂直地看汽车。自动驾驶、智能座舱、车辆控制等功能都是垂直发展的，过去的传统汽车爱好者也是垂直看待这些功能的。如果我们做这一轮软件定义汽车，是否需要横向看汽车？我们也在考虑这个题，包括受邀参加AUTOSEMO的时候，我们觉得需要横向的看待这一代，为软件定义汽车打下坚实的基础，而上汽正在开发这样一个软件，SSP。虽然表面上理解为一个VWOS，但我们的设计更深入、更彻底，因为我们更准确地知道需要什么样的SSP，而不是盲目地把每个操作系统都做成中间件。重型建筑。

接下来我要跟大家分享的是云、管、端的端到端融合。是云、管、端一体化的SOA软件。刚才我们提到的就是将各个应用的纵向布局横向打通，然后不断迭代用户场景，丰富SSP。假设考虑到信息安全题，车辆中的SSP最终将是可拆卸的。可复制，可任意组合，传感器可任意暴露在车辆侧面。同时开发了可在车辆端持续支持和迭代的云服务。很多来自不同汽车公司的人都在谈论电子架构。有些人构建4或5个域控制器，因此硬件类型并不重要。重要的是如果可能的话，是否有这样一个可以覆盖算力的软件。你所有的硬件，这就是我给你分享的SOA和SSP。

SOA可以带来哪些优势或好处？过去曾使用过AUTOSAR，但应用开发需要大量时间，统计显示最快可能需要8至10个月才能上线。如果我们换个思路，用现在新的开发思路来开发，如右图所示，一个特定的应用程序一天之内就可以开发出来，包括设计、开发和验证。开发的新应用可以满足当前客户的新需求。必需的。某个特定的用户有这样的需求，而我们的SOA解决方案通过开发这些满足他的需求的应用程序，可以真正满足成千上万人的需求。基于以上开发思路，SSP的开发思路将带来以下设计变化软件架构功能逻辑和软件算法开始集中转移，车端软件架构和云端软件架构不断融合，软件更新方式从分布式更新转向集中式更新。

那么SOA和SSP的新产品形态会是什么样子呢？汽车内的所有控制单元，按照域控制器架构划分，实时上线，上线的结果是为SOA和SSP提供数据通道和数据驱动源，最终迭代创造新动力。这样，我们要完成的SSP就能够开发和运行任何对车型不敏感的软件。

大众号称转型为科技公司，丰田也谈转型为出行公司。在我们这样做之前，我认为我们需要清楚地思考我们能做什么，是否存在这样一个，这个的开发周期和整体产出，包括车型的推出，所有关于主机厂目前面临的挑战。但在目前的过程中，我感觉没有案。