简介：《Citect2018培训手册》是面向工业自动化领域初学者的SCADA系统入门资料，系统讲解施耐德电气CitectScada2018的完整使用流程。内容从安装前的软硬件环境准备，到Citect Studio开发环境中的功能菜单与工程菜单，再到新建工程、工程组网、PLC通讯设置、变量标签定义、画面与精灵制作、报警与趋势配置，直至工程部署，覆盖了从零开始构建SCADA系统的主要环节，适合电力、水处理、矿业等行业从事监控系统开发与维护的技术人员参考。

资源包为单个docx文档，大小约11.18MB，目录层级清晰，便于按章节索引查阅。该手册已在CSDN获得928人学习，实用性得到一定认可。通过学习，读者可以掌握Citect2018的安装配置步骤、理解工程组织与网络架构设计思路、学会配置PLC通讯与I/O点、借助变量标签实现实时数据可视化，并利用报警与趋势功能完成生产过程的监控分析和故障诊断，为后续独立开展自动化监控项目打下基础。

1. 从《Citect2018培训手册》这份docx说起：SCADA 2018并不难，难的是工程思维

《Citect2018培训手册》这份docx，是我见过不少自动化工程师入坑CitectSCADA2018时都会先找的资料。刚接触这套软件的人普遍有同感：看手册觉得功能都认识了，真打开工程界面还是不知道先点哪里。Citect的工程管理方式和常见组态软件差别很大，它把工程、服务器角色、编译运行拆得很细，培训手册能帮你扫盲，但要真正把一套监控画面上线，还需要有人把“工程怎么搭、通讯怎么配、脚本怎么写、出问题往哪查”这条线串起来。这篇文章就把这份手册的实用内容拆成一条上手路线，适合准备做SCADA项目的电气工程师、负责老系统维护的运维人员，以及刚从PLC转过来做上位机的新手。

2. 先看懂2018的工程结构：配置文件、集群角色与编译产物一次理清

Citect SCADA 2018和其它组态软件最大的不同，是它一开始就要求你按“服务器-客户端”的分布式架构去思考。哪怕是单机演示工程，也绕不开集群、IO服务器、报警服务器这些概念。不先把工程树看懂，后面配IO设备、写Cicode脚本都会觉得别扭。

2.1 Citect Studio与Citect Explorer：同一套工程的“开发台”和“驾驶室”

2018版把开发工具整合进了Citect Studio，新建画面、配置标签、编辑Cicode脚本、编译工程都在这里完成。Citect Explorer则负责运行时的启动、停止、热部署和客户端分发。新手常见的误区是只在Studio里面折腾，却不知道Explorer才是控制和启动运行环境的地方。

我一般在现场拿到一台工控机，会先确认两个东西：Studio里打开的工程路径和Explorer里指向的运行工程路径是不是同一个。很多莫名其妙的“我改了画面为什么不生效”，就是因为Studio编译的是A目录下的工程，而Explorer启动时加载的是B目录的旧版本。这个习惯从第一天就养成，能省掉后面大量排查时间。

开发环境里点“编译”按钮，Citect会把全部配置和画面脚本编译成运行时文件，然后由Explorer把运行时下发到IO服务器和操作员站。理解这个“编辑-编译-运行”三步流程，是上手Citect的第一步。

2.2 集群、计算机角色与工程树：单机也按分布式搭

Citect的工程树从上到下大致是：集群（Cluster）→ 计算机（Computer）→ IO设备（IO Device）→ 标签（Tag）。集群是把若干台计算机组织成一组服务资源，每台计算机承担不同角色，比如IO Server负责和PLC通讯，Alarm Server负责报警处理，Trend Server负责历史数据存储。

很多初学者看到集群就头大，觉得单机项目没必要。我的建议是：单机训练时也按标准角色建。工程建好后默认会有一个Cluster和一个Computer，你只需要把IO Server、Alarm Server、Trend Server这些角色挂到该Computer上即可。这样以后要扩成真正的多客户端结构，不需要推翻工程重来。

配置方法并不复杂：在Studio的工程树里找到Computer节点，右键查看属性，把“IO Server”“Alarm Server”“Trend Server”等角色设为启用。需要注意，角色一旦启用，运行时就会对应拉起独立进程，工控机上会看到多个Citect相关进程，这是正常的。

2.3 标签是工程的血液：先搞懂DIGITAL、ANALOG与地址映射

标签就是Citect里的变量，也是IO设备和画面之间的桥。标签类型最常用的有三种：数字量标签（DIGITAL）、模拟量标签（ANALOG）和字符串标签（STRING）。数字量处理开关、运行状态这类布尔量；模拟量处理温度、压力、液位这类工程量；字符串一般用来存操作员姓名、批次号等文本信息。

标签定义里最核心的两个字段是“IO设备”和“地址”。IO设备指定数据从哪套PLC来，地址指定读PLC里的哪个寄存器。地址写法有讲究，常见格式是“@设备名:寄存器编号”，例如“@PLC1:40001”表示读取PLC1的保持寄存器40001。这里注意不同驱动的地址偏移规则不一样，Modbus协议下40001对应地址0，写错一个偏移量读上来的数据就会南辕北辙。

我习惯把标签命名全部用英文字母加数字，比如“LT101_LEVEL”“PA101_STATUS”。原因后面会提到，中文标签在报表和脚本里踩坑的概率太高了，能不用就不用。

2.4 编译产物与备份：手动备份胜过一切自动恢复

Citect工程编译后会生成运行时数据库和中间文件，这些文件的扩展名各有分工，但普通维护人员不需要背。你要记住的是：整个工程目录才是宝贝。Citect的工程目录一般包含主工程文件（.CIT后缀）、编译中间目录、画面文件目录和Cicode脚本文件。

我参与过的几个项目都有统一的备份习惯：每周五下班前把整个工程目录压缩一次，命名带日期，保留最近三份。听起来原始，但比依赖软件的自动备份可靠得多。遇到过一两次数据库文件损坏的情况，最后都是靠这种土办法把工程拉回来的。Citect的工程文件本质上是文本加二进制的混合体，用文本编辑器打开主工程文件能看见很多配置段，但别手改，乱改一个字符都可能让整个工程编译不过。

3. 通讯配置与IO设备：把PLC数据送进画面之前，先选对驱动和参数

通讯配置是Citect SCADA项目里最容易出乱子的环节。培训手册通常会把IO设备的配置界面列一遍，但实际项目中“为什么连不上PLC”“为什么数据刷新慢”“为什么某一台设备掉线影响整个画面”这些问题，都要靠对通讯机制的理解。

3.1 IO Server与驱动选型：Modbus TCP和OPC UA怎么选

IO Server是Citect里负责和外部设备通讯的进程，每个IO设备都挂在某个IO Server下面。Citect 2018支持的驱动很广，常见的有Modbus TCP、Modbus RTU、OPC DA、OPC UA，以及一些主流PLC的专用驱动。

选型上没有绝对标准，我一般按这样的优先级判断：新项目、新设备，优先OPC UA，因为跨平台、跨网段、安全性都比老协议好，而且不需要额外装DCOM配置；老设备、存量PLC，优先Modbus TCP或该PLC的专用驱动，改动最小；偶尔有串口设备，走Modbus RTU，需要额外注意串口参数。

Modbus TCP和OPC UA还有一个差别要心里有数：Modbus TCP下你需要自己管理从站地址和寄存器区间，OPC UA则通常由服务器端把节点树整理好，Citect这边只需要填入节点ID。OPC UA在调试初期更省心，但前提是现场有懂OPC UA配置的同事或供应商配合。

3.2 配置IO设备的参数清单：超时、重试与轮询周期

在Studio工程树里添加IO设备时，界面上的参数不少，但真正影响通讯健壮性的就几个。我习惯先把IO设备的通讯参数表格做出来再填，不直接上手乱配。

IO设备通讯参数参考表：

超时时间这个参数最容易被人忽略。设成200ms看起来反应快，实际上PLC稍微忙一点就判定超时，通讯状态反复跳。我一般先设3000ms跑一天，看误报率再往下调。轮询周期的设置要区分场合——联锁、急停这类信号越快越好，温度、液位这种缓慢变化的量，设2秒甚至5秒完全没问题。

3.3 地址映射与工程量换算：原始值和工程单位差着一条公式

Citect的模拟量标签读上来的是原始值，比如PLC里存储的0到65535对应实际的0到100摄氏度，画面上显示不能拿原始值直接摆上去。标签配置界面里有“原始量程下限、原始量程上限、工程量下限、工程量上限”四个字段，填好后Citect自动完成线性换算。

这套换算机制用熟了很方便，但坑也在这。常见问题是上位机显示满量程，但现场仪表读数正常，十有八九是量程上限填错了。我遇到过一个案例：某液位传感器4-20mA对应0-10米，PLC内部量程是0-4000，结果工程量下限填成0，上限填成40000，液位直接显示爆表。

排查这种问题有个快速办法：在IO设备属性里打开在线诊断，看标签的“原始值”是多少。如果原始值在预期范围内，问题一定出在换算配置上。如果原始值本身就不对，那就回头查通讯和地址映射。

3.4 通讯故障排查顺序：别在标签定义里反复折腾

IO设备联不上时，很多人第一反应是删了标签重新建，这其实是浪费时间。正确的排查顺序应该是：先确认物理链路（网线、交换机、IP能否ping通），再确认PLC侧通讯设置（从站号、寄存器区是否开放），然后看IO Server进程是否启动，最后才轮到检查Citect里的IO设备和标签配置。

Citect有一套运行时的IO诊断工具，能看到每个设备当前的通讯状态、累计超时次数、最近错误码。错误码的含义在手册里有对照表，现场排查时直接查错误码比猜原因快太多了。维护记录里我见过的超时问题，有三分之一是交换机端口接触不良，别一上来就怀疑软件配置。

4. 画面、报警、趋势与Cicode脚本：把操作员真正需要的交互做出来

通讯通了，标签有值了，接下来才是操作员看得到摸得着的东西：监控画面。培训手册里这部分内容往往比较分散，但核心就三件事：画面怎么做、报警怎么报、趋势怎么看。再加上脚本把逻辑串起来，一套SCADA系统就算立住了。

4.1 Graphics Builder画面编辑器：控件绑定标签的两种方式

Citect 2018的画面开发在Studio内置的图形编辑器里完成，绘制矩形、管道、阀门、仪表盘这些图元都不难，关键是让图形动起来。选中一个图形对象，在属性面板里找到“动画”相关设置，把它的显示状态、填充颜色、位置移动、数值显示绑定到某个标签上，运行时图形就会跟着标签值变化。

我的习惯是数值显示单独放一个“文本控件”，关联标签后选择显示格式，比如小数位数、单位后缀。不要在图形编辑器的默认标签显示里将就，那种显示格式不好控制。图形颜色变化用“填充颜色”的动画表达式，例如某台泵运行时变绿、停止时变灰，表达式判断标签值即可。

还有一种更高级的复用方式叫超级标签（Super Tag），本质上是一个带参数的面板模板。做一台泵的面板，把泵号、转速、电流做成参数，然后实例化给十台不同的泵用。这个功能培训手册里通常有介绍，实际项目里维护起来特别省事，改一次模板所有实例跟着更新。

4.2 报警配置：触发值、死区和确认策略缺一不可

Citect报警的核心配置包括报警变量、报警类别、报警显示和报警确认。报警变量就在标签配置里勾选“启用报警”，然后填报警触发条件。模拟量标签可以同时配多个报警级别，比如高高报、高报、低报、低低报，每个级别独立设置触发值和恢复值。

死区（回差）是新手最容易漏的参数。假设某温度高报触发值80度，没有死区的话，温度在79.9和80.1之间波动，报警会反复触发和恢复，操作员能疯掉。正确的做法是设一个回差，比如触发80度、恢复75度，这样报警一旦触发，至少要降到75度以下才会恢复，消除抖动。

报警类别决定报警的优先级和显示方式。我一般把报警分成“设备故障”“工艺越限”“联锁动作”三个类别，分别对应不同顏色和声音。报警确认机制必须培训操作员，Citect支持单个确认和批量确认，但批量确认容易漏掉关键信息，有些项目干脆只开放单条确认。报警记录默认保存在Alarm Server的历史库里，界面上加一个报警历史控件，就能按时间段查询和导出。

4.3 历史趋势：趋势服务器、采集周期与存储策略

趋势功能由Trend Server服务器角色负责。要记录某个标签的历史曲线，需要在标签配置里勾选“趋势记录”，并设置采集周期。比如工艺参数每秒记录一次，能耗数据每五分钟记录一次，没必要所有标签都高频采集。

历史存储占用的磁盘空间要提前估算。每秒记录一条模拟量，单标签一天就接近86400条记录，几十个标签连续跑一个月，硬盘会告急。我见过客户把全厂上千个点都设为每秒记录，结果趋势服务器一个月就满了，历史数据全被冲掉。合理做法是：联锁和关键质量参数高频记录，一般监视参数延长采集周期，归档数据单独做慢周期存储。

画面上的趋势控件提供时间轴、曲线笔、缩放这些基本操作，培训手册里都有，但有一个实用技巧值得掌握：给趋势控件加上“预设时间段”按钮，例如“最近1小时”“最近24小时”“本周”，操作员点一下就能切换时间范围，比手动拖时间轴直观得多。

4.4 Cicode脚本：三种触发方式与一段可直接套用的模板

Cicode是Citect的脚本语言，语法接近C和Basic的结合体。写Cicode不是程序员的专利，电气工程师只要理解“什么时候触发、要做什么事”就能上手。触发方式主要有三种：画面事件触发（比如画面打开时执行初始化）、按钮命令触发（操作员点击后执行动作）、后台循环触发（周期性的逻辑判断）。

下面是一段很常用的Cicode模板：高位联锁启泵。逻辑是液位超过80%时启动一台泵，低于50%时停止。

FUNCTION INT nLevel; nLevel = TagRead("LT101_LEVEL"); IF nLevel > 8000 THEN TagWrite("PA101_RUN", 1); ELSE IF nLevel < 5000 THEN TagWrite("PA101_RUN", 0); END END

代码先通过TagRead函数读取液位标签LT101_LEVEL的值。这里8000和5000是工程量换算后的数值，对应80%和50%。然后判断条件，通过TagWrite函数把启泵命令写入PA101_RUN标签。需要注意TagWrite写入的通常是PLC里的命令寄存器，PLC侧程序再根据这个命令字去控制接触器。

在实际项目里，这种联锁逻辑我更倾向于放在PLC里做，Citect脚本只做画面联锁和操作提示。原因很简单：上位机重启、通讯中断的时候，脚本是没办法保证安全性的。PLC是最后的安全底线，上位机脚本负责锦上添花。

5. 避坑与排查：编译通过不等于能上线，五条血泪经验

这一章是给已经动手建过工程、被各种问题折磨过的人看的。Citect 2018项目从开发到上线，我踩过的坑比看过的文档还多，把最常见的几条写出来，希望你不用再走一遍。

5.1 现象：编译0错误0警告，但运行画面还是旧内容

这是最典型的一个坑。Studio编译了一遍又一遍，Explorer里启动的还是上一版画面。

原因：Studio编译后的运行文件没有正确分发到Explorer指定的运行目录，或者Explorer还在跑旧进程，新文件没有被加载。

解决：先看Explorer的工程路径是否和Studio一致，然后确认IO Server、Alarm Server这些进程已完全退出再重新启动，而不是只关画面。生产环境下先做一次“停止运行时”操作，再启动。从那以后我每次改完画面，都会在Explorer里先停后启，而不是点“重启画面”按钮糊弄过去。

5.2 现象：IO设备通讯状态正常，但个别标签读数始终为0

现象有点玄学：同一台设备下的大部分标签都有数据，就那一两个标签永远显示0。

原因：标签的地址映射和PLC侧变量表对不上，或者该寄存器区间没有被PLC程序刷新。还有一种可能是标签类型选错，把模拟量地址配成了数字量标签。

解决：先用IO诊断工具看标签原始值。如果原始值也是0，去PLC侧监控对应寄存器，看PLC程序是否写了这个地址。如果PLC侧一直保持0而设备实际有输出，问题就在PLC程序，而不是Citect。别在上位机里反复折腾，那是浪费时间。

5.3 现象：中文标签名能显示，但报表导出和脚本比较时总出问题

中文显示没有问题，但一到报表、Cicode脚本字符串比较、数据库写入时就出乱码或者匹配失败。

原因：Citect的多语言资源和标签命名混在一起了。标签名用中文，在不同代码页切换时字符串比较就会出错，数据库写入也可能因为字符编码不一致而乱码。

解决：标签名严格使用英文字母、数字和下划线，所有界面上的中文用多语言资源文件或单独的显示文本标签实现。这个规则我从第二个项目开始严格执行，之后再没在报表环节翻过车。

5.4 现象：热部署后新画面只在一部分操作员站生效

热部署改了画面，有些客户端始终是旧界面。

原因：客户端没有重新连接服务器，或者客户端的本地缓存还保留旧画面文件。Citect的客户端机制在某些配置下会缓存画面资源，热部署不会强制刷新所有节点。

解决：客户端全部退出后重新登录一次，或者部署完成后在服务器端执行一次“全部客户端强制刷新”。现场人多的时候提前广播通知，避免操作员中途重启导致操作中断。

5.5 现象：32位运行库缺失，工控机上运行时报错

Citect 2018本身依赖一些系统运行库，重装系统或迁移到新工控机后，只拷贝工程文件过去是不行的。

原因：安装包里的运行库没有被正确安装，尤其是Visual C++运行库和某些网络组件。

解决：在一台干净的机器上完整安装一次Citect，做一次“安装包修复”，再把工程文件恢复进去。不要图省事只拷工程目录，运行时环境也必须一起准备。我经历过现场换工控机，以为把工程拉过去就能跑，结果折腾了半天，最后老老实实重新装了运行环境才恢复正常。

6. 一套半小时完成的仿真验证流程：用模拟器把整套工程从通讯到趋势全部跑通

最后一章不聊理论，分享一个我每次做Citect 2018项目前都会跑的验证流程。用Modbus模拟器代替真实PLC，在电脑上把通讯、画面、报警、趋势、脚本全部验证一遍，半小时收工。这个方法适合新工程上线前、旧工程大改后，以及培训学员练手。

先准备一个Modbus TCP模拟器，市场上很多免费工具都能用。启动一个从站，监听端口502，往寄存器区里填充一组可手动修改的数值。然后在Citect工程里新建IO设备，协议选Modbus TCP，IP地址填127.0.0.1，端口502，设备地址和模拟器从站号保持一致。

标签配置按前面提到的方式建几个典型的：一个模拟量测点对应一个寄存器，再建两个数字量标签对应线圈区。画面上放一个仪表盘控件、一个趋势控件、一个报警列表控件，把标签都关联好。编译运行后，模拟器里改数值，画面上的仪表指针应该跟着动；把数值改到报警触发值以上，报警列表应弹出未确认报警；打开趋势控件，确认曲线有历史数据。

Cicode脚本的验证要更刻意一些：故意把工程量换算量程填反，让画面显示和模拟器原始值差异明显，确认画面上的换算公式毫无问题后再改回来。这样做过的工程上线后，变量单位换算错误的概率基本为零。从那以后我每次给Citect工程做改动，都强制把模拟器跑一遍，把报警、趋势、联锁逻辑逐项打勾，确认无误后才敢拿到现场去部署。这套流程看起来原始，却是最值钱的实践经验，希望能帮你少走几段弯路。

本文还有配套的精品资源，点击获取