原创 模块平台化

  最近一个同事在忙着将一个平台化的模块进行区分。这个想法是源于将不同的对象在同一个模块上实现，然后通过生产时候不同的配置使得一套外壳模具和一套PCB板能够覆盖很多车型以及不同的配置（高，中，低）。我在这里有一些想法，是关于车用模块平台化的。
  最典型的车用模块平台化的案例，可能就是BOSCH的发动机点火的模块，覆盖不同公司的不同车系，经过配置和匹配完成工作内容，当然这是一个非常成功的案例。但是似乎，这里有个先决条件，就是输入和输出的对象要较为统一。虽然发动机点火模块有诸多的传感器信号，控制信号也略有不同，不过总体而言，架构是类似的。
  我经历的有一个案子，是低成本的车用车身控制解决方案。通常的车身方案，往往都是控制板和驱动板合在一起的，在确定输入和输出参数的条件下进行设计。往往以PCB小型化，驱动芯片廉价适用化为目标，也把一个车型的不同配置考虑在内。但是这个方案的提出，是把控制和驱动分开，设计尽可能全潜在的输入和输出负载，通过节约模具费用和增大元件和单套PCB的数量的方式进行低成本化。这里就存在了很多的潜在问题：
1.模块有些配置使用，有些配置不用的端口怎么办？必须考虑端口抗干扰和静电的问题。某些不使用的电路往往直接连接至距离MCU很近的距离，如果不能有效的抑制传导和耦合的干扰，很容易出现问题。感性噪声引起MCU的Reset 这是一个很典型的案例。必须在可选的MCU接口上设置上拉和下拉电阻，悬空的接口是非常危险的，诸多配置可能引起潜在的问题。
2.驱动的负载的阈度如何设计？比如说典型的负载，灯泡和电机，驱动芯片本身能够覆盖的范围是有限的，而不同厂家采用的同样规格或者略有差异的负载，特性往往不同，如何去覆盖这些变化是个非常重要的问题。
3.单片机的IO口和能力选择？越多的IO，越高的工作频率和处理能力虽然可以覆盖大多数的设计，但是对成本和EMC性能来说，确实存在着太多的潜在的风险，同时由于不同的配置需要设计不同的程序以及不同的EOL的单元，这个事情也是非常考验人的。
4. 协调生产与设计？用同一个平台覆盖多个产品，意味着生产的时候需要分外的小心，另外的一个很大的问题是测试结果，如何协调一个很全的产品和一个部分的产品，本质上这两个产品虽然是同一个板子，由于不同的贴装只能说是具有参考意义的，测试的结果是不是使用最全的那个版本覆盖所有的版本，这是一个很考验人的事情。
  今天和有个新来的同事聊起了车用音响控制器，不同的公司确实有不同的方案，设计理念确实有很大的差异。我有时候不知道，哪个方向和方法是较为有效和较为正确的。只能说，对手头上经历的事情做较为深入的审视，对差异化的想法和设计思想进行对比，不断质疑和验证，可能能够有些不一样的结论出来。因此坦诚的说一句，关于以上的想法可能有很多偏颇的地方，欢迎大家指正和讨论。
  最后烟烟SHOW了最近购买的护肤系列，我只能说男人的任务是赚钱，女人的任务是花钱。最后的最后，我发现虽然遇到的女工程师并不同，但是她们对工作上的一些事情与设计的想法和我相差极大，有着完全不同的思想，有点点奇怪的说。