Posts

引言 在汽车功能安全的实施过程中，不同 ASIL 等级要求不同深度和严格程度的分析方法。ISO 26262-9 专门针对 ASIL A、B、C、D 定义了相应的分析方法要求。 想象一个真实场景：某汽车厂商的制动系统，虽然通过了 ASIL B 的 FMEA 分析，但系统仍然发生了严重的安全事故。事后调查发现，原因是 FMEA 分析不够深入，没有考虑某些极端的故障组合场景。 这个案例告诉我们：**ASIL 等级越高，要求的分析越深入、越全面。**这正是 ISO 26262-9 ASIL 导向的分析方法的核心使命。 ASIL 导向分析的目标和范围 ASIL 导向分析的核心活动 ISO 26262-9 定义了针对不同 ASIL 等级的分析要求： graph LR subgraph ASIL等级与分析方法对应关系 ASILA[ASIL A低安全要求] --> FMEA1[FMEA失效模式分析] ASILB[ASIL B中低安全要求] --> FMEA2[FMEA] ASILB --> FTA1[FTA故障树分析] ASILC[ASIL C中高安全要求] --> FMEA3[FMEA] ASILC --> FTA2[FTA] ASILC --> STPA1[STPA系统理论分析] ASILD[ASIL D最高安全要求] --> FMEA4[FMEA] ASILD --> FTA3[FTA] ASILD --> STPA2[STPA] ASILD --> SA[安全分析Safety Analysis] end style ASILA fill:#34C759,stroke:#34C759,stroke-width:2px,color:#ffffff style ASILB fill:#30D158,stroke:#34C759,stroke-width:2px,color:#ffffff style ASILC fill:#FFCC00,stroke:#FF9500,stroke-width:2px,color:#ffffff style ASILD fill:#FF3B30,stroke:#FF3B30,stroke-width:3px,color:#ffffff style FMEA1 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FMEA2 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FMEA3 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FMEA4 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FTA1 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FTA2 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FTA3 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style STPA1 fill:#AF52DE,stroke:#AF52DE,stroke-width:1px style STPA2 fill:#AF52DE,stroke:#AF52DE,stroke-width:1px style SA fill:#FF9500,stroke:#FF9500,stroke-width:2px ASIL A 分析 ...

引言 ISO 26262 标准提供了完整的汽车功能安全要求，但在实际应用中，如何正确理解和应用这些要求是一个挑战。ISO 26262-10 指南部分正是为了解决这个问题而设计的，它提供了详细的解释、示例和最佳实践。 想象一个真实场景：某汽车电子公司的工程师在实施 ASIL D 项目时，对于如何确定硬件架构指标（SPFM、LFM）存在困惑。不同的工程师有不同的理解，导致项目进展缓慢。 这个案例告诉我们：**需要详细的指南和示例来帮助正确理解和应用 ISO 26262 标准。**这正是 ISO 26262-10 指南部分的核心使命。 指南的结构和内容 指南的目的 ISO 26262-10 的主要目的是： 解释标准要求：详细解释 ISO 26262 各部分的要求 提供示例：提供实际应用的示例 分享最佳实践：分享行业最佳实践 解决常见问题：解决常见的问题和困惑 指南的内容 ISO 26262-10 包含以下内容： 概念阶段的指南 危害分析（HARA）的示例 ASIL 确定的示例 功能安全概念的示例 系统级开发的指南 系统架构设计的示例 技术 安全概念的示例 系统集成和测试的示例 硬件级开发的指南 硬件架构设计的示例 FMEDA 分析的示例 硬件架构指标计算的示例 软件级开发的指南 软件架构设计的示例 软件单元测试的示例 软件集成和测试的示例 生产和运行的指南 生产一致性的示例 服务和维护的示例 支持过程的指南 配置管理的示例 文档管理的示例 工具置信度评估的示例 ASIL 导向分析的指南 FMEA 的示例 FTA 的示例 STPA 的示例 概念阶段的指南 危害分析（HARA）的示例 示例 1：制动系统的 HARA 系统功能：电子液压制动系统（EHB） ...

引言 随着汽车电子系统日益复杂，半导体芯片（如 MCU、SoC、FPGA）在汽车中的应用越来越广泛。这些芯片是功能安全的物理基础，如何确保它们的安全性能成为关键问题。 想象一个真实场景：某汽车厂商的电动助力转向系统（EPS）采用了先进的 MCU，但由于 MCU 内部的某些 IP 核（如看门狗定时器）存在设计缺陷，导致在特定条件下系统失效，造成了多起事故。 这个案例告诉我们：**半导体芯片的功能安全分析是一个复杂的过程，需要从 IP 核、SoC 到整个芯片进行系统化的分析。**这正是 ISO 26262-11 半导体部分的核心使命。 半导体的目标和范围 半导体的核心活动 ISO 26262-11 定义了半导体功能安全的核心活动： 半导体安全需求 确定半导体的安全需求 分配安全需求到 IP 核和子系统 IP 核安全分析 分析 IP 核的安全特性 评估 IP 核的失效模式 SoC 安全分析 分析 SoC 的安全架构 评估 SoC 的失效模式 半导体 FMEDA 识别半导体失效模式 评估失效影响 计算半导体架构指标 半导体集成和测试 集成半导体到系统 测试半导体安全特性 半导体生产 确保生产过程符合功能安全要求 进行生产测试 半导体的输入和输出 输入 系统安全需求：来自系统级开发 硬件安全需求：来自硬件级开发 半导体技术文档：来自半导体供应商 IP 核规格说明：来自 IP 核供应商 输出 半导体安全需求：半导体级安全需求 半导体 FMEDA 报告：失效分析报告 半导体测试报告：测试结果报告 半导体安全手册：安全使用手册 IP 核安全分析 IP 核的分类 IP 核（Intellectual Property Core）是半导体芯片的预设计功能模块。 ...

引言 ISO 26262 最初是为汽车设计的，但随着摩托车电子系统的日益复杂，如何确保摩托车、踏板车等两轮车辆的功能安全成为重要问题。ISO 26262-12 摩托车部分专门针对两轮车辆的功能安全进行了适应性修改和补充。 想象一个真实场景：某摩托车厂商的电动踏板车采用了先进的电子制动系统（CBS），但在雨天湿滑路面上，由于系统对两轮车辆特性的考虑不足，导致制动时后轮抱死，造成车辆侧翻事故。 这个案例告诉我们：**摩托车和汽车在动力学特性、使用场景、安全需求等方面存在显著差异，需要对 ISO 26262 进行适应性修改。**这正是 ISO 26262-12 摩托车部分的核心使命。 摩托车和汽车的差异 动力学差异 1. 稳定性 特性 汽车 摩托车 稳定性 四轮稳定，自稳定性高 两轮不稳定，需要动态平衡 倾斜角度 无倾斜，固定姿态 可倾斜，最大倾斜角可达 45° 转向方式 前轮转向 前轮转向 + 车身倾斜 2. 制动特性 特性 汽车 摩托车 制动方式 四轮独立制动 前后轮协同制动 制动力分配 固定比例或动态分配 需要考虑负载转移 制动稳定性 相对稳定 容易抱死侧翻 3. 操控特性 特性 汽车 摩托车 转向响应 相对平缓 敏捷，需要精确控制 负载转移 相对均匀 显著，特别是加速和制动时 驾驶姿态 固定 随速度和路况变化 使用场景差异 1. 使用环境 汽车： 主要在道路上行驶 相对受控的环境 摩托车： 道路行驶 越野环境 更复杂的环境条件 2. 驾驶员因素 汽车： ...

引言 在汽车电子化、智能化迅猛发展的今天，一辆现代汽车可能包含上百个电子控制单元（ECU），数千行软件代码，以及复杂的传感器和执行器网络。当这些系统失效时，后果可能是灾难性的。这就是为什么 ISO 26262——道路车辆功能安全标准——成为汽车行业的圣经。 ISO 26262 不是一本简单的操作手册，而是一个完整的体系，包含 12 个相互关联的标准文件。这 12 个文件就像乐高积木，每个都有其特定的功能和位置，只有将它们正确地组合在一起，才能构建出功能安全的汽车电子系统。 在本系列文章中，我们已经深入解读了 ISO 26262 的每一个部分。在本文中，我们将从整体视角审视这个标准，理解它们如何协同工作，形成一个完整的汽车功能安全体系。 ISO 26262 的诞生与演进 为什么需要功能安全标准？ 在 ISO 26262 诞生之前，汽车行业使用的是 IEC 61508——通用的功能安全标准。然而，汽车电子有其特殊性： 安全性要求高：汽车故障可能导致人员伤亡 成本敏感：汽车是大宗消费品，必须控制成本 供应链复杂：涉及 OEM、Tier 1、Tier 2、半导体供应商等多方 使用环境苛刻：温度、湿度、振动、电磁干扰等 因此，ISO 于 2011 年发布了专门针对道路车辆的 ISO 26262 标准，并于 2018 年进行了全面更新（第二版）。 标准的总体目标 ISO 26262 的核心目标可以用一句话概括： 确保电子电气系统在发生故障时，不会导致不合理的安全风险 这个目标分解为三个关键要素： 预防性开发：通过系统化的开发过程，预防系统性故障 故障控制：通过安全机制，检测和控制随机硬件故障 全生命周期管理：从概念到报废的全程安全管理 与 IEC 61508 的关系 ISO 26262 是 IEC 61508 在汽车领域的应用和裁剪，两者关系如下： 特性 IEC 61508 ISO 26262 应用领域 所有行业 道路车辆 SIL 等级 SIL 1-4 ASIL A-D (汽车) / MSIL (摩托车) 特化程度 通用 汽车特定 复杂度 高 中等（更易理解） ISO 26262 的 12 个部分：全景图 ISO 26262 分为 12 个部分，每个部分都有其特定的职责和范围： ...

引言 在微分几何的宏伟殿堂中，Gauss-Bonnet 定理和它的推广形式 Gauss-Bonnet-Chern 定理堪称璀璨的明珠。它们建立了曲面（及更一般的紧致 Riemann 流形）的局部几何性质（曲率）与全局拓扑性质（Euler 示性数）之间的深刻联系。这种局部与全局之间的桥梁，正是现代几何学的核心思想之一。 本文将从经典的二维 Gauss-Bonnet 定理出发，逐步介绍其高维推广——Gauss-Bonnet-Chern 定理，并探讨这些定理的证明思路。 一、Gauss-Bonnet 定理 1.1 二维情形 经典 Gauss-Bonnet 定理是关于曲面的最基本也是最重要的定理之一。对于紧致定向 Riemann 曲面 $M$，我们有： $$ \int_M K , dA = 2\pi \chi(M) $$ 其中： $K$ 是曲面的Gauss 曲率 $dA$ 是面积元素 $\chi(M)$ 是曲面的Euler 示性数 这个定理之所以重要，是因为它告诉我们：曲面的总曲率是一个拓扑不变量！无论你如何弯曲曲面（保持拓扑结构不变），曲率的积分永远等于 $2\pi$ 乘以 Euler 示性数。 一些经典例子 球面 $S^2$： Euler 示性数 $\chi(S^2) = 2$ Gauss 曲率 $K = \frac{1}{R^2}$（$R$ 为球面半径） 总面积 $A = 4\pi R^2$ $$ \int_{S^2} K , dA = \frac{1}{R^2} \cdot 4\pi R^2 = 4\pi = 2\pi \chi(S^2) ✓ $$ ...

陈希孺在他的《高等数理统计学》一书的前言中, 关于学习方法的建议，真的让人十分认同。我们自己或者观察别人就会发现，很多时候对一个概念的理解很肤浅，又或者以为对理论的内容已经知道了，但是要做题或者真的上手的时候，有会不知从何下手。现在将陈希孺的建议摘抄在下面，以供自勉。 书中习题及提示占了近半的篇幅，从写作时间言，则占了四分之三以上. 总计得题五百，若计小题，则不止千数. 其中除少量选摘自有关著作外，大半属作者自创. 有时一题之设，累日始成，可以说倾注了不少心力. 这样做完全是因为，多做习题，尤其是多做难题，对掌握并熟练数理统计学基本的论证方法和技巧，有着不可替代的重要性. 如果通过一门基础课的学习，只是记住了若干概念，背了几个定理，而未能在这方面有所长进，那就真是"入宝山而空返"了. 技巧的熟练固非一日之功，但取法乎上，仅得乎中，必须在开始学基础课时就设定一个高目标. 日后进入研究工作，克服难点的能力如何，相当一部分就取决于在这上面修为的深浅了. 同时，经验表明，在打基础的阶段因忽视习题而导致素质上的缺陷，在日后不易弥补，或事倍功半. 笔者在学生时代及其后的几年中，对做习题未给予足够重视. 当时误认为做题费时间，不增长新知识，不如多读些书，占得实地. 以后试做研究工作，就日渐感到其不良后果，表现在碰到问题办法少，容易钻死胡同，克服难点的能力弱，以致对自己缺乏信心. 对许多方法，都似雾里看花，似曾识面，而不能切实掌握和灵活运用. 有如十八般兵器，样样都见过，但拿到手里，就使不动或很笨拙. 欲以此克敌制胜，自难有成. 以后稍明白了这一点，做了些亡羊之补，终究晚了一些，所谓"困而学之，又其次也". “熟能生巧”，前人的经验不诬. 而要达到"熟"，舍大量做题，无他捷径可循. 几十年来，审了大量的杂志稿件，每见某些工作，由于未经深思，为一个并不难克服之点加上了若干不必需的繁复条件，从而使整个工作流于肤浅. 这根子，大略也在于早先在习题上下的工夫不够，以致难以产生别出心裁的想法. 以本书的习题量，要求学员在课程时间范围内做完，恐不现实. 但作者本意并非把这一组题全作为课内习题，而是把它作为"打基础"这个工作的一环，一两年、两三年完成都可以，有空就做一点. 根据题的难易，将其分为三类：加*号的难度较大，加◇号的相对容易，教师可考虑作为课外作业;不加任何记号的，其难度介乎二者之间. 对自学者、已经研究生毕业的青年教师和研究者，可利用这组题测试一下自己解题的能力如何. 可能会有一种意见，认为这组题过于偏难. 作为课程作业，这的确如此. 但笔者觉得，从"打基础"，锻炼技巧和提高能力诸目标看，非做难题不行，这道理正如训练运动员要加大运动量，做高难动作，不然，在训练的过程中舒服了，就别指望出好成绩. 各题都有详细提示，大多数较难的题都给出了完整解答. 这是因为，鉴于这些题的难度，需要有一个解答文本在，以作为依据. 对读者而言，笔者切望这部分是备而不用、备而少用. 如碰到一个题一时做不出来，宁肯暂时搁一搁，也不要轻易翻看解答. 譬如登山，经过艰苦努力上了峰顶，自有其乐趣和成就感. 反之，如在未尽全力之前就任人抬上去，则不惟无益，实足以挫折信心. 以上就习题一事唠叨了半天，读者也许烦了，就此打住. 千言万语，归结到一点：希望大家多做题，做难题. “千里之行，始于足下”，就从今日开始吧!

前言 最近要给别的团队A,在AWS的EC2上面去搭建一个算法的开发环境。鉴于自己之前在AWS上都是使用的Linux,在和团队A讨论了之后,最后决定建个Linux的EC2。 但是在基本的Python和数据分析和算法开发的环境都搭建好了之后,团队A的同学又提了没有IDE,影响效率。 没有办法,得考虑是不是换个Windows的EC2了。这个时候VS Code Remote Development comes to my rescue。 试用了下来,感觉这个VS Code Remote Development是个神器啊。 什么是VScode Remote Development VScode Remote Development是VScode的一个扩展功能,允许你: 使用容器、远程机器或Windows Subsystem for Linux (WSL)作为全职开发环境 在远程环境中运行扩展和工具 使用本地VScode的所有功能,就像在本地开发一样 三种Remote模式 Remote - SSH:通过SSH连接到远程机器 Remote - Containers:使用Docker容器作为开发环境 Remote - WSL:连接到Windows上的Linux子系统 本文主要介绍Remote - SSH,这是最常用的模式。 为什么使用Remote Development 传统远程开发的痛点 没有IDE:只能使用vim或emacs,学习曲线陡峭 文件传输麻烦:需要频繁使用scp或rsync 调试困难:无法使用图形化调试工具 本地和远程环境不一致:容易产生"在我机器上能跑"的问题 协作困难:难以分享开发环境 Remote Development的优势 完整的IDE体验:使用本地VScode连接远程服务器 无缝的文件操作:直接编辑远程文件,就像本地文件一样 强大的调试功能:完整的断点、变量查看等功能 环境一致性:直接在远程环境中开发 扩展支持:大部分扩展都可以在远程环境运行 安装和配置 1. 系统要求 本地机器: Windows 7/8/10/11 macOS 10.12+ Linux (Desktop) 远程机器: 运行SSH服务器 可以是Linux、macOS或其他Unix-like系统 2. 安装扩展 在本地VScode中安装"Remote - SSH"扩展: ...

前言 如果把之前做anti spam的工作也算是数据分析的话(确实跟数据分析沾边,当时招聘的时候就说懂机器学习是个加分项。其实我们当时所做的工作,可以用"专家系统"来概括:通过我们的知识和经验,去写规则和脚本去anti spam),再加上在华米科技的这3年多做大数据分析的经历,也算是一个在数据分析领域浸淫了快7年之久的人了。如果再加上大学四年的"信息与计算科学"这个专业的学习经历(其实是3年,因为大一上半年是在农学类专业,大一下学期转到信息与计算科学),那就是跟数据打交道了快10年的人了。往多了说10年,往少了说3年多,也是该写点总结了。 BTW,最近在看《谁说菜鸟不会数据分析》这本书,发现自己的很多思考跟书中提炼的内容竟然不谋而合,看来这本书还是不错的,哈哈哈。 数据分析的分类 从技巧和方式来看 描述性数据分析(Descriptive Data Analysis) 对数据进行概括性描述 计算基本统计量:均值、中位数、方差等 可视化展示数据分布 探索性数据分析(Exploratory Data Analysis) 发现数据中的模式和规律 提出假设 为进一步分析奠定基础 验证性数据分析(Confirmatory Data Analysis) 验证假设 确认发现的显著性 得出结论 从作用来看 现状分析 了解当前业务状况 监控关键指标 发现异常情况 原因分析 分析问题产生的原因 找到关键影响因素 为决策提供依据 预测分析 预测未来趋势 建模预测 支持战略决策 数据分析的六步曲 在《谁说菜鸟不会数据分析》这本书中,作者总结了数据分析的6步曲: 明确分析目的和思路 理解业务需求 定义分析目标 制定分析框架 数据收集 确定数据源 提取数据 数据质量评估 数据处理 数据清洗 数据转换 特征工程 数据分析 选择分析方法 建立模型 验证结果 数据展现 选择合适的可视化方式 制作图表 突出关键发现 报告撰写 总结分析结果 提出建议 沟通汇报 实际上,只要是在企业里做过数据分析的人,这几步应该都是做过的。或许在报告撰写这块,不是每次都需要,尤其是做临时业务分析,并非每次都要写结论报告。 数据分析的难点 针对上面的6步曲,以我丰富的"描述性数据分析"经验来看,1-5都不难,只要: 受过专业的数学或统计方面的训练 加上一定的数据分析专业工具和知识的培训 就可以上手了 但是第6点就比较复杂了,可能跟我这边"报告"撰写的少有关系,毕竟我们很多都是临时业务分析,不需要出报告。而且报告的撰写需要: ...

前言 下面的机器学习流程图是从某视频中看到的,虽然"会的不难",但里面的每一步都很艰辛。尤其是被很多人认为是脏活累活的"加载预处理数据集"这块,这个大家实践下来的基本共识是:这块就占了整个机器学习流程的60%到80%的工作量。 所以,不要心存美好幻想,觉得机器学习或者人工智能是多么高大上和美好的事情。 机器学习完整流程图 ┌─────────────────────────────────────────────────────────────┐ │ 机器学习项目完整流程 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 1. 问题定义 │ │ - 明确业务目标 │ │ - 定义成功指标 │ │ - 确定项目范围 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 2. 数据收集 │ │ - 确定数据源 │ │ - 收集训练数据 │ │ - 数据质量评估 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 3. 数据探索(EDA) │ │ - 统计分析 │ │ - 可视化探索 │ │ - 发现模式和异常 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 4. 数据预处理 │ │ - 数据清洗 │ │ - 缺失值处理 │ │ - 异常值处理 │ │ - 特征编码 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 5. 特征工程 │ │ - 特征选择 │ │ - 特征变换 │ │ - 特征构造 │ │ - 降维处理 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 6. 模型选择 │ │ - 选择算法 │ │ - 设计基线模型 │ │ - 确定评估指标 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 7. 模型训练 │ │ - 数据集分割 │ │ - 交叉验证 │ │ - 超参数调优 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 8. 模型评估 │ │ - 性能评估 │ │ - 错误分析 │ │ - 模型解释 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 9. 模型优化 │ │ - 集成方法 │ │ - 模型融合 │ │ - 迭代改进 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 10. 模型部署 │ │ - 模型序列化 │ │ - API设计 │ │ - 监控和维护 │ └─────────────────────────────────────────────────────────────┘ 详细步骤解析 第1步:问题定义 重要性: ...