笔者总结了诊断的三个特征：资源消耗、软件统管、无标准参考。
　　需消耗软硬件资源
　　如果把内存也看作硬件资源的一种，则所有诊断均需要消耗软件和硬件资源。如果从狭上只认为硬件端口才能称作硬件资源，则功能诊断不需要额外的硬件资源。
　　图中为用一款高驱芯片驱动灯泡负载的例子，该芯片自带短路到地和开路检测，通过诊断使能、诊断片选，MCU可从诊断反馈口获得当前电流信息。而如果需要做短路到电源的诊断，则因驱动芯片无法支持，必须增加专用诊断电路来实现：即增加采样电路，将采样口返回至MCU，使MCU可以监测到电压情况。需注意的是由于是高驱芯片，这里的短路至电源的故障只能在芯片无输出的时候进行。
　　软件统一管理
　　一般场合下诊断的重要性并非是第一位的，而不同的诊断其重要性也有不同，所以不同诊断的管理策略往往也有差别。
　　很多软件的策略都需由系统的需求进行输入，诊断也如此。譬如哪些DTC需要在芯片打开时做哪些在打开时做、让一个故障灯亮起的条件...一个模块的功能诊断大多可以参考诊断协议和一般性需求制定，DTC的定义则十分灵活，不过也十分不易，因为制定太多则会增加软件工程师的工作量甚至会增加硬件成本，他们都会很不乐意甚至反对，所以每个DTC的必要性都需考虑清楚，否则当他人提出反对时定义者将无言以对。而对终端客户来说，如对制造、售后、故障分析的人而言，如果诊断定义得不当（如过少）又可能影响他们的工作乃至受到他们抱怨。故在定义时应充分合理，不能多不能少，只能恰到好处。
　　定义人员是上游客户和下游客户间的桥梁，诊断是基于硬件的软件实现，有时需要多轮的评审讨论才能确定最终的需求。
　　无统一的标准
　　对于一个成熟的公司来说，凡事如果有标准则事情将变得很简单，比如DV、PV测试，每个部件都能找到适用于它的标准，使得工程师不需怎么花时间在需要测哪些不需要测哪些上做过多谈论，可以将时间放在其他事情上。
　　很多功能的定义因前人已积累了多年经验和数据，他们已有的成果可以作为后来者的一个参考，可以认为是一种一定意义上的标准。

    而诊断的定义几乎没有很通用的标准可循，没有标准时便给参与的工程师提供了最大的自由发挥空间，因为任何人都可以从自己的立场来建议或反对，各自想法不一便会影响工作效率。很多公司已经定义了自己的诊断协议、DTC库，但是却没有定义每个模块的具体诊断，这是由诊断的多变性决定的、需要定义成标准需很多精力和知识，而管理者不一定舍得花这些人力来做此事，就当前而言仍然是在做具体开发时再定义对于每个模块的诊断需求。如果说花很多时间专门来做一个标准，可能会收到一定效果，但起码目前没有，可以随着经验的增加而做一些总结，以便为后来者提供便利，这是努力的方向之一。

（2015-1-19 发表于本人QQ空间）