功能安全概念及功能安全需求浅析...
功能安全概念源于功能安全要求，安全目标，安全状态、并分配他们到该项目的初步建筑元素或外部措施中。
功能安全概念包括：
1、故障检测和故障缓解方法;
2、如何过渡到一个安全状态;
3、容错机制，即其中一个故障不会直接导致违反安全目标（S）保持功能在安全状态（或功能退化）;
4、故障监测与驾驶员警告来减少风险暴露的时间到一个可接受的范围（例如发动机故障指示灯，ABS故障指示灯）;
5、仲裁逻辑来判断从不同的功能发送过来的多个请求中选择最重要的控制请求执行.
功能安全需求应来自安全目标和安全状态，并考虑到初始的架构情况提出。同时每个明确的安全目标至少有一个功能安全的要求。
功能安全需求的明确需要考虑以下的方面：
操作模式
容错的时间间隔
安全状态
应急操作的间隔
功能冗余（例如故障冗余）
如果安全状态在可接受的时间间隔内不能达到，那么应急操作应该在安全需求中被明确；同时报警和降级（功能退化）的概念应该被安全需求明确；
如果假设司机采取必要的行动，或其他人可能在风险，为了符合安全目标，那么a）和b）应满足：
a）这些行动应在功能安全概念中明确；
b）提供给司机或处于潜在危险的其他人的足够的手段和控制方法应在功能安全概念中明确。
功能安全需求需要分配到初始的架构元素中：
1、分配时，ASIL等级与信息继承于安全目标，如果ASIL等级分解被应用，与其分配的等级保持一致；
2、多个功能分配到同一个部件中，选取最高的功能安全等级；
3、如果项目的组成超过一个系统，那么功能安全需求需要考虑初始的架构，将需求这些独立的系统与其接口。如此分配功能安全需求到系统中；
4、如果在功能安全需求分配中分解被应用，那么分解应该遵循相应的措施（ISO 26262-9:2011, Clause 5）。
在分解过程中，系统功能具有独立架构是分解能够使用的先决条件； 通过独立的架构要素执行功能安全的冗余要求时可以分配一个低ASIL等级到这些架构要素中； 特别需要注意的是，如果架构要素不是完全的独立的，那么冗余要求与基本的架构保持最初的功能安全等级要求，且不能分解； ASIL分解能够被应用于功能，技术，硬件，软件的安全要求； ASIL分解的应用必须满足冗余安全要求是分配到独立的架构要素中； 当使用同系的冗余（例如：通过增加同样的设备或者同样的软件）来考虑系统的软硬件故障，ASIL不能被减少，除非他们完全独立的存在。
例如：
一个ASIL D被裁剪成一个ASIL C与一个ASIL A，将其标记为“ASIL C（D）”与“ASIL A（D）”。
如果ASIL C(D)另外分解为一个ASIL B与ASIL A，这里仍然标记该ASIL的安全目标为“ASIL B（D）”与“ASIL A（D）”。
标记为D的原因是该ASIL是由一个功能要求ASIL D分解而来的，同时其分解之后的结果虽然低于原功能安全等级，但是其功能安全的确定、检查流程均按照ASIL D等级的要求执行，其他的等级要求相同。
- 用户评论