特斯拉召回超43万辆电动车，我们如何避免软件问题的召回？
新闻报告
昨天，新闻报告了特斯拉召回事件，新闻中，指出指出了召回的原因：
新闻链接：
特斯拉召回超43万辆电动车，涉两款车型！
问题发生的原因
现代汽车上的软件越来越多，也越来越复杂，甚至有软件定义汽车的说法，有统计数据显示，一辆电动汽车的代码量高达上亿行。软件如何吞噬汽车一文就说到，汽车的电气化和自动化是代码量增加的主要推手，而软件的成本占比也越来越高。
How Software Is Eating the Car (ieee.org)
那么，面对如此庞大和复杂的汽车软件，如何保证的正确和可靠是汽车安全的重要部分。
保证正确，一般用动态测试的方法来验证。
但是我们都是知道，动态测试始终是有限的，只能说明该测试用例没有测出问题。我相信该汽车的代码肯定是经过充分测试的，但是，最基础的初始化问题仍然存在，说明验证正确是最基础的，他并不能说明代码中没有问题。计算机先驱Edsger Dijkstra也说过这样的话。
如何避免这类问题
初始化的问题虽然基础，但是涉及的东西还是比较多的。不同数据类型，初始化的方式，直接赋值，memset/memcpy等，再加上在不同的分支的初始化等，问题就复杂起来了。
Polyspace bug finder能够帮助你检查是不是在所有分支都对变量进行初始化了，memset/memcpy初始化的时，目标和源的字节数是不是不会出现问题。
比如下面的例子，value在没有进入if分支的情况下，就只有声明，没有初始化。
Polyspace bug finder提供了自动化了自动化的检查，并提供了准确的问题位置、详细的问题说明，风险和甚至修复的建议，还有问题发生的路径。帮助你定位问题根本原因。
另一个例子，strcpy的源是20个字符，而目标是5个字符，明显会内存拷贝导致的溢出。
在实际项目中当然比较复杂，polyspace也能够给出更详细的数据，帮助定位问题。
Polyspace Bug Finder除了这些基本的检查，还能够做更多的问题检查，诸如数据溢出、除零、内存泄漏、多线程中的死锁，重复锁等并发问题。Polyspace Bug Finder提供12大类，350多种问题的检查。
如何进一步保证软件质量
动态测试不能说明没有问题，那么有没有什么手段可以做到说明没有问题呢？
Polyspace Code Prover提供这样功能，其使用基于抽象解释的方法，证明代码中不存在严重的运行时错误。运行时错误是代码中隐藏极深，非常不容易出现，甚至不容易复现的问题。这类问题一旦发生，会直接导致软件系统的崩溃。
下图是我们不时地在windows机器上看，出现了后我们只能重启软件或计算机。笔记本重启对我们不会造成多大的危害，而汽车的软件在汽车行驶的过程中，是不允许重启的。这就必须保证汽车软件中没有这类问题。
所谓的抽象解释法，就是使用数学推理的方法，证明代码中没有代码运行时错误。下图就是对一段简单的代码，针对变量x范围进行推理的过程。
通过这样的方法，可以证明你的代码没有运行时错误，从而避免因为软件问题导致的车辆缺陷，避免这方面的召回。
下图所示，展示了20行处，没有除零的问题，并详细显示了除数的范围。
一些资料
现在，很多的OEM和供应商越来越重视软件问题，开始使用相关的静态代码分析工具，比如Polyspace来避免问题，保证可靠。
以安全著称的沃尔沃汽车已经对其车载的代码全面使用Polyspace进行检查分析。您可以参考MATLAB官网了解详情。
沃尔沃汽车软件工厂使用 Polyspace 提高开发速度和质量
更多关于polyspace的详细介绍，大家可以移步B站，MATLAB中国有一个系列视频详细介绍该产品。
破解嵌入式软件质量难题: C/C++代码静态分析技术
破解嵌入式软件质量难题: 查找软件缺陷度量软件质量
破解嵌入式软件质量难题: 消除缺陷证明无运行时错误