功能安全中的软件隔离（一）
说到功能安全绕不开的一个话题是ASIL分解。而软件隔离就是出于不同ASIL 等级要求提出的。先说说ASIL分解吧。为了降低软硬件的开发难度，功能安全提供了ASIL分解的思路，为什么要做ASIL分解呢？个人总结从软硬件两方面说：
1，硬件上说，能达到ASIL C要求的芯片要求，要么没有，要么贵（很多厂家都声称自己的芯片做到了ASIL C或者ASIL D，但是如果要求完整的认证材料或是按ISO26262标准去抠细节，例如是否有符合要求的FMEDA等，就达不到要求）。系统降级可以降低硬件要求，同时降低成本（也有可能增加，因为冗余设计）
2，软件上说，就是为了降低开发难度。功能安全的软件开发，有个分水岭，就是ASIL C。当软件开发从ASIL B跨到ASIL C的要求，就是一个质的跨越了。假设我们只选择实现ISO26262的“++”号（强烈建议）的内容（知名车厂会要求一个“+”也要实现，不实现需要给出理由），则在ASIL C与ASIL B相比有两个难度较高的要求
一是防御性编程，二是程序流监控。这两个概念在传统的嵌入式编程中较少被提到，虽然我们平时编写软件时多多少少有做到一部分内容，防御性编程例如使用while循环时使用阻塞处理，可跳出循环，防止数组越界，防止除0，关键数据备份等。程序流监控如果使用看门狗的话，也实现了一部分。但如果严格执行起来，会增加很多的编程难度。例如程序流监控，需要监控各个模块的调用顺序，要有在线检测的能力。防御性编程也是永无止境的，增加了很多代码量。除此之外对于编码规则和测试的要求也是高出很多，具体参照ISO 26262-PART6可看，或后面有时间的时候再展开说说。
在ISO 26262的PART9中有详细介绍，下图是标准中推荐的ASIL分解方法
ASIL分解需要注意的点，在这抄一下从别处引用的内容：
ASIL 分解的一个最重要的要求就是独立性，如果不能满足独立性要求的话，冗余单元要按照原来的ASIL等级开发。所谓的独立性就冗余单元之间不应发生从属失效（Dependent Failure），从属失效分为共因失效（Common Cause Failure）和级联失效（Cascading Failure） 两种。共因失效是指两个单元因为共同的原因失效，比如软件复制冗余，冗余单元会因为同一个软件bug导致两者都失效，为了避免该共因失效，我们采用多种软件设计方法。级联失效是指一个单元失效导致另一个单元的失效，比如一个软件组件的功能出现故障，写入另一个软件组件RAM中，导致另一个软件组件的功能失效，为了控制该级联失效，我们采用内存管理单元，可以探测到非法写入RAM的情况。
ASIL分解是看起来简单，但真正操作起来会变得很复杂的活，涉及到RAM,FLASH的隔离，TASK的分配，各种独立性分析，安全分析，不胜繁琐。
看来本篇只能介绍下背景了，受限于本人码字水平太差，写着写着就跑题，见谅。最近也忙到不行，偶尔插空总结一下，就暂时先这样吧。
- 用户评论