软件2.0时代功能安全的思考

什么是软件2.0

特斯拉人工智能总监Andrej Karparthy在他的一篇技术博客中提出构建软件2.0技术栈的观点，代码正在从软件 1.0（由人类编写的代码）过渡到软件 2.0（由优化编写的代码，以神经网络训练的形式编写）。

软件1.0 是我们熟悉的，它是用 Python、C++、C等语言书写的。 它包括程序员对计算机的明确说明，通过编写每行代码，程序员会用一些可取的行为识别程序空间中的特定点。

软件1.0的工程方法遵循以下4个步骤：

1. 确定要解决的问题，即需求；

2. 把需求进行分解；

3. 为每个分解的需求设计软件；

4. 逐级测试，集成并部署软件.
   

软件2.0是用抽象、不友好的语言书写，如神经网络的权重。没有人编写这个代码，有很多参数权重（典型的网络可能有数百万个权重参数），人类编码已无可能。

软件2.0为何会出现，它可以解决什么软件1.0解决不了的问题呢？

以如何识别图片中的一只猫来举例，软件1.0工程方法需要把猫的照片进行分解，分为左耳、右耳、左眼、右眼、鼻子、……，对输入的图像像素点进行分解，对应去查找匹配的特征。

          

 

当面对各种各样不同颜色、不同动作的猫，软件1.0的方法就不好使了。对于这一类问题，机器学习为代表的数据驱动方法给出了一种新的解决思路，通过训练数据集，调整神经网络的参数权重，逐渐优化模型的输出结果。与传统软件开发过程不同的是，新方法不关注于算法的具体实现，对数据集进行标记，哪种照片是猫，哪种照片是狗，每次给模型输入后对它的性能进行评价。

在软件2.0模式中，解决的是一个较大空间下的最优解问题。在软件 2.0 中，源代码通常包括：

1） 定义理想行为的数据集

2） 神经网络架构，

该结构提供了代码的high level框架，但需要填写许多详细信息（权重）。训练神经网络的过程将数据集编译到二进制——神经网络模型。

  

上图是特斯拉FSD自动驾驶系统的1.0代码和2.0代码的比例，可以系统的开发逐步演进，2.0代码占有的比重越来越大。Andrej Karparthy提出了以下观点：

Software (1.0) is eating the world, and now AI (Software 2.0) is eating software. 

软件1.0正在吞噬世界，AI（软件2.0）正在吞噬软件

2.0时代功能安全软件的思考

软件2.0时代正在逐渐到来，目前AI算法大量应用于自然语言识别、行为分析、决策协助、身份识别等不涉及公众安全的领域，也在自动驾驶、医疗诊断等安全领域也在逐步应用。对于安全关键系统，系统工程方法学是否还适合软件2.0时代，功能安全标准如IEC61508、ISO26262、EN50128不同行业安全软件开发所遵循的标准，是否还能指导软件2.0的开发实践，下面从开发过程、软件需求、开发工具三个方面谈谈想法。

软件2.0开发过程

软件1.0的开发生命周期模型按照系统工程V模型的方式开发，从上到下是瀑布式的，规定每个阶段的过程要求、使用的工具方法和人员要求，前一阶段的输出交付物作为下一阶段输入，在每个阶段完成后对交付物进行验证，在软件集成后在最后阶段进行确认与软件需求的一致性。在实际应用中，设计实现阶段和测试阶段，会规划小版本之间的迭代，从整体过程来看还是V模型。

ISO26262软件开发生命周期模型

在软件2.0中，软件的行为需求很大程度上取决于所使用的数据集（datasets），数据集不同于传统意义上的数据，以往的数据如传感器数据、系统的参数（如配置参数、校准数据等）或系统使用的数据库（如导航数据库、障碍物数据库等），这些数据可以一定程度上确定系统的行为，但它们并不描述这种行为的逻辑。而机器学习使用的数据集不仅用来提取信息，而且用来建立模型，用来处理其他数据并确定一个系统的行为，确定安全关键系统的需求，等同于软件需求。当软件需求阶段无法获得完整的训练数据集，从V模型来说，后面的架构、设计实现阶段也无法开始。

软件2.0的开发模型始于数据，可以划分为数据管理、模型训练、模型验证、模型部署，这四个阶段不断往复迭代，不是一次性完成的。

• 数据管理：先建立所需数据集的要求，通过对数据的分析确定数据收集、增强和预处理的需求，收集什么数据，如何收集数据，如何解决样本数不足，收集成本过高的问题，如何对收集的数据清洗预处理。

• 模型训练：选择所使用的模型，构建损失函数作为训练误差的衡量标准，训练的目的是产生一个最小化该误差的模型。需要制定一个合适的数据拆分策略，用于训练模型、验证模型、测试模型的比例。

• 模型验证：针对数据管理阶段产生的独立于训练数据集的验证数据集，通过测试评估训练模型的性能。

• 模型部署：使用验证过的模型的系统将被集成，将经过验证的ML模型与使用传统软件工程方法开发和验证的系统组件进行整合，对其运行进行监控，并通过在线维护或在线学习进行更新。

以下图为例，FSD系统的训练模型在线获取传感器数据，在影子模式下输出与预期的偏差，收集数据后离线进行训练分析标记，对模型参数进行修正，验证后再次部署，不断循环迭代。

这种情况下，以迭代渐进为主线的敏捷开发方式与传统安全软件的瀑布开发方式有较大差异，如何确认软件达成系统目标、建立软件基线，需要重新考虑。

软件2.0新的软件需求：数据集

既然软件2.0的系统行为主要由数据集决定，系统是否符合其预期功能，很大程度上取决于数据集的质量。要证明数据集对于软件的预期功能在系统的操作环境下是足够的，对于认证来说是非常大的挑战。与软件1.0的需求对比，有以下不同：

• 确定软件需求不是在需求阶段，而是在软件开发阶段，对软件设计实现的输入将不是软件的功能需求，而是训练过程的输出。如一个神经网络架构、权重和偏差。

• 需求和设计实现不具备可追溯性，神经网络结构和权重不能追溯到开发它们的软件需求，追溯不到描述预期属性的需求文件，也追溯不到训练数据集。

• 安全软件的验证方法不再适合数据集及训练模型，人类已无法理解，无法实现人工审查和分析，传统软件基于需求的测试方法也无法进行。例如，功能安全软件的测试用例采用的等价类生成分析，由于常规规模的神经网络的高度复杂和非线性特征，不适用于模型的实施。要确定神经网络模型算法的等价类是不可能的。

  ISO26262 软件单元测试用例生成推荐方法
  

• 数据集的属性与软件需求保证属性存在差异，传统软件需求的完整性，清晰性，精确性，无歧义性，可验证性，可测试性，可维护性，可扩展性 这些属性的含义需要重新定义。

• 网络权重作为参数数据项，在本质上与传统的数据配置文件不同，依据已有配置参数修改流程而套用网络权重，存在很大偏差。

软件2.0开发工具链

传统软件开发中已建立完善的工具链用于支持开发，集成开发环境，编辑器，编译器，调试器，git集成，单元测试，集成测试工具，在功能安全软件工具的鉴定中，根据工具对软件安全性影响的不同，划分为不同的级别，例如ISO26262-8对软件工具的TCL1、TCL2和TCL3分级。在软件2.0中，也可以按照类似的分类对工具进行分级，但目前还没有完善的开发工具链和如何对工具鉴定的标准。

如何面对软件2.0的变化

从软件领域的发展来看，以机器视觉（上图）为例，软件2.0所占的规模越来越大，已出现机器自动生成的代码，当这类软件应用于安全关键系统时，有可能彻底改变既有软件的开发模式，需要识别与现有标准的差异，安全关键领域如航空航天、铁路、汽车标准，采用协作的方式在不同领域之间获取经验；对应用软件2.0产品的鉴定也不再是一次性的，与软件2.0生命周期类似，是一个迭代的过程，评估系统运行性能表现是重要环节；软件的变更会更加频繁，如智能网联汽车的OTA功能，对软件变更的评估，应考虑其服务期限、运行设计域差异、产品异常行为记录报告等所有既有数据记录。

原文始发于微信公众号（薄说安全）：软件2.0时代功能安全的思考