功能安全中的软件隔离（1）

关于功能安全性，ASIL分解是无法避免的主题. 软件隔离基于不同ASIL级别的要求. 让我先谈谈ASIL分解. 为了减少软件和硬件开发的难度，功能安全性提供了ASIL分解的想法. ASIL为什么会分解？从硬件和软件两个方面的个人总结:

1. 在硬件方面软件隔离如何取消，没有符合ASIL C要求的芯片或价格昂贵（许多制造商声称其芯片为ASIL C或ASIL D软件隔离如何取消，但是如果它们需要完整的认证材料或ISO 26262，则该标准删除了细节，例如是否有一个符合要求的FMEDA，但不能满足要求）. 系统降级可以减少硬件需求并降低成本（由于冗余设计，它可能还会增加）

2，该软件表示这是为了减少开发难度. 功能安全软件开发中有一个分水岭，即ASILC. 当从ASIL B到ASIL C的软件开发要求交叉时，这是质的飞跃. 假设我们只选择实现ISO26262的“ ++”号（强烈推荐）的内容（知名汽车制造商也将要求实现“ +”，并且没有理由）是ASIL C和ASIL B之间的两个比较. 比较困难的要求

一种是防御性编程，另一种是程序流监视. 这两个概念在传统的嵌入式编程中很少提及. 尽管我们通常在编写软件时会涉及一些内容，但防御性编程（例如在使用循环时使用阻塞）可能会跳出循环并阻止数组. 超出范围，防止被0除，备份关键数据等. 如果将看门狗用于程序流监视，则也将实现其中的一部分. 但是如果严格执行，将会增加编程的难度. 例如，程序流监视需要监视每个模块的调用顺序，并且必须具有检测的能力. 防御性编程也无止境，添加了大量代码. 另外，对编码规则和测试的要求也更高. 有关详细信息，请参阅ISO 26262-PART6，或在以后有空时再谈.

ISO 26262第9部分中的详细介绍，下图是标准中推荐的ASIL分解方法

ASIL分解需要注意，这是其他地方引用的内容的副本:

ASIL分解的最重要要求之一是独立性. 如果无法满足独立性要求，则应根据原始ASIL级别开发冗余单元. 所谓独立性是指冗余单元之间不应该有从属故障（Dependent Failure）. 有两种类型的相关故障: “常见原因故障”和“级联故障”. 共因故障是指两个单元由于通用原因而导致的故障，例如软件复制冗余，冗余单元都将由于相同的软件错误而失效，为了避免这种常见原因的故障，我们采用了多种软件设计方法. 级联故障是指一个单元的故障导致另一单元的故障. 例如，一个软件组件的功能失败，并被写入另一软件组件的RAM中，从而导致另一软件组件的功能失败. 为了控制级联的故障，我们借助内存管理单元，可以检测到对RAM的非法写入.

ASIL分解很简单，但是在实际操作中它将变得非常复杂. 它涉及RAM，FLASH隔离，任务分配，各种独立性分析，安全性分析，而且很繁琐.

本文似乎只能介绍背景. 我受我的代码水平太差的限制. 我最近太忙了. 有时我只是想总结一下. 我们暂时这样做.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/ruanjian/article-172418-1.html