BMS功能安全开发流程（六）：汽车软件开发.docVIP

BMS功能安全开发流程（六）：汽车软件开发 来源：第一电动网 作者：129Lab 前面五部分介绍了基于ISO26262标准的开发BMS的系统及硬件部分，最后一部分介绍软件部分。至此整个BMS的功能安全开发流程简单梳理了一遍。这个月国家标准化管理委员会发布了功能安全的GB/T版本，虽是推荐标准，但是以后越来越多的OEM会对供应商列为强制标准，对零部件企业的电子电气系统开发是个极大的挑战。【BMS功能安全开发流程（一）--（五）】 在汽车行业软件开发一般遵循V模型，左边是开发过程，右边对应的测试过程。ISO26262第六部分推荐的软件开发流程也V模型，如下图所示，跟硬件的V模型开发流程基本一样，需求--架构--详细设计。 1. 软件架构设计 软件开发流程跟硬件开发基本一样，由软件TSR和系统需求可以确定软件基本架构。软件安全要求需要与软件架构一起实施，以及与安全相关的其它软件要求。在软件架构中， 由于软件单元获得了分配给他们的不同软件安全性要求，因此考虑这些可能与不同ASILs的要求是否可以共存在同一软件单元中也很重要。 如果不符合这些标准，则需要根据所有分配的安全要求的最高ASIL开发和测试软件。 这些标准可能包括内存保护和保证的执行时间。 软件架构包含静态和动态方面的，静态方面的主要和不同软件单元之间的接口：1）软件结构包括其分级层次； 2） 数据处理的逻辑顺序； 3) 数据类型和它们的特征参数； 4） 软件组件的外部接口； 5）软件的外部接口及 约束（包括架构的范围和外部依赖）。动态方面的涉及：1）功能性和行为； 2）控制流和并发进程；3） 软件组件间的数据流；4） 对外接口的数据流时间的限制。为了说明这两个方面，软件架构所用到的标记法有，非正式标记法，半正式标记法，正式标记法，ASIL 等级越高，标记法越正式。 在软件架构设计中，需要重点考虑软件的可维护性及可测试性。在汽车行业，软件在整个产品周期内都应当考虑维护性，同时还要考虑软件架构的设计测试的容易醒，在ISO 26262标准中，测试是非常重要的一方面，任何设计都应该同时考虑到测试的方便性。 为避免高度复杂性导致系统性故障， ISO26262列出来一些推荐的标准： ? 软件层次性，软件模块的高内聚性，限制软件模块大小 ??软件模块之间的接口应当尽量少且简单。这个可以通过限制软件模块的耦合度实现 ??软件调度应当避免使用中断，如果使用了中断，要注意考虑中断的优先级。目的是确保软件单元执行时间 ? 在软件架构层面，可以检测不同软件单元之间的错误。ASIL等级越高，要求的安全机制越多。下面是ISO26262中提到的一些安全机制，有些安全机机制之间可能有重复。 数据范围检查：数据在不同的软件模组读写时，这个简单方法可以确保数据在正常合理范围之内。任何超出这个范围的数据，都可以被认为是错误的数据，比如电池cell电压超出5v，就可以认为这个数据是无效的。 真实性检查：软件模组之间的信号传递可以采用这种类型的合理性检查。比如汽车在1s内从静止状态加速到100km/h，这个减速度在汽车上是不现实的。同时可以采用参考模型或者其他来源信息来评估信号的合理性。 数据错误检查：有许多方法可以检查数据的正确性，比如数据校验(data checksums)，冗余数据备份 控制流监控：通过监控软件单元的执行流程，可以检测到某些故障，包括跳过的指令和软件卡在无限循环中。 多样化软件设计：在软件设计中使用多样性设计可以高效的检测软件故障。 该方法是设计两个不同的软件单元进行互相监控; 如果二者行为不同，那么说明其中一个故障。 因为软件设计师也犯了类似的错误并不罕见。 为了避免类似的错误，软件功能越多样化，这些类型的错误的可能性就越低。 一旦软件错误被检测到，应该有相应的错误处理机制。在软件架构级别ISO26262详列的错误处理安全机制如下： 静态恢复机制：目的是从破坏的状态回到可以继续正常运行的状态 适度降级：当发生故障时，该方法让系统进去一个安全运行模式。汽车软件的通常做法是亮起警示灯通知驾驶员某部件出现了问题，对高压系统而言，如BMS检测到轻度绝缘故障等。 独立并行冗余：该安全机制可能会需要硬件冗余，因此成本相对而言较高。这个概念假设基于两个冗余硬件同时发生错误的概率相对很低，并且有一个硬件一直处于正常无故障运行模式。 数据纠错码：对于数据错误，有机制可以纠正这些错误。 这些机制都是基于添加冗余数据来提供不同级别的保护。使用的冗余数据越多，可以更正的错误就越多。 这通常用于CD，DVD和RAM，但也可以在汽车领域使用。 一旦软件架构设计结束后，就需要对软件架构的需求进行测试。ISO26262详列了一些方法： 设计走查：一种同行审查的形式，软件架构设计者将这种架构描述为一组审查人员，目的是检测任何