诊断之美-流程

 　　一个系统诊断项目可以分为计划，开发，调试，维护几个阶段。
　　
　　计划阶段要做的是硬件分析和进度安排。
　　
　　1.确定系统的处理器类型。比较常见的有x86，arm和ppc。
　　2. 确定系统启动代码的存放设备。在系统上电时，处理器会跳到某个固定地址去读取第一条指令。这个地址一般会被映射到一块闪存，其中存放了系统最初的启动代码，也就是boot loader。这段代码会建立起软件的基本运行环境，以便后续的诊断代码能够执行。关于boot loader的具体功能和流程，请自行搜索相关文档。
　　3.确定系统和开发者的交互方式。个人电脑通过显卡，而大多数的系统是通过UART来传送字符串。
　　
　　以上三个部分是系统能够进行诊断的最小集合。硬件工程师必须保证这个最小集合是工作的，否则就要通过外部设备来找出硬件故障了。
　　
　　4. 在大型系统上，往往有几个子系统，每个子系统拥有独立的处理器集群和主板，通过背板连接在一起。对于这种情况，我们可以按照处理器来划分，分开处理。通常他们中会有一个监控板，负责联系外部和监管其他子系统。前面提到的最小集合概念对这个监控系统仍然适用。对于其他的板，有两种可能。一个就是还是使用 UART，上电的时候单独诊断。另一种可能就是需要一个额外的通讯接口，连接到监控板来实现人机交互。硬件工程师必须保证这个额外的接口也是工作的。
　　
　　5.确定需要进行诊断开发的设备。在很多情况下，硬件系统只是局部更新，那么我们只需集中在这一部分新的设备上即可。
　　6. 确定每个设备的类型和访问方式。典型的设备类型有：缓存，各种内存，闪存，各种控制器，数据处理器件，可编程阵列，定时器等。有些设备是集成在处理器内部的，它们的诊断可以根据情况省略。原因是处理器芯片通常非常稳定，如果能够启动代码能够运行，那么我们可以认为片上的其他内部设备也是可靠的。但是所有外部器件都应该有对应的诊断测试。我们还要弄清每个外部器件和处理器的连接方式来开发驱动程序。
　　7.针对每个设备，根据前文提到的五层任务来写详尽的诊断列表。这点将在后文展开。
　　8.为每个诊断条目估计一个编码时间，然后乘以三作为写代码，单元测试和回归测试的总时间。将这个时间和整个项目时间表作比较。如果达不到预期，那么就需要更多的人力和资源。有经验的工程师能够判断出那些诊断是难点，从而更合理的安排资源。
　　9.写一份详尽的诊断开发计划，包括时间和诊断列表的详细说明。和硬件工程师讨论，看是否有遗漏。
　　10. 还有一点，就是尽量把代码开发的时间安排在第一个硬件出厂的时间点之前，这样可以在拿到硬件后立刻开始系统调试。在开发代码的阶段，如果有模拟器的话最好能试运行，没有的话也尽量利用类似的系统来跑诊断程序，这样会大大减少软件本身的错误，从而提高在真正的硬件系统调试阶段的效率。
　　以上十条就是在计划阶段所需要的步骤。总的来说，就是定列表，定时间，写计划。
　　
　　进入开发阶段，我们所需的工作和普通软件工程开发没有什么区别。一般包括：
　　1.版本控制下的代码开发和互相审阅
　　2.单元测试，回归测试和提交。
　　3.周期性代码集成和回归测试

 

　　接下去是硬件出厂后的系统调试阶段。这也是最能体现诊断工程师价值的阶段。完善的前期工作能够使得这个阶段的调试有条不紊，覆盖全面，同时还能精确的定位硬件问题。这个阶段也非常考验工程师的个人能力，包括调试与沟通两方面。以下一些经验可能会有帮助：
　　1. 要有诊断的思维方式。什么是诊断的思维方式？一句话，以不变应万变。在前文提到的最小集合的概念中，就牵涉到这个思想。诊断就是要拿已知的，确定的，可靠的东西去探测未知的错误。举一个实际的例子：一块芯片，设计是完好的，拿去做了一点功能改进后，新的芯片集成到主板上，发现出现问题了。作为诊断工程师，应该怎么来解析这个问题？首先，我们应该看哪些东西变动了。在这种情况下，有四种东西变了。1.芯片设计图。2.主板设计图。3.制造出来的多个芯片个体之间的差异。4.制造出来的多个主板个体间的差异。那我们就可以从这四个方面着手来判断。先假设制造出来的多个芯片和主板个体差异为零，也就是说，都是和设计一致的。那么，错误就集中到第一和第二点上。而第二点是可以排除的，因为芯片的改动是内部的，并不引起主板设计上的改动。接下来这一步就很容易了，我们只要着重观察芯片原型改动的部分就可以了。如果查不出错误，那么就说明我们的假设错误了，制造出来的芯片和主板个体间差异不为零，并且这个差异引起了错误。那么，先假设差异在芯片上，主板都是好的。我们可以通过多换几个芯片做实验来判断。如果每个芯片个体都会引起错误，那么可能问题就是在主板的差异上。通过类似的方法，我们最终就可以确定问题的根源。
　　这个思维方式还可以用另外一种方式来体现。在做数据通路的诊断时，我们会发现数据流不能在末端被接收到。怎么办？解决的方法就是，先通过前文提到的五层诊断任务中的第一层和第二层，确定通路上的每一个设备都是好的，并且每两个设备间的通路也是完好的。有了这个基础，我们才能进行下一步。接下来我们要确认每个设备的初始化都是正确的。如果这些都没问题，那么我们需要观察每个设备上的计数器，状态统计以及中断，看看数据到了哪一步出现了问题，问题的原因是什么。在这个过程中，我们不断扩大已知的东西，缩小未知的范围，最终，整个通路被完全解析，你说还有什么问题不能解决的呢？
　　
　　2. 善于和硬件工程师合作。当我们的诊断程序发现问题，不要立刻把问题丢给硬件工程师。而是自己先做分析，判断到底是软件还是硬件的问题。如果确认是硬件，那么要拿出数据来证明。如果不能确定，那么可以把需要硬件工程师做的辅助工作清晰的列出，然后和他商量一个时间一起调试。如果能够连续几次发现他们的硬件问题，那么他们就会对你的意见很重视，下次合作就会很顺利。相反，如果每次都发现是软件本身没写好，那你的信誉就会打折扣。
　　3.解决问题后做完善的测试。有时候，诊断工程师觉得只修正了一两行代码，不会引起多大的变化；或者遇到一系列相同的问题，解决了其中一个，就会觉得其他的用相同方法能解决；再或者，觉得解决了第一步，整个问题就应该被解决了，不会出现后续错误。所有这些想法都要被杜绝。在解决了一个问题之后，一定要做单元测试。在正式提交前，最好要做回归测试。在得到明确的结果前，千万不要想当然的汇报给硬件说问题解决了，也不要缩短解决问题所需的预期时间。提前一两天解决问题，别人不会觉得你水平更高；但是一旦在预计时间内没解决，或者声称解决了但是最终还是有问题，那你就要被质疑了。
　　4.要善于利用现有资源。在开发过程中，很多代码都是有现成的，比如驱动程序。如果诊断组内没有，那么硬件组或者软件也可能有。如果公司都在一个框架上开发，那么就更容易拿到这些代码资源了。同样，发现一个复杂的缺陷，也可以现在组内看看是不是之前有人遇到过。不过缺陷最好别轻易的去问别的组，不然别人觉得整个诊断组水平不够。此外，可以多问问设备提供商的售后工程师，他们会热心帮你解决问题，从而体现他们的价值。还有，组内成员之间要多沟通，共享知识和经验。一个比较好的方式就是定期组织演讲，介绍各个成员做过的东西或者擅长的领域。这样对别人会有帮助，对自己也能提高声誉。
　　5.发现可能引起工程延误的问题要及早汇报，以投入更多的资源来解决。不能等到最后期限了才说。那时候就晚了。这一点可以通过每周甚至是每日的项目会议来避免。
　　6. 要有大局观，有愿景(Vision)。做到了以上的五点，只能让你成为一个优秀的工程师，提供高质量的软件。但是要实现小组和个人的成长，我觉得还远远不够。我们必须明白，遵循开发流程写代码，目的绝不仅仅是为了开发一个诊断系统，而是在为我们的客户提供服务。我们必须了解到他们需要什么，是不是能提供更先进的诊断概念来让他们更满意。这就牵涉到我们的诊断是不是够专业，我们的平台和构架是不是够完善。还有，公司是不是有其他团队也做同样的事情，我们能否借鉴他们的经验。带着这样的想法去工作，看似琐碎的事情就会变得有意义。这是技术上的愿景，还有战略上的愿景。我们要清楚自己这个部门在公司的定位，为什么要存在，谁给我们预算。还有我们所服务的产品在公司整体的战略中是怎样一个地位，产品销路好不好，是不是核心产品。只有在大的背景下，我们的工作才有意义，否则做的再好，产品也有可能被裁掉。当然，好的团队即使换到别的产品线也还是会受到认可的。此外，还有财务上的愿景。我们的诊断系统开发成本如何，改进需要多少人力，需要花多少钱，在哪里雇佣工程师做这些事情性价比更高。还有，花这些钱是不是能给别人带来成本上的降低。如果答案是可以，那么怎么去说服别人花钱来用我们的服务。此外还有人事上的愿景等等。
　　那么怎么才能形成这种大局观呢？我想，哪怕是在拥有良好培训环境和个人成长机制的外资企业，也很少会有人帮你培养这种思想；相反，在大型企业，由于总是专注于某一个模块，有的工程师会很容易陷入其中，最终失去了工作的激情和动力，变成了被动的的完成任务。只有不断的思考，并且通过和别人沟通，和社会沟通，我们才会有长远规划，不断调整自己的软技能和硬技能，从而更好的成长。
　　
　　最后是维护阶段。这个阶段主要是硬件制造商和售后工程师会不断的通过缺陷跟踪系统提交新发现的问题。如果是引起整个生产线停产的问题，那么诊断工程师必须快速的确定问题是软件还是硬件，给出解决方案。如果是一般问题，那么也要在期限内给出答案。这样，诊断工程师就会得到他们的正面评价，从而赢得声誉，获得成长。