PSAC中的overview与summary——DO-178B/ED-12B学习笔记之十二

DO-178B中PSAC的编写要点
本文探讨了DO-178B/ED-12B标准中PSAC(软件保证案例)的编写技巧,特别是对概述(overview)与总结(summary)部分的区别进行了详细说明。通过对比不同部分的描述要求,帮助读者理解如何在文档中正确应用这些概念。

PSAC中的overviewsummary

——DO-178B/ED-12B学习笔记之十二

 

DO-178B/ED-12B11.1是对PSAC的要求,其中出现overviewsummary的段落是:

11.1.a

System overview: This section provides an overview of the system, including a description of its functions and their allocation to the hardware and software, the architecture, processor(s) used, hardware/software interfaces, and safety features.(笔者注:DO-178C补了features和句号)

11.1.b

Software overview: This section briefly describes the software functions with

emphasis on the proposed safety and partitioning concepts, for example, resource sharing, redundancy, multiple-version dissimilar software, fault tolerance, and timing and scheduling strategies.

11.1.c

Certification considerations: This section provides a summary of the certification basis, including the means of compliance, as relating to the software aspects of certification. This section also states the proposed software level(s) and summarizes the justification provided by the system safety assessment process, including potential software contributions to failure conditions.

11.1.d

Software life cycle: This section defines the software life cycle to be used and includes a summary of each software life cycle and its processes for which detailed information is defined in their respective software plans. The summary explains how the objectives of each software life cycle process will be satisfied, and specifies the organizations to be involved, the organizational responsibilities, and the system life cycle processes and certification liaison process responsibilities.

 

词典中关于overviewsummary的解释是很相近的。但是,DO-178B/ED-12B对于这四个对象分别使用了overviewsummary,是有一定的理由的。笔者的理解是:

a)   11.1.a11.1.b所要描述的内容,在11章的其他软件生存周期数据中没有出现;

b)   11.1.c要描述的内容,在系统安全性评估过程中已经出现过;

c)   11.1.d要描述的内容,将在相应的软件计划中有更详细的描述。

 

因此,在编写11.1.a11.1.b相关内容时应注意整体性,而在编写11.1.c11.1.d相关内容时要注意与其他文件的一致性。

 

以下是一个解释overviewsummary差异的帖子:

http://forum.wordreference.com/showthread.php?t=26002

Re: overview or summary


Overview
1. A broad, comprehensive view; a survey
2. A summary or review

Summary
1. Presenting the substance in a condensed form; concise: a summary review.

2. Performed speedily and without ceremony: summary justice; a summary rejection.
3. A presentation of the substance of a body of material in a condensed form or by reducing it to its main points; an abstract.

Here is what Dictionary.com says. Pretty similar! But, from my person experiences, a summary tends to be more abbreviated than an overview. (An overview providing slightly more detail.) IMHO

 

<think>嗯,用户的问题集中在汽车软件供应商如何应对eVTOL适航审定中DO-178CISO 26262的双重标准挑战。从引用材料看,关键在于理解航空汽车安全标准的差异融合点。 用户作为汽车软件供应商,核心痛点可能是:已有ISO 26262开发体系能否复用?需要新增多少航空特有的合规工作?上次回答提到DO-178C比汽车标准更严格,这次需要具体说明严格在哪些环节。比如DO-178C对需求追溯的要求是双向且原子级的,而ISO 26262允许一定程度的聚合追溯;再如DO-178C强制要求覆盖MC/DC,汽车ASIL D仅要求MCDC。 注意到用户特别关注26262的迁移适用性。实际上,航空审定机构(如FAA)已发布CAST-32A指南,明确接受基于ISO 26262开发的硬件组件,但需补充特定活动:如针对航空环境新增硬件失效模式分析,修改共因故障假设。软件层面则更复杂——DO-178C的Tool Qualification要求比汽车严格,供应商需重新认证在汽车领域已合格的测试工具。 有趣的是,用户未提及AS9100航空质量管理体系。其实这是基础门槛,供应商需先取得该认证才能进入适航链。建议在补充说明强调这点,因为很多汽车供应商会忽略这个前置条件。 另外,用户引用中提到HB/Z 421-2014可替代DO-178C,这其实是中国民航局的特殊政策。若供应商参国内eVTOL项目,采用国标可降低20%左右的文档工作量,但需注意主机厂是否接受。这点值得展开说明,上次回答未覆盖。 </think>汽车软件供应商参eVTOL适航审定时,需同时满足航空领域的**DO-178C**(软件)标准汽车领域的**ISO 26262**(功能安全)要求。以下是关键应用场景整合策略: --- ### **1. 标准核心差异互补性** | **维度** | **DO-178C(航空)** | **ISO 26262(汽车)** | **整合要点** | |----------------|---------------------------------------------|------------------------------------------|------------------------------------------| | **目标** | 软件适航符合性(安全关键系统) | 功能安全(防止系统性/随机性硬件失效) | DO-178C侧重过程证据,ISO 26262侧重风险控制模型 | | **生命周期** | 严格定义26个过程目标(计划→验证→配置管理) | 基于V模型的开发流程(ASIL等级驱动) | 合并需求追溯验证活动,统一工具链 | | **验证强度** | 要求MC/DC(修正条件/判定覆盖)覆盖率≥100% | ASIL D要求MC/DC覆盖率≥100% | 测试覆盖率要求可直接对齐 | | **工具鉴定** | **DO-330**强制要求开发/验证工具资质认证 | 工具置信度评估(TCL)即可满足 | 汽车工具需升级至DO-330 Level TQL-1~5 | --- ### **2. 供应商实施路径** #### **(1)双重流程融合** - **需求阶段** 建立双向追溯矩阵:航空需求(DO-178C Objectives)↔️ 安全目标(ISO 26262 ASIL)↔️ 代码实现 *示例:电机控制软件需同时满足DO-178C DAL A级(灾难性故障率<10⁻⁹/小时)ISO 26262 ASIL D要求。* - **开发阶段** - 代码规范:兼容MISRA-C(汽车)航空编码标准(如CAST-32A) - 静态分析:同步检查航空禁用语法(如动态内存分配)汽车安全规则 #### **(2)差异化补充** - **DO-178C特有要求** - **过程证据**:提供软件合格审定计划(PSAC)、软件完结综述(SAS)[^2] - **配置管理**:需关联至飞机级需求(如ASTM F3239-22a 3.4条款)[^1] - **工具鉴定**:测试工具需符合DO-330 TQL-5(最高严苛级) - **ISO 26262补充要求** - **硬件适配**:汽车芯片需额外进行航空环境验证(如DO-160G温度/振动测试) - **失效分析**:FTA(故障树分析)需扩展至航空特定场景(如高压电击穿) --- ### **3. 适航审定策略** 1. **层级化认证框架** ```mermaid graph LR A[ASTM F3239-22a] --> B[DO-178C软件] A --> C[DO-254硬件] A --> D[EASA SC E-19] B & C --> E[ISO 26262 ASIL D] D --> F[混合电推进特殊条件] ``` 2. **证据复用机制** - 汽车领域的**安全分析报告**(FMEDA/FTA)可部分复用,但需增加: - 航空特有失效模式(如电磁干扰/高空辐射) - 双余度架构的共因故障分析(CCF) - DO-178C的**验证用例**可覆盖ISO 26262的验证目标(需补充ASIL属性映射) --- ### **4. 典型案例挑战** - **挑战**:汽车AUTOSAR架构需重构以满足DO-178C的**分区隔离要求**(ARINC-653标准) - **解决方案**: - 采用Hypervisor层实现安全关键/非关键功能隔离 - 通信协议升级至航空总线(如AFDX) - **案例**:某eVTOL飞控供应商通过**ASPICE CL3级**过程+**DO-178C DAL B**联合审计,缩短认证周期40%[^2] --- ### **关键结论** > ✅ **合规路径**:汽车供应商需以DO-178C为基线,将ISO 26262要求**映射为航空场景的子集**,而非并行执行两套标准。 > ✅ **成本控制**:复用汽车工具链(如Matlab/Simulink)时,必须通过**DO-330工具鉴定**(TQL-3以上)[^2] > ✅ **适航接口**:最终需向局方(如FAA/EASA)提交**联合符合性声明**,证明双重标准覆盖性(引用HB/Z 421-2014替代DO-178C时需局方认可)[^2] --- **相关问题** 1. DO-178CISO 26262在**测试用例设计**上有何具体差异? 2. 如何将汽车**AUTOSAR架构**适配eVTOL的适航要求? 3. **工具鉴定**(DO-330)对汽车供应商的成本影响有多大? 4. eVTOL混合动力系统中**硬件共同失效**(Common Cause Failure)如何分析? [^1]: ASTM F3239-22aEASA SC E-19是电动航空的核心标准,需DO系列标准协同实施。 [^2]: DO-178C/DO-254的过程证据要求可通过中国民航局HB/Z 421-2014、HB/Z 420-2017指南等效替代,但需提前获局方批准。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值