本系列博客包括6个专栏，分别为：《自动驾驶技术概览》、《自动驾驶汽车平台技术基础》、《自动驾驶汽车定位技术》、《自动驾驶汽车环境感知》、《自动驾驶汽车决策与控制》、《自动驾驶系统设计及应用》。
此专栏是关于《自动驾驶系统设计及应用》书籍的笔记.
3.ASIL分解与冗余功能安全
-
ISO 26262将失效类型分为系统失效和硬件随机失效两类；
-
系统失效的原因是：系统设计时的缺陷，主要是由设计人员的失误所导致，如：软件编写过程中的bug，硬件设计中的错误等；
-
硬件随机失效的原因：由于硬件材料老化引起的物理性能硬件失灵；
-
ISO 26262并未要求所开发的产品完全杜绝系统失效，而是建议通过加强过程管理与科学设计及检验，最大限度地减小系统失效的可能；
-
ISO 26262中很多建议条款都采用定性而非定量的描述方法，如下表所示，其中：●表示无要求，+表示推荐，++表示强烈推荐：
方法 ASIL A B C D 1a 软件组件分层结构 ++ ++ ++ ++ 1b 限制软件组件的大小 ++ ++ ++ ++ 1c 限制软件接口的规模 + + + + 1d 软件组件高内聚 + ++ ++ ++ 1e 限制软件组件之间的耦合 + ++ ++ ++ 1f 合适的调度属性 ++ ++ ++ ++ 1g 限制中断的使用 + + + ++ -
ASIL分解实质是通过额外的冗余部件实现安全，对于高ASIL级别的安全需求，标准允许将其在满足附加需求条件的情况下分解为两个低ASIL级别的安全需求；其中一个安全需求可使用相对复杂的方法实现，并被赋予一个相对较低的ASIL级别从而降低其开发与验证的难度，另一个安全需求则作为冗余实现，其安全需求也相对较高；ASIL分解的典型案例，如下图所示：
- 安全功能1需要满足ASIL D，可以将其分解为两个实现同样功能的低ASIL等级的需求，其中复杂的功能实现遵循ASIL A(D)开展，冗余功能实现遵循相对较严格的ASIL C(D)级别实现；
- 两个需求均实现原始需求同样的功能，当两者计算结果一致时，系统认为工作正常，当两者计算结果发生分歧时，系统采用ASIL C(D)对应模块的输出结果作为最终结果；
-
分解需求的独立性：指两个需求不可有共因失效，即同一个原因可导致两个需求同时失效；
-
飞思卡尔MPC5643L硬件冗余如下图所示：
飞思卡尔MPC 5643L数据手册
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。