- 博客(54)
- 收藏
- 关注
RSS订阅原创 ISO8800经验分享之MUNIK带你实施汽车AI安全标准
需要注意的是，ISO8800并不是独立的安全标准，通常会建立在ISO26262和ISO21448的基础上，否则差距分析的时间可能会扩展到三到五天。差距分析后，MUNIK技术老师整理并生成差距分析报告，并提交给客户，以帮助客户进行后续改进和梳理，明确客户计划建立的流程框架，包括AI安全手册，各类流程和指南(建立在ISO26262和ISO21448基础之上，如果客户产品属于底层组件，只考虑和ISO26262的交互，和ISO21448的交互会定义在SEooC中)，各类工作模板（规范，分析，验证等），各类检查表。
2025-04-17 15:33:46
850
原创 MUNIK解读ISO21434专题分享（10）：验证测试，漏洞扫描、模糊测试和渗透测试
在漏洞挖掘领域，与渗透测试技术相伴使用的是模糊测试技术，广泛应用于智能网联汽车的不同车载系统，发掘潜在的未知网络安全漏洞。渗透测试采用以攻击代替测试的观点，站在攻击者的角度，使用各种技术与工具尝试入侵目标系统，一旦发现可被利用的安全漏洞则将其提交给系统所有者。但是在日常的咨询工作时，我们发现很多客户（OEM和Tier1）做了大量的测试工作，但是工作内容大量重复，故本篇推文主要为大家理清楚各种测试之间的关系。通过这些测试方法，可以识别和修复系统中的潜在漏洞，确保系统在面对各种威胁时的安全性和可靠性。
2025-04-10 09:43:25
1099
原创 MUNIK解读ISO21434专题分享（9）：安全子系统设计
在后续的内容中，我们将继续探讨安全刷新、安全诊断、安全存储和安全通讯等具体内容。8）安全通信：为保护车内网络通信的完整性、真实性、抗重放性，采用安全通信机制例如SecOC，在需要保护的报文中增加新鲜度值、身份认证信息等；3）安全更新：为保护ECU软件更新包/固件更新包的真实性和完整性，通常在预刷新阶段验证更新包的真实性，在后刷新阶段验证刷写包的完整性；通过遵循这些网络安全规范和设计原则，可以有效地实现安全启动，保护系统免受恶意软件和未经授权的代码篡改，确保系统的安全性和可靠性。【常见的网络安全措施】
2025-04-10 09:36:40
1110
原创 MUNIK解读ISO21434专题分享（8）：基于具体开发目标的安全工程示例
影响了车辆的运营，因此财产为F1即Moderate；信号类型包括通信信号（CAN/CANFD、LIN、以太网等）、串口信号（SPI、IIC等）、PWM、调试信号（JTAG、USB等），功能类型包括MCU固件、CAN收发器、继电器、SPI通信模块、PWM通信模块、ADC采样模块等。说明：接口类型包括但不限于JTAG、UART、USB等调试接口，CAN、以太网等标定接口，OBD等诊断接口，4G/5G、WIFI、蓝牙、USB、OBD、GNSS、TPMS等无线接口，CAN、LIN、以太网等通讯接口以及硬线接口等。
2025-04-09 17:23:31
1107
原创 MUNIK解读ISO21434专题分享（7）：网络安全TARA(网络安全及网络安全概念)
采用基于攻击潜力的分析方法对攻击可行性进行分析时，需要从经历时间Elapsed time、专业知识Expertise、相关项或组件知识Knowledge of the item or component、机会窗口Window of opportunity、设备Equipment这五个参数进行分析，最终取值由以上5个参数累加而成，并根据下表中的映射关系得出攻击可行性，攻击可行性分为Very low、Low、Medium、High4个层级。确定损害场景的影响等级时，取四类影响等级中最严重的等级。
2025-04-09 16:35:03
711
原创 MUNIK 解读 ISO21434 专题分享（6）：网络安全安全运营
随着智能网联汽车的发展，网络安全已成为汽车领域的关键议题。它涵盖了对安全威胁和漏洞的持续监测与评估，以及采取适当的预防、检测、响应和修复措施，不仅包含事前的防范，还包括事件发生后的应急响应与恢复，以保障汽车网络的完整性、保密性和可用性。通过安全监控、安全事件检测与响应、补丁管理和漏洞修复、数据保护与隐私管理，以及安全培训与意识提升，全面构建网络安全体系。本文将从五个方面对汽车网络安全整车架构设计进行系统探讨，包括安全监控、安全事件检测与响应、补丁管理和漏洞修复、数据保护与隐私管理，以及安全培训与意识提升。
2025-04-09 16:03:08
1077
原创 MUNIK 解读 ISO21434 专题分享（5）：网络安全风险管控摘要
ISO21434是汽车行业网络安全管理的重要标准，其核心目标是通过综合的评估和管理体系，确保汽车网络系统的安全性，避免网络攻击、数据泄露等事件对车辆、驾驶员和乘客造成危害。—原创文章，文章内所有内容文字资料，版权均属本公众号所有，任何媒体、网站、公众号或个人未经Munik公司授权不得转载、转贴、引用或以其他方式复制发布 、发表。网络安全风险评估是ISO21434体系的基础，旨在识别潜在的安全问题并提供缓解方案，以降低风险对汽车网络安全的影响。车载信息娱乐系统因其与外部设备（如手机）的连接，易成为攻击目标。
2025-04-09 15:59:56
869
原创 MUNIK 解读 ISO21434 专题分享（4）：网络安全元器件开发
通过安全启动、加密模块、硬件安全模块（HSM）、物理不可克隆函数（PUF）等技术的结合，能够全面提升汽车系统对网络攻击的防护能力。未来，随着智能化和网联化的进一步深化，网络安全技术将在汽车领域发挥更加重要的作用，为驾驶者提供安全、可靠的出行体验。汽车中的电子控制单元（ECU）、微控制器（MCU）、传感器、执行器以及通信模块等元器件都面临网络安全威胁。—原创文章，文章内所有内容文字资料，版权均属本公众号所有，任何媒体、网站、公众号或个人未经Munik公司授权不得转载、转贴、引用或以其他方式复制发布 、发表。
2025-04-09 14:54:26
830
原创 MUNIK 解读 ISO21434 专题分享（3）：网络安全整车测试摘要
同时，防御能力的验证也是关键，必须确认网络安全控制措施（如加密、认证、授权等）在集成后的系统中能够应对潜在的安全威胁。在此背景下，集成测试的目标是确保车载网络（如 CAN 总线、以太网、Wi-Fi 等）在多个ECU之间的通信是安全的，确保自动驾驶系统中的各个组件（如传感器、决策控制模块、执行机构等）能够安全地交换数据。不同于单一组件或ECU 的安全测试，整车测试不仅关注单个电子控制单元的安全性，还强调所有互联系统的集成安全，确保车辆的各项功能能够在实际应用中保持安全，避免可能的网络攻击或安全事件。
2025-04-09 14:22:42
785
原创 MUNIK解读ISO21434专题分享（1）：网络安全标准全貌解读
可以看到，ISO/SAE 21434描述了一个项目在全生命周期里对于网络安全的目标或者要求，从开始的法律法规要求、公司网络安全文化形成，到公司间交互的网络安全权责划分，再落实到具体项目、对应Item的网络安全目标，对产品开发、量产、售后、报废不同阶段提出了相应的网络安全目标，可以说，网络安全贯穿全生命周期。其实，ISO/SAE 21434也是参照了ISO26262的成功经验，所以文档在结构方面还是有所类似，只是21434面向Security，26262面向Safety。
2025-04-08 13:51:10
1027
原创 MUNIK 解读 ISO21434 专题分享（2）：网络安全整车架构设计摘要
这一设计目标是通过全面的安全规划与实施，确保车辆硬件和软件系统在全生命周期内的安全性，防范外部攻击、数据泄露等威胁，并保护车辆、驾驶员及乘客的安全。随着车辆智能化和网联化的不断发展，网络安全问题将更加复杂多变，车企需要不断创新和完善网络安全架构，以应对日益严峻的安全挑战。它根据车辆功能的不同，将车辆划分为多个独立的安全域，每个安全域内包含独立的网络安全机制，从而实现不同系统的安全防护。安全通讯在整车架构中扮演着至关重要的角色，通过一系列的加密技术和认证机制，确保车内外数据传输的安全性，防止数据泄露和篡改。
2025-04-08 13:47:28
726
原创 MUNIK谈ASPICE系列专题分享（十）ASPICE配置管理如何做
ASPICE（Automotive Software Process Improvement and Capability dEtermination）是一种用于评估汽车行业软件开发过程成熟度的模型。配置管理是ASPICE中的一个关键过程领域（KPA），它涉及到对软件项目的版本控制、变更管理、以及对项目工件的追踪和标识。
2024-09-18 16:55:37
1244
原创 MUNIK谈ASPICE系列专题分享（九）ASPICE对项目需求管理的实践分享
VDA scope里面主要有2个过程域涉及到需求定义，即SYS.2 系统需求分析和SWE.1 软件需求分析。SYS.2的过程目的是将已定义的利益相关方需求转换成一组系统需求，以指导系统设计。SWE.1的过程目的是将系统需求中与软件相关的部分转化为一组软件需求。
2024-09-18 16:34:23
667
原创 MUNIK谈ASPICE系列专题分享（八）ASPICE评估范围主要是针对软件开发的吗
通过这些方面的评估，ASPICE旨在改进汽车电子系统的开发流程，提高产品的质量和安全性，以及降低开发成本和风险。MUNIK公司作为一家全球认可的ASPICE服务公司，我们的专家由德国和印度，以及本地化的ASPICE资质评估老师构成。基于MUNIK丰富的项目经验，我们可以为您提供专业的ASPICE培训，咨询，评估及认证服务。基于我们专家的这些服务不止可以帮客户企业建立ASPICE能力，拿到相应的资质证书和评估报告，也是您系统、软件设计能力及流程实施提高的专业途径。以上为MUNI公司的一家之言，供您参考。
2024-09-18 16:07:27
858
原创 MUNIK谈ASPICE系列专题分享（五）如何选一家ASPICE评估服务认证公司
例如，XX服务公司拥有10年以上的行业经验，不止有专精于ASPICE、敏捷SPICE等ASPICE服务的流程服务能力，同时也有ISO26262功能安全等流程实施，系统产品设计及实施，硬件V模型的全领域设计及测试，软件V模型的全领域设计及测试等产品开发经验，基于这些经验的技术团队实力和丰富的项目案例，将为企业的ASPICE设计实施提供非常专业的设计助力，无论是ASPICE的各个过程域，还是设计环节的每个细节，专业的服务公司老师都会有专业的经验跟您讨论，以确保流程实施的正确性、完整性及一致性。
2024-09-18 15:44:14
912
原创 MUNIK谈ASPICE系列专题分享（七）ASPICE项目中需要考虑哪些工具软件？
ASPICE评估过程中需要考虑工具吗？ASPICE项目中常用的工具有哪些类别，需求，配置，管理…
2024-09-18 15:39:13
1247
原创 MUNIK谈ASPICE系列专题分享（四）ASPICE评估为什么要做差距分析
ASPICE（Automotive Software Process Improvement and Capability dEtermination）评估是一种用于衡量汽车行业软件开发过程成熟度的方法。进行差距分析是ASPICE评估过程中的不可或缺的一个关键步骤。ASPICE评估的差距分析是在做什么？差距分析的结果会不会给到企业？差距分析的结果对后续项目有什么作用？
2024-09-18 15:29:27
432
原创 MUNIK谈ASPICE系列专题分享（三）ASPICE评估资质和评估依据？
ASPICE的评估是依据ISO/IEC33002，所以一般证书上会涵盖适用的过程评估以及评估改进模型。此之外还会根据ISO/IEC33002的要求标明class等级、Category的类型以及评估的过程的能力等级。明确一点企业所取得的ASPCIE评估等级与评估师的个人资质有关，与发证机构无关。每个评估师在取得VDA QMC的注册资格以后，可以履行注册评估师对应的责任与职能。该证书的有效性主要取决于评估师的资质，如果评估师在发证节点的资格为无效，那么证书的有效性也同样无效。
2024-09-18 15:24:18
1082
原创 MUNIK谈ASPICE系列专题分享（二）什么是ASPICE评估？
CL1，2，3...等级介绍：Automotive SPICE®的六个能力级别代表了项目过程能力的分析。级别0(未执行incomplete)意味着流程的预期结果不存在、不完整或不合适，或者流程活动没有被执行。在第1级(执行performed)，可以声明过程的结果存在，但它们没有受到控制，过程活动也没有受到控制。在第2级（管理managed），对过程活动的实施进行计划和监控，明确职责，系统地存档过程结果并保证质量。
2024-09-18 14:09:15
893
原创 MUNIK谈ASPICE系列专题分享（一）什么是ASPICE？
ASPCIE的英文简称是什么？ASPCIE的全称为Automotive Software Process Improvement and Capability Determination（汽车软件过程改进以及能力测定），简称Automotive SPICE®。是由整车制造厂主导的特殊利益集团SIG（Special Interest Group）、采购论坛以及SPCIE用户团体于2005年共同开发的。
2024-09-18 13:54:48
1118
原创 ADAS十大系统解读-MUNIK解读标准
然后系统进行自动泊车轨迹计算，并通过精确的车辆定位与车辆控制系统使车辆沿定义的泊车轨迹进行全自动泊车，直至到达最终目标泊车位相比于传统的倒车辅助功能，如倒车影像以及倒车雷达，自动泊车的功能智能化程度更高，有效的减轻了驾驶员的倒车困难。一般应用在L0级别的自动驾驶中，属于增强感知能力类的功能，系统是可以根据周围路况情况，自动辅助驾驶员进行远近光灯的切换，进而确保在符合法规要求和行车安全的情况下尽可能增加远光灯的使用率，提高驾驶员在黑暗环境中尤其是夜间驾驶的安全性和舒适性的智能辅助驾驶系统。
2024-08-29 13:37:02
1175
原创 认识ISO8926标准-MUNIK解读标准
国际标准组织ISO新编写的ISO/PAS 8926:2024《道路车辆 — 功能安全 — 使用预先存在的软件架构元素》- 作为一个公开可用规范（Publicly Available Specification）- 提供了一套框架，用于在符合ISO 26262:2018系列标准的安全相关嵌入式软件中，使用那些并非最初按照该系列标准开发的预先存在的软件架构元素（Pre-existing Software Architectural Elements, PSAEs）。
2024-08-29 13:33:30
1076
原创 MUNIK解读ISO26262-软件复用
例如，依据ISO26262的影响分析可能表明，必须重新创建用于验证的检查单（Inspection checklist）（因为检查/Inspection对ASIL B、C和D来说是必要的），因为分析前是以走查（Walkthrough）的形式进行的验证（对于ASIL A来说足够）。在这种情况下，保持不变的软件部分的工作产出物可以被复用。通过上面的讲解，我们能意识到与安全相关的软件的复用可以有很多实际应用场景，接下来必须在ISO26262中确定与特定项目相关的重复使用的具体实践，这里将通过几个例子来讨论。
2024-08-29 13:29:40
1040
原创 认识R156法规-MUNIK解读标准
总体而言，UN R156法规通过为软件升级设定高标准，不仅提高了汽车的安全性和可靠性，还为汽车制造商在全球市场上提供了更多的机遇和挑战。比如，R156作为统一的国际法规，减少了OEM为满足不同国家法规而进行的重复测试和认证，降低了合规成本，提高了市场进入效率。再如R156要求OEM公开软件升级的相关信息，这有助于消费者和监管机构更好地了解车辆的软件状态，从而增加市场透明度。最后，R156对数据处理和隐私保护的要求促使OEM在设计软件升级系统时更加注重用户隐私，这在现今这样数据敏感的市场尤为重要。
2024-08-29 13:27:17
2004
原创 预期功能的必要性与典型案例解析——MUNIK
随着汽车行业的不断发展，人们已经不再满足车辆仅仅作为提高出行效率的简单工具，希望能有有更“聪明的车辆”帮用户解决一部分驾驶带来的困扰。此事件中，该特斯拉Model S驾驶员未遵守Autopilot功能定义的ODD（Operational design domain）界限，在红绿灯场景仍然未接管驾驶责任，属于典型的自动驾驶功能误用案例。随着自动驾驶技术的不断发展，越来越多的功能被集成在车辆上，极大地提升的驾驶者的使用体验。上述因素可以看出，即使在功能实现的情况下，依然不排除有其他可能导致危害行为的事件发生。
2024-07-10 16:33:11
519
原创 认识R155法规（UN Regulation No. 155）-MUNIK
随着汽车新四化（电动化、智能化、网联化、共享化）政策的提出，大数据和人工智能等技术的发展，以及软件驱动汽车、舱驾一体、行泊一体等新型架构概念的提出，车内外智能传感器采集的大量数据（包括驾驶员，乘客，车外道路交通环境等）通过通信网络（比如5G蜂窝移动）实时与外部世界互联互通，汽车已经从传统的交通工具转变为可移动的智能终端并承载各类创新应用场景，但是与此同时也增加了被网络黑客攻击的概率。需要注意的是，R155的规定是动态的，随着网络安全威胁的发展和技术的进步，这些要求可能会不断更新。
2024-07-10 15:20:41
1938
原创 一文带你快速了解项目ASPICE评估的那些事-MUNIK
32个过程对企业选择也比较难，VDA推荐了16个过程组，红框里面作为ASPICE的一些基本过程，如果企业不知道做哪些过程，可以以这16个过程为基础，当然，企业可以根据自己来选择增加或者减少哪些过程组；它提供了一套标准和指南，帮助组织评估其软件开发过程的成熟度和质量，并提供改进的方法和最佳实践。同时，在本次ASPICE 4.0中进行还了修正和明确了之前ASPICE 3.1的实施过程中经常会遇到的一些困惑和模糊的内容，让ASPICE标准与项目实践更加贴合适用，具体的变化在后续技术文章中再给大家带来分享。
2024-07-10 11:15:44
1604
原创 MUNIK解读ISO26262：安全计划
安全计划是管理和指导开展项目中安全活动的计划，这样是可以系统化的对项目所有的安全活动及进度进行管理。常见的一个误区是，认为项目计划等同于安全计划。项目计划是对项目实施过程中所有的活动进行系统性的规划，其中当然不止功能安全相关事宜。安全计划只是项目计划的一部分。我们也可以将安全计划的内容与项目计划写在同一份文件中，但是要确保安全计划能够明显的识别，也可以将安全计划单独写一份文件，标准中对此有明确的要求。图：项目时间轴。
2024-07-10 11:02:42
890
原创 MUNIK解读ISO26262 : 硬件架构评估及FMEDA(系统级)
汽车功能安全关注汽车电子/电气系统功能的正确、完整、可靠的实现，但由于硬件要素物理因素的限制，不同的硬件要素总会出现各种随意硬件失效，这个是由于要素材质、工艺、技术等因素带来的不可消除的影响。当单点故障被安全机制覆盖时，安全机制覆盖到的部分会生成双点故障，它们单独失效都不会导致安全目标的违背，只有当器件与覆盖它失效模式的安全机制同时失效时才会违背安全目标。此时，考虑增加安全机制来防止双点失效的发生，被安全机制覆盖的部分是可探测和和感知的双点故障，安全机制未覆盖到的部分是潜伏的双点故障。
2024-07-10 10:56:48
1901
原创 MUNIK解读ISO26262--什么是系统安全分析
简单来讲就是安全分析和仿真一样属于产品研发阶段做的事前的分析，它可以预测产品的可靠性，判断系统的鲁棒性并且依据当前的薄弱点设计安全措施并制定持续优化的改进过程。在此篇中我们着重介绍系统阶段的安全分析，其他的不在此处赘述（会在其他的文章中体现，DFA可参考我们之前的文章：“功能安全之DFA相关失效分析”，其余的安全分析类的解读文章会陆续更新）在系统阶段的作用是通过SG导出FSR，通过FSR导出TSR，适用于复杂的系统，该方法是可选择的（不一定必须使用），在我们的前期分享的标准解读文章（
2024-07-05 15:55:19
1287
原创 MUNIK解读ISO26262--系统架构
通过在设计阶段就充分考虑安全需求，采用分层的安全策略，设计安全关键组件，以及进行严格的安全验证和确认，可以有效地提高系统的安全性。个模块之间少不了有通讯或者系统层级需要有程序的烧录等情况出现，模块可能会通过CAN，CAN-FD，UART，I2C，SPI，PHY等进行片内或片外、板内或板外的通讯或者程序的烧录，下面以串口UART举例说明通讯模块的安全机制都有哪些。综上所述，系统架构设计是我们在产品开发中不可忽视的重要阶段，下面我们着重探讨“系统的架构类型”和“系统架构层级相关的安全机制”。
2024-07-05 15:48:59
1290
原创 MUNIK解读ISO26262--什么是功能安全文档
功能安全强调工作成果的追溯性，文档管理可以很好的实现这个要求，所以文档管理对功能安全来说也是必要的。对于已经建立质量体系的企业来说，文档管理应当已经有一个健全的系统在运作了，这时我们只需要识别现有的文档管理的程序与功能安全要求的文档管理有什么出入即可，没必要单独为功能安全体系建立一个新的文档管理程序。当然，不排除也有企业还未建立或正在建立功能文档管理程序，此时就需要考虑在满足功能安全体系文档管理的条件下，如何适配其他体系的文档管理任务，尽可能做到覆盖企业所有文档均能够通用的情况最佳。
2024-07-05 15:35:51
448
原创 MUNIK解读ISO26262--什么是DFA
首先DFA（相关失效分析）的执行与ASIL没有关系，这是与FMEA还有FTA明显的一个区别，其次就是在架构设计过程中若产生了ASIL分解，有要素共存的情况（低等级的要素我们通常会认为他的开发要求不够严谨，可能会对高要求的产品造成不利影响），有冗余设计，功能电路和安全机制等情况时，那么就要执行相关失效分析。：假设我们的架构设计中存在PLL(锁相环，实现外部输入信号与内部震荡信号同步)和对其的监控电路CMC，它们之间的关系就属于功能电路和安全机制的关系，所以我们要分析这两者会不会发生相关失效。
2024-07-05 15:33:42
1331
原创 MUNIK解读ISO26262--什么是变更管理
（3）变更对功能安全的潜在影响；在完整的项目生命周期内，变更管理并不是为了拒绝变更，而是通过变更管理来控制变更，使得变更带给项目的影响变得有序可控，因此在项目启动时，建立变更管理制度和相关流程规范，以便指导和规范执行变更的相关人员进行项目变更行为。变更结束前，应当记录变更的相关明细、变更的工作产品清单和变更对象信息，并给出变更的实施时间。变更管理的目的是在整个功能安全生命周期中,分析和控制功能安全相关工作成果、相关项和要素的变更，同时在整个安全生命周期内维护工作成果、相关项和要素的相关功能和特性。
2024-07-05 15:24:25
408
原创 MUNIK解读CMMI-带你认识什么是CMMI
4级:量化管理级：在3级基础上，依据公司年度目标，制定部门和项目的量化目标，通过建立数据模型和数据基线等数据统计方法论，实现对项目目标的预测和过程方法的优化，提升项目的资源利用率，实现项目的成本、过程、质量精准管控、极大地提升了项目的开发管理水平。5级：优化改进级：在4级基础上，依据公司的发展战略和规划，制定项目量化目标，不断优化和改进开发资源组合，不断优化资源配置，从技术变革、公司业务革新方面全面提升公司能力。2级：已管理级：在1级基础上，部分过程具有简单的流程控制，有完整的方法，能满足过程控制的目标。
2024-07-04 14:19:05
658
原创 MUNIK解读ISO26262--验证活动之认可措施
它关注的内容就比较全面和细致，不仅关注产品的开发流程是否符合标准（这里其实也就是Audit的内容，所以标准有提到Audit的内容是可以纳入到Assessment中的），还要关注所有工作成果的合理性，完整性（因为是所有的工作成果，当然也包含CR中的工作成果，所以CR的结果也可以是Assessment的一部分）。注：虽然这三个活动的名称意思比较相近，但是在ISO 26262中是有特指意义的，所以在实际执行的时候是要区分清楚，并且在一些文档的描述上要注意用词的准确性。下图就是标准对于Audit独立性的要求。
2024-07-04 14:00:32
1067
原创 MUNIK解读ISO26262--FMEA设计大全
上述的PC会对“O”的取值进行优化，降低失效发生的概率，常见的PC措施就比如对设计的评审验证。对于FMEA-MSR的思考逻辑有点类似于ISO 26262中在概念阶段执行HARA（危害分析和风险评估）来确定SG的活动，HARA的三个参数S(严重度),E（暴露概率）,C（可控性），与FMEA-MSR中的S（严重度）,F（运行过程中的发生频率）,M（对失效的发现和处理的可能性或者叫难易程度），大家可以类比着进行理解。而FMEA-MSR(监控及系统响应的补充FMEA)是作为对这两种形式的补充。
2024-07-04 13:58:28
1074
原创 MUNIK解读ISO26262--ASIL分解详解
在上面我们提到了ASIL分解要将分解后的需求分配到相互独立的要素上，这是一个必须满足的条件，因为ASIL分解本质概念是冗余，冗余就要求组件之间不存在共因失效或者级联失效，那么怎么来证明要素之间互相冗余？这里有必要说明一下，冗余并非是直接使用两个相同的组件互相备份，这种直接复制组件的方式称为同构冗余，同构冗余的两个组件是缺乏要素间的独立性的，因为同样的组件大概率是会存在相同的系统性失效，而系统性失效是我们在开发功能安全产品时是要尽可能避免的，所以一般会采用功能相同，设计存在明显区别的组件进行互相冗余。
2024-07-04 11:39:26
2145
原创 MUNIK解读ISO26262--Item定义及HARA活动
例如，HWP（高速路自动驾驶）相关项完成功能时，感知系统（雷达、摄像头）提供道路信息，控制器（SoC、MCU）处理接收到的信息并运算最佳行驶轨迹，执行器实现控制器下达指令完成纵向、横向的整车运行调整。例如：车辆的高速领航功能，由智驾域控（SoC），感知系统（雷达、摄像头等）以及动力系统可以组成一个完整的车辆功能，这个系统组合就是一个相关项。从图中我们可以看出，单一的系统是相关项的最低限度也是要素的最高限度；E0（几乎不可能发生）、E1（低概率）、E2（中等概率）、E3（高概率）、E4（非常高概率）。
2024-07-04 11:35:10
1080
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人