缘由

模块诊断这块对于刚工作不久的需求定义者来说会比较头疼，因目前并没有哪个公司有一份通用性的指导或标准告诉定义者哪些该定哪些不需要定，定义者往往会收到一些零星要求或反馈说哪些必须做、哪些又做不了...定义出合理和清晰的诊断需求并非易事。正是由于缺乏诊断需求定义的标准或经验性文件，在这一章会稍微啰嗦一些，以便尽可能让需要者了解得更多；另一方面因相关原因，并不打算所叙述要包罗万象，在整个行业国内的平均水准比国外还差一些的大背景下，对我们来说不管是个人、团队还是企业通过相互分享，是可以共同提升和相互促进的。

将第三章放诊断的原因是它也是设计中极重要的部分，只是有时有时为了赶时间不一定会计较得面面俱到，在因为细节而出了很多bug。

特征

没有统一的定义标准或经验是诊断的特征之一，它的另一个特征便是需要消耗硬件资源（但狭义而言并非所有的都需要），某些诊断需求很可能要用到额外的硬件资源从而带来成本的增加，那么为实现该诊断而增加成本是否有必要呢？定义者需要考虑清楚、需要在成本与需求之间找到平衡点。第三个特征就是一般来说所有的诊断功能均需要软件参与（不排除极少数用纯硬件方式实现，但是那样DTC是无法传送出来的，这种情况不在我的讨论范围），没有软件的参与硬件无法实现独立的诊断，也就是硬件是基础、软件是手段，更多的诊断必然要求更多的软件资源、更多的测试资源，是否完全必要也是需要充分考虑的。

主线