原创 设计的发布

    前面写过一篇文章，是关于循环设计的，其实以前我一直不太清楚Release发布是一个什么概念，相信对于大多数工程师而言，可能也不知道这个Release的意义，而面对后面的设计变更管理（Change management）可能更模糊一些，我最近对于整车的一些开发流程进行了一些学习，慢慢有些想法，在此整理一下，可能有很多错误。

   在前面的一篇文章中，把整车根据各个部分进行划分，称为VPPS，这是按照功能零件进行划分，但实际上整车中有很多零件是复用的。VPPS中一般从1级分类可以划分至7～8级，由底层的级数进行组装形成上一级分类，并且每个等级有可能复用。比如门控模块，后门的模块是一样的，在车里面使用了两次，因此在VPPS里面只有一个规范，但是有另外的唯一的一组编号，定义这个部件在车里面，是右后门或者是左前门。这是对于整车的概念，因为这既涉及到采购，又涉及到生产，对于工程部门而言，后门两个门的控制模块是完全一样的，但是对于后门两个部门而言，就完全不同了。

   沿着上面的思路，对于门控模块而言，它里面有很多的部件，成品而言：上壳，PCBA（装配好的PCB），下壳，外部打标的标签等，这些都需要发布专门的图纸定义。在生产前，PCB空板，上壳，下壳，空白标签，空白单片机和软件程序等，这些重要的部分。注意一般模块的单片机，有两种方式灌程序，如果你足够强势可以要求单片机在MCU厂家那里灌入，否则就得自己在生产前灌入。以上的这些东西，主要涉及模块在生产过程中，并不像研发过程中那样简单，需要对所有的部件进行定义，需要配置相应的图纸。

    这里必须要说明一个事情，工程物料清单（Engineering BOM）和器件供应商列表PQVL（Product Qualified Vendor List）是有一定的区别的，这里需要进行一些转换。在器件定义的时候，往往并不会在BOM中添加供应商的厂家信息，因此BOM中只会用一个元件属性号（一般公司定义，属于公司内部编号）+元件表称号两个定义，前者用来定义其类型，属性的因素，后一个位置来确定其在整个板子中的唯一性。而在PQVL中，则必须加入供应商和其对供应商的订单号码，这个确保其采购的唯一性。而且一般需要给每个元件，配置2～3个供应商，防止产品在缺货的时候不能用。但事实上，有些部件不太存在替换件，不同厂家的芯片可能是Pin to Pin，但是其性能可能并不相同，因此前期的设计工程中，往往很多的采用元件属性号；而在采购和生产中，直接使用厂家的元件编号。

    因此，所有的设计发布，实质上是将设计过程中的冻结的部分，整理成为可以采购和生产的东西。因此需要将，硬件的PCB Gerber图纸，PQVL清单，下线测试EOL规范，软件规范，外壳图纸等等进行打包。并且给以上的这些文件进行统一的有联系的命名，以方便其他部门调用，有点涉及文档概念了。

    其实将技术和管理分开是个伪命题，当然大多数的人都认为“管理”是“管人”，在产品开发过程中，技术研发仅仅是一个部分，有大量的设计文档和过程文档需要开发人员进行创建和管理，也需要开发人员与不同职能部门的人进行协作和沟通，才能达到一个令人满意的效果。

设计发布的作用

    这里就要谈到设计变更了，一般而言在设计的前期中，整车企业的需求（功能规范，硬件规范，工程规范）可能是需要改变的；但是到了DV阶段（Design Validation），零部件企业需要将设计文档和需求文档，进行固定的封存，在这之前的变更，属于研发费用，在这之后就属于整车企业需要额外支付费用了。因此可以说，这对于零部件企业的工程师而言是一种保护，也是对于整车企业和零部件企业的“君子协定”。

误区

     我遇到的情况，就是由于某些整车企业需求的定义不清，或者说没有能力去定义；而同时，零部件企业又不足够强势的时候，就容易出现很多的问题。频繁的更改和内部的设计问题，曾经导致出现很多版无谓的更改，使得硬件工程师饱受非议，软件工程师疲于奔命。

     当然也尝试过不用设计发布，让文件系统处于浮动状态下，结果更悲惨，经常背炸弹。当时被这些琐碎的事情和繁重的海外支持工作搞得身心俱疲，往事了……

建议

     在使用正式的软件系统发布这些文件之前，也就是DV之前，需要使用相对灵活一些的设计Release的方式，否则将所有的文件整理进系统是个非常麻烦的事情，如果IT系统又不足够人性化的情况下。

    个人的一点体会和总结，可能有很多错误，如有异议可直接留言，免得误导其他xdjm。