珠海企业建站,photoshop在线入口,网站地图文件,佛山淘宝设计网站设计价格摘 要
ISO26262道路车辆功能安全标准已经制定实践了多年#xff0c;主要目标是应对车辆的电子和电气#xff08;E/E#xff09;系统失效。该方法践行至今#xff0c;有些系统功能安全方法已经成熟#xff0c;例如电池管理系统#xff08;BMS#xff09;#xff0c;并且…摘 要
ISO26262道路车辆功能安全标准已经制定实践了多年主要目标是应对车辆的电子和电气E/E系统失效。该方法践行至今有些系统功能安全方法已经成熟例如电池管理系统BMS并且已经制定相应功能安全标准GBT 39086但是仍有很多人对标准的执行有模糊之处。为此我们用一个例子来说明功能安全整体方法。
1、导言
汽车系统虽然相对复杂但考虑其风险不得不被描述为安全关键系统除了功能要求外还必须满足安全要求。更具体地说安全要求描述了系统为了安全所必须具备的特征它是必须确保避免或减轻任何潜在不可接受的危险事件的关键属性。如果不遵守安全要求系统将面临各种可能危及用户安全的漏洞。因此在汽车系统的设计和开发过程中考虑安全要求以减少危险事件发生的风险是非常重要的。汽车行业已经在使用安全分析、验证和验证技术来提高车辆安全性。此外ISO 26262是一项功能安全标准它为汽车制造商提供了适当的开发流程、要求和安全完整性级别。
2、背景
ISO 26262是一项功能安全标准其主要目的是提供指南和最佳实践以提高车辆E/E系统的安全性。它涵盖了整个汽车安全生命周期包括规范、设计、实施、集成、验证和确认。ISO 26262侧重于E/E系统的危害及其相关风险。然后将相关风险指定为汽车安全完整性等级ASIL。ASIL可分为质量管理QM1、ASIL A、ASIL B、ASIL C和ASIL D其中ASIL D需要最高的风险降低工作。下表显示了ISO 26262中与本文相关的条款。
3、处理汽车系统功能安全要求的整体方法
ISO 26262标准主要考虑车辆的E/E系统对于机械、液压等其他系统仅在风险分析时作为原因考虑不能分配ASIL等级有企业分配了等级但笔者认为不尽可行。整体方法的基础过程包括七项主要活动。活动1, 2, 3、4和7分别基于ISO 26262条款C.3-4、C.3-6、C.3-7、C.4-6和C.4-9。活动5和6分别基于第C.5-6条和第C.6-6条。 1-项目定义是流程的第一项活动其目的是根据项目的主要功能、接口、已知危害、依赖性以及与环境的相互作用来定义项目。在我们的方法中该活动被扩展为考虑作为项目的一个组成部分的驱动程序即在项目的定义期间也考虑了驱动程序组件和项目的网络和物理组件之间的依赖关系和交互。该活动的结果是项目定义。
2-危险分析和风险评估HARA当项目定义被认为是完整的时可以开始。HARA活动可分为两个相关子活动1-危害分析其中项目定义用于识别可能的危害事件。由于驱动程序被视为项目的组成部分因此该活动应考虑可能由于其行为和与项目的其他组件的相互作用/依赖性而产生的危害。2-风险评估根据三个变量对已识别的危害事件进行分类。1-严重性衡量每个危险事件的潜在危害范围从S0到S3其中S0表示无伤害S3表示危及生命的伤害。2-暴露测量项目处于危险事件中描述的运行状态的概率范围从E0到E4其中E0表示最低发生概率E4表示高概率。3-可控性衡量通过相关人员的及时反应避免特定伤害/损害的能力范围从C0到C3其中C0表示一般可控C3表示难以控制或无法控制。
根据这三个参数为每个危险指定ASIL。ASIL是一种必要的风险降低措施其级别范围为QM、ASIL a、ASIL B、ASIL C和ASIL D其中ASIL D最高。然后按照ISO 26262的要求将至少一个安全目标SG3分配给ASIL A、B、C或D级危险。这些SGs可用于推导功能安全要求FSR其中规定了缓解其相应危险所需的功能。这项活动的结果是SGs。
3-功能安全概念该活动的主要目标是通过从SGs中推导FSR然后将FSR分配给项目的元素来发展功能安全概念。根据ISO 26262FSR是独立于实施的安全行为/安全措施的规范包括其安全相关属性。因此FSR用于定义物品的安全功能而不指定如何实现这些功能。与ISO 26262不同该活动应规定FSR并考虑驱动程序的行为特别强调其与项目其他组件的交互/依赖性这有助于在以后的活动中将FSR分配给项目的元素。
4-技术安全概念旨在从FSR中得出技术安全要求TSR。特别是FSR可能处于较高的抽象级别需要将其细化为更详细的技术需求。与活动4类似该活动应指定TSR以提供有关驾驶员行为及其与项目其他组件的交互/依赖关系的更详细信息。请注意完成整套TSR被认为足以确保该项目符合其功能安全概念。
5-硬件安全要求规范HWSR旨在从可分配给硬件的TSR中衍生出HWSR-HWSR是与项目物理硬件相关的安全要求。根据ISO 26262HWSR应包括与功能安全相关的每个硬件要求的信息包括安全机制的相关属性以a控制元件硬件的内部故障b 控制或容忍元件外部的故障c 遵守其他要素的安全要求以及d检测内部或外部故障并发出信号。此外应在该活动中规定该项目硬件元件的设计规范和验证标准。
6-软件安全需求规范SWSR旨在从可分配给软件的TSR中衍生出SWSR-SWSR是与项目软件功能相关的安全要求。根据ISO 26262SWSR应从TSR中衍生出来考虑到软件所需的安全相关功能和属性其故障可能导致违反分配给软件的技术安全要求。然后SWSR可用于定义软件设计规范。
7-安全验证旨在1-提供安全目标充分的证据2-提供在车辆级别实现安全目标的证据3-提供安全概念适用于项目功能安全的证据。
4、该方法在MAS示例中的应用
1.项目定义。
MAS的主要功能是当车辆以50 km/h以上的速度行驶时允许/防止驾驶员的预期/非预期操作动作。MAS依靠传感器收集有关驾驶员的信息提示
· 头部姿势和运动可用于识别驾驶员的视觉方向并预测一些驾驶员的动作例如头部运动可能先于动作
· 手/脚位置和运动可用于预测一些驾驶员的动作。此外MAS依赖于激光雷达和雷达它们可以提供有关周围车辆/物体的信息。此外MAS将包括一个软件系统该系统能够在适当的时间内分析所有提示信息以确定驾驶员的操纵是有意的即它是需求、欲望和/或动机的结果还是无意的即没有执行此类操纵的需求、欲望和/或动机。最后MAS依靠锁执行器来防止驾驶员的意外操作。
2-危害分析和风险评估。该活动有两个子活动
2.1-危险识别。它分析了项目定义主要关注项目组件的行为及其相互作用和依赖性可能导致的危险事件。已确定与MAS相关的两个主要危险
· H1当车辆以超过50 km/h的速度行驶时将预期操纵归类为非预期操纵这会阻止驾驶员执行预期操纵。
· H2当车辆以50 km/h以上的速度行驶时将非预期操纵归类为预期操纵从而允许执行非预期操纵。
2.2-风险评估。根据其严重性、暴露和可控性对每个已识别的危险进行分类。
H1的发生使驾驶员无法执行预期的操作这可能导致危及生命的伤害甚至死亡。因此选择最高严重性级别S3。选择暴露水平E3中等概率是因为有几个原因可能导致将预期动作归类为非预期动作例如关于头部姿势和运动、手/脚位置的错误信息提示。最后选择最高可控性级别C3因为驾驶员没有必要的时间执行任何纠正措施以避免潜在伤害。根据H1的严重程度S3、暴露E3和可控性C3确定该危险的ASIL C。
类似地H2的发生具有最高的严重程度S3因为允许进行非预期操作可能会导致危及生命的伤害甚至死亡。暴露水平为中等概率E3因为识别非预期的可能会由于错误的信息提示而出错。此外选择最高可控性级别C3是因为驾驶员可能不知道此类操纵无法执行任何纠正措施以避免潜在伤害/损害。因此ASIL C是针对这种危险确定的。按照我们的方法至少应为每个ASIL A、B、C或D级危险指定一个安全目标SG。为此我们分别为危险H1和H2指定以下两个安全目标SG1和SG2
SG1当车辆行驶速度超过50 km/h时不应阻止驾驶员进行预期操纵。
SG2当车辆行驶速度超过50 km/h时应防止驾驶员意外操纵。
3-功能安全概念。
根据之前活动中确定的SGs我们得出了相关的功能安全要求FSR。特别是我们从SG1中得出以下FSR
FSR1-1当车辆行驶速度超过50 km/h时应激活MAS。
FSR1-2MAS应能够收集所有相关线索信息以确定是否需要机动。
FSR1-3MAS应能够收集所有相关提示信息以确定驾驶员是否有进行机动的愿望或动机。
FSR1-4MAS应能够验证驾驶员的操作是否在适当的时间内进行。
FSR1-5MAS不应阻止预期的操纵。
根据SG2我们得出以下FSR
FSR2-1:MAS应能在适当时间内识别驾驶员的非预期操纵。
FSR2-2:MAS应防止意外操作。
4-技术安全要求。
本活动的主要目的是将之前活动中确定的FSR细化为更详细的技术要求。推导TSR的过程与从SGs推导FSR的过程类似但ISO 26262不要求每个FSR至少定义一个TSR-它只要求TSR应按照FSR进行规定。根据之前活动中确定的FSR我们得出以下TSR
TSR1-1.1:MAS应依靠可靠的传感器来识别车速并在车辆以高于/低于50 km/h的速度行驶时激活/停用MAS。
TSR1-1.2:MAS应依赖于可靠的技术如传感器、激光雷达、雷达以便预测所需的动机。
TSR1-1.3:MAS应取决于可靠的技术例如头部姿势和运动、手和脚的位置和运动以便预测预期和/或有动机的动作。
TSR1-1.4:MAS应能够在适当的时间内验证是否需要驾驶员的操作操作。
TSR1-1.5:MAS应能在适当时间内验证驾驶员的战术机动是否符合要求和/或动机。
TSR1-1.6:MAS不得阻止所需的操作操作。
TSR1-1.7:MAS不得阻止期望的和/或有动机的战术演习。
TSR1-2.1:MAS应依赖于可靠的技术允许识别不必要的操作动作。
TSR1-2.2:MAS应依赖于可靠的技术该技术允许识别非期望和/或无动机的战术机动。
TSR1-2.3:MAS应防止不必要的操作操作。
TSR1-2.4:MAS应防止意外和/或无动机的战术机动。
5.硬件安全要求HWSR规范。
在确定TSR列表后可分配给该项目物理硬件的TSR用于推导HWSR的规范。根据之前活动中确定的TSR考虑标准对于HWSR的要求我们得出以下HWSR
HWSR-001MAS的每个硬件组件如传感器、执行器、雷达等应通过其硬件安全要求和安全机制的相关属性来描述以控制内部故障。
HWSR-002MAS的每个硬件组件/与之相关的硬件组件应通过其硬件安全要求和安全机制的相关属性来描述以控制或容忍元件外部的故障。
HWSR-003MAS的每个硬件组件/与MAS相关的硬件组件应通过其硬件安全要求和安全机制的相关属性进行描述以符合其他元件的安全要求。
HWSR-004MAS的每个硬件组件/与MAS相关的硬件组件应能够处理其输入上的任何干扰/噪声。
HWSR-005MAS的每个硬件组件/与MAS相关的硬件组件的输出不允许出现任何意外信号。
HWSR-006MAS的每个硬件组件/与MAS相关的硬件组件应通过其硬件安全要求和安全机制的相关属性进行描述以检测和发出内部或外部故障信号。
HWSR-007应识别MAS硬件组件之间或与MAS相关的硬件组件之间的任何通信错误/丢失。
HWSR-008应通过诊断其输入/输出信号来识别由于错误、故障或故障可能导致的MAS的每个硬件组件/与之相关的任何异常行为。
HWSR-009MAS的每个硬件组件/与MAS相关的硬件组件应在符合其可能运行的真实环境的环境中进行测试。
HWSR-010MAS硬件组件之间的通信和依赖关系应在符合其可能运行的真实环境的环境中进行测试。
6.软件安全要求SWSR规范。
在确定TSR列表后可分配给项目软件功能的TSR用于推导SWSR规范。根据之前活动中确定的TSR同时考虑标准中SWSR的要求我们得出以下SWSR
SWSR-001:MAS应能够检测并适当传达从其相关组件如传感器、致动器、雷达等接收到的信号中的任何错误。
SWSR-002:MAS应能够检测从其相关组件接收到的信号中的任何延迟、丢失和损坏。
SWSR-003:MAS应能够检测其任何相关组件是否没有响应和/或在适当的时间内没有响应。
SWSR-004:MAS应实施缓解计划以适当处理从其相关组件接收到的信号中的任何错误、延迟、丢失和损坏。
SWSR-005:MAS应能够检测可能导致故障的相关组件中的错误、故障和故障。
SWSR-006:MAS应实施缓解计划以适当处理其相关组件中的错误、故障和故障以避免潜在故障。
SWSR-007:MAS应为每个错误、故障、故障等指定一个特殊代码以便于识别和区分。
SWSR-008:MAS安全相关软件功能和与及时响应相关的属性应在符合其可能运行的真实环境的环境中进行测试。
SWSR-009:MAS安全相关软件功能和属性例如对错误输入的鲁棒性、软件的容错能力等应在符合其可能运行的相同真实环境的环境中进行测试。
7.安全验证。
该活动的主要目的是确保安全目标充分且已在检查和测试的基础上实现并提供可靠证据证明已在车辆层面实现了确定的安全目标。这种验证只能在拟议系统的完整实现上进行这超出了本文的范围。在我们的方法中我们通过手动查看衍生的HWSR、SWSRs和SCSRs列表来验证结果如果适当实现这些列表可以满足TSR-反过来完成整套TSR被认为足以确保该项目符合其功能安全概念。
5、结论
我们讨论了一种基于ISO 26262标准的整体方法。我们根据其主要活动描述了该方法并通过将其应用于汽车领域的一个示例来说明这一方法。
未来基于车辆系统的有限性会有越来越多的系统按照这一方法规范化、标准化这也将给汽车功能安全工作带来莫大的支持。
