车道收费系统的关键技术及其Delphi环境下的实现.docVIP

车道收费系统的关键技术及其Delphi环境下的实现 　　摘要： 前言 本文讨论了高速公路收费系统中车道收费系统的关键技术，从系统稳定、可靠、简单、实用的角度提出了新的设计思路，并给出了Delphi环境下的具体实现。 　　　详细内容： 目前我国高速公路收费系统一般都是采用人工判别车型、人工收费、计算机管理、检测器计算校核、闭路电视辅助监督的半自动收费方式。在这种采用半自动收费方式的收费系统中，车道收费系统是其核心。车道收费系统运行于车道控制机上，实现车道收费设备（栏杆机、红绿灯、天棚灯、IC卡读写器、票据打印机等）自动控制，协助收费员完成入口发卡、出口收费操作。车道收费系统要24小时连续运行，对收费数据的完整性、可靠性和实时性都有很高的要求。同时车道收费系统还要为防作弊提供有力手段。本文就车道收费系统的关键技术进行讨论，并给出在Delphi环境下的具体实现，车道收费系统采用Client/Server体系结构，网络操作系统（NOS）为Windows NT 4.0，数据库管理系统为Microsoft SQL 7.0，车道控制机操作系统为Win95/Win98。前端开发工具为Delphi 5.0。 单机、网络双轨制工作 车道收费系统要求具有24小时不间断工作能力，即使在车道的收费站之间的网络连接中断时。同时要求网络中断时，收费员要能象网络正常时一样工作，并且系统能把收费数据保留在车道上，当网络恢复正常时，系统会自动把数据上传。这就是所谓的单机、网络双轨制工作。即系统要能在网络正常和中断之间自动切换，保持正常工作状态，同时要保证数据的完整性。 　　国内绝大多数车道收费软件都是采用面向非连接的异步轮寻数据方式，以避免那种面向连接数据通信方式为网络中断或不稳定时，系统会长时间的等待，甚至逻辑闭锁，从而导致与车道连续工作要求和响应时间要求相冲突的问题。然而这种面向非连接的异步数据轮寻方式在通讯策略控制上很麻烦，且收费数据上传的实时性上也受得一定限制。笔者在此提出一种新的设计思想，可以很好地解决这些问题。 Windows操作系统是一个多任务操作系统，不象在DOS这样的单任务操作系统中，用户在计算机中启动一个程序后，只有等待其完成后才能运行另一个程序。在Windows操作系统中，用户可以一次启动多个程序，甚至可以启动一个程序的多个实例。因此，在车道收费系统中，我们可以把车道应用程序分解为两个独立的应用程序。一个Toll.ExE的程序专门负责前台的收费业务，并把收费数据（包括抓拍的图像）存放在本地盘上。这个Toll.EXE程序不涉及到网络。因此当网络出现故障或者不稳定时，它依然能正常工作；另一个叫Back.EXE的程序专门负责车道和收费站服务器之间的后台数据通信，包括定时下载员工表、费率表、黑白名单。服务器时钟和实时上传收费数据。Back.EXE程序运行与网络状态有关，但不影响前台收费业务的进行。车道收费系统运行时，先最小化运行Back.EXE程序。在Back.EXE程序中再调用Toll.EXE。对于用户来说，车道收费系统象一个程序。在Delphi 5.0中，要实现在一个应用程序调用另一个应用程序非常简单。因为Delphi中调用Windows API函数如同调用自身内部函数一样(Delphi已在Window.pas中全部声明了Windows API)，Windows API函数中WinExec函数可实现此功能。具体调用格式为： WinExec（‘:\Toll.Exe,SW_MAXIMIZE’）。 　　以上讨论只是解决了当网络发生故障或不稳定时，系统仍能正常工作的问题，要解决收费数据实时上传问题就必须保持Back.EXE和Toll.EXE程序的实时通信。当然Back.EXE程序定时（用定时器来触发完成）发送数据也可以。但实际收费业务中车道车流量密度随机很大，高峰时，收费员处理不过来，而有时十分钟，甚至一个小时都没有一辆车（深夜常见的现象）。因此，定时器时间间隔不好定。间隔过大不能达到收费数据实时发送的要求，过小则计算机资源消耗过多，且在长时间无车时，显然是做无用功。因此，采用定时发送收费数据的方式很不合理。 　　Windows系统是消息（Message）驱动的操作系统。Window的应用程序通过对接收到的各种消息进行处理来完成任务。因此基于Window的消息响应机制可以建立Back.EXE程序和Toll.EXE程序之间的实时通信以实现收费数据的实时上传。其具体实现过程为： A．在Toll.EXE程序中先定义消息。当程序处理完了一条收费记录（即收费数据存入当地数据库表中后）后，Back.EXE程序发送已定义的消息，在发送消息之前，要先找到Back.EXE程序的窗口句柄。 Const Wm_TollMsg=WM_USER+1000 //定义消息 If