1. 项目概述为什么一个低代码平台要原生支持 OPC UA 客户端命令活字格 12.1 这个版本更新我第一时间下载安装后没急着点开设计器而是先翻了下 release notes 里关于“OPC UA”的那几行字——不是因为多爱看文档而是过去三年里我用活字格做过 7 个工业现场的数据集成项目其中 5 个卡在 OPC UA 接入环节要么靠写 C# 插件硬扛要么拖 Node-RED 做中间桥接再把结果塞进活字格的 Web API。每次交付前都要给客户额外解释“为什么我们的低代码平台不能直接连 PLC”那种心虚感干过工业集成的都懂。这次标题里写的“原生 OPC UA 客户端命令”不是加个按钮、配个地址就叫原生。它意味着活字格运行时也就是你发布的 Web 应用背后那个 .NET Core 服务内置了符合 OPC Foundation 认证的 UA TCP 栈能直接发起 Session、建立 SecureChannel、执行 Read/Write/Call 等标准服务调用全程不依赖外部进程、不走 HTTP 中转、不强制要求 Windows 系统——这点特别关键。很多同行还在用“活字格调用 Python 脚本去连 KEPServerEX”本质上还是两层架构出问题要查三处日志而 12.1 的命令是直接跑在活字格服务进程里的错误堆栈能精准定位到哪一行表达式、哪个节点 ID、哪次超时。我拿手头一个真实产线做测试西门子 S7-1500 TIA Portal V18 配置的 OPC UA 服务器启用匿名访问和 Basic256Sha256 加密。过去用旧版活字格必须在服务器上装 KEPServerEX再配置一个 OPC UA to REST 的通道活字格前端通过 Ajax 轮询那个 REST 接口现在我在活字格设计器里拖一个“OPC UA 读取”命令填入opc.tcp://192.168.1.100:4840点开节点浏览器直接看到Objects Station PLC GlobalDB DB1 Value1这个路径选中后生成绑定表达式{OPCRead(Objects.Station.PLC.GlobalDB.DB1.Value1)}发布后刷新页面数值实时跳动——整个过程从原来平均 3 小时配置调试压缩到 8 分钟内完成。这不是功能“有无”的问题而是架构层级的跃迁低代码平台第一次真正站在了工业通信协议的语义层上而不是在应用层打补丁。所以如果你正面临这些场景这个更新对你价值极大产线 MES 系统需要直连多品牌 PLC西门子、罗克韦尔、倍福但团队里没有专职的 OPC 开发工程师客户明确要求“所有数据链路必须可控、可审计、不引入第三方中间件”你不能再偷偷装 Node-RED项目预算紧张没法为每个接入点单独采购 KEPServerEX 许可证单点授权动辄上万你需要在移动端uniapp 打包的 App里展示实时设备状态但传统方案因跨域或证书问题无法在 iOS 上稳定运行。这 9 个命令不是孤立的功能点它们共同构成了一个完整的 OPC UA 会话生命周期管理能力从连接、发现、读写、方法调用到异常重连、会话保持、批量操作。接下来我会带你逐个拆解不讲抽象概念只说你在设计器里点哪里、输什么、为什么这么输、输错会报什么错——就像我当年带新人时在工控柜旁一边接线一边教的那样。2. 核心设计逻辑与技术选型深挖为什么是这 9 个命令为什么不是 SDK 封装2.1 这 9 个命令的完整清单与设计意图活字格 12.1 并没有把 OPC UA 协议栈全量暴露给用户而是做了非常务实的裁剪。我对照 OPC UA Part 4Services规范和实际工业现场高频需求梳理出这 9 个命令的底层映射关系命令名称对应 OPC UA 服务典型使用场景是否支持异步是否需预建会话OPCConnectCreateSession首次连接服务器获取 SessionId否阻塞否OPCBrowseBrowse查看服务器地址空间结构找节点路径是是OPCReadRead读取单个/多个节点当前值含时间戳、状态码是是OPCWriteWrite写入单个/多个节点值支持类型自动转换是是OPCSubscribeCreateMonitoredItems订阅节点变化实现“推模式”实时更新是是OPCUnsubscribeDeleteMonitoredItems取消订阅释放服务器资源是是OPCCallCall调用服务器端定义的方法如启动/停止设备是是OPCDisconnectCloseSession主动关闭会话清理资源否阻塞是OPCGetStatusGetStatus获取当前会话状态、服务器基本信息是是注意两个关键设计点第一“OPCConnect”和“OPCDisconnect”是唯一两个同步阻塞型命令。这是刻意为之——连接建立失败必须立刻反馈比如证书不信任、端口不通、用户名密码错不能让用户以为“正在连”结果后台静默重试 30 秒才报错。我实测过当输入一个不存在的 IP 地址时OPCConnect在 2.8 秒后抛出System.Net.Sockets.SocketException错误信息里直接包含“No such host is known”比某些国产 OPC 调试软件的“连接超时”提示清晰十倍。第二所有读写类命令Read/Write/Subscribe都强制要求先执行 OPCConnect。这不是为了增加步骤而是 OPC UA 协议本身的强会话约束你不能跳过 Session 创建就直接发 Read 请求。活字格用这种“硬性依赖”倒逼开发者理解协议本质——很多现场问题比如读数始终为 Bad根源就是会话未激活或已过期而不是节点路径写错。2.2 为什么不用封装好的 OPC UA .NET SDK——性能与安全的双重权衡有朋友问“既然 .NET 生态有成熟的Opc.UaFx.Client库活字格为什么不直接封装它” 我专门约了活字格架构师喝了顿茶得到的答案很实在不是不能而是不敢。Opc.UaFx.Client是个优秀的开源库但它默认启用了“自动重连”和“会话保持”机制。在工业现场PLC 重启、网络抖动、防火墙策略变更太常见了。如果活字格底层无脑套用它的自动重连就会出现两种灾难性情况资源泄漏每次重连都新建一个UaTcpSessionChannel而旧 Channel 因未显式关闭TCP 连接处于TIME_WAIT状态。我们一个客户现场曾因此在 72 小时内耗尽了 Windows 服务器的 65535 个端口导致所有新连接失败状态错乱自动重连后旧的 MonitoredItem 订阅关系可能失效但客户端仍按老规则推送数据导致前端显示“设备运行中”而实际 PLC 已停机。活字格的选择是自己实现精简版 UA TCP 栈只保留最核心的 Session/SecureChannel 管理把重连逻辑完全交给开发者控制。比如OPCConnect命令有个关键参数RetryCount默认 0你设成 3它就会在首次失败后间隔 1 秒、2 秒、4 秒各重试一次每次失败都触发OnError事件你可以在此写日志、发告警、切备用服务器地址。这种“可控的脆弱性”远比“不可控的健壮性”更适合工业系统。另一个常被忽略的点是证书信任链处理。Opc.UaFx.Client默认信任所有证书开发方便生产危险而活字格 12.1 强制要求若服务器使用自签名证书必须提前将证书导入活字格服务所在机器的“受信任的根证书颁发机构”存储区。我在测试时故意没导入OPCConnect直接返回BadCertificateInvalid错误并附带证书指纹供你核对——这看似增加了部署步骤实则堵死了生产环境最常被忽视的安全缺口。2.3 与 Node-RED / KEPServerEX 的本质区别谁在承担协议解析工作网上搜“opc ua node-red 实现 opc ua 转 mqtt”结果铺天盖地。但很少有人说清一个事实Node-RED 本身不解析 OPC UA 二进制协议它依赖node-opcua这个 JavaScript 库。而 JS 解析二进制流的性能天然弱于 .NET 原生实现。我做过对比测试同一台 i5-8250U 的工控机用 Node-RED 每秒最多处理 120 个 OPC UA Read 请求换成活字格 12.1 的原生命令轻松跑到 850 QPS测试条件读取 10 个 Int32 节点超时 100ms。更关键的是数据语义保真度。Node-RED 的 OPC UA 节点输出的是 JSON比如一个DateTime类型节点它会转成2024-05-20T08:30:45.123Z字符串而活字格的OPCRead返回的是 .NET 的DateTime对象前端绑定时可直接用{value:yyyy-MM-dd HH:mm:ss}格式化毫秒级精度不丢失。这对需要做时间序列分析的场景比如计算设备单次运行时长至关重要。至于 KEPServerEX它本质是个 OPC UA 服务器代理——你让活字格连 KEPServerEXKEPServerEX 再去连真正的 PLC。多一层转发就多一重故障点KEPServerEX 的许可证到期、License Server 不可达、内部队列积压……而活字格 12.1 是直连只要 PLC 的 OPC UA 服务开着就能通。当然KEPServerEX 的优势在于协议转换比如把 Modbus RTU 设备转成 OPC UA这不属于活字格的职责范围二者是互补而非替代关系。3. 9 个命令全流程实操从零开始搭建一个设备监控页面3.1 环境准备与前置验证别跳过这 3 分钟否则后面全是坑在活字格设计器里新建一个空白页面前请务必完成以下验证。我见过太多人卡在这一步最后发现是基础环境问题第一步确认 OPC UA 服务器已就绪不要依赖“PLC 程序已下载”这个说法。打开任意 OPC UA 调试软件推荐免费的 UaExpert输入服务器地址opc.tcp://192.168.1.100:4840点击连接。成功后在地址空间树里展开Objects→Station你应该能看到类似PLC_1或Controller的子节点。如果连不上优先检查PLC 防火墙是否放行 4840 端口西门子默认是 4840罗克韦尔可能是 49320TIA Portal 中 OPC UA 服务器是否启用Options Settings OPC UA Server Enable用户权限是否正确匿名访问需勾选Allow Anonymous Login否则OPCConnect会报BadUserAccessDenied。第二步验证活字格服务账户权限活字格 Web 应用默认以IIS APPPOOL\GrapeCity身份运行。这个账户必须有权限读取本地证书存储区。打开服务器上的certlm.msc本地计算机证书管理器展开受信任的根证书颁发机构 证书确认你的 OPC UA 服务器证书或其 CA 证书已在此处。如果没有右键证书 →所有任务 导入选择“本地计算机”并勾选“将此证书放入下列存储区” →受信任的根证书颁发机构。提示如果服务器用的是公共 CA 签发的证书如 Lets Encrypt这步可跳过。但工业现场 95% 以上都是自签名证书务必手动导入。第三步设计器插件检查打开活字格设计器 →帮助 关于确认版本号是12.1.xxx。然后进入工具 选项 扩展查看OPC UA Client Commands是否已启用。如果灰色不可选说明安装包未包含该模块——请重新下载完整版安装包官网下载页明确标注“含工业协议扩展”。完成这三步后你才算真正站在了起跑线上。接下来的所有操作我都基于一个真实案例监控一条包装线的 3 台变频器VFD1/VFD2/VFD3实时显示运行状态、频率设定值、当前输出频率并提供“启动/停止”按钮。3.2 第一个命令OPCConnect —— 建立会话的 5 个必填参数详解在页面设计器中点击左侧工具箱的命令分类找到OPCConnect命令拖到画布上。双击打开属性面板你会看到 7 个参数但真正必须填的只有 5 个EndpointUrl必填格式必须是opc.tcp://IP:Port不能带路径、不能加/、不能用主机名除非 DNS 解析已配置。例如opc.tcp://192.168.1.100:4840。我曾因填了opc.tcp://vfd-server.local:4840导致连接失败查日志才发现 DNS 解析超时——工业现场请一律用 IP。SecurityPolicy必填下拉菜单有None、Basic128Rsa15、Basic256、Basic256Sha256。这必须和 PLC 服务器配置严格一致。西门子 TIA Portal V18 默认是Basic256Sha256罗克韦尔 Studio 5000 默认是Basic256。填错会直接报BadSecurityPolicyRejected。不确定时先用 UaExpert 连一次看连接详情里的 Security Policy 字段。UserIdentity可选但强烈建议填类型是OPCUserIdentity对象。即使服务器允许匿名也建议填一个空对象{}避免某些固件版本的兼容性问题。如果需要认证填{ Type: UserName, UserName: admin, Password: 123456 }注意密码明文存储有风险生产环境应结合活字格的“加密参数”功能将密码存在配置文件中。SessionName必填这是你在活字格里给这个会话起的名字用于后续所有命令引用。必须全局唯一建议用业务含义命名如PackLine_VFD_Session。别用Session1这种后期维护会疯。Timeout必填单位毫秒默认 1000010 秒。别贪大工业现场网络延迟波动大设成 30000 反而会让前端卡住。我的经验是局域网设 3000跨 VLAN 设 5000有防火墙策略的设 8000。其他两个参数RetryCount设 2 即可配合RetryDelay默认 1000ms形成指数退避KeepAliveInterval默认 10000ms即每 10 秒发一次心跳包维持会话。PLC 侧通常要求 30 秒内有心跳这个值足够安全。配置完点击测试命令。如果返回Success: Connected to opc.tcp://192.168.1.100:4840说明会话建立成功。此时你可以在设计器的变量面板里看到一个名为PackLine_VFD_Session的会话变量类型是OPCSession——这就是后续所有命令的操作手柄。3.3 发现节点OPCBrowse 命令的三层递进式探索法会话建好了但你还不知道要读哪个节点。OPCBrowse就是你的“探照灯”。拖一个OPCBrowse命令到画布设置SessionName为PackLine_VFD_Session其他参数留空点击测试。返回结果是一个 JSON 数组类似[ {NodeId:ns2;i5,DisplayName:VFD1,NodeClass:Object}, {NodeId:ns2;i6,DisplayName:VFD2,NodeClass:Object}, {NodeId:ns2;i7,DisplayName:VFD3,NodeClass:Object} ]这里的关键是理解NodeId的语法ns2;i5表示命名空间索引 2整数节点 ID 5。不同 PLC 命名空间不同西门子通常是ns2罗克韦尔是ns3。DisplayName是你在 TIA Portal 里给对象起的名字这才是你该记住的。但光有顶层对象不够得往下钻。OPCBrowse支持BrowseDirection参数设为Forward默认ReferenceTypeId设为Organizes固定值i35NodeId填ns2;i5即 VFD1 的 ID再测试。这次返回[ {NodeId:ns2;i101,DisplayName:Status,NodeClass:Variable}, {NodeId:ns2;i102,DisplayName:FreqSetpoint,NodeClass:Variable}, {NodeId:ns2;i103,DisplayName:FreqOutput,NodeClass:Variable}, {NodeId:ns2;i104,DisplayName:ControlMethods,NodeClass:Object} ]看到ControlMethods是个 Object说明里面有可调用的方法。再对它Browse一次NodeId填ns2;i104ReferenceTypeId仍为i35返回[ {NodeId:ns2;i201,DisplayName:Start,NodeClass:Method}, {NodeId:ns2;i202,DisplayName:Stop,NodeClass:Method} ]至此你拿到了完整路径状态变量VFD1.Status→ns2;i101启动方法VFD1.ControlMethods.Start→ns2;i201注意OPCBrowse返回的NodeId是二进制协议里的原始 ID而活字格命令支持更友好的“路径式”写法。你完全可以不用记ns2;i101直接在OPCRead命令里写VFD1.Status活字格会在运行时自动解析。但建议你第一次用OPCBrowse把路径摸清楚避免拼写错误。3.4 实时读取OPCRead 命令的 3 种用法与性能陷阱现在可以读数据了。拖一个OPCRead命令SessionName填PackLine_VFD_SessionNodeIds参数填一个数组[VFD1.Status, VFD1.FreqSetpoint, VFD1.FreqOutput]点击测试返回[ {NodeId:VFD1.Status,Value:1,StatusCode:Good,SourceTimestamp:2024-05-20T08:30:45.123Z}, {NodeId:VFD1.FreqSetpoint,Value:50.0,StatusCode:Good,SourceTimestamp:2024-05-20T08:30:45.124Z}, {NodeId:VFD1.FreqOutput,Value:49.8,StatusCode:Good,SourceTimestamp:2024-05-20T08:30:45.125Z} ]Value字段就是你要的值StatusCode是 OPC UA 的状态码Good表示正常SourceTimestamp是 PLC 侧的时间戳比活字格服务器时间更可信。但这里有个巨大陷阱别在页面加载时一次性读 100 个节点OPC UA 协议规定单次 Read 请求最多携带 100 个节点但实际性能取决于 PLC 处理能力。我测试过一台 S7-1200当NodeIds数组超过 15 个时响应时间从 15ms 暴涨到 220ms。解决方案是分组组 1高频监控Status,FreqOutput,AlarmCode每 1 秒读一次组 2低频配置MaxFreq,AccelTime,DecelTime每 30 秒读一次组 3事件驱动只在用户点击“刷新参数”按钮时读在活字格里这通过定时器命令 不同的OPCRead实例实现。每个OPCRead命令独立配置NodeIds和Timeout互不影响。另外OPCRead支持AttributeId参数默认是Value读值也可设为DataType读数据类型、Description读描述。比如你想确认VFD1.Status确实是Int32类型可以单独发一个AttributeId: DataType的请求返回i6对应 Int32避免前端类型转换出错。3.5 实时推送OPCSubscribe 命令的订阅-取消订阅闭环轮询Polling适合低频数据但对状态变化如设备启停必须用订阅Subscription。OPCSubscribe是活字格 12.1 最惊艳的设计——它让低代码平台第一次拥有了真正的“推”能力。拖一个OPCSubscribe命令SessionName填PackLine_VFD_SessionNodeIds填[VFD1.Status]PublishingInterval设为1000毫秒SamplingInterval设为100毫秒。这意味着服务器每 100ms 检查一次VFD1.Status值只要变化就立即上报活字格客户端每 1000ms 向服务器发一次 Publish 请求收取所有待推送的数据。关键点来了OPCSubscribe返回的不是数据而是一个SubscriptionId如12345。这个 ID 必须保存下来用于后续取消订阅。所以你要做三件事在页面变量里创建一个VFD1_SubscriptionId类型NumberOPCSubscribe的OnSuccess事件里写表达式SetVariable(VFD1_SubscriptionId, result.SubscriptionId)在页面OnUnload事件用户离开页面时里拖一个OPCUnsubscribe命令SessionName填PackLine_VFD_SessionSubscriptionId填VFD1_SubscriptionId。提示如果不取消订阅PLC 侧的 MonitoredItem 会一直占用资源长时间运行后可能导致服务器内存溢出。活字格没有自动清理机制必须由你显式管理。订阅成功后数据会通过OnDataChange事件推送。在OPCSubscribe的OnDataChange里写SetVariable(VFD1_Status, result[0].Value); SetVariable(VFD1_LastUpdate, result[0].SourceTimestamp);这样只要VFD1.Status值一变前端变量就实时更新无需任何轮询。3.6 远程控制OPCCall 命令调用 PLC 方法的完整流程最后是“启动/停止”按钮。拖一个按钮控件点击事件里放OPCCall命令。SessionName填PackLine_VFD_SessionObjectId填VFD1.ControlMethods注意不是VFD1.ControlMethods.StartMethodId填VFD1.ControlMethods.StartArguments留空启动方法通常无参数。为什么ObjectId和MethodId要分开因为 OPC UA 协议要求Call 服务必须指定“对象节点 ID”和“方法节点 ID”二者是父子关系。VFD1.ControlMethods是对象VFD1.ControlMethods.Start是它下面的方法。调用成功后OPCCall返回result.StatusCode: Good。但要注意方法调用成功 ≠ 设备真的启动了。PLC 程序里可能有互锁逻辑比如“只有温度80℃才能启动”此时StatusCode仍是Good但result.OutputArguments[0]可能返回false。所以严谨的做法是在OPCCall的OnSuccess里检查result.OutputArguments[0]如果为false弹窗提示“启动失败温度过高请检查冷却系统”。停止按钮同理只是MethodId换成VFD1.ControlMethods.Stop。3.7 全流程收尾OPCDisconnect 与错误处理的黄金组合页面关闭前必须执行OPCDisconnect。但别简单拖个命令就完事。工业现场最怕“假断开”——命令执行了但 TCP 连接没真正关闭。活字格的OPCDisconnect会主动发送CloseSession请求并等待服务器返回ResponseHeader.ServiceResult Good。更关键的是错误处理。在OPCConnect的OnError事件里我写了这样的逻辑记录详细错误日志含EndpointUrl、SecurityPolicy、ErrorMessage弹窗提示用户“OPC 连接失败请检查网络或联系管理员”启动一个定时器30 秒后自动重试OPCConnect避免用户反复点击若连续 3 次失败切换到备用服务器地址如opc.tcp://192.168.1.101:4840。这套机制让系统具备了基本的容错能力。而OPCDisconnect的OnError事件我只做一件事记录日志。因为断开失败通常不影响业务下次连接时自然会重建。4. 常见问题排查与独家避坑指南那些文档里不会写的细节4.1 连接失败的 5 种典型错误及秒级定位法我把过去三个月客户现场遇到的连接问题按发生频率排序给出精准定位步骤错误信息关键词根本原因定位步骤解决方案No such host is knownDNS 解析失败或 IP 错误1. 在活字格服务器上ping 192.168.1.1002.telnet 192.168.1.100 4840改用 IP 地址检查网络连通性A connection attempt failed端口未开放或防火墙拦截1. 在 PLC 侧用netstat -an | findstr :48402. 临时关闭 Windows 防火墙测试开放 4840 端口配置防火墙规则BadCertificateInvalid证书未导入或过期1. 打开certlm.msc检查证书有效期2. 双击证书看“证书路径”是否完整重新导入证书联系 PLC 工程师更新证书BadUserAccessDenied用户名密码错或匿名访问禁用1. 用 UaExpert 以相同凭据连接2. 检查 TIA Portal 中Allow Anonymous Login核对凭据启用匿名访问BadNotConnected会话已断开但命令仍调用1. 检查OPCDisconnect是否被执行2. 查看OPCGetStatus返回的SessionState确保OPCDisconnect在OnUnload中执行添加会话状态检查实操心得遇到连接问题永远先用 UaExpert 复现。如果 UaExpert 也连不上问题一定在 PLC 或网络层跟活字格无关。这是节省时间的铁律。4.2 数据读取不准的 3 个隐蔽原因读到的值和 PLC HMI 显示不一致别急着怀疑活字格先查这三项原因 1数据类型自动转换陷阱PLC 里FreqSetpoint是REAL类型32 位浮点但活字格OPCRead默认按Double解析可能产生微小误差如50.0读成49.99999999999999。解决方案在OPCRead命令的DataType参数里显式指定Float强制按 32 位解析。原因 2时间戳来源混淆OPCRead返回的SourceTimestamp是 PLC 时间ServerTimestamp是 OPC 服务器时间。如果你用ServerTimestamp做数据对齐会发现和 PLC 日志对不上。务必统一用SourceTimestamp。原因 3采样周期与 PLC 扫描周期冲突S7-1500 的默认扫描周期是 10ms但OPCRead每秒发 10 次请求100ms 间隔可能刚好错过 PLC 更新瞬间。解决方案将OPCRead的Timeout设为500SamplingInterval在OPCSubscribe中设为10让数据推送更贴近 PLC 实时性。4.3 性能优化的 4 个硬核技巧活字格 12.1 的 OPC UA 命令性能很强但用不好会拖垮整个系统技巧 1合并读取减少请求次数别为每个变量单独建OPCRead。把同一批次更新的变量如 VFD1 的 5 个状态放在同一个OPCRead的NodeIds数组里。一次请求 5 个节点比 5 次请求各 1 个节点快 3 倍以上。技巧 2善用缓存避免重复解析OPCBrowse结果可以缓存。在页面OnLoad时执行一次OPCBrowse把结果存入页面变量NodeMap后续所有OPCRead都从NodeMap里取NodeId避免每次都要遍历地址空间。技巧 3动态订阅按需开启不要一进页面就订阅所有节点。用“懒加载”当用户点击某个 VFD 的卡片时再执行OPCSubscribe离开卡片区域时执行OPCUnsubscribe。这样 10 台设备同时在线实际只订阅当前聚焦的 1-2 台。技巧 4错误隔离防止单点崩溃一个OPCRead失败不该导致整个页面卡死。在每个 OPC 命令的OnError里只处理本命令的错误用SetVariable设置一个LastError变量前端用Visible: !IsEmpty(LastError)控制错误提示框显示。这样VFD1 读取失败VFD2 依然正常工作。4.4 安全加固的 2 个必须动作工业系统安全无小事这两个配置必须做动作 1禁用匿名访问生产环境在 TIA Portal 中取消勾选Allow Anonymous Login创建专用 OPC UA 用户如grapecity_ro只读grapecity_rw读写。活字格OPCConnect的UserIdentity填对应凭据。这样即使网络被嗅探攻击者也无法获取数据。动作 2限制会话数量在活字格服务配置文件web.config中找到add keyOPCUA.MaxSessions value10 /根据服务器性能调整。默认 100 个会话对一台 4 核 CPU 的服务器压力过大。我们客户现场设为 20稳定运行半年无异常。5. 场景延伸与能力边界它能做什么不能做什么5.1 能 活字格12.1原生OPC UA客户端命令深度解析
1. 项目概述为什么一个低代码平台要原生支持 OPC UA 客户端命令活字格 12.1 这个版本更新我第一时间下载安装后没急着点开设计器而是先翻了下 release notes 里关于“OPC UA”的那几行字——不是因为多爱看文档而是过去三年里我用活字格做过 7 个工业现场的数据集成项目其中 5 个卡在 OPC UA 接入环节要么靠写 C# 插件硬扛要么拖 Node-RED 做中间桥接再把结果塞进活字格的 Web API。每次交付前都要给客户额外解释“为什么我们的低代码平台不能直接连 PLC”那种心虚感干过工业集成的都懂。这次标题里写的“原生 OPC UA 客户端命令”不是加个按钮、配个地址就叫原生。它意味着活字格运行时也就是你发布的 Web 应用背后那个 .NET Core 服务内置了符合 OPC Foundation 认证的 UA TCP 栈能直接发起 Session、建立 SecureChannel、执行 Read/Write/Call 等标准服务调用全程不依赖外部进程、不走 HTTP 中转、不强制要求 Windows 系统——这点特别关键。很多同行还在用“活字格调用 Python 脚本去连 KEPServerEX”本质上还是两层架构出问题要查三处日志而 12.1 的命令是直接跑在活字格服务进程里的错误堆栈能精准定位到哪一行表达式、哪个节点 ID、哪次超时。我拿手头一个真实产线做测试西门子 S7-1500 TIA Portal V18 配置的 OPC UA 服务器启用匿名访问和 Basic256Sha256 加密。过去用旧版活字格必须在服务器上装 KEPServerEX再配置一个 OPC UA to REST 的通道活字格前端通过 Ajax 轮询那个 REST 接口现在我在活字格设计器里拖一个“OPC UA 读取”命令填入opc.tcp://192.168.1.100:4840点开节点浏览器直接看到Objects Station PLC GlobalDB DB1 Value1这个路径选中后生成绑定表达式{OPCRead(Objects.Station.PLC.GlobalDB.DB1.Value1)}发布后刷新页面数值实时跳动——整个过程从原来平均 3 小时配置调试压缩到 8 分钟内完成。这不是功能“有无”的问题而是架构层级的跃迁低代码平台第一次真正站在了工业通信协议的语义层上而不是在应用层打补丁。所以如果你正面临这些场景这个更新对你价值极大产线 MES 系统需要直连多品牌 PLC西门子、罗克韦尔、倍福但团队里没有专职的 OPC 开发工程师客户明确要求“所有数据链路必须可控、可审计、不引入第三方中间件”你不能再偷偷装 Node-RED项目预算紧张没法为每个接入点单独采购 KEPServerEX 许可证单点授权动辄上万你需要在移动端uniapp 打包的 App里展示实时设备状态但传统方案因跨域或证书问题无法在 iOS 上稳定运行。这 9 个命令不是孤立的功能点它们共同构成了一个完整的 OPC UA 会话生命周期管理能力从连接、发现、读写、方法调用到异常重连、会话保持、批量操作。接下来我会带你逐个拆解不讲抽象概念只说你在设计器里点哪里、输什么、为什么这么输、输错会报什么错——就像我当年带新人时在工控柜旁一边接线一边教的那样。2. 核心设计逻辑与技术选型深挖为什么是这 9 个命令为什么不是 SDK 封装2.1 这 9 个命令的完整清单与设计意图活字格 12.1 并没有把 OPC UA 协议栈全量暴露给用户而是做了非常务实的裁剪。我对照 OPC UA Part 4Services规范和实际工业现场高频需求梳理出这 9 个命令的底层映射关系命令名称对应 OPC UA 服务典型使用场景是否支持异步是否需预建会话OPCConnectCreateSession首次连接服务器获取 SessionId否阻塞否OPCBrowseBrowse查看服务器地址空间结构找节点路径是是OPCReadRead读取单个/多个节点当前值含时间戳、状态码是是OPCWriteWrite写入单个/多个节点值支持类型自动转换是是OPCSubscribeCreateMonitoredItems订阅节点变化实现“推模式”实时更新是是OPCUnsubscribeDeleteMonitoredItems取消订阅释放服务器资源是是OPCCallCall调用服务器端定义的方法如启动/停止设备是是OPCDisconnectCloseSession主动关闭会话清理资源否阻塞是OPCGetStatusGetStatus获取当前会话状态、服务器基本信息是是注意两个关键设计点第一“OPCConnect”和“OPCDisconnect”是唯一两个同步阻塞型命令。这是刻意为之——连接建立失败必须立刻反馈比如证书不信任、端口不通、用户名密码错不能让用户以为“正在连”结果后台静默重试 30 秒才报错。我实测过当输入一个不存在的 IP 地址时OPCConnect在 2.8 秒后抛出System.Net.Sockets.SocketException错误信息里直接包含“No such host is known”比某些国产 OPC 调试软件的“连接超时”提示清晰十倍。第二所有读写类命令Read/Write/Subscribe都强制要求先执行 OPCConnect。这不是为了增加步骤而是 OPC UA 协议本身的强会话约束你不能跳过 Session 创建就直接发 Read 请求。活字格用这种“硬性依赖”倒逼开发者理解协议本质——很多现场问题比如读数始终为 Bad根源就是会话未激活或已过期而不是节点路径写错。2.2 为什么不用封装好的 OPC UA .NET SDK——性能与安全的双重权衡有朋友问“既然 .NET 生态有成熟的Opc.UaFx.Client库活字格为什么不直接封装它” 我专门约了活字格架构师喝了顿茶得到的答案很实在不是不能而是不敢。Opc.UaFx.Client是个优秀的开源库但它默认启用了“自动重连”和“会话保持”机制。在工业现场PLC 重启、网络抖动、防火墙策略变更太常见了。如果活字格底层无脑套用它的自动重连就会出现两种灾难性情况资源泄漏每次重连都新建一个UaTcpSessionChannel而旧 Channel 因未显式关闭TCP 连接处于TIME_WAIT状态。我们一个客户现场曾因此在 72 小时内耗尽了 Windows 服务器的 65535 个端口导致所有新连接失败状态错乱自动重连后旧的 MonitoredItem 订阅关系可能失效但客户端仍按老规则推送数据导致前端显示“设备运行中”而实际 PLC 已停机。活字格的选择是自己实现精简版 UA TCP 栈只保留最核心的 Session/SecureChannel 管理把重连逻辑完全交给开发者控制。比如OPCConnect命令有个关键参数RetryCount默认 0你设成 3它就会在首次失败后间隔 1 秒、2 秒、4 秒各重试一次每次失败都触发OnError事件你可以在此写日志、发告警、切备用服务器地址。这种“可控的脆弱性”远比“不可控的健壮性”更适合工业系统。另一个常被忽略的点是证书信任链处理。Opc.UaFx.Client默认信任所有证书开发方便生产危险而活字格 12.1 强制要求若服务器使用自签名证书必须提前将证书导入活字格服务所在机器的“受信任的根证书颁发机构”存储区。我在测试时故意没导入OPCConnect直接返回BadCertificateInvalid错误并附带证书指纹供你核对——这看似增加了部署步骤实则堵死了生产环境最常被忽视的安全缺口。2.3 与 Node-RED / KEPServerEX 的本质区别谁在承担协议解析工作网上搜“opc ua node-red 实现 opc ua 转 mqtt”结果铺天盖地。但很少有人说清一个事实Node-RED 本身不解析 OPC UA 二进制协议它依赖node-opcua这个 JavaScript 库。而 JS 解析二进制流的性能天然弱于 .NET 原生实现。我做过对比测试同一台 i5-8250U 的工控机用 Node-RED 每秒最多处理 120 个 OPC UA Read 请求换成活字格 12.1 的原生命令轻松跑到 850 QPS测试条件读取 10 个 Int32 节点超时 100ms。更关键的是数据语义保真度。Node-RED 的 OPC UA 节点输出的是 JSON比如一个DateTime类型节点它会转成2024-05-20T08:30:45.123Z字符串而活字格的OPCRead返回的是 .NET 的DateTime对象前端绑定时可直接用{value:yyyy-MM-dd HH:mm:ss}格式化毫秒级精度不丢失。这对需要做时间序列分析的场景比如计算设备单次运行时长至关重要。至于 KEPServerEX它本质是个 OPC UA 服务器代理——你让活字格连 KEPServerEXKEPServerEX 再去连真正的 PLC。多一层转发就多一重故障点KEPServerEX 的许可证到期、License Server 不可达、内部队列积压……而活字格 12.1 是直连只要 PLC 的 OPC UA 服务开着就能通。当然KEPServerEX 的优势在于协议转换比如把 Modbus RTU 设备转成 OPC UA这不属于活字格的职责范围二者是互补而非替代关系。3. 9 个命令全流程实操从零开始搭建一个设备监控页面3.1 环境准备与前置验证别跳过这 3 分钟否则后面全是坑在活字格设计器里新建一个空白页面前请务必完成以下验证。我见过太多人卡在这一步最后发现是基础环境问题第一步确认 OPC UA 服务器已就绪不要依赖“PLC 程序已下载”这个说法。打开任意 OPC UA 调试软件推荐免费的 UaExpert输入服务器地址opc.tcp://192.168.1.100:4840点击连接。成功后在地址空间树里展开Objects→Station你应该能看到类似PLC_1或Controller的子节点。如果连不上优先检查PLC 防火墙是否放行 4840 端口西门子默认是 4840罗克韦尔可能是 49320TIA Portal 中 OPC UA 服务器是否启用Options Settings OPC UA Server Enable用户权限是否正确匿名访问需勾选Allow Anonymous Login否则OPCConnect会报BadUserAccessDenied。第二步验证活字格服务账户权限活字格 Web 应用默认以IIS APPPOOL\GrapeCity身份运行。这个账户必须有权限读取本地证书存储区。打开服务器上的certlm.msc本地计算机证书管理器展开受信任的根证书颁发机构 证书确认你的 OPC UA 服务器证书或其 CA 证书已在此处。如果没有右键证书 →所有任务 导入选择“本地计算机”并勾选“将此证书放入下列存储区” →受信任的根证书颁发机构。提示如果服务器用的是公共 CA 签发的证书如 Lets Encrypt这步可跳过。但工业现场 95% 以上都是自签名证书务必手动导入。第三步设计器插件检查打开活字格设计器 →帮助 关于确认版本号是12.1.xxx。然后进入工具 选项 扩展查看OPC UA Client Commands是否已启用。如果灰色不可选说明安装包未包含该模块——请重新下载完整版安装包官网下载页明确标注“含工业协议扩展”。完成这三步后你才算真正站在了起跑线上。接下来的所有操作我都基于一个真实案例监控一条包装线的 3 台变频器VFD1/VFD2/VFD3实时显示运行状态、频率设定值、当前输出频率并提供“启动/停止”按钮。3.2 第一个命令OPCConnect —— 建立会话的 5 个必填参数详解在页面设计器中点击左侧工具箱的命令分类找到OPCConnect命令拖到画布上。双击打开属性面板你会看到 7 个参数但真正必须填的只有 5 个EndpointUrl必填格式必须是opc.tcp://IP:Port不能带路径、不能加/、不能用主机名除非 DNS 解析已配置。例如opc.tcp://192.168.1.100:4840。我曾因填了opc.tcp://vfd-server.local:4840导致连接失败查日志才发现 DNS 解析超时——工业现场请一律用 IP。SecurityPolicy必填下拉菜单有None、Basic128Rsa15、Basic256、Basic256Sha256。这必须和 PLC 服务器配置严格一致。西门子 TIA Portal V18 默认是Basic256Sha256罗克韦尔 Studio 5000 默认是Basic256。填错会直接报BadSecurityPolicyRejected。不确定时先用 UaExpert 连一次看连接详情里的 Security Policy 字段。UserIdentity可选但强烈建议填类型是OPCUserIdentity对象。即使服务器允许匿名也建议填一个空对象{}避免某些固件版本的兼容性问题。如果需要认证填{ Type: UserName, UserName: admin, Password: 123456 }注意密码明文存储有风险生产环境应结合活字格的“加密参数”功能将密码存在配置文件中。SessionName必填这是你在活字格里给这个会话起的名字用于后续所有命令引用。必须全局唯一建议用业务含义命名如PackLine_VFD_Session。别用Session1这种后期维护会疯。Timeout必填单位毫秒默认 1000010 秒。别贪大工业现场网络延迟波动大设成 30000 反而会让前端卡住。我的经验是局域网设 3000跨 VLAN 设 5000有防火墙策略的设 8000。其他两个参数RetryCount设 2 即可配合RetryDelay默认 1000ms形成指数退避KeepAliveInterval默认 10000ms即每 10 秒发一次心跳包维持会话。PLC 侧通常要求 30 秒内有心跳这个值足够安全。配置完点击测试命令。如果返回Success: Connected to opc.tcp://192.168.1.100:4840说明会话建立成功。此时你可以在设计器的变量面板里看到一个名为PackLine_VFD_Session的会话变量类型是OPCSession——这就是后续所有命令的操作手柄。3.3 发现节点OPCBrowse 命令的三层递进式探索法会话建好了但你还不知道要读哪个节点。OPCBrowse就是你的“探照灯”。拖一个OPCBrowse命令到画布设置SessionName为PackLine_VFD_Session其他参数留空点击测试。返回结果是一个 JSON 数组类似[ {NodeId:ns2;i5,DisplayName:VFD1,NodeClass:Object}, {NodeId:ns2;i6,DisplayName:VFD2,NodeClass:Object}, {NodeId:ns2;i7,DisplayName:VFD3,NodeClass:Object} ]这里的关键是理解NodeId的语法ns2;i5表示命名空间索引 2整数节点 ID 5。不同 PLC 命名空间不同西门子通常是ns2罗克韦尔是ns3。DisplayName是你在 TIA Portal 里给对象起的名字这才是你该记住的。但光有顶层对象不够得往下钻。OPCBrowse支持BrowseDirection参数设为Forward默认ReferenceTypeId设为Organizes固定值i35NodeId填ns2;i5即 VFD1 的 ID再测试。这次返回[ {NodeId:ns2;i101,DisplayName:Status,NodeClass:Variable}, {NodeId:ns2;i102,DisplayName:FreqSetpoint,NodeClass:Variable}, {NodeId:ns2;i103,DisplayName:FreqOutput,NodeClass:Variable}, {NodeId:ns2;i104,DisplayName:ControlMethods,NodeClass:Object} ]看到ControlMethods是个 Object说明里面有可调用的方法。再对它Browse一次NodeId填ns2;i104ReferenceTypeId仍为i35返回[ {NodeId:ns2;i201,DisplayName:Start,NodeClass:Method}, {NodeId:ns2;i202,DisplayName:Stop,NodeClass:Method} ]至此你拿到了完整路径状态变量VFD1.Status→ns2;i101启动方法VFD1.ControlMethods.Start→ns2;i201注意OPCBrowse返回的NodeId是二进制协议里的原始 ID而活字格命令支持更友好的“路径式”写法。你完全可以不用记ns2;i101直接在OPCRead命令里写VFD1.Status活字格会在运行时自动解析。但建议你第一次用OPCBrowse把路径摸清楚避免拼写错误。3.4 实时读取OPCRead 命令的 3 种用法与性能陷阱现在可以读数据了。拖一个OPCRead命令SessionName填PackLine_VFD_SessionNodeIds参数填一个数组[VFD1.Status, VFD1.FreqSetpoint, VFD1.FreqOutput]点击测试返回[ {NodeId:VFD1.Status,Value:1,StatusCode:Good,SourceTimestamp:2024-05-20T08:30:45.123Z}, {NodeId:VFD1.FreqSetpoint,Value:50.0,StatusCode:Good,SourceTimestamp:2024-05-20T08:30:45.124Z}, {NodeId:VFD1.FreqOutput,Value:49.8,StatusCode:Good,SourceTimestamp:2024-05-20T08:30:45.125Z} ]Value字段就是你要的值StatusCode是 OPC UA 的状态码Good表示正常SourceTimestamp是 PLC 侧的时间戳比活字格服务器时间更可信。但这里有个巨大陷阱别在页面加载时一次性读 100 个节点OPC UA 协议规定单次 Read 请求最多携带 100 个节点但实际性能取决于 PLC 处理能力。我测试过一台 S7-1200当NodeIds数组超过 15 个时响应时间从 15ms 暴涨到 220ms。解决方案是分组组 1高频监控Status,FreqOutput,AlarmCode每 1 秒读一次组 2低频配置MaxFreq,AccelTime,DecelTime每 30 秒读一次组 3事件驱动只在用户点击“刷新参数”按钮时读在活字格里这通过定时器命令 不同的OPCRead实例实现。每个OPCRead命令独立配置NodeIds和Timeout互不影响。另外OPCRead支持AttributeId参数默认是Value读值也可设为DataType读数据类型、Description读描述。比如你想确认VFD1.Status确实是Int32类型可以单独发一个AttributeId: DataType的请求返回i6对应 Int32避免前端类型转换出错。3.5 实时推送OPCSubscribe 命令的订阅-取消订阅闭环轮询Polling适合低频数据但对状态变化如设备启停必须用订阅Subscription。OPCSubscribe是活字格 12.1 最惊艳的设计——它让低代码平台第一次拥有了真正的“推”能力。拖一个OPCSubscribe命令SessionName填PackLine_VFD_SessionNodeIds填[VFD1.Status]PublishingInterval设为1000毫秒SamplingInterval设为100毫秒。这意味着服务器每 100ms 检查一次VFD1.Status值只要变化就立即上报活字格客户端每 1000ms 向服务器发一次 Publish 请求收取所有待推送的数据。关键点来了OPCSubscribe返回的不是数据而是一个SubscriptionId如12345。这个 ID 必须保存下来用于后续取消订阅。所以你要做三件事在页面变量里创建一个VFD1_SubscriptionId类型NumberOPCSubscribe的OnSuccess事件里写表达式SetVariable(VFD1_SubscriptionId, result.SubscriptionId)在页面OnUnload事件用户离开页面时里拖一个OPCUnsubscribe命令SessionName填PackLine_VFD_SessionSubscriptionId填VFD1_SubscriptionId。提示如果不取消订阅PLC 侧的 MonitoredItem 会一直占用资源长时间运行后可能导致服务器内存溢出。活字格没有自动清理机制必须由你显式管理。订阅成功后数据会通过OnDataChange事件推送。在OPCSubscribe的OnDataChange里写SetVariable(VFD1_Status, result[0].Value); SetVariable(VFD1_LastUpdate, result[0].SourceTimestamp);这样只要VFD1.Status值一变前端变量就实时更新无需任何轮询。3.6 远程控制OPCCall 命令调用 PLC 方法的完整流程最后是“启动/停止”按钮。拖一个按钮控件点击事件里放OPCCall命令。SessionName填PackLine_VFD_SessionObjectId填VFD1.ControlMethods注意不是VFD1.ControlMethods.StartMethodId填VFD1.ControlMethods.StartArguments留空启动方法通常无参数。为什么ObjectId和MethodId要分开因为 OPC UA 协议要求Call 服务必须指定“对象节点 ID”和“方法节点 ID”二者是父子关系。VFD1.ControlMethods是对象VFD1.ControlMethods.Start是它下面的方法。调用成功后OPCCall返回result.StatusCode: Good。但要注意方法调用成功 ≠ 设备真的启动了。PLC 程序里可能有互锁逻辑比如“只有温度80℃才能启动”此时StatusCode仍是Good但result.OutputArguments[0]可能返回false。所以严谨的做法是在OPCCall的OnSuccess里检查result.OutputArguments[0]如果为false弹窗提示“启动失败温度过高请检查冷却系统”。停止按钮同理只是MethodId换成VFD1.ControlMethods.Stop。3.7 全流程收尾OPCDisconnect 与错误处理的黄金组合页面关闭前必须执行OPCDisconnect。但别简单拖个命令就完事。工业现场最怕“假断开”——命令执行了但 TCP 连接没真正关闭。活字格的OPCDisconnect会主动发送CloseSession请求并等待服务器返回ResponseHeader.ServiceResult Good。更关键的是错误处理。在OPCConnect的OnError事件里我写了这样的逻辑记录详细错误日志含EndpointUrl、SecurityPolicy、ErrorMessage弹窗提示用户“OPC 连接失败请检查网络或联系管理员”启动一个定时器30 秒后自动重试OPCConnect避免用户反复点击若连续 3 次失败切换到备用服务器地址如opc.tcp://192.168.1.101:4840。这套机制让系统具备了基本的容错能力。而OPCDisconnect的OnError事件我只做一件事记录日志。因为断开失败通常不影响业务下次连接时自然会重建。4. 常见问题排查与独家避坑指南那些文档里不会写的细节4.1 连接失败的 5 种典型错误及秒级定位法我把过去三个月客户现场遇到的连接问题按发生频率排序给出精准定位步骤错误信息关键词根本原因定位步骤解决方案No such host is knownDNS 解析失败或 IP 错误1. 在活字格服务器上ping 192.168.1.1002.telnet 192.168.1.100 4840改用 IP 地址检查网络连通性A connection attempt failed端口未开放或防火墙拦截1. 在 PLC 侧用netstat -an | findstr :48402. 临时关闭 Windows 防火墙测试开放 4840 端口配置防火墙规则BadCertificateInvalid证书未导入或过期1. 打开certlm.msc检查证书有效期2. 双击证书看“证书路径”是否完整重新导入证书联系 PLC 工程师更新证书BadUserAccessDenied用户名密码错或匿名访问禁用1. 用 UaExpert 以相同凭据连接2. 检查 TIA Portal 中Allow Anonymous Login核对凭据启用匿名访问BadNotConnected会话已断开但命令仍调用1. 检查OPCDisconnect是否被执行2. 查看OPCGetStatus返回的SessionState确保OPCDisconnect在OnUnload中执行添加会话状态检查实操心得遇到连接问题永远先用 UaExpert 复现。如果 UaExpert 也连不上问题一定在 PLC 或网络层跟活字格无关。这是节省时间的铁律。4.2 数据读取不准的 3 个隐蔽原因读到的值和 PLC HMI 显示不一致别急着怀疑活字格先查这三项原因 1数据类型自动转换陷阱PLC 里FreqSetpoint是REAL类型32 位浮点但活字格OPCRead默认按Double解析可能产生微小误差如50.0读成49.99999999999999。解决方案在OPCRead命令的DataType参数里显式指定Float强制按 32 位解析。原因 2时间戳来源混淆OPCRead返回的SourceTimestamp是 PLC 时间ServerTimestamp是 OPC 服务器时间。如果你用ServerTimestamp做数据对齐会发现和 PLC 日志对不上。务必统一用SourceTimestamp。原因 3采样周期与 PLC 扫描周期冲突S7-1500 的默认扫描周期是 10ms但OPCRead每秒发 10 次请求100ms 间隔可能刚好错过 PLC 更新瞬间。解决方案将OPCRead的Timeout设为500SamplingInterval在OPCSubscribe中设为10让数据推送更贴近 PLC 实时性。4.3 性能优化的 4 个硬核技巧活字格 12.1 的 OPC UA 命令性能很强但用不好会拖垮整个系统技巧 1合并读取减少请求次数别为每个变量单独建OPCRead。把同一批次更新的变量如 VFD1 的 5 个状态放在同一个OPCRead的NodeIds数组里。一次请求 5 个节点比 5 次请求各 1 个节点快 3 倍以上。技巧 2善用缓存避免重复解析OPCBrowse结果可以缓存。在页面OnLoad时执行一次OPCBrowse把结果存入页面变量NodeMap后续所有OPCRead都从NodeMap里取NodeId避免每次都要遍历地址空间。技巧 3动态订阅按需开启不要一进页面就订阅所有节点。用“懒加载”当用户点击某个 VFD 的卡片时再执行OPCSubscribe离开卡片区域时执行OPCUnsubscribe。这样 10 台设备同时在线实际只订阅当前聚焦的 1-2 台。技巧 4错误隔离防止单点崩溃一个OPCRead失败不该导致整个页面卡死。在每个 OPC 命令的OnError里只处理本命令的错误用SetVariable设置一个LastError变量前端用Visible: !IsEmpty(LastError)控制错误提示框显示。这样VFD1 读取失败VFD2 依然正常工作。4.4 安全加固的 2 个必须动作工业系统安全无小事这两个配置必须做动作 1禁用匿名访问生产环境在 TIA Portal 中取消勾选Allow Anonymous Login创建专用 OPC UA 用户如grapecity_ro只读grapecity_rw读写。活字格OPCConnect的UserIdentity填对应凭据。这样即使网络被嗅探攻击者也无法获取数据。动作 2限制会话数量在活字格服务配置文件web.config中找到add keyOPCUA.MaxSessions value10 /根据服务器性能调整。默认 100 个会话对一台 4 核 CPU 的服务器压力过大。我们客户现场设为 20稳定运行半年无异常。5. 场景延伸与能力边界它能做什么不能做什么5.1 能