做汽车行业的自动化项目这些年我越来越觉得SICAR是每个想在这行长期待下去的工程师绕不开的坎。你可能刚拿到一套TIA Portal里的程序打开一看全是规律得像印刷体一样的FB块、命名规整的DB块这就是SICAR的影子。SICAR全称是Siemens Car Standard翻译过来就是“西门子汽车规范”它不只是一份文档更是一整套围绕汽车行业PLC/HMI项目的标准化开发方法论。这篇文章就围绕SICAR展开讲清楚它到底是什么、规范了哪些东西、怎么落地使用以及我在实际项目中踩过的坑和总结的经验。适合刚切入汽车产线的自动化工程师、集成商的技术负责人还有那些想在非标设备里引进标准化思路的朋友。我第一次接触SICAR是在一个焊装车间改造项目里。当时客户验收的第一条硬指标不是设备能不能动而是“程序是否符合SICAR规范”。那时候我才意识到在汽车行业程序代码本身就是交付物的一部分而且是按标准验收的那种交付物。后来我陆续参与过几条完整的白车身和动力总成产线项目从方案设计到调试陪产对SICAR的认识也从最初“觉得它麻烦”变成“确实离不开它”。这篇文章我不讲官方宣传稿我就按一个一线工程师的视角把SICAR的框架、实操、坑点一次性说透。1. 为什么汽车行业需要一套“宪法”而不是几份模板1.1 汽车产线的“三高三长”决定了标准化的刚需汽车产线和普通的非标设备最不一样的地方是它的“三高三长”高节拍、高柔性、高并发以及长生命周期、长调试周期、长维护周期。一条60JPH每小时60台车的焊装主线PLCS7-1500里的程序动辄几万个PLC变量、上千个FB实例。如果每个工程师都按自己的习惯写程序换一个人维护就是场灾难。我见过非标设备厂商给汽车客户做的程序同一卷线里电机控制有三种风格一种用置位复位一种用自锁线圈还有一种用SFC写状态机。程序能跑但出了问题没人敢动。汽车行业还有一个场景是“全球造车”同一个平台的车在德国、中国、美国、墨西哥的工厂都要生产产线可能来自不同集成商。如果没有一套统一的程序规范那从设备调试到后期维护每个工厂都要重新培养一批维护团队成本完全不可控。所以汽车OEM从上世纪开始就推动集成商按照统一的自动化标准来交项目。SICAR就是在这种背景下被广泛使用的标准之一。1.2 标准化到底解决了谁的痛点很多工程师一听“标准化”就觉得是公司管理层用来限制创造力的工具实际不是这么回事。标准化解决的是三个层面的痛点第一是调试工程师的时间写过的标准块可以直接复用不用每个设备都从零开始写逻辑第二是维护工程师的信任一个标准电机块在十来个项目里验证过远比现场临时写的一段逻辑可靠第三是项目交接的成本新来的同事拿到程序就能根据命名规范快速定位不需要原开发者在旁边讲三天。我举个实际例子。在一个发动机装配线项目中有几十台拧紧枪每台拧紧枪的控制逻辑包含自动循环、结果判断、报警处理、数据上抛。如果没有标准块这几十台枪的逻辑可能被写成几十种样子。用了SICAR的思路之后每台枪只是标准FB的一个实例参数不同而已。程序里看到“K”前缀就知道是拧紧枪看到后面的编号就知道是哪台出了问题直接打开对应的背景DB就能查状态。这种心智负担的降低在紧张调试阶段的价值是没法用钱衡量的。1.3 SICAR不是西门子拍脑袋定的名字SICAR发展到现在已经不仅仅是一份文档。它实际上由三部分组成标准库Library、编程规范Guideline、项目模板Template。标准库里放的是经过验证的功能块比如电机控制、阀控制、气缸控制、报警管理、配方管理、安全逻辑等编程规范规定的是命名规则、程序结构、变量表布局、报警文本格式项目模板则是一个已经搭好框架的TIA Portal项目拿到手之后直接往里填具体工艺就行。这三部分配合起来就构成了一个从模块到项目再到生产线的完整标准体系。用我的话来说它不是一套“约束”而是一套“脚手架”。约束是限制你想干什么脚手架是指导你怎么高效地建成房子。这也是我后期带团队时最常用的一句话SICAR是手段不是目的目的是让项目又快又稳地交付。2. SICAR的核心框架到底拆开了看是什么2.1 生产层级与命名的“AK”体系SICAR对命名最核心的贡献是引用了汽车行业常见的AK德语Anlagenkennzeichnung设备标识层级体系。这个概念不复杂就是把整个工厂从大到小分成几个层级AK1通常是工厂或者厂区AK2是区域或者线体AK3是工位或者设备组AK4是单台设备AK5是设备里面的部件AK6是具体的信号点。在实际编程中PLC变量、DB块、FC/FB的名称甚至HMI画面的名称都会把AK层级嵌进去。举个例子一条白车身线AK2可能叫“WH”Body in WhiteAK3叫“ST10”工位10AK4叫“MOT01”这台工位上的第一个电机那这个电机的运行反馈信号就能命名成“WH_ST10_MOT01_RUN”对应的FB背景DB可能叫“DB_MOTOR_WH_ST10_MOT01”。你只要扫一眼名字就知道这个变量在物理世界的哪个位置。好处是显而易见的程序不再是“纸面逻辑”和“物理设备”两张皮对照着铭牌就能在程序里找到对应的块。尤其是现场查故障的时候拿着图纸找到电机编号在PLC里一搜名字直接跳到这个设备的所有逻辑和报警效率完全不一样。这种做法在非标行业偶尔也会遇到但大多数是没有全厂统一规划只有局部工位的简写不成体系。SICAR把它做成了所有项目必须遵守的底线性规则。2.2 程序的组织OB/FC/FB/DB各管一摊SICAR对程序结构有一个很明确的分层原则OB只做“委派”不写业务逻辑FC做“流程组织”负责按顺序调起工位内的各个设备FB做“设备控制”每个物理设备对应一个FB实例DB只做“数据仓库”存储状态、参数和诊断信息。这个分层最主要的价值是避免了“面条代码”。我见过很多非标项目一个OB1里面塞了上万行程序全是线圈和定时器。这种程序在设备少的时候看不出问题一旦工位超过10个逻辑之间的耦合度就爆炸了。SICAR的做法是把每个工位封装成一个独立的调用结构工位和工位之间通过命名约定和接口交换数据而不是互相直接访问内部位。从实际维护角度讲我可以把一条线的程序拆成几十个独立的“零件”哪个坏了换哪个。再有一点SICAR对OB的组织也很讲究。除了OB1主循环之外标准的程序包里通常有OB100暖启动初始化、OB82诊断错误处理、OB121/OB122编程错误和IO访问错误等。不同优先级的报警和故障会有意识地分配到不同OB里去处理这样就不会出现程序哪里进死循环了连错误都来不及上报的情况。2.3 标准对象块电机、阀门、气缸的封装逻辑SICAR标准库里最常用的是对象控制块。所谓对象控制块就是你把一种设备的所有控制逻辑做成一个模板FB比如“FB_MOTOR”管所有电机“FB_VALVE”管所有阀门“FB_CYL”管所有气缸。每个设备使用的时候只需建立一个对应的背景DB把参数填进去就行。以电机块为例它一般包含这些输入输出命令输入启动、停止、复位、反馈信号运行反馈、故障反馈、过载信号、联锁条件、超时监控、故障输出等。它内部会自动处理“启动命令已发出但反馈未到位”这种超时情况也会在复位按钮按下之后对故障寄存器做清除。一个设备调试人员想在程序里临时“旁路”某个信号他只需要在对应的背景DB里改联锁位而不是去程序逻辑里找那段“迷宫”。这种封装逻辑给现场调试带来的直接好处是新设备的程序不需要从零开始写项目前期的工作量变成了“查表、复制、填参数”。到现场之后大部分时间是在跟机械、电气、工艺打交道而不是在改程序。说实话在汽车行业做调试真正花在PLC逻辑上的时间比重是越来越少的因为标准块已经替你完成了90%的基础工作。2.4 HMI、报警与数据采集的约定程序标准化只是SICAR的一部分HMI和报警的约定同样关键。SICAR对HMI的规定主要体现在画面层级、控件命名和变量连接方式上。画面的布局通常和AK层级一致工厂级画面是总览往下是线体画面再往下是工位画面最下面是设备级诊断画面。操作员和维修人员能顺着画面层级一层一层往下钻直到看到某个传感器具体是哪个IO地址。报警文本这块尤其值得说。SICAR的报警管理一般要求在PLC侧生成报警文本变量名和报警文本有固定的映射关系。报警分为不同等级比如“急停触发”这种安全级报警和“滤芯堵塞”这种维护级报警放在不同的报警类别里HMI上显示的颜色、优先级、确认方式都不同。数据采集方面SICAR会定义专门的DB区域来存放需要上抛的质量数据、设备状态和能耗数据上层MES系统只需要读约定好的DB地址不需要关心PLC内部逻辑怎么写的。这种“接口契约”思想让自动化层和IT层之间可以并行开发不互相拖累。3. 把一个SICAR项目从零搭起来实操流程走一遍3.1 开工之前的组态清单很多工程师一上来就建项目写程序这在SICAR体系里是大忌。按标准流程开工之前先要梳理一份组态清单内容包括AK编码表、IO清单、设备清单、安全回路清单、报警清单、HMI页面结构、上位机接口表。这套清单不需要多花哨但要全。我通常会用Excel配合Eplan的部件库把每个设备的AK号、端子号、信号类型都对齐。组态清单的价值在于它把整个程序架构的“骨架”先搭好了。后面写代码其实是在这个骨架上填肉不会出现写到一半发现少了一个工位、IO点分配冲突的问题。我记得有次一个项目客户在半路追加了三个拧紧工位因为前期AK编码预留了扩展号段程序侧只是增加了几个FB实例和对应的IO映射工作量和风险远小于传统方式。硬件的组态也要提前做好规划。SICAR对PLC型号、通信模块、分布式IO站的位置都有建议。最核心的一个原则是一台PLC控制的范围要有明确的物理边界不要一台PLC既管主线又管辅机中间跨太多远程站。Profinet设备名称和IP地址要按AK规则统一编比如“plc-wh-st10”这样将来网络扫描时一眼能看出哪个设备在哪。3.2 一个电机FB的接口到底怎么设计这里我用电机控制块举个例子说说接口设计的具体思路。一个完整的标准电机FB输入侧一定要把“命令”和“条件”分开输出侧把“状态”和“故障”分开。命令类输入包括启动、停止、复位条件类输入包括“允许启动联锁”、“允许停止联锁”、“保护信号”等状态类输出包括运行状态、停止状态、故障状态故障类输出包括过载、反馈超时、联锁断开等。写FB接口时容易犯的错误是把所有输入都堆在一起逻辑上分不清哪个是“我要它启动”的意愿哪个是“它能不能启动”的条件。这就导致逻辑耦合特别严重后期想在HMI上加一个“自动允许”条件往往要改FB内部逻辑。标准做法是定义接口时严格区分命令和条件联锁条件通过一个UDT统一管理内部逻辑只认这个UDT的结果。这样现场部署的时候工艺改动只需要改联锁UDT的参数不需要动FB逻辑。我把一个简化版的电机块接口用ST语言示意如下TIA Portal环境下的常见写法FUNCTION_BLOCK FB_MOTOR VAR_INPUT bCmdOn : BOOL; // 启动命令 bCmdOff : BOOL; // 停止命令 bReset : BOOL; // 故障复位 bInterlockOk : BOOL : TRUE; // 外部联锁允许 bFeedbackRun : BOOL; // 运行反馈 bFeedbackFault: BOOL; // 故障反馈输入 tOnDelay : TIME : T#3S; // 启动超时 END_VAR VAR_OUTPUT bRun : BOOL; // 输出控制 bFault : BOOL; // 故障汇总 eFaultCode : WORD; // 故障码 END_VAR这个接口里bInterlockOk默认给TRUE意味着外部条件不强制时设备可以直接运行工艺联锁越来越多时通过外部逻辑“与”进来就行。超时时间tOnDelay做成整数倍现场微调方便不需要改程序下载。3.3 手动/自动/复位/急停的状态机怎么处理汽车产线程序里最讲究的是“手动/自动”双模式切换还要考虑安全回路。SICAR规范里一般把设备抽象成几个互斥的状态停机中、启动中、运行中、停止中、故障。每个命令只能在特定状态下生效比如“自动启动”只能在“停机中”或者“已准备好”状态才能被接受“复位”只能在“故障”状态清除故障标志。状态机的好处是逻辑清晰不容易出竞争条件。用梯形图写电机控制的时候最怕的就是启保停互相竞争启动按钮和停止按钮同时被按到线圈状态不确定。状态机里这个情况不可能存在因为状态转换表是固定的同一条命令不会在两个状态下产生冲突。这也是为什么汽车标准块普遍用状态机而不用简单自锁电路的原因。安全回路的处理在上面这些对象块之外。急停、安全门、光栅这些信号通常进F-CPU安全PLC或者硬回路标准控制程序通过安全继电器反馈的触点来获取“安全回路就绪”状态。程序里只把这个状态用作联锁条件不允许在普通逻辑中跨过它做任何强制动作。在SICAR项目里安全逻辑和功能逻辑分层是认证审核和客户验收的底线要求。3.4 程序写完之后怎么自检SICAR项目交付前通常有一个“内部自检”环节把程序过一遍。自检的清单一般包括变量命名是否符合AK规范标准FB是否直接复制于库背景DB是否有明确注释报警文本是否和IO点一一对应HMI按钮是否连接到正确的PLC变量。别看这个环节简单很多交付延误就是在这里发现的程序能跑但规范一查一堆问题。我自检的时候还有一个习惯用TIA Portal的“交叉引用”功能搜索每个标准块的实例数量和现场设备清单核对。比如现场有37台电机程序里如果只找到了36个电机块实例那多半是有一台设备的IO点被接错或者漏写了。这种“数量核对式”的自检比挑着看逻辑更高效因为它是在验证完整度而不只是正确性。4. 我在现场踩过的坑SICAR常见问题与排查实录4.1 “半套化”比不标准化更可怕很多项目团队对SICAR的执行是“半套化”变量名前面带了工位号但FB没有用标准库自己写了一套复杂的电机逻辑或者标准块用了但背景DB的命名随心所欲比如DB1、DB2这种。这种半吊子标准化反而让维护更困难。因为你看命名规则要往SICAR上面猜看代码又发现根本不是那么回事两头不对。我处理这种问题只有一个办法从项目一开始就把规范文档作为合同附件写进去。不要觉得这是业务层面的事情技术负责人必须参与约束。只要合同里写明“交付程序需遵循SICAR规范并通过甲方自动化部门检查”团队才会认真对待。现实就是没有验收压力的标准化都是“锦上添花”有验收压力的标准化才是“柴米油盐”。4.2 库版本漂移和“改了一版但没同步”标准库版本管理是一个特别容易翻车的点。供应商的标准库跟工程项目的实际库经常不同步顾问在总部更新了标准FB项目现场还在用旧版。更隐蔽的情况是现场工程师觉得标准块“不好用”偷偷在原位改了库里的FB导致同一个项目里同一个标准块有两种行为。这个问题没有完美的自动化解决方案只能靠流程保障项目里用的所有标准块从库复制到项目后立即锁定禁止在项目内编辑如果确实需要修改必须走变更申请更新库版本并且做回归测试。我自己的经验是在TIA Portal里把标准库放在一个独立的库文件里项目全部引用库副本并在项目信息里记录库版本号。这样就算出问题追根溯源也比一盘散沙强得多。4.3 HMI与PLC变量“失联”的三大原因调试HMI的时候最崩溃的就是画面上的变量突然变成问号或者黄色感叹号。排查下来原因无非三大类。一是PLC里的DB变量被优化了而HMI用的是绝对地址二是连接设置不对HMI的通讯连接里PLC网段变了没更新三是HMI变量引用的PLC变量被删了或者改名了HMI侧没有刷新。这三大问题在SICAR体系里都应该被“规范”规避变量连接统一走符号寻址HMI集成了PLC变量列表之后PLC端的批量修改要重新编译并上载到HMI工程。另外我提一个容易被忽略的坑TIA Portal里很多标准块使用了带“优化块访问”属性的DB。这个功能好是好但它会导致HMI不能使用绝对地址访问DB必须连接符号。所以SICAR里一般建议所有HMI访问的DB统一启用优化块访问并且用符号名禁止用DB绝对地址。这样就算程序结构变了HMI连接也不会莫名其妙断掉。4.4 联锁误动作的排查套路联锁误动作是汽车产线最常见的问题。设备明明已经满足条件了但就是起不来。排查SICAR标准块时要记住联锁条件不是一把抓进FB内部的而是通过背景DB里的UDT管理。排查套路是先看接口区“联锁汇总”位是0还是1再用“交叉引用”找到这个UDT被哪些程序写过逐项排查。有一次一个拧紧工位总是偶发报警最终发现是安全门传感器信号用了常闭逻辑但PLC里因为信号抖动被误判成了门打开。这种问题如果不按“联锁UDT → IO映射 → 硬件信号”的层次排查很容易在程序里迷路。所以SICAR对联锁信号的强约束是有道理的所有联锁来源必须集中定义并注明物理位置不允许散落在程序各处。4.5 与机器人、视觉等第三方设备的接口“打架”焊接和装配工位一定会跟机器人控制器、视觉系统、涂胶机等第三方设备通信。SICAR规范里会约定通信接口区比如定义一组IN/OUT字节每个bit的含义在通信接口文档里写清楚。但现实是机器人厂商和PLC工程师经常因为启动时序问题互相甩锅。我的经验是第三方设备的交互用“心跳握手”模式PLC发出启动命令后机器人必须在一个窗口时间内反馈“启动完成”或者“进行中”否则PLC做超时处理。同时PLC也发送自己的运行状态给机器人两边都能看到对方是否在线。这个做法虽然不是SICAR老库默认的但我做了几个项目之后发现它特别管用后来干脆写成团队内部的补充规范。4.6 通讯报错与批量BOM化带来的隐患热词里那些“PLC通讯模块8180错误”之类的报错很多都不是设备坏了而是网络拓扑和被动参数不一致造成的。用Profinet时设备名和IP必须严格一致但项目里如果同时存在多个网段上电顺序又不一样很容易出现PN设备搜索不到或者报错。SICAR的标准做法是给每台设备命名一个AK号IP地址段按工厂区域规划并且在上电顺序上规定先PLC后分布式IO。这样做之后大部分网络通讯问题其实是可以提前规避的。另一个容易踩的坑是IK标准接口分配不合理。有的项目把所有信号点都通过一个大的数据块跟OEM的工厂标准交互表面上很规范实际上这个块被几千个程序位引用编译时间超长改一个点的注释都可能导致全项目“重编译”。我后来的做法是拆小接口块一个工位一个接口域只上抛关键状态其他的留在本地访问效率反而更高。5. 工具链和生态SICAR怎么和周边系统配合5.1 TIA Portal Openness用代码检查代码规范人眼检查程序规范永远有盲区所以我会用TIA Portal Openness接口写一些小工具批量检查项目里的命名和块属性。Openness是TIA Portal提供的开发接口可以通过C#或者其他.NET语言读写项目结构。写一个控制台程序遍历所有的PLC块检查FB名称前缀、DB名称是否符合SICAR规则把不合规的列出来几十秒钟就能跑完一个上千块的项目。// 用 Openness 遍历项目中所有 PLC 块并检查命名前缀 foreach (var plcGroup in project.Devices) { var software plcGroup.DeviceItems.FirstOrDefault(i i.Name.Contains(PLC)); if (software null) continue; var blocks software.GetAttribute(Blocks) as IEnumerablePlcBlock; foreach (var block in blocks) { if (block.Name.StartsWith(OB_) || block.Name.StartsWith(FC_) || block.Name.StartsWith(FB_) || block.Name.StartsWith(DB_)) continue; Console.WriteLine($不合规块名: {block.Name}); } }这个工具最大的价值不是替代人而是把“检查规范”从几小时的人工抽检变成几分钟的全量扫描而且能在项目交付前反复跑。你可以把它接到CI流程里每天晚上自动打开开发版项目生成不合规清单第二天早会直接对着清单改。长期坚持下来团队对规范的重视程度会高很多因为每个人都觉得有一双“审计之眼”在盯着。5.2 PLCSIM Advanced 与虚拟调试规范校验的捷径PLCSIM Advanced配合Process Simulate做虚拟调试这几年在汽车行业已经很成熟了。基于SICAR项目做虚拟调试有一个额外好处标准块的行为是可预测的虚拟环境里的模型不需要处理各种“特例逻辑”。换句话说因为程序结构规整设备模型和程序逻辑的映射关系简单虚拟调试的建模成本能下降不少。我建议至少在方案阶段跑一次“软硬分离”验证用PLCSIM Advanced跑SICAR程序把机器人、传感器模型接进来验证逻辑时序是否合理。这个阶段最容易发现问题因为改逻辑的成本是0等到了现场再改每一步都要盯安全门、盯IO点、盯机械配合效率不可同日而语。5.3 与Eplan、Teamcenter的数据协同SICAR项目不是孤岛它要和Eplan电气图纸、Teamcenter工艺数据、MES生产数据协同。最理想的状态是Eplan里的设备编号、IO点位和PLC程序里的变量名一一对应这样从图纸到程序到HMI的链路是通的。很多自动化工程师觉得这不是自己的工作但实际上如果不参与后面调试多半会出“图纸IO和程序对不上”的情况。TIA Portal本身有导入/导出功能配合Openness可以做一个从Eplan部件库到PLC标签表的自动映射工具。这样做完之后BOM里的电机编号在程序里就肯定存在不会出现“图纸有但程序没有”这种事。Teamcenter那边主要是通过标准接口把工艺参数下发到PLC配方区。SICAR因为数据区规划得好配方结构清晰对接成本就低很多。5.4 规范在团队里的落地与沉淀再好的规范团队不用就是废纸。我见过最成功的做法是把SICAR转成团队内部的三层文档第一层是指导原则一句话说清楚每个规范为什么要这么定第二层是操作手册写清楚举例子和截图告诉新人怎么建项目、怎么添加FB、怎么填参数第三层是惩罚机制不叫惩罚叫“合规积分”代码评审里不合规的地方会被记录到项目总结里。这样一代一代沉淀下去标准库会越来越厚踩过的坑也越来越少。还有一点很关键团队的新人培训不要用官方PPT要用真实项目的代码走查印象最深。挑一段不符合SICAR规范的老代码让新人根据规范文档找出问题并重构这个过程要比讲一百页课件有效得多。6. 标准化的收益到底怎么衡量6.1 从“调试时间”和“故障率”两个维度算标准化的收益最直观的是看调试时间。非标项目里各写各的一个20个电机工位可能需要一周调试SICAR项目因为标准块和IO映射都很明确可能三天就搞定了。第二个维度是故障率标准化之后程序逻辑经过多个项目验证逻辑缺陷数量会明显下降现场的“疑难杂症”大部分都变成硬件故障或者机械干涉而不是程序bug。我自己统计过使用SICAR风格做项目的团队在相似复杂度的产线上PLC问题导致的停机时间平均能降低30%左右。当然这个数字跟团队成熟度强相关但它说明了一个方向标准化做得好至少不会让它变差。6.2 合规度评估怎么判断一个项目“够不够SICAR”判断一个项目合规不能光看运行正常。我会看四个维度命名覆盖率有多少PLC变量符合AK规则、块复用率有多少控制逻辑是标准FB实例而不是重复代码、报警文本完整率每个IO故障点是否有对应报警、文档更新度IO清单、接口协议、版本记录是否更新。这四个维度用Openness脚本都能量化。比如可以生成一份报告命名覆盖率95%、块复用率80%、报警完整率100%、文档更新度90%然后根据这个报告决定是否签发验收证书。这样就把“合规”从感觉变成了数字客户也容易接受团队自己也知道差距在哪。6.3 推行标准化最容易忽略的一件事推行标准化容易忽略的是“变更管理”。现场的调试人员经常有个习惯程序先跑起来再说规范后面补。但在SICAR体系下一次不合规的临时修改如果在调试高压期蔓延后面就会变成“谁也不知道程序里到底哪些地方是标准的、哪些是临时的”。我在团队里定了一条规矩现场临时改动必须在程序注解中写明“临时”两个字并在当天的调试日志里登记项目结束前必须由负责人逐条确认要么固化到标准库要么恢复原样不允许带着“临时修改”交付。这条规矩看起来简单但它保证了标准库在项目之后不会被“悄悄污染”下一个项目能站在上一个项目干净的代码基础上。说回开头那句话SICAR就是标准化开发的基石。基石这个东西你在上面走的时候感觉不到它的重量但没有它整栋楼就会晃。我做了这么多年自动化标准化的核心价值不是让人变蠢而是让人把精力放在真正需要创造力的地方——工艺优化、异常处理、新功能预研。如果每个设备都要重新造轮子你哪来的时间思考更高层的东西呢。