越来越懒了,好久没有更新了。今天看到新闻——黑豹去世了,那个才40出头的威漫英雄从此落幕。无论什么时候,健康的身体都是最重要的,在忙也别忘了抽时间锻炼身体哦!突然有一种建一个跑步微信群的想法,大家可以每天在群里打卡,通过这种方式,那些想锻炼却又坚持不下去的人慢慢的也可以养成习惯。本期接着聊一聊技术安全概念相关话题,一起来学习吧!
01
概述
在我们实际的系统开发过程中,了解和实现产品系统阶段的最先进设计是十分重要的(也就是老牌车企常说的state-of-the-art)。
我们知道技术安全概念是一个规范文档。那也就是说,技术安全概念 = TSRs+系统架构设计+设计限制。上一篇中已经谈过了前两个,今天我们继续聊一聊技术安全概念规范(图中红框部分)。
02
TSRs 规范
技术安全要求有4个主要的规范:
1- TSR应该根据相关项的功能安全概念和系统来确定,考虑下面:
相关项和相关项要素的安全相关的依赖性和限制性;
系统的外部接口;
系统的可配置性;
注意1:可以对硬件、软件、数据、操作程序、接口或系统的任何部分进行限制。比如:系统必须使用预定义的COTS硬件或者软件、使用特定的算法或实现特定接口协议的限制。它还可能包含非功能性的要求(例如性能要求,安全性)。
注意2:可配置性是指允许系统行为通过少量的用户输入而改变的质量。系统的可配置性越强,构建和修改就越容易。通过配置数据或者校准数据,现有的系统可以用于不同的应用。也就是说,硬件和代码没有变化。
2- 应结合每个可能的操作模式和系统状态,为每一个TSR规定系统或元素对刺激的响应。
比如:TSR = 对刺激的响应 + 操作模式 + 系统状态;
举个例子:当制动西戎的ECU报出车辆稳定性控制(VSC)功能在传动(drive-train)状态下的EV模式下不可用时,自适应巡航(ACC)ECU应该关闭ACC功能。
3- 明确或者指出系统或系统的要素的非功能性要求。比如:ECE标准;GB/T标准;FMVSS标准;公司的平台战略,功能概念或其他概念,如网络安全(CyberSecurity)。4- 技术安全要求和非安全要求不能互相矛盾。由于写下了非安全要求(或参考文献),任何矛盾的检测都是很容易被证明的。
03
安全机制
安全机制将在系统和ECU级别上被实现,我们可以下图的在D．4和D．9上为SbW用例演示一下安全机制:
(图片来自ISO-26262 Part5 Annex D)
安全机制有5种主要的规范,本篇只讨论一种:
1 -技术安全要求应该明确检测故障并防止或者减轻系统输出处出现的违反功能安全要求的故障的安全机制,包括:
a-与系统本身故障的检测、指示和控制有关的安全机制;
(注意:1-这包括系统自我监控,以检测随机硬件故障,并在适当情况下检测系统故障;2-这包括用于检测和控制通信信道故障的安全机制,比如数据接口、通讯总线、无线广播链路;3-安全机制可根据系统架构中的级别进行规定。)我们可以回顾下SbW的用例,见下图:
对于上面的架构,我们希望进行安全分析,目的是得出系统的软硬件故障。我们怎么做呢?通过FTA分析,我们将重点关注红色突出显示的方框和箭头,以证明在系统设计中产生潜在的系统故障,然后提供安全机制来检测和防止系统输出违反安全目标,请看下图:
在TSC的文档中,我们将列出基本事件的结果,潜在故障,并提出预防这些基本事件的安全机制,以避免顶级事件违反,该安全目标的表达为:SG01“EPS系统应在所有车辆运行条件下防止任何方向的意外自转向——ASIL D”。
下面的图片说明了处理单元“SbW控制器”和传感器“方向盘扭矩传感器”上衍生的系统故障和相应的安全机制:
b-与检测、指示和控制与系统相互作用的其他外部元件中的故障相关的安全机制。
示例:外部设备包括其他电子控制单元、电源或通信;
比如:应检测SbW外部电源的电压波动是否超过窗口阈值[0．3,4．8];
c-有助于系统实现或保持项目安全状态的安全机制;
注:这包括来自安全机制的多个控制请求和仲裁。
d-定义和实施报警和降级策略的安全机制;
e-防止潜在故障的安全机制;
QUES1:什么是潜在故障(latent fault)呢?
一种存在但在常规检测手段中隐藏的故障。也就是说,正常实施的安全机制没有检测到它。(注:26262中的解释是说,不能被驾驶员感知或者不能被安全机制检测到的多点故障就是潜伏故障)
QUES2:如何预防潜伏故障呢?
使用潜伏故障的安全机制。注:这些安全机制通常与在上电期间(驾驶前检查),如措施a——d,运行期间,下电期间(驾驶后检查),以及作为维护的一部分进行的自检有关。
