模块化（CBB）硬件设计（模块化 设计）

模块化（CBB）硬件设计（模块化 设计）

CBB（Common Building Block）即共同性构建模块，指那些可以在不同产品、系统之间共用的零部件、模块、技术及其他相关的设计成果，软件、硬件系统都有自己的CBB。在产品中我们鼓励共享和重用CBB，这里面好处很多，比如对于采购、制造这些领域，CBB可以降低采购成本，降低库存和出现物料呆死的风险，也更利于大批量制造。

我们重点讨论一下硬件CBB，硬件基础模块是硬件系统中一组实现特定功能、性能及规格的实体硬件单元，对外以硬件接口的方式呈现，而接口包含了硬件模块所提供的功能和应用它时所需的要素。硬件基础模块是构成硬件产品和硬件系统的单元，是基于硬件系统架构逐步抽象出来、定义开发的，硬件CBB包括可共享硬件器件、可共享硬件组件/模块、可共享单板、可共享整机、可共享硬件系统等。

对于硬件研发团队硬件CBB的价值很大，对CBB的坚定投资是有高回报的。首先，硬件技术、硬件模块若被大量共享，能够极大降低研发成本，提升研发效率；在硬件共享的基础上，增加新技术、新特性，新产品的开发将一直“站在巨人的肩膀”，利于对市场做出快速反应。同时，工程师在一个CBB模块上持续发现、解决问题，提升CBB质量，打磨出高质量的CBB，这也是产品质量保障的有效手段，共享成熟度高的货架产品，能够大大增加了产品稳定性和可靠性。另外，坚持共享，可以减少开发团队低水平重复投入，释放人力资源做更有价值的工作。

很多做硬件产品的大公司都把硬件CCB作为系统构建的核心资产，坚持通过CBB的开发和维护提高整体设计效率和设计质量，缩短开发周期。在大公司里有些高价值的CBB甚至可以跨产品、跨产品线共用，支持不同的应用系统，具备灵活方便的二次开发能力；与产品或应用系统间界面清晰，能实现平行开发；硬件CBB模块功能规格、性能指标清晰，可测试、可维护，还有完善的资料手册。大公司把CBB的构建定义为平台战略的关键支点，是公司重要的组织资产。

硬件工程师要特别要关注那些高价值硬件CBB的开发和维护。比如，你开发的无线路由器产品都会应用2.4G或5G的棒状天线，那么就要关注天线的性能指标、降成本空间、应用问题等；如果你是开发服务器产品的，可能70%的产品都会重用一款X86 CPU，那CPU CBB的硬件设计就是至关重要的，CBB交付后，你还要持续跟踪供应商，刷新器件问题列表，合入新的优化点。这些高价值CBB的持续投入能够让借用这个CBB的多款产品都收益。

“好的CBB是管理出来的”，CBB管理过程不是一个独立的流程，而是嵌入在产品流程化的开发活动中。CBB管理可以分为4个阶段：定义规划、设计开发、使用监控、维护优化四个阶段，详解一下这四个阶段的主要工作。

阶段一：规划定义阶段

在总体设计阶段，就要规划CBB，针对不同种类的产品，CBB规划的侧重点就不一样。如复杂框式硬件，产品的生命周期很长，对于电源、风扇、拉手条等关键组件都必须要CBB化；各单板上对于背板的接口、各个单板子节点的监控也要定义为CBB，保证规则和设计要求的一致。盒式海量发货的单板很多都是系列化的设计，在一个系列中核心模块是共用的，比如CPU模块、业务接口模块等，为了保证一个系列类所有单板都遵循统一规则，并且整个产品系列成本最优，这些核心共用模块都要规划为CBB。终端类产品的CBB更有学问了，这类产品的定制化诉求强烈，单个款型对成本都极度敏感，因此如果定义CBB，必须要和产品设计耦合度极低，避免对其它模块设计有影响，因为冗余设计导致成本增加。

阶段二、设计开发阶段

规划好后，我们要进行CBB的设计。首先要确定好硬件CBB的设计人员，由于CBB是一个通用模块，工程师设计CBB时要跳出单板，看到系列化的产品和这个产品的演进路径，心里有全景图，才可能做出一个有生命力的CBB。定了设计人员，就要认真分析CBB的各种接口，做好抽象的工作，这个设计很考验硬件工程师，接口定义不全就很难通用化，定义的过于复杂，冗余太多，又会在CBB上沉淀过多的成本，应用起来复杂度很好。比如，CPU这类核心处理模块定义CBB难度就很高，内存和Flash怎么定义？电源模块是放到CBB内，还是CBB外？集成方式是扣板还是在直接放在主板上？等等这些问题都需要仔细考虑。定义完接口后就要做模块的原理图和PCB，想到你的模块会被大量借用，你就会感到自己责任重大了。最后，还要提醒一下，CBB一定要通过文档传递你的接口定义和关键的设计要求，方便借用者使用。

阶段三、使用监控阶段

好的CBB不是一蹴而就了，CBB交付后会在一块或者几块单板上先使用，这时候你就要开始监控使用时遇到的问题，不管是在设计阶段还在产品上市发货后。硬件工程师要监控这些CBB模块在整机或者系统被借用时，使用是否方便，接口的定义对主板的设计限制是否太多了。模块在发货后适应不同单板和系统在不同场景应用有什么质量问题，比如是不是借用到室外产品后防护规格就不满足要求了。收集这些问题后，进行记录和整理，这个是进行CBB优化的依据。

阶段四、维护优化阶段

问题都收集全了，下一步就是进行优化了，切记每一个改动都要特别小心，要做好记录，改动点的验证要覆盖到这个CBB不同的场景上。这里还要强调一下，硬件CBB的修改是否影响软件系统要特别注意，我们在CBB设计阶段都会把硬件对软件的要求写清楚，和软件工程师做好澄清，但是在硬件CBB维护优化时，有时会疏漏针对所有借用CBB的单板或整机同步修改点，请软件工程师分析是否要优化软件，导致了硬件模块优化升级了，软件适配没更上，产品一上线问题就暴露了。

这十多年中，我从一个初入硬件行业的小白逐步成长为一个老练的硬件工程师，我一直在和CBB打交道。

刚进入硬件团队的时候被师傅安排去维护几个成熟的CBB，根据收集到的问题进行优化。那时候有两点体会，一是有些同事水平很高，设计出的CBB考虑非常全面，特别是对于场景适应性的考虑很细致，借用到单板或整机上问题很少，我维护起来很方便；二是CBB优化后的验证是个技术活，修改点要覆盖全，这逼着我去熟悉不同的单板。

后来，我有机会做核心CBB的设计师，那时候觉得很有荣誉感，当时我做了一个ARM CPU的CBB，做接口设计时天天都和软件架构师泡在一起，学习业务模型，软件规格升级要求等知识，觉得自己进步很快。还有一个让我印象深刻的事是，当时我的主管要求我硬件CBB设计一定要文档化，文档要包括的主要内容有：CBB整体介绍，包括功能描述和重要性能指标描述，限制条设计及应用关注点；CBB电路设计，包括原理图和接口设计说明，关键接口设计要求等；CBB PCB设计指导，对于CBB电源、时钟、散热的设计要求都要重点说明；CBB对于软件的设计说明，对于一些需要配置的接口要特别写清楚。

等我成为硬件项目经理的时，我更加能体会到CBB的价值和问题，规划好的CBB，对于设计效率，供应柔性，制造通用性帮助都很大。然而，我也体会到定义CBB也是一种“妥协”的结果，由于在资源、时间、成本等方面的限制，不同团队的核心目标可能会和CBB建设的目标发生冲突。这时候就需要项目经理站出来，去平衡各方利益，坚持对团队长期利益最优原则，说服大家使用CBB。

同时，我还希望大家多去思考并警惕过度CBB化给产品和团队带来的“负作用”。首先在产品设计中，由硬件CBB搭积木一样组合一个单板让硬件设计缺乏了很多美感，强行使用CBB导致有些设计很变扭，不得不进行妥协，硬件成本做不到极致。其次，CBB质量出问题会有蝴蝶效应，特别是核心CBB出问题对于产品就是灾难，一个单点错导致系列化的产品都出错。2009年起丰田公司旗下的多款车型因加速踏板故障存在自动加速问题,导致多起伤亡，这个刹车门事件就是CBB应用的一个负面典型案例。最后，回到CBB对于硬件工程师的“负作用”，过多依赖CBB师硬件工程师失去了对产品每个关键模块设计细节的控制力，由设计师变成了装配工人，有空心化的风险，很难培养出18般武艺样样精通的高手。综上，不论对于大公司，还是中小公司，硬件CBB都不是万能的，我们在通过CBB获益的同时也要预防CBB给我们带来的问题。

大公司用CBB能够帮助团队减少工作量，提升硬件模块复用，优化了采购、制造等后端流程。但是CBB也是一剂毒药，对于产品设计，让硬件工程师不求甚解，硬件性能、质量、成本可能都做不到极致；对于质量，有些CBB内的问题对于产品就是灾难，一个错大家都错，丰田刹车门就是CBB的一个负面典型案例。