★ FEATURED ARTICLE 1. 从 ICD 到 CID变电站 SCL 文件链路到底在做什么如果你刚接手一个 IEC 61850 变电站项目最先撞上的不是 GOOSE 报文而是一堆后缀名ICD、SCD、CID、IID。它们都属于 SCLSubstation Configuration description Language也就是 IEC 61850-6 定义的 XML 配置描述语言。SCL 不是某一种具体文件而是一整套文件体系ICD、SCD、CID 只是它在不同工程阶段的不同用途载体。简单说ICD 是设备厂家交出的“能力清单”描述这台 IED 能提供哪些逻辑设备、逻辑节点、数据对象、数据集、报告控制块、GOOSE 能力SCD 是系统集成商把全站 ICD 导入系统配置工具后配置好 IED 名称、网络地址、报告、GOOSE 等形成的“全站最终配置”CID 则是从 SCD 中导出、下发给某一台具体 IED 的“单机最终配置”。链路就是ICD → 作为系统配置输入 → SCD → 保存全站最终配置 → CID → 下发给具体 IED。这条链路里最容易出问题的不是语法而是“配置遗漏”某个遥信没进数据集、某个报告控制块没使能、GOOSE 订阅地址对不上。传统做法靠人工比对 XML几百个点位根本看不过来。这篇就按真实工程流程拆一遍给出可复制的 SCL 模板片段、CID 生成命令、校验脚本并演示用 TaoToken 统一 Key 调用 API 做批量文件比对把“配置无遗漏”这件事从人眼检查变成脚本检查。适合谁看继保调试人员、系统集成商、BMS/PCS/电表等设备厂家的嵌入式工程师以及需要把 libiec61850 跑起来的开发者。你不需要先精通 XML Schema跟着步骤走就能把一条最小链路跑通。2. 前置准备TaoToken 统一 Key 与 SCL 工具链在动手之前先把两件事准备好一是本地 SCL 工具链二是用于批量比对的 API Key。工具链方面系统配置工具各家不同但底层都绕不开 libiec61850 提供的 genmodel.jar它能把 ICD 或 CID 解析成 static_model.c / static_model.h。你至少需要 JDK 8 以上以及一个能打开 XML 的编辑器。API Key 这块我用 TaoToken 的统一 Key 来调用模型接口做文件比对。原因是工程现场经常要批量比对几十个 CID本地写 diff 脚本只能比文本比不了“语义上这个 LN 的 DataSet 是否少了一个成员”。用模型接口可以把两份 SCL 的关键结构抽出来做语义级对照。获取 Key 的入口在控制台登录后创建即可控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteAPI Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteAPI 基地址是https://taotoken.net/api注意这个地址不带 UTM 参数直接用于代码里的 Base URL。模型 ID 按你实际开通的填下面示例里我用一个通用对话模型 ID 占位你替换成自己控制台里看到的即可。三件套记牢Base URL、Key、Model ID缺一个请求就报错。注意API Key 只放在环境变量或本地配置文件里不要写进要下发给现场设备的 CID也不要提交到 Git。工程文件里混入密钥是常见事故。工具链检查命令先确认 Java 可用java -version # 期望输出类似 openjdk version 1.8.0_xxx 或更高把 genmodel.jar 放到工作目录后面生成模型文件要用。目录建议这样组织避免 ICD、SCD、CID 混在一起project/ ├── icd/ # 厂家原始 ICD ├── scd/ # 集成后的全站 SCD ├── cid/ # 导出的单机 CID ├── model/ # genmodel 生成的 c/h └── tools/ # 校验脚本3. 可复制配置SCL 模板片段与 CID 生成命令先看一个最小可用的 ICD 模板片段。它描述一台 BMS 设备包含一个逻辑设备、一个 LLN0、一个测量逻辑节点以及一个数据集和一个报告控制块。你可以直接存成icd/VRFB_BMS.icd再改?xml version1.0 encodingUTF-8? SCL xmlnshttp://www.iec.ch/61850/2003/SCL version2007 revisionB Header idVRFB_BMS version1.0 revision1/ IED nameTEMPLATE manufacturerYourCo typeBMS configVersion1.0 AccessPoint nameS1 Server LDevice instBMS LN0 lnClassLLN0 inst lnTypeLLN0_BMS DataSet namedsMeas FCDA ldInstBMS prefix lnClassMMXU lnInst1 doNameTotW fcMX/ FCDA ldInstBMS prefix lnClassMMXU lnInst1 doNameTotVAr fcMX/ /DataSet ReportControl nameurcbMeas datSetdsMeas rptIDBMS01/LLN0$RP$urcbMeas confRev1 bufferedfalse TrgOps dchgtrue qchgtrue dupdfalse periodfalse gitrue/ OptFields seqNumtrue timeStamptrue reasonCodetrue dataSettrue/ RptEnabled max1/ /ReportControl /LN0 LN lnClassMMXU inst1 lnTypeMMXU_BMS/ /LDevice /Server /AccessPoint /IED DataTypeTemplates LNodeType idLLN0_BMS lnClassLLN0 DO nameMod typeINC_Mod/ DO nameBeh typeINS_Beh/ /LNodeType LNodeType idMMXU_BMS lnClassMMXU DO nameTotW typeMV_TotW/ DO nameTotVAr typeMV_TotVAr/ /LNodeType DOType idMV_TotW cdcMV DA namemag bTypeStruct typeAnalogueValue fcMX/ DA nameq bTypeQuality fcMX/ DA namet bTypeTimestamp fcMX/ /DOType DOType idMV_TotVAr cdcMV DA namemag bTypeStruct typeAnalogueValue fcMX/ DA nameq bTypeQuality fcMX/ DA namet bTypeTimestamp fcMX/ /DOType DOType idINC_Mod cdcINC DA namestVal bTypeEnum typeMod fcST/ DA nameq bTypeQuality fcST/ DA namet bTypeTimestamp fcST/ /DOType DOType idINS_Beh cdcINS DA namestVal bTypeEnum typeBeh fcST/ DA nameq bTypeQuality fcST/ DA namet bTypeTimestamp fcST/ /DOType DAType idAnalogueValue BDA namef bTypeFLOAT32/ /DAType EnumType idMod EnumVal ord1on/EnumVal EnumVal ord2blocked/EnumVal EnumVal ord3test/EnumVal EnumVal ord4off/EnumVal /EnumType EnumType idBeh EnumVal ord1on/EnumVal EnumVal ord2blocked/EnumVal EnumVal ord3test/EnumVal EnumVal ord4off/EnumVal /EnumType /DataTypeTemplates /SCL这个模板的关键点FCDA里的doName必须和LNodeType里定义的 DO 名一致fc要和 DOType 里 DA 的 fc 对得上。很多“数据集为空”的报错根源就是这里对不上。集成商把多个 ICD 导入系统配置工具后配置 IED 名称、网络、报告、GOOSE导出station.scd。从 SCD 导出单机 CID 时不同工具命令不同但本质是“按 IED name 过滤”。如果你用脚本化方式可以用 XSLT 或 Python 的 lxml 按 IED 节点抽取。下面是一个用 Python 从 SCD 抽 CID 的可复制片段from lxml import etree NS {scl: http://www.iec.ch/61850/2003/SCL} def export_cid(scd_path, ied_name, out_path): tree etree.parse(scd_path) root tree.getroot() # 找到目标 IED target root.xpath(f//scl:IED[name{ied_name}], namespacesNS) if not target: raise SystemExit(fIED {ied_name} not found in SCD) # 构造只含该 IED 的 CID 树 cid etree.Element(root.tag, nsmaproot.nsmap) header root.find(scl:Header, NS) if header is not None: cid.append(header) cid.append(target[0]) dtt root.find(scl:DataTypeTemplates, NS) if dtt is not None: cid.append(dtt) etree.ElementTree(cid).write(out_path, encodingUTF-8, xml_declarationTrue, pretty_printTrue) if __name__ __main__: export_cid(scd/station.scd, BMS01, cid/BMS01.cid)生成 CID 后用 genmodel.jar 解析验证模型能被 libiec61850 识别java -jar tools/genmodel.jar cid/BMS01.cid # 生成 static_model.c 和 static_model.h如果这一步报SCL parse error先别急着改 CID回到 SCD 检查对应 IED 的 DataTypeTemplates 是否完整。4. 验证请求用统一 Key 批量比对 SCL 文件单机验证通过后真正的痛点是“全站几十台 IED怎么确认每台 CID 和 SCD 里的配置一致、没有遗漏”。人工 diff 只能比文本比不了语义。这里用 TaoToken 的 API 做批量比对把 SCD 中该 IED 的期望结构抽出来和 CID 实际结构一起发给模型让它输出差异清单。先设置环境变量三件套齐全export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_MODEL你的模型ID然后写一个比对脚本核心是把两份 SCL 的关键结构LDevice、LN、DataSet、ReportControl、GOOSE抽成精简 JSON再调用接口import os, json, requests from lxml import etree NS {scl: http://www.iec.ch/61850/2003/SCL} BASE os.environ[TAOTOKEN_BASE_URL] KEY os.environ[TAOTOKEN_API_KEY] MODEL os.environ[TAOTOKEN_MODEL] def extract_structure(scl_path, ied_nameNone): root etree.parse(scl_path).getroot() ieds root.xpath(//scl:IED, namespacesNS) result {} for ied in ieds: name ied.get(name) if ied_name and name ! ied_name: continue ldevs [] for ld in ied.xpath(.//scl:LDevice, namespacesNS): lns [ln.get(lnClass) ln.get(inst, ) for ln in ld.xpath(.//scl:LN, namespacesNS)] datasets [ds.get(name) for ds in ld.xpath(.//scl:DataSet, namespacesNS)] rpts [rc.get(name) for rc in ld.xpath(.//scl:ReportControl, namespacesNS)] ldevs.append({inst: ld.get(inst), lns: lns, datasets: datasets, reports: rpts}) result[name] ldevs return result def compare_with_api(expected, actual): prompt ( 你是 IEC 61850 SCL 配置比对助手。下面是 SCD 中期望的结构和 CID 中 实际的结构请找出 CID 相对 SCD 缺失或多余的 LDevice、LN、DataSet、 ReportControl用简洁列表输出不要解释。\n\n f期望(SCD):\n{json.dumps(expected, ensure_asciiFalse)}\n\n f实际(CID):\n{json.dumps(actual, ensure_asciiFalse)} ) resp requests.post( f{BASE}/v1/chat/completions, headers{Authorization: fBearer {KEY}, Content-Type: application/json}, json{model: MODEL, messages: [{role: user, content: prompt}], temperature: 0}, timeout60, ) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: scd extract_structure(scd/station.scd, BMS01) cid extract_structure(cid/BMS01.cid, BMS01) print(compare_with_api(scd, cid))成功时你会看到类似输出CID 相对 SCD 缺失 - LDevice BMS 下 DataSet dsMeas 缺少成员 MMXU1.TotVAr - ReportControl urcbMeas 的 TrgOps 缺少 qchg CID 相对 SCD 多余 - 无这就是“配置无遗漏”的脚本化验证。批量场景下把 IED 名称列表循环一遍即可。模型对话入口在这里想先手动试一条请求可以用它模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite如果你要长期跑这类批量校验、甚至接进 CI用 Coding Plan 更划算额度按编码场景走Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite5. 本篇常见错排查401、local proxy failed、reading choices、OAuth现场跑脚本时报错基本集中在几类。下面按真实报错对照排查。401 Unauthorized最常见。原因通常是 Key 没读到、Key 失效、或 Base URL 写错。检查echo $TAOTOKEN_API_KEY是否有值Base URL 必须是https://taotoken.net/api不要多加/v1之外的路径。如果你把 Key 写进代码又提交了去控制台重新生成一个。local proxy failed / connection refused这类报错说明请求根本没出去通常是本机网络配置或环境变量里残留了代理设置。检查env | grep -i proxy把不需要的代理变量清掉再试。注意不要用任何非正规网络手段工程现场应走合规网络。reading choices / KeyError choices说明响应体里没有choices字段多半是接口返回了错误 JSON而脚本直接取字段。修复方式是先打印resp.status_code和resp.text确认错误信息。常见触发是 Model ID 填错或请求体里model字段为空。OAuth / authentication failed如果你用的是需要 OAuth 的客户端比如某些 IDE 插件或 Claude Code 类工具要确认认证方式选的是 API Key 而不是 OAuth。三件套必须写全Base URL、Key、Model ID。以 Claude Code 接入为例配置文件里要同时给出这三项缺 Model ID 会直接认证失败。接入文档在这里接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteSCL parse errorgenmodel 报错不是 API 问题是 XML 本身。检查命名空间是否为http://www.iec.ch/61850/2003/SCLDataTypeTemplates里引用的 type 是否都存在。用xmllint --noout cid/BMS01.cid先做语法校验。CID 导出后模型为空多半是 XPath 抽取时漏了DataTypeTemplates或者 IED name 大小写不匹配。SCL 里 IED name 区分大小写BMS01和bms01是两个东西。排查顺序建议先xmllint验语法再genmodel验模型最后才调 API 比对。前面两步过了API 报错基本就是 Key 和 Model ID 的问题。6. 把校验接进工程流程从一次性脚本到可复用工具跑通一次比对不算完工程上要的是每次 SCD 更新后都能自动校验。我的做法是把上面三段脚本合成一个scl_check.py接受--scd、--cid-dir、--ied-list三个参数输出一份 Markdown 报告。这样每次集成商更新 SCD你只要重跑一次就能拿到所有 IED 的差异清单。一个实用技巧把 SCD 的哈希值和校验报告一起存档。下次现场出问题先比对哈希确认下发的 CID 是不是从当前 SCD 导出的。很多“配置对不上”的扯皮最后发现是拿旧 CID 下发了。另一个坑是 GOOSE 配置。上面的比对脚本只抽了 LDevice、LN、DataSet、ReportControlGOOSE 的GSEControl和GSE通信参数要单独抽因为 GOOSE 的appID、macAddress、vlanId在 SCD 和 CID 里必须完全一致否则订阅方收不到。建议在extract_structure里加一段gse [{name: g.get(name), appID: g.get(appID), datSet: g.get(datSet)} for g in ld.xpath(.//scl:GSEControl, namespacesNS)]把 gse 一起塞进比对 JSON模型就能告诉你哪台设备的 GOOSE 控制块少了或 appID 变了。最后如果你要把这套流程交给团队里不写代码的继保人员用可以包一层命令行把 API Key 从环境变量读报告输出成表格。他们只需要改 IED 列表不用碰 Python。这样 ICD → SCD → CID 的链路校验就从“专家手工活”变成了“每次集成后跑一下”的常规动作。
阅读完成 · 觉得有帮助？
