官话

2007年1月胶济客运专线开工，为维持运营，修建多条便线，事故发生于其中之一DK310，中铁二十局2007年10月-2008年3月间修建。便线的工程标准低于常规，该线又因故呈S形，设计半径400米，实际半径可能更小。3月21日晚驳接，3月23日济南局发布4240、4241号调度命令，该线临时限速。

4月23日济南局又发布154号文件<关于实行胶济线施工调整列车运行图的通知>，将该线80公里/小时临时限速改为图定限速，4月28日0点起执行。4月26日发布4158号调度命令，废止此前临时限速。图定限速即运行图常规限速，显示为机车运行监控器，俗称黑匣子屏幕上的一条红色曲线。施工临时限速发车前由IC卡输入运监器。司机只能在限速内运行，否则列车将自动制动。

一些媒体显然对此报道失误，并被网站以讹传讹：“……4158号调度命令，要求取消多处限速，其中正包括王村至周村东间……何以出尔反尔，在发文限速之后又以调度命令形式取消限速……”实际上取消地不是限速而是临时，4158号命令是154号文件的补充而非中止。

媒体猜错开头，却猜对了结局。4158号只能算半个命令，与154号文件对照才能理解。据网上公布的事故调查资料(以下简称据查)，该命令第一句即“根据济铁运函[2008]154号文件”云云，默认对方已收到文件。也说明并非出尔反尔。问题是，内容关联，却通过两个信息系统分别发送，我称为官话和工话系统。

前者基于权威，形如金字塔，从单一的中心下发若干单行的权线(限)，每线依此类推。根据收发者地位，又分三种方式。一般下行比上行快。154号文件的文件可不简单，俗称红头文件，非常国情，正是下行的主要格式。红头突出发文单位名，名头大小，决定传播速度和下级重视程度。本次事故即提供一个案例，据查，23日文件发布，济南局调度所下载电子公文，24日调度所网站下达学习和落实文件的通知。25日9:15分召开诸工种当值班主任会议。而上行未必有时间期限和回复义务，上级甚至只简单地批示“已阅”或“知道了”。

上行和下行都是内行，即同线传播，异线则为外行，一般不如内行快。首先距离长，即使两人办公桌对桌，只要行政序列异线，就不能直接对话。当然可以私下交流，但落实只能走正式流程，先上行至两线的交点再下行。其次不重视。每人只对本线上级负责，俗话说县官不如现管，强龙难压地头蛇，除非外线来头非常大，本线惹不起。

本次事故中即存在外行，报道很清楚：“北京机务段并非济南局下辖单位，根据行文惯例，济南铁路局没有把它列为受文单位，只作为抄送单位。公文应由北京局逐级传达至运输处、调度所，再到相关机务段、车辆段。”据查，事发前约两小时，济南局电务段某员工仍不知道154号文件，我们猜想，这是因为该文件针对调度而非电务，可视为某种隐性的外行。

铁路现有18个铁路局，火车数小时就能穿越一局的辖区，官话显然太慢，调度另有一套工话系统。工话的速度接近实时，内容基于合理，本次事故中限速取决于铁路工程原理，而非发布者职权。工话采用网络架构，多中心也无中心，各调度所是平等的信息源，也没有固定的边界和路径，全国是一张网，直接发送外局调度所，与经过辖区的列车建立临时的指挥关系。

两者在铁路内部的正式名称，分别是办公信息系统和运输调度指挥管理信息系统(DMIS)，前者从1980年代中期分散地建设，1998年开始整合。凑巧地是，2001年初选定在全路推广的“铁路办公信息系统”1.0版标准软件，正是济南局开发。1996年开始建设DMIS，2004年一期工程开通，二期启动。

济南局提前于23日发布并抄送外局28日0点生效的154号文件，其调度所不在当天或稍后，而是26日才发布4158号命令撤消临时限速，说明全局上下对官话和工话的速度并非没有认识，留出了余量。我们猜想，铁路内部约定俗成，官话外行一般三天，最迟五天送达。上述三个时间不是巧合，而是习惯成自然。铁路的业务特点，相比很多官僚机构已经神速。

但约定俗成不是严格的制度，这次就出现例外，不知什么原因，大为延误。这是单线系统的通病，一点中断会导致全线崩溃。包括T195次，运监器数据与限速标志不符的列车多隶属北京局，说明延误发生在该局。但工话仍迅速可靠地送达了半个命令，北京机务段就像媒体的误报，理解为撤销限速并从IC卡删除，向悲剧迈出第一步。

看到这里，大家会想：如果文件和命令都用一个信息系统发布，同时延误或到达，就可能避免事故。事发次日，新任局长耿志修坦承，“济南局对施工文件、调度命令管理混乱，用文件代替临时限速命令极不严肃。”多家媒体也持此看法。事情没有这么简单。