AF框架与SICAR标准有什么区别？

STANDARD · 工控选型★★★★★乐高散件，还是官方套装AF 与 SICAR 的底层基因差异
同样是西门子、同样基于博途、同样遵循 ISA-88，两套体系却走向了完全不同的路：一个替非标工程师省掉重复劳动，一个替整车厂把几十家供应商拧成一股绳。#产线标准#架构逻辑#国产替代NO.001选型指南GRADES
✂
VALID FOR ONE READADMIT ONE

做自动化项目的人，基本上都会遇到这样一种困扰：同样是西门子基于博途、按照 ISA-88 标准设计的系统，有人认为 AF 好用，也有人认为 SICAR 才是正宗。做单机设备的工程师觉得 SICAR 没做到极致，做汽车生产线的又觉得 AF 撑不起整条产线。

人们通常以为两者的区别只在功能上，其实并不是这样。一个是为非标工程师设计的效率工具箱，另一个是针对整车厂制定的产线规则手册。从诞生的那一刻起，它们的底层数字基因就已经不一样了。

理解了这层区别，也就理解了单机设备与整线自动化之间的底层逻辑关系。

01起源的分野 一个为效率，一个为协作

要知道两个体系有什么不同，先要看它们各自是在什么土壤里长出来的。

AF：非标行业的「去重复劳动」工具

自动化框架，本质上是西门子为离散非标行业客户准备的一套通用积木库。

以前做非标设备，每个项目都要从底层重新搭一遍：气缸逻辑、电机控制、报警管理、状态机、HMI 面板……功能大体相同，代码却每个项目重写一次，大量时间浪费在重复造轮子上。

AF 的出现就是为了解决这件事。它把设备通用的底层功能全部封装成标准库：手动／自动／故障状态机、阀岛控制、伺服轴控、ProDiag 诊断、WinCC Unified 面板模板，开箱即用。工程师不必再写底层逻辑，只需专心填工艺代码。

它的目的很直接——提高单机项目的开发速度，让代码更规范，新人入职也更容易上手。开源免费、轻量化、可裁剪，对中小集成商非常友好；包装、木工、光伏、锂电单机，拿来就能用。

SICAR：汽车行业逼出来的「统一语言」

SICAR 的出现完全是另一种逻辑。

早期汽车整车厂的生产线上，十几家设备供应商同时供货，各家程序风格差异巨大：变量命名不同、操作模式不同、报警逻辑不同、MES 对接接口也不同。一条焊装线跑起来之后，运维人员要适应十几种编程风格，故障排查效率极低，后期改造更像一场噩梦。

于是主机厂提出要求：所有供应商必须遵守同一套程序标准。SICAR 就是在整车项目的土壤里孕育出来的。

它不只是一个功能库，而是一整套产线级交付规范：程序结构怎么搭、功能块接口怎么定义、变量怎么命名、HMI 画面怎么布局、报警怎么分级、MES 怎么对接，甚至连文档怎么写、验收怎么过，全部定死。

它的核心诉求是「统一」：让几十家供应商做出的设备程序逻辑一致、操作习惯一致、运维方式一致。本质上，它是甲方用来约束乙方的管理手段，而不只是技术手段。

一句话区分： AF 面向工程师个人，解决重复开发；SICAR 面向整条产线，解决多供应商协作。起因不同，本就不在同一个维度上。

02架构逻辑 灵活与统一天生反义

架构设计上的差异，是两者基因分化的直接原因。

AF：轻量模块化，以灵活为先

AF 的核心是 Unit 单元——一台设备、一个工位，就是一个独立单元。

每个单元自带完整状态机：空闲、初始化、运行、故障、停机，形成闭环。单元之间耦合度很低，可以独立调试、仿真和裁剪，也不需要强制遵守繁复的命名规则与接口约束。

这套设计天生是为单机非标设备准备的：项目周期短、需求变化快，工程师可以按需删减模块，不必被庞大的框架绑住。入门门槛也低，有一定基础的工程师一周左右就能上手。

代价同样明显：没有整线级的一体化标准。如果一条产线由多个供应商用 AF 开发，最后大概率是各家各写各的——底层功能模块统一了，程序风格、接口定义、操作逻辑仍然千差万别。

SICAR：双层架构，统一优先

SICAR 采用 ModeArea 模式区域 加 TecUnit 工艺单元 的双层结构。

上层是模式区域，负责整线／工位的操作模式：自动、手动、维护、调试、安全模式。所有工位必须遵守同一套模式切换规则，以保证全线操作逻辑一致。下层是工艺单元，即具体的工艺设备，负责完成相应动作。

顺控统一用 S7-Graph 开发，诊断统一用标准面板，机器人、输送线、安全系统都配有标准接口，连 MES 对接的报文格式也是事先规定的。

代价是框架重、约束多、学习周期长，核心模块不能随意删改。只做一台独立单机却上 SICAR，属于典型的大炮打蚊子。

但到了多工位协同的产线项目里，这套设计的价值就显现出来：十几家供应商提供的工位，模式切换逻辑一致、报警格式一致、数据接口一致，操作工换到任何一个工位都能上手，运维人员处理任何一台设备的问题都能驾轻就熟。

AF 是乐高散件包，想怎么拼就怎么拼；SICAR 是指定的官方套装，步骤、成品、零件规格全部定死。

所有人都按同一张图纸施工，最后拼出来的东西才一模一样。灵活与统一无法兼得，选哪一个不取决于谁更高级，而取决于你的场景需要什么。

03真正的鸿沟 库之外的整套生态

很多人学 SICAR，以为就是学一个功能块库——这是最大的误区。两者的真正差别不在库里有多少功能，而在库之外的整套生态。

AF 的交付物很单纯：库文件、帮助文档、演示项目。拿到就能用。至于怎么命名、怎么排版、怎么与上层系统对接、怎么做项目审核，全由你自己决定。它解决的是「底层功能不必重复编写」，解决不了「多人协作如何保持一致」。

SICAR 体系之外还有更多东西：

01规范体系 ：变量命名规则、FB 接口标准、报警文本规范、HMI 布局要求，没有一点遗漏。02工具体系 ：配有 SiVarc 自动生成画面、Openness 批量生成程序等工具，大幅提高整线项目的交付速度。03审核体系 ：有完整的程序检查清单与验收标准，甲方可以逐条核验，确保交付质量。04培训体系 ：从初级到高级的一整套培训材料，工程师的能力也能被标准化地培养。

简单说，AF 给你的是「零件」，SICAR 给你的则是「零件＋图纸＋施工规范＋验收标准＋人员培训」的全套方案。

所以汽车主机厂只认 SICAR 这套体系：他们要的是一条能把几十家供应商拧成一股绳的产线标准。

很多国产厂商做标准时，一开始总想着把功能块做全、做漂亮，却忽略了规范、工具、审核、培训这些「软」的部分。而代码之外的东西，才是这套标准真正的护城河。

关键差异： AF 交付的是零件，SICAR 交付的是整套交付体系——护城河在代码之外。

04延伸 国产标准走向何方

说到这儿，就不能不提国产替代。

目前国内很多 PLC 厂家都推出了自己的行业标准模板，例如汇川的 InoCar 汽车解决方案。从对标方向看，它们走的是 SICAR 这条路，不是 AF。

原因很简单：汽车行业最根本的需求不是单机开发效率，而是整线的标准化、一致性与可维护性。主机厂需要的是一套能约束所有集成商的标准，而不是一套让某个工程师写代码更快的工具包。

但差距也不能忽视：目前国内不少行业标准还停留在「功能块库」阶段——把常用逻辑封装好给用户使用。命名规范、接口定义、审核体系、工具体系、生态配套，还没有达到 SICAR、VASS 的程度。

从「做一款好用的库」到「建立一套被整个行业接受的标准体系」，中间差的不仅是技术，还有行业共识、项目积累与生态磨砺。国产替代的下半场，硬件性能的差异会越来越小，真正决定胜负的是标准体系。

判断一条标准成不成熟： 看它有没有规范、工具、审核、培训这四件套，而不只是看功能块有多少。

05工程师怎么选 别陷入框架崇拜

回到最实际的问题：做项目到底该选哪一个？答案不是「哪个更先进」，而是「你的场景是什么」。

如果你做的是单机非标设备，或中小型独立项目，且客户没有强制标准要求，优先选 AF。轻量、上手快、灵活，能切实提高开发效率，也不必为用不到的功能付费。

如果要对接汽车主机厂，或者做整线项目，或者与多家供应商联合开发，且客户对统一规范有明确要求，那就不用纠结——按甲方要求用 SICAR（或对应的车企 VASS 等标准）。它限制的是自由度，规范的是生产力。

比选型更重要的，是跳出框架本身看问题。

很多工程师沉迷于学各种框架、调各种功能块，却很少思考：这些框架为什么这样设计？它解决了什么问题？背后的设计理念是什么？

只会调用功能块，你只是框架的使用者；能理解架构逻辑、能按场景设计标准体系，你才是规则的制定者。

前面说过：做了十年 PLC 才知道，最有价值的能力不是编程，而是搞架构、定标准、解决系统级难题。

选型口诀： 单机非标用 AF，整线协同用 SICAR；先定场景，再定框架。

06最后 没有高下，只有场景

AF 和 SICAR 没有高下之分，只有场景的不同。

标准化的本质，从来不是用了哪个高级框架，而是用体系化的手段来降低协作成本、提高工程质量。

理解了这层底层逻辑之后，用什么工具，都是随手拿来的东西罢了。

最后一句： 工具只是结果，场景才是原因。

#AF#SICAR#ISA-88#产线标准#国产替代