整车电子电器架构面临着智驾系统、智慧车身、智趣座驾、智联服务的挑战。SOA是面向这些挑战的有效手段，通过SOA服务架构实现灵活可变的软件系统。

  上汽大众智能网联研发高级总监朱丽敏表示，SOA电子电器架构面向服务通讯方法，实现了服务远程调用，软件异地部署，易于兼容和更新，并应用于车内域控制器和云端服务器。上汽大众从分布式架构切换成了基于域控制器的集中式架构，逻辑功能集中在域控制器或云服务器中，采用SOA技术，充分的利用车内控制器资源，并满足网络性能要求。

  最后，SOA也可以定义，S还是service，是万物皆可服务；O可定义为network，即怎样服务网络和架构连在一起，提供更多的可能；A是architecture，如何把服务的架构深化，能够做的更好。

  我来自上汽大众的智能网联研发部门，该部门成立于去年5月份。我们的团队有着长期的电子电气研发经验，现在专注于软件领域，主要是针对座舱系统，网联系统，以及整车电子电器架构进行研发。很荣幸在这里分享一些在智能座舱领域的探索和经验，作为合资企业，上汽大众在过去十多年里也进行了很多符合中国市场需求的创新和尝试。

  我今天的分享分为四个部分：第一部分，对于SOA服务架构的理解；第二部分，SOA服务架构的应用实践；第三部分，基于SOA服务架构的汽车生态探索；第四部分，未来展望。

  汽车的应用面临着架构变迁的挑战，其中一个是无人驾驶。目前，从驾驶辅助到未来的无人驾驶的应用深度不断的提高。另一个是智能座舱和网联，这样的领域创新不断涌现。座舱系统的功能是实现车身与大脑的协同，完成各种应用。还有一个是云端，它可以通过云的能力，把更多的IOT和服务联系在一起。这些都给我们整车的电子电气架构带来了全新的挑战。

  为了应对这些挑战，我们大家都认为SOA是必然的选择。SOA是一种对软件进行架构设计的模型和方法论，在不同的领域有独特的设计理念。它的核心目标是灵活可变、可升级、可部署。我们大家可以通过SOA实现关键应用的标准化封装和软件的复用等要素。SOA最频繁提到的两个词就是服务和中间件。服务是一系列应用的集合，通过服务接口与其他服务进行交互。中间件是保证应用与底层软件的交互和互通的桥梁。

  采用基于SOA（面向服务的架构）的电子电气架构，采用服务化的通信方式，可以实现服务的远程调用。为了满足这种通信方式的需求，我们需要具备高带宽、低延时的特性，无论是车内的通信还是车内与云端的通信，都需要保证通信的兼容性，确保不同类型的生态功能能够根据自己的特点进行开发，而不会产生过多的依赖。软件可以实现异地的部署，灵活地被车内的服务或者云端的服务调用，这些特性是整车架构从传统架构向中央计算架构演进过程中核心的方案解决。西门子、百度、Sonatus等公司都提供了很多基于SOA架构的解决方案和应用 。

  在传统的汽车研发过程中，所有的汽车功能在初期就已经定义好，而在量产交付之后，基本上不会有变化。甚至有些整车厂要求在设计冻结投产前的一年半以上时间内，不进行任何软件功能的升级。这样的做法在目前行业智能化的趋势下是难以被接受的。

  在软件定义汽车的新时代，汽车的软件功能必须持续更新迭代。软件供应商不需要在一年半之前就冻结所有的功能，但是底层的功能和能力还是必须提前确定好。如果有一些功能无法在一年半之前完成，还需要进行风险管理，避免对整车系统造成影响。

  可以想象，未来的汽车软件不再是静态的功能，而是在交付以后，在用户使用产品的生命周期中都需要不断地升级和改变。刚才Sonatus介绍的方案非常令人兴奋，我们认为，目前主要的功能还是需要按照传统流程进行开发，同时也会出现新的软件迭代方式，保证解耦性和升级的安全性。

  此外，车辆在下线时应预留一定的算力和硬件能力，以便随着技术的逐步成熟，架构能够支撑软件的自有升级和迭代，为用户带来新的创新和应用，甚至产生更多的增值服务。

  既然面向服务的架构可以提高车载软件系统的灵活性和可扩展性，那么上汽大众在SOA技术上有哪些实践呢？如图所示，我们分了三层：云端、域控和执行传感器层。这个架构是2020年投产、2021年上市的ID系列车型开始量产应用的。我们说三层架构，其实也是基于SOA理念开发的。云端通过无线交互、数据预埋和数据采集，提供数据驱动的软件开发支撑，并能不断接入新服务。域控集成是车内功能的逻辑中心，是大数据的集成平台，能够收发数据，并在车内提供更多服务的可能。同时也是应用主要的算力平台。执行器和传感器层是实现基础功能的层面，软件和硬件相对简单，维护成本相对低，这为未来功能的升级带来了可能。但是，也带来了一些新的挑战。

  虽然软件分层、硬件分层可以实现解耦，但是在开发过程中，这样的解耦给整车厂带来了很多问题。在理想情况下，所有的底层和上层应该完全解耦，完全分开，但是在实际应用中，功能层面的解耦还很难做到。因此，任何一个软件升级都需要在整车层面进行大量的集成测试和验证，这就增加了软件集成和交付管理的复杂度。

  域控制器提供了额外的算力和可能性，但是也增加了新的成本。新能源车辆对我们来说，成本压力更大。

  组织架构也面临着挑战。因为全新的模式要求功能跨域打通，而传统的方式是按照零件或系统开发的。如何实现跨域打通的工作，如何实现面向功能而不是面向零件或系统的交付，这些都是需要解决的问题。

  第一，我们基于HTTP协议层，根据不同应用场景的需求，进行协议的定制和适配。保持原有的风格的同时，符合车规通信的标准。我们主要应用这一方案于应用领域，车云通信和信息系统。

  第二，采用SOME/IP协议，将符合AUTOSAR规范的协议作为车内主要服务通信的协议，用于控制相关的周期性通讯，主要用于控制类数据的传输。

  第三，采用MQTT技术，这是一种物联网的成熟技术，我们尽可能沿用现有IT通讯协议栈，主要将这一方案应用边缘计算和IOT设备的接入，引入L2TP加密和特定数据交换方式，我们能够兼容不同供应商和不同生态的应用，打造我们自己的全新平台。

  在通信层面，我们实现了信号和服务混合的模式，实现带宽合理利用，服务与硬件分离，服务远程调用。既能优化传统的通信负载，又能利用以太网资源实现负载均衡、安全加密和实时通讯。这对我们的开发端和测试端都提出了更高的要求。我们需要在数据路由、通信配置等方面有更强的能力，同时也需要有更多懂车又懂以太网的人才。

  在介绍软件架构与SOA之前，我们先回顾一下ICAS域控制器，这是一个大众自主研发的集中式的服务部署处理器，它能够通过多种虚拟机的方式来支持不同的功能类型、不同的安全要求、和不同的实施性要求。同时，它也通过域间的通信技术来实现统一的软件架构。

  这样的设计，使得我们能够实现软硬件分离，提高系统的可复用性和可维护性。但这也给我们带来了更多的测试工作，比如我们必须要自己做一些内部的协议层测试，以往我们只需要使用以太网来进行通信，但是未来我们还要考虑控制器内部的缺失和异常。

  下面讲到芯片与SOA，要打通以太网/高性能网络和SOA架构，这一块的挑战主要有两个方面：一是通信芯片，怎样保证可靠性，尤其是必须有一些通信安全的机制，冗余的通信等等。甚至于包括以太网，在出现问题的时候，我们是否能够最终靠降级的方式去实现。二是车规级的SOC，在选型的时候发现可以选择的并不多，甚至还出现了芯片供应商跳票的情况，项目已经开始了，做到一半，结果供应商告诉我们，原来承诺的做不到了。在这个过程中，我们发现SOC对我们整个团队的制约非常大。

  现在我们也希望看看国产芯片未来是否有可能成为一种新的选择。目前其实有很多芯片供应商已经在这个方向努力了，未来两到三年可以进入量产。但能否真正投入使用，这一点还需要等待市场的验证。整个产业链，无论是软件还是硬件，设计还是制造，是否能有机地合作在一起？这仍然是一个问题。

  随着数据量、软件量和功能的增加，用户隐私和国家合规性等对汽车的信息安全提出了更高的要求。

  我们目前采用了虚拟局域网的方案，通过VLAN划分不同安全等级的区域，并在安全区域之间设置过滤器和防火墙。我们主要考虑了以下几个方面：如何预防网络攻击，如何避免不可信的中间人攻击，如何减少自动化配置的风险，以及如何实现端到端通信的加密保护。另外，我们也重视软件知识产权的保护。由于开源软件应用广泛，我们需要有效地管理和审核软件代码，并建立相应的认证和管理机制。最后，我们还关注接口API的标准化、共用化和安全防护。

  在未来的项目开发中，我们如何做好SOA，我们认为必须从整车到软件，再到芯片，有机地结合起来考虑。具体来说，我们需要考虑高性能的SOC芯片和通信收发器，面向服务的通信中间件，统一的软件架构和技术服务，以及基于SOA的整车电子电器架构。

  在芯片开发方面，我们关注三个层面：外设层，核心层和版载层。核心层的芯片，我们会选择国内外主流的SOC，它们都采用了功能分割和物理隔离的方式来实现。版载层的芯片，我们会集成一些基础的PHY芯片，并寻找可以二次开发的软化芯片。

  外侧层，包括以太网控制器等等，我们会将国内外主流的SOC都必须纳入产品的规划范围，这对我们软件知识产权的路线和复用有重要的影响。

  我们的服务通信中间件开发主要采用平台驱动的思路，即建立自己的平台，并利用供应商已有的成熟产品。但是如何基于成熟产品进行适配，实现控制器的融合，是整个SOA架构设计的难点。我们的解决方案是对不同应用服务进行打包，形成自己的接口调用。我们负责服务接口的开发，业务逻辑的开发，集成环境的部署。同时，我们希望跟更多的供应商合作，实现高效低投入的开发。

  整车软件架构设计要实现SOA，基础服务是主要抓手。我们认为，基础服务是一种功能或服务，也可说是具有特定功能的软件模块，是实现全域服务化的核心技术之一。所有的基础服务在车内必须是唯一的，不能出现重复。最关键的是基础服务必须跟用户体验无关，只代表一定的物理特性和化学特性。

  随着整车的电子电器架构从分布式向集中式转变，面向服务的理念也会出现不同的应用层次。在分布式架构中主要通过网络协议实现控制器之间的调用，但这种方式仅限于车机系统，与云端无关，属于局部性的SOA。在过渡架构中能轻松实现了较为完整的SOA，但仍需优化结耦性。在集中式架构中就需要实现端到端的全域服务化，进一步深化SOA的应用。

  以下是一些案例，展示了SOA在不同场景下的作用，例如第一个案例是如何通过SOA实现域内软硬件分离开发。我们将安卓系统内的生态与车辆之间的交互通过与LINx系统之间的通讯实现。具备域内服务化，从而方便实现软硬件分离开发：为适应信息娱乐域控制器本土化需求，基于德国大众平台，增加Android系统，即保证系统软件复用，又新增中国特殊需求；采用核间通信，Android Gateway等方式，实现系统间的服务调用。

  第二个案例是通过SOA实现开发分工重定义，我们可以采用SOA技术，合理划分开发分工，提高开发效率和降低维护成本：下图中红色框表示：提出中国特殊需求，本土设计软件逻辑和分配，完成服务实例本土化开发；蓝色框表示：按照全球技术平台的服务接口标准化设计；黄色框表示：合作完成中国特殊需求的服务架构集成。

  值得注意的是，我们在设计服务框架和接口定义时，需要考虑如何实现本土的服务一体化。比如说，在研发过程中，我们遇到了一个导航功能的问题：导航功能的定位不稳定，时而在这里，时而在那里。经过分析，我们发现问题出在协议内的定位服务上，同时在以太网也有一个定位服务，两个服务的地址采用同样的地址，导致我们调用服务时出现混乱。这个问题让我们意识到，新技术的落地对管理上的要求很高，尤其是跨系统的协调。因此，在设计服务框架时，我们要提高设计的灵活度和自由度。

  此外，我们还探索了如何把传统的功能服务化。以用户信息显示功能为例，不同的系统需要把用户信息显示在不同的屏幕上，有的是仪表，有的是抬头显示。我们把这个功能整合为一个服务，让不同的屏幕，不同的系统可以调用，这样可以大大简化功能开发。

  语音功能也是我们重点关注的领域。我们想通过语音来取代屏幕交互，提供用户更快更直接的应用触达，也能够给用户更情感化的交流。为了实现这个目标，我们应该把整车接口全部打开。我们正在开发中逐步实现这个方向，我们预计明年投产的产品会打开更多的接口。传统的设计仍然是每个应用单独去做设计到底层的访问，或者有很多服务没有封装出来，整个语音没有办法提供智能化的服务应用。

  云端也是我们服务化设计的重要部分。通过SOA，我们可以把车内的服务接口通过云端直接调用。目前我们已经实现了49种场景的快速实现。

  我们正在探索如何将IOT系统设备集成到车辆中。例如，我们想要将车内的服务，如空调，分装出来，并拓展到IOT设备上。这样，我们就可以从IOT设备上看到更多的车辆信息，并对车辆进行一些额外的指令输入。这是我们在SOA方面所做的工作和思考的内容。我们的诉求是什么？我们遇到了什么困难？在软件领域，如何做好SOA是大家的共识，也是对整个研发团队的一种新的思路和新的模式。

  最后，我们大家都认为SOA可以定义为：S-Service服务，即万物皆可服务；O-NetwOrk开放，即通过将一切东西连接起来，构建服务网络和架构，提供更多的可能；A-Architecture架构，即如何深化服务的架构，使其更优化和更高效。

  （以上内容来自上汽大众智能网联研发高级总监朱丽敏于2023年3月14日-16日在2023第四届软件定义汽车论坛暨AUTOSAR中国日发表的《SOA技术与车-软-芯联动的探索与实践》主题演讲。）