新思科技杨国梁：通过Shift-Left提高汽车软件竞争力

由Gaspar、AUTOSAR和上海车展联合主办的第二届SDVF2021软件定义汽车高峰论坛暨AUTOSAR 2021中国日于4月19日至21日在上海举行。本次活动也是2021上海车展同步活动之一，也是AutoSAR在中国的唯一官方活动。本次会议上，信思科技软件质量安全部高级安全架构师杨国梁先生受邀在本次论坛上做了题为“通过Shift-Left提升汽车软件竞争力”的主题演讲。以下是他讲话的主要内容:

我们公司成立于1986年，主要业务是EDA。后来公司成立了一个叫软件质量安全的部门。我属于这个部门。我们将做软件层面、应用层面、安全和质量测试，通过将R&D工具嵌入R&D流程来提高产品质量和安全性。

在昨天的会上，我感觉大家都很清楚汽车未来的发展，以及成本在哪里。我们回想一下，在过去的一两年里，新势力厂商和传统厂商推出的新车型，在做广告的时候基本都是这两个方向，要么是车外的自动驾驶有多智能，要么是车内的体验对乘客或者司机来说有多好。我看过一些数据，保守估计三到五年内，电子电器和软件的成本可能占到汽车的50%以上。当然，昨天也听到了一些声音，说以后70%的成本都在软件上。

当然，我们这里所列举的是狭义的车载部分。如果我们把它推得更宽，合并到车联网V2X，汽车生态系统APP以及后台的各种东西，软件的范围可能会更广。

下面我们来看看如何提高软件的竞争力。我们所说的左移是什么意思？无非是软件迭代上市更快，质量更可靠，更安全。大家可以理解为两个方向。一个方向是可以先做原有的串行硬件开发，等硬件出来后再基于此进行软件开发，通过虚拟化实现软硬件同步开发。这样，你就可以计算上市时间了。芯片一出来，就做一些调试、测试、上市，大大减少了时间。从大方向来说，虚拟化可以完成整体软件开发的左移。从更小的角度来说，每一个软件，每一个软件项目迭代都需要相应的工具，将你在测试过程中可能发现的问题尽量向左移动，也就是所谓的Shift-Left。

这些术语我就不说了，因为很多厂商已经讲过功能安全/预期功能安全/信息安全等等的关系了。

从测试的角度来看，这就是所谓的左移概念。当你最终定位到问题的时候，大部分问题可能都是因为你写代码的时候粗心或者水平不够，导致代码无法很好的处理你的场景。这个直方图代表了引入主要bug的阶段。可以看出，编码和集成阶段是最多的，绿线代表不同阶段测试和查找相应bug的成本。

记得昨天有个嘉宾谈到伊藤，说汽车行业平均用人成本20万左右，软件人才有2万多。这还是一般。再看新势力，他们的开发者很大一部分来自互联网。你知道互联网人员有多贵吗？你再想想，如果让这么贵的人在软件发布后花2-3天研究一个本来可以在写代码时轻松修复的BUG，他的整体成本会大大降低。这是左移上面方法论的介绍。

2019年我们(新思科技安全研究中心)和SAE一起做了一个研究报告，叫做《汽车行业网络安全实战研究》。这里有很多数据，就不跟你说了，简单说一下。一般来说，调查问的是你的产品在哪个阶段进行质量安全检测。需求设计阶段，19%的人在这个阶段做，28%的人在R&D和测试阶段，更多的人在发布后阶段。可能SOP什么的更早。做……是在将车辆整合到道路上之后，还是在产品发布之后。当然，现在主机厂做的是在SOP阶段找厂家渗透，等等。大概市场就在这样一个阶段。

综上所述，现在评价产品发布过程中的安全问题为时已晚。如果太晚了，就会出现我刚才提到的问题。发现问题，打电话回来整改。整改成本很高。

我们来看看里面的数据。至于这些车企出现安全问题后如何改进自己的软件，我们先来看三个安全补丁管理、渗透测试和动态安全测试DAST。所以这些目前排名很靠前的手段，实际上是在发展阶段非常落后的位置上进行的。相应的静态测试，软件组成分析，安全架构分析等等，在编码阶段就可以做的，目前似乎开展的很少。你可能会说，成熟了就有OTA了。有问题可以随时推送OTA解决。但即使OTA是，本质上也是个安全补丁，在整个研发周期上还是太落后了。在同一份报告中，我们统计了37%的人在那个时候开始实施OTA。当然现在会更高，这个时候不考虑做OTA就没有竞争力了。

我们做了一些总结，大家会谈到21434。我们已经列出了在绘制21434时，在开发和安全工作的每个不同阶段需要做的事情。白色表示需要做的开发，蓝色表示安全活动，从最早的安全计划开始，然后指导安全编码，管理第三方组件，进行各种内部安全测试，甚至引入第三方渗透测试，全程实时处理安全漏洞。我们现在看到一个典型的场景，OEM接安全需求，最后做安全测试(比如渗透)，有的组织一个团队做很多TARA；现在的传统厂商更像是一个组装厂，没有源代码，但是新势力现在似乎更喜欢全栈自研，响应速度自然会更快。

我们回头看一个数据，看看车上漏洞的主要原因。更不用说项目时间紧张(71%)，可以通过虚拟化shift-left等方式缓解；再往下，60%和55%的人缺乏对安全编码实践和意外编码错误的理解。再往下是测试阶段，占不安全或过时的开源软件组件的40%。我们来看看这些问题的类型。编码有什么问题？

这里我们谈谈汽车行业常见的编码规范。MISRA，AutoSAR，26262大家都比较熟悉，其他的如CERT，MISRA，AutoSAR都有大量来自CERT的规则，里面有上百条规则。手工检查肯定不现实，其他规格也差不多。正如您从上面的介绍中所看到的，支持以下规范。当汽车的智能化程度进一步提高，车联网和人机交互更多的时候，这里列举的其他编码规范，比如OWASP等其他行业常见的，在汽车行业也会越来越多的被参考。

汽车行业也有特殊情况。对于ECU等嵌入式系统的开发，不同的厂商会有不同的开发版本和编译器。对于白盒代码工具来说，如果不能准确识别编译过程，检查起来会非常困难。比如，某个类型在你的系统中存在于16位或者32位。没有编译过程的抓拍，很可能你不知道这个，白盒检查的结果其实更鸡肋。Coverity是目前业界最好的支持嵌入式开发环境的白盒工具，适用于各类编译器，具有业界最好的误报率控制。

说到白盒工具的最佳实践，我们可以看看这个典型的开发过程，从编写代码到提交、编译、计时检查和发布。在这种情况下，我们可以在哪里进行白盒测试？在IDE端，我们可以先截一些检查规则，在编写代码的时候同时检查速度和准确性都比较高的规则，避免出现问题，把检查本身的耗时控制在第二级。其次，在提交代码时，可以通过工具配置查看企业自身的10大问题，比如命令注入、关键的硬编码等。，而检查本身需要2-3分钟；项目构建时，涉及到跨文件/跨功能/数据流的分析。虽然时间更长，但是分析深度会更深，时间会控制在十到几十分钟。最后，在发布前做一个详细的检查，所以会花更长的时间，每小时或者晚上。所以这些都是权衡的，在什么阶段，你的使用习惯，你能在多大程度上接受检查和干预，在不同的岗位要做不同的调整，以适应这些白盒工具的整合。

事实上，中国一家新的电源制造商几年前就开始这样做了。当时的做法是在最终发布阶段做一些测试，这两年逐渐挪到了建设检验的位置，在每个版本搭建的时候做相应的测试。只是当时强制程度还比较低，提供了这样的检测服务，但并没有强制你使用。但是现在新势力厂商的智能驾驶舱代码非常庞大，一个完整的Android本身的编译可能需要一天的时间。然后进一步推，推至每一个开发，每一个模块，你会实时得到相应的结果来检查，进一步左移。以上是静态工具。当然工具也有各种报表，比如MISRA，HIS度量，质量，安全等等。

我刚看到40%的问题都是使用不安全或者过时的组件，这里指的是常见的开源组件。你的开发过程加速后肯定是有一些前提条件的，可以肯定的是复用大量现成开源组件的效率是可以提高的。我们新思科技每年都会发布开源风险审计报告，显示各行各业使用了多少开源组件，面临哪些风险，趋势如何。这是今年刚刚发布的。经审查，汽车行业所有代码中，有70%是由开源组成的。如果加上智能驾驶舱，可能会更高，甚至后端的TSP和APP参考其他行业也能知道，这里就不解释了。

比如你的车上市后，你用的是curl7.58组件。如果明年它发现了一个严重的安全漏洞，这个时候，如果你有自己的ALM，PLM系统可以追溯到这些组件的哪些软件版本被使用过，这些软件版本的哪些部分被使用过，这些组件的哪些型号被使用过，这样就可以知道一个完整的攻击范围，这样你就可以精准的推送你的软件补丁。

另外，21434中规定需要Fuzz(模糊测试)。我们列出了车辆中需要模糊测试的各种协议和接口。目前，典型的做法是，OEM在最后阶段进行模糊测试；然而，根据左移法，Fuzz也需要调整和适应开发过程的早期阶段。

除了上面提到的各种测试方法，在练习21434的过程中还需要做更多的安全测试。然而，所有的测试类型都有自己的左移方法和实践。

综上所述，我们刚刚讲了现阶段在V模型上做这个开发需要考虑哪些安全活动和流程。现在我们来看看21434的安全活动流程图，其实是一个圆。对于右下角的尾部报废，仔细想想该型号是否已经退市。除非不维护软件，否则很有可能上一个模型的软件版本会迭代应用到下一个模型，所以是一个迭代的过程。

我们刚刚谈到的一些实践实际上属于DevSecOps的范畴。当我们把三者放在一起看的时候，我们会怀疑21434模型是否只是V型模型向DevSecOps过渡的中间产物。未来一定是一个快速迭代、快速进化的过程。

我在这发现了一个病例。这是美国国防部使用的DevSecOps方法，kubernetes部署在F16上。开发周期从3-8个月缩短到一周，37个项目的总开发时间节省了100多年。这是重型武器，应该比汽车开发慢很多，但是DevSecOps可以开发。

综上所述，从软件架构的角度来看，我们每个开发周期需要用到的所有工具，一般都是基于开源组件的，开源组件编写一些特殊的代码，为业务需求搭建一个框架，在上面运行你的业务逻辑，通过WebUI或者API等服务接口对外提供服务。不同阶段用什么测试方法？我们有能力在代码开发过程中检查和修复安全漏洞和质量问题。BlackDuck软件组件分析，检测和管理开源和第三方组件风险。探索者，交互式安全测试，在QA的同时自动完成安全测试。防御性和锡箔，模糊测试和动态安全测试。

到目前为止，实际上是质量/安全测试工具和方法可能在每个具体项目中使用。通过虚拟化同时开发软件和硬件怎么样？简单告诉你，这种V型模式可以自下而上理解为从半导体厂商到Tier1，再到OEM的一系列基于芯片的发展。由Gaspar、AUTOSAR和上海车展联合主办的第二届SDVF2021软件定义汽车高峰论坛暨AUTOSAR 2021中国日于4月19日至21日在上海举行。本次活动也是2021上海车展同步活动之一，也是AutoSAR在中国的唯一官方活动。本次会议上，信思科技软件质量安全部高级安全架构师杨国梁先生受邀在本次论坛上做了题为“通过Shift-Left提升汽车软件竞争力”的主题演讲。以下是他讲话的主要内容:

我们公司成立于1986年，主要业务是EDA。后来公司成立了一个叫软件质量安全的部门。我属于这个部门。我们将做软件层面、应用层面、安全和质量测试，通过将R&D工具嵌入R&D流程来提高产品质量和安全性。

在昨天的会上，我感觉大家都很清楚汽车未来的发展，以及成本在哪里。我们回想一下，在过去的一两年里，新势力厂商和传统厂商推出的新车型，在做广告的时候基本都是这两个方向，要么是车外的自动驾驶有多智能，要么是车内的体验对乘客或者司机来说有多好。我看过一些数据，保守估计三到五年内，电子电器和软件的成本可能占到汽车的50%以上。当然，昨天也听到了一些声音，说以后70%的成本都在软件上。

当然，我们这里所列举的是狭义的车载部分。如果我们把它推得更宽，合并到车联网V2X，汽车生态系统APP以及后台的各种东西，软件的范围可能会更广。

下面我们来看看如何提高软件的竞争力。我们的b是什么意思……向左移位？无非是软件迭代上市更快，质量更可靠，更安全。大家可以理解为两个方向。一个方向是可以先做原有的串行硬件开发，等硬件出来后再基于此进行软件开发，通过虚拟化实现软硬件同步开发。这样，你就可以计算上市时间了。芯片一出来，就做一些调试、测试、上市，大大减少了时间。从大方向来说，虚拟化可以完成整体软件开发的左移。从更小的角度来说，每一个软件，每一个软件项目迭代都需要相应的工具，将你在测试过程中可能发现的问题尽量向左移动，也就是所谓的Shift-Left。

这些术语我就不说了，因为很多厂商已经讲过功能安全/预期功能安全/信息安全等等的关系了。

从测试的角度来看，这就是所谓的左移概念。当你最终定位到问题的时候，大部分问题可能都是因为你写代码的时候粗心或者水平不够，导致代码无法很好的处理你的场景。这个直方图代表了引入主要bug的阶段。可以看出，编码和集成阶段是最多的，绿线代表不同阶段测试和查找相应bug的成本。

记得昨天有个嘉宾谈到伊藤，说汽车行业平均用人成本20万左右，软件人才有2万多。这还是一般。再看新势力，他们的开发者很大一部分来自互联网。你知道互联网人员有多贵吗？你再想想，如果让这么贵的人在软件发布后花2-3天研究一个本来可以在写代码时轻松修复的BUG，他的整体成本会大大降低。这是左移上面方法论的介绍。

2019年我们(新思科技安全研究中心)和SAE一起做了一个研究报告，叫做《汽车行业网络安全实战研究》。这里有很多数据，就不跟你说了，简单说一下。一般来说，调查问的是你的产品在哪个阶段进行质量安全检测。需求设计阶段，19%的人在这个阶段做，28%的人在R&D和测试阶段，更多的人在发布后阶段。可能SOP什么的更早。并且在将车辆集成到道路上之后或者在产品发布之后这样做。当然，现在主机厂做的是在SOP阶段找厂家渗透，等等。大概市场就在这样一个阶段。

综上所述，现在评价产品发布过程中的安全问题为时已晚。如果太晚了，就会出现我刚才提到的问题。发现问题，打电话回来整改。整改成本很高。

我们来看看里面的数据。至于这些车企出现安全问题后如何改进自己的软件，我们先来看三个安全补丁管理、渗透测试和动态安全测试DAST。所以这些目前排名很靠前的手段，实际上是在发展阶段非常落后的位置上进行的。相应的静态测试，软件组成分析，安全架构分析等等，在编码阶段就可以做的，目前似乎开展的很少。你可能会说，成熟了就有OTA了。有问题可以随时推送OTA解决。但即使OTA是，本质上也是个安全补丁，在整个研发周期上还是太落后了。在同一份报告中，我们统计了37%的人在那个时候开始实施OTA。当然现在会更高，这个时候不考虑做OTA就没有竞争力了。

我们做了一些总结，大家会谈到21434。我们已经列出了在绘制21434时，在开发和安全工作的每个不同阶段需要做的事情。白色表示需要做的开发，蓝色表示安全活动，从最早的安全计划开始，然后指导安全编码，管理第三方组件，进行各种内部安全测试，甚至引入第三方渗透测试，全程实时处理安全漏洞。我们现在看到了一个典型的场景，其中原始设备制造商提出了安全要求……并且在最后做安全测试(比如渗透)，有的组织团队做很多TARA；现在的传统厂商更像是一个组装厂，没有源代码，但是新势力现在似乎更喜欢全栈自研，响应速度自然会更快。

我们回头看一个数据，看看车上漏洞的主要原因。更不用说项目时间紧张(71%)，可以通过虚拟化shift-left等方式缓解；再往下，60%和55%的人缺乏对安全编码实践和意外编码错误的理解。再往下是测试阶段，占不安全或过时的开源软件组件的40%。我们来看看这些问题的类型。编码有什么问题？

这里我们谈谈汽车行业常见的编码规范。MISRA，AutoSAR，26262大家都比较熟悉，其他的如CERT，MISRA，AutoSAR都有大量来自CERT的规则，里面有上百条规则。手工检查肯定不现实，其他规格也差不多。正如您从上面的介绍中所看到的，支持以下规范。当汽车的智能化程度进一步提高，车联网和人机交互更多的时候，这里列举的其他编码规范，比如OWASP等其他行业常见的，在汽车行业也会越来越多的被参考。

汽车行业也有特殊情况。对于ECU等嵌入式系统的开发，不同的厂商会有不同的开发版本和编译器。对于白盒代码工具来说，如果不能准确识别编译过程，检查起来会非常困难。比如，某个类型在你的系统中存在于16位或者32位。没有编译过程的抓拍，很可能你不知道这个，白盒检查的结果其实更鸡肋。Coverity是目前业界最好的支持嵌入式开发环境的白盒工具，适用于各类编译器，具有业界最好的误报率控制。

说到白盒工具的最佳实践，我们可以看看这个典型的开发过程，从编写代码到提交、编译、计时检查和发布。在这种情况下，我们可以在哪里进行白盒测试？在IDE端，我们可以先截一些检查规则，在编写代码的时候同时检查速度和准确性都比较高的规则，避免出现问题，把检查本身的耗时控制在第二级。其次，在提交代码时，可以通过工具配置查看企业自身的10大问题，比如命令注入、关键的硬编码等。，而检查本身需要2-3分钟；项目构建时，涉及到跨文件/跨功能/数据流的分析。虽然时间更长，但是分析深度会更深，时间会控制在十到几十分钟。最后，在发布前做一个详细的检查，所以会花更长的时间，每小时或者晚上。所以这些都是权衡的，在什么阶段，你的使用习惯，你能在多大程度上接受检查和干预，在不同的岗位要做不同的调整，以适应这些白盒工具的整合。

事实上，中国一家新的电源制造商几年前就开始这样做了。当时的做法是在最终发布阶段做一些测试，这两年逐渐挪到了建设检验的位置，在每个版本搭建的时候做相应的测试。只是当时强制程度还比较低，提供了这样的检测服务，但并没有强制你使用。但是现在新势力厂商的智能驾驶舱代码非常庞大，一个完整的Android本身的编译可能需要一天的时间。然后进一步推，推至每一个开发，每一个模块，你会实时得到相应的结果来检查，进一步左移。以上是静态工具。当然工具也有各种报表，比如MISRA，HIS度量，质量，安全等等。

我刚看到40%的问题都是使用不安全或者过时的组件，这里指的是常见的开源组件。你的开发过程加速后肯定是有一些前提条件的，可以肯定的是复用大量现成开源组件的效率是可以提高的。我们新思科技每年都会发布开源风险审计报告，显示各行各业使用了多少开源组件，面临哪些风险，趋势如何。这是今年刚刚发布的。经审查，汽车行业所有代码中，有70%是由开源组成的。如果加上智能驾驶舱，可能会更高，甚至后端的TSP和APP参考其他行业也能知道，这里就不解释了。

比如你的车上市后，你用的是curl7.58组件。如果明年它发现了一个严重的安全漏洞，这个时候，如果你有自己的ALM，PLM系统可以追溯到这些组件的哪些软件版本被使用过，这些软件版本的哪些部分被使用过，这些组件的哪些型号被使用过，这样就可以知道一个完整的攻击范围，这样你就可以精准的推送你的软件补丁。

另外，21434中规定需要Fuzz(模糊测试)。我们列出了车辆中需要模糊测试的各种协议和接口。目前，典型的做法是，OEM在最后阶段进行模糊测试；然而，根据左移法，Fuzz也需要调整和适应开发过程的早期阶段。

除了上面提到的各种测试方法，在练习21434的过程中还需要做更多的安全测试。然而，所有的测试类型都有自己的左移方法和实践。

综上所述，我们刚刚讲了现阶段在V模型上做这个开发需要考虑哪些安全活动和流程。现在我们来看看21434的安全活动流程图，其实是一个圆。对于右下角的尾部报废，仔细想想该型号是否已经退市。除非不维护软件，否则很有可能上一个模型的软件版本会迭代应用到下一个模型，所以是一个迭代的过程。

我们刚刚谈到的一些实践实际上属于DevSecOps的范畴。当我们把三者放在一起看的时候，我们会怀疑21434模型是否只是V型模型向DevSecOps过渡的中间产物。未来一定是一个快速迭代、快速进化的过程。

我在这发现了一个病例。这是美国国防部使用的DevSecOps方法，kubernetes部署在F16上。开发周期从3-8个月缩短到一周，37个项目的总开发时间节省了100多年。这是重型武器，应该比汽车开发慢很多，但是DevSecOps可以开发。

综上所述，从软件架构的角度来看，我们每个开发周期需要用到的所有工具，一般都是基于开源组件的，开源组件编写一些特殊的代码，为业务需求搭建一个框架，在上面运行你的业务逻辑，通过WebUI或者API等服务接口对外提供服务。不同阶段用什么测试方法？我们有能力在代码开发过程中检查和修复安全漏洞和质量问题。BlackDuck软件组件分析，检测和管理开源和第三方组件风险。探索者，交互式安全测试，在QA的同时自动完成安全测试。防御性和锡箔，模糊测试和动态安全测试。

到目前为止，实际上是质量/安全测试工具和方法可能在每个具体项目中使用。通过虚拟化同时开发软件和硬件怎么样？简单告诉你，这种V型模式可以自下而上理解为从半导体厂商到Tier1，再到OEM的一系列基于芯片的发展。其实我们可以和半导体芯片厂商合作，通过虚拟化把芯片规格交付给Tier1，然后Tier1基于VDK开发ECU，再交付给OEM，OEM第一时间开始做各种应用层的工作。对于Sil和pil阶段，我们还有ECU虚拟化工具Silver。众所周知，SiL和PiL中的代码和HiL中的代码还是有区别的，区别在一定程度上意味着风险。VDK可以以vHiL的形式填补空缺，解决HiL的时间和资源短缺问题。运行在vHiL上的代码非常接近真实的HiL环境。

VDK可以模拟芯片中的各种接口，并且可以模拟到任何层。虽然性能相比真实芯片环境会有一些损失，但是对于功能测试来说已经足够了。

从汽车软硬件层次来看，可以从上面的SW阶段用SILVER工具模拟，然后在直接处理硬件的阶段用VDK完全虚拟化，然后Saber是另一个物理层信号的虚拟化工具。这些工具可以与汽车行业中使用的其他常用工具进行联合仿真。

这里有一个案例。英飞凌将于2023年推出其下一代自动驾驶芯片AURIX 3G MCU系列。然而，这种芯片规格已被VDK虚拟化，并给予第1层。Tier1以此为基础设计了软件，交给了一家国际知名的OEM厂商。现在主机厂正在以此为基础整合整体方案。这样做，它的好处很容易理解。不用等芯片出来再开发软件部分，已经提前把整个周期Shift-Left到2-left了。

最后总结一下，这就是软件安全层面。我们这个事业部一直比较低调，但是已经连续三年在Gartner排名中处于领先地位。如果你是……感兴趣的，可以跟进。这里还有我的微信和我们业务部门的二维码。你可以扫描并添加它们。有兴趣的可以去外面的展台进一步交流。其实我们可以和半导体芯片厂商合作，通过虚拟化把芯片规格交付给Tier1，然后Tier1基于VDK开发ECU，再交付给OEM，OEM第一时间开始做各种应用层的工作。对于Sil和pil阶段，我们还有ECU虚拟化工具Silver。众所周知，SiL和PiL中的代码和HiL中的代码还是有区别的，区别在一定程度上意味着风险。VDK可以以vHiL的形式填补空缺，解决HiL的时间和资源短缺问题。运行在vHiL上的代码非常接近真实的HiL环境。

VDK可以模拟芯片中的各种接口，并且可以模拟到任何层。虽然性能相比真实芯片环境会有一些损失，但是对于功能测试来说已经足够了。

从汽车软硬件层次来看，可以从上面的SW阶段用SILVER工具模拟，然后在直接处理硬件的阶段用VDK完全虚拟化，然后Saber是另一个物理层信号的虚拟化工具。这些工具可以与汽车行业中使用的其他常用工具进行联合仿真。

这里有一个案例。英飞凌将于2023年推出其下一代自动驾驶芯片AURIX 3G MCU系列。然而，这种芯片规格已被VDK虚拟化，并给予第1层。Tier1以此为基础设计了软件，交给了一家国际知名的OEM厂商。现在主机厂正在以此为基础整合整体方案。这样做，它的好处很容易理解。不用等芯片出来再开发软件部分，已经提前把整个周期Shift-Left到2-left了。

最后总结一下，这就是软件安全层面。我们这个事业部一直比较低调，但是已经连续三年在Gartner排名中处于领先地位。有兴趣可以跟进。这里还有我的微信和我们业务部门的二维码。你可以扫描并添加它们。有兴趣的可以去外面的展台进一步交流。

标签：发现理念

汽车资讯热门资讯