|
|
特别提醒：此版块涉及军标体系，各位在分享学习资料，互相交流探讨的时候，务必遵守国家法律，不得泄密！不得泄密！不得泄密！！！
按照国军标要求，军工产品可靠性设计分析工作项目很多，其实真正落实到产品设计过程中审核的重点各有不同。一定要记住，可靠性设计分析工作目的是影响产品的设计，通过可靠性工作真正提升产品可靠性水平。结合多年的工作经验，可靠性设计分析要点总结如下，这也是项目评审和审核的重点。
可靠性建模要点
(1) 可靠性建模是进行可靠性分配/预计的基础，因此必须尽早开展，并随着产品的研制进展不断细化迭代。
(2) 应该先建立产品的可靠性框图，然后据此建立相应的数学模型。
(3) 在建立基本可靠性模型时，要包括产品的所有组成单元。当单元工作在多个环境条件下，应该采用可靠性最差的数据进行分析。
(4) 不同的任务剖面应该分别建立各自的任务可靠性模型，模型中应该包括在该任务剖面中工作的所有单元。
(5) 任务可靠性框图应该与系统的任务故障判据一致。
(6) 当提高单元的可靠性所花的费用高于使用冗余模型的费用时，则应采用冗余模型。
(7) 对于简单并联模型，n=2时，可靠度的提高最显著；当冗余单元超过一定数量时，可靠性提高的速度大为减慢，因此需要进行权衡。
(8) 当采用冗余时，在产品层次较低的地方采用冗余的效果比层次较高的地方好。例如，在元件级采用冗余比部件级好。但工程上有时不允许进行级别低的冗余，工程上常用的是部件级及设备的冗余。
(9) 采用并联模型可以提高产品的任务可靠性，但也会降低产品的基本可靠性，同时增加产品的重量、体积、复杂度、费用及设计时间。因此，必须进行综合权衡。
可靠性分配要点
(1) 可靠性分配应在研制阶段早期进行，这样可以使设计人员尽早明确其设计产品的可靠性要求，并作为外协、外购产品可靠性定量要求的依据。
(2) 为了尽量减少可靠性分配的重复次数，进行可靠性分配时，应在可靠性指标的基础上留有一定的余量，一般按可靠性指标的1.1～1.2倍进行分配。
(3) 对于有并联的分系统，应先把可靠性方框图逐步简化，形成一个串联系统，然后再进行分配。
(4) 对于已有可靠性指标的货架产品或成熟产品，不再进行可靠性分配。
(5) 可靠性分配时应综合考虑产品各组成单元的复杂度、重要度、技术成熟度、工作时长等因素。
(6) 通过选择一种可靠性分配方法对产品的可靠性指标进行分配后，需要对分配结果进行验算，确定分配结果是否满足指标要求。验算的方法是当组成单元分配的故障率之和大于产品的故障率指标(假定服从指数分布) ，即，则可靠性指标分配不成功，需要重新分配。
电子产品可靠性预计要点
(1) 可靠性预计工作应与功能性能设计同步进行，在产品研制的各个阶段，可靠性预计应反复迭代，以使预计结果与产品的技术状态始终保持一致。
(2) 注意与故障定义和任务剖面的相关性。不同的任务剖面对应不同的预计值，故障定义影响预计的模型与结果。
(3) 在方案论证和初步设计阶段，可靠性预计只能提供大致的估计值，这些值适用于最初分配的比较和确定分配的合理性。随着设计工作的进展，产品定义进一步确定，可靠性模型的细化，可靠性预计结果将逐步趋于精确。
(4) 由于可靠性信息数据积累不足，产品的可靠性预计结果可能并不精确，但这不会影响对产品各种设计方案或各组成单元的可靠性的对比结果，因此，可靠性预计结果的相对值有时比绝对值更有意义。通过可靠性预计结果的对比可以找到系统易出故障的薄弱环节，加以改进；可靠性预计结果是方案优选、调整的重要依据。
(5) 可靠性预计值必须大于产品研制总要求或合同中确定的成熟期规定值或目标值，否则，必须及时采取设计改进措施，直到预计结果达到要求为止。
非电产品可靠性预计要点
(1) 使用应力强度干涉法时，为了使可靠度计算更为准确，需要清楚地了解零部件的应力和强度分布形式及分布参数。
(2) 可靠性预计结果应大于规定的要求，否则必须采取改进措施。
(3) 非电产品可靠性的预计模型和数据来源的准确性需要特别注意。
(4) 使用极限状态函数法时，注意区分随机变量的分布形式，对正态分布和非正态分布的随机变量要分别处置。
(5) 对于复杂非电产品的可靠性预计建议采用计算机辅助设计软件进行。
FMECA要点
(1) 重视FMECA计划工作。实施中应贯彻边设计、边分析、边改进和“谁设计、谁分析”的原则。可在可靠性工程师的协助下,由产品设计、工艺设计人员完成,最好由各相关部门的代表组成一个分析小组,以便发挥各方面专家的特长,全面发现潜在缺陷。
(2) 加强规范化工作。产品总体单位应明确与各转承制单位之间的职责与接口分工,统一规范、技术指导,并跟踪其效果,以保证FMECA分析结果的正确性、可比性。
(3) 及时性。在不同阶段应及时开展FMECA,同时必须与设计工作保持同步。FMECA的结果应作为进一步设计的参考,在设计中加以改进。FMECA的有效与否很大程度上取决于分析及纠正是否及时,应在产品研发的各评审点及其之前提供有用的信息,否则它就是不及时的和没有作用的。
(4) 层次性。各约定层次间存在一定的关系,即低层次产品的故障模式是相邻上一层次的故障原因。FMECA是一个由下而上的分析迭代过程。
(5) 有效性。改进措施的有效与否是FMECA改善产品可靠性水平的关键。为使这些措施是合理有效的,应注意以下四点:
- 1) 改进措施首先从设计、工艺等方面考虑。仅用换件、维修等是不能提高产品固有可靠性的。
- 2) 在确定是否采取进一步的改进措施时,应进行可靠性与经济性的权衡。
- 3) 书写建议改进措施的原则是使上级领导及负责人易于理解,并决定是否采取这些措施。
- 4) 应把FMECA的结果补充到图纸、技术资料及标准、质量文件中,以体现纠正措施的有效性。
(6) 完整性。彻底弄清产品各功能级别的全部可能的故障模式是至关紧要的,因为整个FMECA的工作就是以这些故障模式为基础进行的。这里强调的是全部故障模式,绝不可不经分析就想当然认为某种或某些故障模式不重要,放弃分析,这样做有时会导致严重后果。
(7) 对于RPN高的故障模式,应从降低故障发生概率等级、故障影响严酷度等级和改进故障检测手段方面提出改进措施;在RPN分析中,不同的故障模式可能出现RPN相同的情况,对此分析人员应对严酷度等级高的故障模式给予更大的关注。
(8) 在一般零件的故障模式严酷度评级中,若出现法规中不允许发生的故障模式,原则上应评定其严酷度为最高等级。
(9) 开展FMEA时的S,O,D值只有相对的意义,只能比较在具体的FMEA时不同失效模式的相对等级和关注等级。
嵌入式软件FMECA要点
(1) SFMECA的应用重点在软件开发过程的早期，如需求分析与概要设计阶段，找出可能存在的与功能和性能有关的缺陷，以尽早完善需求分析与概要设计。
(2) 应明确和掌握SFMECA 基本步骤中主要内容，如分析对象既可以是软件的系统、分系统、部件，又可以是能单独编译的模块；软件故障除了与硬件故障一样与功能有关的缺陷外，还有一种仅与软件本身有关的缺陷，对这两种缺陷在SFMECA 中均要加以纠正等。
(3) SFMECA 与其他故障分析方法(如软件FTA等)综合进行分析可取得更佳效果。
损坏模式及影响分析(DMEA) 要点
(1) 明确DMEA与生存力的关系。针对生存力四个基本要素：难以被敌方察觉(如隐形武器装备)、难以被敌方命中(如利用电子干扰设备)、难以被敌方击毁(如装甲防护或被覆)、遭损坏后但能迅速修复或自救(如自行撤离)，通过DMEA结果，采取相应的有效措施，提高武器装备的生存力。
(2) 明确威胁机理类似于FMEA中的故障机理，它是造成产品损坏模式的根本原因。在实施DMEA时，往往选择一种或几种典型的威胁机理进行针对性的分析。
(3) 掌握DMEA与FMEA的关系。DMEA是在FMEA基础上进行的。未进行FMEA，就不能进行DMEA。FMEA是针对产品在使用过程中(含作战)可能出现的偶然故障和耗损故障；而DMEA是针对产品在战场环境下出现各种战斗损坏。DMEA是针对产品的损坏模式及影响加以改进，一般不会显著地提高其可靠性，但能改善产品的生存力和易损性。
(4) 提高DMEA分析效率。广泛收集整理、分析归纳各类装备的战损数据，建立战损分析基础数据库、战损模式数据库，提高DMEA的分析效率。
工艺FMECA要点
(1) 遵循“谁工艺设计、谁分析”的原则。在工艺FMECA中应充分考虑产品设计特性，根据需要，邀请产品设计人员参与分析工作，并促进不同部门之间充分交换意见，以最大限度地确保产品满足“顾客”的需求。
(2) 工艺FMEA是一个动态的、反复迭代分析的过程。应对工艺故障模式的风险优先数(RPN)值的大小进行优先排序，并对关键过程采取有效地改进措施，进而对改进后的RPN 进行跟踪，直到RPN值满足可接受水平为止。
(3) 应明确工艺FMECA 与设计的关系，工艺FMEA中的缺陷不能全靠更改产品设计缺陷来克服，主要是从工艺设计和工艺FMEA中采取有效措施加以解决。设计缺陷所产生的潜在故障模式也可能包含在工艺FMEA中，它们的后果及避免措施由DFMEA解决。
(4) 可以与FTA技术结合使用，FTA分析结果可以作为工艺FMEA的输入。
FTA要点
(1) 为保证分析工作的及时性，应在设计阶段早期开始分析工作，并在各个研制阶段都要迭代进行，以反映产品技术状态和工艺的变化。
(2) 贯彻“谁设计、谁分析”的原则，并邀请经验丰富的设计、使用和维修人员参与FTA工作。
(3) 应该首先开展FMEA/CA工作，从故障后果为Ⅰ、Ⅱ类的系统故障模式中选择最不希望发生的故障模式作为顶事件，建立故障树。
(4) 必须考虑环境、人为因素对产品的影响，当产品处于多个环境剖面下工作时，应分别进行分析。
(5) 若产品具有多个工作模式，各工作模式的顶事件应该单独分析。
(6) 在进行故障树分析时，假设底事件之间是相互独立的，并且每个底事件及顶事件只考虑其发生或不发生两种状态。
(7) 建树时，门与门之间不能直接相连。
(8) 复杂产品的故障树应该进行模块分解和简化，并尽可能采用有关软件辅助进行故障树分析。
(9) 建立故障树后都要进行定性分析，根据相关要求确定是否需进行定量分析。
(10) 必须进行薄弱环节分析及重要度分析，并提出可能的改进措施及改进的先后顺序。 |
|
发表于 2022-3-22 18:26:06
发表于 2022-3-23 17:58:15
发表于 2022-3-22 20:36:31
发表于 2022-3-23 08:27:37