基于ISO26262标准的软件开发 发布时间: 2020-08-19 12:01

 基于ISO26262标准的软件开发

1.软件架构设计
软件开发流程跟硬件开发基本一样,由软件TSR和系统需求可以确定软件基本架构。软件安全要求需要与软件架构一起实施,以及与安全相关的其它软件要求。在软件架构中,由于软件单元获得了分配给他们的不同软件安全性要求,因此考虑这些可能与不同ASILs的要求是否可以共存在同一软件单元中也很重要。如果不符合这些标准,则需要根据所有分配的安全要求的最高ASIL开发和测试软件。这些标准可能包括内存保护和保证的执行时间。
软件架构包含静态和动态方面的,静态方面的主要和不同软件单元之间的接口:1)软件结构包括其分级层次;2)数据处理的逻辑顺序;3)数据类型和它们的特征参数;4)软件组件的外部接口;5)软件的外部接口及约束(包括架构的范围和外部依赖)。动态方面的涉及:1)功能性和行为;2)控制流和并发进程;3)软件组件间的数据流;4)对外接口的数据流时间的限制。为了说明这两个方面,软件架构所用到的标记法有,非正式标记法,半正式标记法,正式标记法,ASIL等级越高,标记法越正式。
在软件架构设计中,需要重点考虑软件的可维护性及可测试性。在汽车行业,软件在整个产品周期内都应当考虑维护性,同时还要考虑软件架构的设计测试的容易醒,在ISO26262标准中,测试是非常重要的一方面,任何设计都应该同时考虑到测试的方便性。
为避免高度复杂性导致系统性故障,ISO26262列出来一些推荐的标准:
软件层次性,软件模块的高内聚性,限制软件模块大小
软件模块之间的接口应当尽量少且简单。这个可以通过限制软件模块的耦合度实现
软件调度应当避免使用中断,如果使用了中断,要注意考虑中断的优先级。目的是确保软件单元执行时间 
在软件架构层面,可以检测不同软件单元之间的错误。ASIL等级越高,要求的安全机制越多。下面是ISO26262中提到的一些安全机制,有些安全机机制之间可能有重复。
数据范围检查:数据在不同的软件模组读写时,这个简单方法可以确保数据在正常合理范围之内。任何超出这个范围的数据,都可以被认为是错误的数据,比如电池cell电压超出5v,就可以认为这个数据是无效的。
真实性检查:软件模组之间的信号传递可以采用这种类型的合理性检查。比如汽车在1s内从静止状态加速到100km/h,这个减速度在汽车上是不现实的。同时可以采用参考模型或者其他来源信息来评估信号的合理性。
数据错误检查:有许多方法可以检查数据的正确性,比如数据校验(datachecksums),冗余数据备份
控制流监控:通过监控软件单元的执行流程,可以检测到某些故障,包括跳过的指令和软件卡在无限循环中。
多样化软件设计:在软件设计中使用多样性设计可以高效的检测软件故障。该方法是设计两个不同的软件单元进行互相监控;如果二者行为不同,那么说明其中一个故障。因为软件设计师也犯了类似的错误并不罕见。为了避免类似的错误,软件功能越多样化,这些类型的错误的可能性就越低。
一旦软件错误被检测到,应该有相应的错误处理机制。在软件架构级别ISO26262详列的错误处理安全机制如下:
静态恢复机制:目的是从破坏的状态回到可以继续正常运行的状态
适度降级:当发生故障时,该方法让系统进去一个安全运行模式。汽车软件的通常做法是亮起警示灯通知驾驶员某部件出现了问题,对高压系统而言,如BMS检测到轻度绝缘故障等。
独立并行冗余:该安全机制可能会需要硬件冗余,因此成本相对而言较高。这个概念假设基于两个冗余硬件同时发生错误的概率相对很低,并且有一个硬件一直处于正常无故障运行模式。
数据纠错码:对于数据错误,有机制可以纠正这些错误。这些机制都是基于添加冗余数据来提供不同级别的保护。使用的冗余数据越多,可以更正的错误就越多。这通常用于CD,DVD和RAM,但也可以在汽车领域使用。
一旦软件架构设计结束后,就需要对软件架构的需求进行测试。ISO26262详列了一些方法:
设计走查:一种同行审查的形式,软件架构设计者将这种架构描述为一组审查人员,目的是检测任何潜在的问题。
设计检查:与走查相比,检查更正式。它包括几个步骤:规划,离线检查,检查会议,返工和更改的后续工作
仿真:如果软件架构可以通过软件进行仿真,那么仿真是一种有效的方法,特别是在架构的动态部分找到故障。
生成原型:与仿真一样,原型设计对于动态部件来说也是非常有效的。分析原型和预期目标之间的任何差异也是很重要的。
形式验证:这种方法用数学证明或反驳正确性,很少用于汽车行业。它可用于确保预期的行为,排除意外行为,并证明安全要求。
控制流分析:这种类型的分析可以用在在静态代码分析。目的是在架构层的软件执行中找到任何安全关键路径。
数据流分析:这种类型的分析可以用在在静态代码分析。目的是在软件架构层面找到任何安全关键的变量
 
2.软件单元测试
一旦软件安全要求确定了,单元级别的软件架构已完成,那么就可以展看软件单元的设计和实施。ISO26262支持手动编写的代码(manuallywrittencode)和自动生成的代码。如果生成代码,则可以省略对软件单元的要求,前提是使用的工具已经通过ASIL等级认证。在本节中,重点将是人工编写的代码。
与软件架构的规范一样,ISO26262规定了应用于软件单元设计的符号。ISO26262要求适当组合所使用符号。并且始终强烈推荐自然语言。此外,该标准建议使用非正式符号,半正式符号和正式符号。
关于软件单元实施,ISO26262中提到的许多设计原则。有些可能不适用,取决于开发过程。有些也可能被使用的编码指南所涵盖:
子程序和函数采用一个入口和一个出口:多个出口点通过代码使控制流复杂化,代码难以理解和维护。
无动态对象或动态变量,在其产生过程中也没有在线测试:动态对象和变量存在两个主要挑战,不可预测的行为和内存泄漏。两者都可能对安全产生负面影响。
变量初始化:没有初始化变量,变量可能是任何值,包括不安全的和非法的值。这两者都可能对安全产生负面影响。
不能重复使用变量名称:使用相同名称的不同变量有风险
避免全局变量,否则需证明对全局变量的使用是合理的:全局变量从两个方面来说都是坏的:它们可以被任何人读取并被任何人写入。开发安全相关的代码,强烈建议从这两个方面控制变量。有些时候,可能存在全局变量优先的情况,如果使用全局变量的相关风险的使用可以被证明安全,ISO26262允许这些情况。网上文章说丰田的踏板事件中,28万行代码,有1w多个全局变量。
限制使用指针:使用指针的两个重大风险是变量值的破坏和程序的崩溃;两者都应该避免。
无隐式类型转换:即使编译器支持某些编程语言,应避免这种情况,因为它可能导致意外的行为,包括数据丢失。
无隐藏数据流或控制流:隐藏的流程使代码更难以理解和维护。
没有无条件跳转:无条件跳转使得代码更难以分析和理解
无递归:递归是一种强大的方法。然而,它使代码复杂化,使其难以理解和验证。
在软件单元设计和实现的时候,需要验证硬件-软件接口和软件安全要求是否满足安全需求。此外,应确保软件代码符合编码准则,软件单元设计与预期硬件兼容。ISO推荐了的方法基本和软件架构的一样。
静态代码分析: 分析的基础是调试源代码而不执行它。通常包括语法和语义的分析,检查编码指南,如MISRA-C,变量估计,控制流和数据流的分析。
语义代码分析:该方法一般考虑到的是源代码的语义方面,是一种静态代码分析。可以检测的示例包括未正确定义和以不正确方式使用的变量和函数。
IATF16949 IATF16949认证 IATF16949五大工具 IATF16949培训 IATF16949质量体系 IATF16949认证公司 IATF16949认证机构 IATF16949认证咨询公司