• 与互联网的区别

作为互联网程序员 ， 日常工作环境是后端服务器或者客户端浏览器 ， 开发、测试和运行环境都非常成熟、稳定 ， 越来越标准化 。 作为开发者只需要关注到操作系统接口层面 ， 通常来说不需要也没有必要进一步深入到硬件层面 。
当从事自动驾驶系统开发时 ， 软件系统与车辆平台、车端硬件和传感器紧密耦合 ， 所有特性都必须经由软硬件系统的协调一致配合才能正常运行 ， 而且自动驾驶行业正处于剧烈进化的高速成长阶段 ， 车型与传感器型号繁多 ， 技术标准和接口多变 ， 所以 需要我们从底向上、从硬件到系统 ， 对各个层面、各个环节的知识都要有一定的了解 ， 最好是能有机会自己亲自参与硬件配置和软件部署调试的全过程 ， 才能加深整体认识 ， 避免盲人摸象 。
以我个人的看法 ， 如果具备一定年限的驾龄 ， 会更有助从司机角度理解用户的关注点和诉求 。

• 车规和功能安全

每个新进入自动驾驶行业的互联网程序员最多关注到的新名词必然是“车规”和“功能安全” 。
简要地说 ， 车规是汽车行业多年来积淀的从代码规范到开发过程的一系列行业标准和行业规范的统称 ， 功能安全（Functional Safety）是一个专业术语 ， 特指汽车行业一整套避免伤亡和损失的研发流程方法论 。
这其中与自动驾驶系统关系最密切的有国际标准《ISO26262-道路车辆功能安全》、C/C++代码规范MISRA C和MISRA C++（Motor Industry Software Reliability Association） 。 因为最新一版MISRA C++规范是2008年制定的 ， 无法覆盖C++11以来天翻地覆的语言标准变化 ， 所以也可以选择参考支持更高语言标准的代码规范AUTOSAR C++14 。

文章图片

ISO26262 V研发流程模型
如果遵照功能安全标准和方法论 ， 最终的成果是软件的车辆安全完整性等级（ASIL ， Automotive Safety Integrity Level） ， 分为ASIL-A、ASIL-B、ASIL-C、ASIL-D四个级别 ， 安全等级逐级递增 ， 如果通过了ASIL-D ， 就代表符合了最高级别的功能安全等级 ， 例如目前微内核实时操作系统QNX的功能安全版本QNX OS for Safety的部分组件（系统内核、部分系统服务、C编译器和标准库）就通过了ASIL-D标准认证 。
这里从ASIL-D标准里摘取几条要求 ， 我相信业界从业者都能体会到通过ASIL-D认证的复杂度和工作量：

• 形式化验证
• 限制使用指针
• 无隐藏数据流或者控制流
• 测试的分支覆盖率、函数覆盖率、调用覆盖率都要求100%

软件功能安全是一个专业性比较深的话题 ， 通常自动驾驶团队都会配备专业的功能安全工程师 ， 开发人员需要做的主要是了解标准概要和熟悉配套工具 ， 遵循专业人员的要求和建议 。 另外因为通过最高级别认证的成本相当高 ， 所以实际操作中一般都会根据项目需求 ， 针对不同模块 ， 选择适用的功能安全级别 。

• 实时性

在互联网行业 ， 实时系统一般泛指处理或者响应足够快速的系统 ， 并没有的明确的定义和定量的指标 。
在自动驾驶行业 ， 实时性（real-time）是特指系统具备在承诺的时间窗口或者调度周期内 ， 不受任务调度、资源争抢等外部因素干扰 ， 准时完成运算的能力 。 我个人认为更恰当的描述应该是“确定性” 。
举例来说 ， 一个设计指标为20Hz（即每秒20次）输出运算结果的任务模块 ， 如果能精确地做到每两次输出间隔都是50毫秒 ， 那就满足了设计要求的实时性指标 。 但是如果输出间隔不均匀或者明显抖动 ， 那即使能够实现30Hz甚至更高的输出频率 ， 也是不满足实时性指标的 。