简介Q/CSG 110017.12-2012是中国南方电网一体化电网运行智能系统技术规范第1部分第2篇面向电网调度、自动化、二次系统设计与运维人员针对二次系统种类繁杂、运行信息割裂、缺乏统一建设与运行标准等痛点给出标准化的术语与定义框架。该篇属于系列标准总则分册系统梳理了8部分共72篇的整体体系并围绕架构、数据、平台、主站应用、厂站应用、配置、验收等环节定义关键术语为各篇落地执行提供公共语言基础。文档内容包含范围、标准参考、术语和定义等正式条款同时还附有标准体系结构表便于读者从全局理解南方电网一体化电网运行智能系统的组成与相互关系。压缩包内共1个doc文档包体大小约211KB适合直接查阅原文。目前已有324人学习下载可供智能电网标准化建设、主站与厂站系统集成、科研教学及工程实践人员参考使用。1. 被 91 个术语卡住的项目这本南方电网 OS2 术语篇为什么值得先读做智能电网二次系统集成这行最怕的不是算法难而是对不上号。你在标书里写「程序化操作」设计院图纸上叫「顺序控制」厂家说明书里叫「顺控」验收专家手里拿的是 Q/CSG 110017.12-2012一场澄清会下来才发现三方说的是同一个功能。这份规范是南方电网一体化电网运行智能系统行业里常说的 OS2系列标准的第 1 部分第 2 篇正式名称叫《总则术语和定义》正文收录了 91 条术语覆盖系统架构、厂站装置、数据通信、测试验收到容灾备份。它不是为了应付考试才存在的项目招标、方案评审、设计联络、出厂验收每一轮都需要它来统一口径。适合正在做新建或技改项目技术文件、写功能规范、准备验收材料的人放到桌面第一屏。2. 先看懂它的位置72 篇标准体系里的「共同语言层」2.1 八部分 72 篇的体系结构这篇在第 1 部分里扮演什么角色这份术语篇所属的系列标准体系非常庞大。前言里写得很清楚之所以要建这套标准是因为二次系统种类繁杂、运行信息割裂、缺乏统一的建设和运行标准。为了把「一体化电网运行智能系统」的建设和运行做成标准化动作南方电网把整套标准拆成了 8 个部分、共 72 篇覆盖从总则、架构、数据、平台到主站应用、厂站应用、配置、验收的全生命周期。部分内容篇数第 1 部分总则标准体系基本描述、术语与定义2第 2 部分架构系统总体、主站、厂站架构原则3第 3 部分数据数据源、数据架构、IEC 61850 实施、公共信息模型、命名编码、SVG 图形、数据交换12第 4 部分平台主站/厂站平台、OSB 总线、安全防护、容灾备用6第 5 部分主站应用数据中心、监视中心、控制中心、管理中心、运行驾驶舱等功能规范26第 6 部分厂站应用厂站各中心、智能远动机、装置功能及接口15第 7 部分配置主站/厂站配置、二次接线、辅助设施6第 8 部分验收主站和厂站验收技术管理要求2这篇 Q/CSG 110017.12-2012 是第 1 部分的第 2 篇。第 1 篇《基本描述》讲标准体系本身长什么样第 2 篇就是给整个体系做「术语定标」。后面 70 篇规范里出现的每一个专业名词默认都以这篇的定义为准。换句话说如果第 3 部分的 IEC 61850 实施规范里出现「合并单元」你回这篇查定义第 5 部分驾驶舱功能规范里出现「KPI」也回这篇查定义。它是一份全局字典而不是单独的技术方案。这里还有一个很实用的细节标准编号本身带了「位置信息」。Q/CSG 110017.12-2012 编号里的「12」表示第 1 部分第 2 篇同理Q/CSG 110017.21-2012 是第 2 部分第 1 篇总体架构Q/CSG 110017.52.1-2012 是第 5 部分第 2.1 篇智能监视中心稳态监视类功能规范。拿到一个编号扫一眼小数点后的数字就能判断它是平台、数据、主站应用还是厂站应用。做招标文件索引和档案管理时这个规则比文件名好使得多。2.2 术语表的使用时机招标、澄清、验收三处最容易被考这份术语篇不是拿来通读的而是按场景查的。我自己的使用习惯是四个触发点。第一是编写可研报告和技术规范书阶段。项目范围里涉及程序化操作、一体化测控装置、智能远动机这类名词时先回术语篇确认标准叫法。可研阶段能统一术语后面设计联络会大概率不会再出现「同一个功能三种叫法」的局面。第二是招标答疑和澄清阶段。投标人问「厂站数据是否要求支持插值法同步」这句话里的插值法定义就出自 3.12 条。注意它的定义是电子式互感器各自独立采样、以固定延时发送至 MU、MU 以本地时钟为基准补偿延时后重采样实现同步且明确写了「不依赖全站同步时钟源」。这个定义直接关系到要不要配同步时钟、时钟坏了数据还能不能用。答标时照这个口径写评审专家挑不出毛病。第三是设计联络会和接口方案评审。涉及 GOOSE 跳合闸信号传输、SCD/CID/IID 文件流转、OSB 服务注册发布时术语篇提供了通信层面的统一说法。比如「订阅/发布」定义为消息范式发布者不关心订阅者是谁订阅者只接收感兴趣的消息。你把这块用在自己系统的事件总线上评审时引用标准定义会显得方案有出处。第四是出厂验收和现场验收。验收环节最容易暴露术语分歧分歧集中在差异分类。标准把系统测试发现的问题分成偏差、缺陷、工程化问题、改进要求几类每类处置路径完全不同这个我在第 5 章展开。2.3 引用标准之间的关系IEC 61970、61850、61968 不是摆设术语篇第 2 章列了四份引用文件IEC 60050 国际电工技术词汇表、DL 890/IEC 61970 能量管理系统应用程序接口、DL 860/IEC 61850 变电站通信网络和系统、DL 1080/IEC 61968 电力企业应用集成配电管理的系统接口。这里有个容易被忽略的技术细节标准里区分了「注日期引用」和「不注日期引用」。凡是注日期的引用文件以后的修改单不含勘误不自动适用不注日期的引用文件最新版本自动适用。做合同附件时我一般这样处理合同正文里引用术语篇术语篇里的 IEC 61850 相关条款注明以当时有效版本为准同时留一句「如标准修订双方协商确定过渡期」避免设备生命周期内标准换版导致验收口径漂移。在实际项目中这三份 IEC 标准各有各的用途。IEC 61970EMS-API管主站侧的能量管理系统接口CIM 公共信息模型的源头在它那IEC 61850 管厂站侧的变电站通信网络和系统SCD、GOOSE、合并单元这些词全是从它延伸出来的IEC 61968 管配电管理系统的应用集成。术语篇把这三份串起来实际上是在告诉你OS2 的技术底座是「主站按 IEC 61970 建模、厂站按 IEC 61850 通信、配网侧按 IEC 61968 集成」。理解这个引用关系比死记术语更有用。3. 91 条术语的四条主线系统、厂站、数据、测试各看什么3.1 系统与平台维度驾驶舱、四大中心、OSB、SOA 之间的关系这一组术语解决的是「OS2 系统由什么组成、彼此怎么协作」的问题。三个最核心的术语是电力系统运行驾驶舱PSOC、变电运行驾驶舱SOC和四大智能应用中心。术语定义要点工程指向PSOC 电力系统运行驾驶舱基于四大中心数据与功能通过 OSB 采用态势感知技术展示 KPI、预警、决策支持的「一站式」工具服务于高层管理决策和电网运行关键岗位主站侧建设SOC 变电运行驾驶舱厂站侧人机交互界面直观反映运行状态、设备运维状态、运行环境状态服务于厂站运行管理、检修、现场值班厂站侧建设单点登录 SSO用户只需登录一次即可访问所有互信应用主站平台统一身份认证多个子系统共用账号体系服务可用一系列服务原语建模的资源功能能力OSB 上注册、管理的最小单元订阅/发布发布者不特定发送给接收者订阅者只收感兴趣类别的消息事件总线、告警分发、数据订阅场景CIM 公共信息模型电网模型的抽象覆盖电力企业主要对象主站数据中心建模多系统同图同库SOA 面向服务的体系服务间通过中立接口和契约联系独立于硬件平台、操作系统和编程语言平台集成架构的总体风格这里最容易混的是 PSOC 和 SOC。PSOC 在主站侧强调的是「决策支持」和「态势感知」服务对象是调度值班和高层管理SOC 在厂站侧强调的是「运行管理、检修、值班」的一站式界面服务对象是现场运维人员。两个名词差一个词系统部署位置完全不一样。做厂站项目的时候只提 SOC做主站项目才谈 PSOC写标书时别混。四大中心的关系在术语篇里没有单独成条但通过 SOC、PSOC 的定义能串出来智能数据中心提供数据智能监视中心提供监视与预警智能控制中心提供手动/自动控制智能管理中心提供定值、方式、统计等管理功能PSOC 和 SOC 都是基于这四个中心向上做综合呈现。换句话说四个中心是「底座」驾驶舱是「门面」。3.2 厂站装置维度合并单元、智能终端、保护测控一体化各管一段厂站侧术语是最贴近现场设备的一批。它们的共性是每个术语都对应一类真实安装在变电站里的物理设备或装置参数。理解这组术语时我建议按「一次设备→采样→保护控制→网络」的链路去记而不是孤立背定义。术语定义要点工程指向电子式电流互感器 ECT二次转换器输出正比于一次电流、相位差已知采样源头对应罗氏线圈、光学互感器电子式电压互感器 EVT二次电压正比于一次电压采样源头合并单元 MU对二次转换器的电流/电压数据进行时间相关组合采样汇聚点输出数字采样值插值法以本地时钟为基准补偿固定延时后重采样同步不依赖全站同步时钟源没有统一同步源时的采样同步方案保护测控装置保护、测量控制功能集成于一体站内最多的一类二次装置智能终端通过 GOOSE 与保护测控配合的开关操作执行单元断路器/刀闸控制回路数字化软压板通过软件实现功能投退投退过程中装置不应重启保护功能投退、远方操作安全设备态测控装置根据开关/刀闸信号与遥测量判别间隔设备状态顺序控制的前提条件判断智能远动机厂站端数据汇集与远动传输的综合装置数据上送、规约转换、主站通信一体化测控装置第 6 部分第 7.2 篇具体规定的一体化装置形态集测量、控制、GOOSE 于一体存储设备降低存储成本、解决海量报文存储通过专用高速接口连接录波、报文存储用独立存储设备插值法这条值得单独强调。它解决的是电子式互感器各自独立采样、没有统一参考时钟时的同步问题电子式互感器以固定延时把数据发给 MUMU 用本地时钟补偿这个固定延时再在补偿后的时刻做插值重采样。工程上它的价值在于——当站内同步时钟故障或未配置时采样同步依然成立只是对固定延时的一致性要求很高。验收时如果只看「有没有插值功能」不看「每只互感器的固定延时是否一致」后期数据同步会出问题。3.3 数据通信维度GOOSE、ICD/CID/SCD/IID、延时参数怎么算数据通信维度是术语篇里技术密度最高的一块也是跟 IEC 61850 实施规范衔接最紧密的一块。四个描述文件术语非常容易混这里先列一张对照表。术语全称内容由谁产生ICDIED Capability DescriptionIED 基本数据模型及服务不含实例名称和通信参数装置制造商CIDConfigured IED Description根据 SCD 文件中与 IED 相关配置生成的装置文件每装置一个装置制造商SCDSubstation Configuration Description全站唯一描述所有 IED 实例配置、通信参数、IED 间通信及一次系统结构含版本修改信息系统集成厂商IIDInstantiated IED Description描述 IED 数据模型及服务含实例名称和通信参数装置厂商配置工具记忆方法是这样ICD 是「能力说明书」出厂就有了不带工程信息SCD 是「全站总图」集成商汇总配置后统一发布CID 是「按图施工」的结果每个装置从 SCD 里取自己那段IID 是单个装置的实例化描述包含了通信参数。工程现场最常见的流程是厂家提供 ICD → 集成商生成 SCD → 下装时转为各装置 CID。如果现场发现改了 SCD 但某台装置没生效先查对应 CID 是否重新生成——这个坑在第 5 章再展开。通信术语里还有一个「背靠背帧」设备在最小帧间隔情况下一次能转发的最大固定长度数据帧数。这个参数直接衡量交换机或装置在突发数据下的极限转发能力雪崩测试和接入能力考核都会用到它。另外「存储转发」定义是整个帧接收完成后再做冗余码校验、过滤和转发与「直通转发」是两条技术路线选工业以太网交换机时这两种模式对实时性和误码率的影响要结合 GOOSE 报文特性评估。MU 传输延时这条必须拆开看。总定义是「从一次模拟量产生时刻到 MU 对外接口输出数字量的时间」但对不同互感器类型具体构成完全不同电子式互感器场景下包含电子式互感器采样延时常规互感器场景下则要包含互感器传变角差、模拟低通滤波器及变换器传变角差。也就是说你拿一个常规互感器配独立 MU算传输延时漏掉角差保护整组动作时间算出来就会偏乐观。3.4 测试验收维度FAT、72 小时连续运行、雪崩、差异分类测试验收术语决定了一个系统怎么算「合格」。OS2 系列的验收分主站和厂站两侧术语篇里的测试相关定义是第 8 部分验收规范各篇的总纲。这里挑最关键的几条。「工厂验收 FAT」的定义里藏着组织关系主站系统通过工厂预验收后由建设单位组织、上级系统运行部主持、制造单位参加在工厂模拟环境下检验是否满足合同技术文件要求。注意 FAT 之前还有一道「工厂预验收」两道门都过了才具备出厂条件。性能测试类术语有三个容易混淆的场景「大容量雪崩测试」是在工厂模拟环境下模拟大量厂站信息量、电网事故雪崩数据与主站实时通信考核系统功能与综合性能「72 小时连续运行测试」是在功能测试、性能测试全部完成后所有设备同时投入运行连续 72 小时不间断「黑启动测试」则是为检测主站黑启动时间所做的启停机及电源操作记录。雪崩考压力72 小时考稳定性黑启动考恢复能力三者不是一回事。差异分类是验收争议的核心。标准把测试过程中发现的问题分作五类差异是总称往下细分为不符合合同条款或新要求的技术差异偏差是不满足具体功能和性能指标、不影响稳定运行、可通过简易修改纠正缺陷是不满足基本功能或主要性能指标、影响系统稳定运行工程化问题是工程配置参数或系统工作未完成导致功能不能正确运行改进要求是为完善某项功能而提出的新需求。我在现场见过太多验收会卡在「这算偏差还是缺陷」上。区分的核心看两条影不影响稳定运行、需不需要重新设计开发。影响稳定运行就是缺陷简易修改就能纠正就是偏差属于配置没做对就是工程化问题属于新增需求就是改进要求。分类不同整改时限和费用归属完全不同。另外如果涉及发电厂并网考核术语篇还专门定义了「两个细则」——即《南方区域发电厂并网运行管理实施细则》和《南方区域并网发电厂辅助服务管理实施细则》这两份细则文件编号都是电监市场〔2008〕56 号在做并网考核数据接入时这个术语经常出现在需求文档里。4. 把术语串成工程链路从一次设备到运行驾驶舱的落地映射4.1 厂站数据流链路采样、合并、保护控制、上送的完整路径把第 3 章的术语按物理世界顺序串起来就是一条清晰的厂站数据流链路。链路从一次设备开始电流电压信号由电子式互感器ECT/EVT或常规互感器采到送至合并单元 MU 做时间相关组合与格式统一。合并单元输出数字采样值给到两类对象一是保护测控装置做测量、监视、控制和保护逻辑二是智能终端负责跟断路器和刀闸的 GOOSE 命令交互。保护测控装置与智能终端之间通过 GOOSE 传输跳合闸信号。再往上站控层交换机把所有装置连到监控后台和远动装置最终上送到调度主站。整个链条里SOC 是基于这四个中心数据在厂站侧做综合展示的界面而主站侧的 PSOC 则把这套数据继续向上聚合。接入能力、背靠背帧、存储转发三个参数正好分布在这条链路的三个环节接入能力衡量一体化装置最多能带多少个 MU 还不丢报文标准里明确以接入 MU 数量为指标背靠背帧衡量交换机或装置在极限突发下能连续转发多少帧存储转发决定报文在装置里是收完再校验还是边收边转。做容量规划时要同时看这三个参数只看其中一个会翻车。比如接入能力按 MU 数量算够了但背靠背帧不够雪崩数据一来装置来不及转发丢帧就从这里开始了。4.2 配置描述文件链路ICD 到 SCD 再到 CID、IID 的工程流转工程实施时厂站通信配置的流转顺序是固定的。装置制造商先提供 ICD 文件描述装置的基础数据模型和通信能力此时不包含实例名称和通信参数。系统集成商拿到所有 ICD 后汇总形成全站唯一的 SCD 文件把每个 IED 的实例配置、通信参数、IED 间通信关系、一次系统结构都写进去。SCD 必须带版本修改信息明确描述修改时间和版本号这是工程追溯的依据。SCD 合稿之后每个装置制造商用配置工具从 SCD 里导出自己装置的 CID 文件再下装到装置里。如果现场要调整通信参数或在某个间隔增加装置正确顺序是改 SCD → 重新导出受影响装置的 CID → 下装。跳过 SCD 直接改装置 CID 的做法短时间能跑通但全站配置文件跟实际不一致后续做 SCD 一致性校验时全部暴露。IID 文件则是装置厂商配置工具根据 SCD 生成的实例化描述含实例名称和通信参数通常用于单装置调试与工程归档。调试单装置用 IID全站联调用 SCD这两者用途别弄反。涉及新增间隔或更换装置时SCD 的版本修改信息要同步更新修改时间、修改版本号两条是验收专家必查项。4.3 测试验收链路差异分类决定整改路径验收测试按术语篇的分类逻辑可以设计成一张处置路径表。拿到测试问题单先按「影响稳定运行」和「是否为新需求」两问分到对应类别。差异类别判定要点典型处置偏差不满足具体功能和性能指标、不影响稳定运行、可简易修改限期修改后复测该项缺陷不满足基本功能和主要性能指标、影响系统稳定运行停工整改重新组织测试工程化问题运行环境、条件、参数配置不对导致功能不正确修正工程配置重新验证改进要求为完善某项功能而提出的新需求按新增需求走变更流程不阻塞验收实际验收中工程化问题和偏差最容易扯皮厂家喜欢把所有功能不符都定性为「工程化问题」因为改配置不算设计变更建设单位则倾向按偏差或缺陷处理以争取整改时限和质量责任。我的做法是在验收启动会前把五类差异的定义打印出来连同判定标准发给双方确认。先把尺子对准了再开始测能省掉一半的会后争吵。另一个容易漏的细节是差异记录要带出处比如「第 5.13 篇智能控制中心自动控制类功能规范条项」没有出处的差异项在后续整改确认时会被反复推翻。4.4 容灾链路RPO、RTO、降级容灾与实际投运状态灾备建设在主站平台里占六篇中的一篇第 4 部分第 5 篇容灾备用技术规范。术语篇给了三个关键参数。RTO 恢复时间目标是「从停顿到必须恢复的时间要求」RPO 恢复点目标是「可以恢复到的时间点要求」。这两个参数必须在项目设计阶段定值调度主站对 RTO 要求比一般系统严格对 RPO 则要结合历史数据重要性来定。定低了灾备链路投入大、成本高定高了验收时专家一句话就退回。「降级容灾」定义为灾备系统功能、性能、处理能力、可靠性指标低于原系统。工程上这意味着灾备侧不是简单复制而是允许在容灾状态下降低非核心功能保证调度和监视等核心功能优先恢复。「数据级容灾」则只做业务数据冗余备份确保数据不丢恢复时还需重建应用环境。这两者在方案评审时经常被混用讲的是数据级容灾答的是降级容灾的指标口径一乱后面的验收标准就跟着乱。项目前期先把「做数据级还是业务级、允许不允许降级、RTO/RPO 定多少」三个问题定下来后面的容灾设计才有边界。5. 避坑指南术语篇最容易被带偏的五个常见问题5.1 ICD、CID、SCD、IID 四个文件混用现象现场报障说「SCD 下装了但不生效」排查半天发现下装的是 IID或者要求厂家提供配置备份厂家交来一堆 ICD。原因四个英文缩写都带 D都跟 IED 配置相关文档管理不严时极易张冠李戴。很多现场工程师只记得「SCD 是全站文件」对其他三个文件的角色边界模糊。解决在项目文档管理规范里固定四类文件的责任人和命名规则。ICD 由装置制造厂商提供进库标记「原始能力」SCD 由集成商统一维护进库标记「全站唯一修改需走变更」CID 是下装版本标记对应装置和 SCD 版本号IID 只用于单装置调试不作为现场运行版本。同一台装置四个文件各存各的目录文件名带装置路径和修改日期。只要归档时强制核对「文件类型-内容-来源」三要素这个坑基本不会再踩。5.2 把插值法当成「必须依赖统一同步时钟」的方案现象投标方案里写「采样同步采用插值法需配置全站同步时钟源」评审专家看到就发问「标准明确说不依赖全站同步时钟源为什么还要加时钟」。原因插值法强调的是以本地时钟为基准补偿固定延时工程人员没有细读定义想当然认为所有采样同步都必须有时钟源。这个误解在技术方案评审里几乎每年都能见到。解决写技术方案时分两种场景表述——有统一时钟源时采用对时加插值校验无统一时钟源时插值法本身可实现同步前提是电子式互感器固定延时一致且稳定。按标准原文口径写「不依赖」然后再说明本工程出于保护定位和事件时标一致性仍配置同步时钟两个层次分开讲既符合标准又不丢时钟的工程价值。5.3 保护装置动作时间与保护整组动作时间起点算错现象整组动作时间测试结果偏小验收专家质疑数据造假测试人员用的是故障录波起始时刻而不是一次模拟量产生时刻。原因两个时间定义起点不同。保护装置动作时间从「收到故障起始数据」开始算保护整组动作时间从「一次模拟量产生时刻」开始算终点到智能终端操作回路出口动作。测试端子接错或用报文时间戳代替一次量产生时刻结果就偏了。解决测试前先明确考核的是哪一个时间记录路径为一次模拟量产生时刻 → 电子式互感器采样 → MU 传输延时 → 保护逻辑 → 跳闸命令 → GOOSE 传输 → 智能终端出口。按这个链路取时标每一项延时来源都能对上号差毫秒级时优先查 MU 传输延时和 GOOSE 传输环节。5.4 常规互感器场景下 MU 传输延时漏算互感器传变角差现象同一套合并单元配常规互感器时测试延时比配电子式互感器时偏差大且偏大方向不稳定。原因MU 传输延时对两类互感器定义不同。常规互感器场景必须包含互感器传变角差、模拟低通滤波器及变换器传变角差电子式互感器场景则包含其采样延时。漏算这部分延时一致性自然对不上。解决做延时参数表时按互感器类型分两列填写构成项。常规互感器传变角差加模拟低通滤波器加变换器加 MU 内部处理电子式互感器传感器采样加转换器加 MU 内部处理。每一段都要求厂家提供实测或出厂值逐项相加后再和整组实测对照。现场如果两组配置混用还要额外验证两种互感器采样值在同一 MU 下的时标对齐。5.5 把「2013 年起开始可研」误读为「2013 年起实施强制」现象项目是 2012 年完成可研、2014 年招标评审专家要求按 2012 版标准全套执行商务认为项目启动早可以豁免。原因前言明确规定「适用于 2013 年起开始可研的新建或技改项目」判定依据是可研启动时间不是招标或开工时间。这个时间点表述太短很多项目经理没注意到。解决项目启动时先做「标准适用性判定」可研启动时间在 2013 年之前用旧版体系并备案差异说明在 2013 年及以后全部按 2012 版系列标准执行。把这个判定写进项目章程的编制依据一章进出文件都引用同一个版本号避免后续扯皮。如果你是集成商还要注意投标文件里承诺的版本号必须与招标文件一致否则验收时会按更严版本执行。6. 把 91 条术语变成验收对齐清单一张映射表的事6.1 术语映射表的制作方法做一个厂站项目开工前花半天做一张五列表能省后面五天。表的列是标准术语、标准定义关键词、我方系统模块、设计院叫法、验收关注点。行按系统架构、厂站装置、数据通信、测试验收四组填。标准术语定义关键词我方模块设计院/厂家叫法验收关注点程序化操作按严格条件和顺序自动完成操作顺控模块顺序控制/顺控操作操作条件闭锁保护测控装置保护与测量控制一体测控保护装置综自装置软压板投退不重启合并单元电流电压数据时间相关组合采样汇聚装置MU/采集单元传输延时、接入能力驾驶舱基于四大中心的一站式界面运行驾驶舱PSOC/SOC 界面数据来源、KPI 准确性这张表做好后设计联络会直接按表对齐图纸叫法投标文件按标准术语描述再括注工程叫法验收测试项也从「验收关注点」列直接派生。6.2 映射表在评审与验收里的用法做评审材料时我把它放在技术附件最前面。评审专家习惯先找术语再找方案五列一眼扫过去术语出处、对应模块、图纸叫法、验收点全对齐比正文写三段解释高效也难被挑「术语不一致」的毛病。验收阶段用它做差异清单的出处检索测试单写标准术语映射表一查就定位到具体模块再按第 4 章的偏差、缺陷、工程化问题分类定性整改。这个习惯是有代价的。第一次做表你会发现自家系统有很多叫法从没统一过——有一次验收专家拿术语篇逐条问「你说的驾驶舱是 SOC 还是 PSOC」我翻映射表才发现项目前期压根没定义清楚。从那以后每个项目启动第一周先开术语对齐会把标准术语、系统功能、图纸叫法三方对完再动手设计。这也算我踩过的最值得分享的一个坑希望帮到你。本文还有配套的精品资源点击获取