AMSAA可靠性工作项目核查评分表

1、AMSAA可靠性工作项目核查评分表蔡丽影可靠性项目组成单元记 分可靠性要求和规划RYG在产品研制阶段按规定制定并更新可靠性案例/可靠性规划可靠性案例/可靠性项目规划证明研发人员已经对可靠性要求有了充分了解，用于实现这些要求的计划是合理的并且可实现的，对旨在满足这些要求的进程进行定期更新。可靠性案例向用户保证合同商正在积极进行设计和检测活动，可以成为优秀的工业执行者。研发人员的可靠性项目规划，是基于生产可满足各项可靠性要求的产品的现实时间帧、检测和产品设计活动制定的。对由纠正措施导致的延迟进行确定，并把它们纳入到规划之中。绿色可靠性案例/可靠性项目规划没有清楚地证明研发人员已经对可靠性要求有了充

2、分了解，根本不存在用于实现这些要求的计划，或者是这一计划在执行方面存在问题，对旨在满足这些要求的进程没有文件记录或只有零星记录。可靠性案例没有向用户保证合同商正在进行最新的/最高的质量设计或检测活动。可靠性规划在生产可满足各项可靠性要求的产品的现实时间帧、检测和产品设计活动各方面存在问题。根本没有对由纠正措施导致的延迟进行确定，或者没有并把它们纳入到规划之中。黄色研发人员没有制定出可靠性案例/可靠性项目规划，或者制定出的可靠性案例/可靠性项目规划非常差。红色已经确定的和被记录的可靠性和质量经验已经记录了关于以前项目的可靠性和质量目标的成功经验。绿色没有确定或记录关于以前项目的可靠性和质量目标。

3、黄色没有记录关于以前项目的低劣的可靠性和质量目标，或者记录很差。红色设计小组拥有生产可靠硬件和软件的历史记录设计小组的以前很多项目都生产了硬件和/或软件，并且项目中的大多数案例都已经证明是可靠的。绿色设计小组以前有一些项目是生产硬件和/或软件的，并且项目中的一些案例已经证明是可靠的。黄色没有设计小组尚没有生产出多少硬件和/或软件，或者不存在以前生产可靠硬件的项目。红色采纳新方法提高可靠性和持续关注可靠性改进的历史情况研发人员具有采纳新方法和强调实现高可靠性以及寻找提高可靠性方法的历史。绿色研发人员在以前项目中比较强调寻找改进可靠性的方法。黄色研发人员拥有很少开发新方法的经验，不热衷/不强调对改

4、进可靠性方法的寻找。红色明确确定可靠性项目的可靠性活动，包括：一项工程预计花费的时间/日期，与设计和检测活动是完整不可分割的整体，并与项目的进度表保持一致。可靠性/可用性/维修性（RAM）的全部活动都被纳入到项目综合的总进度表（IMS）之中。绿色可靠性/可用性/维修性（RAM）的部分活动被纳入到项目综合的总进度表（IMS）之中。黄色可靠性/可用性/维修性（RAM）的活动没有被纳入到项目综合的总进度表（IMS）之中。红色可靠性项目确定某些产品的交货日期和/或分析，以保证项目能够实现各项要求。可靠性项目规定一个详细的进度表，里面说明某些产品的交货日期，和/或分析，以向用户提供确定该项目是否能够按时

5、实现各项可靠性要求的信息。绿色概述一个总进度表，里面可能确定也可能没有确定交付日期，从而不能向用户提供确定该项目是否能按时满足各项可靠性要求的信息。黄色没有做出进度表以跟踪为满足各项可靠性要求而取得的各个成绩。红色把零件、物资和程序管理纳入到全部系统工程方法之中研发人员努力所有的零件、物资和程序管理纳入到全部的系统工程方法之中，以保证按照产品的寿命周期重点和各项可靠性要求适当应用零件、物资和程序。绿色研发人员没有把所有的零件、物资和程序管理纳入到全部的系统工程方法之中，因此，不能保证按照产品的寿命周期重点和各项可靠性要求适当应用零件、物资和程序。黄色研发人员几乎没有把零件、物资和程序管理纳入到

6、全部的系统工程方法之中。红色确定各种可利用的资源（物资、人力资源、设备等等）研发人员明确确定全部可利用的物资、设备、分析、人力资源、分析工具等，和如何在整个寿命周期中利用它们来生产高可靠性的产品。绿色研发人员明确确定部分可利用的资源，但是没有完全确定什么资源可利用和如何在整个寿命周期中利用它们来生产高可靠性的产品。黄色研发人员几乎没有确定研制高可靠性产品所需要的资源和步骤。红色确定所有有限寿命部件；已经阐明替换政策研发人员已经确定了所有的有限寿命部件。已经制定出关于这些部件的一个思考成熟的、详细的、经济合算、可以在产品的寿命周期内保持一个足够高的可靠性水平的替换政策。绿色研发人员已经确定以少数

7、的有限寿命部件。已经制定出一个一般的、不具备在产品寿命周期内维持一个足够高的可靠性水平所需的详细细节的替换政策。黄色几乎没有确定各个有限寿命部件。也没有制定出在产品寿命周期内维持一个足够高的可靠性水平的替换政策。红色利用可靠性工程和管理工具，例如故障模式影响及危害性分析（FMECA）和可靠性增长（RG）。制定了一个详细的/详尽的故障模式影响及危害性分析（FMECA），计划了各个可靠性增长（RG）工具，并在该项目的整个寿命周期内循环持续使用这些工具，以跟踪该项目的进程。绿色制订了一个一般的故障模式影响及危害性分析（FMECA），内容并不详尽，并且在项目研制阶段对各可靠性增长（RG）工具的使用很有

8、限。黄色没有制定故障模式影响及危害性分析（FMECA），并在项目周期阶段没有使用各可靠性增长（RG）工具。红色训练与研制RYG与设计小组直接相连的足够大的可靠性工程小组依照项目的规模及相关工作量来说，可靠性工程小组的规模适当，并且他们与设计小组保持良好的联系和沟通。绿色拥有一个可靠性工程小组，但是工作量是过多的，而且这个可靠性工程小组没有与设计小组相连。黄色可靠性工程小组人员不足，并且没有与设计小组相连。红色为个人和管理制定训练计划，包括进度表、预算和训练人员确认。已经为所有的个人和管理制定了一个考虑成熟的、详细的训练计划，它明确确定了进度表、预算和训练人员的确认。绿色制定了一个一般的计划，但

9、是没有详细规定关于进度表、预算和训练人员的确认的所有细节问题。黄色已经制定了一个有限的训练计划，或者没有制定出训练计划。红色监控新研发的技术、模型与分析技术和影响可靠性的趋势等等，并相应地调整训练训练人员非常勤勉，并且在与各项新研发技术、模型与分析技术和任何影响可靠性和可靠性提高的过程保持一致。适当的技术、模型/分析技术和过程都被纳入到训练计划之中。绿色训练人员与某些新研发技术、模型与分析技术和影响可靠性与可靠性提高的各个过程保持一致，并能够把其中的一部分纳入训练之中。黄色训练人员没有（或者很差地）与各项新研发技术、模型与分析技术和任何影响可靠性和可靠性提高的过程保持一致，并且没有很好地把新想

10、法和过程纳入到训练计划之中。红色不要依赖各个手册（例如：MIL-HDBK-217），并且不要仅仅把可靠性视为平均故障间隔时间（MTBF）。研发人员集中力量设计和生产一个拥有较长无故障运行时间的产品，并把可靠性不仅仅看作平均故障间隔时间（MTBF）。研发人员把概率分析视作产品设计的组成部分。研发人员不把手册预测视作设计情况和完备的指示器。人员知道怎样分配、模仿、分析和评估各种可靠性要求。绿色研发人员对手册预测有很大依赖，并将之视为设计情况和完备的指示器，并且把平均故障间隔时间（MTBF）视作测量可靠性的主要方法。研发人员不是特别清楚如何分配、模仿、分析和评估各种可靠性要求。黄色研发人员只依赖手册

11、预测，并将之视为设计情况和完备的指示器，并把平均故障间隔时间（MTBF）视作测量可靠性的唯一方法。研发人员不知道如何分配、模仿、分析和评估各种可靠性要求。红色可靠性分析RYG利用综合热震动分析和/或有限元分析法（FEA）指出潜在的故障机理和故障位置。设计是对热量和振动特点的模拟。 从较高级别的模型或有规律的数据来确定限制条件。对特殊项目和运行条件进行模拟。从多个位置以全部适合的工具对振动反应进行测量。按步骤进行有限元分析法（FEA）。应该满足所有的热量和振动目标。绿色可能对设计进行了模拟。从较高级别的模型或有规律的数据来确定限制条件。没有从多个位置或没有以全部适合的工具对振动反应进行测量。进行

12、了有限的有限元分析法（FEA）。没有满足一些热量和振动目标。黄色没有计划热量或振动分析或者进行有限元分析法（FEA）。红色对临界载荷和应力进行刻画；对寿命周期环境和运行负载循环应力进行刻画。详细说明对寿命周期用户和环境负责的评估，定期更新，对试生产系统/产品的测量方法进行核实。研发人员必须对临界载荷和应力进行刻画。以附加的检测和数据收集进行验证。绿色从相似运行环境的“相似系统”对寿命周期用户环境负荷进行评估。没有通过检测和数据收集对实际系统的测量方法进行验证。黄色没有说明寿命周期用户环境负荷和负载循环应力。红色掌握可靠性问题；掌握故障机理和故障位置明确确定故障模式和故障分配，并通过分析、检测或

13、加速测试进行核实。在输入信息发生变化的时候，要随着设计的发展对故障模式和故障分配进行更新。绿色通过有限的研究/分析或与相似系统进行比较，来对故障模式和故障分配进行粗略地确定。努力随着设计的发展对故障模式和故障分配进行更新。黄色不清楚可能出现的故障机理和故障位置。红色指导故障模式影响与危害性分析（FMECA）、故障树分析（FTA）；进行低级别的检测和故障机理分析以确保覆盖到主要问题。研发人员使用可靠性工程和管理工具，例如：故障模式影响与危害性分析（FMECA）和可靠性增长（RG）。这些工具和分析与产品设计小组直接相连，并且研发人员利用这些结果来影响产品设计和集中产品设计小组的成绩。从功能级别到系

14、统级别在设备/系统上执行故障模式影响分析（FMEA）。确定全部潜在的产品和界面的故障模式，及其对直接功能、设备/系统和运行的影响。把为排除设计或生产风险的纠正设计选择或其他活动、安全考虑和内置检测限制都进行很好的记录。每次技术评估中都对故障模式影响分析（FMEA）过程和结果进行评估。绿色研发人员利用不甚正式的过程例如：与相似系统进行比较或手册预测等来进行评估确定故障模式及其对系统的影响。产品设计小组没有完全参与到这一过程中去。没有很好记录为排除设计或生产风险的纠正设计选择或其他活动、安全考虑和内置检测限制。黄色没有组织故障模式影响与危害性分析（FMECA）、故障树分析（FTA）或不太正式的过程

15、来确定故障模式。红色通过研制对每一可靠性参数和技术交换进行技术评估，从而了解和促进故障、维修定义和记分标准成熟。研发人员非常了解关于用户的可靠性和维修性要求的原理，并根据研发人员的最新系统的详细设计结构通过产品研制组织经常的技术交换，来了解和促进用户的故障和维修定义和计分标准。绿色研发人员不是十分了解关于用户的可靠性和维修性要求的原理，并组织很少的技术交换，或者只在出现问题用户提出申请时进行技术交换。研发人员不能根据最新的设计结构及时地更新用户的故障和维修定义和记分标准。黄色研发人员不清楚用户的可靠性和维修性要求，也没有组织日常的技术交换和制定维修定义和记分标准，这是用户不能接受的或不适合目前

16、的设计。红色基于工程的可靠性评估可以获得高的通过检测比率研发人员经常组织基于工程的可靠性评估以对可靠性方面的设计进行评估。在检测之前根据分析把设计变更纳入到增加满足可靠性要求的概率，“通过检测”并减少“test -fix -test”的数量，因此节省检测资源。绿色研发人员很少组织基于工程的可靠性评估，可以稍微改进满足各项可靠性要求的能力，但是没有增加“通过可靠性检测”的概率，有时可以进行更加频繁的分析。黄色研发人员基本不组织基于工程的可靠性评估，因此，会减少通过检测的概率并增加必需的检测资源。红色可靠性测试RYG早期组织低级别检测以确定和减少故障模式。组织高加速寿命试验（HALT）和高加速应力

17、筛选（HASS）。研发人员组织明确设计的早期设计检测以预测各种故障，从而可以再产品设计流程中较早地改进设计。研发人员在产品研制过程中经常组织低水平的检测。研发人员经常向用户提供结果和故障机理模型的各个结果，以验证和提供保证：产品研制正在努力满足规定的各项可靠性要求。研发人员组织高加速寿命试验（HALT）和高加速应力筛选（HASS）。这些试验都是针对具体的故障机理进行组织的。确定纠正措施，并及时执行。绿色研发人员组织一些试验从而试图影响设计。用户可能也可能不知道试验结果。没有经常组织高加速寿命试验（HALT）和高加速应力筛选（HASS）。没有经常采取及时的纠正措施。黄色没有组织低级别的试验来确定

18、和减少故障模式。红色通过结合诊断学、预测学、试验和训练来考虑嵌入式仪器。研发人员已经根据参谋长联席会议指示CJCSI 3170.01F通过把诊断学、预测学、试验和训练纳入到产品研制过程的产品设计早期来考虑嵌入式仪器，并对一些选择项进行评估，以包括基于时间变化的诊断学、基于先兆的预测学和基于应力历史的预测学。绿色研发人员已经考虑了一些嵌入式仪器。一定的诊断学、预测学、试验和训练或通过嵌入式仪器收集的至少四类的数据已经被考虑在内。对预测学选项进行了考虑但是没有对其进行彻底的评估。黄色没有考虑任何嵌入式仪器或用于预测的选择项，或者在研制过程中很晚才出于经济划算才考虑重新设计。红色基于各个结果更新可靠

19、性评估、关键项目和故障模式/机理。对可靠性评估、关键项目和故障模式进行定期更新，也根据详细的可靠性分析结果和试验结果进行及时更新。与用户协商进行更新以获取他们的赞同，并且研发人员利用更新来影响设计变更。绿色没有定期或及时更新可靠性评估、关键项目和故障模式。进行更新没有与用户经常协商，可能会因为影响设计变更的能力导致进度延误。黄色没有更新可靠性评估、关键项目和故障模式，或者是在项目中更新太晚从而导致设计已经固定。红色进行试验数据分析从而更新部件应力和损坏故障模型和模型参数。在研制的寿命周期早期，组织模式振动测量试验、热剖面测量试验和不减分析，从而确定底盘和电路卡装配（CCA）的自然频率、具有底盘

20、和原料性质的温度剖面，故障机理和/或高级损坏分析的内部结构。从试验中收集的数据将被用于验证和/或更新模型参数以利用损伤故障模型来精简分析。绿色组织有限的试验来更新在损伤故障模式中使用的部分不是全部的参数。黄色.没有组织试验来更新部件应力和模型参数。红色供应链管理RYG首选的/有资格的/核准的供应商清单、第二来源计划和应对未来零件报废的应急计划研发人员制定了清晰的管理程序和设计控制措施，包括对各项要求的分配，以确保从转包商和卖主那获得产品满足可靠性和维修性要求。在所有的技术评审中报告情况。研发人员已经对研发人员的供应链进行了分析，并有了全面了解。研发人员非常清楚各个可靠性风险和部件和组件供应商的

21、设计/生产情况。研发人员也已经分析和详细制定了应对零件报废的应急计划绿色制定了从转包商和卖主获得产品的一般/不具体的程序。研发人员对供应链有一个基本的了解，对部件和组件供应商的活动有一个大概的了解。制定了有限的/一般的计划来应对零件报废。黄色研发人员不了解供应链提供可靠零件的历史，也不清楚如何应对零件报废问题。红色基于供应商的历史质量数据和目前可靠性数据接受或拒绝其提出的建议。研发人员有一个适当的程序来了解供应商的产品质量历史。研发人员竭尽全力获得最近卖主产品的当前可靠性数据。详细的程序和标准根据卖主的历史质量数据和目前的可靠性数据适当地接受或拒绝卖主的建议。绿色研发人员对供应商产品质量的历史

22、有一个大概的了解，但不能了解卖主产品最近的可靠性情况。根据一定的基础（具有适当的程序但是没有详细的程序或标准可以作为做出决策的基础）作出接受/拒绝卖主建议的决定。黄色研发人员没有制定监督卖主质量的方法。红色计划和制定成熟的、记录良好的生产程序。研发人员已经为每一种产品制定了详细的、具体的生产程序。在检测和分析阶段确定了用来提高产品可靠性的各个程序提高设计参数。很好地记录了所有的生产程序。绿色研发人员已经为每一产品制定了没有特色的/不甚具体的生产过程。程序没有足够具体以使在检测和分析阶段确定用来提高产品可靠性的各项提高设计参数。没有很好地记录所有的生产程序。黄色研发人员没有制定生产程序。红色执行

23、确定的生产质量保证和资格检验程序。在整个寿命周期中，研发人员执行全部的工业标准确定的生产质量保证和设计的资格检验程序。绿色在整个寿命周期中，研发人员执行部分的工业标准确定的生产质量保证和设计的资格检验程序。黄色研发人员没有执行确定的生产质量保证和资格检验程序。红色故障跟踪和报告组织评审以保证纠正措施的部署与充分。研发人员组织定期评审以明确界定在研制阶段采取的所有的纠正措施，并使用户同意要采取的纠正措施。清楚记录全部的问题领域和纠正措施。绿色研发人员组织临时评审来讨论纠正措施。没有清楚界定各个问题和纠正措施，在评审阶段也没有全部涉及到所有的问题和纠正措施。记录不完整。黄色基本没有组织评审来讨论纠

24、正措施。没有界定和很好地记录（如果记录了）各个问题和纠正措施。红色适当记录故障部件的可描述性和故障分析。收集和分析了在检测阶段包括接收、性能评估和限制发生的全部故障。这些数据将被用作设计改进和故障类型确认。对每一故障都进行分析以确定具体的原因和影响。利用类似有限元分析法（FEA）的工具对问题区进行研究以确定故障的潜在原因。清楚记录所有的结果，并在每一技术评审中确定各个问题区/解决方案。绿色没有收集和分析在检测阶段发生的全部故障。没有记录全部的故障/分析，没有在技术评审中尽全力来对各个问题区/解决方案进行评审。黄色对故障的部件没有进行跟踪，也没有进行故障分析。如果进行了任何记录，记录得也很差。红

25、色使用故障报告、分析和纠正措施系统(FRACAS)研发人员具有一个完整的故障报告、分析和纠正措施系统(FRACAS)。故障报告、分析和纠正措施系统(FRACAS)过程是的结构合理，与产品设计小组直接相连。故障报告、分析和纠正措施系统(FRACAS)过程收集了跟踪和纠正缺陷必需的全部信息。故障报告、分析和纠正措施系统(FRACAS)在一个拥有权力和职责的故障评审委员会的管理下来分配用于解决问题的各种资源。绿色研发人员有一个系统可以跟踪和纠正缺陷，但是其结构并不合理，也不能总收集到必需的全部信息。个人可以评审各个故障并寻找解决方案，但是这一过程并没有在有组织的评审委员会的管理下对解决各个问题用的资

26、源进行分配。绿色研发人员没有建立一个跟踪和纠正缺陷的系统。红色验证与确认RYG更新潜在的故障模式/机理记录在项目的整个寿命周期里，研发人员很好地组织检测和分析，并详细记录了潜在的故障模式/机理。在研制阶段及时对记录进行更新。绿色研发人员试图保持对潜在的故障模式/机理进行更新，但是没有及时记录更新的情况。黄色研发人员没有记录更新的潜在故障模式/机理，或者记录地很差。红色改进可靠性分析方法和故障模型研发人员随工作环境和设计的变化来及时改进可靠性分析方法和故障模型。对所有影响可靠性的变化都进行了模拟。绿色研发人员没有随工作环境和设计的变化来及时改进可靠性分析方法和故障模型。没有对影响可靠性的全部变化

27、进行模拟。黄色在系统的整个寿命周期内，研发人员没有很好地改进可靠性分析方法和故障模型。红色基于产品现场故障改进检测和程序研发人员很好地跟踪现场故障，改进检测和程序以能够充分确定故障的原因，从而可以采取纠正措施和修理。绿色研发人员没有很好地跟踪产品现场故障，因此不总能改进检测和程序，进而不能充分确定故障原因，并针对所有故障采取纠正措施。黄色研发人员没有跟踪产品现场故障，进而不能改进任何确定故障原因的检测和程序。红色组织技术设计评审在产品研制阶段，研发人员根据当前已知的设计结构和知识定期组织对每一可靠性参数的评估，通过几个正式的技术评审（技术评审是典型的设计评审，例如：系统要求评审、系统功能评审、

28、早期设计评审、项目设计评审、关键设计评审和试验准备状态评审）强调早期的评估。绿色研发人员组织一定数量的评审，但是没有跟上最新的技术设计。没有定期组织正式的技术评审。黄色研发人员没有组织好可靠性参数的技术评估工作。红色可靠性改进RYG在没有用户指导下的可靠性改进工作研发人员定期带头组织基于工程的分析，并对试验结果进行分析，从而确定改进产品可靠性需要的设计改进工作。研发人员在没有用户指导下的改进工作。记录结果/改进措施，并在技术评审中提交这些记录。绿色研发人员带头进行一些设计改进工作，但是更倾向于在用户的指导下进行改进。黄色研发人员不进行任何改进，除非是在用户的指导下。红色记录经验教训确定吸收的经

29、验和教训，并与多功能小组的全部成员和整个组织进行沟通，以确保说明各个系统问题（及其解决方案）从而排除对旧问题和解决方案的重复。绿色没有很好地确定经验和教训，或者没有很好地与小组成员或整个组织进行沟通。黄色没有确定经验和教训，也没有与小组或整个组织进行沟通。没有记录原来的问题和解决方案，这就导致在将来会出现更多的故障。红色跟踪纠正措施的效果研发人员的结构控制很好。详细记录了全部的纠正措施及其效果。绿色研发人员记录了纠正措施，但是没有详细记录具体的细节和效果。黄色研发人员没有跟踪或很差地跟踪了纠正措施和记录其效果。红色保持关于现场事件的数据库研发人员指导发生在现场的所有事件，并保持了关于每一事件的详细数据库。绿色研