七、模块功能边界的明确与冲突规避

李工团队通过 “模块接口规范” 明确功能边界，规范包含三部分：一是输入输出参数定义（数据格式、长度、存储地址），如 “补零模块” 仅接收 “非标准分组 + 补零需求”，输出 “标准分组 + 校验位”，不接收其他模块的矩阵变换数据；二是功能禁止清单，如 “异常处理模块” 仅监测异常，不执行加密 \/ 解密运算，避免功能侵入；三是数据交互规则，模块间仅通过磁芯存储器指定缓存区（地址 0x4000-0x7FFF）传输数据，禁止直接调用其他模块的内部变量。

针对潜在的模块功能冲突（如 “密钥整合模块” 与 “加密输出模块” 均需处理加密数据），团队设计 “数据所有权机制”：明确 “密钥整合模块” 生成 “加密中间数据” 后，标记数据所有权为 “加密输出模块”，仅该模块可读取，其他模块（如矩阵模块）无法访问，避免数据被误修改；数据处理完成后，所有权释放，缓存区可复用。

边界验证通过 “交叉测试” 实现：郑工团队选取 5 组模块（如 “明文校验 - 分组 - 补零 - 矩阵变换 - 密钥整合”），模拟数据交互，验证是否存在功能越位 —— 例如 “分组模块” 是否尝试修改明文格式（禁止功能），测试结果显示 19 组模块均未越界，数据交互仅通过指定缓存区，无直接调用，边界清晰。

针对 “模块间依赖过强” 问题（如 “矩阵变换模块” 依赖 “矩阵并行控制模块” 的调度信号），团队设计 “依赖降级方案”：若并行控制模块故障，矩阵变换模块可切换为 “串行模式” 独立运行（速度降低但不中断），避免因单一模块故障导致整体算法停滞，提升鲁棒性。

11 月 5 日，团队完成《19 组算法模块接口规范与边界确认报告》，包含接口定义、冲突规避方案、交叉测试数据，通过内部评审，确认模块边界清晰、无功能冲突，可进入代码编写阶段。

八、模块与代码固化的适配性设计

马工团队开展模块与代码固化的适配性设计，核心目标是确保 19 组模块的代码可顺利加载至磁芯存储器程序区（8Kb），并适配硬件运算单元的调用逻辑。

代码量控制与存储分配：根据模块功能复杂度，估算每组模块的代码量（如 “明文格式校验模块” 约 384 字节，“矩阵变换执行模块” 约 480 字节），19 组模块总代码量约 7.2Kb，预留 0.8Kb 空间（用于后续优化），存储地址按类别分配：输入处理类（0x0000-0x07FF）、分组补零类（0x0800-0x0FFF）、矩阵运算类（0x1000-0x1FFF）、密钥管理类（0x2000-0x27FF）、加密输出类（0x2800-0x2FFF）、解密处理类（0x3000-0x37FF）、异常处理类（0x3800-0x3bFF）、辅助功能类（0x3c00-0x3FFF），地址不重叠。

硬件调用逻辑适配：每个模块代码编写时，预留硬件接口函数（如 “矩阵变换模块” 包含 “调用乘法运算单元” 函数），接口参数与硬件电路（如 1369 个逻辑单元）的输入输出引脚匹配，例如调用乘法运算时，代码输出 “矩阵地址 + 向量数据” 至硬件地址总线与数据总线，确保硬件可正确接收并执行运算。

代码可测试性设计：每个模块代码包含 “测试入口函数”，输入预设测试数据（如 “明文格式校验模块” 输入含非法字符的明文），输出测试结果标记（如 “合法 \/ 非法”），无需运行其他模块即可独立测试，例如测试 “模 256 运算模块” 时，输入 “300”，输出 “44”（300 od 256=44），验证代码正确性。

11 月 10 日，团队完成《19 组算法模块代码固化适配方案》，包含存储地址分配表、代码量估算表、硬件接口函数定义，提交中科院计算所（负责代码固化），确认适配性无问题，可启动代码编写。

九、模块划分的评审与最终确认

11 月 12 日，团队组织 “19 组算法模块划分评审会”，邀请国防科工委专家（3 人）、硬件团队负责人（王工）、代码固化团队（中科院计算所 2 人）、存储方案团队（刘工）参会，重点评审模块的 “功能完整性”“边界清晰度”“适配性”。

功能完整性评审：专家确认 19 组模块覆盖加密与解密全流程（无遗漏步骤），如 “补零移除模块” 对应 “补零生成模块”，“矩阵逆变换模块” 对应 “矩阵变换模块”，反向流程完整；异常处理模块覆盖格式错误、运算溢出等 6 类常见异常，无功能缺失。

边界清晰度评审：王工团队验证模块接口是否清晰，例如硬件调用 “矩阵变换模块” 时，仅需传入 “分组向量地址”，无需了解模块内部运算逻辑，符合 “黑盒调用” 原则；代码固化团队确认模块代码可独立编译、加载，无需修改其他模块代码，边界无耦合。

适配性评审：刘工确认模块存储分配（7.2Kb）在磁芯存储器程序区（8Kb）范围内，地址分配合理（无重叠）；中科院计算所代表确认硬件接口函数定义符合代码固化规范，可直接调用硬件运算单元，适配性达标。

评审会后，团队根据专家建议微调 1 组模块（将 “密钥同步模块” 的 “同步信号生成” 功能从模块中拆分，合并至 “辅助功能类” 的 “通信控制模块”，模块总数仍为 19 组），形成《19 组算法模块划分最终方案》，通过最终评审，11 月 15 日正式定稿，作为代码固化的官方依据。

十、模块划分的历史意义与后续影响

从 “73 式” 研发看，19 组模块划分是代码固化与硬件集成的 “桥梁”—— 通过系统化拆解，复杂的加密逻辑变得可控，代码编写可按模块分工（如陈工负责输入处理类，吴工负责矩阵运算类），效率提升 50%；同时，模块独立测试减少了整体调试的难度，1965 年代码固化阶段仅出现 3 次模块间交互错误（均快速解决），确保研发按周期推进。

从技术标准化看，模块划分形成 “加密算法模块化设计范式”—— 后续我国军用加密设备（如 “84 式”“92 式”）的算法设计，均借鉴 “流程拆解 - 功能分类 - 独立模块” 的逻辑，例如 “92 式” 将椭圆曲线加密算法拆分为 22 组模块，模块接口规范与 “73 式” 一脉相承，推动军用加密算法设计的标准化。

从维护与升级看，模块划分大幅降低后续成本 ——1970 年 “73 式” 升级矩阵参数时，仅需修改 “矩阵变换执行模块” 代码（约 480 字节），无需整体重构，升级周期从 1 个月缩短至 1 周；1975 年某部队设备出现密钥同步故障，仅替换 “密钥同步模块” 代码即可修复，维护成本降低 70%。

从人才培养看，模块划分培养了 “系统化设计思维”—— 参与划分的李工、吴工等技术人员，后续成为我国通信安全领域的骨干，在教学与研发中推广模块化设计理念，1980 年代清华大学《军用密码学》教材中，将 “73 式” 模块划分作为案例，培养了大批具备系统化设计能力的人才。

从产业协同看，模块划分促进 “算法 - 硬件 - 代码” 的协同效率 —— 硬件团队按模块需求设计运算单元（如矩阵运算类模块对应 1369 个逻辑单元），代码团队按模块编写程序，协作冲突减少 60%；这种协同模式后续被应用于雷达、卫星通信等领域，成为我国电子设备研发的重要协作范式，推动 “需求 - 设计 - 落地” 的高效衔接。