一种基于铁路行车场景模板的行车日志压缩方法

技术领域

本发明涉及高速铁路调度系统技术领域，尤其涉及一种基于铁路行车场景模板的行车日志压缩方法。

背景技术

高速铁路行车调度系统是铁路运输日常组织工作的指挥中枢。作为重要辅助，日志模块在线或离线记录各业务子系统的硬件运行状态、外部运行环境、软件业务逻辑以及异常情况下的错误故障等信息，是时间轴线中有序追加的事实行为集合的记录者和提供者。可靠高效的行车日志记录，可以满足管理部门审计要求，追踪记录程序执行变化，广泛应用于现场问题定位、仿真回放测试、历史数据挖掘和运输模式优化等领域。但现有海量行车日志分散存储于各终端节点，存在以下问题：1)日志模块紧耦合核心业务，独立性差；2)日志记录格式随意，存储规则不统一，增大后期解析难度；3)日志数据直接以原始数据流形式存储于终端，冗余信息巨大，空间浪费严重；4)数据冗余同样对网络传输产生极大压力，不利于数据的实时监控和分析。部分系统以通用压缩方式存储或直接网络传输至日志服务器，但仍未从根本上解决以上缺陷。

作为细分领域的特有日志，铁路行车日志在具有传统日志通用特性的基础上，额外呈现着铁路行车的独有业务特点，包括：1)单车次行车日志严格顺序递增；2)多车次行车的多会话逻辑日志交错混合；3)单车次行车日志逻辑具有业务场景相关性。

随着高速铁路建设步伐的加快和信息系统的普及，行车日志呈现数据量爆炸式增长趋势，在现有终端计算能力和网络带宽限定下，结合铁路行车日志特点，通过日志记录模板提取和协议规划，设计一种高存储效率和传输效能的铁路调度系统日志方法，对于行车调度系统的稳定运行和智能改进有极大促进作用。

目前，主要采用如下几种方案处理日志数据。

方案一、日志数据以原始数据流形式存储于网络终端节点。

方案一中，日志数据按存储模式是否压缩，分为原始数据直接存储和压缩存储2种。各子系统内嵌日志模块，实现业务模块与日志模块的紧耦合。系统在行车调度操作的同时，直接输出业务状态信息到本地硬盘，现场多以文本方式进行日志数据的原始直接存储记录。

方案一的缺陷在于：铁路行车调度系统中，大量车站工控主机硬件性能较差，存储资源紧张。日志模块无法记录完整业务流程。原始信息的缺失增加了故障问题定位和历史数据使用的难度；日志中冗余信息的存在极大增加了节点存储压力和网络传输压力，难以对数据进行有效的实时监控和分析；由于日志模块的业务紧耦合特性，日志记录规则和格式依赖于子系统的具体实现，不利于数据的自动化提取和解析，日志数据中价值信息的挖掘困难

方案二、原始日志数据按类型和等级，以压缩形式存储于网络终端节点。

方案二中，按描述事件的归属，日志类型可分为系统日志、业务日志和故障日志等。按记录问题的严重程度，日志等级可分为非常严重、严重、一般、较为轻微和非常轻微等。将原始日志按类型和等级分类输出，并对数据流进行通用压缩和存储，可以在方案一的基础上，一定程度降低数据冗余，提高数据存储和传输效率，有利于数据分析和挖掘。方案二中的压缩操作，按压缩时效性分为离线压缩和在线压缩，其中在线压缩又细分为实时压缩和伪实时压缩。按压缩适配性，分为通用压缩和专用压缩。现场实现中，可根据需要灵活选用。

方案二的缺陷在于：作为日志数据标签，日志类型和等级的引入并未对日志数据存储格式和协议进行有效统一；大量原始数据流的直接压缩，增加了前端节点的计算压力；方案二降低了方案一中的数据冗余度，但仍有较大提升空间；日志数据的解析和使用涉及反向解压，在增加计算量的同时，解压后的数据仍需要较大存储空间。

方案三、在方案一或方案二的基础上，日志数据由本地存储改为日志服务器集中存储。

方案三中，将原始日志数据流或压缩后的日志数据，通过网络传输到日志服务器，由其进行集中存储和使用。

方案三的缺陷在于：虽然解决了终端存储资源不足的问题，但仍未有效解决方案一和方案二的其他问题。此外，日志数据的冗余度和网络通道质量，对网络传输过程有较大影响。

发明内容

本发明的目的是提供一种基于铁路行车场景模板的行车日志压缩方法，将日志数据统一归集和管理，并且可以提升数据存储效率，降低终端存储压力，降低网络传输压力。

本发明的目的是通过以下技术方案实现的：

一种基于铁路行车场景模板的行车日志压缩方法，包括：

网络终端节点判断当前是否开启基于场景的日志处理逻辑；

若是，则提取一段日志数据，确定对应的行车场景模板类别，并与确定的行车场景模板进行场景单元匹配；每一类行车场景模板包含了多个行车场景，行车场景为场景单元，分配唯一场景单元ID；单一行车场景包含了多个业务阶段，每一业务阶段称为一个行车场景节点，每个行车场景节点记录了相应业务流程所包含的事件、对象及对象状态；每一行日志数据记录了即时时刻业务状态，对应单一的行车场景节点，通过提取一行日志数据中的事件、对象及对象状态，即可完成日志数据与场景单元的匹配；匹配成功后，将每一行日志数据中的事件、对象及对象状态按照相应场景单元的格式处理为节点结构体信息；根据场景单元的结束特征判断日志数据对应的行车场景是否结束，若是，则构造当前行车日志的ID以及各节点的ID，按照对应的行车场景模板，综合日志ID以及所有节点结构体信息及对应的节点ID，获得当前行车日志；之后，根据预先的设置对当前行车日志进行压缩或非压缩后做持久化操作；其中，构造的日志ID全局唯一，不能产生数据冲突；构造的节点ID在所属行车日志中唯一。

由上述本发明提供的技术方案可以看出，1)用于实现行车日志压缩的日志模块松耦合于业务模块，功能独立，可靠性高，后期升级维护便捷；2)在网络终端计算量较少增加的前提下，大幅提高数据存储效率，降低终端存储压力。同时连带提高网络传输效率，有助于日志数据的统一归集、管理和分析；3)可以降低的日志数据冗余，有利于日志数据挖掘和价值提取。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他附图。

图1为本发明实施例提供的一种基于铁路行车场景模板的行车日志压缩方法的流程图；

图2为本发明实施例提供的铁路行车场景及关联模型关系图；

图3为本发明实施例提供的行车指令状态转换示意图；

图4为本发明实施例提供的控制命令状态转换示意图；

图5为本发明实施例提供的场景模板存储格式示意图；

图6为本发明实施例提供的行车场景模板的定制及动态更新流程图。

具体实施方式

下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明的保护范围。

本发明实施例提供一种基于铁路行车场景模板的行车日志压缩方法，其主要包括：

首先，网络终端节点判断当前是否开启基于场景的日志处理逻辑(步骤S06)。

本发明实施例中，网络终端节点可以是各类铁路行车信息系统，例如，可以是行车调度子系统(包括行车调度子系统中位于铁路局中心的助调台，位于前端车站的自律机、车务终端等)。参见图1左侧虚线框中给出的流程，如果开启基于场景的日志处理逻辑，则执行如下步骤：

步骤S10、场景单元匹配。

本步骤根据行车场景模板(行车指令状态转换场景模板、控制命令处理场景模板等)以及模板内场景单元特征定义，通过日志条目数据中目标对象提取以及目标对象即时状态，确定本条日志数据与特定场景单元的匹配情况，即查找本条日志数据对应场景单元的ID。对场景单元中的首节点，记录场景基准时间；对场景单元中的非首节点，记录节点偏移时间。

本发明实施例中，预先建立了多个类别的行车场景模板。每一类行车场景模板对应一个大类别下的多个行车场景。定义行车场景为场景单元，分配唯一场景单元ID。单一行车场景包含了多个业务阶段，每一业务阶段称为一个行车场景节点，每个节点记录了相应业务流程所包含的事件、对象及对象状态。每一行日志数据记录了即时时刻业务状态，对应单一的行车场景节点。通过提取一行日志中的事件、对象及对象状态，即可完成日志数据与场景单元的匹配。匹配成功后，再将日志数据中每一节点的事件、对象及对象状态按照场景单元的模版格式处理为节点结构体信息。

基于以上原理介绍，本步骤可以理解为三个子步骤：1)提取一段日志数据，确定其对应的行车场景模板类别；2)将每一行日志数据与场景单元进行匹配，从而确定日志数据所述的场景单元；3)将一行日志数据抽象为预定格式的数据节点。

步骤S11、场景单元中的节点缓存。

本步骤主要是将前述步骤得到的节点结构体信息缓存。

步骤S12、判断当前行车场景是否结束。

本发明实施例中，可以利用行车场景模板中行车场景结束特征判定场景逻辑是否结束。例如，后文表1中提到的场景ID＝001的“行车自动触发成功”行车场景，T5状态序列的发生，代表该场景的结束。场景逻辑未结束时，持续等待。S11步骤中缓存节点链表可能同时对应若干场景，以最先匹配的完整场景为S12结束条件。

步骤S13、构造基于行车场景模板的行车日志。

在当前行车场景结束后，构造当前行车日志的ID以及各节点的ID，按照设定的行车场景模板，综合日志ID、当前行车场景的类别以及所有节点结构体信息，获得当前行车日志。

本发明实施例中，构造的日志ID全局唯一，不能产生数据冲突；构造的节点ID在所属行车日志中唯一。关于日志ID与节点ID的构造方式、以及行车场景模板的格式及其内容将在后文进行说明。

步骤S14、判断是否进行行车日志的压缩。

本发明实施例中，根据预先的设置对当前行车日志进行压缩或非压缩操作。

本发明实施例中，是否对行车日志进行压缩可以按照需求自行设定，同时压缩算法也根据实际需要灵活设定。

步骤S15、行车日志的持久化操作。

本发明实施例中，各网络终端节点可以将压缩或者未压缩的行车日志进行转存，例如：通过本地硬盘进行存储，由内存中数据模型转换为本地存储模型，或者通过网络发送至中心日志服务器，由日志服务器转换为本地存储模型。

可选的，数据持久化操作中的网络传输技术，可根据需要采用消息中间件技术。

以上为本发明实施例提供的行车日志压缩方法的主体流程，所涉及的技术细节将在后文做详细说明。图1中上方虚线所示的基本逻辑、右侧所示的既有日志处理逻辑均为现有技术，下面针对这两部分逻辑做简要说明。

1、基本逻辑。

步骤S01、日志模块启动，初始化相关参数，包括日志缓存区大小、日志缓存时限、压缩参数等。本发明实施例中，日志模块设于各个网络终端节点。

步骤S02、读取日志模板。随着行车调度系统的开发，业务场景逐步扩展，部分场景微调。日志模块在基础核心功能不变的情况下，通过完整读取日志场景模板或热更新的方式，实现行车日志模板的定制化和适配性。

步骤S03、接收业务日志。日志模块以松耦合和低优先级方式持续接收业务模块日志信息，以较为独立和不影响业务处理效能的方式处理日志。

可选的，通过消息中间件解耦日志模块和业务模块。

步骤S04、日志规整。对业务直输日志进行：1)数据清洗，过滤无效日志；2)格式化转换和规整；3)更新时间标签等附加信息，使其统一、易读，便于后续处理。

步骤S05、日志输出。将规整化的日志数据交由相关分支单元处理。

步骤S06、判断是否开启基于场景的日志处理。

2、既有日志处理逻辑。

步骤S21、无论基于场景的日志处理逻辑是否开启，基础逻辑步骤S05中的信息都持续发送至日志缓存。

日志缓存的目的是：1)提升日志响应速度，减少频繁的硬盘操作；2)避免基于场景的日志处理逻辑失效时的日志丢失问题。

步骤S22、判断缓存是否已达上限。在未开启基于场景的日志处理逻辑时，缓存日志上限取决于步骤S01中从配置文件读取的缓存参数；开启基于场景的日志处理逻辑时，接收步骤S13的已处理完结日志最晚时间通知，并完结时间以前的缓存日志输出至步骤S23。

步骤S23、普通日志压缩判断。对缓冲溢出的日志进行压缩处理判断。

步骤S24、普通日志压缩操作。压缩开关打开时，对普通日志进行压缩操作。同步骤S14，压缩算法的选取可根据实际需要灵活设定。

步骤S25、普通日志持久化操作。对S23直输普通日志或S24压缩后的普通日志进行转存。

步骤S13与步骤S22交互的已处理完结日志最晚时间，为步骤S13已处理的场景日志集合与步骤S03已接收业务日志集合的差值中，最早日志时间。该时间概念及通知机制的引入，可以保证个别日志未匹配场景模板时，仍可以得到有效存储和记录。

为了便于理解，下面针对本发明实施例提供的行车日志压缩方法中所涉及的各项技术细节做详细介绍。

一、铁路行车场景的提取和规范。

本发明实施例中，确定铁路行车调度过程中待研究问题粒度；通过底层独立或半独立的原子问题细节化规则知识，抽象由事件、对象、对象状态组成的上层通用行车场景规范，建立行车场景数据库(也即行车场景模版)。

铁路行车场景的覆盖范围直接关系到实际行车业务记录到日志压缩节点的转换率。本发明实施例中，通过梳理行车业务中操作对象模型和事件模型来提取和规范行车场景，确定各模型中最小粒度原子问题；铁路行车场景，事件驱动对象在各个对象状态间跳转，各单元关系如图2所示。

行车场景的内容包括：场景知识、场景规则、对象实例列表与事件实例列表。其中，场景知识可以理解为场景的说明或场景的备注；例如，后文表1中提到的场景ID＝001的“行车自动触发成功”，场景知识可概括为一段文字描述，即“列车指令自动触发并且排路成功的业务逻辑”；场景规则，是本场景单元的特征信息，可以作为场景单元匹配的依据，仍以场景ID＝001为例，列车指令的状态为T1-T2-T3-T4-T5，当某个日志数据能够满足这个序列或规则，则认为匹配为场景ID＝001的日志。

事件实例列表是铁路行车调度过程中的标志性动作集合，抽象事件实例为独立模型，将单个事件用四元组<事件标识、事件描述、操作、关联对象>进行完整描述。

本领域技术人员可以理解，标志性动作一般为系统内部对象状态变化的触发因素。以分散自律调度集中系统中列车指令为例，它由“等待”状态变为“触发中”状态的标志性动作为“向联锁发送排路命令”，由“触发中”状态变为“排路成功”状态的标志性动作为“收到进路锁闭和信号机开放的表示信息数据”。不同对象的状态变化，对应的事件不同，标志性动作也不同。四元组中的操作也即相应事件对应的操作，例如“对外发送排路命令”、“收到进路锁闭和信号机开放的表示信息数据”等。

对象实例列表是铁路行车调度过程中产生的具体对象集合；抽象对象实例为独立模型，将单个对象用四元组<对象标识、对象属性、对象状态、附加信息>进行完整描述，对象状态包含了状态标识、状态描述与状态属性。

本领域技术人员可以理解，对象是本领域的专用数据。以行车调度系统中自律机为例，对象可为自律机程序内部的指令对象、控制命令对象和进路预告对象等。

本发明实施例中，根据铁路行车领域特点和工程实现业务逻辑，抽取典型对象包括行车指令对象、控制命令对象和进路预告对象；各对象在不同事件驱动下，进行各自的状态跳转，以此构成三类行车场景：行车指令状态转换场景、控制命令处理场景和进路预告处理场景，下面针对各个行车场景进行介绍。

1、行车指令状态转换场景。

行车指令是调度系统将调度员编写的阶段计划映射到相应站场对象集合及其状态的操作序列，以控制后续命令操作和预告操作的处理时机。行车指令分为列车指令和调车指令；其中，列车指令分为接车指令、发车指令和通过指令；根据外部事件(例如，列车运行状态、站场显示、车次追踪结果以及排路控制命令执行情况等外部事件)驱动，行车指令映射到7种指令状态集合：等待(标识符为T1，下同)、已触发(T2)、排路成功(T3)、进路占用(T4)、进路出清(T5)、重试(T6)和失败(T7)。

行车指令对应调度系统软件开发中的指令类，指令状态则对应为指令类的状态成员变量；调度系统可以很容易监控指令类的状态参数变化，即行车指令的状态变化。典型行车指令的状态迁移图如图3所示。行车指令对象、对象状态和事件在一段时间轴上的集合，构成行车指令状态转换场景。

本发明实施例中，提供了表1所示的行车指令状态转换场景，行车指令状态转换场景的场景ID起止范围为001～299。

表1行车指令状态转换场景

场景独有特征是基于场景的日志的提取依据。在行车调度系统的指令类中，增加指令历史状态转换记录集。在指令状态跳转时刻，将指令的上一状态压入历史集，然后匹配状态历史集与表1中场景的状态序列，实现实际行车流程与行车指令状态转换场景的映射。

2、控制命令处理场景。

控制命令是行车指令排路意图的业务实现，负责调度系统与联锁系统交互命令的创建、监控命令的完整生命周期管理工作；控制命令分为排路命令和非排路命令；根据车站现场设备状态和联锁采集结果，控制命令映射到四种命令状态集合：命令排队等待发送(标识符为C1，下同)、命令已发送至联锁(C2)、命令执行成功(C3)和命令超时失败(C4)。

同行车指令及其状态类似，调度系统根据表示信息监控控制命令的状态变化。典型控制命令的状态迁移图如图4所示。控制命令对象、对象状态和事件在一段时间轴上的集合，构成控制命令处理场景。

本发明实施例中，提供了表2所示的控制命令处理场景，控制命令处理场景中场景ID的起止范围为301～599：

表2控制命令处理场景

在行车调度系统的命令类中，增加命令历史状态转换记录集。在控制命令状态跳转时刻，将命令的上一状态压入历史集，然后匹配状态历史集与表2中场景的状态序列，实现实际控制命令处理流程与控制命令状态转换场景的映射。

3、进路预告处理场景。

进路预告是调度系统通过无线调令的文字方式向机车司机提供进路预告信息的业务实现，分为接车进路预告和发车进路预告；进路预告状态包括：等待发送(标识符为F1，下同)、已发送等待回执(F2)、超时重发(F3)、已成功接收回执(F4)、失败(F5)。

同行车指令和控制命令类似，调度系统实际运行中，在适当时机主动对外发送进路预告信息，并接收机车/司机的自动/人工预告回执信息；根据预告发送和确认回执状况，更新维护内部进路预告对象的状态；通过历史状态集合，实现进路预告处理流程与相应场景的映射。进路预告对象、对象状态和事件在一段时间轴上的集合，构成进路预告处理场景。

本发明实施例中，提供了表3所示的进路预告处理场景，进路预告处理场景中场景ID的起止范围为601～899：

表3进路预告处理场景

需要说明的是，前文给出的各行车场景、行车场景所包含的场景单元及其内容、各场景单元的ID等具体信息均为举例，并非构成限制；在实际应用中，用户可以根据实际情况调整相应的具体信息及其定义。

二、行车场景模板及基于行车场景模板的行车日志。

本发明实施例中，设计了如图5所示的行车场景模板的存储格式，其中节点ID与日志ID由网络终端节点(也即现场设备)生成，相关的生成方法将在后文进行介绍。

本发明实施例中，还设计了基于行车场景模板的行车日志存储协议。以行车指令状态转换场景(场景ID＝001)为例，场景中，列车G777在车站A的接车指令自动触发且正常占用并出清，一段典型的日志数据如表4所示。

表4行车自动触发成功场景日志实例

对上述日志数据进行分析，得出如下结论：

1、日志具有特定规范格式。上表实例中日志由时间标签、车站站名、业务描述组成。

2、日志条目具备严格时间递增属性。作为一致性问题描述的关键数据结构，无论是否显示标明时间项，日志都是天然自带时间属性的操作序列。

3、日志由固定文本标签和可变属性值之一或联合组成，其中标签属性的候选集状态有限且常用属性出现概率远超平均值。如实例中独立可变属性值“[G777接车X-3G]”、联合项的“车次＝[G777]”和“指令状态[占用->出清]”等。

4、日志具有冗余结构。

本发明实施例中，按照图5所示的行车场景模板，设计了行车日志的存储协议，综合日志ID、当前行车场景的类别以及所有节点结构体信息，获得当前行车日志。

如表5所示，行车日志的存储协议内容包括：日志固定头部信息与节点信息；其中：日志固定头部信息包括：日志ID、日志等级、场景ID、场景文字描述、场景基准时间、数据总长度、节点个数、以及压缩标识；所述场景ID根据行车场景的类别设定，所述场景基准时间为日志数据中首个条目对应的时间；节点信息包括：所有节点的结构体信息，每一节点的结构体信息包括：节点ID、节点的等级、节点的偏移时间、关联对象ID、关联对象状态ID、关联事件ID与节点的备注；所述节点的偏移时间是指节点相对于场景基准时间的偏移量。

表5基于行车场景的行车日志存储协议

本领域技术人员可以理解，日志等级是本领域通用概念，例如，背景技术中介绍的方案二也针对日志等级进行了说明。节点的等级表征节点在行车场景业务逻辑中的重要程度，具体取值可根据实际情况自行设定，当前阶段作为预留扩展字段。

三、日志ID及节点ID生成方法。

铁路调度系统中，大量网络终端节点产生的日志需要归集存储于日志服务器进行统一集中归档、分析和数据挖掘。这就要求归档时段内，分布式创建的日志ID不能产生数据冲突。在同一网络终端内部，不同场景的业务逻辑交错运行，归属于多场景日志的节点项前后顺序随机。这就要求节点ID具备恢复一定时段内归属不同业务逻辑的不同节点日志前后准确顺序的能力。综合以上需求，作为日志内容索引，日志ID和节点ID需要具备表6所示的特性：

表6日志ID和节点ID特性

1、日志ID生成方法。

SnowFlake算法具备ID生成速度快，独立灵活等特点。因此，可以采用SnowFlake算法构造日志ID，日志ID包括：序列号、设备戳与时间戳以及预留项；其中：序列号采用递增形式；设备戳包括：程序ID与车站ID；程序ID为车站设备内程序或程序内部通道的唯一标识符；时间戳包括：毫秒ID、秒数ID与日期ID；所述毫秒ID为日志构造时刻的毫秒值；秒数ID为每日零时起的秒数，实现单日时段内秒数ID唯一；日期ID为距本年本季度起始日期的天数，实现季度时段内日期ID唯一。通过上述生成的日志ID可以满足各铁路局既有日志系统需求，保证在季度(3个自然月)范围内各终端日志模块生成的日志ID的唯一性和模块内部日志ID的递增性。

示例性的，可以生成64bit日志ID，各字段含义如表7所示。

表7日志ID数字位含义

2、节点ID生成方法。

本发明实施例中，采用递增循环方式由各网络终端节点构造节点ID(例如，16bit节点ID)，取值范围为[0～65535]，单一日志场景内的节点ID有序但不保证连续(例如，表5所示的，单个行车日志中的所有节点ID是按照先后顺序排布，但是不要求ID连续)，相近时间段内的不同场景的日志节点ID有序，日志节点ID有序可以简单理解为日志节点ID递增排序，以列车排路为例，排路场景会自动产生预告发送场景；两个场景的主要节点顺序为：a)检查时机，发送排路命令；b)联锁排路成功；c)列车驶入区间，发送进路预告；d)接收预告回执；e)列车占用。其中，a/b/e是自动排路场景，c/d是预告场景；五个节点虽然归属两个场景，然节点顺序必然是a在最前，依次为bcde排列的(两个相邻节点大小关系确定，但ID数值间隔不一定相同)。

由于节点ID内嵌于日志场景，日志ID唯一有效的时间范围(一个季度)远超单一场景持续时间(一般为若干分钟)，由日志ID管控下的节点ID，能够实现原始无序的不同场景日志节点归类存储于日志场景以及反向解析复原功能。

四、行车日志持久化操作。

调度系统中各网络终端节点的计算能力和存储能力是固定和有限的，将分布式日志通过网络归集到中心日志服务器对日志的长期保存和集中分析处理以及后期的数据挖掘必要。

图1的步骤S16和步骤S25中的日志数据持久化操作可以为数据的本地硬盘直接存储，也可以为网络传输后的服务器端硬盘存储，或者二者兼顾。

数据的网络传输模式可以为日志模块内嵌网络传输功能，也可独立为松耦合和低时延的网络传输模块，二者通过文件系统监控建立关联。针对不同操作系统，分别选用Linux系统下的Inotify机制和Windows系统下的文件目录监控机制实现此功能。

在网络传输技术上，可以自行开发Socket直传功能，也可采用第三方中间件，如ActiveMQ等日志分发技术。

五、场景日志的反向解析。

场景日志的反向解析，即为根据日志ID和节点ID判定日志顺序的图1操作的逆过程，故不再赘述。

六、行车场景模板定制及动态更新。

铁路行车业务扩展将带来行车日志的场景模板扩展。行车日志场景模板的灵活定制及动态更新对本方案的现场应用有极大实际意义。

本发明实施例中，新增日志场景模板服务器(位于中心)与更新客户端(与日志模块位置相同)实现行车场景模板定制及动态更新；日志场景模板服务器用于铁路局或整条线路的行车场景模板的统一定制与更新操作，以及管辖范围内网络终端节点的场景模板的版本控制，更新客户端是日志模块和日志场景模板服务器的桥梁。

如图6所示，为实现行车场景模板定制及动态更新的流程图，主要步骤包括：

1)日志模块启动，读取本地既有的行车场景模板，启动更新客户端。

2)更新客户端连接日志场景模板服务器。

3)更新客户端读取本地既有的行车场景模板，发送本地行车场景模板概要信息至日志场景模板服务器，包括：场景模板的总版本与模板文件概要信息。

由于行车场景模板涉及到动态更新，因此更新客户端也会更新自身的行车场景模板，每一次更新，都需要记录版本；场景模板的总版本可以理解为行车场景模板文件的最新版本；每一个版本，会有一个概要信息，主要用于描述本版本的修改内容，例如，上一个版本为2.1，本版本为2.2，概要信息记录2.2新增加内容，“本版本引入进路预告在超时报警功能下的场景日志模板”。

4)日志场景模板服务器动态编制或更新行车场景模板。

5)在设定时刻(例如，空闲时刻或者需要更新模版的时刻)，日志场景模板服务器向更新客户端发送更新请求，主动将更新后的行车场景模板推送到更新客户端。

6)日志场景模板服务器以单一行车场景模板文件为单元，依次发送待更新的行车场景模板，在发送过程中，更新客户端接收文件，保存至网络终端节点的临时位置。这一步骤采用的临时保存机制，为更新失败后的版本回退提供支持。

7)更新客户端与日志模块交互，在日志模块业务量不高于设定值的时刻，进行行车场景模板更新。

8)日志模块同意更新后，以完全重启并重读全部日志场景模板的方式，或者热更新，只读取变化部分的方式，实现行车场景模板的动态更新。

9)日志模块本地更新完成。

10)更新客户端将网络终端节点临时位置中的已更新的行车场景模板移至日志模块配置路径，同时将更新的行车场景模板概要信息通知日志场景模板服务器。

相较于现有技术而言，本发明上述方案主要带来了如下有益效果：

1)日志模块松耦合于业务模块，功能独立，可靠性高；后期升级维护便捷。

2)日志缓存功能和网络传输的中间件技术，可以有效削峰，实现数据的平稳输出。

基于场景的日志压缩方法，在终端计算量较少增加的前提下，大幅提高数据存储效率，降低终端存储压力；同时连带提高网络传输效率，有助于日志数据的统一归集、管理和分析。

3)方案中的日志场景模板可动态更新。热更新或简单冷重启的灵活更新方式，对现场既有系统和在用业务影响较小。

4)进一步降低的日志数据冗余，有利于日志数据挖掘和价值提取。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例可以通过软件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，上述实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。