上回我们谈论了基于系统体系结构的安全性分析过程，简要介绍了PSSA中FTA的要点。对于软件安全性来说，是如何从这个过程获取软件安全性需求的呢？
在FTA过程中，如果是具有失效率的功能或硬件，那么可以基于FTA进行安全性指标的定量评估，和低层次功能或硬件安全性指标的分配，这是主要的功能或硬件的安全性需求来源。
对于软件来说，引起顶事件FC的来源是设计错误，由于设计错误难以获取准确的失效率，所以在功能安全方法中，对于设计错误如何在FTA中进行分析和评估，PSSA提供了另一个视角：研制保证等级DAL-DevelopmentAssuranceLevel。DAL的含义是，以一定级别的严格程度去控制设计过程，以尽可能消除设计过程中引入的错误。
这些错误包括：
软件设计错误（软件需求、软件体系结构等等）
软件开发错误（软件开发过程、软件配置管理等等）
硬件设计错误（硬件需求、硬件体系结构等等）
硬件开发错误（硬件开发过程、硬件配置管理等等）
电子硬件工具错误（VHDL代码生成、布线工具等等）
软件工具错误（编译器、连接器等等）
DAL分为功能Function的FDAL与配置项Item的IDAL两类，和软件研制保证等级相关的就是IDAL，但是IDAL的获取必须经由FDAL分解而得。原因是Item是由Function分解而来的。
在SAEARPA中，为了获取IDAL，采用了FFS：FunctionalFailureSet来帮助分析。FFS是一个或多个彼此独立对象（功能或配置项）的集合，它们同时发生会导致顶事件FC。
概念上可以认为，FFS是故障树的最小割集，FFS中的对象（Member）表示开发错误，而不是失效。FFS的目标是识别能够引起顶事件FC的对象组合，并且给这些对象的错误控制过程（也就是软件和电子硬件的开发过程）分配合适的DAL。
上图来自于SAEARPA
可以近似理解为，在FDAL和IDAL分析过程中，观察FTA的视角可以脱离“失效Failure”，而聚焦于“错误Error”。有权威人士曾提出，FTA是两棵树，一个失效的FTA，一个是错误的FTA。
这是一种工程权衡和把握，没有绝对的对错，从SAEARP自身的实例中，失效和错误是在一棵FTA中同时出现的，这并不影响理解和实施。
例如：
如果FHA识别出的故障树顶事件是一个A级的FC，FTA中导致这个FC的如果是一个功能或配置项，那么这个功能或配置项的开发保证等级DAL就是A。
如果FHA识别出的故障树顶事件是一个A级的FC，FTA中导致这个FC的如果是多个彼此独立的功能或配置项，那么其中至少1个对象的DAL是A，其余不能低于C；或者其中至少2个对象的DAL是B，其余不能低于C。
如果其中的对象有软件配置项，那么该软件配置项的IDAL有可能是A级、B级或C级。这取决于和这个软件配置项共同构成FFS的其他功能和配置项在FTA中的关系及各自的DAL等级。
这个DAL的分配过程如下图所示。
上图来自于SAEARPA
这个软件配置项的研制保证等级IDAL，就是我们习惯说的软件“重要度等级”或“关键度等级”或“安全性等级”。它是FHA和FTA共同分析、权衡出来的，是系统安全性结果PSSA的重要输出。
这是系统分配给软件的安全性需求。
不做IDAL等级的分析，无法获得正确的IDAL等级，基于等级的软件开发就没有开展的基础，软件就做不到安全可靠。
例如SAEARP中页的例子：
我们把DAL加在这个FTA里，就得到了两个可能将会由软件或电子硬件去实现的“设计错误”，图中划红线的A级和B级。
上图来自于SAEARP
以右下角A级的“BSCU1CPUFunctionDesignErrorCausesBadData”为例，这个功能的设计错误将由软件或FPGA去实现——这也是系统FTA分配给软件或FPGA的安全性需求。
所以，写在《软件研制任务书》里的软件安全性需求包括：
1、BSCU1软件的研制保证等级（重要度等级）——A级。
2、BSCU1软件应采取措施确保不发生“BSCU1功能设计错误，导致错误的输出数据”的事件，并采用软件分析与测试的方法，验证本需求的满足性。
如果，设计师发现，在这个需要采取措施让它“不发生”的安全性需求里，可以加入一些新功能，使错误数据输出时能够得到监控和处理，这岂不是更好？
这确实是更好。
比如，既然我们知道如果产生了错误输出数据，将可能会引起不好的结果，那么完全可以加入一个“监控器”，当真的产生错误输出数据时，进行告警或处理，这样的系统，更加安全。
如果两者的功能彼此独立，于是右下角的事件就会变成下图所示。
我们看到，加入了“Monitor”后，原来只需BSCU1自己错的事件，就变为了BSCU1自己错，加上Monitor也出错同时发生才可以，这样的发生条件更苛刻了，系统更安全——当然也更复杂，这就需要权衡了。
按照IDAL等级分配方法，原来A级的IDAL，可以分配为两个B级的IDAL了。
到底是选择一个A级的开发，还是两个B级的开发，要设计者根据自己的情况去决策。
如果采用了两个B级的方案，那么，写在《软件研制任务书》里的软件安全性需求就可以写成：
1、BSCU1软件的研制保证等级（重要度等级）——B级。
2、应采取措施确保不同时发生“BSCU1功能设计错误，导致错误的输出数据”，和“BSCU1DataMonitor功能设计错误，导致错误的监控结果”，并采用分析与测试的方法，验证本需求的满足性。
这就是待开发的软件配置项的安全性目标。
系统FTA向软件分配IDAL的过程中，产生了新的需求，这个需求系统不是根据功能分解传递给软件的，是系统的PSSA安全性评估过程中发现的，因此是安全性需求。这时还需要向系统反馈这个新需求，以确保需求的可追踪性。
同时，需求变化又带来FTA的迭代，工作成本将上升。
如何满足软件任务书里的安全性需求的实现过程，是后续软件需求规格说明要要去分析和描述的。
软件需求要表明：在需求阶段，采取了可信的设计手段，能够避免“BSCU1功能设计错误，导致错误的输出数据”这样不期望结果的发生；并表明，各种可能导致该结果的情况，均已经被识别和消除。
这样的表明手段，包括软件FMEA和测试，也包括需求评审——这是“狭义”的软件安全性或软件“健壮性”所聚焦的。而实际上，它是系统安全性过程中的一个环节。
这次我们简要探讨了软件研制任务书中的安全性需求如何获取，后面我们将对软件需求分析和规格编写中的安全性需求进行详述。
赞赏