简介：这份资源是挪威船级社（DNV）发布的DNV-CG-0130《波浪载荷》类指南，2021年10月版，面向船舶与海洋工程结构设计人员、审图工程师及相关专业师生。它系统阐述了波浪载荷计算与评估的方法、技术要求、原则和接受标准，涵盖波浪力计算、波浪统计特性、海况分析与结构响应分析等关键内容，可用于设计阶段评估结构安全性与耐久性，并作为DNV认证过程中的重要参考依据。资源包共1个文件，为PDF格式，大小约3.65MB，内容完整、便于检索查阅。文档同时说明了知识产权与使用风险条款，并明确其取代2018年1月版DNVGL-CG-0130，本次更新主要因品牌由DNVGL更名为DNV，技术内容未作实质改动。目前已有71人学习下载，适合需要掌握波浪载荷规范依据、对照DNV规则开展合规设计的工程师参考使用。

1. DNV-CG-0130 到底管什么：一份被低估的船级社合规入口

如果你在做海上风电、海工装备或者船舶电气系统的合规工作，大概率在某个时刻被甲方或船东甩过来一句「按 DNV-CG-0130 来」。很多人第一反应是去搜这个编号，然后下载到一份几十页的 PDF，翻两页发现全是分类、定义和符合性判定逻辑，就搁置了。DNV-CG-0130 是 DNV 发布的入级规范体系里的一份核心指南文件，它管的是与电气装置、控制系统、安全相关的那一整套合规判定路径。它不是一个孤立标准，而是 DNV 规范体系里承上启下的那一环——往上接 DNV 的入级规范（Rules for Classification），往下落到具体设备、系统、软件的符合性验证。你如果只把它当一份「参考文件」看，就会在项目后期被审图意见反复打回；你如果把它当成一个可执行的合规检查框架来用，很多返工是可以提前避免的。这篇内容面向的是需要实际交付 DNV 合规文件的电气、控制、安全工程师，以及做海上风电/海工项目技术管理的从业者。我会把这份指南的定位、怎么拆解它的要求、怎么落到实际文档和验证动作上讲清楚，让你拿到这份 PDF 之后知道从哪一页开始看、哪些条款必须逐条响应、哪些地方最容易翻车。

2. 拆解 DNV-CG-0130 的条款结构：从目录到可执行检查项

2.1 先搞清楚它在 DNV 规范体系里的位置

DNV 的规范体系是分层级的。最上层是 Rules for Classification，规定船级社对船舶和海工设施的整体入级要求；中间层是各种 Standard 和 Recommended Practice，给出具体技术领域的推荐做法；再往下就是 CG（Class Guideline）这一类指南文件。DNV-CG-0130 属于指南层级，它的特点是：不直接创造新的强制性要求，而是把上层规范里的要求拆解成可操作的符合性判定方法。这意味着你在读它的时候，不能只看它本身写了什么，还要顺着它引用的条款往回追。常见做法是：先把 CG 里引用的 Rules 条款号列出来，再去 Rules 里找到原文，确认强制等级（是 SHALL 还是 SHOULD），然后再回到 CG 看它给的验证方法。这个来回过程听起来繁琐，但它是避免漏项的唯一可靠方式。我一般会在项目启动阶段就建一个对照表，左边是 CG 条款号，中间是引用的 Rules 条款号，右边是强制等级和验证方式。这个表后面会直接变成审图响应清单。

2.2 把条款拆成三类：设计输入、验证动作、文档输出

DNV-CG-0130 的条款大致可以归到三类里。第一类是设计输入类，告诉你系统设计时必须考虑哪些因素，比如环境条件、冗余要求、故障模式。第二类是验证动作类，规定你必须做哪些测试、分析或仿真来证明符合性。第三类是文档输出类，明确你要提交什么文件、文件里必须包含哪些信息。很多人在做合规的时候只盯着第三类，觉得把文件交上去就完了，结果审图意见回来发现验证动作没做或者设计输入没考虑，又得返工。我的做法是：拿到 CG 之后，先通读一遍，把每一条按这三类打标签。设计输入类的条款要落到设计规格书里，验证动作类的条款要落到测试计划或分析计划里，文档输出类的条款要落到交付物清单里。这三条线并行推进，才能保证在审图节点前把所有证据链补齐。

2.3 用表格把条款映射到项目交付物

下面这个表是我在实际项目里用的映射模板，你可以直接抄。左边是 CG 条款号，中间是条款摘要，右边是对应的交付物和责任人。这个表建好之后，每周项目例会过一遍，看哪些条款还没有对应的交付物，哪些交付物还没有完成验证。

这个表的关键在于「状态」列要真实更新。我见过太多项目把表建得很漂亮，但状态永远停在「进行中」，到了审图节点才发现一半的交付物根本没启动。建议每周更新一次，状态只有三个值：未开始、进行中、已完成。已完成的标准是文件已经内部评审通过并且上传到项目文档库。

2.4 识别条款里的「隐性要求」

DNV-CG-0130 里有一些条款写得很含蓄，不会直接说「你必须做某某测试」，而是说「应通过分析或测试证明……」。这种表述就是隐性要求。它给了你选择权，但同时也意味着你不能什么都不做。常见做法是：对于这种条款，在项目早期就决定走分析路线还是测试路线。如果走分析路线，要明确用什么分析方法、输入数据从哪来、谁来做评审。如果走测试路线，要明确测试标准、测试环境、合格判据。这个决定越早做越好，因为测试资源通常需要提前预约，分析工作也需要时间。我一般会在项目设计阶段就出一个「符合性验证策略」文件，把每一条隐性要求都明确到具体路线和责任人。这个文件不需要很长，但它是后面所有验证工作的总纲。

3. 落地执行：从条款到文档、测试和分析的完整链路

3.1 设计输入类条款怎么落到规格书里

设计输入类条款的核心是「可追溯」。你不能只在规格书里写一句「满足 DNV-CG-0130 要求」，而要具体到条款号。我的做法是在规格书里加一个章节叫「合规性设计输入」，逐条列出 CG 里的设计输入要求，然后写明本项目的设计值或设计策略。比如 CG 里要求考虑环境温度对电气设备的影响，你就要在规格书里写明本项目的最低和最高环境温度、选用的设备温度等级、以及为什么这个等级是足够的。这样审图人员一看就知道你不仅读了条款，还把它落到了具体设计里。这个章节通常放在规格书的前面，作为设计依据的一部分。写的时候注意不要抄 CG 原文，要用自己的项目语言重新表述，否则审图人员会认为你没有真正理解。

3.2 验证动作类条款怎么排测试计划

验证动作类条款是最容易出问题的地方。很多人以为测试就是按标准做一遍，但 DNV-CG-0130 里的验证要求往往需要你先把测试计划提交给船级社认可，然后才能执行。这个「先认可后执行」的顺序如果搞反了，测试做了也白做。我的经验是：在项目中期就把测试计划框架搭出来，包括测试对象、测试项目、测试方法、合格判据、测试环境要求。然后拿着这个框架去和船级社开一次预沟通会，确认哪些测试项目是必须的、哪些可以合并、哪些可以用分析替代。预沟通会之后再把计划细化，提交正式认可。这个过程听起来多了一步，但实际上省掉了后面反复修改的时间。测试计划里每个测试项目都要对应到 CG 的具体条款号，这样审图人员能直接看到覆盖关系。

3.3 文档输出类条款怎么建交付物清单

文档输出类条款看起来最简单，但其实最容易漏。因为 CG 里可能在不同章节分别提到不同的文件要求，你如果只看目录，很容易漏掉某个章节里的一句话。我的做法是：通读全文，把所有出现「应提交」「应提供」「应包含」这类表述的地方全部标出来，然后汇总成一个交付物清单。清单里每个交付物要写明：文件名称、对应 CG 条款号、提交时间节点、内部评审人、提交对象。这个清单建好之后，直接和项目的文档管理计划合并。注意一点：CG 里要求的文件格式和内容深度可能和项目现有模板不一致，这时候要么改模板，要么在文件里加一个对照说明，解释为什么现有模板已经覆盖了 CG 的要求。不要假设审图人员会自己帮你做这个对照。

3.4 用检查表做内部预审

在正式提交船级社之前，我强烈建议做一轮内部预审。预审的工具就是前面建的条款映射表和交付物清单。预审的时候逐条过：设计输入类条款，看规格书里有没有对应章节；验证动作类条款，看测试计划或分析报告有没有覆盖；文档输出类条款，看交付物清单里的文件是不是都已完成内部评审。预审发现的问题要记录在案，指定责任人限期关闭。这一轮预审通常能发现 70% 以上的明显问题，比如条款漏响应、文件缺页、测试判据写错。这些问题如果到了船级社那边才被发现，来回沟通的时间成本会高很多。预审的另一个好处是：你能提前知道哪些条款的响应方式可能引起争议，然后提前准备好解释材料。

4. 避坑指南：DNV-CG-0130 执行中最容易翻车的五个地方

4.1 把 CG 当强制标准，逐字照抄

现象：规格书或测试计划里大段引用 CG 原文，甚至直接把 CG 的条款号当标题。原因：没有区分 CG 和 Rules 的效力层级，误以为 CG 里的每句话都是强制要求。解决：先确认 CG 条款引用的上层规范条款，以 Rules 的强制等级为准。CG 本身是指南，它给的是推荐做法，你可以采用，也可以提出替代方案，但替代方案需要证明等效性。在文件里写的时候，用「依据 DNV-CG-0130 第 X 节，本项目采用如下设计/验证策略」这样的句式，而不是直接抄原文。

4.2 验证动作做完才提交计划

现象：测试已经执行完了，船级社才收到测试计划，要求重做或补充。原因：没有仔细看 CG 里关于验证时机的要求，或者项目进度压力导致先做后补。解决：在项目计划里把「测试计划认可」作为一个独立节点，放在「测试执行」之前。这个节点的前置条件是测试计划已经内部评审通过并提交船级社。如果项目进度实在紧张，可以和船级社沟通是否可以先执行部分测试，但一定要拿到书面同意，否则后面很被动。

4.3 文档输出漏掉分散条款

现象：提交的文件被退回，说缺少某个分析报告或某个声明文件。原因：只看了 CG 的目录和主要章节，漏掉了分散在各节里的文件要求。解决：通读全文，用关键词搜索「应提交」「应提供」「应包含」「应记录」等表述，把所有文件要求汇总成清单。这个清单要和项目的文档管理计划做交叉检查，确保每个文件都有责任人、有模板、有评审流程。

4.4 设计输入和验证动作脱节

现象：设计规格书里写了某个设计值，但测试计划里没有对应的验证项目；或者测试做了，但设计规格书里没有对应的设计输入。原因：设计团队和验证团队各干各的，没有做交叉检查。解决：在条款映射表里加一列「关联条款」，把设计输入类条款和验证动作类条款关联起来。每周例会过一遍，看每个设计输入是不是都有对应的验证动作，每个验证动作是不是都有对应的设计输入。这个交叉检查能发现很多隐性漏项。

4.5 忽略 CG 的版本和适用范围

现象：用了旧版 CG 做合规，或者把适用于其他设施类型的条款套用到本项目上。原因：没有确认 CG 的版本号和适用范围章节。解决：在项目启动阶段就确认 CG 的版本号，并记录在合规依据文件里。同时仔细阅读 CG 的适用范围章节，确认本项目属于哪一类设施、哪些条款适用、哪些条款不适用。如果 CG 更新了版本，要评估新版对项目的影响，必要时更新合规策略。这个工作看起来简单，但实际项目里因为版本问题翻车的情况并不少见。

5. 进阶技巧：用追溯矩阵把合规证据链串起来

前面讲的条款映射表和交付物清单是基础工具，但如果你想让整个合规工作更可控，我建议再往前一步：建一个追溯矩阵。追溯矩阵的核心是把「条款要求 → 设计输入 → 验证动作 → 文档输出 → 审图意见」这五个环节串起来。每一行是一个条款，每一列是一个环节，单元格里填对应的文件编号或记录编号。这样你随时可以看到：某个条款的要求有没有落到设计里、有没有做验证、有没有形成文件、审图时有没有被提意见。如果某个条款在某一列是空的，那就是风险点。这个矩阵在项目后期特别有用，因为审图意见往往不是孤立的，它可能牵涉到设计、验证、文档多个环节。有了追溯矩阵，你能快速定位问题的影响范围，而不是到处翻文件。

我自己的习惯是：追溯矩阵用电子表格做，每周更新一次。更新的时候重点看两件事：一是新增的审图意见有没有对应的条款行，二是已关闭的审图意见有没有更新验证状态。这个习惯坚持下来，项目结束时你会发现整个合规证据链是完整且可追溯的。审图人员如果问某个条款的验证依据，你能在几分钟内把设计文件、测试报告、分析报告全部调出来。这种响应速度在项目后期能省下大量沟通时间。希望帮到你。

本文还有配套的精品资源，点击获取