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

7月22日至23日，由广汽主办、上海国际汽车城支持的“2020首届软件定义汽车高峰论坛”正式举行。本次论坛主要探讨软件定义汽车领域的最新创新理念、技术趋势、现实挑战等热点话题，共同探索行业未来发展之路。以下是维克多汽车技术（上海）有限公司分布式系统和网络部业务开发经理范克发在本次论坛上的讲话：

下午好，维克多汽车技术（上海）有限公司分布式系统和网络部业务开发经理范克发先生！

首先，我要感谢顾先生给了我额外的时间，因为我一直担心我的材料可能有点长。今天，我们讨论了许多趋势，但我们确实需要实施一些事情。我相信大多数与会者都是开发工程师，需要设计和实施软件产品，同时还要验证您的产品质量。所以，让我们花点时间介绍一下材料的背景，并直接使用该软件作为我演讲的开始。我们将主要研究如何设计和实现，以及确保软件方面的质量。我们看到整个行业正在发生重大变化，不仅在汽车行业，而且越来越以软件为中心。软件在所有行业的价值基本上都在增加，我们正在比较越来越多的自动驾驶汽车和软件。汽车行业与软件相关，OEM差异化主要在传感器层面。另一个主要区别是在应用程序级别，因为中间的BSP（包括一些操作系统）是标准化的，我们直接购买并集成它们以供使用。另一个趋势是，软件开发和设计越来越受原始设备制造商的控制，不一定所有的软件都由原始设备制造商完成，但越来越多的软件由原始设备供应商主导。至于沃尔沃同事提到的部分，我们谈论的是供应商和原始设备制造商如何密切合作。我们谈论的是持续集成和持续测试。越来越多的时候，我们会看到很多车型的功能发布和车型发布是相互独立的。这是一个主要趋势。上午，孟超先生还提到SOA是未来的推动者。SOA技术本身是我们未来互联、自动驾驶和软件更新的基本前提。只有采用这项技术，我们才能确保我们相应的软件能够不断迭代，满足我们更多的应用。因此，在这里我们看到软件非常重要，整个开发过程涉及原始设备制造商和供应商之间的合作，以及相应的实施。让我们看看每一个。作为供应商，Victor是如何做这些事情的，因为每一个具体的项目都需要实施。首先，让我们来看一下服务。我相信在场的许多工程师有时会使用DBC来发送和接收信号。那么什么是服务呢？服务的载体是什么？包括我们的通信，我们如何实现通信应用？从OEM的角度来看，我们将定义各种服务。例如，孟先生在早上提到，每个传感器和信号都应该根据我们的需求进行IP化、相应编码和相应调用。我们可以升级汽车内部的相应功能，以满足我们相应的应用程序，SOA确保我们的汽车能够与外部互连连接。同时，我们也看到了沃尔沃提到的高性能中控节点的出现。在这个图中，我们可以看到我们的服务有服务提供商和用户。有趣的是，我们的服务可以放在后台，这是一个非常有趣的应用场景。我们在云中实现了相应的控制应用程序。然而，当我们谈论SOA和开发时，一个非常致命的点是安全性，它涉及所有的开发和验证工具链系统，每个OEM使用的安全性不同，这对供应商来说是一个非常严峻的挑战。原始设备制造商相对容易，因为他们是一个固定的系统。然而，我们今天不会深入研究安全性的主题，我们将回到SOA主线本身。在所有这些车辆的传统设计中，我们基本上在设计过程中定义了一个数据库，哪个ECU释放哪些信号是固定的，并在执行过程中以预期的方式运行。在设计过程中，系统之间的通信是静态的，通常通过C语言进行开发。在这个图中，有相应的通信应用程序，但当我们有服务应用程序时，该服务仍然应用于我们的软件组件或ECU中。当我们设计时，我们设计了一个部分，但在执行过程中，其他部分也占用了相应的资源来进行计算，而我们在执行过程只有相应的功能。因此，整个过程是动态完成的，我们将使用C++来实现这一点，自适应AUTOSAR通常用于实现基于服务的通信，当然，经典的AUTOSAR平台也支持基于服务的通讯。这是一个简单的比较。相对来说，最重要的一点是，我们面向服务的一面是动态的，而我们的一面更侧重于动态执行，以实现相应的实现。那里……

那么，让我们来看看服务实际上是如何做到这一点的，什么是服务？我们提供的服务对应于不同的软件组件或彼此通信的ECU。这些服务有相应的接口和方法，因为你们中的许多人都是工程师，所以我们将更多地讨论技术。然后，我们将定义的服务与特定的ECU相结合，以实现服务部署的应用。我们设计的服务非常灵活，可以根据我们的架构设计和相应平台上的应用程序部署进行相互通信。所有这些都是通过序列化和反序列化与底层通信来实现的。我们对应于一个中间件协议，但当我们对应于后端时，我们会逐渐看到一系列相应的协议。这些都是中间件协议，我们需要通过中间件协议应用程序序列化和反序列化此服务，以便相应地在总线上传输服务。我们想补充一点，并不是所有的服务都是通过以太网提供的，因为一些应用程序仍然考虑传统系统。SOA的要求是：传输速率快，数据端有大量有效数据，并支持动态通信。CAN FD可以基于AUTOSAR 4.2中定义的动态PDU，因此动态PDU也可以实现服务通信，并且现有供应商的样本已被证明是可行的。该行业正在开发相应的CAN下一代总线技术CAN XL，该技术也支持基于服务的通信。这是一项将于明年或更晚发布的新技术。也就是说，不可能所有的汽车都使用以太网，如果成本太高，肯定会在车内使用混合动力总线系统。但我们的主题是提供服务，传统部分也需要提供服务来满足我们的应用程序级别需求。我们将通过中间件实现特定的服务托管，在中间件中我们将定义我们的服务定义以及我们的软件和硬件。我们将把服务部署到相应的硬件上，并配置我们的相关硬件信号路由，包括以太网IP，以实现服务托管。在这里，我们需要根据车辆的实际情况设计一个服务文件，用于我们未来的开发工作，因此我们将导出相应的格式文件，以满足我们的应用要求。此外，我们需要定义相应的服务，并对其进行加强，例如服务接口、部署和一些状态机的设计。这些都与不同级别的相应文件一起导出，以满足我们未来服务的部署和设计实现。这就是我们谈论的可以定义和实现的服务。Victor是一家工具供应商，我们提供PREEVision工具，支持自适应和以太网数据库的定义，以及传统的总线数据库定义。在开发一个好的数据库时，它是我们满足功能模拟、开发实现和测试验证服务功能的基本条件。我们需要在特定的通信运营商和中间件上设计服务，然后才能进行后续工作。我们需要做实际的工作，在设计完成后，我们需要做一些模拟来验证我们设计的内容是否符合我们的期望。在模拟之后，我们可以继续进行开发和实现。Victor也是一家软件协议栈供应商，我们也可以应用我们相应定义的相应服务。我们将看到，整个行业都是由于汽车与外部世界之间的互联互通。许多传统IT的知识系统或协议将参考汽车，并通过互联实现。另一方面，我们的汽车本身非常关心安全问题。我们的行业存在强大的技术壁垒，例如诊断汽车和连接整个工具链。我们需要把两端连接起来。当我们去制造高性能的车载计算控制器时，传统汽车行业使用的所有传统工具链和适用的方法都是必要的，内部会发生激烈的碰撞，最终每个人都可能走向共识。但我在这方面仍然强调的是功能安全和信息安全，这是无法避免的。我们在任何驾驶中都必须确保可靠性，因此我们还需要考虑如何在设计中实现安全性和可靠性。这就是今天早上大家谈论的话题。娱乐系统、互联网系统和软件更新正在推动我们在行业中开发相应的应用程序。更详细的定义在AUTOSAR中，其中自适应AUTOSAR平台pro……

des详细定义。Adaptive AUTOSAR主要对某些模块的API进行标准化，但对如何实现它们没有太多解释。作为协议栈供应商，Victor积极参与规范开发过程，我们还将与我们的汽车工厂讨论在控制器中实现应用的想法。我们可以在图的顶部看到，我们有许多应用程序，每个应用程序都有特定的算法实现，以及来自操作系统和后端本身的平台调用。这是我们的特定应用程序，你可以等效地使用它来做类似于经典AUTOSAR的SWC，但其中涉及到很多复杂性。当然，整个系统的开发需要一系列工具和协议栈协同工作，所以我们需要设计它，包括各种部署文件。我们还将根据自己的算法逻辑和相应的协议站生成代码。我们将做相应的工作，然后编译和部署它。这就是如何在内部实现相应的开发过程。每个步骤都涉及许多细节和工具来完成整个事情，首先定义它，然后进行模拟验证，当然，协议也包括在内。我们还提供相应的协议模块，可以满足我们高性能ECU平台所需的各种场景，并与各种系统具有相应的接口，以及部署和托管。同时，汽车的安全要求非常严格，包括当我们没有L3时，安全相关要求是L4级，通信协议站也是一样的。在这一领域进行相应的应用之前，也有必要达到相应的水平。对于Adaptive AUTOSAR，Vector不仅提供了协议栈，还提供了整个开发的工具链。我们将提供服务设计工具和诊断服务设计工具。在我们设计之后，我们会得到我们需要的产品，然后将它们加载到我们相应的工具中进行模拟。我们的设计理念是合理的，我们还将集成相应设计的协议栈和APP开发工具进行具体实现。实施后，我们需要进行测试和验证，这是如何进行测试和核实的下一个主题。在我们今天的主题中，我们参与了SOA系统的测试和验证，包括Adaptive AUTOSAR系统，以及如何验证整个软件系统。自适应AUTOSAR出现后，验证变得更加复杂。我们可以在这个系统中看到沃尔沃的架构、中央控制单元和软件系统。据信，并不是所有的软件都是沃尔沃自己开发的，它可能会集成到供应商设计的软件中。我们将从最初的ECU和基于总线的测试转向以APP为中心的测试。我们的功能逻辑是否符合原始定义，以及我们通信的安全性是否能够满足我们的要求等等。相应的AUTOSAR标准系统为我们提供了进行实验的标准系统。我们在服务之间有契约精神。你需要测试一个应用程序，我们需要模拟与它交互的应用程序。过去，当我们在公交车上工作时，我们还必须测试与它交互作用的ECU。因为测试有一个非常基本的定律：它是尽早建立一个完整的车辆环境，然后进行相应的测试，因为测试离实际车辆越近，它就越可靠。相应的OEM和供应商是一样的。因此，在研究SOA和相应的自适应AUTOSAR系统时，我们需要从技术角度解释一些基本概念：通信对象和绑定。通信对象已经从传统的信号发展到信号、PDU、RPC和服务。这些都是我们在图中沟通的具体载体。我们刚刚提到，我们只测试APP，APP和我们设计的相应服务之间可能会有相应的交互。同时，我们需要部署一些RPC，我们可以灵活地部署和传输这些RPC。在下面的层中，我们根据特定的协议进行捆绑，我们可以切换到一个不同的协议，该协议可以应用于Web和HTTP协议。它可能是一个简单的应用程序测试，也可能是同一协议的一部分的应用程序或模拟系统。无论行业如何发生相应的变化，我们都不会在基础测试方面做出重大改变。我们基本上需要做一些事情，比如模型测试、代码测试和控制器测试。在这里，我们将重点讨论代码的这一部分。今天，我们将不详细介绍代码本身的单元测试和集成测试。

我们指的是软件系统……

测试，这意味着在没有硬件板的情况下进行测试。无论我们在测试哪个方面，我们都需要有一个相应的模型来测试它本身及其交互，以实现相应的交互行为。然而，在测试中，我们会强调我们需要改进如何进行测试，因为我们最初的测试方法是文本+脚本，但现在我们希望采用更好的方法，通过模型和数据来推动我们的整个测试。我们到底怎么能做到这一点？模型和数据的概念是什么？我们稍后再看。当我们进行软件开发时，不可能一次开发出没有任何缺陷的产品。然而，我们仍然需要筛选出哪些回归可以进行，例如由于代码原因，在HiL平台上分析和定位100万个测试用例中的10个。修改代码后，我们如何实现代码单元测试、代码集成测试和系统测试？我们可以在工具层面解决这个问题，只要我们找到与之相关的测试，然后用相应的方式来做，而不是像原来的系统工程师那样。当然，这也涉及到不同部门之间的联系。要以软件的方式驱动定义并进行相应的测试，我们必须面对如何快速进行回归测试，这对我们内部来说也是一个巨大的挑战。当然，Vector在这方面也提供了完整的工具来解决这个问题。广泛使用的工具CANoe已经被汽车行业开发和验证，但它仍然非常重要。我们的汽车和IT软件完全不同。在我们的汽车行业开发软件后，我们需要进行一系列测试，每一步都需要进行相应的测试。在这里，我们完全可以满足这些测试。我们在一个工具系统中完成所有这些任务，例如支持MiL、SiL、HiL、DV/PV和EOL测试构建的CANoe。同时，当服务通信出现时，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顺序执行相应的100万个测试用例，这也很耗时，而且基本上不可能快速获得结果。我们有一款名为CANoe 4Server的新产品，它使用并行测试技术，并根据我们的服务器进行部署。因此，我们可以在我们的一端支持相应的系统，我们可能有一个带有相应交互对象的闭环模型，我们可以部署和验证该模型，以满足自动驾驶测试或大规模CI敏捷开发测试的要求。当CANoe4Server中的配置N足够大时，基本上可以运行al……

在几分钟内完成100万个测试用例，因此您可以快速获得相应的结果。对于ADAS，数据驱动测试是验证软件系统所必需的。因为我们有很多场景和数据要收集和生成，所以数据有两部分。其中一部分来自我们相应的模拟过程。我们生成模拟场景来做我们的模拟数据，并通过并行方法验证我们软件的可靠性。此外，我们还通过相应的设备收集数据，并将场景数据注入场景。为了验证我们的软件系统是否稳定可靠，如果我们都需要用数据进行训练，许多设备需要收集大量数据，因此我们可以部署大规模的测试系统来验证我们的相应系统。如果你不这样做，你不可能也不可能在短时间内降低L4及以上级别的成本。Vector提供了动力学和场景仿真工具DYNA4，以及实车环境数据采集设备VX1161。我们需要在获得数据后进行相应的测试。传统的测试方法包括需求和测试规范，根据文本编写相应的脚本，然后编写报告进行验证。我们现在有了一种新的方法，在传统开发中，我们根据需求进行建模，而V模型左侧的基于模型的方法是最好的设计概念，而不是手写代码。反之亦然。我们测试的输入是相同的，所以我们也可以对功能测试进行建模，因为在建模时，变量和参数配置良好，模型可以生成相应的测试用例。无论是使用状态机还是序列组合，都可以通过建模将其注入系统中进行大规模测试。建模的各个方面都可以应用，Vector提供了一个名为VTESTstudio的测试建模工具，它不仅涵盖了传统的测试方法，还支持新的测试框架和技术来帮助每个人。另一个重要的观点是，我们的方法将变得敏捷，但当您采用敏捷时，您将构建一个连续的测试环境。如果您没有自动化的测试脚本，那么您的环境就是一个空架子。因为在中国，我们经常看到追风，但你没有足够的测试力量来评估你的系统。因此，如果只根据相应的测试用例进行设计，就可以达到软件系统验证的真正效果。

标签：沃尔沃理念

汽车资讯热门资讯