秒尼科技术-CSDN博客

原创 MUNIK谈ASPICE系列专题分享（十）ASPICE配置管理如何做

ASPICE（Automotive Software Process Improvement and Capability dEtermination）是一种用于评估汽车行业软件开发过程成熟度的模型。配置管理是ASPICE中的一个关键过程领域（KPA），它涉及到对软件项目的版本控制、变更管理、以及对项目工件的追踪和标识。

2024-09-18 16:55:37 772

原创 MUNIK谈ASPICE系列专题分享（九）ASPICE对项目需求管理的实践分享

VDA scope里面主要有2个过程域涉及到需求定义，即SYS.2 系统需求分析和SWE.1 软件需求分析。SYS.2的过程目的是将已定义的利益相关方需求转换成一组系统需求，以指导系统设计。SWE.1的过程目的是将系统需求中与软件相关的部分转化为一组软件需求。

2024-09-18 16:34:23 378

原创 MUNIK谈ASPICE系列专题分享（八）ASPICE评估范围主要是针对软件开发的吗

通过这些方面的评估，ASPICE旨在改进汽车电子系统的开发流程，提高产品的质量和安全性，以及降低开发成本和风险。MUNIK公司作为一家全球认可的ASPICE服务公司，我们的专家由德国和印度，以及本地化的ASPICE资质评估老师构成。基于MUNIK丰富的项目经验，我们可以为您提供专业的ASPICE培训，咨询，评估及认证服务。基于我们专家的这些服务不止可以帮客户企业建立ASPICE能力，拿到相应的资质证书和评估报告，也是您系统、软件设计能力及流程实施提高的专业途径。以上为MUNI公司的一家之言，供您参考。

2024-09-18 16:07:27 734

原创 MUNIK谈ASPICE系列专题分享（五）如何选一家ASPICE评估服务认证公司

例如，XX服务公司拥有10年以上的行业经验，不止有专精于ASPICE、敏捷SPICE等ASPICE服务的流程服务能力，同时也有ISO26262功能安全等流程实施，系统产品设计及实施，硬件V模型的全领域设计及测试，软件V模型的全领域设计及测试等产品开发经验，基于这些经验的技术团队实力和丰富的项目案例，将为企业的ASPICE设计实施提供非常专业的设计助力，无论是ASPICE的各个过程域，还是设计环节的每个细节，专业的服务公司老师都会有专业的经验跟您讨论，以确保流程实施的正确性、完整性及一致性。

2024-09-18 15:44:14 754

原创 MUNIK谈ASPICE系列专题分享（七）ASPICE项目中需要考虑哪些工具软件？

ASPICE评估过程中需要考虑工具吗？ASPICE项目中常用的工具有哪些类别，需求，配置，管理…

2024-09-18 15:39:13 1015

原创 MUNIK谈ASPICE系列专题分享（六）企业为什么要做ASPICE？

知名的几家主机厂对ASPICE有什么各自的要求？企业应该做哪些应对。

2024-09-18 15:33:42 647

原创 MUNIK谈ASPICE系列专题分享（四）ASPICE评估为什么要做差距分析

ASPICE（Automotive Software Process Improvement and Capability dEtermination）评估是一种用于衡量汽车行业软件开发过程成熟度的方法。进行差距分析是ASPICE评估过程中的不可或缺的一个关键步骤。ASPICE评估的差距分析是在做什么？差距分析的结果会不会给到企业？差距分析的结果对后续项目有什么作用？

2024-09-18 15:29:27 308

原创 MUNIK谈ASPICE系列专题分享（三）ASPICE评估资质和评估依据？

ASPICE的评估是依据ISO/IEC33002，所以一般证书上会涵盖适用的过程评估以及评估改进模型。此之外还会根据ISO/IEC33002的要求标明class等级、Category的类型以及评估的过程的能力等级。明确一点企业所取得的ASPCIE评估等级与评估师的个人资质有关，与发证机构无关。每个评估师在取得VDA QMC的注册资格以后，可以履行注册评估师对应的责任与职能。该证书的有效性主要取决于评估师的资质，如果评估师在发证节点的资格为无效，那么证书的有效性也同样无效。

2024-09-18 15:24:18 612

原创 MUNIK谈ASPICE系列专题分享（二）什么是ASPICE评估？

CL1，2，3...等级介绍：Automotive SPICE®的六个能力级别代表了项目过程能力的分析。级别0(未执行incomplete)意味着流程的预期结果不存在、不完整或不合适，或者流程活动没有被执行。在第1级(执行performed)，可以声明过程的结果存在，但它们没有受到控制，过程活动也没有受到控制。在第2级（管理managed），对过程活动的实施进行计划和监控，明确职责，系统地存档过程结果并保证质量。

2024-09-18 14:09:15 632

原创 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 953

原创 ADAS十大系统解读-MUNIK解读标准

然后系统进行自动泊车轨迹计算，并通过精确的车辆定位与车辆控制系统使车辆沿定义的泊车轨迹进行全自动泊车，直至到达最终目标泊车位相比于传统的倒车辅助功能，如倒车影像以及倒车雷达，自动泊车的功能智能化程度更高，有效的减轻了驾驶员的倒车困难。一般应用在L0级别的自动驾驶中，属于增强感知能力类的功能，系统是可以根据周围路况情况，自动辅助驾驶员进行远近光灯的切换，进而确保在符合法规要求和行车安全的情况下尽可能增加远光灯的使用率，提高驾驶员在黑暗环境中尤其是夜间驾驶的安全性和舒适性的智能辅助驾驶系统。

2024-08-29 13:37:02 1010

原创认识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 717

原创 MUNIK解读ISO26262-软件复用

例如，依据ISO26262的影响分析可能表明，必须重新创建用于验证的检查单（Inspection checklist）（因为检查/Inspection对ASIL B、C和D来说是必要的），因为分析前是以走查（Walkthrough）的形式进行的验证（对于ASIL A来说足够）。在这种情况下，保持不变的软件部分的工作产出物可以被复用。通过上面的讲解，我们能意识到与安全相关的软件的复用可以有很多实际应用场景，接下来必须在ISO26262中确定与特定项目相关的重复使用的具体实践，这里将通过几个例子来讨论。

2024-08-29 13:29:40 786

原创认识R156法规-MUNIK解读标准

总体而言，UN R156法规通过为软件升级设定高标准，不仅提高了汽车的安全性和可靠性，还为汽车制造商在全球市场上提供了更多的机遇和挑战。比如，R156作为统一的国际法规，减少了OEM为满足不同国家法规而进行的重复测试和认证，降低了合规成本，提高了市场进入效率。再如R156要求OEM公开软件升级的相关信息，这有助于消费者和监管机构更好地了解车辆的软件状态，从而增加市场透明度。最后，R156对数据处理和隐私保护的要求促使OEM在设计软件升级系统时更加注重用户隐私，这在现今这样数据敏感的市场尤为重要。

2024-08-29 13:27:17 1085

原创预期功能的必要性与典型案例解析——MUNIK

随着汽车行业的不断发展，人们已经不再满足车辆仅仅作为提高出行效率的简单工具，希望能有有更“聪明的车辆”帮用户解决一部分驾驶带来的困扰。此事件中，该特斯拉Model S驾驶员未遵守Autopilot功能定义的ODD（Operational design domain）界限，在红绿灯场景仍然未接管驾驶责任，属于典型的自动驾驶功能误用案例。随着自动驾驶技术的不断发展，越来越多的功能被集成在车辆上，极大地提升的驾驶者的使用体验。上述因素可以看出，即使在功能实现的情况下，依然不排除有其他可能导致危害行为的事件发生。

2024-07-10 16:33:11 380

原创认识R155法规（UN Regulation No. 155）-MUNIK

随着汽车新四化（电动化、智能化、网联化、共享化）政策的提出，大数据和人工智能等技术的发展，以及软件驱动汽车、舱驾一体、行泊一体等新型架构概念的提出，车内外智能传感器采集的大量数据（包括驾驶员，乘客，车外道路交通环境等）通过通信网络（比如5G蜂窝移动）实时与外部世界互联互通，汽车已经从传统的交通工具转变为可移动的智能终端并承载各类创新应用场景，但是与此同时也增加了被网络黑客攻击的概率。需要注意的是，R155的规定是动态的，随着网络安全威胁的发展和技术的进步，这些要求可能会不断更新。

2024-07-10 15:20:41 1338

原创一文带你快速了解项目ASPICE评估的那些事-MUNIK

32个过程对企业选择也比较难，VDA推荐了16个过程组，红框里面作为ASPICE的一些基本过程，如果企业不知道做哪些过程，可以以这16个过程为基础，当然，企业可以根据自己来选择增加或者减少哪些过程组；它提供了一套标准和指南，帮助组织评估其软件开发过程的成熟度和质量，并提供改进的方法和最佳实践。同时，在本次ASPICE 4.0中进行还了修正和明确了之前ASPICE 3.1的实施过程中经常会遇到的一些困惑和模糊的内容，让ASPICE标准与项目实践更加贴合适用，具体的变化在后续技术文章中再给大家带来分享。

2024-07-10 11:15:44 1170

原创 MUNIK解读ISO26262：安全计划

安全计划是管理和指导开展项目中安全活动的计划，这样是可以系统化的对项目所有的安全活动及进度进行管理。常见的一个误区是，认为项目计划等同于安全计划。项目计划是对项目实施过程中所有的活动进行系统性的规划，其中当然不止功能安全相关事宜。安全计划只是项目计划的一部分。我们也可以将安全计划的内容与项目计划写在同一份文件中，但是要确保安全计划能够明显的识别，也可以将安全计划单独写一份文件，标准中对此有明确的要求。图：项目时间轴。

2024-07-10 11:02:42 752

原创 MUNIK解读ISO26262 : 硬件架构评估及FMEDA(系统级)

汽车功能安全关注汽车电子/电气系统功能的正确、完整、可靠的实现，但由于硬件要素物理因素的限制，不同的硬件要素总会出现各种随意硬件失效，这个是由于要素材质、工艺、技术等因素带来的不可消除的影响。当单点故障被安全机制覆盖时，安全机制覆盖到的部分会生成双点故障，它们单独失效都不会导致安全目标的违背，只有当器件与覆盖它失效模式的安全机制同时失效时才会违背安全目标。此时，考虑增加安全机制来防止双点失效的发生，被安全机制覆盖的部分是可探测和和感知的双点故障，安全机制未覆盖到的部分是潜伏的双点故障。

2024-07-10 10:56:48 1232

原创 MUNIK解读ISO26262--什么是系统安全分析

简单来讲就是安全分析和仿真一样属于产品研发阶段做的事前的分析，它可以预测产品的可靠性，判断系统的鲁棒性并且依据当前的薄弱点设计安全措施并制定持续优化的改进过程。在此篇中我们着重介绍系统阶段的安全分析，其他的不在此处赘述（会在其他的文章中体现，DFA可参考我们之前的文章：“功能安全之DFA相关失效分析”，其余的安全分析类的解读文章会陆续更新）在系统阶段的作用是通过SG导出FSR，通过FSR导出TSR，适用于复杂的系统，该方法是可选择的（不一定必须使用），在我们的前期分享的标准解读文章（

2024-07-05 15:55:19 1092

原创 MUNIK解读ISO26262--系统架构

通过在设计阶段就充分考虑安全需求，采用分层的安全策略，设计安全关键组件，以及进行严格的安全验证和确认，可以有效地提高系统的安全性。个模块之间少不了有通讯或者系统层级需要有程序的烧录等情况出现，模块可能会通过CAN，CAN-FD，UART，I2C，SPI，PHY等进行片内或片外、板内或板外的通讯或者程序的烧录，下面以串口UART举例说明通讯模块的安全机制都有哪些。综上所述，系统架构设计是我们在产品开发中不可忽视的重要阶段，下面我们着重探讨“系统的架构类型”和“系统架构层级相关的安全机制”。

2024-07-05 15:48:59 1067

原创 MUNIK解读ISO26262--什么是功能安全文档

功能安全强调工作成果的追溯性，文档管理可以很好的实现这个要求，所以文档管理对功能安全来说也是必要的。对于已经建立质量体系的企业来说，文档管理应当已经有一个健全的系统在运作了，这时我们只需要识别现有的文档管理的程序与功能安全要求的文档管理有什么出入即可，没必要单独为功能安全体系建立一个新的文档管理程序。当然，不排除也有企业还未建立或正在建立功能文档管理程序，此时就需要考虑在满足功能安全体系文档管理的条件下，如何适配其他体系的文档管理任务，尽可能做到覆盖企业所有文档均能够通用的情况最佳。

2024-07-05 15:35:51 349

原创 MUNIK解读ISO26262--什么是DFA

首先DFA（相关失效分析）的执行与ASIL没有关系，这是与FMEA还有FTA明显的一个区别，其次就是在架构设计过程中若产生了ASIL分解，有要素共存的情况（低等级的要素我们通常会认为他的开发要求不够严谨，可能会对高要求的产品造成不利影响），有冗余设计，功能电路和安全机制等情况时，那么就要执行相关失效分析。：假设我们的架构设计中存在PLL(锁相环，实现外部输入信号与内部震荡信号同步)和对其的监控电路CMC，它们之间的关系就属于功能电路和安全机制的关系，所以我们要分析这两者会不会发生相关失效。

2024-07-05 15:33:42 838

原创 MUNIK解读ISO26262--什么是变更管理

（3）变更对功能安全的潜在影响；在完整的项目生命周期内，变更管理并不是为了拒绝变更，而是通过变更管理来控制变更，使得变更带给项目的影响变得有序可控，因此在项目启动时，建立变更管理制度和相关流程规范，以便指导和规范执行变更的相关人员进行项目变更行为。变更结束前，应当记录变更的相关明细、变更的工作产品清单和变更对象信息，并给出变更的实施时间。变更管理的目的是在整个功能安全生命周期中,分析和控制功能安全相关工作成果、相关项和要素的变更，同时在整个安全生命周期内维护工作成果、相关项和要素的相关功能和特性。

2024-07-05 15:24:25 316

原创 MUNIK解读CMMI-带你认识什么是CMMI

4级:量化管理级：在3级基础上，依据公司年度目标，制定部门和项目的量化目标，通过建立数据模型和数据基线等数据统计方法论，实现对项目目标的预测和过程方法的优化，提升项目的资源利用率，实现项目的成本、过程、质量精准管控、极大地提升了项目的开发管理水平。5级：优化改进级：在4级基础上，依据公司的发展战略和规划，制定项目量化目标，不断优化和改进开发资源组合，不断优化资源配置，从技术变革、公司业务革新方面全面提升公司能力。2级：已管理级：在1级基础上，部分过程具有简单的流程控制，有完整的方法，能满足过程控制的目标。

2024-07-04 14:19:05 498

原创 MUNIK解读ISO26262--验证活动之认可措施

它关注的内容就比较全面和细致，不仅关注产品的开发流程是否符合标准（这里其实也就是Audit的内容，所以标准有提到Audit的内容是可以纳入到Assessment中的），还要关注所有工作成果的合理性，完整性（因为是所有的工作成果，当然也包含CR中的工作成果，所以CR的结果也可以是Assessment的一部分）。注：虽然这三个活动的名称意思比较相近，但是在ISO 26262中是有特指意义的，所以在实际执行的时候是要区分清楚，并且在一些文档的描述上要注意用词的准确性。下图就是标准对于Audit独立性的要求。

2024-07-04 14:00:32 912

原创 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 920

原创 MUNIK解读ISO26262--ASIL分解详解

在上面我们提到了ASIL分解要将分解后的需求分配到相互独立的要素上，这是一个必须满足的条件，因为ASIL分解本质概念是冗余，冗余就要求组件之间不存在共因失效或者级联失效，那么怎么来证明要素之间互相冗余？这里有必要说明一下，冗余并非是直接使用两个相同的组件互相备份，这种直接复制组件的方式称为同构冗余，同构冗余的两个组件是缺乏要素间的独立性的，因为同样的组件大概率是会存在相同的系统性失效，而系统性失效是我们在开发功能安全产品时是要尽可能避免的，所以一般会采用功能相同，设计存在明显区别的组件进行互相冗余。

2024-07-04 11:39:26 1413

原创 MUNIK解读ISO26262--Item定义及HARA活动

例如，HWP（高速路自动驾驶）相关项完成功能时，感知系统（雷达、摄像头）提供道路信息，控制器（SoC、MCU）处理接收到的信息并运算最佳行驶轨迹，执行器实现控制器下达指令完成纵向、横向的整车运行调整。例如：车辆的高速领航功能，由智驾域控（SoC），感知系统（雷达、摄像头等）以及动力系统可以组成一个完整的车辆功能，这个系统组合就是一个相关项。从图中我们可以看出，单一的系统是相关项的最低限度也是要素的最高限度；E0（几乎不可能发生）、E1（低概率）、E2（中等概率）、E3（高概率）、E4（非常高概率）。

2024-07-04 11:35:10 923

原创 MUNIK解读ISO26262--验证活动之认可措施

它关注的内容就比较全面和细致，不仅关注产品的开发流程是否符合标准（这里其实也就是Audit的内容，所以标准有提到Audit的内容是可以纳入到Assessment中的），还要关注所有工作成果的合理性，完整性（因为是所有的工作成果，当然也包含CR中的工作成果，所以CR的结果也可以是Assessment的一部分）。注：虽然这三个活动的名称意思比较相近，但是在ISO 26262中是有特指意义的，所以在实际执行的时候是要区分清楚，并且在一些文档的描述上要注意用词的准确性。下图就是标准对于Audit独立性的要求。

2024-07-04 11:16:47 682

原创 MUNIK解读ISO26262--硬件开发阶段详解

硬件设计包括硬件架构设计和硬件详细设计，硬件架构设计表示所有的硬件组件以及他们彼此的相互关系，从安全的角度来看，硬件的设计应该能够满足对硬件的安全要求，这种设计是为了提供功能安全和保障硬件的实际功能，可以确保系统在面对各种故障和异常情况时仍能保持安全状态，因此，设计中就必须要考虑安全机制的存在。确保硬件设计能达到必要的汽车安全完整性等级。硬件可能是基于多个样本迭代开发的，基于在集成和验证阶段的问题发现，对需求分析进行更新，再进行硬件设计的调整和安全分析，在成功集成和测试后完成硬件研发并进行工作成果的发布。

2024-07-04 11:14:29 914

原创功能安全软件开发阶段---软件测试验证

根据图一软件开发阶段V模型，软件单元设计和实现之后，需要对相应的软件设计进行测试验证即V模式右边内容。具体包括：软件单元验证、软件集成和验证、嵌入式软件验证。本文着重阐述功能安全软件开发阶段中这三个阶段的测试验证活动。图一：软件开发阶段V模型1、软件测试验证方法。

2024-07-01 13:17:12 816

原创解读ISO26262功能安全验证与确认（Verification and validation）

安全验证和确认是两个独立但相互关联的功能安全活动，验证贯穿于安全生命周期中的每一个执行阶段，通过使用各种技术和方法来验证系统实际的安全性能，这可能包括进行仿真、模拟、测试和评估等活动，以验证系统设计和实现的安全性。评估就是对安全确认的结果进行评估，可以聘请专家小组参与评估活动，具体的方式可采用评审检查的方式进行：对以上确认活动进行评估，确认系统的最终安全性，并出具评估报告。安全确认是通过测试、评估和分析整个开发过程中的安全性活动，确认集成到目标车辆的相关项实现了其安全目标，并提供最终的安全评估报告。

2024-06-28 15:38:00 3150

空空如也

空空如也