4. 基线建立与初始版本入库

在完成版本命名规范与变更分级之后，接下来要解决一个更实际的问题：设备已经在现场运行，程序散落在工程师电脑、U盘或控制器存储卡里，如何把这些“既成事实”的现有程序，变成受控的、可追溯的初始基线？这一步做不好，后续所有变更治理都失去参照点——因为你不知道“改之前”到底是什么。本节以一台已投运的NJ/NX系列设备为例，完整走一遍首次基线冻结、项目归档、校验信息记录与入库操作。

一、先明确“基线”冻结的是什么

基线不是简单地把工程文件复制一份，而是对某一时刻“可运行程序全集”的一次快照声明。对Sysmac Studio项目而言，一个可运行程序至少包含：控制器型号与固件版本、CPU机架与扩展单元配置、任务与程序（POUs）、变量与数据类型、运动控制轴参数、EtherCAT从站配置与PDO映射、安全相关设置（如适用）、以及HMI/触摸屏工程。基线冻结意味着：以上内容在冻结时刻被确认一致，并赋予唯一版本标识，此后任何修改都必须以该基线为父版本进行记录。

需要特别提醒：控制器里实际运行的代码，与工程师电脑里最新保存的工程文件，可能并不一致。现场调试时经常出现“改了没保存”“保存了没下载”“下载了没上传”的情况。因此基线建立的第一步不是归档，而是确认来源。

二、从设备侧取回真实运行程序

推荐以控制器中的实际运行程序为准。在Sysmac Studio中通过“控制器 → 从控制器上传”操作，将当前运行项目完整上传到本地，另存为只读的原始快照文件，例如：

项目名：Line3_Filling_NJ501
快照文件：Line3_Filling_NJ501_RUN_20240612.smc2
说明：从控制器上传，未做任何修改，作为基线候选源

上传后立即核对三项关键信息：控制器型号是否为NJ501-1500、固件版本是否为1.42、EtherCAT主站配置是否与现场从站数量一致。若上传失败或版本不匹配，说明本地Sysmac Studio版本过旧，需先升级到不低于控制器固件对应的版本，否则可能丢失部分配置。

三、建立基线目录与归档结构

基线归档不能只放一个工程文件。建议按“项目—基线版本—内容分类”三层组织，目录结构如下：

Line3_Filling/
└── Baseline/
    └── V1.0.0_20240612/
        ├── Project/
        │   └── Line3_Filling_NJ501_V1.0.0.smc2
        ├── Config/
        │   ├── EtherCAT_Topology.pdf
        │   └── Axis_Parameters.csv
        ├── HMI/
        │   └── Line3_HMI_V1.0.0.njf
        ├── Checksum/
        │   └── checksum_V1.0.0.txt
        └── README.md

其中README.md记录基线冻结人、冻结日期、设备编号、控制器序列号、固件版本、上传来源（控制器/工程师电脑）、以及“本基线对应现场运行状态”的声明。这一步看似繁琐，但在半年后追查“当时到底跑的是哪版”时，它是唯一可靠的依据。

四、校验信息记录：让基线可验证

基线冻结后，必须生成可复核的校验信息。Sysmac Studio本身不直接提供工程文件哈希，但可以对归档目录中的关键文件计算SHA-256，并记录文件大小与修改时间。示例记录如下：

文件：Line3_Filling_NJ501_V1.0.0.smc2
大小：18,432,512 字节
SHA-256：3f7a9c2e1b8d4f6a0c5e7b9d2f4a6c8e1b3d5f7a9c2e4b6d8f0a2c4e6b8d0f2a
记录时间：2024-06-12 14:30:00
记录人：张工

校验信息的用途有两个：一是入库后再次取出时，可确认文件未被意外修改；二是当现场程序与基线不一致时，可通过重新上传并计算哈希，快速判断差异是否来自未受控修改。注意，哈希只证明“文件是否相同”，不证明“程序是否最优”，后者属于变更评审范畴。

五、入库操作与状态标记

将上述归档目录提交到版本库（如Git、SVN或企业级PLM/文档管理系统）。若使用Git，建议将.smc2等二进制文件通过Git LFS管理，避免仓库膨胀。入库提交信息应包含基线标识与来源：

commit: 建立Line3灌装设备初始基线V1.0.0
- 来源：NJ501-1500控制器上传
- 固件：1.42
- 冻结日期：2024-06-12
- 校验文件：checksum_V1.0.0.txt
- 状态：Baseline / Frozen

入库完成后，在版本库中为该提交打标签Line3_V1.0.0_Baseline，并将基线状态标记为“Frozen”。此后任何修改都必须从该标签拉出分支或创建新版本目录，不得直接覆盖基线文件。若企业使用Sysmac Studio的Project Version Control功能，也可在工程内创建版本快照，但建议仍保留外部归档作为独立备份。

六、常见问题与判断依据

实际操作中，最容易出问题的是“上传的程序与现场不一致”。判断方法：上传后不要急于归档，先在Sysmac Studio中执行一次“控制器 → 验证”或对比关键任务（如主任务周期、轴使能状态、EtherCAT从站在线状态）。若发现上传程序缺少某个现场已启用的功能块，说明控制器中运行的可能不是最新下载版本，此时应以控制器为准重新上传，而不是以工程师电脑中的“最新版”为准。

另一个常见问题是校验信息记录不完整。只记录文件名和日期是不够的，因为同名文件可能被覆盖。必须记录哈希值，并在入库后从版本库重新取出一份，重新计算哈希进行比对，确认“入库的”和“冻结的”完全一致。这个复核动作只需几分钟，却能避免后续大量扯皮。

七、基线冻结检查清单

为便于现场执行，以下清单可直接用于首次基线冻结的逐项确认：

完成以上步骤后，这台设备的初始基线V1.0.0即正式建立。它不一定是“最完美”的程序，但它是“当时真实运行”的程序，并且被完整记录、校验和冻结。后续任何变更，无论是修改一个定时器还是增加一个轴，都必须从这个基线出发，形成可追溯的版本链。这正是版本治理从口号落到设备上的第一步。