S1000D DMC 编码示例：如何拆解数据模块代码？
DMC（Data Module Code，数据模块代码）要先服务于稳定的模块身份，再服务于检索和出版物组织。下面用一个虚构的维修任务演示如何从型号、SNS 层级、信息类型和变体建立编码检查表；示例值不代表任何正式标准字段或项目代码表。
ABC-29-10-05-040A-A 只是虚构的分段示意。它不构成正式 DMC、Schema、代码表、BREX、命名空间或可直接交付的 XML；真实项目应从批准的规范包和样例反向确认字段。DMC 在 S1000D 项目中解决什么问题？
DMC 为数据模块提供可管理的身份，帮助 CSDB 区分模块、处理引用、记录版本并组织出版物。它通常需要与产品型号、系统分解、信息类型、组件或差异范围建立稳定关系。DMC 解决“这个模块是谁”，模块标题解决“读者看到什么”，两者都要和实际内容、适用性及状态一致。
DMC 不是标题、文件路径、版本号或完整的项目配置矩阵。一个稳定的 DMC 可以被多个出版物引用；不同型号或构型的差异，通常应通过项目批准的字段、适用性和配置规则表达，而不是随意把日期、人员或临时版本塞入编码。
如果项目采用 GJB 6600，应另按GJB 6600.2 编码导读核对字段和代码表。本页仅说明 S1000D 场景，不能把示例直接当成 GJB 6600 编码模板。
示例任务：为一个维修模块建立编码需求
假设项目为“ABC-100”装备建立一份液压泵更换程序。项目的系统分解把液压泵放在示意路径 29 / 10 / 05，团队需要编制一个程序类数据模块，供型号 A 构型使用。下面的型号、SNS 路径、任务编号和人员均为虚构值。
| 需求对象 | 示例值 | 编码前的检查 |
|---|---|---|
| 产品型号 | ABC-100（虚构） | 是否已进入项目型号清单，简称和大小写是否统一。 |
| 系统层级 | 29 / 10 / 05（示意 SNS 路径） | 系统、分系统和组件边界是否有批准的定义。 |
| 模块主题 | 液压泵更换程序 | 任务边界、受众、先决条件和完成判据是否明确。 |
| 信息类型 | 程序类（具体代码待项目确认） | 信息代码、变体和模块类型是否来自当前 Data Dictionary。 |
| 适用性 | 型号 A、构型 1（示意） | 是否由 ACT/PCT/CCT 或项目规则表达，能否被 PM 筛选。 |
DMC 示例如何拆解？
将示意编码写作 ABC-29-10-05-040A-A。为避免把外部样例误当成正式模板，下面只展示“字段规划和核对责任”，不宣称每个分隔段在所有 Issue 中有固定长度或固定语义。
| 示意片段 | 本例的解释 | 项目必须确认 |
|---|---|---|
ABC | 虚构的型号或产品识别片段。 | 对应 modelIdentCode 还是项目映射值；来源、长度、大小写和代码表。 |
29-10-05 | 虚构的系统、分系统、组件层级路径。 | 与 SNS 的节点、责任边界、型号配置和 DMRL 是否一致。 |
040A | 虚构的信息/组件/变体组合片段，用于展示需要拆分核对的区域。 | 当前 Issue 的 assyCode、disassyCode、infoCode 等字段怎样组合，允许值和变体如何定义。 |
A | 虚构的差异或位置片段。 | 实际对应 infoCodeVariant、itemLocationCode 或其他项目字段，不能凭字面猜测。 |
正式项目应把“示意片段”换成 Schema 和数据字典中的正式属性，再用代码表限定允许值。若规则要求无分隔符文件名或不同的显示形式，应在 DMC、文件名、DMRef 和 CSDB 中建立可追踪映射，而不是修改 DMC 语义来适应目录习惯。
常见 DMC 字段如何进入规则？
| 字段或对象 | 应回答的问题 | 推荐证据 |
|---|---|---|
modelIdentCode | 模块属于哪个型号或产品识别范围？多个供应方如何区分？ | 型号清单、代码表、申请与变更记录。 |
systemCode、subSystemCode、subSubSystemCode | 模块在哪个系统层级，是否与 SNS 和责任边界一致？ | SNS 分解、节点责任表、DMRL 映射。 |
assyCode、disassyCode、disassyCodeVariant | 组件、拆装组件及其变体如何区分，是否可维护和复用？ | 装配树、组件代码表、代表性 DMC。 |
infoCode、infoCodeVariant | 模块承载哪种信息，变体是否有稳定的业务含义？ | 信息类型矩阵、Data Dictionary、代码表和 Schema。 |
itemLocationCode | 对象位置或项目定义的定位信息如何表达？ | 项目规则、适用性/配置映射和样例校验报告。 |
字段名称只是检索和理解入口，是否必填、字段顺序、长度、取值、组合关系和允许扩展均由采用的 Issue、Schema、Data Dictionary、BREX 和项目规则决定。实际编制前应使用工具加载批准基线，避免按网页片段手工拼码。
DMC、标题、文件名、DMRL 和 DMRef 的关系
同一个模块的身份、内容和交付路径需要形成可追溯链，但每个对象承担的职责不同：
| 对象 | 回答的问题 | 不应承担的职责 |
|---|---|---|
| DMC | 模块的结构化身份和编码关系是什么？ | 不替代标题、内容、版本状态和适用性矩阵。 |
| 模块标题 | 读者和编制人员如何理解主题？ | 不替代可校验的编码和唯一身份。 |
| 文件名/路径 | 源文件或交付包如何存放、传输和查找？ | 不应悄悄改变 DMC 语义或破坏引用。 |
| DMRL | 需要编制什么模块、由谁负责、处于什么状态？ | 不替代正式数据模块和 CSDB 对象。 |
| DMRef / PM | 出版物如何引用模块并按顺序和适用性组织？ | 不把临时文件名当作已批准模块身份。 |
对本例，可建立一条虚构追溯链：DMRL-0237（液压泵更换需求）→ 示例 DMC → 程序类数据模块 → 安全模块和接口图引用 → PM/DMRef → 型号 A 交付包。每一环都应记录版本、状态和校验证据；示例编号不代表实际项目编号。
DMC 编码发布前检查清单
- 规则基线：确认 Issue、Schema、Data Dictionary、代码表和 BREX 是同一批准版本。
- 唯一性：检查 DMC 在当前 CSDB、历史版本和项目范围内不重复，变更有审批轨迹。
- 层级一致：确认系统码、组件码和 SNS 节点对应同一设备分解和责任边界。
- 内容匹配：检查 DMC、模块标题、信息类型、实际任务和引用对象没有互相矛盾。
- 适用性正确：确认型号、构型、序列范围和变体通过项目适用性规则筛选，不把配置写成临时编码。
- 引用可解析：扫描 DMRef、PM、媒体、代码表和相关模块，确认版本和交付包清单一致。
- 工具回归：用代表性描述、程序、零件和故障隔离模块执行 Schema/BREX 校验和目标环境预览。
常见问题
下面的 DMC 示例可以直接用于项目吗？
不可以。示例中的型号、系统码、信息码和变体都是虚构占位值，只用于展示字段规划和检查思路。正式编码必须以项目批准的 Issue、Schema、Data Dictionary、代码表和业务规则为准。
DMC 和文件名是一回事吗？
不是。DMC 是数据模块的结构化身份，文件名是存储或交付环境中的路径标识。项目可以建立映射，但不能让文件名变化破坏 DMC、DMRef、CSDB 和历史追溯。
DMC 中可以放设备序列号或发布日期吗？
不能随意放入。序列号、发布日期和软件版本是否属于 DMC 字段，必须由采用的规范和项目规则决定；通常应通过适用性、状态或配置管理表达，并保留稳定的模块身份。
制定 DMC 规则前要先做什么？
先确定产品型号、系统分解、信息类型、差异管理、SNS 映射、代码表、责任边界和复用策略，再用代表性模块试编并经过 Schema、BREX 和引用检查。