Aleeex_Zhao的博客

原创 AI Safety 之 AI Standard

Clause 6：AI within the context of road vehicles systems safety engineering 车辆系统中的AI系统，定义了AI系统的参考架构及风险行为的因果模型，以及与ISO 26262及ISO 21448之间的关系。仍在开发阶段，暂时还未正式发布，预计24年正式发布，目前手里的也是行业专家review版本，很多内容处于Work in Progress，待完善。

原创 激光雷达点云畸变补偿

而在这个bag文件里，是按行存储的，也就是先索引第一根线上的点，再第二根，依次类推，直到最后一根，这样的缺点是，我们无法通过这个来计算雷达实际扫描角度了，因为第一个点不一定是时间最早的点，如果第一根线前半部分被遮挡，那么你就会得到错误的计算角度，所以这时候，像我们这样直接强制把扫描角度设置成360度是更稳妥的，缺点就是它不够精确。畸变产生的原因是一帧点云中的点不是在同一时刻采集的，在采集过程中，雷达随着载体在运动，但是雷达点测量的是物体和雷达之间的距离，所以不同激光点的坐标系就不一样了。

原创 AI Safety 之 数据集

原创 ISO 21434 之 附录E 风险接受准则

将ODD内可合理预见的场景进行必要的划分，划分为若干个子场景，并论证，与有经验且专注的驾驶员相同，自动驾驶系统可以应对每个子场景，不会产生不合理的风险。对于每个危害行为事件，可从其属性出发，定义出定性或定量的安全度量准则对于自动驾驶系统，ODD内可合理预见的场景可能是复杂多样的，可能很难完整列举所有子场景，因此，还需要进一步论证，未能充分考虑的子场景（如，未知场景）下的风险以及已划分的子场景下的残余风险是否足够低。总体安全风险接受准则，将总风险控制在合理可接受的水平；

原创 ISO21434 之 V&V

根据公布的交通事故统计数据计算SOTIF建议的最小确认距离的示例；长期车辆测试/车队测试被选作确认方法；如果以必要的置信度满足了接受准则，可能没有必要通过驾驶里程等于或者超过B来证明达到了可接受的残余风险水平；

原创 ISO 21434 之 标准解读

Measures for functional restriction are aimed at maintaining a partial functionality by degrading (or limiting) the intended functionality. 通过施加限制，保留部分功能；只有可控性C=0或者严重度S=0，可以认为是absence of unreasonable risk；Analysis can start from:(正反两个方向)

原创 ISO26262 Part6 之 免于干扰FFI

想想软件分区之间的关系是一种信任，高级设备不信任任何低级设备，所以ASIL D可以从QM设备中读取，然而ASIL D设备应该尽可能减少QM设备的读数，ASIL D设备也可以写入QM设备，但QM设备却只能读取ASIL D设备，关键设备不应写入较高的ASIL设备。我们要讨论的最后一个干扰源是通信干扰,在车辆系统中软件设备需要交换电子控制单元之间的信息.即使发送者和接收者的ASIL相同,也有必要防止干扰.软件系统之间的通信渠道往往会有较低的ASIL或QM评级，受保护的通信通道将检测数据传输错误；

原创 ISO26262 Part6 之 软件测试安全汇总详解

如V model中所示，软件阶段包括：6-9 Software unit verification6-10 Software integration and verification6-11 Testing of the embedded software为了提高测试效率及合理性，可以对测试进行分组数据流的分析可以包括被0除，不可达的路径，死循环，数值越界等等价类：在连续的信号，如车速，可以分为低速，中速，高速，分别抽一个点来测试；边界值参考B

原创 ISO26262 Part10 之 Safety Element out of Context

步骤1a：对SEooC范围的定义-步骤1b：对SEooC安全要求的假设-步骤2：SEooC的开发-步骤3：工作成果-步骤4：SEooC集成到相关项。

原创 ISO26262 Part 10 之 Item, system, element, component, hardware part and software unit

系统(3.163)、组件(3.21)(硬件或软件)、硬件元器件(3.71)或软件单元(3.159)。：由一个以上硬件元器件(3.71)或一个到多个软件单元(3.159)组成的逻辑上或技术上可分的。：至少与一个传感器、一个控制器和一个执行器相关联的一组组件(3.21)或一组子系统。

原创 ISO26262 Part 9 之 DFA的输入确定方法

在进行DFA分析的时候，可基于演绎分析法,例如,割集检查或者FTA中重复的相同事件。,例如,在FMEA中多次出现的具有相似失效模式的相似元器件或组件。GB/T34590.11—2022的4.7。

原创 ISO26262 Part 9 之 ASIL分解的意义

5.4.11 The development of the decomposed elements at the system level and at the software level shall be performed, as a minimum, in accordance with the ASIL requirements (after decomposition) of ISO 26262-4 and ISO 26262-6. The development of the decompos

原创 ISO26262 Part 9 之 相关失效的的参考DFI/Coupling factor

同时ISO 26262-9:2018附录C中的表C.1从系统、硬件、软件和半导体从四个层面提供了一些可以参考的耦合因素示例。c. 环境免疫不足 Insufficient Environmental Immunity。e. 相同类型的组件 Components of Identical Type。b. 共享信息输入 Shared Information Inputs。g. 非预期接口 Unintended Interface。d. 系统性耦合 Systematic Coupling。

原创 ISO26262 Part 9 之 相关失效分析DFA/FFI的适用场景

用于证明分配了不同ASIL等级的，或者无ASIL等级和有ASIL等级的要素可以共存；：用于证明在进行ASIL等级分解时的独立性；

原创 ISO26262 Part 8 之 软件工具置信度

在系统或其软件要素，硬件要素开发过程中使用的软件工具，需要具备软件工具有效达到以下目标的置信度：– 在开发产品中，将因软件工具功能异常导致错误输出的系统性故障的风险减小到最低；软件工具的评估与鉴定活动应当在项目初期完成，至少在开发阶段之前，以免影响后续开发活动输出物的有效性，延长项目进度。分为3步：包括：– 软件工具的识别码和版本号；– 软件工具的配置– 软件工具的使用案例；– 软件工具的执行环境；– 当软件工具功能异常并产生相应的错误输出时，会直接违背分配给相关项或要素的全部安全要求的最高ASIL等级；

原创 ISO26262 Part 8 之 验证Verification

验证是ISO26262中关于成果认可最重要的环节。ISO26262对验证（Verification）的定义是检查对象是否满足特定的要求，验证的形式包括了验证评审（verification review）、走查（walk-through），检查（inspection）、验证测试（verification testing）、模拟仿真（simulation）、原型机验证（prototyping）和分析（analysis包括安全分析、控制流程分析、数据流分析等等）。

原创 ISO26262 Part 6 之 文档管理

应计划文档管理过程，以获得文档：– 用于在整个生命周期的每个阶段中有效完成各阶段及验证活动；– 用于功能安全的管理；– 作为认可措施的输入；

原创 ISO26262 Part 8 之 配置管理

1.确保工作成果、相关项、要素及其生产的原理和一般条件，在任何时间以可控的方式可被唯一识别和重生成；安全计划要求的工作成果及再生成相关项和要素所需要的工作成果，应按照。2.确保当前版本和较早版本的关系及区别时可追溯的；

原创 ISO26262 Part 8 之 分布式开发接口

1.定义客户和供应商在进行开发活动时的交互 和 上下游安全开发活动的依赖关系；2.描述职责的分配；3.识别相关项及其要素在进行分布式开发时需要交换的工作成果；

原创 ISO26262 Part8 之 内容架构梳理

Specification and management of safety requirements 安全要求的定义和管理。Confidence in the use of software tools 软件工具的置信度。Qualification of software components 软件组件鉴定。Configuration management 配置管理。Documentation management 文档管理。Change management 变更管理。Verification 验证。

原创 ISO26262 Part6 之 嵌入式软件测试

此活动的目的是提供证据,证明嵌入式软件可以在中满足其要求。

原创 ISO26262 Part 6 之 软件集成和验证

在此子阶段,按照软件架构设计,对软件要素之间特有的。软件要素的集成和验证的步骤直接对应着软件的分层架构。

原创 ISO26262 Part 6 之 软件单元验证Verification

需要对软件单元设计和已实现的软件单元进行验证，以证明：– 符合第8章有关单元设计和实现的要求；– 源代码与设计规范的符合性；– 符合软硬件接口规范– 确信没有非预期功能和特性；– 足够的资源支持其功能和特性；– 实施由安全导向分析得出的安全措施；

原创 ISO26262 Part 6 之 软件单元设计规范及原则

1. 标记法要求2. 单元设计原则

原创 ISO26262 Part 6 之 软件架构设计的验证Verification

a) 软件架构设计满足对应ASIL等级的软件安全要求;（架构设计本身）b) 软件架构设计的评审或研究能够为设计满足对应;（支持软件安全需求）c) 与目标环境的兼容性;注:目标环境是指软件运行的环境,包含了操作系统、基础软件以及在7.4.13中详细描述的目标硬件及其资源。d) 与设计指南保持一致。

原创 ISO26262 Part 6 之 软件架构设计颗粒度

总结：软件架构的设计应至少满足对软件安全需求的追溯和软件功能在软件组件层面的分解。软件架构设计并非追求越详细越好，应当在满足上述要求的前提下给予软件组件设计的灵活性，同时也能避免因为底层代码逻辑的修改给软件架构设计带来的反复变更工作。软件架构(3.1)中的最低层级且可被独立测试(3.169)的软件组件(3.157)。

原创 ISO26262 Part 6 之 软件架构设计内容

the software structure including its hierarchical levels;分级层次的软件结构the data types and their characteristics;数据类型及特征参数the external interfaces of the software components;软件组件的外部接口the external interfaces of the embedded software;嵌入式软件的外部接口the global variab

原创 ISO26262 Part 6 之 软件架构设计的描述方法

形式化规范就是用一套基于明确定义的数学概念的符号来书写，并且通常伴随着支持性的解释（非形式化）语句。这些数学概念被用来定义符号的句法和语义，以及支持逻辑推理的证明规则。支持形式化符号的句法和语义规则应该定义如何明确地识别其结构和确定其含义。并且必须有证据表明矛盾不可能产生，支持符号的所有规则都有定义或者引用。

原创 ISO26262 Part 6 之 软件安全需求的导出思路

那什么是软件安全需求？软件安全需求 = 安全相关的软件功能需求 + 软件安全机制应该考虑所需的安全相关的软件功能和特性，其失效可能违背分配给软件的技术安全要求：直接来源于分配给软件的技术安全需求；对软件功能和特性的要求（这些要求不满足可能违背分配给软件的技术安全需求）；软件安全相关的功能可以是：- 使标称功能可以安全执行的功能；- 使系统达到或者维持安全状态或降级状态的功能；- 与安全相关硬件要素故障探测、指示和减轻相关的功能；- 与操作系统、基础软件或应用软件本身失效探测、指示和减轻有关的自检或监控

原创 ISO26262 Part 6 之 软件活动语言及工具

在进行安全相关的软件开发时，对于开发语言和使用的工具也会有相应的要求，汇总整理如下：当选择一种设计语言、建模语言或编程语言时,应考虑准则：开发指南和环境需要明确项目开发者需要遵守的语言准则：

原创 ISO26262 Part 4 之 安全确认

前述验证活动(例如:设计验证、安全分析、硬件集成和测试、软件集成和测试、相关项的集成和测试)的目的是提供每项特定活动的结果的证据。对典型车辆上所集成的相关项的安全确认,目的是为预期使用的恰当性提供证据并确认安全措施对一类或一组车辆的充分性。安全确认基于检查和测试,为安全目标的实现提供了保证。此处相关的工作是需要由OEM来主导实施；

原创 ISO26262 Part 4 之 系统及相关项集成

整体上，测试目标分为以下4个方面，并在不同的层级进行实施：Case1： 功能安全及技术安全要求的正确实施;Case2： 安全机制正确的功能性能、准确性和时序;Case3：接口的一致性和正确实施;Case4： 足够的鲁棒性。

原创 ISO26262 Part 4 之 软硬件接口规范

为了定义软硬件接口(HSI),可以考虑下述软硬件接口(HSI)要素。软硬件接口规范规定硬件与软件的交互，应包括组件中由。

原创 ISO26262 Part 4 之 系统层面的安全分析

为系统设计的适合性提供证据，以证明其适合提供与ASIL等级相应的特定安全相关功能和特性。注3:在足以识别随机硬件失效和系统性失效的原因和影响的细节层面上进行分析。支持设计规范，并基于已识别的故障原因和失效影响验证安全机制的有效性；注1:安全相关特性包括独立性和免于干扰的要求。注4:演绎和归纳的方法结合使用的目的是提供。在系统架构设计阶段，需要进行安全分析，识别或确认安全相关系统要素和接口。如果有必要,采用定量分析。识别失效原因和故障影响。注2:这些分析的目的是。

原创 ISO26262 Part 4 之 安全机制的设计

技术安全需求需要定义安全机制，以便探测故障并防止或消除系统输出违反功能安全需求的失效。(例如:数据接口、通信总线、无线射频链接)的探测和控制的安全机制。示例:外部设备包括其他的电控单元、电源或者通信设备。注3:可以在系统架构适当的层级定义安全机制。涉及探测，指示和控制与本系统有相互影响的。的探测，指示和控制相关的安全机制。(如果适用)的系统自身监控。中所发生故障的安全机制。使系统实现或维持相关项。

原创 ISO26262 Part 4 之 系统层面开发的主要任务

到了系统层面，其主要的安全开发活动及相互之间的关系整理如下：

原创 ISO26262 Part 4 之 内容架构梳理

第四章主要是系统层面的安全活动，主要分为以下3个大的小节，围绕展开。

原创 ISO26262 Part 3 之 功能安全概念要点

a)故障避免;b)故障探测、对故障或其导致的功能异常表现的控制;c) 过渡到安全状态,及如果适用,过渡出安全状态;d) 故障容错;e) 故障情况下的功能降级,及其与f)或g)的交互。示例:将车辆保持在跛行模式,直到点火开关从“开”切换到“关”。f) 将风险暴露时间缩短到可接受时间所需的驾驶员警告;g) 增加驾驶员可控性所需的驾驶员警告(例如,发动机功能异常指示灯、ABS故障报警灯);h)如何满足整车层面的时间要求(即,如何定义故障处理时间间隔来满足故障容错时间间隔);

原创 ISO26262 Part 3 之 Occurrence与Frequency的区别

一个因素是以何种频率、多长时间暴露在危害事件的运行场景中；简化成运行场景发生概率的度量。，以控制或减少随机硬件失效的概率，并且避免系统性故障；同样的，在SOTIF的hazard 分析中，也有。针对风险R，可以描述为一个包含三个参数的函数。发生率反映了功能在运行阶段遇到触发条件的概率；，以及所产生伤害或损坏的潜在严重度。通过E、S、C确定的ASIL等级，一般来说，触发条件不独立于场景，，这在HARA中不考虑；

原创 ISO26262 Part 3 之 暴露度Exposure的确定

第一种是基于场景的持续时间, Duration，,暴露概率按照场景的持续时间分级,暴露概率通常根据所考虑的场景下花费的时间与总的运行时间(如上电)的比值来估算。第二种是基于场景发生的频率，Frequency；一个合适的例子是,在这些情况下,场景发生后的很短的时间间隔内,危害的暴露概率(E)可通过两种方式进行预估。