SASETECH
建立安全生态圈，成为汽车安全的布道者
进入主页添加星标，第一时间获得消息⭐
原创
简述软件架构元素的复用
如果已有的软件架构元素没有根据功能安全标准要求进行开发，为了加快项目的研发进度，是否可以复用该软件架构元素到功能安全相关的软件组件里呢？答案是可行的。下面我们一起看看，复用的 PSAE 如何做，能够满足功能安全要求。在开始介绍之前，先来熟悉几个术语的定义。
◆ 复杂性：软件的设计、实现及其功能很难理解和验证。
◆ 复杂性度量：根据复杂性测量结果分配值的变量。
◆ 已存在的软件架构元素（PSAE）：已经有专门可用的OTS软件，定制的软件，以及没有遵循ISO 26262进行开发的软件。
◆ 起源：在使用PSAE时，识别可预见的限制，并确认已知的限制。
➡本文主要内容（约2200字，10分钟阅读）
01.
PSAE的分类
PSAE是依据它的起源和复杂性来进行分类的。
起源方面，主要指起源相关的不确定性，因为它会导致PASE可能包含系统性故障，这会影响目标软件架构设计。如果PSAE的开发过程遵循了相关国家/国际标准（比如：ISO/IEC/IEEE 12207），或者是遵循了不同的功能安全标准（比如：IEC 61508）,此时可以选择”P1”；如果”P1”不能完全声明满足，但是经过评估，软件开发过程的相关差异是可接受的，这时可以选择“P2”；所有其他的情况，选择”P3“。
复杂性方面，主要指复杂性相关的不确定性，因为它会导致PSAE可能包含很难被发现的系统性故障。如果没有确定的复杂度指标表明高复杂度时，可以选择”C1”；如果确定的高复杂度指标表明高复杂度，但是经过评估是可接受的，此时可以选择”C2”；所有其他的情况，选择”C3”。
将起源方面的P值和复杂性方面的C值进行组合，就得到了PSAE的分类表格。
经过分析，如果得出的PSAE分类为ClassⅠ，那么后续直接遵循 ISO 26262-8:2018 的第12章节的相关要求即可 （Qualification of SW components）；如果得出的PSAE分类为ClassⅡ，那就需要根据实际情况来准备影响分析以及其他相关文档。
02.
ClassⅡPSAE的影响分析
首先是评估操作方面的影响
根据功能安全标准中要求（part2, 第6章节），元素层面的影响分析至少要考虑以下几方面：
①分配给PSAE的安全要求的ASIL等级；
②PSAE的外部接口；
③目标环境；
④调度，定时和并发性方面 （比如：数据竞争条件和操作系统同步机制的行为）；
⑤标定和配置数据。
其次是软件安全要求的分配
相关的软件安全要求要分配给PSAE的功能和属性。这里需要进行评估，来确定PSAE是否满足分配的软件安全要求。如果不同ASIL等级的软件安全要求分配给了PSAE，那么我们也需要评估下PSAE是否可以满足已分配给它的最高ASIL等级的要求。
之后对PSAE现存的设计文档进行评审
对现存的PSAE的设计文档进行评审，评估其是否提供了足够的证据表明已经集成了PSAE的目标软件架构设计支持实现功能安全。
最后，别忘记计划相关的安全活动
按照分类的定义，对PSAE进行分类，然后计划上述内容产生的安全活动（安全分析，软件安全要求的分配，相关设计文档的评审）来识别并减少PSAE潜在的系统性故障，并确保实施必要的安全措施。如果PSAE不能满足分配的安全要求，我们还还需要在安全计划中定义相关活动以解决符合性问题。这里可以把评估起源相关和复杂性相关的不确定性过程当成是确认措施（confirmation measure）。
03.
ClassⅡPSAE的适用性评估
完善架构设计：当PSAE的设计信息不足够来评估其在目标软件架构设计使用中的影响时，我们需要重新分析下PSAE的架构设计，并明确好它的子元素（这里的设计信息可能包括：响应时间，资源管理和时间交互，输入数据组合集，软件安全功能的时序，软件功能执行时序内的时间关系等）。PSAE的设计信息要能够支持识别与安全相关的子元素，包括：
①子元素的功能和属性及其对实现功能安全的影响；
②子元素之间动态和静态的相互作用。
分配并完善软件安全要求：基于完善后的架构设计，我们要将软件安全要求分配给 PSAE，并对软件安全要求进行优化完善。如果通过识别PSAE的子元素的功能和属性 （通常是安全相关的），发现其故障可能导致违背软件安全要求，这时，我们需要分配给PSAE子元素额外的软件安全要求（比如：安全与非安全相关的子元素之间的免于干扰，不同安全等级的子元素之间的免于干扰）。软件安全要求分配完成后，注意这里需要对相关软件安全要求进行需求管理（需求的可追溯性，需求和架构设计的追溯性和一致性），相关需求管理办法可以参考ISO 26262 PART8的第6章节。
软件安全分析：软件安全分析主要用来验证以下几方面：①基于完善的软件架构和软件安全要求，验证违背分配给PSAE的软件安全要求的风险足够低；
②验证PSAE内充分实现了所需要的免于干扰；
③安全分析的结果要明确PSAE是否满足软件安全要求。具体如何做软件的安全分析，相信大家都比较熟悉了，这里不在阐述（可以参考ISO 26262 PART6, 第7章节 和 ISO 26262 PART9，第8章节）。
04.
验证ClassⅡPSAE的使用
验证PSAE及其在目标软件架构中的集成主要是提供证据表明：
①通过软件安全分析得到的每一个安全机制都是有效的；
②在PSAE里实现的安全相关的功能和属性满足由影响分析和适用性评估得出的要求。
已有的对PSAE的验证结果经过评估过后，可以用来支持验证目标软件架构设计。如果集成的目标软件有未测试的接口，未测试的代码等，可以用安全分析结果来提供证据和论证，说明这些未进行测试的点不会影响功能安全的实现。
05.
PSAE设计的变更
对PSAE设计的修改应该保持在最低限度（修改只适用于ClassⅡPSAE，不适用于Class Ⅰ PSAE）。PSAE设计的变更实施过程中，相关的文档证据要按照ISO 26262配置管理的要求进行管理和记录。变更请求的分析按照ISO 26262 PART8 第8章节的相关要求进行即可。
参考文献：
[1] ISO 26262 PART2
[2] ISO 26262 PART6
[3] ISO 26262 PART8
[4] ISO 26262 PART9
[5] ISO/PAS 8926
赵伟占| 作者
闻继伟 | 审核
免责声明：如涉及侵权请及时与我们联系反馈，我们会在第一时间做更正声明或做删除处理。文章版权及解释权归原作者及发布单位所有，如需转载或引用本文的任何内容，请注明出处。
END
近期热门
AI课程火热报名中
功能安全工程师培训
往 期 精 选
JOIN US
长期招募
杭州
— 高级信息安全工程师
欢迎将个人简历发送至邮箱：
double.ma@sasetime.com
SASETECH是国内首个由汽车安全专家发起组建的技术社区，致力于为汽车安全的从业者提供交流、学习、合作的中立性平台。
SASETECH
扫码联系管理员加入交流群→
