ADAS/AD相关标准翻译 - SOTIF

2019-08-30 21:58:36·  来源:汽车功能安全  
 
文章转自知乎,作者:我爱露营车前言翻译翻译SOTIF(预期功能安全)吧!正文引言车辆行驶安全是整个汽车工业最关心的问题。近年来,汽车中新增了大量更先进的功
文章转自知乎,作者:我爱露营车
 
前言
翻译翻译SOTIF(预期功能安全)吧!
 
正文
 
引言
 
车辆行驶安全是整个汽车工业最关心的问题。近年来,汽车中新增了大量更先进的功能。这些功能被集成到整车电子电器系统,依赖感知、复杂的算法和执行装置来运行。
 
比较合理的汽车安全等级是做到避免不合理风险。ISO26262-1定义了如何避免因电子电器系统故障导致的不合理的安全风险。ISO26262-3详细描述了危害分析与风险评估(HARA)方法来确定整车级危害。该方法主要用来评估因相关项失效导致的潜在风险,并定义顶层安全需求,例如安全目标、减轻风险的必要性等。ISO26262其他章节主要提供需求和建议,来避免并控制那些能影响到安全目标的随机硬件失效或系统性失效。
 
对于那些依赖感知内外部环境的系统,可能会遇到潜在的、ISO26262没有包含的系统失效行为,包括系统预期功能失效,或者性能限制等。例如:
 
· 功能无法正确理解场景信息,导致系统无法安全的运行,例如机器学习这种黑盒子算法。
 
· 因传感器输入变化或不同环境条件造成的功能鲁棒性不足。
 
SOTIF的主要目的是为了规避那些因功能限制导致潜在危害行为发生的不合理风险。ISO26262功能安全和SOTIF在关于Safety主题上是互补的。
 
为了实现SOTIF,需要实施以下几个阶段的活动:
· 设计阶段的措施,例如传感器性能的需求。
· 验证阶段的措施,例如技术评审、相关场景覆盖率高的测试用例、潜在触发事件的(错误)注入测试、相关用例的SOTIF在环测试。
· 确认阶段的措施,例如长期的仿真测试、车辆测试和路试。
 
用户对功能本身、功能行为、功能限制(包括HMI)的正确认知是保证安全的关键。
 
在许多案例中,一些触发事件是导致潜在危害行为发生的关键;因此,这些触发事件在特定用例中分析危害就显得非常重要。
 
本文档对于危害的定义,是指因某个触发事件导致系统出现潜在危害行为。这里的触发事件,既包括车辆正确操作,也包括一些合理可预见的车辆误操作。例如,在使用L2节自动驾驶功能过程中,驾驶员出现分心。
 
另外,合理可预见的误作用(直接导致潜在危险系统行为)也可以考虑成一种可能的触发事件。
 
利用车辆的安全漏洞对车辆进行网络攻击也能产生非常严重的后果(例如数据和身份被窃、隐私侵犯等)。尽管网络安全也可能导致潜在危害行为发生。但是本标准并不涉及安全(security )问题。【PS:作者注,网络安全是外部攻击导致的安全问题,英文单词能说明问题,security 。功能安全和预期功能安全是针对自身问题导致的安全问题,注意英文单词safety】
 
ISO26262主要是解决电子电器系统的随机硬件失效和系统性失效。而SOTIF则是ISO26262的补充。


1 范围
预期功能的实际功能表现不足,或人类合理可预见的误作用,都会导致危害的发生。为了避免以上危害造成的不合理风险,我们提供了各种实用设计、验证和确认措施的方法论和文档,并称之为预期功能安全(SOTIF)。本文档不适用于ISO26262所涵盖的故障,也不适用于因系统技术直接形成的危害(例如激光雷达灼伤人眼)。
 
本文适用于对安全至关重要的态势感知的预期功能性。态势感知依赖于复杂的传感器和感知算法,尤其是紧急介入系统(例如AEB)和其他ADAS系统。当前版本的SOTIF可以用于更高级别的自动驾驶,不过可能需要其他措施的支持。对于现有的、发布时已经制定了可靠设计、验证和确认措施(例如动态稳定控制系统DSC、安全气囊系统)的成熟系统,本文档不适用。如果有一些创新功能,是基于复杂传感器和算法中提取的感知信息来保持运作的话,本文档可以适用此类系统。
 
在识别危害时,应综合考虑以下两种潜在危害系统行为的发生:预期作用;合理可预见的误用。其中,合理可预见的误用这种危害,一般认为属于SOTIF相关危害,会导致直接的潜在的具有危害性的系统行为发生。有意更改系统操作的行为被视为功能滥用,不属于SOTIF的谈论范围。
 
2 引用标准
 
以下文件的部分的或全部内容构成,会被本文引用。关于引用文件,凡是注明了日期的,表示仅引用的版本适用;凡是未注明日期的,表示最新版本(包括任何修正版)适用:
ISO 26262-1:2018, Road vehicle —— Functional Safety Part 1:Vocabulary
 
3 术语及定义
ISO26262-1:2018中给出的术语及定义,在本文件中适用。
国际标准化组织(ISO)和国际电工委员会(IEC)在以下地址维护标准化术语数据库:
— ISO online browsing platform : available at iso.org/obp
— IEC Electropedia : available at electropedia.org/
3.1 Action(行动):某个场景中,执行者需要执行的最小原子行为。方案描述主要由动作/事件和场景的时间序列组成。例如:自车触发应急灯。
3.2 Erroneous Pattern(错误方式):触发意外行为的输入。
3.3 Event(事件):发生在特定地点和特定时间点的遭遇。
注释1:按时间顺序排列的动作/事件和场景(scenes),组成了情景(scenario)。
注释2:本文会涉及到触发事件和危害事件的概念。所谓危害事件是指危害(由故障引起)和特定操作状态的组合。
例1:车辆前方街道50米处,一棵树倒了。
例2:在某时某分,交通信号灯的绿灯亮了。
3.4 Functional Improvement (功能性优化):对一个功能/系统/元素规格进行修改,以减少风险。
3.5 Intended Behavior (预期行为):预期功能的特定行为,包括相关项的交互行为
注1:有关预期行为规范的更多信息,请参见第5条。
注2:该指定行为是指功能开发人员认为是正常(即无故障)的功能,由于零部件和技术的固有特性,导致能力受到限制。
3.6 Intended Functionality (预期功能性):一个系统的特定行为
3.7 Misuse (误作用):人们对某个系统进行非系统制造商本意的使用。
注1:因对系统性能过分自信导致的误作用;
注2:误作用不包括人们故意修改系统导致的系统行为。
3.8 Misuse Scenario (误用情景):误作用发生的情景
3.9 Performance Limitation (性能限制):预期功能在实现层面的不足
eg: 情景感知的不完整,决策算法的不足,执行器的性能不足等
3.10 Safety Of The Intended Functionality (SOTIF):规避因预期功能的功能性不足或人员的合理可预见误用导致危害发生的不合理风险。
注1:正常性能包括预期功能和预期功能的实现,这些功能可能会受到性能限制或人员可预见误用的影响。
3.11 Scenario (情景):一系列场景(scenes)随时间演化形成的场景序列,叫情景。


注1:每个情景都始于一个初始场景。行动和事件,以及目标和数值,可用来描述情景的时序发展关系。与场景相比,情景会跨越一定时间。
PS:个人理解,scenes场景是个空间概念,而scenario情景是scenes加时间维度。


 


3.12 Scene (情景):环境快照,包括风景、动态元素和所有参与者和观察者的自我表达以及这些实体之间的关系。
注1:见图4.
注2:只有仿真世界中的场景才可以是全方位的(如:客观场景或真实场景)。在真实世界中,不论从一个或几个观察者的角度看(如:主观场景),场景都是不完整的、不准确、不确定的。
注3:


3.13 Situation (情境):在特定时间点选择适当的行为模式。
注1:情境是所有相关条件、选择和行为决定因素的结合。情境是通过场景衍生过来的,这种派生行为既基于短期的信息选择和增强过程,也基于长期的目标和价值。因此情境总是主观的,它代表了一个元素观点。
注2:


3.14 test case (测试用例):确定系统是否根据其预期功能正常工作的一组条件。
注1:测试用例需要一个逻辑情景,该情景的每个方面都有一组特定参数值,以及评估测试成功/失败的标准。
3.15 triggering event (触发事件):驾驶情景中一组特定条件的引发者,会导致危害事件后续系统反应。
例:在高速公路上驾驶车辆时,车辆的AEB系统误将一个路标识别成一辆前车,且导致车辆在几秒内以几g减速度刹车的行为。
3.16 use case (用例): 通用应用领域的规范,可能包含有关系统的信息如下:
—— 一个或几个情景;
— 功能范畴;
— 期望的行为;
— 系统边界
注1:用例描述通常不包括用例的所有相关情景的详细列表。用更抽象的描述来表示该情景。
3.17 unexpected item behavior (意外行为):非预期的意外行为。
注1:在验证过程中能够发现非预期行为。
3.18 validation (验证):一组活动,使人们相信一个项目能够完成其预期的功能和任务。
分享到:
 
反对 0 举报 0 收藏 0 评论 0
沪ICP备11026917号-25