CBB(Common Building Block)即共同性构建模块,指那些可以在不同产品、系统之间共用的零部件、模块、技术及其他相关的设计成果,软件、硬件系统都有自己的CBB在产品中我们鼓励共享和重用CBB,这里面好处很多,比如对于采购、制造这些领域,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的一个负面典型案例。

,