简介：这份资源是施耐德电气 Vijeo Citect 6.1 版本的 SCADA 上位机软件安装包，面向工业自动化领域的工程师、系统集成人员及自动化相关专业学习者，用于构建操作员站画面、对接 PLC 设备并完成生产过程的实时监控与控制。压缩包共 311 个文件，约 483MB，以 exe、msi 安装程序与 dll 运行库为主体，辅以 cab 压缩组件、ini 配置文件、mst 安装脚本，并附带 25 份 pdf 手册、chm 帮助文档及 bmp 图形素材，覆盖安装部署与查阅学习两类需求。目前已有 579 人学习下载。软件涵盖图形化界面设计、实时数据监控、报警与事件管理、SQL Server 数据库集成、内置脚本扩展、多用户权限与网络安全、工程备份与版本迁移等模块，配合随包手册可帮助读者理解 SCADA 项目的组态流程与工程组织方式，适合作为施耐德自动化项目的配套工具与学习环境。
1. 老工控人硬盘里那个 Vijeo Citect6.1.zip，到底还能不能打
翻出一份 Vijeo Citect6.1.zip，多半是某次项目交接、旧机备份或者同行顺手拷过来的。它属于施耐德上位机软件体系里偏经典的一支，核心定位是 SCADA 组态与监控：把 PLC、仪表、变频器这些现场设备的数据采上来，做画面、报警、趋势、报表，再往下发给操作员。这套东西在电力、水处理、制造产线的老项目里存量很大，很多现场还在跑，维护、改造、迁移都绕不开它。这份资源适合两类人：一是接手了老 Citect 工程、需要读懂并改动的运维和自控工程师；二是想系统摸清经典 SCADA 组态逻辑、拿它当练手环境的学习者。它不是新潮的 Web 组态，界面和工程组织方式都带着年代感，但正因为存量项目多，能把它跑起来、把工程结构讲清楚，本身就是一项实用技能。下面按“先立住概念、再动手复现、最后说坑”的顺序拆。
2. 先把工程模型立住：Citect 的层级与变量体系
很多人拿到压缩包第一反应是找安装程序双击，结果装完打开一片空白，不知道从哪下手。问题不在软件，在于没先理解它的工程模型。Citect 的组织方式和一般组态软件不太一样，它把“设备怎么连、数据怎么采、画面怎么画、报警怎么报”拆成几个相对独立的配置层，层与层之间靠变量名和标签串起来。先把这套模型在脑子里立住，后面每一步配置才知道自己在改哪一层。
2.1 从设备到画面：四层结构怎么对应现场
Citect 的工程大致可以按四层理解。最底层是 I/O 设备层，对应现场的真实硬件，配置里叫 I/O Device，要指定通信协议（比如 Modbus、OPC、专有驱动）、站地址、端口这些连接参数。往上一层是标签/变量层，也就是 Variable 和 Tag，把设备里的寄存器地址映射成一个有业务含义的名字，比如把 40001 映射成“一号泵运行状态”。再往上是画面与逻辑层，Graphics 页面负责可视化，用 Genie（图符）和动画连接把变量绑到图形元素上；命令语言（Cicode）负责逻辑，处理按钮动作、联锁、计算。最上面是报警与趋势层，Alarm 定义报警条件和级别，Trend 负责历史数据记录与曲线展示。
这四层的依赖关系是单向的：画面引用标签，标签引用设备，设备引用物理连接。所以排错时永远从下往上查——画面不动，先看标签值有没有刷新；标签不刷新，先看设备通信状态；设备连不上，才去查协议和地址。反过来从上往下猜，十有八九在画面层瞎折腾半天，其实底层设备根本没通。我见过不少新手一上来就调动画连接，最后发现是 I/O Device 的站号填错了，血泪经验。
2.2 变量命名与标签规范：后期维护的后悔药
工程小的时候变量随便起名无所谓，一旦点位上百，命名混乱就是灾难。Citect 里变量名是全局的，画面、报警、Cicode 都靠它引用，改一个名字可能牵动几十处。常见做法是按“区域_设备_测点_类型”的规则命名，比如AREA1_P01_RUN表示一区一号泵运行状态，AREA1_P01_SP表示设定值。这样在变量浏览器里按前缀一筛，同设备的点全出来，批量改、批量绑都快。
标签（Tag）和变量（Variable）的区别也要分清：Variable 偏底层，直接对应设备地址和数据类型；Tag 偏业务，可以带工程单位、量程转换、报警限值。简单项目里两者可以合并用，但点位一多，建议把量程换算和报警阈值放在 Tag 层，Variable 只做原始数据搬运。这样现场换仪表、改量程时只动 Tag，不用碰设备映射。下面是一个变量定义在工程配置里的典型字段示意，实际界面是表格填写，这里用结构化形式说明各字段含义：
Variable 定义字段示例（工程配置表） Name : AREA1_P01_RUN # 全局唯一变量名，供画面与逻辑引用 I/O Device : PLC_AREA1 # 关联的 I/O 设备名 Address : 40001 # 设备寄存器地址，按协议偏移规则填写 Data Type : DIGITAL # 数字量/模拟量，决定后续处理方式 Eng Units : - # 工程单位，模拟量才需要 Scale : 1.0 # 原始值到工程值的缩放系数字段里最容易翻车的是 Address。不同协议对寄存器地址的偏移约定不一样，有的从 0 开始，有的从 1 开始，Modbus 的 4xxxx 保持寄存器在配置里到底填 40001 还是 1，取决于驱动文档。填错不会报错，只会读到一个固定错值或者干脆不刷新，这种“静默错误”最难查。我的习惯是先用一个已知会变化的点位（比如计数器或心跳寄存器）验证通信，确认地址规则对了，再批量铺其他点。
2.3 通信驱动与 I/O Device 配置的取舍
Citect 支持多种驱动，老项目里 Modbus 和 OPC 最常见。选哪个不是拍脑袋：现场设备原生支持 Modbus 且点位不多，直接用 Modbus 驱动最省事，少一层中间件；设备是别的品牌、协议不开放，或者要汇总多台设备，走 OPC 更现实，让 OPC Server 去对接各家驱动，Citect 只认 OPC 这一层。代价是 OPC 多一个进程、多一处故障点，调试时要在两边分别看状态。
配置 I/O Device 时几个参数要盯住：通信端口（串口的波特率、数据位、停止位、校验位必须和现场设备完全一致，差一位就通不了）、站地址（从站号，多设备总线上一旦重复直接冲突）、超时与重试次数（现场干扰大时适当放宽，但放太宽会让画面刷新变迟钝）。串口参数这块是经典翻车点，尤其是校验位，设备手册写“8N1”就老老实实 8 数据位、无校验、1 停止位，别自作主张改成偶校验。配置完先别急着画画面，用软件自带的通信状态监视看设备是否 Online、读写计数是否在涨，这一步过了再往上走。
3. 从零跑通一个监控画面：配置步骤与 Cicode 逻辑
模型清楚之后，动手做一个最小可用的监控画面，是验证整条链路最快的方式。目标不大：连一台模拟设备，采两个点（一个运行状态、一个温度值），画一个页面显示状态灯和数值，加一个按钮能下发启停命令，再配一条超温报警。这套流程走通，后面做多大工程都是同一套动作的重复。
3.1 建立工程与 I/O 设备：最小链路先通
第一步建工程，指定工程目录和运行模式（开发/运行）。第二步加 I/O 设备，选协议、填端口和站地址。如果手头没有真实 PLC，常见做法是用 Modbus 从站模拟工具在本机开一个虚拟从站，把 Citect 指向 127.0.0.1 的对应端口，这样不依赖硬件也能把链路跑通。模拟从站里预先放几个寄存器，一个模拟运行状态（0/1 翻转），一个模拟温度（递增数值），方便观察刷新。
I/O Device 关键配置项（以 Modbus TCP 为例） Name : PLC_SIM Protocol : Modbus TCP IP Address : 127.0.0.1 # 指向本机模拟从站 Port : 502 # Modbus TCP 默认端口 Slave/Unit : 1 # 从站单元号，与模拟端一致 Timeout : 1000 ms # 单次读写超时 Retries : 3 # 失败重试次数参数说明：IP 和端口必须和模拟从站监听的一致，Unit 号在 TCP 下有些设备忽略、有些严格校验，模拟端设几就填几。Timeout 别设太小，本机模拟可以 500ms，现场串口或跨网段建议 1000ms 以上。Retries 给 2 到 3 次足够，太多会拖慢整体扫描。配好后打开通信监视，确认 Online 且读写计数持续增长，这一步不通，后面全是白费。
3.2 变量、标签与画面绑定：让数值动起来
链路通了，接着建变量。按 2.2 的命名规则建两个 Variable，分别映射模拟从站里的状态寄存器和温度寄存器，数据类型一个 DIGITAL 一个 ANALOG。再建对应 Tag，温度 Tag 上配量程换算，比如原始 0 到 1000 对应 0 到 100.0 摄氏度，缩放系数 0.1。然后新建一个 Graphics 页面，从图符库拖一个指示灯绑运行状态变量，拖一个数值显示绑温度 Tag，设好刷新周期。
绑定的时候注意动画连接的方向：显示类元素是“读”，按钮类元素是“写”。指示灯绑 DIGITAL 变量，0 灭 1 亮，映射关系别搞反。数值显示要确认绑的是 Tag 而不是 Variable，否则量程换算不生效，画面上会显示原始寄存器值，看着像“温度 523 度”这种玄学数字。页面做完切到运行模式，看指示灯是否随模拟值翻转、温度是否按预期递增，两个都动，说明读链路完整。
3.3 Cicode 写按钮动作与联锁：逻辑别塞进画面
按钮下发命令不建议直接在动画连接里写死，稍微复杂一点的动作都放到 Cicode 里，画面只负责触发。比如启停按钮，点击时调用一个 Cicode 函数，函数里先判断当前状态、做互锁判断，再写目标寄存器。这样逻辑集中、可复用、好排查，画面层保持干净。
// 一号泵启停控制，带运行状态互锁 FUNCTION PumpStartStop() INT nRun; nRun = TagRead("AREA1_P01_RUN"); // 读取当前运行状态 IF nRun = 1 THEN // 已在运行，执行停止：先确认无联锁条件再写 0 IF TagRead("AREA1_P01_FAULT") = 0 THEN TagWrite("AREA1_P01_CMD", 0); ELSE // 有故障时禁止停止，弹提示 Message("P01 故障中，禁止操作", 1); END ELSE // 未运行，执行启动 TagWrite("AREA1_P01_CMD", 1); END END逻辑说明：先读运行状态决定这次点击是启动还是停止，避免用两个按钮各写一套。启动前可以再加条件判断（比如液位、联锁），停止前检查故障位，有故障不允许停，防止把带故障运行的设备直接断掉造成二次问题。TagRead/TagWrite是 Citect 里读写标签的标准函数，参数是标签名，返回当前值。Message用于弹提示，第二个参数控制提示级别。这段逻辑的关键是把“判断”和“动作”分开写，判断条件以后要加就加在 IF 里，动作保持单一，改起来不容易漏。
3.4 报警与趋势：把历史数据留下来
报警配置在 Alarm 里定义，给温度 Tag 设一个高限，比如超过 80 度触发高报警，超过 90 度触发高高报警，级别分开。报警要配确认机制，操作员确认后状态从“未确认”转“已确认”，但条件仍存在时不能消失，这是 SCADA 报警的基本规矩，别图省事做成条件消失就清掉，否则事后追责没有记录。趋势用 Trend 配置，把温度 Tag 加进去，设采样周期和保存时长，历史数据落到工程的历史库文件里。
采样周期和保存时长要算一下存储量：点位多、周期短、保存久，历史库会涨得很快。常见做法是关键工艺点 1 秒采样、保存 30 天，一般监视点 5 到 10 秒采样、保存 7 天，按需分级。趋势配好后在运行画面拉出来看曲线是否连续、有无断点，断点通常意味着通信中断或采样任务没跑起来，回到通信监视去查。
4. 避坑与排查：老版本 SCADA 最容易翻车的五处
这套软件年代久，跑在现代系统上、对接现代设备时，坑集中在兼容性、通信和工程迁移三块。下面五条是按“现象 → 原因 → 解决”整理的实战记录，遇到问题先对照，能省不少时间。
4.1 安装后无法启动或运行报错
现象：安装过程看似正常，双击运行提示缺少组件或直接闪退。原因：老版本对操作系统版本、运行库、权限有要求，装在过新的系统上或缺某些运行库时容易出问题；另外安装路径含中文或空格也可能引发异常。解决：优先装在受支持的较老系统环境或独立虚拟机里，安装路径用纯英文无空格；补齐对应运行库；以管理员权限安装和运行。装之前先确认目标系统在支持列表内，别硬上新系统再回头折腾。
4.2 设备显示 Online 但数据不刷新
现象：通信监视里设备状态是 Online，读写计数也在涨，但画面数值纹丝不动。原因：多半是变量地址偏移规则不对，读到了固定错值；或者画面绑的是 Variable 而量程换算在 Tag 上，显示的是原始值看着像没变；也可能是画面刷新周期设得太长。解决：先用一个确定会变的点位（计数器）验证地址规则，确认偏移从 0 还是从 1 开始；检查画面绑定对象；把刷新周期调到 1 秒观察。地址规则这条最隐蔽，因为不报错，只能靠已知变量反推。
4.3 串口通信时通时断
现象：串口设备偶尔掉线，重连后恢复，运行一段时间又断。原因：波特率或校验位与设备不完全一致、总线干扰、超时设得过紧、多设备轮询间隔太密。解决：逐项核对串口参数，尤其是校验位和停止位；适当加大超时和重试；降低轮询频率，给总线留出间隔；检查接线屏蔽和接地。串口这块没有捷径，参数必须和设备手册逐字对齐，差一位就是时通时断的玄学。
4.4 工程从旧机器迁移后画面错乱
现象：把工程目录整体拷到新机器，打开后画面元素错位、图符丢失、部分变量报未定义。原因：工程依赖图符库、驱动、字体等外部资源，只拷工程目录不带全资源就会缺；不同版本间工程格式也可能不完全兼容。解决：迁移时连同图符库、驱动、自定义资源一起打包；确认源和目标的软件版本一致或按官方迁移路径升级；迁移后逐个页面检查绑定关系。别指望一个压缩包拷过去就能跑，工程是“工程 + 环境”的组合。
4.5 报警刷屏或历史数据断档
现象：报警列表瞬间被同一条件刷满，或者趋势曲线中间出现大段空白。原因：报警没配死区（deadband），数值在阈值附近抖动反复触发；历史数据断档多是采样任务中断、历史库路径不可写或磁盘满。解决：给模拟量报警配死区，比如高限 80 度、回差 2 度，避免临界抖动；检查历史库所在磁盘空间和写入权限，确认采样服务在运行。报警死区这个参数新手常忽略，配上之后报警列表立刻清爽。
5. 进阶：用 Cicode 做批量点检与工程自检脚本
工程做到几十上百点位后，靠人工逐个点画面确认状态不现实，也容易漏。我的习惯是在交付或改造前跑一遍自检脚本，用 Cicode 把关键点位批量读一遍，把通信异常、数值越界、报警未确认的点汇总输出，相当于给工程做一次体检。这不是官方功能，是自己搭的一套检查逻辑，但很实用。
思路很简单：维护一张关键点位清单（可以放在一个文本文件或工程表里），脚本循环读取每个点的当前值和通信状态，按规则判断是否异常，最后把结果写到一个汇总页面或日志文件。下面是一个简化版框架：
// 关键点位批量自检，输出异常清单 FUNCTION PointCheck() INT i; INT nVal; STRING sName; STRING sResult; // 点位清单，实际可改为从文件读取 STRING sPoints[5] = ["AREA1_P01_RUN", "AREA1_P01_TEMP", "AREA1_P02_RUN", "AREA1_TANK_LEVEL", "AREA1_P01_FAULT"]; sResult = ""; FOR i = 0 TO 4 DO sName = sPoints[i]; nVal = TagRead(sName); // 读取当前值 // 简单规则：读失败或明显越界记为异常 IF nVal = -1 THEN sResult = sResult + sName + ": 读取异常" + "\r\n"; END END // 结果写入日志文件，便于交付留档 FileWrite("C:\check_result.txt", sResult); END逻辑说明：数组存点位名，循环读取，按规则判断后拼字符串，最后落文件。实际使用时规则可以细化——模拟量按量程判断越界，数字量按预期状态判断，报警点查未确认数量。TagRead读失败时返回值依驱动而定，这里用 -1 作示意，真实项目要先确认驱动的失败返回值约定，别把正常值误判成异常。FileWrite写日志，路径要选运行账户有写权限的目录。
这套自检脚本的价值在于把“人眼扫画面”变成“脚本出清单”，改造前后各跑一次，对比异常项数量，能快速判断这次改动有没有引入新问题。参数上要注意两点：一是点位清单别写死在代码里，点位一多维护成本高，改成读配置文件更现实；二是自检本身会占用通信带宽，别在正常生产高峰跑，安排在检修窗口或低负荷时段。
从那以后我每次接手老 Citect 工程，都强制先跑一遍通信监视加自检脚本，确认底层链路和关键点位状态，再动画面和逻辑，省掉了很多“改了画面发现是设备没通”的返工。这份 Vijeo Citect6.1.zip 对还在维护存量 SCADA 项目的人来说，值得留着当环境用，把上面这套链路和自检习惯跑熟，比单纯装个软件有用得多。希望帮到你。
本文还有配套的精品资源，点击获取
