车载算力平台的发展：功能集成度、算力需求、软硬件复杂度、通信需求指数升高；随着EE架构发展，逐步走向计算中央化、数据和能源区域化的形态。整车EE架构与车载算力平台发展的瓶颈在于其简单的逻辑处理、软硬件不通用、应用功能固化、软件不可迭代等不利因素，导致当前这代智能驾驶产品的应用能力无法真正适用于未来的智能汽车开发过程。对于下一代自动驾驶来说，需要强大的数据处理能力，比如使用千兆以太骨干网，5G高带宽，AI计算平台技术；同时，开放的API与IDE也可以将多种传感器数据进行融合，实现数据与API的开放共享，从而拥有强大的应用管理程序APP开发集成环境。
为实现智能车载软件的快速开发，包含面向服务的设计过程，应对不断测试过程中出现的新场景的快速迭代，满足客户千人千面的需求，缩短整个汽车开发周期。此外，通过软件的快速部署，软硬分离，软件重组，应用新增，实现外部资源的有效整合，增加车辆服务的丰富性。
基于SOA的集中式域控架构设计
对于高性能计算平台而言，通常采用集中化跨域融合的域控架构，需要实现多存在于互联类功能或域控间直接交互实现的功能，通过单一大脑HPC+区域控制的架构方案，要求区域控制器承担代理（Proxy）功用，往往与面向服务的SOA架构一起绑定来进行设计，这将导致灵活性扩展性较高的SOA在下一代集中式域控架构中的渗透率将非常高。
采用SOA设计理念，在SOA服务中实现软硬件解耦，控制IO虚拟化、服务化。进行车内多层级服务的定义和部署是下一代域控平台通用的设计方案。对于集中式域控制器平台而言，设计过程中需将车辆控制、自动驾驶、智能座舱多域融合，硬件资源共享，数据实时共享域控硬件：各领域内最先进的芯片，通过高带宽低时延Switch级联软件，除了实现实现算力扩展和多域融合，也可以实现高安全、硬实时OS、中间件及应用运行环境域控与其他控制单元之间通信。
如下图显示了一种基于中央计算单元+区域控制单元的物理架构，对于实现真正的中央计算平台而言，还需要设置1-多个区域控制器PDC、VDC等组成的环网架构用于实现数据和能源网关的功能，从而减少线束数量/长度，优化能源智能化管理模式，有效提升中央域控制器软件化的功能。
此外，对于上述大数据交互来说，也需要设置相应的交换传输单元进行相应的数据交换。这些交换单元包括PCIe Switch、Ehternet Switch、TSN Switch；其中，PCIe Switch满足算力芯片之间的实时大数据交互；解决高带宽、低延时的痛点需求实现任意端到端之间的数据传输，且带宽在20Gb/s以上，物理隔离，单点失效不影响系统失效。TSN Switch具备CAN/CANFD/LIN到以太网的双向传输协议转换功能。实现了TSN协议中的NC/EE/BE不同优先级数据流转发和数据交换。可兼容其它符合车载规范的TSN设备。Ethernet Switch 用于连接以太网之间或者以太网与快速以太网之间的交换机，该交换机通过物理编址、网络拓扑结构、错误校验、帧序列以及流控，从而节省了资源和时间，提高了数据传输的速率。
这里我们需要说明一下，集中式域控设计中需要支撑SOA实现的技术载体。包括了面向服务的通信SOC：DDS、SOME/IP等及服务接口定义和实现；同时面向服务的软件架构支撑SOSA：如AP，是可满足功能安全的一定实时性要求的方案；面向服务重用共享架构设计SORS：自上而下与自下而上的结合，保证服务重用共享以及扩展；
基于SOA范式的产物包含了服务实现的代码/模型，集成了（服务代码+SOC代码+支持SOSA系统环境）的控制器，整车由该控制器组成的子系统。下图显示了一种典型的对域控来说基于SOA从系统设计到代码实现模型的流程图。
基于SOA服务的终端测试
1、基于SOA服务的终端测试流程
对于下一代自动驾驶系统SOA来说，除了应该明确掌握SOA本身的定义外，还需要掌握如何测试SOA，了解其实现的技术产物是什么，基于SOA的实现实体又是什么，基于SOA理念的新EE架构将如何开展测试。本章节将详细讲述SOA的测试流程和方法。
要清楚了解SOA的测试流程，首先需要掌握SOA的设计流程。他包括9个子流程，分别如下：
A1：整车Feature List定义；
A2：Feature的usecase分析；
A3：逻辑子系统定义；
A4：功能需求规范；
A5: 针对SOA服务和服务接口定义，其中服务包含从可行性和必要性角度，哪些功能适用于作为服务，定义其颗粒度，基础服务、扩展服务、应用服务，同时需要定义服务接口；
A6：网络拓扑定义；包括定义拓扑结构、所需通信技术选择；
A7：功能分配和服务部署；
A8：面向服务和面向信号的通信设计；
A9：开发（AP、CP、ROS、COTS等平台选择）、集成、测试；
对于SOA测试对象来说，是参照一种树形结构的方式进行测试的，如下图所示。
首先，是需要进行整车层面分析，使得整个过程更加智能（如自动/辅助驾驶、人车监测）、更加友好（如语音控制、娱乐冲浪）、更加灵活（如功能升级）；其次，是要进行系统层面分析，包括传统基于信号的分布式功能实现，基于高内聚低耦合的服务及服务组合实现，实现混合异构。
在下一层是进行部件层面分析，包含ECU功用和形态分析，即实现“阶层”分化。首先是核心阶层、大脑级，包含域控制器、计算平台多系统多处理器AP+CP，应用服务的提供者和消费者，大网关。桥梁中枢，新生代的区域控制器（VIU类），大量通信端口与IO同时存在，CP；区域网关/代理网关（S2S），兼顾区域部分控制功能，提供基本服务和扩展服务。延续过度，夹心层：底盘控制、被动安全类，典型嵌入式系统，功能安全即实时性要求高的系统；终端层包含传感器及执行器等。
2、基于SOA服务的终端测试方法论
对于SOA的测试来说，首先需要建立和适配测试规范。我们知道，整个测试的分层包括部件、系统、实车。其中部件和系统级别包括验证功能等行为是否与需求规范一致；对于实车来说需要确认是否满足用户、法律法规等需求。
测试的关键是基于需求规范、用户使用、行业法规和标准角度开发测试用例；基于经验和场景开发测试用例和被测对象。增量和变量需求包括新车载通信技术SOME/IP、DDS、TSN、同步CAN等；新增测试类别包括服务接口测试；新增形态和载体包括服务、S2S、异构型域控/HPC、ZCU/VIU/PDC；新功能和应用场景包括个性化配置、远程诊断、网络/数据安全等。
整个测试规范的开发包括，新的车载通信技术测试、服务接口测试、服务“逻辑”测试。
这三大测试包括SOME/IP中的TC8的协议一致性测试、基于自定义需求规范和配置规范，开发测试规范，源自经验的鲁棒性和场景测试；DDS中有基于自定义需求规范和配置规范，开发测试规范，如端到端延时、QoS配置不兼容等；TSN中针对AS、开发测试规范及启动、延迟、稳定性等方面的测试。服务接口测试包含基于服务接口规范开发基础服务、扩展服务和应用服务接口定义的一致性测试，消息时序、数据合法性和鲁棒性测试。服务逻辑测试主要是按照不同层级的需求建立部件级、系统级和实车级测试规范，越向上层，测试用例复用度越高。基于SOA特点，将实现机制、应用场景相结合，在不同层级增加测试用例，如可引起资源消耗场景，端到端服务稳定性和交互响应性能测试，服务与信号转换的性能测试。
如何搭建SOA的测试环境呢？
首先，新架构下面的ECU“阶层”分化，传统“三大件”（包括底盘、车身、动力）控制模式从原始的感知控制一体机朝向功能实现“高内聚”&“低耦合”的趋势，软件迭代越来越快，ICT等行业的实现技术和流程技术将更多的注入到整个变化挑战中。
其影响是在部件级测试中，针对核心控制器的自动化测试更重要，而测试环境的复杂度取决于ECU处于何种阶层。系统级测试则更为重要，环境复杂取决于功能实现方式和分配方案。整车级测试是对传统大VV HIL将一定程度弱化。通常，HIL测试系统常规硬件IO的比重大幅降低，通信资源类型和数量更多，特殊需求采用特殊方案；如TSN、LVDS等专门的通信测试。而对于HIL测试系统软件及工程开发而言，测试系统软件的适应性、扩展性更为关键，这主要可以降低二次开发工作量：如对SOME/IP、DDS、HTTP、MQTT等协议支持。另一方面，仿真环境开发工作将增加：如需要搭建SOME/IP、DDS“参考ECU”的“交互行为”开环模型。对CI/CT的支持：包括系统远程/云端控制、实时监测和自我保护；支持被测对象的远程刷写和编码；支持软件迭代变更点与测试范围的关联等。
对于整个SOA测试而言，其测试手段主要包括虚拟ECU测试技术，其中需要了解实现原理、其适应对象分析、前提条件分析、实现关键技术构建等。同时使用汽车行业主流工具链对前端模型、软件代码进行有效测试，同时除“在线”自动化测试外，基于数据的“离线”测试也成为可选和补充。为了保证测试颗粒度更细，可以通过将测试工作前移，快速构建，适配性强，适应“适合于”汽车领域的敏捷开发。
如下图表示了针对基于SOA服务模型开发过程中，典型的服务接口测试规范实例。可以看出整体的SOA测试规范、步骤和需求结果。
总结
本文首先对基于SOA的集中式域控制器设计逻辑、架构进行了描述，并且对于该设计将如何满足第二部分对SOA的有效性测试进行了关联。SOA的整个开发过程需要进行类似数据闭环，即从设计、开发到测试的整个流程都需要有完整的关联。如果是合作开发的模式，需要分清主机厂和供应商之间的责任界定，确保最终的测试结果满足开发需求预期。当然，无论从开发还是测试，整个基于服务的工具链应该确保一致性，避免出现边缘化不一致导致的结果偏差。
