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

7月22日23日，盖世汽车主办、上海国际汽车城特别支援的第一届软件定义汽车峰会论坛正式召开。 这次论坛首先探讨软件定义汽车行业的最新创新理念、技术趋势、现实挑战等热点话题，探索领域未来的快速发展道路。 以下是维克多汽车技术(上海)有限企业分散系统和互联网部门商业开发经理范可发在这次论坛上的发言。

维克多汽车技术(上海)有限企业分布式系统和互联网部门的商业开发经理范科发

大家好！ 首先，我总是感谢你给我留下额外的时间。 我担心这种材料比时间长，所以我们今天谈了很多趋势，实际上我们会执行一点事件。 我相信参加的有很多开发工程师。 那个软件产品需要设计和实现所以这边应景。 介绍资料的背景直接拿着软件成为了我演讲的开头。

我们先来看看怎么设计，怎么落地，确保质量。 是软件的一部分。 我们看到，不仅是汽车，以软件为中心，在所有领域基本上软件的价值都越来越高，我们对自动驾驶的车辆、软件的应对越来越多。

汽车领域与软件相关，基本上oem的差异化是传感器级，另一个主要区别是应用级。 中间的bsp中含有一点os，因为有标准化的东西，所以我们采用了直接采购整合。 另一个趋势是软件的开发和设计越来越受oem控制，软件不一定全部由oem进行，但更多软件掌握的话语权是我们沃尔沃同事说的这个部分 我方应对供应商和oem如何紧密合作。 我们的应对有持续的整合、持续的测试。 你会发现很多车型的功能发布和车型发布是独立的。

这是一个大趋势，我们上午孟超总也提到soa对未来来说是给予能量的人，soa的这项技术本身是我们未来一点互联、自动驾驶、软件更新的最基本前提，我们使用这样的技术

所以我们认为软件非常重要，在整个开发过程中有oem和供应商的合作和相应的实现，逐一看看。 维克多作为供给制造商是怎么做这些的，因为具体的东西都要落地了。

让我们先看看服务。 我相信这里的很多工程师有时会在dbc上收发一点信号。 那什么是服务？ 服务的职业是什么？ 包括我们有通信在内，用什么方法实现通信的应用呢？ 站在oem的立场上我们定义各种服务。 孟总上午将各传感器和信号ip化，进行相应的编码，根据我们的需要进行相应的调用。 我们相应地升级了我们车里的相应功能，满足了我们相应的应用程序，soa确保了我们车和外部的互联部分相连。 另外，还出现了沃尔沃描述的高性能中央控制节点。

在这张图中，你可以看到有为我们的服务提供服务的服务和招聘者。 有兴趣的是我们的服务可以放在后台。 这是一个非常感兴趣的应用程序，在云中实现适当的控制应用程序，但在其中谈论soa和开发时，非常致命的一点是security。 这对供应商来说是非常严重的挑战，oem比较简单。 他们是固定的系统，但今天不展开security这个话题，回到soa的主线本身。

我们以前传达了所有这些车辆的设计。 我们基本上在设计时定义数据库，哪个ecu发出这些信号是固定的，执行时按照预想的设定方法进行适当的运行。 我们在设计时在系统之间进行静态通信，开发一般用c语言进行开发。 在这张图中有合适的通信应用程序，但服务还是用于我们的软件构筑和ecu。 我们在设计时设计了一部分，但在执行时其他部分也占有相应的资源进行计算。 我们执行时会出现对应的功能。 所以，总体上用动态的方法解决。 这个时候，我们用c-+进行这个事件。 使用adaptive autosar实现服务基础。

这是一个简单的对象。 相对最重要的是，我们的服务方向是动态的，这边越来越动态地执行，进行适当的实现。 所以，这里服务是怎么做这件事的，什么是service？ 我们构建对应的不同软件或ecu之间的通信我们提供的服务包括根据服务的接口和做法。 这里工程师很多，所以我们经常谈技术。

然后，我们通过定义的service和具体的ecu实现服务部署的应用。 我们设计的服务非常灵活，基于我们的架构设计和应用部署的对应平台，服务这些都通过序列化和反序列化实现基础通信，我们支持中间件的协议，但背景 我们再证明一点。 不是所有的服务都通过以太网，can fd这是基于autosar 4.2中定义的动态pdu，因此动态pdu也可以实现服务通信。 另外，现有供应商有示例说明。 而且，相应的can新一代总线技术can xl也支持基于服务的通信。 这是明年或第二年发布的新技术。 也就是说，车并不是都用以太网，价格太高的话肯定会用混合动力巴士系统在车里。 但是，我们的大基调是服务，以前传达的部分也需要服务来满足我们应用水平的诉求。

我们通过中间件实现具体服务的职业生涯。 我们在这里定义我们的服务定义。 我们也定义软件和硬件。 我们把service配置在对应的硬件上，设定我们的相对硬件信号路径这边我们根据实际车辆的状况设计这样的服务文件，作为我们以后的开发业务使用，所以这里是对应的风格

另外，我们在这里定义相应的服务的同时，包括服务的实力化，例如服务的接口、配置、一点状态机的设计，这些在不同的层次上有相应的文件导出，在我们以后的服务配置和设计的实现上 这是我们说的服务可以定义和实现的。 维克多是工具供应商。 我们提供了preevision工具，支持adaptive数据库和以太网数据库的定义。 当然，开发和创建以前传递的总线数据库是满足功能模拟、开发实现和测试验证服务功能的基本条件。

我们必须将服务应用于具体的通信运营商和中间件进行设计。 然后，我们可以做后续工作。 我们实际进行。 设计后，模拟并验证我们设计的副本是否如我们所期待的那样定义。 模拟后，开发实现车与外部互联后，以往it的很多知识系统和协议等被引用到车中，通过互联实现，因此可以看到整个领域。

另一辆我们的车本身很重视安全。 我们的领域有非常强的技术壁垒。 例如，诊断汽车和贯穿整个工具链。 我们连接上下两端。 我们制作汽车的高性能计算控制器时，以前传达的适当的工具链和我们以前传达的在汽车领域应用的方法有激烈的冲突。 但是，其中我还强调了功能安全和新闻安全。 这个一定逃不掉。 我们的驾驶必须保证可靠性。 所以，我们在设计时也必须考虑实现安全和可靠性的方法。

另外，这是大家上午说的娱乐系统、互联网系统、软件的更新，这些大方向比我们在领域进行相应的应用更具体的定义是在autosar中 adaptive autosar首先对应一点模块的api进行了规范，具体如何实现还没有多少证明。 维克多作为协议栈的供应商，积极参与规范制定的过程，我们也与我们的车厂讨论想法，使应用程序落地于控制器上。 可以看到图的最上面。 我们有很多app。 每个app都有具体的算法。 还有操作系统和后台本身的平台呼叫。 这是我们的具体app。 你可以把它等价成经典的Autosar SWC当然整个系统的开发需要一系列工具和协议栈。 所以，我们需要设计。 我们有各种部署文件。 我们也把自己做的算法逻辑和相应的协议站和代码结合起来，我们做相应的工作。 然后我们再次编译和部署，提供适当的协议模块以满足高性能ecu平台的需要，并提供与各种系统的对接，以及适当的部署和载体。 另外，关于汽车安全的研究非常严格，包括我们不做l3的时候，与安全相关的东西要求是l4等级。 通信协议站也一样，必须达到相应的等级。

与adaptive autosar相比，vector提供了协议栈。 我们还提供了整个开发的工具链。 我们提供服务设计工具和诊断服务的设计工具，我们设计后得到需要的东西，装载到我们对应的工具中进行模拟。 我们把这个设计理念合理化，我们。

测试验证我们在soa系统中包括adaptive autosar系统，包括今天主题的整个软件系统是如何验证的。 adaptive autosar问世后，可以看到沃尔沃的体系结构，验证多，混合。 中央控制单元。 这个软件系统相信并不是所有的软件都是沃尔沃自己开发的。 供应商自己设计的软件可能集成了相应的autosar标准系统为我们提供了做实验的标准系统，我们在服务和服务之间有合同精神。 你必须测量app，模拟与其相互作用的app。 以前我们做公共汽车的时候，在和ecu相互作用的综合下也进行测试。 因为测试有基本法则。 尽快建立整车环境，做相应的测试。 离实车越近，测试可能越可靠。 对应oem和供应商是一样的。

那么，从技术层面证明。 制作soa和对应的adaptive autosar系统时，证明一点基本概念。 communication object和binding。 通信object从以前传来的信号进化为信号、pdu、rpc、service。 这些是我们通信的具体载体。 我们也说过，我们单纯地测量app，app和app之间可能有相应的相互作用。 而且我们设计的相应服务是部署rpc，我们可以非常灵活地进行部署和传输。 下一层根据具体协议捆绑。 我们。

不管在这个领域如何发生相应的一些变化，基本测试对我们都没有大的变化。 基本上进行模型测试、代码测试和控制器测试等。 这里证明代码的这个部分。 今天不讨论代码本身的单元测试和集成测试。 我们提出软件系统的测试。 如果没有硬件板，请进行测试。 无论测量哪个，我们都有测试本身和它相互作用的模型。 但是，测试方面强调要点。 我们会改进测试。 我们原来的测试是复制+脚本的方法，但现在我想用更好的方法。

那么到底怎么做这件事呢？ 模型和数据是什么概念？ 看起来在我们后面。 我们在开发软件的时候，相应的我们宣传的产品一次也不能开发，但是在执行了hil台架的100万个测试用例后，10个被定位为由于代码的原因而发生的。 修改代码后，如何进行代码单元测试、代码集成测试和系统测试？ 它只是找到与其相关的测试，然后用相应的方法进行，不是像原来的系统工程师那样操作，而是在工具层面我们可以处理这个问题。 当然，这也包括不同部门之间的联系问题。 用软件的方法驱动定义，进行相应的测试。当然vector提供了处理这个问题的完美工具。

在汽车领域广泛采用的工具敞篷已经开发验证，但依然很重要。 我们的汽车和it软件完全不同。 在我们的汽车领域开发软件后进行一系列测试。 每个环节都进行相应的测试。 在这里我们可以完全满足这些测试。 例如，canoe支持构建mil、sil、hil、dv/pv和eol测试。 另外，出现服务通信后，以app测试为中心，canoe方面通过近年来的积累和顾客的合作，重构了刚才所述的软件系统和用于应对soa测试问题的软件系统，搭载适当的中间件协议，进行分析 这也叫sil，这是和以前流传的sil不同的概念。 以前传达的sil测试是背靠背测试，经常没有实际落地实施。 你原来的型号和代码不能自己开发，但我们现在是软件系统。 我们用一点手段将算法代码虚拟化为dll，向oem提供虚拟软件。 oem可以非常早期继续构建子系统和整车。 所有模块都以虚拟化的方式提供。 作为供应商每天开发的。 供应商每天设计的部分可以在继续编译之后交给oem。 oem可以进行测试。 在我们后面有实际样本之前与硬件无关地回归。 相关的事情会增加相应的测试。

canoe4sw是vector今年发布的canoe系统的产品。 能处理哪个软件，图中嵌入式系统的软件是canoe4sw的应用场景，在pc端、虚拟机端或云端部署软件。 我们将对应的工具canoe4sw用于软件系统的功能测试，将对应的软件分为app侧和功能接口侧，功能接口侧将实际的ecu和api映射到虚拟环境下对应的api变量，部署环境 这边也是一样的事情。 我们可以用对应的技术做这件事。 这是敏捷迅速迭代的基本保障。

这里可以在canoe上做这样的功能，但是对应的100万个测试用例按pc顺序运行的话很花时间，几乎不能马上得到结果。 这边的构建技术有新的产品canoe4server，使用并行测试技术在我们的服务器上进行适当的部署，我们就可以在对应的系统上支持。 包括我们可能与对应的交互对手有闭环的模型，我们可以实现配置和验证，满足自动驾驶的测试，或者满足企业真正大规模进行ci敏捷开发测试的方式的诉求

与adas相比，必须根据数据驱动的测试来验证软件系统。 因为我们收集和生成非常多的场景和数据，所以数据有两个部分。 部分来自我们相应的模拟环节，我们生成模拟场景制作我们的模拟数据，用并行的方法验证我们的软件是否可靠。 如果我们都需要用数据训练的话，那很多数据需要很多设备收集。 那样我们就可以引进大规模的测试系统来验证我们对应的系统。 否则，以l4以上的价格，你不能在短时间内降低价值成本。 vector提供动力学和场景模拟工具dyna4，同时还提供实车环境数据收集设备vx1161。

我们必须得到数据进行相应的测试。 测试以前传达的做法有诉讼和测试规范，按照复印件写相应的脚本，然后写报告进行验证。 我们现在有了新的方法。 我们以前开发的时候根据诉求建模。 在v模型的左边基于模型的方法不是手写代码，而是最好的设计理念。 相反，我们测试的输入也一样。 我们也可以对功能测试进行建模。 你建模时会放置变量和参数，模型也可以生成对应的测试用例。 无论是带状态机还是序列组合，都可以用建模的方法对系统进行大规模测试。 建模的各个方面都可以应用。

另一个重要的地方是我们的做法会变成敏捷的做法。 但是，当你很敏捷，创造了你持续测试的环境时，如果没有自动化的测试脚本，你乘坐的环境就是空架子。 在中国经常可以看到追风，但你没有足够的测试能力来评价你的系统，所以只有按照合适的测试用例设计才能验证真正的效果软件系统。