对ECU及其软件系统进行开发测试常常需要多种专业工具协同，搭建一个高效的测试环境，行业内大部分工具虽然具有优质的功能与特性，但往往功能单一且因接口特殊，较难与其他工具交互。

　　这一问题限制了工具功能的可发挥性，为了满足多工具集成测试系统的需求，需要提高接口的扩展性和多样性。另外在HPC、区域或云端软件系统开发中，也需要工具对软件系统进行测试，面临如何在软件系统测试层面和ECU测试复用一套工具链，将是后续开发测试面临的另一个挑战。

　　维克多推出的总线与HIL测试工具CANoe（CAN Open Environment），致力于最大程度地解放测试工具潜力，以开放兼容的多接口、多语言适配服务，实现多样性的工具组合，为用户提供丰富的解决方案，近年来进一步开发功能构建软件系统测试，使得CANoe满足SIL应用。

　　据维克多官网，2022年发布的CANoe 16.0版本新增AUTOSAR规范的LIN总线E功能安全应用、vTESTstudio新增Python设计测试脚本；在网联化方面新增HTTP封装、软件化方面运行在服务器中的CANoe4SW已支撑CI/CT自动化等诸多新功能。

　　SDV论坛上，维克多汽车技术（上海）有限公司商业开发经理范科发重点介绍了软件定义汽车的软件需要测试的SIL和DevOps测试平台，如何实现软件虚拟化和虚拟交付，以及部署服务器版本CANoe：CANoe4SW Server Edition实现SIL应用中的CI/CT/CD和并发测试。

　　正如范科发所感受到的：“越来越多的传统汽车工程师将变成以软件为主的IT类工程师，大部分的工程师需要和代码打交道，测试工程师除了熟悉CANoe，还需要熟悉AUTOSAR、Linux、Python…”。

　　传统汽车电子开发按照“V模型”进行：从需求编译、单元测试（MISRA静态规则测试；动态集成测试；功能测试；边界测试）、软件集成测试、硬件在环测试、最终进入实车测试。

　　相较而言，软件开发的流程通常如下：设计阶段（Design）：对软件开发的需求进行分析设计；开发阶段（Develop）：完成开发所需的工程代码，运行单元测试和其他小型测试；测试阶段（Test）：完成软件大型和专项测试，如界面测试，API测试、性能和系统测试等；发布阶段（Release）：产品发布与交付客户。

　　这一过程需要持续集成/CI、持续测试/CT、持续交付/CD、持续部署/CD。CI是敏捷开发（Agile Development）的关键，要求每日频繁地将代码集成到主干分支中，在集成前必须通过自动化验证测试，重点在于集成的快速性，如专注敏捷开发的行业大牛Martin Fowler所言：“持续集成并不能消除Bug，而是让它们非常容易被发现和改正”。

　　CI与CT通常紧密结合在一起，小型的单元测试会与CI同步进行，以便开发人员以尽量短的时间间隔发现Bug所在并进行修正，从而保证软件项目质量的持续改进。

　　总体而言，CI/CT的意义在于确保软件的每一次改动都尽快部署到模拟产品环境中使用严格的自动化测试，确保软件的应用和服务能够符合预期。

　　范科发提出，CI/CT所使用的工具必须全自动化进行部署和应用，要做到“所有事情都以代码实现/Everything as Code”，而自动化可以释放DevOps模式的所有活力，所谓DevOps，顾名思义，是Dev（开发人员）+Ops（运维人员）：开发运维一体化。

　　代码层面的敏捷开发解决了协同开发和多机器部署开发问题，但无法解决大体量公司人员交接的矛盾，DevOps既是一种综合协调资源的理念，也落地为平台工具：涉及项目管理、代码管理、CI/CT、CD、系统监控等一系列流程，对“人、流程、平台”三者进行全流程、端到端的部署与调配。

　　范科发介绍，在DevOps中需要工具具备“业务流”的自动化集成，但面临最困难的点是如何实现软件虚拟化，以便实现虚拟测试、虚拟标定、虚拟诊断和虚拟交付。

　　现如今，域控器、区域和中央计算中心的大量软件将由多方独立并行开发集成，因此，在开发阶段容易因为无硬件、或者耦合软件由第三方开发而无法实现测试工作。如果将系统验证统一放在汽车软硬件集成之后，敏捷开发中CI/CT所需要的自动化测试设备和时间成本会极其高昂。

　　首先了解一下汽车开发测试的主要环节：软件在环测试（SiL）与硬件在环测试（HiL）。其中，“狭义”的SIL需要验证模型自动生成的代码，以及用于代码生成的模型行为是否一致的等效性测试，无法应用于未采用MBD（基于模型进行定义）开发的软件系统。

　　范科发介绍道，Vector提供CANoe、CANoe4SW和CANoe4SW Server Edition提供“广义”的SIL，侧重点在于软件系统，提供不依赖于硬件和算法模型环境的验证，测试过程中，被测ECU的软件运行及测试都在单纯的PC或IT环境中，即不带有任何真实硬件ECU和其工作所需真实组件，实现了全虚拟化环境测试。

　　范科发强调，在软硬解耦、软件定义汽车的趋势下，汽车行业中将涌现越来越多的纯软件供应商，虚拟测试环境的构建会是必经之路，软件虚拟化将包括三个方面：运行环境虚拟化、物理环境虚拟化、与被测软件交互的软件系统虚拟化。

　　首先，运行环境的虚拟化可以满足更高的扩展性要求，系统性测试可以更早进行以节省成本，实现完全的软硬解耦，满足极端场景测试。

　　物理环境的虚拟化具体指传感器和执行器的接口仿真，实现了接口复用，避免避免测试执行中的错误和无意义测试，支持CI/CT的自动化测试。

　　最后，构建仿真的与被测软件交互的软件系统，支持测试云端通信与云端失效的各种情况，并行测试无需额外接口，每个test instance可独立访问后台数据。

　　基于SIL测试，维克多推出开发、测试和分析网络物理系统软件的测试执行CANoe4SW Server Edition，测试对象可能是单一的软件组成部分、子系统、整个分布式系统，允许在基于Windows或Linux的服务器环境中完全自动执行CANoe的测试工程，服务器环境并不局限于标准操作系统，同样适配于虚拟机系统以及Docker上，满足自动化CI/CT应用。

　　此外，使用命令行工具sil-adapter-builder可以使得C、C++、Python适配服务代码可在持续集成中触发自动编译生成。

　　除了上述的虚拟化集成外，CANoe也提供更多可选择的虚拟集成方案：利用WSL共享网络实现与CANoe集成、建立具有相同通信功能的内部/外部IP隧道（Tunneling）、利用CANoe内嵌的MATLAB接口，使用FMI/FMU交互接口、基于CANoe私有的FDX实现交互等。

　　在新发布的16.0版本中，CANoe4SW借助AI Visualizer在可视化上取得了进展：可以将AI组件和 CANoe之间交换的图像可视化，并通过突出输入图像中的重要特征来解释AI输出。

　　在车载以太网和SOME/IP（基于IP、可扩展、面向服务的中间件）兴起之前，要在CANoe中仿真CAN/LIN总线：首先会在CANoe测试环境中加载数据库实现总线和节点，以此添加各种系统变量，完成所有配置后，可在CAPL语言环境中访问各类对象与实现各项功能。

　　从基于信号的总线式传输转向基于服务的SOA架构之后，基于服务的数据库将是最大挑战，需要支持SOME/IP、DDS和MQTT等多种中间件的数据库定义或修改。CANoe提供的vCDL（面向服务的通信数据库），这是一种对SOA通信进行描述的语言，通过vCDL可以编写后缀为.vCDL的Data Source来代替ARXML用在CANoe仿真中。

　　解决了数据库这一首要问题，要在CANoe中实现基于服务的SOA通信协议仿真，就可以直接通过vCDL进行节点的设计、导入与修改，接着进行仿真配置和程序设计，最后进行仿真结果分析，针对vCDL中定义的数据可使用CAPL、C#和Python直接编程处理。

　　CANoe产品如其名，“Open Environment”表明CANoe软件支持不同应用程序选项和接口、可与各种编程语言配合使用，以开放性，兼容性，协同性著称，通过“组合与合作”这两个关键词成为一款强大的系统性测试解决工具。同时配合Vector提供的自动化脚本平台vTESTstudio，可满足各类黑盒测试。

　　推此及彼，这和开源灵活的编程精神相仿，编程上手的关键不在于硬敲代码，凡事都要亲历亲为，而在于灵活运转于各库，集万家经典于一体，正如范科发所言：“Everything as Code”，在这个信息爆炸、技术爆炸的时代，在量才适用、各尽其才之后，敢于将不熟悉的技术领域交给生态也很重要。

　　（以上内容根据维克多汽车技术（上海）有限公司商业开发经理范科发于2022年8月3日由盖世汽车、AUTOSAR组织联合主办的2022第三届软件定义汽车论坛暨AUTOSAR中国日发表的《供应商是否为OEM软件系统虚拟交样做好准备？》主题演讲进行理解和整理。）

　　以上内容转载自盖世汽车，目的在于传播更多信息，如有侵仅请联系#替换成@)删除，转载内容并不代表第一电动网（）立场。