Skip to content

Latest commit

 

History

History
367 lines (225 loc) · 30 KB

4-Functional-Safety-Concept.md

File metadata and controls

367 lines (225 loc) · 30 KB

1. Introduction

Video

我再次强调一下功能安全的终极目标,那就是通过把风险降低到可接受水平来避免安全事故。

  • 首先,我们要知道哪些子系统确实具有高风险等级
  • 以及我们需要做什么来预防事故发生。

我们来看一下架构设计中的各个项目,大家需要总结出要达到安全目标哪些子系统和元素将会被涉及到。还需要进一步细化这些高层级目标,把它们转化为我们所说的“功能安全要求”。

然后,我们再把这些功能安全要求放到我们架构中的合适位置上。

我们把这些信息抽取出来总结到一个文档中,称为功能安全概念文档。

当我们继续沿着V模型的层次向下移动时,你可能会开始识别一个模式;您将继续识别新的需求,然后将这些需求分配到项目体系结构的不同部分。

Attributes of a Functional Safety Requirement 功能安全需求的属性

首先,在所谓的功能性安全需求中细化安全目标。记住,需求定义了车辆需要做什么;换句话说,需求定义了车辆的功能

您需要将这些安全需求分配到系统图的相关部分。分配意味着定义系统架构的哪个部分将实现哪个需求。这可能涉及使用新的元素块扩展系统架构。

然后,您将细化系统架构以处理新的需求。功能安全要求也有一些属性需要在功能安全概念中指定:

  • the ASIL level ASIL水平
  • 容错时间间隔,用来度量系统对危险情况作出反应的速度
  • 安全状态,讨论系统在避免事故后的样子

我们还将讨论检测和验证,这是如何证明一个系统实际上满足您的需求。所有这些信息都将纳入功能性安全概念。

Scope of the Functional Safety Concept 功能安全概念的范围

本节课将介绍如何创建功能性安全概念,下节课将重点介绍一个称为技术安全概念的文档。

功能安全概念和技术安全概念相似之处在于,您将需要识别新的需求并将这些需求分配到系统图中。不同之处在于,功能安全概念是从更高的层次来看待项目。在技术安全概念中,您将开始考虑传感器、控制单元和执行器。技术安全要求是一般的硬件和软件要求,但仍然没有涉及具体细节。例如,在技术安全概念中,您可能意识到需要向系统添加更多的ECUs、传感器和额外的软件块。

在本节课中,您将看到功能安全概念并不涉及技术细节。

  • 功能安全概念着眼于项目的一般功能;
  • 技术安全概念着眼于项目的技术实施。

在实践中,开发这两个文档是一个迭代过程,其中新的功能需求可能导致新的技术需求,而新的技术需求又可能导致新的功能需求。

2. Functional Safety Analysis

在得出安全要求之前,我们先讨论一下故障(malfunction)。我们说过车道偏离警告和车道保持辅助的主要目的或功能是为驾驶员提供振动转向反馈和扭矩作为触觉反馈。我们有一个安全的目标来限制振荡力矩。

这有什么故障(malfunction)呢?一种方法是使用引导词。ISO 26262不提供引导词,但是公司经常使用这些作为指南的一部分。这个例子的一些引导词是:

  • NO
  • WRONG
  • EARLY
  • MORE
  • LESS

因此,在车道偏离警告的情况下,“MORE”似乎是一个合适的引导词;车道偏离警告产生的扭矩超过了(MORE torque than)安全扭矩。会有两个故障。振荡幅度过大,振荡频率过大。形式上,故障为:

  • “车道偏离警告功能应用具有非常高扭矩幅值(超过限制)的振荡扭矩。”
  • “车道偏离警告功能应用非常高扭矩频率的振荡扭矩(超过限制)”

对于车道保持辅助功能,“NO”是一个合适的引导词。车道保持辅助使车辆保持在车道的中心。故障将是辅助系统没有时间限制。故障是:

  • “车道保持辅助功能不受时间的限制,会导致自动驾驶功能的误用。”

注意,功能安全分析中的信息来自于危害分析和风险评估。虽然这个练习看起来很简单,但是想象一下有数百个功能,每个功能都有不同的故障。引导词有助于系统地分析功能和故障。然后将这些故障转换为功能安全需求。

3. Functional Safety Requirements

Video

现在回到我们的车道偏离报警例子中,我们从第一个安全目标来推导出一些功能安全要求。我们遇到的故障是方向盘的报警震动过于强烈,从这个故障我们可以得出一个安全目标,那就是车道偏离报警功能中的震荡扭矩需要被限制。对一个车道偏离报警系统来说,定义一个扭矩振幅最大值和一个最大频率是非常有用的。

从上述安全目标,我们可以为车道偏离报警系统定义两个功能安全要求:

  • 第一个功能安全要求是车道保持模块必须确保车道偏离震荡扭矩幅度小于最大扭矩幅度
  • 第二个功能安全要求是车道保持模块必须确保车道偏离震荡扭矩频率小于最大扭矩频率

注意我们这里的措辞 “必须(Shall)”,因为这些都是强制要求。现在回顾一下上面我们所做的工作,我们从一个要求限制震动的安全目标开始,通过分析我们的架构,得出两个新的安全要求来达到安全目标。最后我们得出车道辅助模块需要限制震荡幅度和振荡频率。

Lane Keeping Assistance Functional Safety Requirement 车道保持辅助功能安全要求

在车道保持辅助功能方面,出现故障的原因是没有时间限制,驾驶员可以把系统当作是专为自动驾驶设计的。我们确定了一个安全目标,即“车道保持辅助功能应该是有时间限制的,额外的转向扭矩应该在给定的定时器间隔后结束,这样驾驶员就不会滥用系统进行自动驾驶”。换句话说,车道辅助系统应该在一段时间后停止施加额外扭矩。

在这个例子中,我们仍然可以满足安全要求,只要添加功能到动力转向ECU。对于车道保持辅助功能,我们将定义一个新的要求,即“电子动力转向ECU应确保车道保持辅助扭矩只适用于Max_Duration”。

Safety Analysis Methods 安全分析方法

我们使用了一些基本逻辑来从安全目标派生出功能安全需求。还有一些更正式的方法来推导功能安全需求。这些方法不仅适用于功能安全,而且适用于一般的系统工程。在功能安全方面,这些方法可以在多种情况下使用:

  • Deriving safety requirements 推导安全要求
  • Identifying conditions and causes that could lead to requirement violations 确定可能导致违反需求的条件和原因
  • Identifying other hazards not identified in the Hazard Analysis and Risk Assessment 识别在危害分析和风险评估中未识别的其他危害

Different companies might use different methods including:

  • Failure Modes and Effects Analysis (FMEA)
  • Hazard and Operability Study (HAZOPS) Note that HAZOP differs from the other items here in that it is a technique that used to derive hazards similar to the methods used in ISO 26262 HARA .
  • Failure Modes Effects and Diagnostic Analysis FMEDA
  • Fault Tree Analysis (FTA)
  • Reliability Block Diagram
  • ETA

4. Allocation to the Architecture

Review 回顾

让我们重申到目前为止所做的工作。危害分析和风险评估导致两个安全目标:

  • 由车道偏离警告功能产生的振荡转向力矩应受到限制
  • 车道保持辅助功能时间有限,额外的转向力矩应在给定的时间间隔后结束,使驾驶员不能滥用系统进行自主驾驶。

然后,您从安全目标1推导出两个功能性安全需求:

  • 车道保持项应确保车道偏离振荡力矩幅值低于Max_Torque_Amplitude
  • 车道保持项应确保车道偏离振荡力矩频率低于Max_Torque_Frequency

对于安全目标2,您推导出了一个功能性安全要求

  • 即“电子动力转向ECU应确保LKA扭矩时间少于“Max_Duration”。

您的下一步将是找出这些需求在系统体系结构中的位置。

Allocation of Requirements to the System Architecture

现在,我们的车道偏离报警系统有了两个功能安全要求:

  • 第一个要求限制方向盘的振动频率
  • 第二个要求限制方向盘的振动幅度

现在,我们要决定车道保持系统的哪个部分将会负责执行这两种限制。车道辅助模块包括三个子系统,摄像头系统、显示系统以及电子助力转向系统。

我们来看一下架构图,从逻辑上。我们可以说摄像头子系统和电子转向子系统都可以来限制频率和幅度。

例如,我们可以设定摄像头子系统请求的震动扭矩必须低于某个阈值,或者我们也可以设定助力转向子系统输出的震动扭矩必须低于该阈值

但是,只要有可能,我们还是想要尽力降低复杂度,简单点的解决方案是我们只要求助力转向子系统来限制震动,对于摄像头子系统不做要求。

这样的话,从功能安全角度来看,相关的子系统就只有一个助力转向系统,这样车道偏离报警功能可以很简单地加入我们的架构设计中。

与其相关的用来限制震动报警的元素只有电子助力转向ECU,我们把两个相关功能安全要求放在助力转向ECU中。我们还要稍微调整一下措辞,以前我们说车道保持模块用来限制震动扭矩。

现在,我们可以更加明确地说助力转向ECU将会限制震动扭矩。这里是最终的安全要求:

  • 功能安全要求1:电子助力转向ECU必须确保车道偏离报警的震荡扭矩幅度小于最大扭矩幅度
  • 功能安全要求2:电子助力转向ECU必须确保车道偏离报警的震荡扭矩频率小于最大扭矩频率

我们可以把结果放在一个表格中,注意,这里我们用的是一个简化了的例子。实践中更常见的是一个功能安全需求会涉及到若干个子系统。

5. Architecture Refinement

Video

下面我们将把所有的额外功能写入我们的架构图表中,这是我们最初的系统架构图

下面我们来给三个子系统添加更多细节,汽车显示子系统会需要额外的软件块,一个软件块控制指示灯,告诉司机车道保持模块处于打开或者关闭状态。第二个软件块控制另一个指示灯,告诉司机车道偏离报警是否处于激活状态。

摄像头子系统需要两个软件块,一个用来感应车道,另一个用来发送扭矩请求给电子助力转向子系统。

电子助力转向子系统需要三个软件块,第一个用于侦测司机转动方向盘的角度大小。第二个软件块从摄像头子系统接收震动扭矩请求。在这个软件块中,我们会完成限制震荡幅度和频率的工作。 第三个软件块将把这些扭矩请求加在一起,输出一个最终的扭矩给马达,然后马达再驱动转向轮。

现在,我们已经推导出功能安全要求,并把这些要求加入到我们的系统架构图中,在下面步骤中我们会在架构图上标示出风险级别。

Lane Keeping Assistance Function 车道保持辅助功能

那么车道保持辅助功能呢?现在,我们还可以假设车道保持辅助功能将是我们已经添加到系统架构中的车道保持软件块的一部分。然而,并不是所有的需求都需要软件块。例如,需求也可以通过机械系统来解决。通常,实现机械解决方案比使用软件更容易。

6. ASIL Inheritance

Video

我们需要给细化的架构图添加 ASIL 标签,如果不这样做,我们就不知道哪个子系统或模块需要使用 ISO 26262 来进行分析。这里一个通用的规则是功能安全要求直接从安全目标继承 ASIL 级别。

从危害分析和风险管理出发我们得出车道偏离报警的安全目标是扭矩需要限制,我们决定把上述安全目标标为ASIL C。这样车道偏离报警相关的两个功能安全要求会继承该值,即ASIL C。

因为我们把这两个功能安全要求放在电子助力转向中,整个电子助力转向子系统也会继承ASIL C等级。

然而,车辆显示子系统中的摄像头对应的ASIL级别是什么?我们之前说过,从功能安全角度出发唯一相关的子系统就是电子助力转向系统。而这两个子系统,我们没有为它们定义任何功能安全要求 ,所以,我们把车辆显示子系统中的摄像头标记为QM。随便说一下QM意思是质量管理,架构图中标示为 QM 的模块无需进行功能安全分析,因为它们对应的风险已经处于一个可接受的级别。

现在我们快速总结一下我们目前完成的工作,

  • 我们从安全目标推出了功能安全要求
  • 我们细化了架构设计
  • 把功能安全要求加了进去
  • 此外,我们还为三个子系统定义了风险级别。

接下来我们会看看对于我们的任意系统元素是否还有别的方法来降低ASIL。

Electronic Power Steering SubSystem ASIL 电子动力转向子系统ASIL

我们没有直接讨论驾驶员转向传感器或驱动方向盘的电机。我们简化了标记为ASIL C的东西,即使功能安全要求只适用于动力转向ECU。

驱动方向盘的电机也将被标记为ASIL C,因为它是确保车道辅助扭矩不会产生不安全条件的一个组成部分。从危险和风险分析来看,你可以认为整个车道保持项目有最高的ASIL,除非你可以证明其他。

记住,我们的例子是一个真实系统的简化。由于包含安全目标设计参数的安全要求,将会有与方向盘电机以及驾驶员扭矩方向盘传感器直接相关的功能安全要求。事实上,大多数汽车制造商会根据危害分析和风险评估为整个电子动力转向系统贴上ASIL D的标签。

7. ASIL Decomposition

Video

我们讲过,对于车道偏离报警功能,电子助力转向子系统的风险级别为ASIL C。尽管ASIL C并非最高的风险级别,但是相比更低的级别,此级别仍然需要很多额外测试和校验工作。

有什么方法可以降低架构中某些元素的风险级别吗?事实证明还是有办法的,该方法称为ASIL分解,假设我们系统中的某个功能模块被标示为ASIL D。如果我们为此模块实现两个完全互相独立的冗余系统,根据ISO 26262我们可以把每个冗余系统标示为 ASIL B。结果源于概率,如果单个系统的故障发生概率为0.8,那么两个互相独立的冗余系统均发生故障的概率会降低到0.8乘0.8 也就是0.64。冗余系统可以降低风险,创建独立冗余系统的收益何在?答案是相比ASIL D, ASIL B需要的分析和测试工作量更少。

根据参考标准,如果原始系统风险级别为ASIL D,那么冗余系统的风险级别可以标为 ASIL B(D)。

最常见的ASIL分解是把单个元素分解到安全相关和安全不相关的模块中,安全无关模块会标为QM,这样做好处是 ISO 26262 只会应用到安全相关所在部分。

我们来看个例子,比如我们想要分解助力转向ECU中的车道偏离报警软件块,我们会把最新的系统软件分为两个部分,一个软件模块包含完成正常功能的代码,然后,我们新建一个分离的软件模块负责我们的功能安全要求。现在我们再看看我们的系统架构图,电子助力转向软件块被标为ASIL C,使用ASIL分解方法后,负责正常功能的软件块被标为QM级别,负责故障处理的软件块被标为ASIL C级别。现在我们无需将ISO 26262应用到我们的正常处理软件块上。通过细化我们的架构以及决定ASIL级别,我们可以得出每个元素和子系统中的风险大小,然后应用分解法,我们可以降低架构中某些元素的风险级别。

System Diagram after ASIL Decomposition ASIL分解后的系统图

ASIL Decomposition ASIL分解

从某种意义上讲,将一个元素拆分为QM和ASIL C元素实际上提供了一些冗余。让我们说,在一些用户测试后,我们决定限制振动扭矩为$+/-3N\cdot m$。任何超过$+/-3N\cdot m$的值都是司机很难控制的。

也许我们会放入一个缓冲区,并说“正常车道辅助功能软件块”将要求扭矩为$+/-2.8N\cdot m$。“安全车道辅助功能”块的唯一工作是确保扭矩不超过$+/-3N\cdot m$。因此,您可以对“普通”块进行编程,使其仅在$+/-2.8N\cdot m$之间发出请求。然后,“安全”块将添加额外的检查,以确保请求不会超过$+/-3N\cdot m$。如果扭矩要求超过$+/-3N\cdot m$,安全软件块将假定系统出了问题。安全软件块可能不知道故障发生的原因或来源。但是安全软件块知道出了问题。

为什么“正常”块会要求扭矩超过$+/-2.8N\cdot m$?两个源,可能是软件错误或ECU硬件组件故障。也许电路短路也会引起故障。

ASIL分解的好处是,“正常”块只需要通过质量管理协议,它将具有接收和解释摄像机子系统信号的功能;否则,所有这些功能都必须经过额外严格的ASIL C测试。

Lane Keeping Assistance Example: ASIL Inheritance and ASIL Decomposition 车道保持辅助实例:ASIL继承和ASIL分解

车道保持辅助功能的软件块放在哪里?ASIL是什么?

让我们回到车道保持功能的安全目标和功能安全要求:从危害分析和风险评估来看,安全目标是“车道保持辅助功能应有时间限制,额外的转向力矩应在给定的定时器间隔后结束,使驾驶员不能滥用系统进行自主驾驶”。我们把这个定为ASIL B。然后我们推导出功能安全要求:“车道保持项应确保车道保持辅助扭矩仅适用于Max_Duration”。功能安全需求从安全目标继承了ASIL,所以这个功能安全需求也是ASIL B。

我们现在该怎么办?我们已经决定,车道偏离警告使车道辅助软件块为ASIL C,但我们也有一个功能安全要求与ASIL B相同的软件块。如果同一区块有两项安全要求,则以较高的ASIL值为准。所以最简单的答案是车道辅助软件块将有ASIL C。

ISO 26262中的规则是子元素应该继承最高的ASIL级别,除非您能够证明较低的ASIL子元素对较高的ASIL子元素没有影响,并且不会导致失败。这叫做共存准则。如果你能证明车道保持辅助软件不会影响车道偏离警告,那么你可以用ASIL C和ASIL B将功能分成两个块。

Criteria for Co-existence 标准共存

如果车道保持辅助软件单元中的故障对车道偏离警告软件单元没有影响,则车道保持辅助软件块可以为ASIL B;否则,车道保持辅助软件块需要ASIL C。

这种类型的故障称为级联故障,其中一个元素失败,然后导致另一个元素失败。通过仔细设计软件的数据和控制流,或硬件的输入/输出信号和控制线,可以避免级联故障。

在本节课中,我们假设车道保持辅助功能的失败不会影响车道偏离警告功能。

System Diagram after Adding Extra Safety Elements 添加额外安全元素后的系统图

以下是添加车道偏离警告和车道保持辅助安全元素后的系统框图:

8. Fault Tolerant Time interval

Video

功能安全概念的主要工作包括,抽取功能安全要求,并把这些要求体现在系统架构中。虽然现在本课程即将结束,但是我们仍然需要讨论与功能安全要求相关的另外三个属性:

  • 一是容错时间间隔
  • 二是报警和降级概念
  • 三是正确性验收标准的验证

我们从容错时间间隔开始讲起,我们需要定义每隔多长时间系统会去检测故障并对故障做出反应,这个时间段我们称之为容错时间间隔。拿我们的ADAS车道偏离报警作为例子,我们担心的一个方面是报警的震动幅度会不会太高,如果幅度过高,那么就发生了一个故障或者错误。系统的故障检测需要时间,相关信号也需要时间在硬件和软件中传递,这个间隔是一个诊断性测试间隔。一旦系统侦测到高振幅,那么它会关闭车道偏离报警功能,这同样也需要时间,也就是故障反应时间。一旦模块功能关闭,车道辅助系统就进入一种安全状态,在此状态下,该模块的风险等级是可接受的。我们期望的是车道辅助系统能够在事故发生前进入安全状态,这样在系统到达安全状态和可能的事故发生时间点之间有一段缓冲时间。因此,容错时间间隔等于诊断检测间隔加上故障反应时间再加上事故发生前的安全状态时间

每一个安全要求都有一个容错时间间隔,我们可以假设车道偏离报警系统的容错时间间隔为50毫秒,大家也可以把这个时间间隔用于我们已经讨论过的两种功能安全要求上,这个值只是一个示例值。在实际的应用中,容错时间间隔可能设定为别的值,通过容错时间间隔,我们可以知道车辆需要多长时间来对故障做出反应。

Measuring Fault Tolerant Time Intervals 测量容错时间间隔

根据危险情况,您可能还必须考虑人类驾驶员的故障反应时间。因此,您必须同驾驶员使用实际程序运行测试,以查看他们需要多长时间才能对故障做出反应并避免危险的情况。

另一方面,软件和硬件诊断测试间隔和故障反应时间可以通过台架测试来测量。

你无法改变一个人的错误反应时间;但是,您可以优化您的软件和硬件,以最小化诊断测试间隔和故障反应时间。无论在何种危险情况下,容错时间间隔的概念都是研究系统在发生故障时需要多长时间才能避免事故

ISO 26262 Revisions ISO 26262修改

ISO 26262的第二个新增功能正在进行中,可能会重新定义这里介绍的一些FTTIs。

Fault Tolerant Time Interval: Lane Keeping Assistance Fault 容错时间间隔:车道保持辅助故障

在车道保持辅助方面,令人担心的是功能没有时间限制。如果车道保持协助超出了我们设定的时间限制,则故障发生后,您将需要关闭系统。

容错时间间隔可能是500毫秒,因为这种情况比警告系统的情况更容易控制。因为系统现在是有时间限制的,驾驶员将不能像用自动驾驶一样滥用系统,而且更有可能一直把手放在方向盘上。如果车道保持辅助功能超过时间限制,它将继续将车辆转向车道中心,那么驾驶员仍然可以控制车辆。车道辅助系统只是在驾驶员已经提供的扭矩基础上增加额外的转向扭矩。

9. Warning and Degradation Concept 警告及降级概念

Video

对于每一个功能安全要求,我们需要讨论一下当故障发生时如何向司机发出警告。对于车道辅助模块的故障,我们会在司机的仪表盘上显示一个警告。如果方向盘ECU收到一个震动扭矩请求,请求值大于最大限值,警告灯将会亮起。

这是一个更新了的系统架构图,已经把警告灯包括在内。注意,我们添加了一个从电子助力转向 ECU 到驾驶显示子系统的连接。我们还需要描述出故障发生后车辆系统应如何反应,故障发生时系统应该切换到一种低风险级别的状态,我们称之为安全状态。我们已经讲过,当违反某个安全要求时车道偏离报警功能和车道保持系统功能均会关闭。我们可以认为关闭某个子系统就是将其调至安全状态,让其处于可接受的风险级别中。

报警和降级概念涉及到当子系统功能受限或者完全关闭时如何向司机发出警告,如何把车辆转入安全状态,以及如何从安全状态恢复。

车辆的使用手册也应该包含上述的报警和降级等相关内容。对于车道保持辅助功能,手册上或许会包括一个警告。警告内容是该功能并不意味着完全自动的驾驶,司机仍然负有安全驾驶的责任。

Summary of Warning and Degradation Concept 警告和降级概念概述

在功能安全中,“概念”与“文件”同义。因此,警告和降级的概念将是一个文件,讨论:

  • 如何提醒司机发生故障
  • 系统将做什么来“降级”功能,即把系统带到一个安全的状态,也从一个安全的状态恢复。

对于车道辅助项,我们讨论了当系统发生故障时,司机将在仪表板上看到一个警告灯。关闭系统会降低车道偏离警告和车道保持辅助功能。换句话说,来自车道保持辅助的扭矩请求将被设置为零。

Gradual Degradation versus Turning a System Off 逐渐退化还是关闭系统

然而,完全关闭系统并不是唯一的选择。一些系统可以提供有限的功能,并根据故障的严重程度“降级”到不同的级别。汽车发动机控制系统就是一个例子。如果一个传感器发生故障,发动机控制系统可能会降低电机的扭矩输出,这样车辆仍然可以以较低的速度行驶。

车道偏离警告系统对驾驶车辆并不重要。所以如果系统出现故障,我们可以关闭系统;另一方面,一个运转良好的马达是驾驶汽车所必需的。将电机系统降级到一个更安全、但运转正常的状态,将有助于司机避免陷入困境。

Warning and Degradation Concept in the Final Project 最终项目中的警告和降级概念

在final project template文件夹中,有一个功能安全概念模板文件。在文件的末尾,你会看到一个空的数据表,它的头信息如下:ID、降级模式、降级模式触发器、调用安全状态?,司机警告。你将负责填这张表。退化模式描述车辆在发生故障时如何被带到安全状态。对于车道偏离警告功能,退化模式是关闭该功能。对于车道保持辅助功能,退化模式相同。

什么将触发降级模式?你们已经学过的故障。是否调用了安全状态?是的。

驾驶员警告栏讨论如何就故障向驾驶员发出警告。

10. Verification and Validation Acceptance Criteria 检验与确认验收标准

Verification and Validation 验证和确认

在某种程度上,你需要证明你的安全要求确实得到了满足。在validation, verification and testing期间,您将在V模型的右侧执行此操作。

但是在功能安全概念中,您可以指定稍后将用于verification, validation and testing功能安全需求的标准和方法。

例如,我们为车道偏离警告功能中允许的最大振幅设置了一个限制。对于我们最终选择的最大扭矩幅值,我们需要validate我们选择了一个合理的值。我们需要测试驾驶员对不同扭矩振幅和频率的反应,以证明我们选择了一个合适的值。

一旦我们validate了我们的选择,然后我们需要verify是否满足安全要求;当转矩幅值超过极限时,在50 ms容错时间间隔内将车道辅助输出设置为零。对于这个特定的情况,我们可能会做一个软件测试,将一个错误插入到系统中,看看会发生什么。

对于车道保持辅助功能,我们必须测试并validate所选择的max_duration确实阻止了驾驶员把手从方向盘上拿开。然后,我们将verify如果保持辅助的车道每次都超过max_duration,那么系统确实关闭了。

What is the difference between verification and validation?

You verify, for example, that the lane departure warning vibrates the steering wheel at the amount you specified in your safety requirements. You validate that the vibration warning amount is neither too high for a driver to handle nor too low that the driver cannot feel the vibration.

12. Summary

Video

我们已经在功能层面定义了安全需求,并把这些需求放在我们的架构中。现在我们了解了每一项中包含的风险级别,我们为每一项添加了额外的功能以确保该项以一种安全的方式来完成工作。下一步,我们会从技术角度来分析安全需求。例如,我们讲过需要限定转向盘的振幅和频率,但是,我们具体使用什么软硬件来完成限制震动的工作?要确保功能安全我们需要哪些软硬件?在下一课中我们会进一步讲解功能安全要求和技术安全要求。

下面是一张图表,概述了我们到目前为止所涵盖的内容

在最后一个项目中,您将被要求记录下车道偏离警告故障和车道保持辅助故障的功能安全要求。你需要记住以下信息:

  • 功能安全需求及其属性(ASIL, Fault Tolerant Time Interval, Safe State, Verification and Validation Acceptance Criteria)
  • 具有更新架构的系统图(我们将为您提供此图)
  • 警告和降级概念,它解释了当故障发生时驾驶员收到的警告以及系统将如何关闭。