简介：组态王6.55是亚控科技面向低端自动化市场推出的工业组态软件，这份doc文档系统梳理了其核心功能与产品特性。内容涵盖向导式报表（可快速建立班报、日报、周报、月报、季报和年报表）、全新Web发布机制（画面发布、数据发布与OCX控件发布）、集成KingHistorian工业实时数据库以支持百万点级数据存储与检索，以及变量导入导出、分布式报警、配方处理、脚本语言等实用能力；同时介绍了硬加密与软授权两种授权方式及英文版、韩语版、繁体版、OEM等多语言版本，适合工业自动化工程师、系统集成商及组态软件学习者快速了解产品功能边界与选型要点。资源仅1个doc文档、293KB，轻量易读。目前已有932人学习下载，是入门组态软件与评估组态王6.55的高性价比参考资料。
1. 组态王 6.55 值不值得升：先说清它跟老版本的区别
手里攥着一套用旧版组态王维护了三年的上位机项目，甲方催着要“报表自动化、网页看数据”，这时候最纠结的不是要不要换软件，而是换了之后原来的画面能不能迁、历史数据怎么接、Web 发布是不是又要单独装一套东西。这份 6.55 中文版文档把这些事讲得比较透：它保留了老版本运行稳定、操作习惯不变的内核，新增了向导式报表、支持 OCX 控件发布的 Web 服务、以及工业实时数据库 KingHistorian 的集成。对正在做中小型自动化上位机、或者想把人工抄表升级成数据平台的工程师来说，这份资料可以直接拿来当选型依据和实施参照。
2. 向导式报表落地：从历史库到班报月报的完整建表流程
6.55 新增的报表向导，是很多老用户最期待的功能。以前做报表要么靠报表控件手动画表格、写脚本填数，要么把历史数据导到 Excel 里手工套模板。向导式报表把“选数据源、定统计周期、出表格”三步压缩到一个配置流程里，直接以组态王历史库或 KingHistorian 为数据源生成报表。
2.1 报表向导到底解决了什么问题
先理一遍数据链路。现场 PLC、仪表的数据进入组态王后，实时值送去画面显示，同时按配置写入历史库。报表向导读的就是这块历史数据，而不是实时快照。这个点经常被人误解，以为报表是“当时有多少数据就取多少”，实际是必须等历史库里有了数据之后统计才有意义。所以新建班报的当天，如果历史库还没来得及落数据，报表预览出来是空表，这是正常现象，不是故障。
向导自动生成的报表类型有六种：班报、日报、周报、月报、季报、年报。它们本质上是同一个统计引擎，区别在于时间粒度和汇总层级。班报按班次时段汇总，日报按自然日汇总，周报按周一到周日汇总，月报、季报、年报依次向上聚合。字段计算包括最大值、最小值、平均值、累计值，全在向导里勾选，不用手写脚本。和旧版本里“每个报表都要单独设计模板、单独绑定变量”的做法比起来，6.55 的改进是把重复劳动压缩成配置项，维护成本降了一大截。
这六类报表的差异还可以再拆一层。
| 报表类型 | 时间切片方式 | 典型用途 | 统计重心 |
|---|---|---|---|
| 班报 | 按班次时段，如 8:00-16:00 | 交接班记录 | 均值、极值、累计 |
| 日报 | 按自然日 0:00-24:00 | 日生产汇总 | 日累产量、每日极值 |
| 周报 | 按周一起止 | 周度分析 | 周累计、日均 |
| 月报 | 按自然月 | 月度绩效考核 | 月累计、月极值 |
| 季报 | 按季度 | 季度趋势 | 季累计、同比 |
| 年报 | 按自然年 | 年度复盘 | 年累计、峰值 |
实际配置时，关键是先想清楚哪一层报表给谁看。给车间操作工看的班报、日报，统计粒度要到测点，给管理层看的月报年报则更多是汇总数值。不要把全部测点堆到一张月报里，那会让表格失去重点。
2.2 建表流程：数据源、时间粒度与字段映射
在工程里新建一张日报表，常见路径和配置要点如下。组态王 6.55 的配置界面集中在开发系统里，报表向导通过菜单或工具箱入口打开，不同行业版的菜单位置会略有不一致，但逻辑顺序不会变。
| 步骤 | 操作 | 关键参数 |
|---|---|---|
| 1 | 进入报表向导，选择新建日报表 | 报表名称、报表保存路径 |
| 2 | 选择数据源类型 | 组态王历史库 或 KingHistorian |
| 3 | 勾选要统计的变量 | 温度、压力、流量、液位等测点 |
| 4 | 设置统计周期与起始时间 | 日期区间、每日起始点 |
| 5 | 勾选输出字段 | 平均值、最大值、最小值、累计值 |
| 6 | 生成并预览 | 核对行列数据，保存 |
数据源选型是第一步要决策的事。如果现场点数在几千点以内、历史数据保留时间不超过一个月，直接用组态王自带历史库就够了，少部署一层服务。如果点数上万，或者要求历史保存半年以上，就让报表向导以 KingHistorian 为数据源，否则查询速度会随着历史文件增大明显下降。这个选择在报表向导里只是一行下拉框，但背后牵涉一整套存储架构，建议在建表前先定架构再建表。
参数说明里有个容易踩的坑：时间范围一定要覆盖已经落库的时间段，否则报表统计出来缺数据。我一般的做法是先到历史查询界面确认目标变量在目标时间段有数据，再回头跑向导。尤其是刚投运的新工程，历史库可能是空的，向导跑出来空表又排查半天，最后发现问题在数据源还没写进去。
报表生成后，组态王会按配置的路径保存文件，支持打印输出。现场常见的需求是交班时自动打印班报，这可以在运行系统里做定时触发，到点自动调出报表并发送到打印机。注意保存路径要设在固定位置，别用默认的相对路径，否则工程拷贝到另一台机器后报表不知道落到哪个目录去了。
2.3 行列统计与跨天班次的处理细节
6.55 除了固定六类报表，还支持值的行列统计。它的作用是把一组变量按行排列、把统计时间按列切开，形成一张“行是测点、列是时段”的统计表，适合交接班记录和过程质量分析。配置时先定义行方向放哪些变量，再定义列方向放哪些时段，每列可以单独设定为均值、极值或累计。这里的逻辑类似 Excel 里的数据透视表，只是聚合计算由组态王在内存完成，不需要额外写 SQL。
验证行列统计是否正确，我习惯的做法是：取某个时间段，把行列统计输出的均值与历史曲线在相同时段读到的数值做抽样对比，偏差在采样精度范围内算通过。如果偏差明显，先检查变量是否在这段时间里有报警或断线，许多统计异常其实源自原始数据本身的缺失，而不是统计引擎算错。
跨天班次是三班倒工厂里最常见的特殊场景。晚班从 22:00 到次日 6:00，如果报表向导按自然日切分，这段数据会被拆成两天各一段，交班记录就对不上。解决办法是把跨天班次拆成两段分别在两天内统计，再做一次合并，或者将班次起始时间调整到 6:00 这种不跨天的整点。这个细节在文档里没有展开写，属于现场摸出来的经验，建议做交接班报表时提前确认班次定义方式。
3. Web 发布别搞混：画面发布、数据发布、OCX 控件发布的边界
6.55 的 Web 发布功能在文档里写得比较集中，但三种发布模式各自的适用场景，需要结合现场需求去理解。很多人以为 Web 发布就是把画面截图传到网页上，实际操作时才发现画面、数据、控件是三套不同的配置逻辑。
3.1 三种发布模式是给不同浏览者准备的
画面发布，是把组态画面原样搬到浏览器里。远程用户能看到与现场监控机相同的画面布局，包括图形、动画、报警闪烁。它的价值在于“看着一样”，适合远程值班室、调度中心这种需要还原现场视觉状态的场景。数据发布，侧重于数值和报表：网页上直接显示实时数据、历史趋势、报表页面，适合做数据看板或者领导查询页，不强调画面还原。OCX 控件发布，则是把工程里的 ActiveX 控件嵌入网页，浏览者可以直接在页面上操作——比如点击启动、停止按钮下发控制命令。
这三者不是互斥的，一个工程可以同时发布画面和数据。决定用哪种的标准是“浏览端要做什么”：只让看，用画面发布或数据发布；要让远程操作，必须走 OCX 控件发布，并且在组态王里配好操作权限。现场最容易出问题的是把“只看数据”和“远程操作”混在一个页面里放开，操作权限没绑好，远程误动引发设备停机，这种事故并不少见。
从实现角度说，画面发布对工程画面的规范性要求高。画面里的图元、动画连接在开发系统里是什么样，浏览器端就是什么样，但前提是画面发布配置里把需要的画面都勾上。经常有人发布完发现少了某个画面，或者画面里文字不显示，多半是发布配置没选全，而不是 Web 服务坏了。
3.2 IE 客户端与 Web 服务器的同步机制
远程 IE 客户端看到的画面和 Web 服务器上的运行系统保持同步。同步不是普通的页面定时刷新，而是 WebServer 把运行系统的画面变化以增量方式推给客户端。比如现场一台电机状态从停止变成运行，组态画面里颜色从灰变绿，远程页面会在下一个推送周期内自动更新，不需要用户手动刷新。
这个机制的代价是实时性依赖网络质量。如果画面里包含大量位图背景、频繁闪烁的动画，或者变量刷新频率特别高，跨公网访问时容易出现画面响应慢。这不是软件本身性能不够，而是增量推送在带宽受限时被拖住了。现场部署 Web 发布时，我一般建议浏览端和 Web 服务器尽量放在同一局域网；跨公网访问时，画面里减少大面积位图和高速闪烁动画，把刷新频率适当调低，比盲目升级服务器更有效。
3.3 发布配置步骤与访问验证要点
发布配置的操作路径大致如下，具体菜单名以安装后的开发系统界面为准。
- 在开发系统中进入 Web 发布配置入口
- 选择画面发布，勾选需要发布的画面文件
- 配置数据发布，勾选需要实时显示的变量和历史报表
- 配置 OCX 控件发布，选择要嵌入的控件
- 绑定浏览端用户与操作权限，区分只读与可操作
- 启动 WebServer 服务
- 在浏览端输入
http://服务器IP/工程名验证访问
验证时重点看画面元素是否与开发系统一致：动画闪烁、颜色变化、数值刷新。OCX 控件发布多一步浏览器端控件注册，首次访问会提示安装控件，需要在浏览器里放行并完成注册。这一步在换了新电脑之后特别容易卡住，因为新机器的安全级别默认更高，ActiveX 直接被拦截。
浏览器端打不开页面时，先查三处。第一，WebServer 服务有没有正常启动，服务没起来页面必然白屏。第二，服务器防火墙有没有放行对应端口，公网访问还要检查路由器映射。第三，浏览器安全设置，把站点加入受信任站点，并将 ActiveX 控件运行权限设为允许。换了一台新电脑浏览端报错，大概率是第三项没做，这是组态王 Web 发布和通用网页浏览最大的差别——它依赖 ActiveX，对浏览器环境有硬性要求。
4. KingHistorian 集成：百万点存储与双库策略怎么选
KingHistorian 是 6.55 里集成度最深的一块。文档给了几个硬指标：单服务器支持 100 万点、256 个并发客户端同时存储和检索、每秒检索单个变量超过 20,000 条记录。这几个数字看起来是性能宣传，实际上是选型边界。
4.1 工业实时数据库在组态监控里的角色
组态监控场景的典型流量是几百上千个变量每秒都在产生新值。传统关系数据库在这种写入频率下很快会变成瓶颈——行锁、索引维护、磁盘随机写都会拖垮性能。工业实时数据库是针对时间序列做了专门优化的存储引擎，写入按时间顺序追加，查询按时间范围分段定位，磁盘读写模式更接近顺序 IO，所以才能扛住高频写入和频繁检索。
KingHistorian 在 6.55 里的位置，是给组态王补上“海量历史数据”这块短板。组态王自带历史库在小点数场景够用，但点数过万、保存周期以年计时，自带的文件型历史存储就很难保证查询效率。KingHistorian 单独部署成服务，组态王通过标准接口把数据同时交给它，报表和趋势直接查工业库，查询压力不再落在现场监控机上。
那三个指标实际上对应三类需求。100 万点对应大厂区的测点总量，256 并发对应多人同时做历史分析和报表查询，每秒 20,000 条检索对应单变量的高频趋势回放。选型时不需要三个指标都拉满，而要根据现场规模卡边界：测点 5 万但只有十个人查询，重点看前两个；测点不多但事故追忆要求高频回放，第三个指标更关键。
4.2 双存储策略：组态王历史库与 KingHistorian 的取舍
6.55 支持数据同时写入组态王历史库和 KingHistorian，形成双存储。为什么要双写？组态王历史库零部署、上手快，适合小工程直接使用；KingHistorian 性能强、容量大，适合大点数长期保存。双写相当于给历史数据上了双保险——KingHistorian 宕机时组态王本地库还在继续收数，等工业库恢复后再补写。
但双写不是没有代价。最直接的是磁盘空间几乎翻倍。假设现场有 2 万个变量，每 5 秒存一个点，单库一天的数据量大约 3.4GB，双写就是约 6.9GB。一个月的保存周期就要 200GB 以上，这个估算虽然粗糙，但磁盘预算必须按双份算。在项目里见过最多的问题就是只按单库估了存储，结果双写跑两周就把磁盘写满了，历史数据开始丢段。
另一个取舍点是查询路径。双存储模式下，查询默认走哪条路径需要配置。如果报表和趋势都查 KingHistorian，现场监控机只写不读，压力会小很多。如果某些查询仍然走组态王本地库，本地库的分区容量和检索效率也要同步优化。我通常建议：2 万点以上且报表查询频繁的项目，数据源统一指向 KingHistorian，组态王本地库只做应急备份，这样查询路径清晰，也方便后续扩容。
4.3 KingHistorian 安装配置与验证
KingHistorian 作为独立组件安装，装完后再到组态王工程里配置连接参数：服务器地址、实例名称、认证账号。配置完成后的第一件事，是用工程自带的历史查询界面验证——如果能查到 KingHistorian 里的历史曲线，说明链路通了。
注意：KingHistorian 的授权与组态王授权是分开的。购买时要确认点数、并发数、授权年限这些维度，只装软件不装授权就上线，运行到某个时间点会停止写入。
验证阶段建议做一个时间压力测试：连续写入若干小时，再同时开多个查询客户端，观察检索响应速度是否满足现场要求。如果查询明显变慢，先看并发连接数是否逼近 256 上限，再看服务器磁盘 IO——工业实时数据库查询慢，八成问题出在磁盘是机械盘而不是接口配置上。现场用 SSD 做 KingHistorian 的存储盘，和用机械盘的效果差距极为明显，这是最容易被忽略的硬件选型点。
另外，双存储模式下 KingHistorian 写满或服务中断时，组态王要在配置里打开自动切换逻辑，让查询自动切回本地历史库，否则会出现“数据显示中断但现场一切正常”的假象。这个切换逻辑要在投运前测试完整——断掉 KingHistorian 服务，确认查询还能从本地库读到数据，再恢复服务确认数据继续双写，整个流程跑通才算合格。
5. 迁移授权与避坑：变量二次利用、软硬加密和四个现场教训
从旧工程迁到 6.55，最恼人的不是学新界面，而是上千个变量要不要重新敲一遍。6.55 的变量导入导出功能就是给这个场景准备的，配合授权方式的选型，基本能把迁移成本压到最低。
5.1 变量导入导出：老工程换新版本最省事的路径
6.55 支持把变量导出到 Excel 表格，修改后再导入新工程。老工程里上千个变量如果在新工程里重新手敲，既慢又容易敲错变量名或地址。导出后的 Excel 每一行对应一个变量，包含变量名、变量类型、连接设备、寄存器地址、数据类型、读写属性等字段。在 Excel 里做批量修改，比如把一批流量计的地址统一加偏移量，几分钟就完成，比在组态界面里逐个翻快得多。
操作流程可以压成几步。
- 在旧工程中导出变量，生成 Excel 文件
- 用文本编辑器或 Excel 批量修改变量属性
- 在新工程中导入 Excel
- 到设备配置里重新关联 PLC 通信参数
- 用“变量检查”功能扫描一遍，确认无重复无冲突
批量修改时最容易翻车的点是 Excel 单元格格式。变量名如果被 Excel 自动转成日期格式或科学计数法，导入后变量名就废了——比如E201被转成2.01E+02，导入直接报错。解决办法是先把整列设为文本格式再填内容，或者导出后不用 Excel 编辑，改用文本编辑器处理 CSV 文件。这是我自己亲手踩过的坑，后来凡是做变量批量修改，一律先设文本格式再动手。
5.2 硬加密与软授权的选择边界
6.55 提供硬加密和软授权两种方式。硬加密是加密锁，插在服务器上，拔走锁软件就不能运行，适合设备整体交付的场景——用户拿到的是一台带锁的整机，锁在机器在，锁不在机器就停。软授权是把授权信息绑定到某台机器的硬件特征上，不需要物理锁，但授权不能随意迁移到另一台机器。
工程上我一般这样判断：现场有多台备用机、工程可能频繁迁移环境，用软授权省事，换机器时找厂商重新激活即可；设备整机出厂、不允许用户随意拷贝工程、又不想管一堆物理锁的，用硬加密。这里有个细节：硬加密的驱动要装好，插上锁之后要在系统里确认识别到了，再启动运行系统，否则运行系统启动时直接报找不到授权。现场经常出现“明明插了锁还报授权失败”，就是驱动版本和系统不匹配。
还有一点值得注意：软授权绑定的是硬件特征，如果现场机器换网卡或重装系统，授权可能失效。遇到这种情况不用慌，走厂商的授权重置流程重新生成一份授权即可，但要在项目文档里写明授权信息和机器对应关系，避免几年后没人知道哪台机器绑了哪份授权。
5.3 现场最常见的四个坑
第一个坑：报表向导生成了空表。现象是预览页面没有任何数据行，报表框架都正常，但统计结果全空。原因通常是所选变量在目标时间段内没有历史数据，或者时间范围超出了历史库的保存周期。解决方法是先在历史查询界面确认目标变量在目标时间段有数据，再生成报表；同时检查历史保存周期是否覆盖报表时间范围。
第二个坑：Web 页面显示和控制画面不一致。现象是远程页面上的图标、数值和现场监控机对不上。原因多半是画面修改后没有重新发布，或者浏览器缓存了旧页面。解决方法是每次修改画面后重新执行发布，浏览器端清理缓存重新加载。我经历过一次远程调度室看到的是三天前的旧画面，现场已经改了工艺参数，问题就出在发布后没做二次验证。
第三个坑：双存储时磁盘空间耗尽导致历史数据缺失。现象是运行一段时间后历史曲线出现断带，前面一段有、后面一段没了。原因是只按单库容量估了磁盘，双写把空间写满后存储任务异常终止。解决方法是按双写量估算磁盘并留出至少 20% 余量，配置磁盘告警，或者在保存策略里启用定期清理、转储到外部存储。
第四个坑：变量导入后大量设备通信报错。现象是导入 Excel 后，工程里一大片变量显示通信故障，现场数据全部不动。原因是变量虽然导入了，但变量关联的连接设备在新工程里没有重新配置，或者设备地址与旧工程不一致。解决方法是导入后逐项核对设备配置，重新绑定通信参数，再进入运行系统做批量联调。不要一次性导入上千个变量就急着投运，先导一小部分验证通路。
6. 性能验证：从开发机到现场跑一遍这些检查
新工程上线前，我习惯按一套固定流程把 6.55 的关键功能跑一遍，这套验证不复杂，但能省掉很多现场返工。
报表验证是第一项。构造一段已知时间段的数据，比如手动写入一批恒定的模拟值，再用报表向导按这时间段生成日报，核对平均值、最大值、累计值和手算结果是否一致。偏差超过采样精度就要查数据链路，先看原始值，再看统计口径。历史曲线验证跟着做：在 KingHistorian 里检索同一时间段，曲线连续无断点，说明存储链路完整。
Web 发布验证要三端同步：一台开发机做配置端，一台现场监控机做运行端，一台浏览端电脑做客户端。三台机器同时打开同一画面，手动改变一个变量状态，观察浏览端是否在预期时间内同步变化。这一项验证的是 WebServer 的推送链路，不是只看页面能不能打开。
压力部分的验证可以简化：模拟多客户端同时查询历史数据，观察检索响应和服务器 CPU。响应变慢时，先查并发连接数，再看磁盘 IO，这两个是瓶颈高发点。
从那以后，我每次交付 6.55 项目都强制走一遍这套流程：报表先比对数、历史再查断点、Web 最后验三端。遇到过很多次看起来没问题、一上线就翻车的情况，最后都落在这些最基础的检查上。这套验证方法算不上什么高深技巧，但能把现场返工的概率压到最低。希望帮到你。
本文还有配套的精品资源，点击获取
