软件变更核对
软件数据发布到现场后，现场在调试前需根据系统发布单和软件、数据发布单来复核，确保所拿到的软件或数据正确。这一部分作为介绍了软件包的一些基本结构及基础知识，也指导开展软件烧录相关准备工作。本节以QNX的STR为例，Linux的STR除少量文件(例如Boot目录下的BSP相关文件)不同外，区别不大，原理相同。
软件数据完整性核对原理及工具
确保软件、数据完整正确的方式，是核对文件特征码，一般采用对比文件的哈希值(Hash)的方式。文件的哈希值，就能通过特定的算法，从一段数据中生成的一段固定长度较小的二进制值。一段特定的数据，相同哈希算法计算出来的哈希值是固定不变的，当该段数据发生任何改变(不管是一个字符，还是一位)，所算出来的哈希值将会不同，并且很难从哈希值反推演算出原始数据。理论上虽有不同数据段产生相同哈希值的可能(称为碰撞)，哈希算法能确保这种概率极低，完全可以忽略这种情况。目前有多种哈希算法，对于安全性要求较高的加密和数据签名等会使用最新发明的各种哈希算法，对于一般文件完整性检查等，用得最为广泛的是仍是传统的MD5和SHA1：
- Message Digest Algorithm(消息摘要算法)，其中我们常用第五版
MD5来校核数据的完整性； - Secure Hash Algorithm(安全哈希算法)，有
SHA1、MD5,SHA1,SHA128,SHA256,SHA512等，都可来校核数据的完整性。
在获取程序数据后，可使用相应的工具程序来产生MD5或SHA1值，为保证所使用的软件和数据的完整性和正确性，现场调试团队所使用的软件、数据需从调试经理处获取，不能直接去仓库获取。为防止不同版本混淆，调试经理在下载软件或数据并压缩打包后，建议使用简洁明确的命名方式；在从调试经理处得到软件、数据后，现场调试人员需再次核对确认，文件所生成的哈希值与软件或数据发布单中所标注的一致，若不一致，则表示存在错误、被修改或损坏。
哈希值计算软件比较通用，可根据自已的习惯选用，例如Quick Hash就是一个功能比较实用的开源软件，目前支持的哈希算法有MD5, SHA1, SHA256, SHA512。
若在Windows平台仅使用MD5计算和校核功能，WinMD5Free是另一个不错的选择，使用较为简单。
软件发布的目录结构
软件发布时，提供了一些包含版本后缀的压缩包，例如
1-CC-V_SW_10.2.14.zip
2-CC-NV_SW_10.2.13.zip
WS_LC_920.zip
WS_ZC_10211.zip
以上分别对应CC的ATP软件、CC的ATO软件、LC软件和ZC软件。
当软件初发布至现场，调试人员需注意核对版本后缀(本文后版本后缀均为示例，具体项可能不同)，然后在各个压缩包的各目录中存在一个文本文件保存有该目录下的各文件的哈希值。
ATP软件
1-CC-V_SW_10.2.14.zip解压缩后，其目录结构如1-CC-V_SW_10.2.14 ├─CC-V-ATP 10.2.14 │ ├─CC-ATP_ASW │ │ ├─ATP_ASW_10.2.14 │ │ │ ├─Prog_FTP │ │ │ │ ├─No_Split │ │ │ │ │ exe.F800 │ │ │ │ │ md5_FTP_CHK_V10.2.14.txt │ │ │ │ │ │ │ │ │ └─Split_512k │ │ │ └─Prog_probe │ │ │ CC-ATP_ASW_V10.2.14 │ │ │ md5_Probe_CHK_V10.2.14.txt │ │ │ │ │ └─CC-ATP_ASW-HOST_10.2.14 │ │ └─... │ └─CC_ATP_OMAP_DB │ └─... └─CC-V-ES 10.2.5 └─...其中，
exe.F800是使用cp或winscp传入操作系统/dev/vital设备进行烧录的方法所使用的文件(参见后续章节)，而使用ColdFire烧录时，把类似CC-ATP_ASW_V10.2.14的文件重命名增加后缀.elf后选择使用(参见后续章节)。在ATP软件对应的文件目录中，存在MD5信息的文本文件，我们用来核对文件的完整性。
ATO软件
2-CC-NV_SW_10.2.13.zip解压缩后，其目录结构如下，2-CC-NV_SW_10.2.13 ├─CC-NV-ATO 10.2.13 │ ├─CC-ATO_ASW │ │ ATO.exe │ │ org_mpc_tsk_ato MD5 checksum.txt │ │ org_mpc_tsk_ato.elf │ │ │ └─CC-ATO_OMAP_DB │ └─... ├─CC-NV-ES 10.2.7 │ └─... └─CC-NV-MNT 10.2.5 ├─CC-MNT_ASW │ MNT.exe │ org_mpc_tsk_mnt MD5 checksum.txt │ org_mpc_tsk_mnt.elf │ └─CC-MNT_OMAP_DB其中，
org_mpc_tsk_ato.elf是ATO软件，org_mpc_tsk_mnt.elf则是为OMAP及MSS维护工具提供信息的软件。同样，在其目录下有相应的确MD5值信息的文本文档，用来核对程序的完整性。ZC软件
ZC的软件WS_ZC_10211.zip展开后，目录结构则如下WS_ZC_10211 ├─OMAP_UEVOL_ZC_10211 ├─TK_ZC_ASW_10211 │ KRN_UEVOL_v2.0_A.s3 │ sml4ilk_128MB_Settings.reg │ TDM_UEVOL_v2.0_A.s3 │ zc_application_A.txt │ zc_application_B.txt │ zc_application_C.txt │ zc_v10211_A.s3 │ zc_v10211_A.sha │ zc_v10211_B.s3 │ zc_v10211_B.sha │ zc_v10211_C.s3 │ zc_v10211_C.sha │ ├─ZC_host_windows_non_sync_10211 └─ZC_host_windows_sync_10211所需软件在子目录
TK_ZC_ASW_10211下，以扩展名.s3结尾的是软件，基本文件名部分的结尾为_A(_B,_C)表明了该软件是对应3oo3平台的通道A(B,C)的。这个目录中的文本文件与CC的不同，不是保存哈希值的。这里保存程序文件的是SHA1值，放在以扩展名.sha的对应文件中，也可用来校验对应文件名的程序文件是否完整正确。在我们使用Media Card Programmer程序(参见后续章节)来烧录USB Key时，该程序也会再次通过些'SHA1'值来查找对应的程序，相当于进行了一次校验。sml4ilk_128MB_Settings.reg则是在Windows下烧录USB Key时导入注册表对该类USB Key的一些参数配置，供烧录程序使用。注意：因三个通道的程序采用不同算法编写，必须对应使用，一般
A通道的软件比其它通道的软件文件数多。LC软件
LC的软件
WS_LC_920.zip解压缩后，目录结构除名称不同外，基本上与ZC的相同。WS_LC_920 ├─LC_host_unix_920 ├─LC_host_windows_920 ├─OMAP_DB_LC_703 └─TK_LC_ASW_920 KRN_UEVOL_v2.0_A.s3 lc_application_A.txt lc_application_B.txt lc_application_C.txt lc_v920_A.s3 lc_v920_A.sha lc_v920_B.s3 lc_v920_B.sha lc_v920_C.s3 lc_v920_C.sha sml4ilk_128MB_Settings.reg TDM_UEVOL_v2.0_A.s3
数据发布的目录结构
Result
├─App Conf
│ │ App Conf.rar
│ │
│ └─intermediate data
├─Beacon layout
├─LEU
│ └─...
└─UNIVIC Conf
UNIVIC Conf.rar
数据发布结构与软件不同，一般把各组件压缩成一个文件，放置在发布目录，其中
App Conf.rar是CC及ZC/LC的软件数据UNIVIC Conf.rar则是STR、Opera及应用层的配置
我们在系统发布单指定对应的数据发布单中，例如A511007_KMLF_CASCO_7117_ATC data Delivery Sheet For Onsite.pdf，在ATC数据发布配置一章，可看到如图所示：
其中的App Conf 1.8.0最后一栏Checksum后的一串十六进制数据，既是App Conf.rar的MD5值，UNIVIC Conf 4.10.0的Checksum后的一串十六进制数据，则是UNIVIC Conf.rar的MD5值。用这些MD5值来对应检查相应数据包的完整和正确性。
App Conf的结构在解压缩
App Conf 1.8.0.rar后，其目录结构如下App Conf_V1.8.0 │ CheckSum.md5 │ ├─+2 Data SGD & VES to be used │ └─... ├─+3 ZC │ └─... └─+4 LC └─...其中
CheckSum.md5，是保存有整个目录树的所有文件的MD5值列表的文本文件，可以用来配合WinMD5Free来对整个目录树的文件进行MD5比较校核，查看文件是否与CheckSum.md5中列表的一致。+2 Data SGD & VES to be used中的是CC使用的ATP和ATO数据+3 ZC中的是各个ZC的数据+4 LC中的是LC的数据
ATP和ATO数据目录结构如下
2 Data SGD & VES to be used └─2 = VES&NVES_V35.1 conf.F880 NVES O1-SpecificFields.xml O8-SpecificFields.xml SpecificEnumerates.xml Train_type_1.NVES Train_type_1.VES Train_type_nvs.txt Train_type_nvs_L2.txt VES ves.s19这里的
conf.F880和ves.s19是ATP的数据，与ATP软件类似，使用cp或winscp传入操作系统/dev/vital设备进行烧录的方法所使用conf.F880文件(参见后续章节)，而使用ColdFire烧录时使用ves.s19(参见后续章节)。NVES则是ATO的数据。其它文件现场不需使用。ZC/LC数据ZC和LC的结构相似，一般一条线只有一个LC，可有多个ZC。现以ZC为例3 ZC └─ZC_v35 └─s3 ├─ZC1 │ cfg_result.log │ ZC_201_appli_v35_A.s3 │ ZC_201_appli_v35_B.s3 │ ZC_201_appli_v35_C.s3 │ ZC_201_database_v35.sha │ ZC_201_fsfb2_v35_A.s3 │ ZC_201_fsfb2_v35_B.s3 │ ZC_201_fsfb2_v35_C.s3 │ ZC_201_krn_v35_A.s3 │ ZC_201_krn_v35_B.s3 │ ZC_201_krn_v35_C.s3 │ ZC_201_peer_v35_A.s3 │ ZC_201_peer_v35_B.s3 │ ZC_201_peer_v35_C.s3 │ ZC_201_uevol_v35_A.s3 │ ZC_201_uevol_v35_B.s3 │ ZC_201_uevol_v35_C.s3 │ ├─ZC2 ├─ZC3 └─ZC4目录名称中有该数据版本号为后缀，这里是
v35，数据同ZC软件，扩展名为.s3的是具体的数据，为.sha的是SHA1值表，基本文件名有版本和通道号做为后缀(可参考前面ZC软件部分描述)。Univic Conf的结构Univic Conf是整个Univic系统的支撑或配置，包括从操作系统到Opera平台和应用层的各个组件。目录结构具体如下：UNIVIC Conf_V4.10.0 ├─Config_V4.10.0 │ ├─Boot │ │ bootLoaderMen.pmm │ │ imageMen.F004 │ ├─SingleGTW │ │ └─disk │ │ ├─dev │ │ │ └─ppu │ │ │ ppu0_iccd1.F024 │ │ │ ppu0_iccd2.F025 │ │ │ ppu0_iccd3.F026 │ │ │ ppu1_bin.F004 │ │ │ ppu1_conf.F027 │ │ │ ppu2_bin.F004 │ │ │ ppu2_conf.F027 │ │ │ ppu3_bin.F004 │ │ │ ppu3_conf.F027 │ │ ├─etc │ │ ├─project │ │ └─usr │ ├─tgt_mpc │ │ └─disk │ │ ├─dev │ │ │ └─vital │ │ │ conf.F880 │ │ │ exe.F800 │ │ ├─etc │ │ │ ip_maint.sh │ │ │ ... │ │ ├─project │ │ │ ├─bin │ │ │ │ NVES │ │ │ │ org_mpc_tsk_ato.elf │ │ │ │ org_mpc_tsk_mnt.elf │ │ │ └─conf │ │ └─usr │ │ ├─bin │ │ ├─lib │ │ ├─opera │ │ │ ├─bin │ │ │ ├─conf │ │ │ └─lib │ │ └─web │ ├─tgt_dmi │ ├─Patch_Single_core_viom │ ├─_data_generated │ └─_ip_maint_cab2 │ ip_maint.sh ├─DMI_v20 │ KMLF_V20.PCC ...上图中，
KMLF_V20.PCC是DMI烧录所需使用的整个系统镜像文件，bootLoaderMen.pmm则是在烧录GTW、CMP等板卡的BootLoader，而imageMen.F004则是QNX操作系统镜像文件，GTW板卡需烧录Opera及板卡配置的文件对应的目录SingleGTW/disk/中除dev目录外的所有内容(至不包含这个目录的原因，请参考操作系统章节)，CMP需烧录Opera及板卡配置使用对应于tgt_mpc/disk中除dev目录外的所有内容，tgt_dmi则是烧录DMI使用的(在191基线中没见使用介绍，不知是何原因)。其中，位于
SingleGTW/disk/dev/ppu/下的，是烧录PPU所需的相关文件：以.F004和.F027分别是PPU的软件和配置，而.F024、.F025和.F026则是烧录至FPGA的文件。位于
tgt_mpc/disk/dev/vital/的exe.F800和conf.F880，则是为方便而把该数据发布版对应的ATP软件和数据拷贝放置于此，主要用来采取cp或winscp传入操作系统/dev/vital设备进行烧录的方式所使用。位于
tgt_mpc/disk/etc/下的ip_maint.sh，是配置CMP面板维护网口地址的配置文件，默认放置的是列车车头(相对参考端)CMP的IP配置，若是烧录列车尾端(相对参考端)的CMP,则需从_ip_maint_cab2拷来替换此文件。位于
tgt_mpc/disk/project/bin/下的org_mpc_tsk_ato.elf和NVES，分别是ATO的软件和数据，在烧录时对应替换文件即可。
软件和数据变更核对
由于发布的软件和数据的App Config部分，供烧录使用的文件数量较少，一方面通过核对软件包或包内文件名版本后缀来检查确认，另外一方面直接比较发布单中的这些包的哈希值，就能确认完整性，能较容易判定变更范围。数据发布包中Univic Conf部分，包含了从系统的BootLoader，到操作系统、Opera平台、应用配置等很多部分，文件较多，不能单从整个包的版本变化来确定变更范围，具体变更范围的确定则要相对困难。下面主要描述如何核对确定这部分在数据发布后的变更范围，也就是升级范围。
在Univic Config部分版本变化后，为确认新、旧版本间具体的变化内容，我们需准备当前装备配置版本，和升级目标版本，把这两个软件包分别解压缩后，利用目录文件比较工具来进行比较，根据比较结果来确定变更(升级)所受影响的文件列表。
能胜任目录比较工作的常用的比较工具除有著名的UltraCompare、Compare It!、Beyond Compare等外，也有开源的WinMerge等。这里介绍WinMerge，安装后可选择比较两个目录的所有文件
根据对比结果，我们可以知道那些文件不同，从而能准确判定变更范围。