维克多范科发：SOA设计实现与软件系统验证

7月22日—23日，由盖世汽车主办、上海国际汽车城特别支持的“2020首届软件定义汽车高峰论坛”正式举办。本次论坛主要探讨软件定义汽车领域最新的创新理念、技术趋势、现实挑战等热点话题，共谋行业未来发展之道。下面是维克多汽车技术(上海)有限公司分布式系统与网络部门商业开发经理范科发在本次论坛上的发言：

维克多汽车技术(上海)有限公司分布式系统与网络部门商业开发经理 范科发

大家下午好！首先感谢顾总给我留了多余的时间，因为我一直担心我这个材料比较长一点，我们今天讲了很多的趋势，但是实实在在的我们要去落实一些事情，我相信参会的大多是开发的工程师，那软件产品需要去设计和实现，同时要去验证你这个产品的质量。所以我们这边应景一下，介绍材料背景直接拿了软件来作为我演讲的开场。

我们主要去看一下怎么样做设计以及如何去落地，以及确保质量，在软件这一块。我们看到整个行业在发生比较大的变化，不仅是汽车这一块，越来越多都是以软件为中心，所有的行业基本上软件的价值越来越重，我们对应自动驾驶的车辆、软件的对比越来越多。

汽车行业跟软件相关的，基本上OEM差异化在传感器层面，另外一块主要差异是在应用层面，因为中间的BSP包括一些OS都是有标准化的东西我们直接去采购集成使用的。另外一个趋势是对应软件开发和设计越来越的被OEM控制，不一定软件全部是由OEM去做，但是越来越多的软件掌握的话语权以OEM为主。还有我们沃尔沃同事提到的这个部分，我们这边对应着说供应商和OEM如何去做紧密的配合，我们对应的有持续集成、持续测试，我们越来越多会看到很多车型的功能发布和车型发布是独立开的。

这是一个大的趋势，我们在上午孟超总也讲到了SOA对于未来来说是一个赋能者，SOA的这个技术本身对于我们未来的一些互联也好、自动驾驶也好还是软件更新都是一个最基本的前提，我们采用这样的技术才能去确保我们对应的软件能够持续地去做相应的迭代，去满足我们更多的一些应用。

所以这边我们看到说，软件很重要，然后整个开发流程上有OEM和供应商的配合以及相应的实现，我们逐一来看一下。维克多作为一家供应厂商如何去做这些，因为具体的每一项都是要去落地的。

首先来看一下服务，我相信在座的很多工程师有时候拿dbc去收发一些信号，那什么是服务？服务的载体是什么？包括我们有通讯，那通过什么方式去实现通讯的应用呢？站在OEM的角度我们会去定义各种各样的服务，如孟总上午提到对每个传感器和信号都进行IP化，进行相应的编码，根据我们的应有去做相应的调用。我们能够让我们车里面对应的功能进行相应的升级，去满足我们相应的应用，SOA确保了我们车与外面互联部分能够衔接起来。同时我们也看到了沃尔沃讲到的有高性能的中央控制结点的出现。

在这张图中可以看到我们服务有提供服务的服务方和使用者，比较有趣的是我们的服务可以放在后台的，这是非常有趣的应用场景，我们在云端去实现相应的控制应用，但是这个里面我们去谈SOA和开发的时候，非常致命的一个点就是Security，涉及所有的开发验证工具链体系，每个OEM用的Security都是不一样的，这对于供应商来说是非常严重的挑战，OEM相对来说比较容易一点，因为他们是固定的一套体系，但是我们今天不会展开探讨Security这个话题，我们再回到SOA主线本身上。

我们传统所有这些车辆的设计，我们基本上都在设计的时候会定义数据库，由哪一个ECU发布哪些信号都是固定的，在执行的时候会按照预期设定的方式进行相应的运行，我们在设计的时候系统之间都是静态的通讯，开发通常通过C语言进行开发，在这个图中有相应的通讯应用，但是当我们出现了服务应用的时候，服务还是应用在我们的软件组建或者是ECU中的，我们在设计的时候是设计了一部分，但是在执行的时候其他部分也会占到相应的资源去做运算，而我们在执行的时候才会有对应的功能出现，所以整个是动态的方式去做处理，这个时候我们会通过C++去做这个事情，通常采用Adaptive AUTOSAR实现基于服务的通信，当然经典AUTOSAR平台也支持基于服务的通信。

这是一个简单的对比，相对来说最重要的一点，我们service-oriented这边是动态的，这边更多是在动态执行去做相应的实现，所以这边我们来看一下服务到底是怎么做这个事情的，什么是service？我们对应的不同软件组建或者ECU彼此之间相通讯我们提供的服务，服务有服务相应的接口和方法在里面，因为在座很多是工程师所以我们讲技术的东西会多一点。

然后我们会把定义的service跟具体的ECU去实现服务部署的应用，我们设计的服务非常灵活的根据我们的架构设计和应用部署的对应平台上，去实现服务之间彼此通讯的应用。所有这一切在序列化和反序列化来实现与底层通信，我们对应的是一种中间件的协议，但是跟后台对应的时候我们慢慢看到有一系列相应的协议，这些都是中间件协议，我们需要把这个服务通过中间件协议进行序列化和反序列化的应用，才能让服务在总线上进行相应的传递。我们再补充说明一点，并不是所有的服务都是通过以太网的，因为有些应用我们仍然考虑传统的系统，SOA的需求是：传输速率足够快、数据端有效数据大、支持动态通信。CAN FD这边是可以基于AUTOSAR 4.2中定义的动态PDU，所以动态PDU也是可以实现服务通讯的，而且已有供应商有样件证明可行。以及行业在做相应CAN下一代的总线技术CAN XL也支持基于服务通信，这是明年或者后年会发布的新的技术。也就是说车不可能所有的都用以太网，成本太贵肯定会用混合总线体系在车里面。但是我们的大基调是做服务，传统的部分也需要去做服务去满足我们的应用层面的需求。

我们会通过中间件实现具体服务的承载，我们会在这个里面去定义我们的service定义，我们也会去定义我们的软件和硬件，我们会把service部署到对应的硬件上以及配置我们相对硬件信号路由等等，包括以太网的IP去实现服务的承载。这边是我们要去根据实际车辆情况去把这样的一个服务文件设计出来，去用作我们后面的开发工作，所以这里会导出对应的格式文件去满足我们的应用。

另外我们这个里面要去定义相应的服务，并且也要把服务实力化，比如说服务接口、部署，包括一些状态机的设计，这些在不同层面都是有相应的文件导出，满足于我们后面服务的部署和设计实现。这是我们说的服务是可以去做定义实现的，维克多是一家工具供应商，我们提供PREEVision工具支持Adaptive数据库和以太网数据库的定义，当然也兼容传统总线的数据库定义。当正向开发做好数据库是满足我们在功能仿真、开发实现和测试验证服务功能的基本条件。

我们需要把服务应用在具体的通讯载体以及中间件上去设计出来，然后我们才能做后续的工作，我们要去做实际，在设计好了以后我们去做一些仿真验证我们所设计的内容是不是符合我们预期定义的，仿真了以后才能做开发实现，维克多也是一家软件协议栈供应商，我们也可以把我们定义的相应服务进行相应的应用，我们会看到整个行业是因为车与外面的互联接通之后，原有传统IT很多的知识体系或者是协议等等我们会引用到车里面去，用互联去实现。

另一块我们车本身是非常关心安全的，我们这个行业里面有非常强的技术壁垒，比如说要去做车的诊断、整个工具链的打通等等这一块，我们上下两端都要去接通，我们去做车载高性能的计算控制器的时候，所有传统所使用的相应的工具链以及我们在传统汽车行业里面所适用的方法，就是会出现激烈的碰撞在里面，最终可能大家会走向一致。但是这个里面我仍然强调的是功能安全和信息安全，这是一定逃不开的，我们任何的驾驶都要保证可靠性的，所以我们也要考虑到如何在设计的时候实现安全和可靠性。

还有这个是大家上午讲到的，娱乐系统、互联系统以及软件更新，这几个大方向下去驱动我们在行业里面去做相应的应用。更细节的具体定义是在AUTOSAR里面，Adaptive AUTOSAR平台去详细定义。Adaptive AUTOSAR主要是对应一些模块的API进行规范，具体怎么去实现里面并没有做太多的说明。维克多作为协议栈供应商，积极参与规范制定过程当中去，我们也会跟我们车厂探讨想法去做应用落地在控制器中。我们可以看到图的最上面，我们有很多的APP，每个APP有具体算法实现也有OS和后台本身的平台调用在里面，这是我们具体的一个APP，你可以把它等价地去做类比经典AUTOSAR的SWC，但是这个有很多的复杂性在里面。当然整个系统的开发是需要一系列的工具和协议栈去做配合的，所以我们需要去做设计，包括我们有各种各样的部署文件去设计好，我们也会结合我们自己做的一些算法逻辑和相应的协议站生成代码，我们去做相应的工作，然后我们再编译然后再去做部署，这是如何实现相应开发流程在里面，每个环节涉及诸多细节和工具去把整个事情做出来，先去做定义然后再去做仿真验证，当然还有协议在里面。我们也提供相应的协议模块，能够去满足我们高性能ECU平台需要的各种各样的场景，以及跟各种系统有相应的对接，以及对接相应的部署和承载。同时车对安全的考究是非常严格的，包括我们没有做L3的时候，跟安全相关的都会要求是L4等级的，对通讯协议站也是一样的，也要达到相应的等级才能做相应的应用在这个里面。

针对Adaptive AUTOSAR，Vector在提供协议栈的同时，也提供整个开发的全套工具链，我们会提供服务设计工具和诊断服务的设计工具，我们设计完了之后去得到我们所需要的产物，然后加载到我们对应的工具里面去做仿真，我们去仿真我们这个设计的理念是合理的，我们也会把相应设计的协议栈以及APP开发工具配合到一块去做具体的实现，实现之后就要去做测试验证，也就是下一个话题如何去做测试验证。

测试验证我们涉及的是SOA系统包括Adaptive AUTOSAR系统，也包括我们今天主题中的整个软件系统如何来做验证。在出现Adaptive AUTOSAR后验证复杂化，我们可以看到沃尔沃的架构，它的中央控制单元，这个里面软件系统相信不可能所有的软件都是沃尔沃自己开发的，可能是供应商自己设计好的软件集成到到里面的：我们会从原来的以ECU和总线为主的测试转向以测试APP为中心，我们的功能逻辑是不是符合原来定义的，以及我们通讯的安全是不是能够满足我们的要求等等。对应的AUTOSAR的标准体系为我们做实验提供了标准体系，我们在服务跟服务之间是有契约精神的，你要去测一个APP，跟它交互的APP我们要做仿真出来，以前我们做总线的时候，做一个ECU跟它交互的总下也要去做测试。因为测试有一个很基本的定律：就是尽可能早地去构建一个整车的环境，再去做相应的测试，因为跟实车越接近测试才可能更加可靠一点，对应OEM和供应商都是一样的。

那我们要从技术层面去说明一下，我们在做SOA跟相应的Adaptive AUTOSAR系统的时候，一些基本概念我们先要说明：Communication Object和Binding。通信Object从传统的信号演变为信号、PDU、RPC和Service。图上这些都是我们通讯具体的载体，我们刚刚也提到了，我们单纯去测APP，APP与APP之间可能有相应的交互，同时我们所设计的相应服务一些RPC我们要进行部署，我们可以非常灵活地进行部署和传输，下面这一层我们根据具体的协议去捆绑，我们可以换一种协议，换成Web和HTTP协议都可以应用的，有可能是单纯APP测试，也可能跟协议在一块的应用或者是仿真系统在里面。

无论是这个行业怎么发生相应的变化，基本测试我们不会有大的改变在里面，基本上都要去做比如说模型测试，代码测试和控制器测试，这里重点说明一下代码的这部分，今天我们不会阐述代码本身的单元测试和集成测试。我们提的是软件系统测试，就是没有带硬件板子情况下去做测试，无论是测哪一方面，我们都是要有相应的做测试本身和它交互的模型这边实现相应的交互行为在里面，但是在测试这边我们后面会去重点强调，我们要去改善一下到底怎么去做测试，因为我们原来的测试是文本+脚本的方式，但是现在我们比较期望采用更好的方式是模型和数据的方式来驱动我们的整个测试。

那到底怎么做这个事情呢？模型和数据是什么概念？我们后面会看到。我们在做软件开发的时候，相应的我们的产品不可能开发一次都是没有任何缺陷的，但是我们还需要筛选出来哪些可以做回归，比如HiL台架上100万条测试用例执行后分析定位说10条是因为代码原因引起的，当修改代码后那如何做到代码单元测试、代码集成测试和系统测试？那只要去找到跟它有关联的测试，然后用相应的方式去做，而不是像原来系统工程师一样操作，在工具层面我们是可以解决这一问题的，当然这个也涉及到不同部门之间的衔接问题在里面，以软件的方式去驱动定义，去做相应的测试，我们一定面临的是如何快速地回归测试，也是我们极大的挑战在里面。当然Vector在这块也提供完整的工具来解决这个问题。

已被汽车行业开发验证广泛使用的工具CANoe，但它依旧及其重要的。我们汽车跟IT软件是完全不一样的，我们汽车行业开发软件后要做一系列的测试，每个环节全部是要做相应测试的，这里我们可以完全满足这些测试，我们在一个工具体系里面全部做完这些事情在里面，比如CANoe支持构建MiL、SiL、HiL、DV/PV和EOL测试。同时当服务通信出现后以APP测试为主，以及CANoe这边我们根据最近几年的积累和跟客户的合作，我们重新构建了软件体系去应对我们刚才提到的软件系统和SoA测试的问题，可以去承载相应的中间件协议，去编辑相应的解析数据信息在里面，我们对于SOA的事情还是在持续的增加功能，但是大的趋势我们是SiL，我们肯定要去做软件系统测试，所以CANoe未来也会在这个方面去承载我们相应的测试。我们这边也称之为SIL，这个跟传统的SIL是不一样的概念。传统SiL测试是背靠背测试，甚至很多时候并未实际落地实施。你原来的模型跟代码自己开发的不可能给OEM，但是我们现在是软件系统，我们通过一些手段把算法代码虚拟为dll，给OEM交付虚拟软件，OEM可以在非常早期持续构建子系统和整车，所有的模块全部是虚拟化的方式去提供出来的，作为供应商每天所开发的软件，如果你们供应商这边跟OEM的CI/CT环境打通的情况下，供应商每天设计的部分可以持续编译完了以后给到OEM，OEM可以去做测试，等到我们后面有真实样件时跟硬件无关的做回归，有关的做增加相应的测试在里面。

CANoe4SW是Vector今年即将发布的CANoe体系中的产品。那些软件我们是可以解决的，图中嵌入式系统的软件都是CANoe4SW的应用场景，我们会把软件部署到PC端、虚拟机或者是云端。我们拿相应的工具CANoe4SW去做软件系统功能测试，把相应的软件分为APP端和功能接口端，功能接口端把真实ECU和API换成在虚拟环境下对应的API变量映射起来，就可以去部署一个环境，让它运行起来。那这边也是一样的道理，我们能够通过对应的技术去做这件事情，这是敏捷快速迭代的基本保障。

这边我们能够通过CANoe去做这样的功能，但是如果对应的100万测试用例拿PC顺序执行，也是很费时间的，基本上不可能很快速地拿到结果，我们这边构建技术有新的产品CANoe4Server，采用并行测试技术，按照我们的服务器来进行相应的部署，那我们这边是对应的相应系统都可以去做支持，包括我们跟相应的交互对象可能有闭环的模型在里面，我们可以去实现部署和验证，要能够满足自动驾驶的测试，或有公司真正大规模去做CI的敏捷开发测试这种方式的需求，在CANoe4Server中的配置N足够大时，基本上几分钟你所有的100万条测试用例都跑完了，所以很快能够得到相应的结果。

针对ADAS而言，基于数据驱动的测试来验证软件系统是必须的。因为我们会有非常多的场景和数据去采集和产生，数据有两个部分，一部分是来自于我们相应的仿真环节，我们产生仿真场景去做我们的仿真数据，通过并行的方式去验证我们的软件是否可靠，另外我们也会通过相应的设备去采集数据，把场景的数据灌到场景里面去，去验证我们的软件系统是否是稳定可靠的，如果我们全部是需要用数据去训练的，那很多数据很多设备需要采集，这样我们就能够去部署大规模的测试系统，去验证我们相应的系统，因为你不这么做的话，L4以上的这个成本，你要在很短的时间里面去降低成本这是不可能的，也办不到的事情。Vector提供动力学和场景仿真工具DYNA4，同时也提供实车环境数据采集设备VX1161。

我们拿到数据要去做相应的测试，测试传统的方法有需求和测试规范，按文本的去写相应的脚本，然后再写报告得到验证。我们现在有一种新的方式，我们在传统开发的时候基于需求去建模，在V模型的左侧基于模型的方法是最好的设计理念，而不是手写代码。那反过来也是一样，我们测试的输入也是一样的，那我们对功能测试也可以建模，因为你建模的时候变量和参数做好配置，模型也能够生成对应的测试用例，无论是带有状态机的还是序列组合的方式能够以建模的方式灌到系统里面去做大规模的测试，建模里面各方面都是可以去适用的，Vector提供测试建模工具vTESTstudio，不仅覆盖传统测试方式也支持全新的测试框架和技术辅助大家。

还有一个很重要的点，我们的方法会变成敏捷的方法，但是当你采用有敏捷，你搭建了持续测试的环境，如果你没有自动化的测试脚本，你搭的环境是一个空架子。因为在中国我们很多时候会看到追风，但是你没有足够多的测试用力去考核你的系统，所以如果你只有按照相应的测试用例去做设计才可以达到真正的效果软件系统的验证。