范克法：SOA设计实现与软件系统验证

7月22日至23日，由盖世汽车主办、上海国际汽车城特别支持的“首届软件定义汽车高峰论坛”正式召开。

本次论坛主要探讨软件定义汽车领域的最新创新理念、技术趋势、实践挑战等热点话题，共同探讨行业未来发展。

以下为维克多汽车科技（上海）有限公司分布式系统与网络部业务拓展经理范克法在本次论坛上的发言： 维克多汽车科技（上海）分布式系统与网络部业务拓展）有限公司范科经理给大家送来了下午好！首先感谢顾老师给了我额外的时间，因为我一直担心我的材料有点长。

今天我们讲了很多趋势，但实际上我们必须要落实一些东西。

我相信大多数参与者都是开发工程师，需要设计和实现软件产品，同时验证你的产品的质量。

所以这里我们顺应形势，介绍一下素材背景，直接用软件作为我演讲的开场白。

我们主要看软件方面如何设计、实现以及保证质量。

我们看到整个行业正在发生比较大的变化，不仅仅是汽车领域，越来越多的软件是中心。

基本上，软件的价值在所有行业中都变得越来越重要。

我们处理自动驾驶汽车和软件。

反差越来越多。

汽车行业与软件相关。

基本上，OEM 的差异化在于传感器层面。

另外一个主要的区别是在应用层面，因为中间的BSP，包括一些OS，都是标准化的东西，我们直接采购集成的。

另一个趋势是相应的软件开发和设计越来越多地由OEM厂商控制。

并非所有软件都一定是主机厂生产的，但越来越多的软件拥有由主机厂主导的话语权。

还有我们沃尔沃的同事也提到了这一部分。

我们在此对应供应商和 OEM 如何紧密合作。

我们对应的是持续集成和持续测试。

越来越多的，我们会看到很多型号的功能。

发布和模型发布是独立进行的。

这是一个大趋势。

上午，孟超先生还提到SOA是未来的推动者。

SOA 技术本身将成为我们未来的一些互连、自动驾驶和软件更新的推动者。

最基本的前提是，我们可以利用这个技术来保证我们相应的软件能够不断地进行相应的迭代，以满足我们更多的应用。

所以这里我们看到软件非常重要，整个开发过程涉及到主机厂和供应商的配合以及相应的实施。

我们来一一看看。

作为供应商，Victor 是如何做到这一点的？因为每一个具体的项目都必须落实。

首先，我们来看看服务。

相信这里很多工程师有时都会使用DBC来发送和接收一些信号。

那么什么是服务呢？服务的载体是什么？包括我们有通信，我们如何实现通信的应用？从OEM的角度，我们会定义各种服务。

比如早上孟老师提到，每个传感器、每个信号都应该是IP化的，进行相应的编码，根据我们的需求进行相应的调用。

我们可以升级我们汽车中相应的功能来满足我们相应的应用。

SOA保证了我们的汽车可以和外部互联部分连接起来。

同时，我们也看到了沃尔沃提到的高性能中央控制节点的出现。

在这张图中，你可以看到我们的服务有服务提供者和用户。

更有趣的是我们的服务可以放在后台。

这是一个非常有趣的应用场景。

我们在云端实现相应的控制应用，但是当我们谈论SOA和开发时，非常致命的一点就是安全性，它涉及到所有的开发和验证工具链系统。

每个 OEM 使用不同的安全性，这对于供应商来说非常严重。

挑战，OEM相对容易，因为它们是固定的系统，但是我们今天不讨论Security的话题，我们将回到SOA本身的主线。

在我们所有这些车辆的传统设计中，我们基本上在设计时定义数据库。

哪个ECU释放哪些信号是固定的。

当执行时，它们将按照预期的方式运行。

我们在设计时，系统之间是静态通信的，开发通常是通过C语言进行的。

这个图中有对应的通信应用，但是当我们有服务应用的时候，服务还是应用在我们的软件组件或者ECU中，我们在设计的时候设计了一部分，但是其他部分在执行的时候也会占用相应的资源进行计算，只有当我们执行时才会出现相应的函数，所以整个事情是动态的。

这时，我们会通过C++来做到这一点，通常使用Adaptive AUTOSAR来实现基于服务的通信。

当然，经典的AUTOSAR平台也支持基于服务的通信。

这是一个简单的比较。

相对来说，最重要的一点是我们面向服务的一面是动态的，而这里更多的是动态的执行和相应的实现，所以这里我们就看一下服务是什么样的。

要做到这一点，什么是服务？我们对应的不同软件组件或者ECU相互通信来提供服务。

服务有相应的接口和方法。

因为在座的很多人都是工程师，所以我们会更多地谈论技术。

然后我们将使用定义的服务和特定的ECU来实现服务部署应用。

我们设计的服务非常灵活，可以根据我们的架构设计和应用部署在相应的平台上实现，实现服务之间通信的应用。

这一切都通过序列化和反序列化来实现与底层的通信。

我们对应的是一个中间件协议，但是对应到后台的时候，我们慢慢看到一系列对应的协议。

这些都是中间件协议。

，我们需要通过中间件协议对这个服务进行序列化和反序列化，使得服务能够在总线上进行相应的传递。

让我们补充一点，并非所有服务都通过以太网，因为对于某些应用程序，我们仍然考虑传统系统。

SOA的要求是：传输速率足够快、数据端有效数据量大、支持动态通信。

CAN FD可以基于AUTOSAR 4.2中定义的动态PDU，因此动态PDU也可以实现服务通信，并且现有供应商有样品证明其可行性。

业界正在研究 CAN 的下一代总线技术 CAN XL，该技术也支持基于服务的通信。

这是一项新技术，预计明年或后年发布。

也就是说，不可能所有车辆都使用以太网。

成本太贵，车辆肯定会采用混合动力总线系统。

但我们主要关注的是提供服务，传统部分也需要提供服务来满足我们应用层面的需求。

我们将使用中间件来实现特定的服务。

我们将在此定义我们的服务定义。

我们还将定义我们的软件和硬件。

我们将服务部署到相应的硬件上，并配置我们相关的硬件信号。

路由等，包括以太网IP，实现业务承载。

这里我们需要根据实际车辆情况设计这样一个服务文件，并用于我们后续的开发工作，所以这里会导出相应的格式文件来满足我们的应用。

另外，我们还需要定义相应的服务，让服务变得更加强大，比如服务接口和部署，包括一些状态机的设计。

这些都有相应的不同级别的文件导出，以满足我们后续的服务。

部署和设计实施。

这就是我们正在讨论的可以定义和实现的服务。

维克多是一名工具供应商。

我们提供PREEVision工具支持自适应数据库和以太网数据库的定义。

当然也兼容传统总线的数据库定义。

在开发一个好的数据库前向时，满足功能模拟、开发实现和测试验证服务功能的基本条件是我们的基本条件。

我们需要在特定的通信载体和中间件上设计服务应用，然后才能进行后续工作。

我们必须做好实际工作。

设计完成后，我们会进行一些模拟来验证我们设计的内容是否满足要求。

我们期望定义的东西只能在仿真之后开发和实现。

Victor也是一家软件协议栈供应商。

我们也可以应用我们相应定义的相应服务。

我们会看到整个行业都与汽车和外界的关系有关。

互联网接入之后，很多原来传统的IT知识体系或者协议都会被引入到汽车中，利用互联网来实现。

另一方面，我们的汽车本身也非常关心安全。

我们这个行业有非常强的技术壁垒，比如汽车诊断、打通整个工具链等等，我们要把上端和下端都打通。

当我们做高性能的车辆计算控制器时，所有传统上使用的相应工具链和我们在传统汽车行业应用的方法都会发生激烈的碰撞，最终大家可能会走到同一个点。

。

但这里我还是强调功能安全和信息安全，这是绕不开的。

我们任何的驾驶都要保证可靠性，所以我们在设计的时候也要考虑如何做到安全可靠。

而这就是今天早上大家谈到的娱乐系统、互联网系统和软件更新。

这些大方向将带动我们在行业中做出相应的应用。

更详细的定义在AUTOSAR中，Adaptive AUTOSAR平台对其进行了详细定义。

Adaptive AUTOSAR主要标准化了一些模块的API。

至于如何实现，没有太多解释。

作为协议栈供应商，Victor积极参与规范制定过程。

我们还将与汽车制造商讨论在控制器中实施应用的想法。

我们可以在图片的顶部看到我们有很多APP。

每个APP都有特定的算法实现，里面也有OS和后台平台调用。

这是我们的专用APP。

你可以等效地做到这一点。

它类似于经典的 AUTOSAR SWC，但它有很多复杂性。

当然整个系统的开发需要一系列的工具和协议栈来配合，所以我们需要去设计，包括我们有各种部署文件来设计，同时我们也会结合一些我们自己的算法逻辑和相应的协议站生成代码，我们做相应的工作，然后我们编译然后部署。

这就是如何实现相应的开发流程。

每个环节都涉及许多细节和工具来完成整个事情。

，先进行定义，然后进行仿真验证。

当然，里面还有协议。

我们还提供了相应的协议模块，可以满足我们高性能ECU平台所需的各种场景，以及与各种系统有相应的对接，以及相应的部署和托管。

同时汽车的安全性要求非常严格，包括我们不做L3的时候，安全相关的东西就会要求是L4的。

通信协议站也是如此，也必须达到相应的级别才可以用于相应的应用。

这里面。

对于Adaptive AUTOSAR，Vector不仅提供了协议栈，还为整个开发提供了完整的工具链。

我们将提供服务设计工具和诊断服务设计工具。

当我们完成设计之后，我们就会得到我们需要的产品，然后将它们加载到我们相应的工具中来模拟我们设计的概念，这是合理的。

我们也会结合相应设计的协议栈和APP开发工具来实现具体的实现。

实施后，我们必须进行测试和验证。

，也就是接下来的话题是如何做测试和验证。

测试和验证涉及SOA系统包括Adaptive AUTOSAR系统，以及我们今天的主题如何验证整个软件系统。

Adaptive AUTOSAR出现后，验证变得复杂。

我们可以在这里看到沃尔沃的架构、中央控制单元以及软件系统。

我认为不可能所有的软件都是沃尔沃自己开发的。

可能是供应商自己设计的软件集成。

Inside：我们会从原来的基于ECU和总线的测试转向以APP为中心来测试，我们的功能逻辑是否满足原来的定义，我们通信的安全性是否能够满足我们的要求等等。

相应的AUTOSAR标准体系为我们做实验提供了标准体系。

我们服务之间有契约精神。

如果要测试一个APP，我们需要模拟与之交互的APP。

过去，我们乘坐公共汽车。

在制作ECU并与之交互时，还需要进行测试。

因为测试有一个非常基本的规律：尽早搭建车辆环境，然后进行相应的测试，因为越接近实车，测试就越可靠。

对于 OEM 和供应商来说也是如此。

。

那我们就得从技术层面来解释一下。

我们在做SOA以及相应的Adaptive AUTOSAR系统的时候，首先要解释一些基本概念：Communication Object和Binding。

通信对象已从传统信号发展到信号、PDU、RPC 和服务。

这些就是图中我们沟通的具体载体。

正如我们刚才提到的，我们只是在测试APP。

APP之间可能存在相应的交互。

同时我们还要部署一些我们设计的RPC对应的服务。

我们可以部署和传输非常灵活。

我们根据特定协议捆绑以下层。

我们可以改成一个既可以应用Web协议又可以应用HTTP协议的协议。

可能是纯粹的APP测试，也可能与协议结合。

其中有一个应用程序或模拟系统。

无论行业如何相应变化，我们都不会在基础测试上做大的改变。

我们基本上要做的就是模型测试、代码测试、控制器测试等。

这里我们重点关注这部分代码。

今天我们不会讨论代码本身的单元测试和集成测试。

我们所说的是软件系统测试，也就是没有硬件板的测试。

无论测试哪一方面，我们都必须对测试本身及其交互有相应的模型，以实现相应的交互行为。

但在测试方面，我们稍后会重点关注。

我们需要改进如何做测试，因为我们原来的测试是文本+脚本，但现在我们希望使用更好的模型和数据的方法。

驱动我们整个测试的方式。

那么你该怎么做呢？模型和数据的概念是什么？我们稍后会看到。

我们在做软件开发的时候，不可能每次都开发出没有任何缺陷的产品，但是我们还是需要筛选出哪些是可以用来回归的。

例如，在HiL bench上执行了数万个测试用例后，分析定位说有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来完成这个功能，但是如果在PC上依次执行相应的一万个测试用例，会非常耗时，而且基本上不可能快速得到结果。

我们这里有带有施工技术的新产品。

CANoe4Server采用并行测试技术，根据我们的服务器进行相应的部署。

那么我们这边相应的系统就可以提供支持，包括我们可能与相应的交互对象有闭环模型。

我们能够实现部署和验证，必须能够满足自动驾驶测试的需求，或者大规模做CI敏捷开发测试的公司。

当CANoe4Server中的配置N足够大时，基本上几分钟就可以拿到所有数据。

所有测试用例都已运行，因此可以快速获得相应的结果。

对于ADAS来说，需要基于数据驱动的测试来验证软件系统。

因为我们会有很多场景和数据需要收集和生成。

数据有两部分。

一部分来自我们相应的模拟链接。

我们生成模拟场景用作模拟数据，并以并行方式验证我们的结果。

软件是否可靠，我们也会通过相应的设备采集数据，将场景数据注入到场景中，来验证我们的软件系统是否稳定可靠。

如果我们都需要用数据来训练，那么就需要收集大量的数据和设备，这样我们就可以部署大规模的测试系统来验证我们相应的系统，因为如果你不这样做，你就会有在很短的时间内降低L4以上的成本。

这是不可能的，也是做不到的。

Vector提供了动力学和场景仿真工具DYNA4，以及实车环境数据采集设备VX。

当我们拿到数据后，我们需要做相应的测试。

传统的测试方法有需求和测试规范，我们根据文字编写相应的脚本，然后写出报告来得到验证。

我们现在有了新方法。

我们根据传统开发过程中的需求进行建模。

V模型左侧的基于模型的方法是最好的设计理念，而不是手写代码。

反过来也是如此，我们测试的输入也是一样的，那么我们也可以对功能测试进行建模，因为当你建模的时候变量和参数都配置好了，模型也可以生成对应的测试用例，无论是与可以将状态机或序列组合方法以建模的形式引入系统中进行大规模测试。

建模的各个方面都可以应用。

Vector提供了测试建模工具vTESTstudio，它不仅涵盖了传统的测试方法。

它还支持新的测试框架和技术来帮助每个人。

还有一个非常重要的一点是，我们的方法将成为一种敏捷方法，但是当你采用敏捷时，你就构建了一个持续的测试环境。

如果你没有自动化测试脚本，你搭建的环境就是一个空架子。

因为在中国我们经常看到追风，但是你没有足够的测试力度来评估你的系统，所以如果你只根据相应的测试用例进行设计，就可以达到软件系统验证的真正效果。