软件变更核对

软件数据发布到现场后,现场在调试前需根据系统发布单和软件、数据发布单来复核,确保所拿到的软件或数据正确。这一部分作为介绍了软件包的一些基本结构及基础知识,也指导开展软件烧录相关准备工作。本节以QNXSTR为例,LinuxSTR除少量文件(例如Boot目录下的BSP相关文件)不同外,区别不大,原理相同。

软件数据完整性核对原理及工具

确保软件、数据完整正确的方式,是核对文件特征码,一般采用对比文件的哈希值(Hash)的方式。文件的哈希值,就能通过特定的算法,从一段数据中生成的一段固定长度较小的二进制值。一段特定的数据,相同哈希算法计算出来的哈希值是固定不变的,当该段数据发生任何改变(不管是一个字符,还是一位),所算出来的哈希值将会不同,并且很难从哈希值反推演算出原始数据。理论上虽有不同数据段产生相同哈希值的可能(称为碰撞),哈希算法能确保这种概率极低,完全可以忽略这种情况。目前有多种哈希算法,对于安全性要求较高的加密和数据签名等会使用最新发明的各种哈希算法,对于一般文件完整性检查等,用得最为广泛的是仍是传统的MD5SHA1

  • Message Digest Algorithm(消息摘要算法),其中我们常用第五版MD5来校核数据的完整性;
  • Secure Hash Algorithm(安全哈希算法),有SHA1MD5, SHA1, SHA128, SHA256, SHA512等,都可来校核数据的完整性。

在获取程序数据后,可使用相应的工具程序来产生MD5或SHA1值,为保证所使用的软件和数据的完整性和正确性,现场调试团队所使用的软件、数据需从调试经理处获取,不能直接去仓库获取。为防止不同版本混淆,调试经理在下载软件或数据并压缩打包后,建议使用简洁明确的命名方式;在从调试经理处得到软件、数据后,现场调试人员需再次核对确认,文件所生成的哈希值与软件或数据发布单中所标注的一致,若不一致,则表示存在错误、被修改或损坏。

哈希值计算软件比较通用,可根据自已的习惯选用,例如Quick Hash就是一个功能比较实用的开源软件,目前支持的哈希算法MD5, SHA1, SHA256, SHA512

Quick Hash

若在Windows平台仅使用MD5计算和校核功能,WinMD5Free是另一个不错的选择,使用较为简单。

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是使用cpwinscp传入操作系统/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.elfATO软件,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.rarCCZC/LC的软件数据
  • UNIVIC Conf.rar则是STROpera及应用层的配置

我们在系统发布单指定对应的数据发布单中,例如A511007_KMLF_CASCO_7117_ATC data Delivery Sheet For Onsite.pdf,在ATC数据发布配置一章,可看到如图所示:

ATC数据发布配置

其中的App Conf 1.8.0最后一栏Checksum后的一串十六进制数据,既是App Conf.rarMD5值,UNIVIC Conf 4.10.0Checksum后的一串十六进制数据,则是UNIVIC Conf.rarMD5值。用这些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使用的ATPATO数据
    • +3 ZC中的是各个ZC的数据
    • +4 LC中的是LC的数据
  • ATPATO数据

    目录结构如下

      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.F880ves.s19是ATP的数据,与ATP软件类似,使用cpwinscp传入操作系统/dev/vital设备进行烧录的方法所使用conf.F880文件(参见后续章节),而使用ColdFire烧录时使用ves.s19(参见后续章节)。NVES则是ATO的数据。其它文件现场不需使用。

  • ZC/LC数据

    ZCLC的结构相似,一般一条线只有一个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则是在烧录GTWCMP等板卡的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.F800conf.F880,则是为方便而把该数据发布版对应的ATP软件和数据拷贝放置于此,主要用来采取cpwinscp传入操作系统/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.elfNVES,分别是ATO的软件和数据,在烧录时对应替换文件即可。

软件和数据变更核对

由于发布的软件和数据的App Config部分,供烧录使用的文件数量较少,一方面通过核对软件包或包内文件名版本后缀来检查确认,另外一方面直接比较发布单中的这些包的哈希值,就能确认完整性,能较容易判定变更范围。数据发布包中Univic Conf部分,包含了从系统的BootLoader,到操作系统、Opera平台、应用配置等很多部分,文件较多,不能单从整个包的版本变化来确定变更范围,具体变更范围的确定则要相对困难。下面主要描述如何核对确定这部分在数据发布后的变更范围,也就是升级范围。

Univic Config部分版本变化后,为确认新、旧版本间具体的变化内容,我们需准备当前装备配置版本,和升级目标版本,把这两个软件包分别解压缩后,利用目录文件比较工具来进行比较,根据比较结果来确定变更(升级)所受影响的文件列表。

能胜任目录比较工作的常用的比较工具除有著名的UltraCompareCompare It!Beyond Compare等外,也有开源的WinMerge等。这里介绍WinMerge,安装后可选择比较两个目录的所有文件

WinMerge

WinMerge

根据对比结果,我们可以知道那些文件不同,从而能准确判定变更范围。

results matching ""

    No results matching ""