设为首页收藏本站

安徽论坛

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 67024|回复: 0

ISO PAS 21448 SOTIF(预期功能安全)笔记(一)

[复制链接]

83

主题

0

回帖

261

积分

中级会员

Rank: 3Rank: 3

积分
261
发表于 2022-3-26 10:31:39 | 显示全部楼层 |阅读模式
网站内容均来自网络,本站只提供信息平台,如有侵权请联系删除,谢谢!
(ISO PAS 21448中的1~3章节内容,涵盖预期功能安全的背景、介绍和重要术语)
笔记

1 Scope(范围)

1.定义: 不存在因预期功能不足或由于合理预见的人员误操作而造成的危险。
2.用途: 指导功能设计验证确认工作。设计阶段(例如,传感器性能需求)、验证阶段(例如,技术复查、相关场景高覆盖率的测试用例、潜在触发事件的注入、在环测试(例如SIL/HIL/MIL)中选定的SOTIF相关的用例)、确认阶段(长期的仿真测试和实车测试)。
3.范围:
(1)不适用于ISO26262中考虑的因系统故障导致的危害;
(2)不适用于现有系统的功能,这些系统在发布时已经有了完善和可靠的设计、验证和验证(V&V)措施,例如:DSG、安全气囊等;
(3) 适用于L1~L2的ADAS功能和更高级别自动驾驶系统;
2 List item Normative references(引用标准)

ISO 26262-1:2018, Road vehicles — Functional Safety Part 1: Vocabulary
3 Terms and definitions(术语和定义)

3.1 action(动作)
情景(scenes)中的任何参与者执行的原子性行为(原子性行为:要么执行成功,要么执行失败,不会存在中间状态);
例如:灯亮或者不亮
3.2 erroneous pattern(错误的模式)
可能触发意外行为的输入
3.3 event(事件)
在特定时间和地点发生的事情
例如:交通灯在XX:XX时刻亮起
3.4 functional improvement(功能改善)
对功能、系统或元素规范的修改以减少风险
3.5 intended behaviour(预期行为)
预期功能的特定行为,包括各组件之间的交互
注1:第5章节会更多描述预期行为的规范
注2:特定的行为是项目的开发人员认为是无故障的功能的行为,由于所使用的组件和技术的固有特性,它的能力存在极限

3.6 intended functionality (预期功能)
系统的执行行为
3.7 misuse(误操作)
操作者以非系统制造商所预期的方式使用系统
3.8 misuse scenario(误操作场景)
发生误操作的场景
3.9 performance limitation(性能极限)
预期功能实现不足
例如:场景感知不完整,决策算法不足,驱动性能不足
3.10 Safety Of The Intended Functionality(SOTIF 预期功能安全)
不存在因预期功能不足或由于合理预见的人员误操作而造成的危险
3.11 scenario(场景)
描述场面(scenes)序列中几个场面之间的时间发展

注1:每个场景都从一个初始场面开始。动作和事件,以及目标和数值,可以被指定来描述一个场景中的这个时间发展,与场面不同的是场景跨越一定的时间。


3.12 scene(情景)
环境的快照,包括风景、动态元素以及所有参与者和观察者的描述,以及这些实体之间的关系
注:只有在模拟世界中,场面的表示才能包含所有的内容(例如,客观场面或地面实况)。在现实世界中,场面是不完整的、不正确的、不确定的,并且是从一个或多个观察者的角度来看(例如,主观场面)

3.13 situation(情境)
在特定时间点选择适当的行为模式
注:一个情境包含了所有相关的条件、选择和行为的决定因素。情境是从情景中衍生出来的,基于瞬态的信息选择和增强过程(例如,任务细节),以及永久的目标和数值。因此,一个情境总是主观的,因为它代表了一个要素的观点。

3.14 test case(测试用例)
一组条件,以确定一个系统是否正在按其预期的功能工作
注:测试用例需要一个(逻辑的)场景,该场景的每个方面都有一组特定的参数值,以及评估它的通过-失败标准
3.15 triggering event(触发事件)
驾驶场景的特定条件,作为后续系统反应的引发因素,可能导致危险事件
例如:在高速公路上行驶时,车辆的自动紧急制动(AEB)系统将路牌错误地识别为前车,导致车辆以 g的减速度制动Y秒
3.16 use case(用例)
广义应用领域的规范,可能涉及系统的以下信息:


  • 一个或多个场景
  • 功能范围
  • 期望的行为
  • 系统边界
    注:用例描述通常不包括此用例所有相关场景的详细列表,而是使用了对这些场景的更抽象的描述。
3.17 unexpected item behaviour(意外的部件行为)
未规定的非预期行为
注:确认过程中可能会发现的意外行为
3.18 validation(确认)
对某一部件能够完成其预期功能和任务获取足够信心的一系列活动
注:验证(Verification)活动主要处理图7、8和9中的第2区域(已知的不安全场景);而确认(validation)活动主要处理图7、8和9中的第3区域(未知的不安全场景)。
要点总结

1.不断增加的功能依靠sensing, processing of complex algorithms and actuation implemented by electrical and/or electronic (E/E) systems(电子电气系统的感知、复杂算法的处理执行)。
2.通过感知内部或外部环境的系统,系统的预期功能或性能限制可能会导致潜在的危险行为。例如:a.功能不能正确理解情况和安全操作,包括使用机器学习算法的功能;b. 功能对传感器输入变化或不同环境条件的鲁棒性不足。
3.预期功能安全和功能安全的区别:功能安全考虑的是系统软硬件可能出现的故障;预期功能安全考虑的是预期功能考不足或合理遇见的误操作,所以,解决风险的措施是通过功能和规范的完善人机交互合理来实现。
4.scenario(场景)scene(情景)situation(情境) 的关系,参照标准中Figure 3。
5.**Verification(验证)validation(确认)**的区别,Verification活动主要处理图7、8和9中的第2区域(已知的不安全场景);而validation活动主要处理图7、8和9中的第3区域(未知的不安全场景)

参考文档:
ISO PAS 21448 Road vehicles — Safety of the intended functionality
我将进一步翻译并总结整个标准,请继续关注后续内容。。。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
免责声明
1. 本论坛所提供的信息均来自网络,本网站只提供平台服务,所有账号发表的言论与本网站无关。
2. 其他单位或个人在使用、转载或引用本文时,必须事先获得该帖子作者和本人的同意。
3. 本帖部分内容转载自其他媒体,但并不代表本人赞同其观点和对其真实性负责。
4. 如有侵权,请立即联系,本网站将及时删除相关内容。
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表