企业官网建设流程全解析

做汽车行业的自动化项目这些年，我越来越觉得，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 White），AK3叫“ST10”（工位10），AK4叫“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 IEnumerable<PlcBlock>; 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就是标准化开发的基石。基石这个东西，你在上面走的时候感觉不到它的重量，但没有它，整栋楼就会晃。我做了这么多年自动化，标准化的核心价值不是让人变蠢，而是让人把精力放在真正需要创造力的地方——工艺优化、异常处理、新功能预研。如果每个设备都要重新造轮子，你哪来的时间思考更高层的东西呢。