【CSDN 编者按】在嵌入式环境中，C、C++作为最常见的编程语言，早已被广泛应用在底层工具链、库中。不过，近日嵌入式工程师Omar Hiari提出一种完全不同的看法，他认为一开始就考虑安全问题的编程语言Rust才是嵌入式领域的未来。虽然要将嵌入式应用程序代码迁移到一种新的编程语言上非常麻烦，但他认为这是可行的，只是需要一些方法和实践。
原文链接：https://apollolabsblog.hashnode.dev/why-you-should-be-worried-about-the-future-of-cc-in-embedded-a-case-for-rust
以下是译文：
软件故障在嵌入式领域时常发生，随着物联 （IoT）和 络物理系统（CPS）等技术的普及，这些故障也没有得到应有的重视。当人们谈论自动驾驶汽车、机器人、无人机时，他们总认为这些出错的机率很小。但在了解一些历史上著名的软件事故、Bug案例研究后，你就不会这么想了。
重现问题简直是一场噩梦
首先，需要声明的是，我主要从事汽车嵌入式领域。此外，在职业生涯中，我还接触到了功能安全领域。
功能安全，简单来说，是指一个系统或是设备整体安全的组成部分。其达成安全性的方式是靠系统或组成零件在接受输入讯 后，可以正常的动作，来减少导致人类受伤的事故风险。例如一个马达中加装温度感测器，若温度超过一定值，即停止马达运转，此机能就属于功能安全。
在进入到汽车行业这些年，我担任过几个项目的技术负责人，其中部分职责会涉及到处理客户退货的问题。之所以这些汽车会被退回，大概率是由于电子单元或模块出现了问题，而我们团队需要确定导致该问题的根本原因。如果问题的根源确认是模块中出现了一个错误，我们会针对这个错误提出一个修复方案，并且将它整合到未来的更新中。有时我们会花费几天，甚至是几周来找出Bug的原因。
我现在还记得我第一次处理这些问题的的经历，那时我还是一个做模块测试的实习生。我们发现，有几个被退回的模块，在现场测试时出现了不一样的结果。有些能够正常工作，有些不能。在和软件团队调试了很长时间后，我们终于找出了问题所在，原来是因为一个未初始化的变量！我惊讶于这样的错误竟然没有被检测出来。
正常导致汽车故障的大多数问题本质上出在软件上。有趣的是，即使是在一些质量至上，而且拥有大量经验丰富软件工程师的公司也会出现这种情况。基本上，这些遇到现场问题的模块，已经进行了彻底的测试、代码审查、代码标准的实施（例如MISRA-C）。
一开始就考虑安全问题h2>
后来，在从汽车嵌入式领域进入功能安全领域时，我发现我的经历更加有趣。
在功能安全方面，像工业IEC-61508和汽车ISO-26262这样的标准在汽车行业开始流行起来。遵循这些标准的目的是为了减少产品故障的风险，风险的大小取决于产品的使用方式或者地点。通过在开发过程中加入更多的测试和检查，可以让产品达到一定的安全水平。
以ISO-26262为例，该标准对软件和硬件中可能发生的故障类型进行了分类。硬件的故障被分为两种类型：随机硬件故障和系统故障。在软件方面，只有一种类型，即系统性故障。根据ISO-26262，随机硬件故障被定义为：
在硬件元素的生命周期中，可能会发生不可预测的故障，并且遵循概率分布。
该标准还补充说：
随机硬件故障率可以以合理的精度进行预测。
而系统性故障被定义为：
故障以确定的方式与某种原因相关，只能通过改变设计或制造过程、操作程序、文件或其他相关因素来消除。
这意味着，系统故障或多或少源于人为错误，并不是真正可以预测的。因此，如果我们考虑修复软件问题，就意味着需要更多额外的检查。当然，在应用程序中也可以添加一些方法让其自己检查（例如N-版本编程），尽管如果把这些方法添加到动态的应用软件代码中，消耗的内存空间会增多。
鉴于我前面提到的，人们可能会认为这种变化是喜闻乐见的。但情况恰恰相反，大多数工程师都会反对整合功能安全流程。事实上，如何让工程师和团队接受这一点，让许多管理安全开发者感到很头疼。
这种推动力通常来自于产业链的顶端，即建立一种 “安全文化”。我认为，部分原因是由于流程和额外的文件或者可交付成果方面的重大变化，而不一定是因为个人反对安全的想法本身。（如果有什么是是工程师不喜欢做的，我想写文件一定排在首位。）
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！