开启全网商机
登录/注册
浙江万向精工有限公司--EMB功能安全工程化
招标详情
下文中****为隐藏内容，仅对千里马会员开放，如需查看完整内容请
「注册/登录」或 拨打咨询热线：
400-688-2000
相关单位：
***********公司企业信息
EMB功能安全工程化技术任务书
1 总则
1.1 范围
本附件用于明确乙方在EMB系统（EMB主副控制子系统+轮边控制子系统）功能安全项目中须提交的工程化交付物清单、交付要求及验收标准，作为甲方付款、阶段验收及最终认证的重要依据。
图1：EMB系统范围图
1.2 要求
所有交付物须满足以下基本要求：
﹒ 基于本项目真实技术方案形成；
﹒ 内容完整、结论明确、具备可追溯性；
﹒ 可直接用于整车厂或第三方认证机构审核；
﹒ 乙方提供咨询服务，需安排独立的第三方对甲方进行审核，并获得产品级的ASIL D证书。
1.3 特殊说明
以下若无特殊说明，各交付物均包含EMB系统（EMB主副控制子系统与EMB轮边控制子系统）两个部分。
2 功能安全管理
2.1交付物清单
| 类别 |
交付物 Work Product |
甲方 |
乙方 |
备注 |
| 整体安全管理 |
组织的专门的功能安全规章和流程 |
R |
S |
****公司提供初版的规章和流程。 乙方与甲方共同讨论修改，乙方培训，导入，甲方负责批准、执行和持续维护； |
| 能力证据 |
R |
S |
****公司都需提供各自的能力证据；乙方提供咨询服务 |
|
| 质量管理证据 |
R |
S |
****公司都需提供各自的能力证据； 乙方提供咨询服务 |
|
| 安全异常识别报告 |
S/A |
R |
乙方主导完成，甲方核对 涵盖产品开展中安全异常或问题清单，安全异常关闭报告，阶段或项目结束时移交 |
|
| 项目相关的功能安全管理 |
相关项层面影响分析 |
S/A |
R |
乙方主导完成，甲方核对 每次安全相关变更后，重新进行item层影响分析，明确受影响的安全目标，需求，架构、分析及确认活动 |
| 要素层面影响分析 |
S/A |
R |
乙方主导完成，甲方核对 每次安全相关变更后，重新进行要素层影响分析，明确受影响的安全目标，需求，架构、分析及确认活动 |
|
| 安全计划 |
S/A |
R |
乙方主导完成，甲方核对 在项目发展阶段持续更新，反映实际进展、延期、偏差和未关闭问题 |
|
| 安全档案 |
R |
S |
甲方主导，乙方辅导支持 |
|
| 认可评审报告/功能安全审核报告/功能安全评估报告 |
S/A |
R |
乙方安排第三方认证机构审核，要求北德，南德，德凯，SGS，DNV，劳盛等的功能安全产品ASIL D认证证书 确认措施必须保证独立性 |
|
| 生产发布报告 |
R |
S |
甲方主导完成，乙方辅助辅导 |
|
| 与生产，运行，服务和报废相关的功能安全管理 |
与生产，运行，服务和报废相关的功能安全管理的证据 |
S/A |
R |
依据甲方的实际情况，获得甲方的认可 |
3 概念阶段功能安全交付物
3.1 交付物清单
| 类别 |
交付物 Work Product |
甲方 |
乙方 |
备注 |
| 危害分析和风险评估 Hazard analysis and risk management |
相关项定义 Item definition |
A |
R |
乙方主导完成，获得甲方批准认可 |
| 危害分析和风险评估报告 Hazard analysis and risk assessment |
A |
R |
乙方主导完成，获得甲方批准认可 |
|
| 安全目标及安全状态定义，FTTI时间 |
A |
R |
乙方主导完成，获得甲方批准认可 |
|
| 危害分析和风险评估以及安全目标的验证评审报告 Verification of the hazard analysis and risk assessment |
A |
R |
甲方进行批准认可 |
|
| 涉及整车架构与安全分析 vehicle architecture and safety analysis |
整车安全架构 Vehicle Safety Architecture |
A |
R |
乙方主导完成，甲方进行批准认可 |
| 整车安全分析（FMEA,FTA） Vehicle Safety Analysis (FMEA, FTA) |
A |
R |
乙方主导完成，甲方进行批准认可 |
|
| 功能安全概念 Functional safety concept |
功能安全概念FSC Functional Safety Concept |
A |
R |
乙方主导完成，甲方进行批准认可 |
| 功能安全要求FSR Functional Safety Requirements FSR |
A |
R |
乙方主导完成，甲方进行批准认可 |
|
| 功能安全概念验证报告 Verification of the functional safety concept |
R |
S |
甲方进行实车测试 |
3.2 工程化验收标准
﹒ Item Definition 明确系统边界、接口定义（通信、电源、状态管理及诊断接口）及工作场景；
﹒ HARA 覆盖目标系统典型使用与失效工况（如：覆盖EMB典型失效工况：制动功能丧失、非预期制动，制动力分配错误，制动响应延迟等）每个危害时间的S/E/C评估及依据，典型工况下对应的SG与FTTI时间（需进行仿真或其方式进行对应），所有都清晰可追溯；
﹒ 安全目标与整车风险场景具备清晰逻辑关联；
﹒ FSC 中每一条功能安全需求可追溯至安全目标，安全状态（如EMB的降级，故障处理，冗余）；
﹒ 整车功能架构定义，明确整车与EMB系统之间的功能关系；
﹒ 功能安全需求责任分配，明确整车与EMB系统之间的安全职责，每条参数都能进行追溯；
﹒ 明确整车的安全机制策略，包括监控、诊断、降级、故障处理及冗余策略。
4 系统阶段功能安全交付物
4.1交付物清单
| 类别 |
交付物 Work Product |
甲方 |
乙方 |
备注 |
| 技术安全概念 Technical safety concept |
技术安全需求规范 |
S/A |
R |
乙方主导完成 1.EMB的主系统技术要求； 2.EMB系统的需求矩阵，与EMB主副控，轮边控制器形成追溯矩阵，3.EMB主副控，轮边控制器的技术文档需与HSR,SSR形成追溯矩阵 |
| 技术安全概念 |
S/A |
R |
乙方主导完成 EMB系统的安全机制，与EMB主副控，轮边控制器的安全机制，并形成追溯矩阵 系统安全状态与降级策略，系统安全机制及故障反应矩阵； |
|
| 系统架构设计规范 |
R |
S |
第一层：EMB系统架构含EMB主副控与4路轮边控制器； 第二层：EMB主副控子系统与单轮轮边控制子系统系统架构； 含系统状态机与降级策略规范 甲方提供初版系统设计（不局限形式，能理解当前设计即可），乙方在其上补充安全要素 含系统接口安全规范 ； |
|
| 软硬件接口（HSI）规范 |
R |
S |
甲方提供产品HSI，供乙方增加安全相关部分插入ASIL属性,并完善输出规范 |
|
| 生产、运行、服务和报废需求规范 |
S/A |
R |
甲方提供EOL测试规范，供乙方了解如何开展对安全相关的组件进行修正 |
|
| 系统架构设计，软硬件接口规范，生产、运行、服务和报废需求规范，技术安全概念的验证报告 |
S/A |
R |
和甲方联合评审乙方交付内容 |
|
| 安全分析报告 |
S/A |
R |
包括FTA，DFA，FMEA中安全相关的内容。分两层（EMB系统安全分析，EMB主副控安全分析，EMB轮边安全分析，并形成追溯关系） |
|
| 系统和相关项的集成与测试 System and item integration and testing |
集成和测试策略/用例 |
S/A |
R |
乙方完成测试用例的编写（测试用例需追溯TSR,TSC,系统架构，接口定义等形成追溯），甲方负责测试执行 |
| 集成测试报告 |
R |
S |
乙方和甲方协商完成测试执行和报告生成及Review |
|
| 系统合格性/安全性测试 System qualification/safety testing |
系统安全验证规范及用例 System Security Verification Specification and Use Cases |
S/A |
R |
乙方完成测试用例的编写（测试用例需追溯TSR,TSC,系统架构，接口定义等形成追溯），甲方负责测试执行 |
| 系统安全要求符合性测试报告 System Saftey Compliance Test |
R |
S |
乙方和甲方协商完成测试执行和报告生成及Review |
|
| 系统安全确认/验证计划 System Security Confirmation/ Verification Plan |
R |
S |
乙方和甲方协商完成测试执行和报告生成及Review |
|
| 实车安全测试 Real vehicle safety testing |
EMB域控的实车安全测试用例 Real vehicle safety test cases for EMB domain control |
S/A |
R |
乙方完成测试用例的编写（测试用例需追溯TSR,TSC,系统架构，接口定义等形成追溯），甲方负责测试执行 |
4.2 工程化验收标准
﹒ TSC 明确监控对象、安全目标对应的安全机制、监控主体、监控方式、故障检测时间、故障成熟条件与时间、故障反应时间、FTTI 与安全状态，降级状态及恢复条件；
﹒ 系统安全需求可追溯至硬件或软件安全机制，每条TSR双向追溯到FSR和安全目标，并分配到系统架构元素，系统接口，软硬件需求中与外部执行机构；
﹒ 系统架构应清晰区分EMB系统层级（EMB主副控与4轮轮边控制）、单轮控制子系统层级，并明确主副控、四个轮边控制器、通信、供电、执行机构之间的功能和安全责任。
﹒ 主副控、轮边控制器及整车之间与安全相关系统接口应定义数据源、接收方、ASIL属性，量纲，范围，精度，周期，超时，初始值、无效值、E2E保护，合理性检查及故障反应。
﹒ 明确EMB主副控制器，轮边控制器的正常状态，初始化状态，降级状态，紧急运行状态，安全状态和恢复状态，并明确状态进入条件、退出条件、允许功能，最大持续时间和状态转换时间。
﹒ 明确每项安全机制应保护的目标，覆盖的失效模式，检测条件、检测时间、故障反应、失效后系统能力及安全机制自身失效的监控方式；
﹒ FMEA / FTA 结论与具体安全机制一一对应，与TSR，HSR,SSR形成的闭环，安全分析应覆盖系统边界内的安全相关功能链、接口和故障传播路径，识别出的缺口、未覆盖失效、共因失效，双方讨论后形成整改措施与关闭证据，并更新到TSR中；
﹒ DFA重点应分析主副控，双CAN，双供电，共用通信源，相同软件算法、相同标定和相同开发过程所引起的共因失效及级联失效，共因失效的根本原因需深入分析，制动具体防护措施，措施更新到TSR中；
﹒ 架构设计、安全机制、冗余切换、故障反应和降级策略能够在样机，台架，HIL或实车环境中通过正常场景测试及故障注入测试，包括通信、供电、执行器偏差、主副控切换、MCU异常及驱动异常等故障。
﹒ 系统集成测试和系统合格性测试用例应覆盖正常、边界、异常、降级、安全状态及恢复场景，并实现TSR与测试用例，测试结果的双向追溯；
﹒ 对涉及FTTI的安全机制，完成时间链分析和测试方法，证明故障检测、确认及反应在FTTI内完成，通过HIL台/台架验证；
﹒ FSR和TSR应明确责任主体，EMB系统对整车的责任分配，EMB主副控与轮边控制器的责任分配，轮边控制器执行机构的责任分配，并获得双方的认可；
﹒ TSR、TSC、系统架构、安全分析及系统测试用例、测试策略与报告应按照ASIL等级要求进行编写与验证，此过程中产生的问题双方讨论后形成整改措施与关闭证据。
﹒ 系统阶段结束形成未关闭的问题清单，残余风险、假设条件等。
5 硬件功能安全交付物
5.1 交付物清单
| 类别 |
交付物 Work Product |
甲方 |
乙方 |
备注 |
| 硬件安全要求的定义 Specification of hardware safety requirements |
硬件安全需求规范（包括测试和认可准则） |
S/A |
R |
乙方完成HSR，HSR需包含ASIL，安全状态或降级状态，安全机制，故障检测时间，故障反应时间，FTTI分配，诊断测试时间间隔，允许的故障容忍时间，随机硬件失效指标分配，环境条件，电压、温度、EMC等约束，验证准则，依赖的外部措施，软硬件的责任边界等； 所提交的文档需经过甲方认可； |
| 软硬件接口规范（细化的） |
R |
S |
甲方提供产品的初步HSI定义，乙方指导评审 |
|
| 硬件安全要求验证报告
|
R |
S |
和甲方完成评审，并出认可报告 |
|
| 硬件设计 hardware design |
硬件设计规范 |
R |
S |
供方线下来到甲方现场，依据需方的资料（原理图、BOM、PCB、器件规格书），双方共同评审安全相关的硬件架构定义，安全机制设计审查，安全需求补充及安全分析。双方共同负责HSR,HSI，硬件设计安全评审，安全分析评审，甲方负责设计修改落地，乙方负责验证修改后的安全符合性 |
| 硬件安全分析报告 |
S/A |
R |
HW FTA，HW DFA，乙方依据甲方的模块提供安全分析案例(CAN模块，电源模块，电机驱动模块，MCU模块，轮速模块,力传感器模块，转角传感器模块，温度模块，EPB开关，EPB驱动模块，踏板行程模块，IMU模块)，甲方依据案例进行适配，乙方对甲方的文档进行安全要素的检查 |
|
| 硬件设计验证报告 |
R |
S |
乙方提供硬件设计验证检查表，并协助甲方完成硬件设计验证 |
|
| 与生产、运行、服务和报废相关的需求规范 |
S/A |
R |
合并在HSR中 |
|
| 硬件架构度量的评估 Evaluation of the hardware architectural metrics |
相关项架构应对随机硬件失效的有效性的分析 |
R |
S |
EMB系统（EMB主副控子系统+EMB轮边子系统） EMB轮边（电机执行机构纳入，力传感器纳入） FMEDA边界，数据源和假设需定义清晰，主芯片按功能展开； 安全机制有效性和诊断覆盖率证据，诊断测试间隔，潜伏故障暴露时间，多点故障组合原则，残余风险，需满足目标ASIL对应要求； SPFM,LFM,PMHF计算及结论，元器件失效率来源，失效模式分布来源； 潜伏故障的处理； 乙方提供现场支持； |
| 相关项架构应对随机硬件失效的有效性评估的验证报告 |
S/A |
R |
和甲方完成评审，并出具VR报告 |
|
| 随机硬件失效导致违背安全目标的评估 Evaluation of the safety goal violations due to random hardware failures |
由随机硬件失效导致违背安全目标的分析 |
S/A |
R |
当PMHF、SPFM、LFM不满足或存在不可接受残余风险时，可以导出： 1、新增硬件诊断； 2、增强软件诊断； 3、缩短诊断周期； 4、增加独立关断路径； 5、增加冗余采样； 6、增加外部监控； 7、增加周期自检； 8、调整器件选型； 9、调整系统降级策略； 10、增加维修检测； 以上意见与TSR/HSR/SSR形成闭环 |
| 硬件专用措施的定义，如果需要，包括专用措施有效性的依据 |
S/A |
R |
||
| 对随机硬件失效导致违背安全目标进行评估的评审报告 |
S/A |
R |
||
| 硬件集成和测试 Hardware integration and verification |
硬件集成和验证规范 |
S/A |
R |
乙方负责安全相关的测试计划和故障注入测试用例设计（按照ISO26262要求的ASILD等级开展），其他电性能，DV测试用例等甲方负责 |
| 硬件集成和验证报告 |
R |
S |
甲方负责测试执行和报告生成，乙方负责支持和Review |
5.2 工程化验收标准
﹒ FMEDA 基于实际原理图、BOM 及器件数据，PCB关键设计、电源架构和接口定义进行分析，元器件失效率数据应具有可追溯来源，供方应说明数据采用的标准、数据库，器件手册或工程判断依据；
﹒ FMEDA应清晰分类安全故障、单点故障、残余故障、已检测多点故障，潜伏多点故障及非安全相关故障，并辅导需方了解计算过程、边界、假设和结论，故障的判定应与具体安全目标、硬件安全需求、安全机制及故障反应追溯关系；
﹒ 安全机制落实到具体器件与电路，安全机制不得仅以芯片手册声明作为有效性证据，应结合实际电路连接、软件配置、测试模式和应用条件进行确认；
﹒ 安全机制的失效纳入FMEA、FTA、DFA或FMEDA分析，必要时应设计二级监控或周期性检测
﹒ 测试结果能够支撑 FMEDA 与安全机制结论。
﹒ HW FTA从系统安全顶事件或TSR向下分解至可分析的硬件基本事件，并与FMEDA和硬件FMEA保持一致；
﹒ HW FMEA应覆所有安全相关硬件模块、接口和关键器件，识别失效模式、影响、原因、现有措施及改进措施；
﹒ HW DFA应识别共用电源、地、时钟、复位、通信、相邻线路，热耦合、EMC及器件同质性可能造成的共因和级联失效；
﹒ 分析中识别的安全缺口，应导出或修改TSR、SSR、HSR，硬件设计要求或系统安全措施，形成闭环跟踪；
﹒ 硬件设计应明确主输出关键路径，独立安全路径，故障隔离路径及降级运行路径；
﹒ 硬件集成与验证应覆盖正常工况、边界工况、异常工况及故障注入场景，故障注入应覆盖关键电源、时钟、复位、通信、驱动器、存储器和诊断机制故障；测试应验证安全机制的检测能力，诊断覆盖范围、检测时间、反应时间和安全状态，并证明满足分配的FTTI，测试结果应能够支撑FMEDA中的诊断覆盖率，故障分类，SPFM,LFM,PMHF结论；
﹒ 硬件阶段未关闭问题，残余风险假设条件形成文档输入到part6的软件需求清单；
﹒ 存在以下任何一项，part5不得验收通过：
(1)FMEDA不是基于受控版本的实际原理图和BOM；
(2)元器件失效率或失效模式分布无来源；
(3)SPFM、LFM、PMHF仅有结果，无计算过程；
(4)主控副控、轮边的FMEDA边界不清；
(5)关键安全机制未落实到具体器件、电路或HSI；
(6)安全机制仅引用芯片手册，未结合实际设计验证；
(7)诊断覆盖率没有分析依据或测试证据；
(8)潜伏故障未定义诊断测试间隔；
(9)FTA、FMEA、DFA与FMEDA结论相互矛盾；
(10)安全分析识别出的缺口未导出需求或整改措施；
(11)关键安全机制未开展故障注入；
(12)未指导验证检测时间和故障反应时间；
(13)测试样件、原理图、BOM与FMEDA版本不一致；
(14)HSR不能追溯到TSR或不能追溯到验证证据；
(15)仍存在可能直接违反安全目标的未处理单点故障。
6 软件功能安全交付物
6.1 交付物清单
| 类别 |
交付物 Work Product |
甲方 |
乙方 |
备注 |
| 软件层面产品开发概述 General topics for the product development at the software level |
软件开发环境 |
R |
S |
软件开发计划； 软件安全计划及ASIL适用方法； 编码规范、建模规范； 编译器、链接器、代码生成器、静态分析工具版本； 工具置信度评估或工具鉴**论； 软件配置管理策略； 软件变更管理和问题管理流程； 第三方软件、开源软件及既有软件组件管理； 模型、代码、标定数据和配置数据的一致性管理 |
| 软件安全要求的定义 Specification of software safety requirements |
软件安全需求规范 |
S/A |
R |
乙方完成ASW+BSW+CDD需求 ASW:制动请求处理，主副控制权管理，轮边目标控制，目标与实际执行偏差监控，降级与安全状态，故障确认和恢复策略； BSW：依据系统覆盖OS任务调度，通信栈，E2E，NVM，诊断服务，时间监控，程序流监控，启动流监控；启动和关机管理，bootloader安全相关功能。 CDD：PWM输出，ADC采样，电机驱动使能和关断，电流、位置、夹紧力采集， SBC、PMIC、驱动芯片故障读取，CAN控制器及收发器诊断，独立硬件安全路径控制。 此项工作需得到甲方认可 |
| 软硬件接口规范（细化的） |
R |
S |
合并到“四、硬件功能安全交付物”-“软硬件接口规范（细化的）” 将初始化顺序、信号极性，安全默认值，寄存器配置，故障寄存器解释，诊断周期，中断优先级，关断路径，故障注入口，硬件故障到软件状态的映射，此阶段软件侧HSI细化 |
|
| 软件验证报告 |
S/A |
R |
和甲方完成评审，并出具VR报告 |
|
| 软件架构设计 Software architectural design |
软件架构设计规范 |
R |
S |
乙方提供参考用例，软件架构设计应覆盖所有安全相关软件组件，并识别非安全软件或低ASIL软件对高ASIL软件的潜在干扰，定义分区、隔离和**保护措施。 软件架构至少应包括： ASW、BSW、CDD分层； 软件组件和接口； 数据流和控制流； 任务和中断架构； 初始化和关机顺序； 主副控状态机； 故障管理架构； 降级状态； Watchdog架构； 通信与E2E架构； NVM架构； 诊断架构； 安全机制分配； 时间和**预算； 软件分区； 共享**管理； 模式管理； 标定和配置管理。 形**全机制矩阵 ASW 内各功能模块的 ASIL 等级 独立的应用层功能安全监控模块 MBD 建模规范检查集 执行MIL与SIL等价性测试 建立满足 ASIL D 要求的结构覆盖率指标 安全关键控制与标定参数必须在 ASW 内部具备上下限饱和保护与非法值校验机制 此项工作全程辅导甲方完成 |
| 安全分析报告 |
S/A |
R |
基于每个分配ASIL属性的安全组件的SW FMEA |
|
| 相关失效分析报告 |
S/A |
R |
基于每个分配ASIL属性的安全组件的SW DFA 重点分析：不同ASIL等级软件共存，ASW、BSW、CDD之间的依赖关系，共用任务，共用内存，共用栈，共用时钟，共用通信缓冲区，共用NVM，共同标定数据，共同故障管理，相同算法和相同模型，主副控相同软件版本，单个OS错误对多个安全组件的影响，单个配置错误同时影响多个安全通道，需证明或评估：空间隔离、时间隔离、通信隔离、执行顺序隔离、数据完整性、**耗尽防护、故障传播限制； 验证：高优先级QM任务不会饿死安全任务；栈溢出不会破坏其他任务，非安全模块不能改写安全数据，DMA不能越界访问，中断不会破坏FTTI，通信洪泛不会沾满CPU，NVM写入不会阻塞关键制动控制，诊断服务不会影响实时制动； |
|
| 软件架构安全验证评审报告 Software verification (refined) |
R |
S |
乙方提供软件安全验证检查表，并辅助甲方联合评审 |
|
| 软件单元设计和实现 Software unit design and implementation |
软件单元设计规范 |
R |
S |
乙方负责交付芯片级安全监控模块SafeMCU: 包括RH850U2，FS26安全机制 实践式指导客户实现基于Task层级的alive，deadline和logic监控和配置。 实践式指导客户实现OS的MPU，Time，Runtime，Stack等监控和配置。 实践式指导客户实现包括关断路径，电源供电，SBC的芯片监控机制，Driver安全机制，E2E，B2B，C2C等。 实践式指导客户实现安全应用功能的模型开发 乙方负责的软件交付，该工作包内容包括： |
| 软件单元实现 |
||||
| 软件单元验证 Software unit verification |
软件单元验证规范 |
|||
| 软件单元验证报告（细化的） 静态验证、软件单元测试、软件安全机制故障注入 |
||||
| 软件集成和验证 Software integration and verification |
软件集成验证规范及测试用例（细化的） |
S/A |
R |
乙方完**全部分的软件集成测试验证计划和测试用例设计 测试用例需区分： 软件单元集成,ASW组件集成,ASW与BSW集成,ASW/BSW与CDD集成,软件与HSI集成,主控副控软件集成，主副控与轮边通信集成，嵌入式目标软件测试； 集成测试应覆盖：接口数据正确性，调用顺序，任务调度，中断，时间预算，数据一致性，初始化，掉电，复位，故障传播，并发访问，**竞争，降级状态，恢复状态，多故障组合； |
| 嵌入式软件 |
R |
S |
乙方指导甲方完成供方安全软件，与甲方软件的集成 |
|
| 软件验证报告（细化的） |
R |
S |
和甲方完成评审，并出具VR报告 |
|
| 嵌入式软件测试 Testing of the embedded software |
嵌入式软件验证规范及测试用例（细化的） |
S/A |
R |
乙方完成在HIL或者目标硬件环境，基于SSR的测试计划和用例设计 |
| 软件验证报告（细化的） |
R |
S |
和甲方完成评审，并出具VR报告 |
|
| 软件配置 Software configuration |
配置数据规范 |
R |
S |
指导甲方完成标定指南规范，配置指南等输出 |
| 标定数据规范 |
||||
| 配置数据Configuration data（CAN路由器、E2E配置、OS任务周期、中断优先级、watchdog窗口、MPU区域、故障反应、NVM布局，诊断掩码等） |
||||
| 标定数据Calibration data（制动力限值，目标与实际偏差阀值、故障确认时间、降级阀值、电压阀值、温度阀值、主副控切换阀值、电机堵转判断阀值等） |
||||
| 验证规范（细化的） |
||||
| 验证报告（细化的） |
||||
| 软件架构设计规范 |
||||
| 软件开发环境 |
6.2 工程化验收标准
﹒ SSR 应完整承接TSR、HSR及HSI输入，并覆盖ASW、BSW、CDD以及安全相关配置和标定需求，每条SSR应明确ASIL属性、触发条件、输入输出、时间约束、故障检测、故障反应、安全状态、验证方法及通过准则。 SSR应双向追溯至上游TSR或HSR，并分配至具体软件组件、软件单元、配置项、标定项及验证用例；
﹒ 交付的软件为白盒，覆盖 MCU/SBC控制相关的关键安全机制。每项软件安全机制应明确监控对象、实现组件、检测条件、检测时间、故障确认、故障反应、安全状态和验证方式；
﹒ 软件FMEA、软件FTA及软件DFA应基于实际软件架构、接口、任务和代码结构开展，并与SSR、安全机制及测试证据建立追溯。软件安全分析发现的缺口应导出或修改SSR、HSI、软件架构、软件单元设计、配置数据或系统安全措施，并形成闭环记录；
﹒ 测试用例与安全需求具备可追溯关系。
﹒ 软件架构应明确ASW、BSW、CDD的分层、接口、任务、中断、数据流、控制流、状态管理、故障管理和安全机制分配。软件架构应分析不同ASIL等级及QM软件共存时的自由干扰，并验证空间隔离、时间隔离、通信隔离和**保护。软件架构应明确CPU、RAM、Flash、栈、任务周期、最坏执行时间和通信负载预算，并验证在最坏工况下满足FTTI；
﹒ 软件单元设计应与SSR及软件架构一致，并明确接口、算法、数据类型、范围、精度、状态、异常处理及时序约束。软件单元测试应覆盖正常值、边界值、异常值、状态转换、故障路径和恢复路径；
﹒ 软件实现应遵循适用编码和建模规范，静态分析告警及规范偏差应具有评审和批准记录；
﹒ 软件结构覆盖应满足对应ASIL适用方法要求，未覆盖代码必须形成不可达性或合理性分析及评审结论；
﹒ 软件集成应按照受控集成策略开展，并验证ASW、BSW、CDD、OS、通信栈、驱动和HSI之间的接口及交互。软件集成测试应覆盖初始化、正常运行、故障运行、降级、安全状态、恢复、复位和掉电场景；
﹒ 关键软件安全机制应通过故障注入验证，并证明故障检测、确认和反应时间满足分配的FTTI；
﹒ 嵌入式软件应在目标硬件或具有代表性的目标环境中进行验证，并覆盖最坏CPU负载、栈使用、任务抖动、通信负载和时序条件；
﹒ 配置数据和标定数据应明确安全属性、合法范围、默认值、完整性保护、访问权限、版本兼容性和变更审批要求；
﹒ 安全相关配置和标定数据应通过边界值、非法值、完整性破坏和版本不匹配测试进行验证；
﹒ 第三方软件、既有软件、OS、BSW、MCAL及安全库应提供适用性、接口约束、使用假设和验证证据；
﹒ Part 6结束时应提交未关闭问题、残余风险、使用假设、外部依赖及软件发布基线清单；
﹒ 出现下列任一情况，part6不应通过验收：
(1)SSR不能追溯至TSR或HSR；
(2)SSR未分配到具体软件组件或软件单元；
(3)主副控、轮边安全软件职责不清；
(4)软件架构未分析QM或低ASIL软件对高ASIL软件的干扰；
(5)ASW、BSW、CDD之间的安全接口未定义；
(6)安全机制只有名称，没有检测条件、时间和故障反应；
(7)软件FMEA、FTA、DFA未基于实际架构和代码结构；
(8)静态分析存在未关闭的高严重度问题；
(9)编码规范偏差无批准和安全影响分析；
(10)单元测试或集成测试不能追溯至SSR；
(11)结构覆盖不足且没有合理性说明；
(12)关键安全机制未进行故障注入；
(13)未验证任务时序、CPU负载、栈和WCET；
(14)未证明故障检测与反应满足FTTI；
(15)配置或标定值可越界修改而没有保护；
(16)第三方BSW、OS或安全库仅直接使用，未进行适用性评价；
(17)软件、模型、生成代码、配置、标定和测试版本不一致；
(18)仍存在可能直接导致安全目标违背的未关闭软件故障路径。
7 生产和运行
7.1 交付物清单
| 交付物 Work Product |
甲方 |
乙方 |
备注 |
||
| 生产，运营，服务，报废的计划 |
生产计划的安全相关内容 |
R |
S |
||
| 生产控制计划（含测试计划）的安全相关内容 |
R |
S |
|||
| 可生产性需求规范 |
R |
S |
|||
| 生产过程能力的评估报告 |
R |
S |
|||
| 服务计划中与安全相关的内容 |
R |
S |
|||
| 服务说明中与安全相关的内容 |
R |
S |
|||
| 用户须知信息中与安全相关的内容 |
R |
S |
|||
| 报废说明中与安全相关的内容 |
R |
S |
|||
| 与运行、服务和报废相关的需求规范 |
R |
S |
|||
| 援助服务说明中与安全相关的内容 |
R |
S |
|||
| 生产 |
控制措施报告 |
R |
S |
||
| 生产过程能力的评估报告 |
R |
S |
|||
| 运行、服务、和报废 |
关于现场观察的说明 |
R |
S |
||
8 支持过程
8.1 交付物清单
| 类别 |
交付物 |
甲方 |
乙方 |
备注 |
| 分布式开发的接口 |
供应商选择报告 |
R |
S |
NA, Tier2 as SeoOC |
| 开发接口协议（DIA） |
R |
S |
NA, Tier2 as SeoOC |
|
| 供应商安全计划 |
R |
S |
NA, Tier2 as SeoOC |
|
| 功能安全评估报告 |
R |
S |
甲方对嵌入式软件或电子产品的供应商进行审核管理，乙方提供咨询服务 |
|
| 供应协议 |
R |
S |
||
| 配置管理 |
配置管理计划 |
R |
S |
|
| 变更管理 |
变更管理计划 |
R |
S |
|
| 变更需求 |
R |
S |
||
| 影响分析和变更请求计划 |
R |
S |
||
| 变更报告 |
R |
S |
||
| 验证 |
验证计划 |
R |
S |
|
| 验证规范 |
R |
S |
||
| 验证报告 |
R |
S |
||
| 文档化 |
文档管理计划 |
R |
S |
|
| 文档指南要求 |
R |
S |
||
| 所使用软件工具的置信度 |
软件工具准则评估报告 |
R |
S |
依据甲方开展工具鉴定，乙方提供咨询服务 |
| 软件工具鉴定报告 |
R |
S |
依据甲方开展工具鉴定，乙方提供咨询服务 |
|
| 软件组件的鉴定 |
软件组件的文档 |
R |
S |
乙方主导完成，需依据甲方真实使用的工具开展 |
| 软件组件鉴定报告 |
R |
S |
乙方指导甲方完成 |
|
| 软件组件鉴定验证报告 |
R |
S |
乙方指导甲方完成 |
|
| 硬件要素的评估 |
硬件要素评估计划 |
R |
S |
乙方指导甲方完成 |
| 硬件要素测试计划 |
R |
S |
乙方指导甲方完成 |
|
| 硬件要素评估报告 |
R |
S |
乙方指导甲方完成 |
|
| 在用证明 |
用于在用证明的候选项描述 |
NA |
NA |
|
| 在用证明分析报告 |
NA |
NA |
||
| 超出ISO26262范围的一个应用的接口 |
主机厂或供应商指南 |
NA |
NA |
|
| Integration of safety-related system not develpmed according to ISO26262 |
安全合理性的依据 |
NA |
NA |
备注：R: responsibility S:service or support A:approve
9 验证、确认与评估交付物
9.1 交付物清单
﹒ 功能安全验证与确认计划；
﹒ 安全机制验证报告（含故障注入说明）；
﹒ 第三方的功能安全评估报告（FSA），评审单位可以是北德，南德，德凯，SGS或DNV中的任一一家；
﹒ 第三方认证支持材料，功能安全涉及的part2/3/4/5/6/7/8/9的产品级资料。
9.2 工程化验收标准
﹒ 验证活动基于样机或等效验证环境；
﹒ 故障注入方式、检测时间与系统响应记录完整；
﹒ 整个EMB系统的FSA结论明确产品级的ASIL-D达成情况与剩余风险；
﹒ 交付物满足第三方（北德，南德，SGS，DNV，德凯，劳盛等）审核机构要求。
10 其他部分
10.1 项目开发过程中支持的工具链
本项目中，供应商有义务提供工具链，支持甲方完成相关的工作：
| 类型 |
工具 |
备注 |
| 功能安全过程管理，需求管理，测试管理等ALM工具 |
ALM,Ansys medini, codebeamer等 |
甲方提供工具，或者项目开展期间甲方没工具用EXCLE开展 |
| 系统架构，软件架构 |
EA |
甲方提供工具 |
| 安全分析：FMEA |
IQ-FMEA，Ansys medini，国可FMEA |
甲方提供工具，或者项目中乙方有合适工具也可提供 |
| 安全分析：FTA，FMEDA |
Isograph，Ansys medini |
甲方提供工具，或者项目中乙方有合适工具也可提供 |
| MBD单元和集成测试 |
Simulink test |
乙方需要提供自动化生成test harness的测试脚本或工具。 乙方负责基于甲方现有的MATLAB/Simulink环境，定制符合本项目ASW模型架构的自动化测试脚本框架（Harness Template），并提供完整操作指导与配置规则 免费提供，永久使用 |
| C代码单元和集成测试 |
VectorCAST/C++ Enterprise |
甲方提供工具 |
| C代码静态检查 |
PolySPACE |
甲方提供工具 |
| MBD模型静态检查 |
Model Advisor |
乙方需要提供模型检查配置文件和配置规则 |
11 验收与付款关联
11.1 本附件所列交付物作为各阶段验收与付款的直接依据。
11.2 任一阶段交付物未满足本附件约定的工程化验收标准，甲方有权：
﹒ 要求乙方整改后重新提交；
﹒ 暂缓或拒绝对应阶段付款。
12 附则
12.1 本附件未尽事宜，参照主合同执行。
12.2 本附件自双方签字盖章之日起生效。
以上仅供参考，设备具体要求请与使用企业进行技术交流。
招标地点:钱潮供应链设备采购及供应商管理平台
联系方式:浙****公司赵一辰187****4427
报名截止时间:2026年11月7日(具体根据用户项目进度时间要求开展】标书代写
招标进度跟踪
2026-10-26
招标公告
浙江万向精工有限公司--EMB功能安全工程化
当前信息
标书代写
招标项目商机
暂无推荐数据
400-688-2000
欢迎来电咨询～
